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.
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. >
