Subject: re: Interest in IS-IS VPLS

From: Xuxiaohu <[email-masked]>
Date: Wed, 2 May 2012 02:54:52 +0000

John,

I'm not wondering that you said that word since you had ever doubted and even scorned the motivation of NVo3 and now NVo3 WG is formed which may make you very raging.

Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 John E
> Drake
> 发送时间: 2012年5月1日 2:33
> 收件人: Linda Dunbar; Lucy yong; Mach Chen; Giles Heron; [email-masked]
> 主题: RE: Interest in IS-IS VPLS
> 
> How about DOA?  (Dead On Arrival)
> 
> Sent from my iPhone
> 
> 
> > -----Original Message-----
> > From: Linda Dunbar [mailto:[email-masked]]
> > Sent: Monday, April 30, 2012 11:02 AM
> > To: Lucy yong; John E Drake; Mach Chen; Giles Heron; [email-masked]
> > Subject: RE: Interest in IS-IS VPLS
> >
> > Agree with Lucy,  DC-VPN might be a better name.
> >
> > Linda
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On
> > Behalf
> > > Of Lucy yong
> > > Sent: Monday, April 30, 2012 10:39 AM
> > > To: John E Drake; Mach Chen; Giles Heron; [email-masked]
> > > Subject: RE: Interest in IS-IS VPLS
> > >
> > > John,
> > >
> > > IS-IS VPLS is completely different from TRILL and SPB although they
> > > all use of IS-IS protocol in control plane. IS-IS VPLS data plane
> > uses
> > > an IP/GRE tunnel carrying VPN instances differentiated by MPLS
> > labels.
> > > TRILL and SPB data planes are Ethernet based, i.e. the frames are
> > > Ethernet frames.
> > >
> > > Isn't it good that one control plane protocol can apply to different
> > > data planes?
> > >
> > > I agree that VPLS has been well defined and used in Service Provider
> > > networks. IS-IS VPLS provides the simplified version of VPLS that can
> > > apply to data center networks. This may be better than developing
> > > something completely new in data center.
> > >
> > > Maybe we need consider another name for this, for example DC-VPN? In
> > > data center, an VPN is not necessary to provide a service to an
> > > customer, the infrastructure need VPN capability.
> > >
> > > Regards,
> > > Lucy
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: John E Drake [mailto:[email-masked]]
> > > Sent: Monday, April 30, 2012 8:12 AM
> > > To: Mach Chen; Lucy yong; Giles Heron; [email-masked]
> > > Subject: RE: Interest in IS-IS VPLS
> > >
> > > We already have TRILL and SPB.  Why is yet another IS-IS variant
> > > necessary, particularly one that is so completely under-specified?
> > >
> > > Sent from my iPhone
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf
> > > > Of Mach Chen
> > > > Sent: Saturday, April 28, 2012 3:04 AM
> > > > To: Lucy yong; Giles Heron; [email-masked]
> > > > Subject: RE: Interest in IS-IS VPLS
> > > >
> > > > Fully agree with lucy here.
> > > >
> > > > In addition, since the ISIS VPLS leverages a uniform protocol(ISIS)
> > > for
> > > > signaling and auto discovery, it would greatly simplify the
> > > deployment
> > > > and maintenance, especially for the DC networks that have already
> > > > deployed ISIS for IP routing. So I'd like to see the draft moving
> > > > forward.
> > > >
> > > > Best regards,
> > > > Mach
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked] [mailto:[email-masked]] On
> > > > Behalf
> > > > > Of Lucy yong
> > > > > Sent: Saturday, April 28, 2012 2:43 AM
> > > > > To: Giles Heron; [email-masked]
> > > > > Subject: RE: Interest in IS-IS VPLS
> > > > >
> > > > > Hi Giles,
> > > > >
> > > > > It seems that the IS-IS VPLS provides the solution for a scalable
> > > > data
> > > > > center network as mentioned in the draft. I am not sure it is
> > > proper
> > > > > to weight service providers more on this. I can see if a service
> > > > > provider already deployed existing VPLS, the gain from IS-IS VPLS
> > > is
> > > > > less than the cost on upgrading all the edge devices to support
> > > > > the
> > > > solution.
> > > > >
> > > > > However, for data center network, IS-IS VPLS could be a useful
> > > > > solution. It simplifies current VPLS mechanism, provides a good
> > > > > scalability, and requires IP only function on core switches.
> > > > >
> > > > > A vendor provides devices for both service provider network and
> > > data
> > > > > center network, the solution brings a synergy in leveraging VPLS
> > > > > solution into DC.
> > > > >
> > > > > Thus, I like to see this work moving forward.
> > > > >
> > > > > Regards,
> > > > > Lucy
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked] [mailto:[email-masked]] On
> > > > Behalf
> > > > > Of Giles Heron
> > > > > Sent: Friday, April 27, 2012 7:57 AM
> > > > > To: [email-masked]
> > > > > Subject: Interest in IS-IS VPLS
> > > > >
> > > > > Hi,
> > > > >
> > > > > At the IETF meeting in Paris I took an action (as noted in the
> > > > > minutes) to poll the WG to see if there was any interest (other
> > > than
> > > > > by the authors of
> > > > > course) in progressing the IS-IS VPLS draft.
> > > > >
> > > > > Would you please respond to this email indicating whether or not
> > > you
> > > > > have interest in seeing this draft progress, ideally giving
> > > reasoning
> > > > > for your position.  It'd be especially interesting to see
> > > > > responses from service providers of course.
> > > > >
> > > > > If there are no (or very few) responses to this email then Nabil
> > > and
> > > > I
> > > > > will probably interpret that as meaning there's insufficient
> > > interest
> > > > > to progress.  Of course it may just mean that you all missed this
> > > > > email in the deluge of debate on E-Tree ;)
> > > > >
> > > > > Giles
> > > > >

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 2 May 2012 03:23:20 +0000

Hi,

Conceptually, TRILL/SPB/ISIS-VPLS are all "L2VPN" techniques. They all leverage ISIS as the control plane but utilize different silicon. SPB tries to utilize existing Ethernet-silicon. TRILL develops a new data plane and there are several vendors who would like to support this with new "TRILL-silicon". Except TRILL/SPB, there is a blue ocean where one can utilize existing IP/MPLS silicon. I agree with Lucy that their differences in control plane are trivial while the differences in data plane really distinguish them .

