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 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 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 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 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-evpn >> >> >> >> >> >> >> >>-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] >> >> >> >> >> >> >> >> >> >> 主题: 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-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 >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> > >
