Subject: Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: New Version Notification for draft-xu-l3vpn-virtual-subnet-02.txt

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 28 Nov 2013 07:44:23 +0000

On 28/11/13 08:33, "Xuxiaohu" <[email-masked]> wrote:

>
>
>> -----邮件原件-----
>> 发件人: Henderickx, Wim (Wim) [mailto:[email-masked]]
>> 发送时间: 2013年11月28日 14:13
>> 收件人: Xuxiaohu; [email-masked]
>> 抄送: [email-masked]
>> 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: New Version Notification for
>> draft-xu-l3vpn-virtual-subnet-02.txt
>> 
>> 
>> 
>> On 28/11/13 04:02, "Xuxiaohu" <[email-masked]> wrote:
>> 
>> >
>> >
>> >> -----邮件原件-----
>> >> 发件人: Henderickx, Wim (Wim)
>> [mailto:[email-masked]]
>> >> 发送时间: 2013年11月28日 1:53
>> >> 收件人: Xuxiaohu; [email-masked]
>> >> 抄送: [email-masked]
>> >> 主题: Re: 答复: 答复: 答复: 答复: 答复: New Version Notification for
>> >> draft-xu-l3vpn-virtual-subnet-02.txt
>> >>
>> >>
>> >>
>> >> On 27/11/13 09:12, "Xuxiaohu" <[email-masked]> wrote:
>> >>
>> >> >
>> >> >
>> >> >> -----邮件原件-----
>> >> >> 发件人: Henderickx, Wim (Wim)
>> >> [mailto:[email-masked]]
>> >> >> 发送时间: 2013年11月27日 14:14
>> >> >> 收件人: Xuxiaohu; [email-masked]
>> >> >> 抄送: [email-masked]
>> >> >> 主题: 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-masked]> 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-masked]]
>> >> >> >> 发送时间: 2013年11月25日 19:16
>> >> >> >> 收件人: Xuxiaohu; [email-masked]
>> >> >> >> 抄送: [email-masked]
>> >> >> >> 主题: 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-masked]> wrote:
>> >> >> >>
>> >> >> >> >I suggest you read the following blog post by Yakov
>> >> >> >> >(http://opencontrail.org/why-contrail-is-using-bgpmpls/).
>> >> >> >> >
>> >> >> >> >> -----邮件原件-----
>> >> >> >> >> 发件人: Henderickx, Wim (Wim)
>> >> >> >> [mailto:[email-masked]]
>> >> >> >> >> 发送时间: 2013年11月25日 15:27
>> >> >> >> >> 收件人: Xuxiaohu; [email-masked]
>> >> >> >> >> 抄送: [email-masked]
>> >> >> >> >> 主题: 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-masked]> wrote:
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >> -----邮件原件-----
>> >> >> >> >> >> 发件人: Henderickx, Wim (Wim)
>> >> >> >> >> [mailto:[email-masked]]
>> >> >> >> >> >> 发送时间: 2013年11月25日 14:29
>> >> >> >> >> >> 收件人: Xuxiaohu; [email-masked]
>> >> >> >> >> >> 抄送: [email-masked]
>> >> >> >> >> >> 主题: 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-masked]>
>>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-masked]]
>> >> >> >> >> >> >> 发送时间: 2013年11月25日 14:08
>> >> >> >> >> >> >> 收件人: Xuxiaohu; [email-masked]
>> >> >> >> >> >> >> 抄送: [email-masked]
>> >> >> >> >> >> >> 主题: 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-masked]>
>> >>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-masked]
>> >> >> >> >> >> >> >>[mailto:[email-masked]]
>> >> >> >> >> >> >> >> 发送时间: 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
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >
>> >> >> >
>> >> >
>> >
>

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 28 Nov 2013 08:45:26 +0000

> 发送时间: 2013年11月28日 15:44
> 主题: 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.
> >> >> >
> >> >> >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.
> >CTRL_C t o break

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>    

> >> >> >> So why I am against this draft is because it has a big impact
> >> >> >>on the data-plane.
> >> >> >
> WH> when you use virtual chassis all works naturally and split horizon
> WH> 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.
> >> >> >
> >> 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.
> >
> WH> urpf/ACL are handled naturally, but you create a new pipeline and
> WH> 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
> >> >> >
> >> >> >> >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
> >> >> >> >
> >> >> >> >> -----邮件原件-----
> >> >> >> >> >> >> 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.
> >> >> >> >> >> >
> >> >> >> >> >> >> >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
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> -----邮件原件-----
> >> >> >> >> >> >> >> >>    This document describes a Layer3 Virtual
> >> >> >> >> >> >> >> >> Private Network
> >> >> >> >> >> >>(L3VPN)-
> >> >> >> >> >> >> >> >>    based subnet extension solution referred to
> >> >> >> >> >> >> >> >> as Virtual Subnet,
> >> >> >> >> >> >> >>which