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

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Wed, 27 Nov 2013 17:53:19 +0000

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 route,
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
>
>> 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
>
>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-subnet-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-virtual-su
>> >> >> >> >>bne
>> >> >> >> >>t-0
>> >> >> >> >>2.t
>> >> >> >> >>xt
>> >> >> >> >> >> Status:
>> >> >> >> >> >>http://datatracker.ietf.org/doc/draft-xu-l3vpn-virtual-sub
>> >> >> >> >> >>net
>> >> >> >> >> >> Htmlized:
>> >> >> >> >> >>http://tools.ietf.org/html/draft-xu-l3vpn-virtual-subnet-0
>> >> >> >> >> >>2
>> >> >> >> >> >> Diff:
>> >> >> >> >> >>
>> >> >> >> >> >>http://www.ietf.org/rfcdiff?url2=draft-xu-l3vpn-virtual-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 03:02:33 +0000

> 发送时间: 2013年11月28日 1:53
> 主题: Re: 答复: 答复: 答复: 答复: 答复: New Version Notification for
> >> 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.
> >
> >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. 

> >Does EVPN have no impact on the data-plane? Are you against that draft
> >as well due to its impact on the data plane?

However, the major selling-point of that technology (i.e., active-active multi-homing) is lost in its basic form accordingly.

> >>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.
> >

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.

Xiaohu

> >> >different approaches and therefore it's meaningless to say which one
> >> >is easier or not.
> >> >
> >> >Xiaohu
> >> >
> >> >> -----邮件原件-----
> >> >> >> There are easier ways to do this which don’t required
> >> >> >>data-plane changes.
> >> >> >>
> >> >> >> >>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
> >> >> >> >> >
> >> >> >> >> >> -----邮件原件-----
> >> >> >> >> >>We can say don’t  decrement but when and how will the
> >> >> >> >> >>PE(s) do or
> >> >> >>don’t.
> >> >> >> >> >>
> >> >> >> >> >> >Any further comments are welcome. BTW, the removed
> >> >> >> >> >> >sections as mentioned above would be described in separate
> docs.
> >> >> >> >> >> >
> >> >> >> >> >> >Best regards,
> >> >> >> >> >> >Xiaohu
> >> >> >> >> >> >
> >> >> >> >> >> >> -----邮件原件-----
> >> >> >> >> >> >> has been successfully submitted by Xiaohu Xu and
> >> >> >> >> >> >>posted to the IETF repository.
> >> >> >> >> >> >>
> >> >> >> >> >> >>    based subnet extension solution referred to as
> >> >> >> >> >> >> Virtual Subnet,
> >> >> >> >> >>which
> >> >> >> >> >> >> 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 03:12:59 +0000

> WH> not in its basic form

By the way, does that mean you are only in favor of its basic form but against its non-basic form?:)

Xiaohu