Thanks,
Mingui

   > From: [email-masked] [mailto:[email-masked]] On Behalf Of
   > Lucy yong
   > Sent: Monday, April 30, 2012 11:39 PM
   > IS-IS VPLS is completely different from TRILL and SPB although they all use of
   > IS-IS protocol in control plane. IS-IS VPLS data plane uses an IP/GRE tunnel
   > carrying VPN instances differentiated by MPLS labels. TRILL and SPB data
   > planes are Ethernet based, i.e. the frames are Ethernet frames.
   > 
   > Isn't it good that one control plane protocol can apply to different data
   > planes?
   > 
   > networks. IS-IS VPLS provides the simplified version of VPLS that can apply to
   > data center networks. This may be better than developing something
   > completely new in data center.
   > 
   > data center, an VPN is not necessary to provide a service to an customer, the
   > infrastructure need VPN capability.
   > 
   > Regards,
   > Lucy
   > 
   > 
   > 
   > We already have TRILL and SPB.  Why is yet another IS-IS variant necessary,
   > particularly one that is so completely under-specified?
   > 
   > Sent from my iPhone
   > 
   > 
   > > From: [email-masked] [mailto:[email-masked]] On Behalf
   > > Of Mach Chen
   > > In addition, since the ISIS VPLS leverages a uniform protocol(ISIS) for
   > > signaling and auto discovery, it would greatly simplify the deployment
   > > > center network as mentioned in the draft. I am not sure it is proper
   > > > provider already deployed existing VPLS, the gain from IS-IS VPLS is
   > > > less than the cost on upgrading all the edge devices to support the
   > > solution.
   > > >
   > > > A vendor provides devices for both service provider network and data
   > > > minutes) to poll the WG to see if there was any interest (other than
   > > > by the authors of
   > > > Would you please respond to this email indicating whether or not you
   > > > have interest in seeing this draft progress, ideally giving reasoning
   > > > for your position.  It'd be especially interesting to see responses
   > > > from service providers of course.
   > > >
   > > > If there are no (or very few) responses to this email then Nabil and
   > > I
   > > > will probably interpret that as meaning there's insufficient interest

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 2 May 2012 04:04:56 +0000

As said in the current L2VPN WG charter, "...It will also address requirements driven by cloud computing services and data centers as they apply to Layer-2 VPN services." That's why the co-authors of this draft tried to push this work in L2VPN WG.

I fully understand that some E-VPN folks are attempting to block this work (or even any other competing proposal) and at least exclude it from L2VPN WG. If that was me, I may also consider to do that, but through providing more objective, concrete and considered reasons, rather than personal preferences and even ...

As for why we need another proposal given TRILL/SPB are already there, you can find the clear answer from the NVo3 charter that has been published.

As for why we need another proposal given EVPN is already there and is deemed as good enough by somebody, you can find the answer from the recent discussions in NVo3 mailing-list and even from the motivation for simplifying E-VPN.

Best regards,
Xiaohu 

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Lucy
> yong
> 发送时间: 2012年5月1日 0:58
> 收件人: Gregory Mirsky; Giles Heron; [email-masked]
> Authors want to bring this work into NV03. However, NV03 just starts the
> problem statement and requirement. It is not in the stage of any solution yet.
> IS-IS VPLS is just an evolution of VPLS, it fits L2VPN too.
> 
> Lucy
> 
> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Monday, April 30, 2012 11:50 AM
> Dear Lucy,
> If authors believe that applicability area for the document is, primarily, in DC
> VPNs, then, IMHO, NVO3 WG might be suitable WG to continue work assuming
> the proposal satisfies functional and performance, including scaling,
> requirements that been referenced in NVO3 WG charter and will be detailed in
> framework and architectural documents.
> And I concur with Sasha, who reminded us, developers, that particular interest
> and value be paid to feedback from service providers.
> 
> 	Regards,
> 		Greg
> 
> Sent: Monday, April 30, 2012 8:39 AM
> Isn't it good that one control plane protocol can apply to different data planes?
> 
> I agree that VPLS has been well defined and used in Service Provider networks.
> IS-IS VPLS provides the simplified version of VPLS that can apply to data center
> networks. This may be better than developing something completely new in
> data center.
> 
> Maybe we need consider another name for this, for example DC-VPN? In data
> center, an VPN is not necessary to provide a service to an customer, the
> > for signaling and auto discovery, it would greatly simplify the
> > deployment and maintenance, especially for the DC networks that have
> > already deployed ISIS for IP routing. So I'd like to see the draft
> > moving forward.
> >
> > Best regards,
> > Mach
> >
> > > reasoning for your position.  It'd be especially interesting to see
> > > interest to progress.  Of course it may just mean that you all
> > > missed this email in the deluge of debate on E-Tree ;)
> > >
> > > Giles
> > >

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 1 May 2012 23:09:19 -0700

On May 1, 2012, at 21:07, "Xuxiaohu" <[email-masked]> wrote:

> I fully understand that some E-VPN folks are attempting to block this work

That's one interpretation. Another is a genuine interest in positive feedback from a *Service Provider* or other entity that cares to deploy this technology.  All I've seen so far is positive feedback from a _single vendor_.  Perhaps I've missed something; at times, my eyes glaze over on this topic.

I'm a simple guy: before I torque my implementation of the IGP that constitutes the backbone of several of my biggest customers, I want to see a substantial justification for doing so. I see a big risk; if there's a big reward, I'll consider it.

I'm still waiting.

Kireeti

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 2 May 2012 07:57:34 +0000

> I'm a simple guy: before I torque my implementation of the IGP that constitutes
> the backbone of several of my biggest customers, I want to see a substantial
> justification for doing so. I see a big risk; if there's a big reward, I'll consider it.

Hi Kireeti,

IS-IS VPLS is just intended to be used in a closed environment such as a data center network, rather than across the WAN backbone. In addition, the only extended TLV required in IS-IS VPLS could be processed as an unknown TLV by those core routers (i.e., P routers) within data centers. According to ISO 10589 and RFC 1195, IS-IS routers would ignore unknown TLVs in the LSP and pass them on to other neighbors unchanged. In other words, there are no need for core routers to parse any unknown TLVs in an IS-IS packet. Hence there is no big risk as you imagined. 

Best regards,
Xiaohu

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 2 May 2012 09:48:53 -0400

I make following observations -

- IETF mission statement: individual contributions/opinions, no company alliances. Given that being true,
  positive feedback from individuals should not be brushed aside as from a _single vendor_.
  Besides, I observe that harder pushback is from individuals from evpn coauthor member companies

- feedback from *service provider*:  
	- yes it is important, but carry equal weight as any other individual.
	- In early days, TRILL chair was asked if any SP wants this solution, answer was "no, but we think
	  this is an interesting problem to solve, so we are going to go ahead and do it" (paraphrasing).
	- Several SPs with deployments asked for -bhh- solution to be considered in MPLS-TP, with no avail.
	- in my view, need for SP feedback argument is used at convenience

- take it nvo3: but we just changed the L2VPN charter to work on DCN solutions...

- multiple protocols: but we have OSPF & ISIS in routing and more recently LDP & BGP in L2VPN..

- Xiahou responded to your concern on IGP. ISIS-VPLS can also be viewed as favorable solution for smaller networks..

Thanks,
himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kireeti Kompella
Sent: Wednesday, May 02, 2012 2:09 AM
To: Xuxiaohu
Cc: [email-masked]
Subject: Re: Interest in IS-IS VPLS

I'm still waiting.

Kireeti

---

From: John E Drake <[email-masked]>
Date: Wed, 2 May 2012 10:28:16 -0700

Comments inline

Sent from my iPhone

> Of Xuxiaohu
> Sent: Tuesday, May 01, 2012 9:05 PM
> To: Lucy yong; Gregory Mirsky; Giles Heron; [email-masked]
> Subject: re: Interest in IS-IS VPLS
> 
> As said in the current L2VPN WG charter, "...It will also address
> requirements driven by cloud computing services and data centers as
> they apply to Layer-2 VPN services." That's why the co-authors of this
> draft tried to push this work in L2VPN WG.
> 
> I fully understand that some E-VPN folks are attempting to block this
> work (or even any other competing proposal) and at least exclude it
> from L2VPN WG. If that was me, I may also consider to do that, but
> through providing more objective, concrete and considered reasons,
> rather than personal preferences and even ...

JD:  No, the issue is simply that developing yet another VPN is a waste of everyone's time, particularly when the only technical justification for it is that it will make things "better and better".  

> 
> As for why we need another proposal given TRILL/SPB are already there,
> you can find the clear answer from the NVo3 charter that has been
> published.

JD:  Where exactly?

> 
> As for why we need another proposal given EVPN is already there and is
> deemed as good enough by somebody, you can find the answer from the
> recent discussions in NVo3 mailing-list and even from the motivation
> for simplifying E-VPN.

JD:  Where exactly?
 
