> -----邮件原件----- > 发件人: 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 > >> >> >> >> >> >> >> >> >> >> > > >> >> >> >> >> >> >> >> >> > > >> >> >> >> >> >> >> >> > > >> >> >> >> >> >> >> > > >> >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> > > >> >> >> > > >> >> > > >> > > >
