Subject: Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: New Version Notification for draft-xu-l3vpn-virtual-subnet-02.txt

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 29 Nov 2013 07:55:08 +0000

On 29/11/13 07:56, "Xuxiaohu" <[email-masked]> wrote:

>
>
>> -----邮件原件-----
>> 发件人: Henderickx, Wim (Wim) [mailto:[email-masked]]
>> 发送时间: 2013年11月29日 12:59
>> 收件人: Xuxiaohu; [email-masked]
>> 抄送: [email-masked]
>> 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: New
>> Version Notification for draft-xu-l3vpn-virtual-subnet-02.txt
>> 
>> I believe we have a disagreement here. The trace route is not providing
>>the
>> output expected. If you define a solution you need to ensure the
>>applications
>> behave in the way IP was designed and as such your solution is not
>>compliant to
>> this.
>
>I have to emphasize that it's absolutely the expected output in the case
>where the Proxy ARP [RFC1027] is deployed. Unless you are strongly
>against the Proxy ARP technology itself which was actually designed at
>most the same time when IP was initially designed...
WH> I am not against this, but there are other ways of implementing it as
I mentioned it before and these solution do not have the issues which I
outlined.
>
>> If you like it or not, it is reality.
>
>No matter you like it or now, the approach of using the host routing and
>the Proxy ARP to emulate an extended subnet has been increasingly
>implemented by more and more vendors in their data center network
>products. It's the reality.
WH> this doesn’t mean that IETF need to adopt it, since it breaks a number
of things
>
>Xiaohu
>
>
>
>> On 29/11/13 02:35, "Xuxiaohu" <[email-masked]> wrote:
>> 
>> >
>> >
>> >> -----邮件原件-----
>> >> 发件人: Henderickx, Wim (Wim)
>> [mailto:[email-masked]]
>> >> 发送时间: 2013年11月28日 18:46
>> >> 收件人: Xuxiaohu; [email-masked]
>> >> 抄送: [email-masked]
>> >> 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: New
>> Version Notification for
>> >> draft-xu-l3vpn-virtual-subnet-02.txt
>> >>
>> >> Please look at the VRF table instance in that example. The packet
>> >>destined for  2.2.2.x is forwarded according to the default route
>> >>advertised by PE-3.
>> >>
>> >> Since each PE acts as a default GW, there is no impact to the output
>> >>of the trace  route for an IP address which is not within the same
>> >>subnet as the trace-route  originator (IMO, this is the major usage of
>> >>trace route).
>> >> If you just want to try a trace route for an IP address which is
>> >>within the same  subnet of the trace-route originator, there are just
>> >>two more hops (i.e., ingress  PE and egress PE) in the output (see
>> >>below), does it matter in practice?
>> >>
>> >> <Host_1>tracert 1.1.1.5
>> >> traceroute to  1.1.1.5(1.1.1.5), max hops: 30 ,packet length:
>> >>40,press CTRL_C t  o break
>> >> 1 1.1.1.1 40 ms  40 ms  50 ms
>> >> 2 1.1.1.1 120 ms  80 ms  110 ms
>> >> 3 1.1.1.5 140 ms  100 ms  90 ms
>> >> <Host_1>
>> >>
>> >>
>> >>
>> >> WH> and this is what I meant with broken since the trace route is
>> >> expecting 1 hop iso 3.
>> >
>> >It's no more a surprise once you have understood that the intra-subnet
>> >traffic is forwarded at L3.
>> >
>> >As I have said before, there is no impact on the normal trace route
>> >function. By the way, are you usually using the trace route command
>> >rather than the PING command on one host to check the connectivity to
>> >another host when these two hosts are actually within the same subnet?
>> >
>> >
>> >> On 28/11/13 09:45, "Xuxiaohu" <[email-masked]> wrote:
>> >>
>> >> >
>> >> >
>> >> >> -----邮件原件-----
>> >> >> 发件人: Henderickx, Wim (Wim)
>> >> [mailto:[email-masked]]
>> >> >> 发送时间: 2013年11月28日 15:44
>> >> >> 收件人: Xuxiaohu; [email-masked]
>> >> >> 抄送: [email-masked]
>> >> >> 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: New Version
>> >> Notification for
>> >> >> draft-xu-l3vpn-virtual-subnet-02.txt
>> >> >>
>> >> >>
>> >> >>
>> >> >> On 28/11/13 08:33, "Xuxiaohu" <[email-masked]> wrote:
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> >> -----邮件原件-----
>> >> >> >> 发件人: Henderickx, Wim (Wim)
>> >> >> [mailto:[email-masked]]
>> >> >> >> 发送时间: 2013年11月28日 14:13
>> >> >> >> 收件人: Xuxiaohu; [email-masked]
>> >> >> >> 抄送: [email-masked]
>> >> >> >> 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: New Version
>> >> Notification
>> >> >> for
>> >> >> >> draft-xu-l3vpn-virtual-subnet-02.txt
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> On 28/11/13 04:02, "Xuxiaohu" <[email-masked]> wrote:
>> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >> -----邮件原件-----
>> >> >> >> >> 发件人: Henderickx, Wim (Wim)
>> >> >> >> [mailto:[email-masked]]
>> >> >> >> >> 发送时间: 2013年11月28日 1:53
>> >> >> >> >> 收件人: Xuxiaohu; [email-masked]
>> >> >> >> >> 抄送: [email-masked]
>> >> >> >> >> 主题: Re: 答复: 答复: 答复: 答复: 答复: New Version
>> Notification
>> >> for
>> >> >> >> >> draft-xu-l3vpn-virtual-subnet-02.txt
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> On 27/11/13 09:12, "Xuxiaohu" <[email-masked]> wrote:
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >> -----邮件原件-----
>> >> >> >> >> >> 发件人: Henderickx, Wim (Wim)
>> >> >> >> >> [mailto:[email-masked]]
>> >> >> >> >> >> 发送时间: 2013年11月27日 14:14
>> >> >> >> >> >> 收件人: Xuxiaohu; [email-masked]
>> >> >> >> >> >> 抄送: [email-masked]
>> >> >> >> >> >> 主题: Re: 答复: 答复: 答复: 答复: New Version Notification
>> for
>> >> >> >> >> >> draft-xu-l3vpn-virtual-subnet-02.txt
>> >> >> >> >> >>
>> >> >> >> >> >> You are changing the forwarding plane of a L3 service and
>> >> >> >> >> >>as such this is not  implementable in merchant silicon so
>>far.
>> >> >> >> >> >>You need a flexible network processor  to do this and I am
>> >> >> >> >> >>not sure about the performance implications.
>> >> >> >> >> >
>> >> >> >> >> >Future merchant silicon could be adapted to support such
>> >> >> >> >> >TTL handling requirement as long as Layer3 forwarding for
>> >> >> >> >> >intra-subnet traffic is worthwhile in practice. In
>> >> >> >> >> >addition, even with the existing L3 forwarding chips which
>> >> >> >> >> >don't support that TTL handling requirement, the
>> >> >> >> >> >Layer3 overlay could still be applicable to most
>> >> >> >> >> >applications except a few ones where TTL is set to 1.
>> >> >> >> >> WH> even with what you say you break basic applications like
>> >> >> >> >> WH> trace route,
>> >> >> >> >
>> >> >> >> >No, it will not break the trace-route application. It has been
>> >> >> >> >successfully verified in our implementation.
>> >> >> >> WH> can you show an output. W/o the TTL handling your hops will
>> >> >> >> WH> be
>> >> >> >> incorrect
>> >> >> >
>> >> >> >
>> >> >> >In the example illustrated at Figure 4 of the draft, the trace
>> >> >> >route output on Host A is as follows (note that 2.2.2.1 is a vrf
>> >> >> >interface address of PE-3):
>> >> >> >
>> >> >> >[Host_1]tracert 2.2.2.1
>> >> >> > traceroute to  2.2.2.1(2.2.2.1), max hops: 30 ,packet length:
>> >> >> >40,press CTRL_C t o break
>> >> >> > 1 1.1.1.1 60 ms  50 ms  50 ms
>> >> >> > 2 2.2.2.1 90 ms  60 ms  80 ms
>> >> >>
>> >> >> WH> figure 4 is addressing 1.1.1.x not 2.2.2.x and the output
>> >> >> WH> should be
>> >> >> from a intra-subnet
>> >> >
>> >> >Please look at the VRF table instance in that example. The packet
>> >> >destined for 2.2.2.x is forwarded according to the default route
>> >> >advertised by PE-3.
>> >> >
>> >> >Since each PE acts as a default GW, there is no impact to the output
>> >> >of the trace route for an IP address which is not within the same
>> >> >subnet as the trace-route originator (IMO, this is the major usage
>> >> >of trace
>> >>route).
>> >> >If you just want to try a trace route for an IP address which is
>> >> >within the same subnet of the trace-route originator, there are just
>> >> >two more hops (i.e., ingress PE and egress PE) in the output (see
>> >> >below), does it matter in practice?
>> >> >
>> >> ><Host_1>tracert 1.1.1.5
>> >> > traceroute to  1.1.1.5(1.1.1.5), max hops: 30 ,packet length:
>> >> >40,press CTRL_C t o break
>> >> > 1 1.1.1.1 40 ms  40 ms  50 ms
>> >> > 2 1.1.1.1 120 ms  80 ms  110 ms
>> >> > 3 1.1.1.5 140 ms  100 ms  90 ms
>> >> ><Host_1>
>> >> >
>> >> >> >> >> etc. SO I don’t want to adopt it at all with such impact on
>> >> >> >> >> the
>> >> >>DP.
>> >> >> >> >> >
>> >> >> >> >> >> So why I am against this draft is because it has a big
>> >> >> >> >> >>impact on the data-plane.
>> >> >> >> >> >
>> >> >> >> >> >Does EVPN have no impact on the data-plane? Are you against
>> >> >> >> >> >that draft as well due to its impact on the data plane?
>> >> >> >> >> WH> not in its basic form
>> >> >> >> >
>> >> >> >> >However, the major selling-point of that technology (i.e.,
>> >> >> >> >active-active
>> >> >> >> >multi-homing) is lost in its basic form accordingly.
>> >> >> >> WH> no its not
>> >> >> >
>> >> >> >If no change to the existing data plane, how to realize the
>> >> >> >following split-horizon function?
>> >> >> >
>> >> >> >9.3 Split Horizon
>> >> >> >
>> >> >> >   Consider a CE that is multi-homed to two or more PEs on an
>> >>Ethernet
>> >> >> >   segment ES1 operating in All-Active mode. If the CE sends a
>> >> >> >   broadcast, unknown unicast, or multicast (BUM) packet to one
>> >> >> > of
>> >>the
>> >> >> >   non-DF (Designated Forwarder) PEs, say PE1, then PE1 will
>>forward
>> >> >> >   that packet to all or subset of the other PEs in that EVPN
>> >>instance
>> >> >> >   including the DF PE for that Ethernet segment. In this case
>> >> >> > the DF
>> >> >>PE
>> >> >> >   that the CE is multi-homed to MUST drop the packet and not
>> >>forward
>> >> >> >   back to the CE. This filtering is referred to as "split
>>horizon"
>> >> >> >   filtering in this document.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >Sajassi, et al.         Expires January 15, 2014
>>[Page
>> >> >>17]
>> >> >> >
>> >> >> >INTERNET DRAFT        BGP MPLS Based Ethernet VPN          July
>> >> 15,
>> >> >> 2013
>> >> >> >
>> >> >> >
>> >> >> >   In order to achieve this split horizon function, every BUM
>>packet
>> >> >> >   originating from a non-DF PE is encapsulated with an MPLS
>> >> >> > label
>> >>that
>> >> >> >   identifies the Ethernet segment of origin (i.e. the segment
>>from
>> >> >> >   which the frame entered the EVPN network). This label is
>> >>referred to
>> >> >> >   as the ESI label, and MUST be distributed by all PEs when
>> >>operating
>> >> >> >   in All-Active multi-homing mode using the "Ethernet A-D route
>> >> >> > per
>> >> >>
>> >> >> WH> when you use virtual chassis all works naturally and split
>> >> >> WH> horizon is
>> >> >> handled by the VC.
>> >> >> >> >> >> The fundamental difference between the proposals is that
>> >> >> >> >> >>you have on egress a  mapping in the label that determines
>> >> >> >> >> >>the forwarding behaviour to be applied,  rather than
>> >> >> >> >> >>having to check src/dst IP matches + LPM lookups.
>> >> >> >> >> >
>> >> >> >> >> >Are you still talking about L3 overlay service for
>> >> >> >> >> >intra-subnet
>> >> >> >> >>traffic?
>> >> >> >> >> WH> I am talking about this draft
>> >> >> >> >
>> >> >> >> >If you are talking about the Virtual Subnet draft, then your
>> >> >> >> >above argument is incorrect. The egress PE would perform IP
>> >> >> >> >lookup in the corresponding VRF table.
>> >> >> >> WH> I am talking about the fact when proper TTL handling has to
>> >> >> >> WH> be
>> >> >> >> applied, you need to determine whether or not to decrement the
>> >> >> >>TTL and as  such you end up doing additional lookups to
>>determine
>> this.
>> >> >> >>As such you will  impact performance.
>> >> >> >
>> >> >> >Have you seen performance degradation on your routers once an ACL
>> >> >> >entry or uRPF check is enabled on interfaces?
>> >> >>
>> >> >> WH> urpf/ACL are handled naturally, but you create a new pipeline
>> >> >> WH> and look
>> >> >> at the operations you have to do to check the intra/inter-subnet
>> >> >>forwarding.
>> >> >> This is whats avoids to use merchant silicon and what impact
>> >> >>performance.
>> >> >> >
>> >> >> >Xiaohu
>> >> >> >
>> >> >> >> >Xiaohu
>> >> >> >> >
>> >> >> >> >> >Xiaohu
>> >> >> >> >> >
>> >> >> >> >> >> On 27/11/13 02:31, "Xuxiaohu" <[email-masked]>
>>wrote:
>> >> >> >> >> >>
>> >> >> >> >> >> >Fine. In my draft, both intra-subnet and inter-subnet IP
>> >> >> >> >> >> >traffic are forwarded at layer3 while in the draft you
>> >> >> >> >> >> >mentioned below only inter-subnet traffic would be
>> >> >> >> >> >> >forwarded at layer3. They are totally different
>> >> >> >> >> >> >approaches and therefore it's meaningless to say which
>> >> >> >> >> >> >one is easier
>> >>or not.
>> >> >> >> >> >> >
>> >> >> >> >> >> >Xiaohu
>> >> >> >> >> >> >
>> >> >> >> >> >> >> -----邮件原件-----
>> >> >> >> >> >> >> 发件人: Henderickx, Wim (Wim)
>> >> >> >> >> >> [mailto:[email-masked]]
>> >> >> >> >> >> >> 发送时间: 2013年11月25日 19:16
>> >> >> >> >> >> >> 收件人: Xuxiaohu; [email-masked]
>> >> >> >> >> >> >> 抄送: [email-masked]
>> >> >> >> >> >> >> 主题: Re: 答复: 答复: 答复: New Version Notification for
>> >> >> >> >> >> >> draft-xu-l3vpn-virtual-subnet-02.txt
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Lets debate the technical solutions iso blogs.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> On 25/11/13 08:52, "Xuxiaohu" <[email-masked]>
>> >>wrote:
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> >I suggest you read the following blog post by Yakov
>> >> >> >> >> >> >>
>> >>>(http://opencontrail.org/why-contrail-is-using-bgpmpls/).
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> -----邮件原件-----
>> >> >> >> >> >> >> >> 发件人: Henderickx, Wim (Wim)
>> >> >> >> >> >> >> [mailto:[email-masked]]
>> >> >> >> >> >> >> >> 发送时间: 2013年11月25日 15:27
>> >> >> >> >> >> >> >> 收件人: Xuxiaohu; [email-masked]
>> >> >> >> >> >> >> >> 抄送: [email-masked]
>> >> >> >> >> >> >> >> 主题: Re: 答复: 答复: New Version Notification for
>> >> >> >> >> >> >> >> draft-xu-l3vpn-virtual-subnet-02.txt
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> There are easier ways to do this which don’t
>> >> >> >> >> >> >> >>required data-plane changes.
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>https://tools.ietf.org/html/draft-sajassi-l2vpn-evpn
>> >> >> >> >> >> >> >>-in
>> >> >> >> >> >> >> >>ter
>> >> >> >> >> >> >> >>-su
>> >> >> >> >> >> >> >>bne
>> >> >> >> >> >> >> >>t-f
>> >> >> >> >> >> >> >>orw
>> >> >> >> >> >> >> >>ard
>> >> >> >> >> >> >> >>in
>> >> >> >> >> >> >> >> g-02
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> On 25/11/13 07:40, "Xuxiaohu" <[email-masked]>
>> >> >>wrote:
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >> -----邮件原件-----
>> >> >> >> >> >> >> >> >> 发件人: Henderickx, Wim (Wim)
>> >> >> >> >> >> >> >> [mailto:[email-masked]]
>> >> >> >> >> >> >> >> >> 发送时间: 2013年11月25日 14:29
>> >> >> >> >> >> >> >> >> 收件人: Xuxiaohu; [email-masked]
>> >> >> >> >> >> >> >> >> 抄送: [email-masked]
>> >> >> >> >> >> >> >> >> 主题: Re: 答复: New Version Notification for
>> >> >> >> >> >> >> >> >> draft-xu-l3vpn-virtual-subnet-02.txt
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> It is not about TTL 1, no TTL decrement should
>> >> >> >> >> >> >> >> >>happen for intra-subnet  forwarding at all On top
>> >> >> >> >> >> >> >> >>you need to modify the data-plane to achieve
>> >> >> >> >> >> >> >> >>this, since it now needs to find out if it is
>> >> >> >> >> >> >> >> >>intra or inter subnet where current
>> >> >> >> >> >> >> >> >>PE(s)  don’t have to do
>> >> >> >> >> >> >>this.
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >Sure, it needs some change to the implementation
>> >> >> >> >> >> >> >> >of PE
>> >> >> >> >>routers.
>> >> >> >> >> >> >> >> >That's why we need a draft to specify the
>> >> >> >> >> >> >> >> >implementation
>> >> >> >> >> >> >>requirements.
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >> On 25/11/13 07:22, "Xuxiaohu"
>> >> >> >> >> >> >> >> >> <[email-masked]>
>> >> >> >>wrote:
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> >Wim,
>> >> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >> >It said clearly "if the source and destination
>> >> >> >> >> >> >> >> >> >addresses of a packet whose TTL is set to 1
>> >> >> >> >> >> >> >> >> >belong to the same extended subnet, both
>> >> >> >> >> >> >> >> >> >ingress and egress PE routers MUST NOT
>> >> >> >> >> >> >> >> >> >decrement the TTL of
>> >>such
>> >> packet."
>> >> >> >> >> >> >> >> >> >Did you doubt that the PE routers could know
>> >> >> >> >> >> >> >> >> >whether the source and destination address
>> >> >> >> >> >> >> >> >> >belong to the same
>> >> >> >> >> >> >> extended subnet?
>> >> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >> >Xiaohu
>> >> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >> >> -----邮件原件-----
>> >> >> >> >> >> >> >> >> >> 发件人: Henderickx, Wim (Wim)
>> >> >> >> >> >> >> >> >> [mailto:[email-masked]]
>> >> >> >> >> >> >> >> >> >> 发送时间: 2013年11月25日 14:08
>> >> >> >> >> >> >> >> >> >> 收件人: Xuxiaohu; [email-masked]
>> >> >> >> >> >> >> >> >> >> 抄送:
>> >> >> >> >> >> >> >> >> >>[email-masked]
>> >> >> >> >> >> >> >> >> >> 主题: Re: New Version Notification for
>> >> >> >> >> >> >> >> >> >>draft-xu-l3vpn-virtual-subnet-02.txt
>> >> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> >> On the TTL issue I believe this is not
>> >> >> >> >> >> >> >> >> >> addressing the
>> >> >> >> >>issue.
>> >> >> >> >> >> >> >> >> >>We can say don’t  decrement but when and how
>> >> >> >> >> >> >> >> >> >>will the
>> >> >> >> >> >> >> >> >> >>PE(s) do or
>> >> >> >> >> >> >> >>don’t.
>> >> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> >> On 25/11/13 03:22, "Xuxiaohu"
>> >> >> >> >> >> >> >> >> >> <[email-masked]>
>> >> >> >> >>wrote:
>> >> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> >> >Hi all,
>> >> >> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >> >> >Major changes since the -01 version include:
>> >> >> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >> >> >1) add a section about TTL consideration;
>> >> >> >> >> >> >> >> >> >> >2) remove the section of PE Router FIB
>> >> >> >> >> >> >> >> >> >> >Reduction;
>> >> >> >> >> >> >> >> >> >> >3) remove the section of PE Router RIB
>> >> >> >> >> >> >> >> >> >> >Reduction;
>> >> >> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >> >> >Any further comments are welcome. BTW, the
>> >> >> >> >> >> >> >> >> >> >removed sections as mentioned above would be
>> >> >> >> >> >> >> >> >> >> >described in
>> >> >> >> >>separate
>> >> >> >> >> docs.
>> >> >> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >> >> >Best regards, Xiaohu
>> >> >> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >> >> >> -----邮件原件-----
>> >> >> >> >> >> >> >> >> >> >> 发件人: [email-masked]
>> >> >> >> >> >> >> >> >> >> >>[mailto:[email-masked]]
>> >> >> >> >> >> >> >> >> >> >> 发送时间: 2013年11月25日 10:10
>> >> >> >> >> >> >> >> >> >> >> 收件人: Brendan Fee; Susan Hares; Fan
>> >> >> >> >> >> >> >> >> >> >>Yongbing; Xuxiaohu; Xuxiaohu; Christian
>> >> >> >> >> >> >> >> >> >> >>Jacquenet; Truman Boyes; Yongbing Fan
>> >> >> >> >> >> >> >> >> >> >> 主题: New Version Notification for
>> >> >> >> >> >> >> >> >> >> >>draft-xu-l3vpn-virtual-subnet-02.txt
>> >> >> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> >> >> A new version of I-D,
>> >> >> >> >> >> >> >> >> >> >>draft-xu-l3vpn-virtual-subnet-02.txt
>> >> >> >> >> >> >> >> >> >> >> has been successfully submitted by Xiaohu
>> >> >> >> >> >> >> >> >> >> >>Xu and posted to the IETF repository.
>> >> >> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> >> >> Filename:	 draft-xu-l3vpn-virtual-subnet
>> >> >> >> >> >> >> >> >> >> >> Revision:	 02
>> >> >> >> >> >> >> >> >> >> >> Title:		 Virtual Subnet: A L3VPN-based
>>Subnet
>> >> >> >> >>Extension
>> >> >> >> >> >> >> >>Solution
>> >> >> >> >> >> >> >> >> >> >> Creation date:	 2013-11-25
>> >> >> >> >> >> >> >> >> >> >> Group:		 Individual Submission
>> >> >> >> >> >> >> >> >> >> >> Number of pages: 13
>> >> >> >> >> >> >> >> >> >> >> URL:
>> >> >> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> >>http://www.ietf.org/internet-drafts/draft-xu-l
>> >> >> >> >> >> >> >> >> >>3vp
>> >> >> >> >> >> >> >> >> >>n-v
>> >> >> >> >> >> >> >> >> >>irt
>> >> >> >> >> >> >> >> >> >>ual
>> >> >> >> >> >> >> >> >> >>-su
>> >> >> >> >> >> >> >> >> >>bne
>> >> >> >> >> >> >> >> >> >>t-0
>> >> >> >> >> >> >> >> >> >>2.t
>> >> >> >> >> >> >> >> >> >>xt
>> >> >> >> >> >> >> >> >> >> >> Status:
>> >> >> >> >> >> >> >> >> >> >>http://datatracker.ietf.org/doc/draft-xu-l3
>> >> >> >> >> >> >> >> >> >> >>vpn
>> >> >> >> >> >> >> >> >> >> >>-vi
>> >> >> >> >> >> >> >> >> >> >>rtu
>> >> >> >> >> >> >> >> >> >> >>al-
>> >> >> >> >> >> >> >> >> >> >>sub
>> >> >> >> >> >> >> >> >> >> >>net
>> >> >> >> >> >> >> >> >> >> >> Htmlized:
>> >> >> >> >> >> >> >> >> >> >>http://tools.ietf.org/html/draft-xu-l3vpn-v
>> >> >> >> >> >> >> >> >> >> >>irt
>> >> >> >> >> >> >> >> >> >> >>ual
>> >> >> >> >> >> >> >> >> >> >>-su
>> >> >> >> >> >> >> >> >> >> >>bne
>> >> >> >> >> >> >> >> >> >> >>t-0
>> >> >> >> >> >> >> >> >> >> >>2
>> >> >> >> >> >> >> >> >> >> >> Diff:
>> >> >> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> >> >>http://www.ietf.org/rfcdiff?url2=draft-xu-l
>> >> >> >> >> >> >> >> >> >> >>3vp
>> >> >> >> >> >> >> >> >> >> >>n-v
>> >> >> >> >> >> >> >> >> >> >>irt
>> >> >> >> >> >> >> >> >> >> >>ual
>> >> >> >> >> >> >> >> >> >> >>-su
>> >> >> >> >> >> >> >> >> >> >>bne
>> >> >> >> >> >> >> >> >> >> >>t-0
>> >> >> >> >> >> >> >> >> >> >>2
>> >> >> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> >> >> Abstract:
>> >> >> >> >> >> >> >> >> >> >>    This document describes a Layer3
>> >> >> >> >> >> >> >> >> >> >> Virtual Private Network
>> >> >> >> >> >> >> >> >>(L3VPN)-
>> >> >> >> >> >> >> >> >> >> >>    based subnet extension solution
>> >> >> >> >> >> >> >> >> >> >> referred to as Virtual Subnet,
>> >> >> >> >> >> >> >> >> >>which
>> >> >> >> >> >> >> >> >> >> >>    can be used as a kind of Layer3 network
>> >> >> >> >> >> >> >> >> >> >> virtualization
>> >> >> >> >> >> >> >>overlay
>> >> >> >> >> >> >> >> >> >> >>    approach for data center interconnect.
>> >> >> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> >> >> Please note that it may take a couple of
>> >> >> >> >> >> >> >> >> >> >>minutes from the time of submission  until
>> >> >> >> >> >> >> >> >> >> >>the htmlized version and diff are available
>> >> >> >> >> >> >> >> >> >> >>at
>> >>tools.ietf.org.
>> >> >> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> >> >> The IETF Secretariat
>> >> >> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >
>> >> >> >
>> >> >
>> >
>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 29 Nov 2013 09:03:38 +0000