> > Authors want to bring this work into NV03. However, NV03 just starts
> > the problem statement and requirement. It is not in the stage of any
> solution yet.
> > If authors believe that applicability area for the document is,
> > primarily, in DC VPNs, then, IMHO, NVO3 WG might be suitable WG to
> > continue work assuming the proposal satisfies functional and
> > performance, including scaling, requirements that been referenced in
> > NVO3 WG charter and will be detailed in framework and architectural
> documents.
> > And I concur with Sasha, who reminded us, developers, that particular
> > interest and value be paid to feedback from service providers.
> >
> > 	Regards,
> > 		Greg
> >
> networks.
> > IS-IS VPLS provides the simplified version of VPLS that can apply to
> > > Behalf Of Mach Chen
> > > > proper to weight service providers more on this. I can see if a
> > > > service provider already deployed existing VPLS, the gain from
> > > > IS-IS VPLS is less than the cost on upgrading all the edge
> devices
> > > > to support the
> > > solution.
> > > >
> > > > data center network, the solution brings a synergy in leveraging
> > > > VPLS solution into DC.
> > > >
> > > > than by the authors of
> > > > you have interest in seeing this draft progress, ideally giving
> > > > reasoning for your position.  It'd be especially interesting to
> > > > see responses from service providers of course.
> > > >

---

From: John E Drake <[email-masked]>
Date: Wed, 2 May 2012 10:28:25 -0700

Nice rant, but a bit off topic.

Sent from my iPhone

> From: Xuxiaohu [mailto:[email-masked]]
> Sent: Tuesday, May 01, 2012 7:55 PM
> To: John E Drake; Linda Dunbar; Lucy yong; Mach Chen; Giles Heron;
> [email-masked]
> I'm not wondering that you said that word since you had ever doubted
> and even scorned the motivation of NVo3 and now NVo3 WG is formed which
> may make you very raging.
> 
> Xiaohu
> 
> > -----邮件原件-----
> > > > IS-IS VPLS is completely different from TRILL and SPB although
> > > > they all use of IS-IS protocol in control plane. IS-IS VPLS data
> > > > plane
> > > uses
> > > > I agree that VPLS has been well defined and used in Service
> > > > Provider networks. IS-IS VPLS provides the simplified version of
> > > > VPLS that can apply to data center networks. This may be better
> > > > than developing something completely new in data center.
> > > >
> > > > Maybe we need consider another name for this, for example DC-VPN?
> > > > In data center, an VPN is not necessary to provide a service to
> an
> > > > > and maintenance, especially for the DC networks that have
> > > > > already deployed ISIS for IP routing. So I'd like to see the
> > > > > draft moving forward.
> > > > >
> > > > > Best regards,
> > > > > Mach
> > > > >
> > > > > > to weight service providers more on this. I can see if a
> > > > > > IS-IS VPLS
> > > > > > solution. It simplifies current VPLS mechanism, provides a
> > > > > > good scalability, and requires IP only function on core
> switches.
> > > > > >
> > > > > > center network, the solution brings a synergy in leveraging
> > > > > > VPLS solution into DC.
> > > > > >
> > > > > > to progress.  Of course it may just mean that you all missed
> > > > > > this email in the deluge of debate on E-Tree ;)
> > > > > >
> > > > > > Giles
> > > > > >

---

From: John E Drake <[email-masked]>
Date: Wed, 2 May 2012 10:28:22 -0700

Mingui,

This completely misses the point.  I have yet to hear anyone say that IS-IS VPLS can do anything that SPB or TRILL cannot.

Given that they exist and that IS-IS VPLS does not, why would should we work an yet another solution?  Asserting that it performs the same function in a different way seems to be a less than compelling rationalization.

Thanks,

John

Sent from my iPhone

> From: Mingui Zhang [mailto:[email-masked]]
> Sent: Tuesday, May 01, 2012 8:23 PM
> Conceptually, TRILL/SPB/ISIS-VPLS are all "L2VPN" techniques. They all
> leverage ISIS as the control plane but utilize different silicon. SPB
> tries to utilize existing Ethernet-silicon. TRILL develops a new data
> plane and there are several vendors who would like to support this with
> new "TRILL-silicon". Except TRILL/SPB, there is a blue ocean where one
> can utilize existing IP/MPLS silicon. I agree with Lucy that their
> differences in control plane are trivial while the differences in data
> plane really distinguish them .
> 
> Thanks,
> Mingui
> 
> Behalf Of
> they all use of
> Provider
> In
> necessary,
> already
> service
> good
> VPLS
> this

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 2 May 2012 12:58:10 -0700

Hi Giles,

I would agree here too. I would like to see this work progress ahead as
well.

Thanks,
Vishwas

On Sat, Apr 28, 2012 at 3:04 AM, Mach Chen <[email-masked]> wrote:

> signaling and auto discovery, it would greatly simplify the deployment and
> maintenance, especially for the DC networks that have already deployed ISIS
> for IP routing. So I'd like to see the draft moving forward.
>
> Best regards,
> Mach
>
> > It seems that the IS-IS VPLS provides the solution for a scalable data
> center
> > network as mentioned in the draft. I am not sure it is proper to weight
> > service providers more on this. I can see if a service provider already
> > deployed existing VPLS, the gain from IS-IS VPLS is less than the cost on
> > upgrading all the edge devices to support the solution.
> >
> > However, for data center network, IS-IS VPLS could be a useful solution.
> It
> > simplifies current VPLS mechanism, provides a good scalability, and
> > requires IP only function on core switches.
> >
> > center network, the solution brings a synergy in leveraging VPLS solution
> > into DC.
> >
> > At the IETF meeting in Paris I took an action (as noted in the minutes)
> to
> > poll the WG to see if there was any interest (other than by the authors
> of
> > have
> > interest in seeing this draft progress, ideally giving reasoning for your
> > position.  It'd be especially interesting to see responses from service
> > providers of course.
> >
> > If there are no (or very few) responses to this email then Nabil and I
> will
> > probably interpret that as meaning there's insufficient interest to
> > progress.  Of course it may just mean that you all missed this email in
> the
> > deluge of debate on E-Tree ;)
> >
> > Giles
> >
>
>

---

From: Giles Heron <[email-masked]>
Date: Wed, 02 May 2012 21:37:53 +0100

Interesting.

As someone who has his name on various TRILL drafts what's your thinking on
the relationship between ISIS VPLS and TRILL?

Giles

---

From: Lucy yong <[email-masked]>
Date: Wed, 2 May 2012 21:07:15 +0000

I share my 2 cents.

>From the technology perspective, IS-IS VPLS and TRILL are two different technologies. From the applicability perspective, TRILL applies to enterprise DC and campus; IS-IS VPLS can apply to multi-tenant required and larger scale DCs that provides the services to enterprise customers.

I personally do not work on TRILL technology and like to see others' opinion.

Lucy 

-----Original Message-----
From: Giles Heron [mailto:[email-masked]] 
Sent: Wednesday, May 02, 2012 3:38 PM
To: Vishwas Manral; Mach Chen
Cc: Lucy yong; [email-masked]
Subject: Re: Interest in IS-IS VPLS

Interesting.

Giles

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 2 May 2012 17:41:40 -0400

Dear Lucy,
I'm intrigued how IS-IS VPLS would address scaling requirements outlined in NVO3 charter when its TLV is limited to 255 bytes and thus can carry only up to 30 VPLS ID-VPLS Labels tuples. Wouldn't OSPF Opaque LSA scale better? Or BGP?
What is the overwhelming benefit, technically speaking, of IS-IS VPLS proposal vs. BGP E-VPN?

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Wednesday, May 02, 2012 2:07 PM
To: Giles Heron; Vishwas Manral; Mach Chen
Cc: [email-masked]
Subject: RE: Interest in IS-IS VPLS

I share my 2 cents.

Lucy 

-----Original Message-----
From: Giles Heron [mailto:[email-masked]]
Sent: Wednesday, May 02, 2012 3:38 PM
To: Vishwas Manral; Mach Chen
Cc: Lucy yong; [email-masked]
Subject: Re: Interest in IS-IS VPLS

Interesting.

As someone who has his name on various TRILL drafts what's your thinking on the relationship between ISIS VPLS and TRILL?

Giles

On 02/05/2012 20:58, "Vishwas Manral" <[email-masked]> wrote:

