Hi everyone, Please try to keep your email Subject line tidy enough !
(You could even go as far as selecting a useful topic line) Thank you. -Thomas, as WG co-chair 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.
