Pedro, I am not saying proxy ARP is not valid, but what I am telling that a lot of applications break in such environment. The applications that rely on this are reality and we should not break them.
On 03/12/13 09:55, "Pedro Roque Marques" <[email protected]> wrote: >Wim, > >On Dec 2, 2013, at 6:18 AM, Henderickx, Wim (Wim) ><[email protected]> wrote: > >> Thomas, there is more applications that break when this solution is >> deployed. HA systems e.g. My view is that the draft break a fundamental >>IP >> behaviour it should not be adopted at all. > >Is the fundamental IP behavior that you are referring to the TTL >decrement between two addresses on the same "subnet" ? >I believe you are wrong: to my knowledge proxy ARP is compliant with Host >and Router requirement RFCs. > >It is very hard for an application to use anything other than an IP >service. First because it is difficult to code, second because some of >the most popular platforms to deploy applications (e.g. AWS) do not >support anything other than an IP service. > >There may be environments where people feel the need to emulate a >specific L2 technology; but applications that depend on L2 are always >going to be in world of hurt since there are actually different L2 >technologies in use. For instance a switched ethernet is different than a >E-VPN based ethernet that does control plane based learning (i.e. unknown >unicast is not forwarded); and the behavior is different from a hub based >ethernet where all traffic is broadcasted. > > Pedro. > >> >> On 02/12/13 12:39, "[email protected]" <[email protected]> >> wrote: >> >>> Hi everyone, >>> >>> I believe we may benefit from taking a step back. Let's not only look >>>at >>> TTL and traceroute (see my comment below on traceroute itself), and >>> let's also try to distinguish between discussions that are useful to >>> have here and discussions that may be more useful elsewhere. >>> >>> First of all, it is obvious that this draft does not claim, nor >>> achieves, an exact emulation of L2 connectivity. Even though TTL >>> decrementing could be avoided (perhaps with a cost penalty on some >>> platforms), other things will also happen differently from how things >>> happen on a LAN: source MAC addresses will not be preserved, the >>> possibility of addressing any IP packet to any host on the (emulated >>> LAN) acting as a gateway, the possibility of doing broadcast and >>> link-local multicast (that one would possibly be fixable), any dot-1p >>> marking will be lost, and of course the possibility of using non-IP >>> protocols. This may break some applications. But, to me this does not >>> rule out such a solution, as soon as the limitations are understood and >>> the solution is used in context where they do not raise issues. >>> >>> Second, let's see what we need to discuss here in l3vpn. Wim, you are >>> saying "this is not in-line with NVO3 requirements.". To me, it seems >>> that this solution deserves to be described, if only as a input for >>> documenting in detail what will happen differently than from a LAN and >>> specific cases of applications that will behave differently, or break, >>> if this is used. >>> >>> -Thomas >>> >>> [ On traceroute, I would actually argue -- keeping in mind that >>> traceroute is a troubleshooting tool -- that in the context of this >>> approach, the output of traceroute will actually provide more >>> information useful for troubleshooting, than what we would have with a >>> bit-for-bit emulation of L2. Than can be seen as a benefit as well. If >>> we make a //, although a l3vpn is supposed to behave, from the VPN >>> customer point of view, like one router -- traceroute can actually >>> provide some information on what happens between the PEs -- AFAIK this >>> has never been considered like "breaking traceroute". ] >>> >>> >>> >>> 2013-11-29, Henderickx, Wim (Wim): >>>>> You violate basic forwarding mechanisms: don’t decrement TTL for >>>>> intra-subnet traffic and this is not in-line with NVO3 requirements. >>>>> Discussion closed for me. >>>>> >>>>> On 29/11/13 10:03, "Xuxiaohu" <[email protected]> wrote: >>>>> >>>>>> >>>>>>> -----邮件原件----- >>>>>>> 发件人: Henderickx, Wim (Wim) >>>>>>>[mailto:[email protected]] >>>>>>> 发送时间: 2013年11月29日 15:55 >>>>>>> 收件人: Xuxiaohu; [email protected] >>>>>>> 抄送: [email protected] >>>>>>> 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: >>>>>>> New Version Notification for draft-xu-l3vpn-virtual-subnet-02.txt >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 29/11/13 07:56, "Xuxiaohu" <[email protected]> wrote: >>>>>>> >>>>>>>> >>>>>>>>> -----邮件原件----- >>>>>>>>> 发件人: Henderickx, Wim (Wim) >>>>>>> [mailto:[email protected]] >>>>>>>>> 发送时间: 2013年11月29日 12:59 >>>>>>>>> 收件人: Xuxiaohu; [email protected] >>>>>>>>> 抄送: [email protected] >>>>>>>>> 主题: 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 >>>>>>> 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. >>>>>> >>>>>>>>> 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 >>>>>>> WH> number >>>>>>> of things >>>>>> You'd better explicit list those things which would be broken. It >>>>>> would >>>>>> be very helpful for the NVo3 WG. >>>>>> >>>>>>>> Xiaohu >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 29/11/13 02:35, "Xuxiaohu" <[email protected]> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----邮件原件----- >>>>>>>>>>> 发件人: Henderickx, Wim (Wim) >>>>>>>>> [mailto:[email protected]] >>>>>>>>>>> 发送时间: 2013年11月28日 18:46 >>>>>>>>>>> 收件人: Xuxiaohu; [email protected] >>>>>>>>>>> 抄送: [email protected] >>>>>>>>>>> 主题: 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 protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----邮件原件----- >>>>>>>>>>>>> 发件人: Henderickx, Wim (Wim) >>>>>>>>>>> [mailto:[email protected]] >>>>>>>>>>>>> 发送时间: 2013年11月28日 15:44 >>>>>>>>>>>>> 收件人: Xuxiaohu; [email protected] >>>>>>>>>>>>> 抄送: [email protected] >>>>>>>>>>>>> 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: New Version >>>>>>>>>>> Notification for >>>>>>>>>>>>> draft-xu-l3vpn-virtual-subnet-02.txt >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 28/11/13 08:33, "Xuxiaohu" <[email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----邮件原件----- >>>>>>>>>>>>>>> 发件人: Henderickx, Wim (Wim) >>>>>>>>>>>>> [mailto:[email protected]] >>>>>>>>>>>>>>> 发送时间: 2013年11月28日 14:13 >>>>>>>>>>>>>>> 收件人: Xuxiaohu; [email protected] >>>>>>>>>>>>>>> 抄送: [email protected] >>>>>>>>>>>>>>> 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: New Version >>>>>>>>>>> Notification >>>>>>>>>>>>> for >>>>>>>>>>>>>>> draft-xu-l3vpn-virtual-subnet-02.txt >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 28/11/13 04:02, "Xuxiaohu" <[email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -----邮件原件----- >>>>>>>>>>>>>>>>> 发件人: Henderickx, Wim (Wim) >>>>>>>>>>>>>>> [mailto:[email protected]] >>>>>>>>>>>>>>>>> 发送时间: 2013年11月28日 1:53 >>>>>>>>>>>>>>>>> 收件人: Xuxiaohu; [email protected] >>>>>>>>>>>>>>>>> 抄送: [email protected] >>>>>>>>>>>>>>>>> 主题: Re: 答复: 答复: 答复: 答复: 答复: New Version >>>>>>>>> Notification >>>>>>>>>>> for >>>>>>>>>>>>>>>>> draft-xu-l3vpn-virtual-subnet-02.txt >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 27/11/13 09:12, "Xuxiaohu" <[email protected]> >>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -----邮件原件----- >>>>>>>>>>>>>>>>>>> 发件人: Henderickx, Wim (Wim) >>>>>>>>>>>>>>>>> [mailto:[email protected]] >>>>>>>>>>>>>>>>>>> 发送时间: 2013年11月27日 14:14 >>>>>>>>>>>>>>>>>>> 收件人: Xuxiaohu; [email protected] >>>>>>>>>>>>>>>>>>> 抄送: [email protected] >>>>>>>>>>>>>>>>>>> 主题: 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 >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>> WH> pipeline 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 protected]> >>>>>>>>> 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 protected]] >>>>>>>>>>>>>>>>>>>>> 发送时间: 2013年11月25日 19:16 >>>>>>>>>>>>>>>>>>>>> 收件人: Xuxiaohu; [email protected] >>>>>>>>>>>>>>>>>>>>> 抄送: [email protected] >>>>>>>>>>>>>>>>>>>>> 主题: 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 protected]> >>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>> I suggest you read the following blog post by >>>>>>>>>>>>>>>>>>>>>> Yakov >>>>>>>>>>>> (http://opencontrail.org/why-contrail-is-using-bgpmpls/). >>>>>>>>>>>>>>>>>>>>>>> -----邮件原件----- >>>>>>>>>>>>>>>>>>>>>>> 发件人: Henderickx, Wim (Wim) >>>>>>>>>>>>>>>>>>>>> [mailto:[email protected]] >>>>>>>>>>>>>>>>>>>>>>> 发送时间: 2013年11月25日 15:27 >>>>>>>>>>>>>>>>>>>>>>> 收件人: Xuxiaohu; [email protected] >>>>>>>>>>>>>>>>>>>>>>> 抄送: [email protected] >>>>>>>>>>>>>>>>>>>>>>> 主题: 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-e >>>>>>>>>>>>>>>>>>>>>>> vpn >>>>>>>>>>>>>>>>>>>>>>> -in >>>>>>>>>>>>>>>>>>>>>>> ter >>>>>>>>>>>>>>>>>>>>>>> -su >>>>>>>>>>>>>>>>>>>>>>> bne >>>>>>>>>>>>>>>>>>>>>>> t-f >>>>>>>>>>>>>>>>>>>>>>> orw >>>>>>>>>>>>>>>>>>>>>>> ard >>>>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>> g-02 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 25/11/13 07:40, "Xuxiaohu" >>>>>>>>>>>>>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> -----邮件原件----- >>>>>>>>>>>>>>>>>>>>>>>>> 发件人: Henderickx, Wim (Wim) >>>>>>>>>>>>>>>>>>>>>>> [mailto:[email protected]] >>>>>>>>>>>>>>>>>>>>>>>>> 发送时间: 2013年11月25日 14:29 >>>>>>>>>>>>>>>>>>>>>>>>> 收件人: Xuxiaohu; [email protected] >>>>>>>>>>>>>>>>>>>>>>>>> 抄送: >>>>>>>>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>>>>>>> 主题: 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 protected]> >>>>>>>>>>>>>>> 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 protected]] >>>>>>>>>>>>>>>>>>>>>>>>>>> 发送时间: 2013年11月25日 14:08 >>>>>>>>>>>>>>>>>>>>>>>>>>> 收件人: Xuxiaohu; [email protected] >>>>>>>>>>>>>>>>>>>>>>>>>>> 抄送: >>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>>>>>>>>> g >>>>>>>>>>>>>>>>>>>>>>>>>>> 主题: 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 protected]> >>>>>>>>>>>>>>>>> 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 protected] >>>>>>>>>>>>>>>>>>>>>>>>>>>>> [mailto:[email protected]] >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 发送时间: 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-x >>>>>>>>>>>>>>>>>>>>>>>>>>> u-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-l3vp >>>>>>>>>>>>>>>>>>>>>>>>>>>>> n-v >>>>>>>>>>>>>>>>>>>>>>>>>>>>> irt >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ual >>>>>>>>>>>>>>>>>>>>>>>>>>>>> -su >>>>>>>>>>>>>>>>>>>>>>>>>>>>> bne >>>>>>>>>>>>>>>>>>>>>>>>>>>>> t-0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Diff: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-x >>>>>>>>>>>>>>>>>>>>>>>>>>>>> u-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 >>>> >>> >>> >>>________________________________________________________________________ >>>__ >>> _______________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>> recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>>messages >>> electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, deforme >>> ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileged >>> information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and >>> delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have >>> been modified, changed or falsified. >>> Thank you. >>> >> >