> Hi Giles,
> 
> I would agree here too. I would like to see this work progress ahead 
> as well.
> 
> Thanks,
> Vishwas
> 
>> already deployed ISIS for IP routing. So I'd like to see the draft moving forward.
>> 
>> Best regards,
>> Mach
>> 
>>> Behalf Of Lucy yong
>>> network as mentioned in the draft. I am not sure it is proper to 
>>> weight service providers more on this. I can see if a service 
>>> less than the cost on upgrading all the edge devices to support the solution.
>>> 
>>> Behalf Of Giles Heron
>>> minutes)

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 2 May 2012 15:06:50 -0700

Hi Giles,

I did not make the TRILL to VPLS connection, as clearly as you probably did.

I may be wrong, but my thought is if TRILL is to be used between DC's, we
will have the CE devices communicating directly (in an overlay). The draft
seems to be talking about PE devices, connecting over IP core. We could use
L2TP/ GRE tunnels between the PE and use an IS-IS VPLS draft defined
mechanism to encapsulate packets.

We could ofcourse use an MPLS based solution in the core to achieve the
same thing, we could use TRILL for Layer-2 core, we could also use
solutions like EVN from Cisco for IP core, or we could use overlays which
the IS-IS VPLS solution provides.

Am I missing the point?

Thanks,
Vishwas

On Wed, May 2, 2012 at 1:37 PM, Giles Heron <[email-masked]> wrote:

> solution

---

From: Giles Heron <[email-masked]>
Date: Wed, 02 May 2012 23:24:28 +0100

Hi Vishwas,

I guess I made the TRILL/IS-IS VPLS connection based on earlier comments in
the thread suggesting that there was no need for a third ISIS-controlled
data-centre technology.

I suppose I'd see the TRILL/IS-IS VPLS differences as:
1) TRILL runs over a flat address space (TRILL nicknames) so you can't use
route aggregation in the core (whereas IS-IS VPLS runs over IP).  Not sure
that's an issue other than in the very largest data centres (and the TRILL
nickname approach has benefits in auto-configuration etc.)
2) TRILL (IIRC) is designed around a flat VLAN space whereas VPN solutions
like IS-IS VPLS tend to be better at supporting multi-tenancy.

Would you agree?

So it might be that we're better off comparing IS-IS VPLS to LDP/BGP VPLS (I
guess we've did a lot of that in the Paris meeting, and consensus in the
meeting at least seemed to be that there was no need for a third flavour of
VPLS) or to the NVO3 solution space (not that the NVO3 WG has got to
solutions yet).

Giles

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 2 May 2012 19:08:22 -0400

+1

	--Tom

On Apr 30, 2012:1:19 PM, at 1:19 PM, Henderickx, Wim (Wim) wrote:

> Not interested. If the problem needs to be solved it should be discussed in NVO3
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Giles Heron
> Sent: vrijdag 27 april 2012 14:57
> To: [email-masked]
> At the IETF meeting in Paris I took an action (as noted in the minutes) to
> poll the WG to see if there was any interest (other than by the authors of
> Would you please respond to this email indicating whether or not you have
> If there are no (or very few) responses to this email then Nabil and I will
> progress.  Of course it may just mean that you all missed this email in the

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 2 May 2012 19:18:31 -0400

I like John's naming suggestion.

	--Tom

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 3 May 2012 01:41:26 +0000

Hi Greg,

This issue has been solved by rfc5311.

Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Gregory Mirsky
> 发送时间: 2012年5月3日 5:42
> 收件人: Lucy yong
> 抄送: [email-masked]
> I'm intrigued how IS-IS VPLS would address scaling requirements outlined in
> NVO3 charter when its TLV is limited to 255 bytes and thus can carry only up to
> 30 VPLS ID-VPLS Labels tuples. Wouldn't OSPF Opaque LSA scale better? Or
> BGP?
> From the technology perspective, IS-IS VPLS and TRILL are two different
> technologies. From the applicability perspective, TRILL applies to enterprise DC
> and campus; IS-IS VPLS can apply to multi-tenant required and larger scale DCs
> that provides the services to enterprise customers.
>

---

From: Mingui Zhang <[email-masked]>
Date: Thu, 3 May 2012 02:44:25 +0000

Hi John,

It is a misunderstanding that I am asserting they "perform the same function". Repetitive explanation seems unnecessary since differences have been well explained by subsequent comments on the mailing list. 
Actually, I was wondering whether ISIS-VPLS can be used to achieve interconnection of TRILL/SPB.

Thanks,
Mingui

   > Sent: Thursday, May 03, 2012 1:28 AM
   > To: Mingui Zhang; Lucy yong; Mach Chen; Giles Heron; [email-masked]
   > This completely misses the point.  I have yet to hear anyone say that IS-IS
   > VPLS can do anything that SPB or TRILL cannot.
   > 
   > Given that they exist and that IS-IS VPLS does not, why would should we work
   > an yet another solution?  Asserting that it performs the same function in a
   > different way seems to be a less than compelling rationalization.
   > 
   > Thanks,
   > 
   > John
   > 
   > Sent from my iPhone
   > 
   >

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 3 May 2012 03:02:58 +0000

Hi Greg,

As for the LS PDU space limitation, the method defined in Simplified Extension of Link State PDU (LSP) Space for IS-IS [RFC5311] can be used to solve that issue. 

Compared to OSPF, IS-IS is more advantageous in the aspect of auto-configuration (e.g., plug&play), for example, there is no need for configuring IP addresses on the interfaces between IS-IS routers due to the unnumbered interface usage. In addition, it could naturally reuse the MAC-Reachability TLV defined in [RFC6165] to realize the control-plane based MAC learning mechanism.

Compared to EVPN, IS-IS VPLS itself could easily switch over between control-plane based MAC learning mechanism and data-plane based MAC learning mechanism on a per VPLS instance basis, and most importantly, without requiring the assistance of an additional PBB layer. In fact, I had ever thought about using BGP for advertising per VPLS instance label (which is different from the PW label) as what IS-IS VPLS does. This difference from E-VPN is there is no need to advertise MAC routes in the BGP updates. In other words, it still uses the data-plane based MAC learning mechanism. The difference from exiting PW-based VPLS solutions [RFC4761, RFC4762] is that there is no need for a full-mesh of PWs between PE routers. 

Best regards,
Xiaohu

---

From: Lucy yong <[email-masked]>
Date: Thu, 3 May 2012 03:21:55 +0000

Hi Gregory,

I like to answer your second question first.

Comparing IS-IS VPLS vs. BGP E-VPN, I think, is about comparing apple with orange. Two have different objectives. Here is some analysis on two.

The objective of E-VPN is to support multi-homing with active-active mode. E-VPN solution chooses BGP as the control plane protocol, so you name it BGP E-VPN. The E-VPN brings SP a new service. Current E-VPN draft use MPLS tunnel carrying the VPN traffic but mentions the potential to use of IP tunnel carrying the VPN traffic.

The objective of IS-IS VPLS is to simplify current VPLS mechanism, which can be scale and require only IP functions (no MPLS) in core switches. These features fit more in DC environment. Current VPLS solution requires full-meshed structure among all the PEs or PEs related to a VPN instance, which is not scale. H-VPLS solves it hub-spoke structure. However, DC architecture is very simple: ToR, Aggregation switch, and core switch. Thus H-VPLS does not apply to DC. IS-IS VPLS uses IP tunnel and a global VPN label so it does not have a full-meshed structure, which makes scale well. IS-IS VPLS does not provide any new service feature as E-VPN. Although it can apply to SP networks and bring the benefits, given the situation that VPLS/H-VPLS have been widely deployed now and is a popular service SP offers, We see it applying to DCs more than SP network.

DC people look for some cost effective solution and have some similar requirements as the VPN in service provider networks. It becomes very popular that DC core switch and aggregation switch to run IP only. When running IP, we need a routing protocol for sure. However, do we need MPLS capability and signaling protocol in these switches? With current chip technology, IP forwarding is equally as good as label forwarding. MPLS function seems unnecessary on these switches, which is cost saving. If IS-IS protocol can help to auto-configuring a VPN, we do not need LDP/BGP to construct the VPN as current VPLS. This reduces weight too. One trade-off is that IS-IS VPLS can't use of MPLS TE capability. But we don't think DC people want to use TE capability. Thus, IS-IS VPLS provides a cost effective L2 VPN solution for the DCs that require multi-tenancy and large scale. Since IS-IS VPLS uses of all existing PE process procedures except MAC binding to IP tunnel instead of PW, there is no need to re-spin the whole wheel and we can reuse existing stuff that was developed in this WG. 

Regarding your first question, I don't think that is correct. 20 bit labels can support a lots of VPNs. IS-IS has been used in DC today.

Regards,
Lucy

-----Original Message-----
From: Gregory Mirsky [mailto:[email-masked]] 
Sent: Wednesday, May 02, 2012 4:42 PM
To: Lucy yong
Cc: [email-masked]
Subject: RE: Interest in IS-IS VPLS

Dear Lucy,

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Wednesday, May 02, 2012 2:07 PM
To: Giles Heron; Vishwas Manral; Mach Chen
Cc: [email-masked]
Subject: RE: Interest in IS-IS VPLS

I share my 2 cents.

Lucy 

-----Original Message-----
From: Giles Heron [mailto:[email-masked]]
Sent: Wednesday, May 02, 2012 3:38 PM
To: Vishwas Manral; Mach Chen
Cc: Lucy yong; [email-masked]
Subject: Re: Interest in IS-IS VPLS

Interesting.

Giles

---

From: sajassi <[email-masked]>
Date: Wed, 02 May 2012 22:03:40 +0900

Giles, Nabil:

I am wondering if there is a plan to yet again re-charter L2VPN. Since this
draft intends to use a completely different data-plane and control plane
mechanism outside VPLS framework and RFC 4761 & 4762. When we introduced
evpn/pbb-evpn,  because of different data-plane/control-plane processing, we
had to go through re-chartering and thus the evpn solution is now explicitly
called out in the charter.

Every solution that this WG has worked on so far has explicitly been called
out in the charter.

If the intention is to re-charter the WG yet again, then it would be nice to
solicit AD's opinion first specially in light of the new NOV3 WG which is
specifically intended to cover  this kind of topic.

If ADs (or you) think that this solution should be covered in NVo3 WG, then
all these discussions around this draft in this WG is a moot point.

Regards,
Ali

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 3 May 2012 07:36:57 +0000

More specifically speaking, to overcome the 255-byte TLV limit, IS-IS allows the interpretation of multiple TLVs of a given type to be considered additive rather than mutually exclusive. For more details, please see section 6.4 of RFC5311.

Best regards,
Xiaohu

> Xuxiaohu
> 发送时间: 2012年5月3日 11:03
> 收件人: Gregory Mirsky; Lucy yong
> 抄送: [email-masked]
> 主题: re: Interest in IS-IS VPLS
> 
> Hi Greg,
> 
> As for the LS PDU space limitation, the method defined in Simplified Extension
> of Link State PDU (LSP) Space for IS-IS [RFC5311] can be used to solve that
> issue.
> 
> Compared to OSPF, IS-IS is more advantageous in the aspect of
> auto-configuration (e.g., plug&play), for example, there is no need for
> configuring IP addresses on the interfaces between IS-IS routers due to the
> unnumbered interface usage. In addition, it could naturally reuse the
> MAC-Reachability TLV defined in [RFC6165] to realize the control-plane based
> MAC learning mechanism.
> 
> Compared to EVPN, IS-IS VPLS itself could easily switch over between
> control-plane based MAC learning mechanism and data-plane based MAC
> learning mechanism on a per VPLS instance basis, and most importantly,
> without requiring the assistance of an additional PBB layer. In fact, I had ever
> thought about using BGP for advertising per VPLS instance label (which is
> different from the PW label) as what IS-IS VPLS does. This difference from
> E-VPN is there is no need to advertise MAC routes in the BGP updates. In other
> words, it still uses the data-plane based MAC learning mechanism. The
> difference from exiting PW-based VPLS solutions [RFC4761, RFC4762] is that
> there is no need for a full-mesh of PWs between PE routers.
> 
> Best regards,
> Xiaohu
> 
> > -----邮件原件-----

---

From: Giles Heron <[email-masked]>
Date: Thu, 03 May 2012 09:52:10 +0100

Hi Ali,

> called out in the charter.

No plans.  But equally, as you well know, we have always allowed discussion
on out-of-charter items (either pending charter changes - as with
E-VPN/E-Tree, or because they've been within the broad scope of layer 2 VPN
- your own discussions of TRILL E-VPN for example...) ;)
 
