Subject: Re: [nvo3] Response to some comments on IS-IS VPLS

From: Xuxiaohu <[email-masked]>
Date: Fri, 6 Apr 2012 07:08:56 +0000

Hi Ali，

I suggest you reading the latest version of IS-IS VPLS draft (http://tools.ietf.org/html/draft-xu-l2vpn-vpls-isis-03) , especially the first section which describes the requirements in details. I believe you could find the answer to your question and also find the obvious differences between IS-IS VPLS and your MVPLS once you have finished reading that draft.

Of course, if the WG consensus is to separate the requirements as an independent draft, I could do that.

By the way, since you mentioned the requirement/framework draft for nov3 solutions, you may have noticed that one of the control plane requirements described in the requirement draft is "Do not rely on IP Multicast in the Underlying Network " (See the section of Control Plane Characteristics), and you may have also noticed section 4.2.3."Handling Broadcast, Unknown Unicast and Multicast (BUM) traffic" of the framework draft, which explicitly said "Depending upon the size of the data center network and hence the number of (S,G) entries, but also the duration of multicast flows, the use of core multicast trees can be a challenge ". Hence I wonder whether you have any different opinions in this regard. If no, based on the abstract of your MVPLS draft shown as follows, I think you would also agree that MVPLS is not a suitable candidate solution for data center networks.

******************************************************************
            Abstract 
             
            Virtual Private LAN Service (VPLS) is a type of Layer-2 Provider 
            Provisioned Virtual Private Network (L2 PPVPN) offered service, which 
            has been described in [PPVPN-FRWK]. If the Service Provider network 
            provides IP multicast functionality, then this network capability can 
            be leveraged in providing very efficient VPLS service and yet 
            simplifying the implementation of such service. This document describes 
            a solution for providing VPLS service based on IP multicast feature 
            referred to as Multicast Virtual Private LAN Service (MVPLS).
*******************************************************************

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: sajassi [mailto:[email-masked]]
> 发送时间: 2012年4月6日 13:08
> 收件人: Xuxiaohu; [email-masked]; John E Drake
> 抄送: [email-masked]; UTTARO, JAMES
> 主题: Re: Response to some comments on IS-IS VPLS
> 
> Hi Xuxiaohu,
> 
> I think when we talk about a given solution, we should also talk about the
> framework and the requirements for which the solution is intended for. There
> is a requirement draft for EVPN/PBB-EVPN solution and there is also a
> requirement/framework draft for nov3 solutions. Frankly, between these two
> sets of framework and their corresponding solutions, I think we are covering
> host-based v.s. network-based,  intraDC v.s. InterDC, as well as different
> kinds of DCs. If you think, there is an area that it is not covered by these
> two sets, then you should start from there and articulate those
> requirements.
> 
> Cheers,
> Ali
> 
> 
> On 4/4/12 8:20 PM, "Xuxiaohu" <[email-masked]> wrote:
> 
> >
> >> -----邮件原件-----
> >> 发件人: sajassi [mailto:[email-masked]]
> >> 发送时间: 2012年4月3日 0:34
> >> 收件人: Xuxiaohu; [email-masked]; John E Drake
> >> 抄送: [email-masked]; UTTARO, JAMES
> >> 主题: Re: Response to some comments on IS-IS VPLS
> >>
> >> Hi Xuxiaohu,
> >>
> >> The draft that I wrote ten years ago (MVPLS) is analogous to VXLAN - both
> do
> >> the same thing but with different IP encap. MVPLS used L2TPv3 encap (since
> >> it was the encap-dejour of that time for IP :-); whereas, VXLAN uses UDP
> >> encap.
> >>
> >> Since there are already three different encap proposals in NVo3 (UDP, GRE,
> >> and TCP), I am NOT planning to introduce yet another encap by resurrecting
> >> my draft. I think we should only pick a single encap among the three current
> >> proposals in NVO3.
> >
> > Hi Ali,
> >
> > Does that mean you also believe a simplified L2VPN approach other than
> EVPN is
> > needed for data center networks? Otherwise why do you suggest picking one
> > rather than dropping them all?
> >
> > Best regards,
> > Xiaohu
> >
> >>
> >> Cheers,
> >> Ali
> >>
> >>
> >> On 3/30/12 1:55 AM, "Xuxiaohu" <[email-masked]> wrote:
> >>
> >>> Hi Ali,
> >>>
> >>> What's your attitude to your own draft as mentioned below from today's
> >> point
> >>> of view? good or bad?
> >>>
> >>> Best regards,
> >>> Xiaohu
> >>>
> >>> ________________________________________
> >>> 发件人: [email-masked] [[email-masked]] 代表 sajassi
> >>> [[email-masked]]
> >>> 发送时间: 2012年3月30日 16:43
> >>> 到: [email-masked]; John E Drake
> >>> Cc: [email-masked]; UTTARO, JAMES
> >>> 主题: Re: Response to some comments on IS-IS VPLS
> >>>
> >>> Hi Robert,
> >>>
> >>> I won't get into the argument of whether this kind of solution is innovation
> >>> or permutation. My point is that it is clearly outside of current L2VPN
> >>> charter and if this kind of solution is to be pursued in L2VPN WG, then it
> >>> needs to be re-chartered.
> >>>
> >>> Also, if we are talking about VPLS service over IP and doing MAC learning
> >>> against IP addresses (as what this draft is talking about), I had a draft 10
> >>> years ago that cover this subject !!
> >>>
> >>> http://tools.ietf.org/id/draft-sajassi-mvpls-00.txt
> >>>
> >>> Cheers,
> >>> Ali
> >>>
> >>>
> >>> On 3/29/12 2:33 PM, "Robert Raszuk" <[email-masked]> wrote:
> >>>
> >>>> Hi John,
> >>>>
> >>>> I think you took it a little bit too far.
> >>>>
> >>>> I have not heard anyone stating that current VPLS solutions suck. I also
> >>>> did not hear anyone claiming that BGP is difficult. The claim I have
> >>>> heard is that in some environments one may not like to use BGP for VPLS.
> >>>>
> >>>> Ali's point is that current PEs will have problem supporting it as this
> >>>> is effectively TRILL over IP is valid from Ali's point of view.
> >>>>
> >>>> However one could ask a question if IETF is still an organization to
> >>>> promote open innovation and consider new ideas (even if only in
> >>>> experimental mode) or is it just a forum to lock customers to limited
> >>>> set of solutions ? If it is the latter the trend to seek alternatives to
> >>>> IETF standardization process will continue to evolve. Especially now
> >>>> when control plane separation from data plane becomes reality.
> >>>>
> >>>> I see nothing wrong to allocate perhaps in experimental mode VPLS Info
> >>>> TLV codepoint for VPLS over ISIS or for that matter well known
> >>>> destination port for STT from IANA and let companies who are asking for
> >>>> it develop the solutions, deploy it then report back the results to the
> >>>> community.
> >>>>
> >>>> Best,
> >>>> R.
> >>>>
> >>>>
> >>>>> Jim,
> >>>>>
> >>>>> You are completely correct , but let¹s not overlook the fun factor.
> >>>>> I.e., it¹s **fun** to say that everything that has gone before sucks and
> >>>>> that the current initiative will be ³practically perfect² (c.f. ŒMary
> >>>>> Poppins¹).
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> John
> >>>>>
> >>>>> Sent from my iPhone
> >>>>>
> >>>>> *From:[email-masked] [mailto:[email-masked]] *On
> >> Behalf
> >>>>> Of *UTTARO, JAMES
> >>>>> *Sent:* Thursday, March 29, 2012 11:30 AM
> >>>>> *To:* 'Xuxiaohu'; [email-masked]
> >>>>> *Subject:* RE: Response to some comments on IS-IS VPLS
> >>>>>
> >>>>> IMHOŠ I am at a bit of a loss as to the notion that BGP is so
> >>>>> overwhelmingly difficult to deal with in a data center environment.. Why
> >>>>> is that?? BGP is being used across a wide spectrum of applications and
> >>>>> is proven. I believe that the data center is becoming more and more a
> >>>>> dynamic extension of a customer¹s network. I also think it would be
> wise
> >>>>> to anticipate the world of tomorrow where customers may expect their
> >>>>> network may span multiple operators DCs. The right approach is to
> >>>>> leverage what has been done BGP and extend it where needed.. This
> >>>>> provides maximum flexibility and simplicity..
> >>>>>
> >>>>> To build solutions based on the notion that ³I don¹t like protocol X² is
> >>>>> invalid..
> >>>>>
> >>>>> Jim Uttaro
> >>>>>
> >>>>> *From:[email-masked] <mailto:[email-masked]>
> >>>>> [mailto:[email-masked]] *On Behalf Of *Xuxiaohu
> >>>>> *Sent:* Thursday, March 29, 2012 2:59 PM
> >>>>> *To:* [email-masked] <mailto:[email-masked]>
> >>>>> *Subject:* Response to some comments on IS-IS VPLS
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> VPLS (Virtual Private LAN Service) has different understandings for
> >>>>> different people, some people think it as a service while others think
> >>>>> it as a concrete technology, especially using PWs. Here, the "VPLS" is
> >>>>> deemed as a VPLS service. If the WG consensus is that "VPLS" should be
> >>>>> taken as a concrete technology, I have no objection to using another
> term.
> >>>>>
> >>>>> As said in the IS-IS VPLS draft, IS-IS VPLS is intended to be a
> >>>>> light-weight VPLS solution which can meet some DC operators'
> >>>>> requirements for simplicity. I don't want to argue in this mailing-list
> >>>>> whether BGP-based L2VPN solutions could meet well the requirements
> >> from
> >>>>> all DC operators. I personally believe that it would be better to ask
> >>>>> this question to NVo3. In addition, according to today's presentation of
> >>>>> E-VPN, I think E-VPN co-authors also admit that the exiting EVPN
> >>>>> solution seems complex to some DC operators. If my understanding is
> >>>>> wrong, pls correct me.
> >>>>>
> >>>>> If I remembered correctly, L1VPN also has two RFCs using IS-IS and OSPF
> >>>>> for L1VPN auto-discovery, although there has been one solution using
> >>>>> BGP. Hence I don't know why can't we have a light-weight L2VPN using
> >> IS-IS.
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Xiaohu
> >>>>>
> >>>>
> >

---

From: sajassi <[email-masked]>
Date: Fri, 06 Apr 2012 09:56:35 -0700

Hi Xuxiaohu,

In my previous email, I said " If you think, there is an area that it is not
covered by these two sets, then you should start from there and articulate
those requirements".

The requirements that you have listed in your draft are "mother-hood and
apple-pie" which are covered by other drafts. If there are any new
requirements above and beyond the ones captured by e-vpn requirements and
nov3 requirements/framework, then you should articulate what those
requirements are.

As, I mentioned before, your proposal is clearly outside of L2VPN charter
but it may fit within NOV3 charter. If you are going to take it there, then
you need to articulate what are the benefits of this proposal over the
existing ones.

Cheers,
Ali

On 4/6/12 12:08 AM, "Xuxiaohu" <[email-masked]> wrote:

> Hi Ali，
> 
> I suggest you reading the latest version of IS-IS VPLS draft
> (http://tools.ietf.org/html/draft-xu-l2vpn-vpls-isis-03) , especially the
> first section which describes the requirements in details. I believe you could
> find the answer to your question and also find the obvious differences between
> IS-IS VPLS and your MVPLS once you have finished reading that draft.
> 
> By the way, since you mentioned the requirement/framework draft for nov3
> solutions, you may have noticed that one of the control plane requirements
> described in the requirement draft is "Do not rely on IP Multicast in the
> Underlying Network " (See the section of Control Plane Characteristics), and
> you may have also noticed section 4.2.3."Handling Broadcast, Unknown Unicast
> and Multicast (BUM) traffic" of the framework draft, which explicitly said
> "Depending upon the size of the data center network and hence the number of
> (S,G) entries, but also the duration of multicast flows, the use of core
> multicast trees can be a challenge ". Hence I wonder whether you have any
> different opinions in this regard. If no, based on the abstract of your MVPLS
> draft shown as follows, I think you would also agree that MVPLS is not a
> suitable candidate solution for data center networks.
>