> 发送时间: 2013年11月29日 15:55
> 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复:
> New Version Notification for draft-xu-l3vpn-virtual-subnet-02.txt
> 
> 
> 
> >> I believe we have a disagreement here. The trace route is not
> >>providing the  output expected. If you define a solution you need to
> >>ensure the applications  behave in the way IP was designed and as such
> >>your solution is not compliant to  this.
> >
> >I have to emphasize that it's absolutely the expected output in the
> >case where the Proxy ARP [RFC1027] is deployed. Unless you are strongly
> WH> I am not against this, but there are other ways of implementing it
> WH> as
> I mentioned it before and these solution do not have the issues which I outlined.

But these solutions may have issues that you haven't outlined:) Different approaches have their different target scenarios. That's the reason why both Layer2 and Layer3 overlays are considered by the NVo3 WG.

> >No matter you like it or now, the approach of using the host routing
> >and the Proxy ARP to emulate an extended subnet has been increasingly
> WH> this doesn’t mean that IETF need to adopt it, since it breaks a
> WH> number
> of things

You'd better explicit list those things which would be broken. It would be very helpful for the NVo3 WG.

> >> >> Since each PE acts as a default GW, there is no impact to the
> >> >>output of the trace  route for an IP address which is not within
> >> >>the same subnet as the trace-route  originator (IMO, this is the
> >> >>major usage of trace route).
> >> >>within the same  subnet of the trace-route originator, there are
> >> >>just two more hops (i.e., ingress  PE and egress PE) in the output
> >> >>(see below), does it matter in practice?
> >> >>
> >> >> <Host_1>tracert 1.1.1.5
> >> >It's no more a surprise once you have understood that the
> >> >intra-subnet traffic is forwarded at L3.
> >> >
> >> >rather than the PING command on one host to check the connectivity
> >> >to another host when these two hosts are actually within the same subnet?
> >> >
> >> >
> >> >> >> >> >> >> You are changing the forwarding plane of a L3 service
> >> >> >> >> >> >>and as such this is not  implementable in merchant
> >> >> >> >> >> >>silicon so
> >>far.
> >> >> >> >> >> >>You need a flexible network processor  to do this and I
> >> >> >> >> >> >>am not sure about the performance implications.
> >> >> >> >> >> >
> >> >> >> >> >> >TTL handling requirement as long as Layer3 forwarding
> >> >> >> >> >> >for intra-subnet traffic is worthwhile in practice. In
> >> >> >> >> >> >addition, even with the existing L3 forwarding chips
> >> >> >> >> >> >which don't support that TTL handling requirement, the
> >> >> >> >> >> WH> even with what you say you break basic applications
> >> >> >> >> >> WH> like trace route,
> >> >> >> >> >
> >> >> >> >> >No, it will not break the trace-route application. It has
> >> >> >> >> >been successfully verified in our implementation.
> >> >> >> >> WH> can you show an output. W/o the TTL handling your hops
> >> >> >> >> WH> will be
> >> >> >> >> incorrect
> >> >> >> >
> >> >> >> >
> >> >> >> >route output on Host A is as follows (note that 2.2.2.1 is a
> >> >> >> >vrf interface address of PE-3):
> >> >> >> >
> >> >> >> >[Host_1]tracert 2.2.2.1
> >> >> >Since each PE acts as a default GW, there is no impact to the
> >> >> >output of the trace route for an IP address which is not within
> >> >> >the same subnet as the trace-route originator (IMO, this is the
> >> >> >major usage of trace
> >> >>route).
> >> >> >within the same subnet of the trace-route originator, there are
> >> >> >just two more hops (i.e., ingress PE and egress PE) in the output
> >> >> >(see below), does it matter in practice?
> >> >> >
> >> >> ><Host_1>tracert 1.1.1.5
> >> >> >> >> >> etc. SO I don’t want to adopt it at all with such impact
> >> >> >> >> >> on the
> >> >> >>DP.
> >> >> >> >> >> >
> >> >> >> >> >> >Does EVPN have no impact on the data-plane? Are you
> >> >> >> >> >> >against that draft as well due to its impact on the data plane?
> >> >> >> >   broadcast, unknown unicast, or multicast (BUM) packet to
> >> >> >> > one of
> >> >>the
> >> >> >> >   in All-Active multi-homing mode using the "Ethernet A-D
> >> >> >> > route per
> >> >> >>
> >> >> >> >> >> >> The fundamental difference between the proposals is
> >> >> >> >> >> >>that you have on egress a  mapping in the label that
> >> >> >> >> >> >>determines the forwarding behaviour to be applied,
> >> >> >> >> >> >>rather than having to check src/dst IP matches + LPM lookups.
> >> >> >> >> >> >
> >> >> >> >> >If you are talking about the Virtual Subnet draft, then
> >> >> >> >> >your above argument is incorrect. The egress PE would
> >> >> >> >> >perform IP lookup in the corresponding VRF table.
> >> >> >> >> WH> I am talking about the fact when proper TTL handling has
> >> >> >> >> WH> to be
> >> >> >> >> applied, you need to determine whether or not to decrement
> >> >> >> >>the TTL and as  such you end up doing additional lookups to
> >>determine
> >> this.
> >> >> >> >Have you seen performance degradation on your routers once an
> >> >> >> >ACL entry or uRPF check is enabled on interfaces?
> >> >> >>
> >> >> >> WH> urpf/ACL are handled naturally, but you create a new
> >> >> >> WH> pipeline and look
> >> >> >> at the operations you have to do to check the
> >> >> >>intra/inter-subnet forwarding.
> >> >> >> >> >> >> >Fine. In my draft, both intra-subnet and inter-subnet
> >> >> >> >> >> >> >IP traffic are forwarded at layer3 while in the draft
> >> >> >> >> >> >> >you mentioned below only inter-subnet traffic would
> >> >> >> >> >> >> >be forwarded at layer3. They are totally different
> >> >> >> >> >> >> >approaches and therefore it's meaningless to say
> >> >> >> >> >> >> >which one is easier
> >> >>or not.
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >Xiaohu
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> -----邮件原件-----
> >> >> >> >> >> >> >> >> >> It is not about TTL 1, no TTL decrement
> >> >> >> >> >> >> >> >> >>should happen for intra-subnet  forwarding at
> >> >> >> >> >> >> >> >> >>all On top you need to modify the data-plane
> >> >> >> >> >> >> >> >> >>to achieve this, since it now needs to find
> >> >> >> >> >> >> >> >> >>out if it is intra or inter subnet where
> >> >> >> >> >> >> >> >> >>current
> >> >> >> >> >> >> >> >> >>PE(s)  don’t have to do
> >> >> >> >> >> >> >>this.
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> >Sure, it needs some change to the
> >> >> >> >> >> >> >> >> >implementation of PE
> >> >> >> >> >>routers.
> >> >> >> >> >> >> >> >> >> >It said clearly "if the source and
> >> >> >> >> >> >> >> >> >> >destination addresses of a packet whose TTL
> >> >> >> >> >> >> >> >> >> >is set to 1 belong to the same extended
> >> >> >> >> >> >> >> >> >> >subnet, both ingress and egress PE routers
> >> >> >> >> >> >> >> >> >> >MUST NOT decrement the TTL of
> >> >>such
> >> >> packet."
> >> >> >> >> >> >> >> >> >> >>We can say don’t  decrement but when and
> >> >> >> >> >> >> >> >> >> >>how will the
> >> >> >> >> >> >> >> >> >> >>PE(s) do or
> >> >> >> >> >> >> >> >>don’t.
> >> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> >> >Any further comments are welcome. BTW,
> >> >> >> >> >> >> >> >> >> >> >the removed sections as mentioned above
> >> >> >> >> >> >> >> >> >> >> >would be described in
> >> >> >> >> >>separate
> >> >> >> >> >> docs.
> >> >> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> >> >> >Best regards, Xiaohu
> >> >> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> >> >> >> -----邮件原件-----
> >> >> >> >> >> >> >> >> >> >> >> has been successfully submitted by
> >> >> >> >> >> >> >> >> >> >> >>Xiaohu Xu and posted to the IETF repository.
> >> >> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> >> >>    can be used as a kind of Layer3
> >> >> >> >> >> >> >> >> >> >> >> network virtualization
> >> >> >> >> >> >> >> >>overlay
> >> >> >> >> >> >> >> >> >> >> >> Please note that it may take a couple
> >> >> >> >> >> >> >> >> >> >> >>of minutes from the time of submission
> >> >> >> >> >> >> >> >> >> >> >>until the htmlized version and diff are
> >> >> >> >> >> >> >> >> >> >> >>available at
> >> >>tools.ietf.org.
> >> >> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> >> >> The IETF Secretariat
> >> >> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >
> >> >> >
> >> >
> >