> Every solution that this WG has worked on so far has explicitly been called

Indeed.

> specifically intended to cover  this kind of topic.

As I've said above - no plans to re-charter at this point.  Though we may
need to address that for TRILL E-VPN, for example.  It was within the scope
of our first drafts of the new charter but appears to be excluded now
(largely because I hacked vast quantities of verbiage out of the charter at
the ADs' insistence).

> all these discussions around this draft in this WG is a moot point.

Well, all the proponents of IS-IS VPLS on this thread seem to see it as a
data-centre solution.  A data-centre solution that is an overlay on IP seems
(to me at least) to be better aligned to the NVO3 scope than the L2VPN
scope.

Or that could just be me being lazy and saying "IS-IS VPLS isn't my problem"
and punting it to Matthew and Benson ;)

Giles

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Thu, 3 May 2012 10:46:37 -0400

Hi,
Thanks Giles. I concur with Giles, and have nothing to add.

Thanks,
Nabil

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 3 May 2012 11:17:51 -0400

All -

Based on the current discussions/feedback expressed on the mailing list, 
We, the authors, have decided to suspend IS-IS VPLS draft considerations 
as a work item in L2VPN WG.

We will reevaluate the applicability and the target WG once the NVO3
requirements are clarified.

Thanks for the input.

Xiahou and Himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bitar, Nabil N
Sent: Thursday, May 03, 2012 10:47 AM
To: Giles Heron; Sagessi; Bitar, Nabil N
Cc: [email-masked]
Subject: Re: Interest in IS-IS VPLS

Hi,

Thanks,
Nabil

---

From: sajassi <[email-masked]>
Date: Thu, 03 May 2012 10:05:03 -0700

Hi Giles,

> (largely because I hacked vast quantities of verbiage out of the charter at

TRILL-EVPN is a member of E-VPN family solution (just like PBB-EVPN) and it
shows how E-VPN can be used to connect TRILL islands across MPLS/IP core
using E-VPN solution (e.g., it is an inter-DC solution for MPLS/IP core).
And it adheres to the charter specification:

"5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that
emulates an Ethernet (V)LAN across a PSN. E-VPN supports
load-sharing across multiple connections from a Layer-2 site
to an L2VPN service. E-VPN is primarily targeted to support
large-scale L2VPNs with resiliency requirements not satisfied
by other L2VPN solutions"

Cheers,
Ali

---

From: Giles Heron <[email-masked]>
Date: Thu, 03 May 2012 18:56:03 +0100

Hi Ali,

> by other L2VPN solutions"

Except a TRILL island isn't an Ethernet (V)LAN.  Though I guess you could
argue that neither is a PBB network.

The earlier drafts had wording along the lines of:

"For instance, interworking between an IEEE 802.1q, 802.1ah, 802.1aq or
TRILL data plane or control plane with an L2VPN data plane or control plane
should be identified when needed and solutions described."

I hacked that out - at the ADs' insistence.  And they're the ones now saying
it's out of scope ;)

Giles

---

From: sajassi <[email-masked]>
Date: Thu, 03 May 2012 12:19:31 -0700

Hi Giles,

> argue that neither is a PBB network.

TRILL network provides (V)LAN services just like PBB/SPB network that
provides (V)LAN services. Although I agree with you it is not an 802.1Q
network :-)

> I hacked that out - at the ADs' insistence.  And they're the ones now saying

