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 trace >> >> WH> 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 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 should be from a intra-subnet > > > >> >> 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 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 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 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-inter-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-l3vpn-virt >> >> >> >> >> >> >>ual >> >> >> >> >> >> >>-su >> >> >> >> >> >> >>bne >> >> >> >> >> >> >>t-0 >> >> >> >> >> >> >>2.t >> >> >> >> >> >> >>xt >> >> >> >> >> >> >> >> Status: >> >> >> >> >> >> >> >>http://datatracker.ietf.org/doc/draft-xu-l3vpn-virtu >> >> >> >> >> >> >> >>al- >> >> >> >> >> >> >> >>sub >> >> >> >> >> >> >> >>net >> >> >> >> >> >> >> >> Htmlized: >> >> >> >> >> >> >> >>http://tools.ietf.org/html/draft-xu-l3vpn-virtual-su >> >> >> >> >> >> >> >>bne >> >> >> >> >> >> >> >>t-0 >> >> >> >> >> >> >> >>2 >> >> >> >> >> >> >> >> Diff: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>http://www.ietf.org/rfcdiff?url2=draft-xu-l3vpn-virt >> >> >> >> >> >> >> >>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 >> >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> > >