If the ADs still think it is outside of the scope of L2VPN, then the
question is where to cover them ? Because it is clearly outside of TRILL WG
scope and it fits much better within L2VPN WG. Or maybe, they want to spin
off another WG to just cover that :-)

Cheers,
Ali

---

From: Lucy yong <[email-masked]>
Date: Thu, 3 May 2012 20:31:57 +0000

Hi Ali,

[[LY]] IMO, E-VPN enhancement is to support multi-homing with active-active mode. Load-sharing across multiple connections from a layer-2 site is desired when this mode is used. Current VPLS can provide resiliency requirement when the multi-homing site configured with active-standby mode.

Regards,
Lucy

Cheers,
Ali

---

From: Aldrin Isaac <[email-masked]>
Date: Thu, 3 May 2012 23:50:18 -0400

I'm not trying to sell E-VPN here, but I'd like to point out that multi-homing isn't the only reason why E-VPN came about.  It's just the one that satisfies the L2VPN charter.

E-VPN also supports policy based-topologies versus simple point-to-point, flat or tree VLANs.  It can support point-to-point, tree, mesh, one-way, or pretty much any other "complex" or overlapped topologies (depending on how you like to see it).  An example is ability to natively recreate private vlan, community vlan topologies (which happen to be quite common in DC networks) and any number of combinations of these simultaneously to a single port.  A BGP E-VPN VPN is also decoupled from the edge EVI/ESI such that it is not limited to a single tenant/vlan but can span tenants/vlans (l2 extranet) if so required.  This is native to E-VPN.

E-VPN supports interconnecting end-stations or interconnecting L2 networks.  Procedures to easily span STP based networks across an E-VPN network without loops comes with the base spec.  Extensions to E-VPN, such as PBB-EVPN, simplify the fully functional spanning of non-EVPN networks across an E-VPN network.

An SVI/IRB interface can also be a member of both an E-VPN EVI and an IP VRF allowing for easily bringing together virtual L2 and L3 topologies anywhere in the network without a physical port.

E-VPN builds on top of years of work in the IETF; traffic engineering, scaling with route reflectors and RT constrain, multicast via NG-MVPN, etc.

Can also use IP for transport tunnel.  But my understanding is that popular merchant silicon has support for MPLS push/pop/swap these days (?).  This was captured by EVPN at it's inception, which is why the PE is referred to as MES (MPLS-enabled switch) in E-VPN.

The way I see it, a major reason why STP-based LANS are fickle and don't scale well is on account of insufficient decoupling of core from edge created by requirement for plug-and-play and how that played out over time.  Conversely the reason (among other things) why IP networks are more stable is because they are not inherently plug-and-play, and with MPLS/BGP allows excellent decoupling of core and edge.  I don't know enough about TRILL or PBB to comment on those -- I just know that I'm not interested for enough good reasons.  E-VPN enables a dynamic edge over a stable decoupled core while giving each operator room for service differentiation.  It is especially interesting to operators that have invested in MPLS technology and operations.  I can find a lot of folks that understand BGP/MPLS IPVPN and in short order have them know the ins and outs of basic E-VPN.  It's quite hard for me to find non-vendor folk who really actually understand the other technologies used to span Ethernet aside from basic STP. 

This is an operator perspective.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 4 May 2012 14:33:54 +0000

+1

Jim Uttaro

---

From: Lucy yong <[email-masked]>
Date: Fri, 4 May 2012 15:07:58 +0000

Hi Isaac,

Thank you for the reply. Please see inline.

Regards,
Lucy

-----Original Message-----
From: Aldrin Isaac [mailto:[email-masked]] 
Sent: Thursday, May 03, 2012 10:50 PM
To: Lucy yong
Cc: sajassi; Giles Heron; Nabil Bitar; [email-masked]
Subject: Re: Interest in IS-IS VPLS

I'm not trying to sell E-VPN here,
[[LY]] Sound like. But We like to hear operator views on it for sure.
 but I'd like to point out that multi-homing isn't the only reason why E-VPN came about.  It's just the one that satisfies the L2VPN charter.
[[LY]] Does that mean some E-VPN functions are not in Charter? Don't have to answer, WG already agree to work on E-VPN now.

E-VPN also supports policy based-topologies versus simple point-to-point, flat or tree VLANs.  It can support point-to-point, tree, mesh, one-way, or pretty much any other "complex" or overlapped topologies (depending on how you like to see it).  An example is ability to natively recreate private vlan, community vlan topologies (which happen to be quite common in DC networks) and any number of combinations of these simultaneously to a single port.  A BGP E-VPN VPN is also decoupled from the edge EVI/ESI such that it is not limited to a single tenant/vlan but can span tenants/vlans (l2 extranet) if so required.  This is native to E-VPN.
[[LY]] Such policy based-topologies are useful for service provider network, but may too complex for intra DCs. One reason that customers often want to choose with L2VPN service is "it is simple". However, L3VPN have its applications although some operators often complain the complexities to configure these policies. Typical example is the a firewall only placed at a location. Could you share why operator want such policy based-topology for L2VPN?

E-VPN supports interconnecting end-stations or interconnecting L2 networks.  Procedures to easily span STP based networks across an E-VPN network without loops comes with the base spec.  Extensions to E-VPN, such as PBB-EVPN, simplify the fully functional spanning of non-EVPN networks across an E-VPN network.
[[LY]] current L2VPN support all these except active-active mode which causes the loop.

An SVI/IRB interface can also be a member of both an E-VPN EVI and an IP VRF allowing for easily bringing together virtual L2 and L3 topologies anywhere in the network without a physical port.
[[LY]] Could you please share how operator plan to use this? Which service will you sell to customer in this case?

E-VPN builds on top of years of work in the IETF; traffic engineering, scaling with route reflectors and RT constrain, multicast via NG-MVPN, etc.
[[LY]] Agree. These are useful features for service provider network. However, these functions may not necessary within DC although they had been proved works well. 

Can also use IP for transport tunnel.  But my understanding is that popular merchant silicon has support for MPLS push/pop/swap these days (?).  This was captured by EVPN at it's inception, which is why the PE is referred to as MES (MPLS-enabled switch) in E-VPN.
[[LY]] Yes, current draft aims on MPLS solution only. But it states the potential to extend to the use of IP tunnel. 

The way I see it, a major reason why STP-based LANS are fickle and don't scale well is on account of insufficient decoupling of core from edge created by requirement for plug-and-play and how that played out over time.  Conversely the reason (among other things) why IP networks are more stable is because they are not inherently plug-and-play, and with MPLS/BGP allows excellent decoupling of core and edge.  I don't know enough about TRILL or PBB to comment on those -- I just know that I'm not interested for enough good reasons.  E-VPN enables a dynamic edge over a stable decoupled core while giving each operator room for service differentiation.  It is especially interesting to operators that have invested in MPLS technology and operations.  I can find a lot of folks that understand BGP/MPLS IPVPN and in short order have them know the ins and outs of basic E-VPN.  It's quite hard for me to find non-vendor folk who really actually understand the other technologies used to span Ethernet aside from basic STP. 
[[LY]] Thank you to share this in the mailing list. 

[[LY]]  This is great!

---

From: Aldrin Isaac <[email-masked]>
Date: Fri, 4 May 2012 20:20:24 -0400

Hi Lucy,

Please see inline

> Subject: Re: Interest in IS-IS VPLS

... 

> [[LY]] Such policy based-topologies are useful for service provider network, but may too complex for intra DCs. One reason that customers often want to choose with L2VPN service is "it is simple".…

Policy-based topologies are generally complex when used to interconnect IP networks because there are generally multiple prefixes in a vrf, and often different prefixes need to be associated to different VPNs or routing behavior.  In the DC, L2VPN role is to interconnect host ports so the policies for basic are very simple --- list of import route targets and list of export route targets where each import/export pair correspond to a VPN (tenant, service, ...).  An example of how a DC operator might use this for example is to meet a requirement for private vlan and community vlans which are very common for DMZs.  Hopefully you are familiar with these very common use cases.  It is even possible to recreate more complex switch "features" like MVR (in addition to private VLANs which are also considered "features") using E-VPN.  It took me three years to get the MVR feature into a particular vendor's switch to meet a business need.  I'll sacrifice plug-and-play simplicity for business agility.  I'm sure my peers are with me on this one.

If simple "plug-and-play" is important, one could imagine RRs sending out an "RR TLV" such that RRs in an IGP area auto-connect with each other and RR-clients connect to the closest RR based on SPF (some details like peer-group, etc would need to be factored in to make it more powerful).  Other BGP/MPLS configuration is, IMHO, trivial unless you CHOOSE to use more advanced capabilities (i.e. not locked in).  

Maybe the reason why MPLS comes across as complex is because of how IETF deals with requirements lately by creating point solutions.  E-VPN tries to put new capabilities on the table while trying not to take existing value off the table.  There is no reason why a solution can't bring more value than what the standards body calls for.

> [[LY]] current L2VPN support all these except active-active mode which causes the loop.

Base E-VPN spec will natively deal with the STP case through an active/standby mode and BPDU-snooping -- detect root bridge and use that as ESI (ethernet segment id) to indicate unique STP network with active/standby bit set to ensure only one forwarding link among links with same ESI.  Tags (vlans) can potentially each have a different active link within the member links of an ESI allowing for automatic tag(tenant)/vlan level load-balancing into an STP network.  Edge networks that don't have mac-move issue will be able to take full advantage of active-active load-balancing without need for LAG/MLAG.

> [[LY]] Could you please share how operator plan to use this? Which service will you sell to customer in this case?

The service will be where a customer wants to communicate to a destination network that is not in his subnet.  Operators most interested in EVPN already have IPVPN services on their network.  This is the gateway point between the EVPN virtual networks and [existing] IPVPN virtual networks.  No physical port required.

> [[LY]] Agree. These are useful features for service provider network. However, these functions may not necessary within DC although they had been proved works well. 

I'm not sure how eventually re-inventing these capabilities (yes it will happen) on behalf of a new protocol will be better than simply leveraging proven technology.  Vendors don't need to implement every MPLS RFC ever written to be able to implement the basic E-VPN.

---

From: Lucy yong <[email-masked]>
Date: Mon, 7 May 2012 15:19:04 +0000

Hi Aldrin,

Thank you very for sharing your insight. It is great and very helpful. It is fine to add new service features on existing services. In fact, that is what we are working on in IETF.  

>From customer perspective, E-VPN supports all existing VPLS capability and add active-active mode and some policy based-topology control. It is useful extension. SPT based LAN is the history technology. LAG, MSTP, TRILL, SPB etc are all the replacement solutions. 

One thing that I am not clear from your reply is that the policy for L2VPN is to be against VLAN or MAC?
The latter will be very complex and not scale. The former will have some additional challenges and complex because VLAN ID may not be global based ID like IP addresses and L2VPN forwarding is based on MAC address while policy control is based on VLAN. Do I understand this right?

IMO: simplification is also important work for IETF and benefit to businesses as silicon technology improving. Without it, we have some limited room for adding new useful features and the system will be overly complex so nobody can afford operating it. This does not say E-VPN.

Thanks again.

Lucy

-----Original Message-----
From: Aldrin Isaac [mailto:[email-masked]] 
Sent: Friday, May 04, 2012 7:20 PM
To: Lucy yong
Cc: sajassi; Giles Heron; Nabil Bitar; [email-masked]
Subject: Re: Interest in IS-IS VPLS

Hi Lucy,

Please see inline

...

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 7 May 2012 15:25:33 +0000

Lucy,

	Comments In-Line..

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Monday, May 07, 2012 11:19 AM
To: Aldrin Isaac
Cc: [email-masked]; sajassi
Subject: RE: Interest in IS-IS VPLS

Hi Aldrin,

One thing that I am not clear from your reply is that the policy for L2VPN is to be against VLAN or MAC?
The latter will be very complex and not scale.
[Jim U>] In what ways is it too complex? In what ways does it not scale?
 The former will have some additional challenges and complex because VLAN ID may not be global based ID like IP addresses and L2VPN forwarding is based on MAC address while policy control is based on VLAN. Do I understand this right?

Thanks again.

Lucy

-----Original Message-----
From: Aldrin Isaac [mailto:[email-masked]] 
Sent: Friday, May 04, 2012 7:20 PM
To: Lucy yong
Cc: sajassi; Giles Heron; Nabil Bitar; [email-masked]
Subject: Re: Interest in IS-IS VPLS

Hi Lucy,

Please see inline

...

---

From: Lucy yong <[email-masked]>
Date: Mon, 7 May 2012 15:38:00 +0000

Hi James,

IMO: MAC address can't be summarized. Policy per individual MAC address will not scale. Host MAC may be from physical address or assigned to VM randomly not like IP address administrated, which makes policy setting BIG burden. I like to see operator insight on this. Do you plan to set the policy against MAC or VLAN?

Thanks,
Lucy

-----Original Message-----
From: UTTARO, JAMES [mailto:[email-masked]] 
Sent: Monday, May 07, 2012 10:26 AM
To: Lucy yong; Aldrin Isaac
Cc: [email-masked]; sajassi
Subject: RE: Interest in IS-IS VPLS

Lucy,

	Comments In-Line..

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Monday, May 07, 2012 11:19 AM
To: Aldrin Isaac
Cc: [email-masked]; sajassi
Subject: RE: Interest in IS-IS VPLS

Hi Aldrin,

Thanks again.

Lucy

-----Original Message-----
From: Aldrin Isaac [mailto:[email-masked]] 
Sent: Friday, May 04, 2012 7:20 PM
To: Lucy yong
Cc: sajassi; Giles Heron; Nabil Bitar; [email-masked]
Subject: Re: Interest in IS-IS VPLS

Hi Lucy,

Please see inline

...

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 7 May 2012 21:29:08 +0000

Adrin, 

You mentioned that " private vlan and community vlans which are very common for DMZs in Data Center". 

I can totally understand why "private vlan" being used. But what scenario will you need "community vlans" but can't be simply achieved by traditional VLANs? 

Thanks, Linda 

> Of Aldrin Isaac
> > E-VPN also supports policy based-topologies versus simple point-to-
> point, flat or tree VLANs.  It can support point-to-point, tree, mesh,
> one-way, or pretty much any other "complex" or overlapped topologies
> (depending on how you like to see it).  An example is ability to
> natively recreate private vlan, community vlan topologies (which happen
> to be quite common in DC networks) and any number of combinations of
> these simultaneously to a single port.  A BGP E-VPN VPN is also
> decoupled from the edge EVI/ESI such that it is not limited to a single
> tenant/vlan but can span tenants/vlans (l2 extranet) if so required.
> This is native to E-VPN.
> > [[LY]] Such policy based-topologies are useful for service provider
> network, but may too complex for intra DCs. One reason that customers
> often want to choose with L2VPN service is "it is simple". However,
> L3VPN have its applications although some operators often complain the
> complexities to configure these policies. Typical example is the a
> firewall only placed at a location. Could you share why operator want
> such policy based-topology for L2VPN?
> 
> Policy-based topologies are generally complex when used to interconnect
> IP networks because there are generally multiple prefixes in a vrf, and
> often different prefixes need to be associated to different VPNs or
> routing behavior.  In the DC, L2VPN role is to interconnect host ports
> so the policies for basic are very simple --- list of import route
> targets and list of export route targets where each import/export pair
> correspond to a VPN (tenant, service, ...).  An example of how a DC
> operator might use this for example is to meet a requirement for
> private vlan and community vlans which are very common for DMZs.
> Hopefully you are familiar with these very common use cases.  It is
> even possible to recreate more complex switch "features" like MVR (in
> addition to private VLANs which are also considered "features") using
> E-VPN.  It took me three years to get the MVR feature into a particular
> vendor's switch to meet a business need.  I'll sacrifice plug-and-play
> simplicity for business agility.  I'm sure my peers are with me on this
> one.
> 
> If simple "plug-and-play" is important, one could imagine RRs sending
> out an "RR TLV" such that RRs in an IGP area auto-connect with each
> other and RR-clients connect to the closest RR based on SPF (some
> details like peer-group, etc would need to be factored in to make it
> more powerful).  Other BGP/MPLS configuration is, IMHO, trivial unless
> you CHOOSE to use more advanced capabilities (i.e. not locked in).
> 
> Maybe the reason why MPLS comes across as complex is because of how
> IETF deals with requirements lately by creating point solutions.  E-VPN
> tries to put new capabilities on the table while trying not to take
> existing value off the table.  There is no reason why a solution can't
> bring more value than what the standards body calls for.
> 
> > E-VPN supports interconnecting end-stations or interconnecting L2
> networks.  Procedures to easily span STP based networks across an E-VPN
> network without loops comes with the base spec.  Extensions to E-VPN,
> such as PBB-EVPN, simplify the fully functional spanning of non-EVPN
> networks across an E-VPN network.
> Base E-VPN spec will natively deal with the STP case through an
> active/standby mode and BPDU-snooping -- detect root bridge and use
> that as ESI (ethernet segment id) to indicate unique STP network with
> active/standby bit set to ensure only one forwarding link among links
> with same ESI.  Tags (vlans) can potentially each have a different
> active link within the member links of an ESI allowing for automatic
> tag(tenant)/vlan level load-balancing into an STP network.  Edge
> networks that don't have mac-move issue will be able to take full
> advantage of active-active load-balancing without need for LAG/MLAG.
> 
> > An SVI/IRB interface can also be a member of both an E-VPN EVI and an
> IP VRF allowing for easily bringing together virtual L2 and L3
> topologies anywhere in the network without a physical port.
> > [[LY]] Could you please share how operator plan to use this? Which
> service will you sell to customer in this case?
> 
> The service will be where a customer wants to communicate to a
> destination network that is not in his subnet.  Operators most
> interested in EVPN already have IPVPN services on their network.  This
> is the gateway point between the EVPN virtual networks and [existing]
> IPVPN virtual networks.  No physical port required.
> 
> > E-VPN builds on top of years of work in the IETF; traffic engineering,
> scaling with route reflectors and RT constrain, multicast via NG-MVPN,
> etc.
> > [[LY]] Agree. These are useful features for service provider network.
> However, these functions may not necessary within DC although they had
> been proved works well.
> 
> I'm not sure how eventually re-inventing these capabilities (yes it
> will happen) on behalf of a new protocol will be better than simply
> leveraging proven technology.  Vendors don't need to implement every
> MPLS RFC ever written to be able to implement the basic E-VPN.
> 
> > Can also use IP for transport tunnel.  But my understanding is that
> popular merchant silicon has support for MPLS push/pop/swap these days
> (?).  This was captured by EVPN at it's inception, which is why the PE
> is referred to as MES (MPLS-enabled switch) in E-VPN.
> > [[LY]] Yes, current draft aims on MPLS solution only. But it states
> the potential to extend to the use of IP tunnel.
> > The way I see it, a major reason why STP-based LANS are fickle and
> don't scale well is on account of insufficient decoupling of core from
> edge created by requirement for plug-and-play and how that played out
> over time.  Conversely the reason (among other things) why IP networks
> are more stable is because they are not inherently plug-and-play, and
> with MPLS/BGP allows excellent decoupling of core and edge.  I don't
> know enough about TRILL or PBB to comment on those -- I just know that
> I'm not interested for enough good reasons.  E-VPN enables a dynamic
> edge over a stable decoupled core while giving each operator room for
> service differentiation.  It is especially interesting to operators
> that have invested in MPLS technology and operations.  I can find a lot
> of folks that understand BGP/MPLS IPVPN and in short order have them
> know the ins and outs of basic E-VPN.  It's quite hard for me to find
> non-vendor folk who really actually understand the other technologies
> used to span Ethernet aside from basic STP.
> 
> >> [[LY]] IMO, E-VPN enhancement is to support multi-homing with
> active-active mode. Load-sharing across multiple connections from a
> layer-2 site is desired when this mode is used. Current VPLS can
> provide resiliency requirement when the multi-homing site configured
> with active-standby mode.
> >>
> >> Regards,
> >> Lucy
> >>
> >> Cheers,
> >> Ali
> >>
> >

---

From: Aldrin Isaac <[email-masked]>
Date: Mon, 7 May 2012 23:59:45 -0400

Hi Lucy, see in line.

> The latter will be very complex and not scale. The former will have some additional challenges and complex because VLAN ID may not be global based ID like IP addresses and L2VPN forwarding is based…

Policy is applied to the EVI (VRF) table which applies to all route types in the table.  An EVI can have a single link or be shared by multiple links.  The tag with which a packet arrives into the network does not have to be the tag with which it leaves the network.  I.e. destination tag and ingress tag are decoupled in EVPN.

> IMO: simplification is also important work for IETF and benefit to businesses as silicon technology improving. Without it, we have some limited room for adding new useful features and the system wi…

For operators who want simplicity, they can get this easily by moving compute/storage to hypervisors and buying an overlay solution -- it's available today commercial or free.  It's the cheapest and easiest to implement out of the box with little to no knowledge of networking protocols.  I'm observing sysadmin and security guys set this up today (literally).

---

From: Aldrin Isaac <[email-masked]>
Date: Tue, 8 May 2012 00:04:34 -0400

Linda,

Let me give a simple example.  If you have a DMZ with a public /24 address and you want to share that DMZ (one pair of firewalls to the Internet) with multiple different classes of applications that you want to keep isolated from each other.  Within each class the computers can communicate with each other and out to the Internet, but computers that are of different classes cannot communicate with one another.

-- aldrin

---

From: Lucy yong <[email-masked]>
Date: Tue, 8 May 2012 14:43:47 +0000

Hi Aldrin,

I got it. Thanks a lot.

Interconnecting private LANs and Community LAN is the application for E-Tree, where private LAN set as leaf AC and Community LAN set as root AC. Of course, policy based-topology can support other more sophisticated scenarios.

Lucy

-----Original Message-----
From: Aldrin Isaac [mailto:[email-masked]] 
Sent: Monday, May 07, 2012 11:00 PM
To: Lucy yong
Cc: sajassi; Giles Heron; Nabil Bitar; [email-masked]
Subject: Re: Interest in IS-IS VPLS

Hi Lucy, see in line.

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 8 May 2012 14:54:44 +0000

Isaac, 

I thought that is why "Private VLAN" is introduced. 
You can put the pair of firewalls in "private VLAN" and create a group of regular VLANs (with each VLAN mapped to /xx, and  xx >24). 
This group of VLANs can access the "private VLAN". Is it correct?

Thanks for the example.

Linda

> Sent: Monday, May 07, 2012 11:05 PM
> To: Linda Dunbar
> Cc: Lucy yong; [email-masked]; sajassi
> Let me give a simple example.  If you have a DMZ with a public /24
> address and you want to share that DMZ (one pair of firewalls to the
> Internet) with multiple different classes of applications that you want
> to keep isolated from each other.  Within each class the computers can
> communicate with each other and out to the Internet, but computers that
> are of different classes cannot communicate with one another.
> 
> -- aldrin
> 
> 
> > I can totally understand why "private vlan" being used. But what
> scenario will you need "community vlans" but can't be simply achieved
> by traditional VLANs?
> >
> > Thanks, Linda
> >
> >

---

From: Aldrin Isaac <[email-masked]>
Date: Tue, 8 May 2012 21:26:53 -0400

Hi Linda, in my rush I didn't explain it properly.  A better explanation can be found here http://en.wikipedia.org/wiki/Private_VLAN.  Best -- aldrin