Subject: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

From: Jiangyuanlong <[email-masked]>
Date: Fri, 21 Sep 2012 09:16:25 +0000

Hi all,

During the 84th IETF meeting, the group discussed the issue of E-Tree in E-VPN, and it was shown that a single solution was more preferred than two different approaches for VPLS and E-VPN.
This I-D probes how the 2VLAN approach can be used to support E-Tree in E-VPN and it seems not a big issue.
Any comments from you are greatly appreciated.

Best regards,
Yuanlong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, September 21, 2012 4:55 PM
To: Jiangyuanlong
Subject: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
has been successfully submitted by Yuanlong Jiang and posted to the
IETF repository.

Filename:	 draft-jiang-l2vpn-evpn-etree-2vlan
Revision:	 00
Title:		 E-Tree Support with 2VLAN in E-VPN
Creation date:	 2012-09-21
WG ID:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
Status:          http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan
Htmlized:        http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00

Abstract:
   This document discusses how the Dual-VLAN approach as described in
   [Etree-vlan] can be used to support the transport of E-Tree service
   in E-VPN. Thus a single convergent solution is possible for both VPLS
   and E-VPN.

The IETF Secretariat

---

From: Giles Heron <[email-masked]>
Date: Fri, 21 Sep 2012 14:09:17 +0100

Thanks Yuanlong,

however I must say that your memory of the IETF 84 L2VPN meeting differs from mine (and from what is noted in the minutes).  Whilst Himanshu said that it was better to have the same solution for VPLS and E-VPN, Ali stated that there was no benefit in the E-VPN case in using an additional tag (such as a VLAN).  No consensus was reached in the meeting.

Giles

---

From: Jiangyuanlong <[email-masked]>
Date: Sat, 22 Sep 2012 02:31:55 +0000

Hi Giles,

Perhaps the gauge of the consensus in the minutes was not so clear for me:
"         Giles - are we agreed we want to get to one solution for VPLS and E-VPN.
          Not many people.  But even fewer who want multiple.  Checked to see if
          people want one solution only for E-VPN and VPLS - only a couple of hands."
Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus to decide which way to take. 

Thanks,
Yuanlong

-----Original Message-----
From: Giles Heron [mailto:[email-masked]] 
Sent: Friday, September 21, 2012 9:09 PM
To: Jiangyuanlong
Cc: [email-masked]
Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Thanks Yuanlong,

Giles

---

From: Aldrin Isaac <[email-masked]>
Date: Sat, 22 Sep 2012 11:28:07 -0400

In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import RTB export RTA at spokes) with filtering to enforce downstream data flow if desired.  The tree could be built using PIM, mLDP, RSVP, etc.

---

From: "Rogers, Josh" <[email-masked]>
Date: Sat, 22 Sep 2012 12:48:43 -0400

So, this same sort of 'import/export' of targets is possible using
BGP-VPLS today, but it faces limitations outlined in
draft-ietf-l2vpn-etree-frwk, in section 2.  E-VPN would be able to
import/export by attachment circuit, and not by PE?  Meaning, AC1 one PE1
may import RTA, while AC2 on PE2 may import RTB?

Its occurred to me that EVPN would be able to use other mechanisms that
have not yet been discussed yet due to sharing a mac table over BGP.

Thanks for the response,
Josh

On 9/22/12 10:28 AM, "Aldrin Isaac" <[email-masked]> wrote:

>In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as
>in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import RTB
>export RTA at spokes) with filtering to enforce downstream data flow if
>desired.  The tree could be built using PIM, mLDP, RSVP, etc.
>
>
>
>> however I must say that your memory of the IETF 84 L2VPN meeting
>>differs from mine (and from what is noted in the minutes).  Whilst
>>Himanshu said that it was better to have the same solution for VPLS and
>>E-VPN, Ali stated that there was no benefit in the E-VPN case in using
>>an additional tag (such as a VLAN).  No consensus was reached in the
>>meeting.
>>
>> Giles
>>
>>> During the 84th IETF meeting, the group discussed the issue of E-Tree
>>>in E-VPN, and it was shown that a single solution was more preferred
>>>than two different approaches for VPLS and E-VPN.
>>> Subject: New Version Notification for
>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
>>>
>>>
>>> URL:
>>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-0
>>>0.txt
>>> Status:
>>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan
>>> Htmlized:
>>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00
>>>
>>>
>>> Abstract:

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Aldrin Isaac <[email-masked]>
Date: Sat, 22 Sep 2012 15:48:21 -0400

Yes, as long as the leaf and root AC or MAC can have different local
contexts against which different RT can be associated.

Implementations may support RT import/export at a virtual switch level,
VLAN level, port level, or even down to MAC level.  The fact that EVPN can
advertise a label for MAC routes down to individual MAC makes it possible
to create topologies at MAC level.  MAC routes can even  have more than one
RT.  I suppose you can even run in a VPLS mode with dataplane MAC learning
at edges with topologies possible at an ESI+tag granularity.

On Saturday, September 22, 2012, Rogers, Josh wrote:

> On 9/22/12 10:28 AM, "Aldrin Isaac" <[email-masked] <javascript:;>>
> wrote:
>
> >> On 21 Sep 2012, at 10:16, Jiangyuanlong <[email-masked]<javascript:;>
> >
> >>wrote:
> >>
> >>> Hi all,
> >>>
> >>> From: [email-masked] <javascript:;> [mailto:
> [email-masked] <javascript:;>]
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>

---

From: "Rogers, Josh" <[email-masked]>
Date: Sat, 22 Sep 2012 17:30:59 -0400

Sorry, allow me to re-type correctly this statement:

Meaning, AC1 on PE1 may import RTA, while AC2 on PE1 may import RTB?

Thank you for the explanation Aldrin.

-Josh

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Sat, 22 Sep 2012 21:56:56 +0000

EVPN is intended to maximize the flexibility of multiple routing contexts with arbitrary topologies.. As I have stated in the past, EVPN allows for E-Tree to be constructed in the control plane, other solutions require some method to interrogate data and infer topology. IMO this is not desirable.

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rogers, Josh
Sent: Saturday, September 22, 2012 12:49 PM
To: Aldrin Isaac; Giles Heron
Cc: [email-masked]; Jiangyuanlong
Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Thanks for the response,
Josh

---

From: "Rogers, Josh" <[email-masked]>
Date: Sat, 22 Sep 2012 19:03:22 -0400

I agree.

Would it be safe to state that VPLS has a need for a 'etree solution', but
EVPN does not, because it is inherently supported?

The previously discussed effort of having a 'single etree solution' for
both VPLS and EVPN may not really be valid due to this.

In fact, I do not think it is valid to ask for a single solution, EVPN
doesn't have a problem that needs to be fixed here, I don't believe it
factors into this discussion.

-Josh

On 9/22/12 4:56 PM, "UTTARO, JAMES" <[email-masked]> wrote:

>EVPN is intended to maximize the flexibility of multiple routing contexts
>with arbitrary topologies.. As I have stated in the past, EVPN allows for
>E-Tree to be constructed in the control plane, other solutions require
>some method to interrogate data and infer topology. IMO this is not
>desirable.
>
>Jim Uttaro
>
>Subject: Re: New Version Notification for
>are not the intended recipient of this E-mail, you are hereby notified
>that any dissemination, distribution, copying, or action taken in
>relation to the contents of and attachments to this E-mail is strictly
>prohibited and may be unlawful. If you have received this E-mail in
>error, please notify the sender immediately and permanently delete the
>original and any copy of this E-mail and any printout.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Sat, 22 Sep 2012 23:34:28 +0000

Josh,

	Yes.. I think that is the reality of it.. VPLS either the LDP or BGP variety uses data plane learning as the mechanism to "learn".. The fact that we extend the L2 footprint via these "tunnels" does not change that fact.. SO in VPLS the only hammer you have is the data plane, so one must manipulate bits on the wire to infer topology ( Limited set of topology )..

Another challenge is when roots and leafs "land" on the same PE.

EVPN is intended to use contexts and associated import/export to manage the topology.. So here there is a set of tools to create the desired topologies, along with that there other mechanisms realized i.e active/active...

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rogers, Josh
Sent: Saturday, September 22, 2012 7:03 PM
To: UTTARO, JAMES; Aldrin Isaac; Giles Heron
Cc: [email-masked]; Jiangyuanlong
Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

I agree.

-Josh

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 23 Sep 2012 08:24:59 +0000

Yuanlong, Giles, Himanshu, Ali and all,

I have probably missed something important (not being present at the latest IETF meeting).

But I think something is wrong with the statement "there was no benefit in the E-VPN case in using an additional tag (such as a VLAN)".

IMHO and FWIW the real E-Tree problem is the situation when there are two (or more) PEs with both Root and Leaf ACs.

When one of such PEs receives a VPLS packet from another such PE, it must somehow identify the source AC of the Ethernet frame in this packet, and, in the case of it being a leaf AC, prevent its forwarding to the local Leaf AC(s) while allowing forwarding to local Root AC(s). This equally applies to regular VPLS and E-VPN, e.g., in the case when the contained Ethernet frame is a broadcast one (so that no learning is associated with it). And I strongly doubt this can be achieved without some "tags" in the encapsulation.

My 2c,

     Sasha

> From: [email-masked] [mailto:[email-masked]] On Behalf

> Of Jiangyuanlong

> Sent: Saturday, September 22, 2012 5:32 AM

> To: Giles Heron

> Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

> "         Giles - are we agreed we want to get to one solution for VPLS and E-

> VPN.

>           Not many people.  But even fewer who want multiple.  Checked to see

> if

>           people want one solution only for E-VPN and VPLS - only a couple of

> hands."

> Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus to

> decide which way to take.

> Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

> however I must say that your memory of the IETF 84 L2VPN meeting differs

> from mine (and from what is noted in the minutes).  Whilst Himanshu said

> that it was better to have the same solution for VPLS and E-VPN, Ali stated

> that there was no benefit in the E-VPN case in using an additional tag (such as

> a VLAN).  No consensus was reached in the meeting.

> On 21 Sep 2012, at 10:16, Jiangyuanlong <[email-masked]<mailto:[email-masked]>>

> > During the 84th IETF meeting, the group discussed the issue of E-Tree in E-

> VPN, and it was shown that a single solution was more preferred than two

> different approaches for VPLS and E-VPN.

> > This I-D probes how the 2VLAN approach can be used to support E-Tree in

> E-VPN and it seems not a big issue.

> > Subject: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

> > URL:             http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-<http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-00.txt>

> etree-2vlan-00.txt<http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-00.txt>

> > Status:          http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-<http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan>

> 2vlan<http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan>

> > Htmlized:        http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-<http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00>

> 2vlan-00<http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00>

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Aldrin Isaac <[email-masked]>
Date: Sun, 23 Sep 2012 09:21:09 -0400

With EVPN, leaf AC should have different context and associated label from
root AC.  A leaf AC forwarding context (say EVI) on an ingress PE would not
import the RT for other leaf AC and hence not have forwarding vectors to
any leaf AC.  The packet would have nowhere to go and hence be dropped on
ingress.  In the case of BUM ingress replication, the leaf AC forwarding
context on the ingress PE would not have imported the Inclusive Tag route
of egress leaf AC and hence have no vectors to local replication context
IDs of other leaf AC .  In the case of BUM tree, the leaf EVI would not
have imported the Inclusive Tag route of other leaf EVI and hence not form
a tree to other leaf EVI.

On Sunday, September 23, 2012, Alexander Vainshtein wrote:

>  Yuanlong, Giles, Himanshu, Ali and all,****
>
> I have probably missed something important (not being present at the
> latest IETF meeting).****
>
> But I think something is wrong with the statement "*there was no benefit
> in the E-VPN case in using an additional tag (such as a VLAN)"*.****
>
> ** **
>
> IMHO and FWIW the real E-Tree problem is the situation when there are two
> (or more) PEs with both Root and Leaf ACs.****
>
> When one of such PEs receives a VPLS packet from another such PE, it must
> somehow identify the source AC of the Ethernet frame in this packet, and,
> in the case of it being a leaf AC, prevent its forwarding to the local Leaf
> AC(s) while allowing forwarding to local Root AC(s). This equally applies
> to regular VPLS and E-VPN, e.g., in the case when the contained Ethernet
> frame is a broadcast one (so that no learning is associated with it). And I
> strongly doubt this can be achieved without some “tags” in the
> encapsulation. ****
>
> ** **
>
> My 2c,****
>
>      Sasha****
>
> ** **
>
> > From: [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');> [mailto:[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>]
> On Behalf
>
> > Of Jiangyuanlong
>
> > Cc: [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
>
> draft-jiang-l2vpn-evpn-etree-2vlan-
>
> > 00.txt
>
> >
>
> > Thanks Yuanlong,
>
> >
>
> > On 21 Sep 2012, at 10:16, Jiangyuanlong <[email-masked]>
>
> > wrote:
>
> >
>
> > > Hi all,
>
> > >
>
> in E-
> draft-jiang-l2vpn-evpn-etree-2vlan-
>
> > 00.txt
>
> > >
>
> > >
>
> http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-<http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-00.txt>
>
> http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-<http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan>
>
> http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-<http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00>
>
> > >   This document discusses h
>
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please inform us
> by e-mail, phone or fax, and then delete the original and all copies
> thereof.
>

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 24 Sep 2012 02:22:56 +0000

Sasha,

>From Ali's I-D draft-sajassi-l2vpn-evpn-etree-00, it seems two ESI MPLS labels per Ethernet segment are used for E-Tree. So one is used for root traffic and another is used for leaf traffic, just like in the 2PW approach.
But it has the same problem as 2PW IMHO and OAM will be a challenge.
Besides, manipulation of those labels and import/export of their associated RT attributes may not be easy.

Thanks,
Yuanlong

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Sunday, September 23, 2012 4:25 PM
To: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi
Cc: [email-masked]
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

My 2c,

     Sasha

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 24 Sep 2012 02:46:08 +0000

Hi Aldrin,

I agree with you that using different labels for root/leaf AC can work, but not sure using 2 forwarding contexts (EVI) is a good thing - that means forwarding plane for E-Tree will be very different from other services in E-VPN.

Regards,
Yuanlong

From: Aldrin Isaac [mailto:[email-masked]]
Sent: Sunday, September 23, 2012 9:21 PM
To: Alexander Vainshtein
Cc: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi; [email-masked]
Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

With EVPN, leaf AC should have different context and associated label from root AC.  A leaf AC forwarding context (say EVI) on an ingress PE would not import the RT for other leaf AC and hence not have forwarding vectors to any leaf AC.  The packet would have nowhere to go and hence be dropped on ingress.  In the case of BUM ingress replication, the leaf AC forwarding context on the ingress PE would not have imported the Inclusive Tag route of egress leaf AC and hence have no vectors to local replication context IDs of other leaf AC .  In the case of BUM tree, the leaf EVI would not have imported the Inclusive Tag route of other leaf EVI and hence not form a tree to other leaf EVI.

My 2c,

     Sasha

> From: [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');> [mailto:[email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>] On Behalf

> Cc: [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>

---

From: Aldrin Isaac <[email-masked]>
Date: Mon, 24 Sep 2012 00:27:53 -0400

Hi Yuanlong,

I'm not clear as to why different forwarding contexts for root and leaf is
less than good -- can you elaborate?  Also I'm not clear as to why you see
that ETREE using EVPN is any different from other topologies that can be
created with EVPN.  EVPN's ability to create any topology is fundamental to
it.  In IPVPN we commonly create hub-and-spoke VPN with hubs and spokes in
different VRF. In some cases we even overlap one or more hub-and-spoke RT
pairs with one or more mesh RT.  EVPN was purposefully designed to bring
this flexibility to Ethernet.

Best regards -- aldrin

On Sunday, September 23, 2012, Jiangyuanlong wrote:

>  Hi Aldrin,****
>
> ** **
>
> I agree with you that using different labels for root/leaf AC can work,
> but not sure using 2 forwarding contexts (EVI) is a good thing – that means
> forwarding plane for E-Tree will be very different from other services in
> E-VPN. ****
>
> ** **
>
> Regards,****
>
> Yuanlong****
>
> ** **
>
> *From:* Aldrin Isaac [mailto:[email-masked] <javascript:_e({},
> 'cvml', [email-masked]');>]
> *Sent:* Sunday, September 23, 2012 9:21 PM
> *To:* Alexander Vainshtein
> *Cc:* Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi;
> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
> *Subject:* Re: FW: New Version Notification for
> draft-jiang-l2vpn-evpn-etree-2vlan-00.txt****
>
> ** **
>
> a tree to other leaf EVI. ****
>
> ** **
>
>
>
> On Sunday, September 23, 2012, Alexander Vainshtein wrote:****
>
>  ****
>  ****
>  ****
> > -----Original Message-----****
>
> > From: [email-masked] [mailto:[email-masked]] On Behalf**
> **
>
> > Of Jiangyuanlong****
>
> > Sent: Saturday, September 22, 2012 5:32 AM****
>
> > To: Giles Heron****
>
> > Cc: [email-masked]****
>
> > Subject: RE: New Version Notification for
> draft-jiang-l2vpn-evpn-etree-2vlan-****
>
> > 00.txt****
>
> > ****
>
> > Hi Giles,****
>
> > ****
>
> > Perhaps the gauge of the consensus in the minutes was not so clear for
> me:****
>
> > "         Giles - are we agreed we want to get to one solution for VPLS
> and E-****
>
> > VPN.****
>
> >           Not many people.  But even fewer who want multiple.  Checked
> to see****
>
> > if****
>
> >           people want one solution only for E-VPN and VPLS - only a
> couple of****
>
> > hands."****
>
> > Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus
> to****
>
> > decide which way to take.****
>
> > ****
>
> > Thanks,****
>
> > Yuanlong****
>
> > ****
>
> > -----Original Message-----****
>
> > From: Giles Heron [mailto:[email-masked]]****
>
> > Sent: Friday, September 21, 2012 9:09 PM****
>
> > To: Jiangyuanlong****
>
> > Cc: [email-masked]****
>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 24 Sep 2012 06:25:05 +0000

Yuanlong.

Lots of thanks for a prompt response and clarification.

I have always considered the CW-based proposal for E-tree as the simplest (and, by implication, the most clean) approach:

- No need to distribute the types of ACs a given PE supports (and to re-distribute it when the set of ACs is changed). It is a purely local matter

- No OAM issues

- No need to allocate special VLAN tags to mark Leaf and Root- originated traffic and to propagate these allocations - hence no problem with preservation of  C-VLANs if/when it is needed (or VLAN manipulation) etc.

Unfortunately the WG has decided to drop this approach - presumably, because it mandated the use of CW in the Ethernet PW encapsulation which is not supported by some implementations.

So now we have a good chance to end with two different solutions (one for E-VPN and one for regular VPLS), and, most probably, with some additional mechanism for their interworking...

But is probably spilled milk now.

Regards.

Sasha.

________________________________
From: Jiangyuanlong [[email-masked]]
Sent: Monday, September 24, 2012 4:22 AM
To: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi
Cc: [email-masked]
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Sasha,

>From Ali’s I-D draft-sajassi-l2vpn-evpn-etree-00, it seems two ESI MPLS labels per Ethernet segment are used for E-Tree. So one is used for root traffic and another is used for leaf traffic, just like in the 2PW approach.

Thanks,
Yuanlong

When one of such PEs receives a VPLS packet from another such PE, it must somehow identify the source AC of the Ethernet frame in this packet, and, in the case of it being a leaf AC, prevent its forwarding to the local Leaf AC(s) while allowing forwarding to local Root AC(s). This equally applies to regular VPLS and E-VPN, e.g., in the case when the contained Ethernet frame is a broadcast one (so that no learning is associated with it). And I strongly doubt this can be achieved without some “tags” in the encapsulation.

My 2c,

     Sasha

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 24 Sep 2012 07:29:14 +0000

Aldrin,

I used to believe that the same MAC based forwarding will be used in E-VPN as in VPLS, but the difference is FIB is populated with the help of BGP.
Using the terminology of VPLS, E-Tree service seems to need two VSIs (EVI in the previous email?) as you proposed rather than only a single VSI is needed for other services.
That is my take of the problem, but perhaps my understanding of your proposal is wrong:)

Thanks,
Yuanlong

From: Aldrin Isaac [mailto:[email-masked]]
Sent: Monday, September 24, 2012 12:28 PM
To: Jiangyuanlong
Cc: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi; [email-masked]
Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Hi Yuanlong,

I'm not clear as to why different forwarding contexts for root and leaf is less than good -- can you elaborate?  Also I'm not clear as to why you see that ETREE using EVPN is any different from other topologies that can be created with EVPN.  EVPN's ability to create any topology is fundamental to it.  In IPVPN we commonly create hub-and-spoke VPN with hubs and spokes in different VRF. In some cases we even overlap one or more hub-and-spoke RT pairs with one or more mesh RT.  EVPN was purposefully designed to bring this flexibility to Ethernet.

Best regards -- aldrin

Regards,
Yuanlong

From: Aldrin Isaac [mailto:[email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>]
Sent: Sunday, September 23, 2012 9:21 PM
To: Alexander Vainshtein
Cc: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi; [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>
Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

My 2c,

     Sasha

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 24 Sep 2012 07:44:30 +0000

Hi Sasha,

You are aiming 2 birds with a single stone;)
But please see my comments in line.

Thanks,
Yuanlong

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, September 24, 2012 2:25 PM
To: Jiangyuanlong; Giles Heron; Ali Sajassi
Cc: [email-masked]
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Yuanlong.

- No OAM issues

[JY] it seems neither issue is with 2VLAN, right?

[JY] It may be commensurate with the negotiation of E-Tree bit in the control word (if using CW), but save the work of redesigning a new forwarding plane;) BTW, not sure what is the problem with preservation of C-VLAN, can you give some more hints?

Regards.

Sasha.

Thanks,
Yuanlong

My 2c,

     Sasha

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 24 Sep 2012 14:32:07 +0000

+1

From: [email-masked] [mailto:[email-masked]] On Behalf Of Aldrin Isaac
Sent: Monday, September 24, 2012 12:28 AM
To: Jiangyuanlong
Cc: [email-masked]; Ali Sajassi; Himanshu Shah
Subject: Re: FW: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Hi Yuanlong,

Best regards -- aldrin

Regards,
Yuanlong

My 2c,

     Sasha

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf

> Cc: [email-masked]<mailto:[email-masked]>

> Cc: [email-masked]<mailto:[email-masked]>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 24 Sep 2012 23:41:38 +0000

Jim, Aldrin, Josh:

You guys are spot on. E-VPN solution doesn't have the limitation of
data-plane forwarding that VPLS has and as such it doesn't need addition
vlan-tag to solve root/leaf indication issue as it can be supported
inherently by the solution.

Cheers,
Ali

On 9/22/12 4:34 PM, "UTTARO, JAMES" <[email-masked]> wrote:

>Josh,
>
>	Yes.. I think that is the reality of it.. VPLS either the LDP or BGP
>variety uses data plane learning as the mechanism to "learn".. The fact
>that we extend the L2 footprint via these "tunnels" does not change that
>fact.. SO in VPLS the only hammer you have is the data plane, so one must
>manipulate bits on the wire to infer topology ( Limited set of topology
>)..
>
>EVPN is intended to use contexts and associated import/export to manage
>the topology.. So here there is a set of tools to create the desired
>topologies, along with that there other mechanisms realized i.e
>active/active...
>
>Jim Uttaro
>
>>>>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan
>>>>>-
>>>>>0
>>>>>0.txt
>>>>> Status:

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 24 Sep 2012 23:41:37 +0000

Jiangyuanlong,

Your proposal of applying vlan-tags (as done for VPLS) to E-VPN solution
is broken and doesn't work properly for E-VPN for the following reasons:

1) It breaks MPLS forwarding for egress PE - E-VPN allows for pure MPLS
forwarding at the egress PE

2) Even in scenarios where MAC lookup is used on egress PE, it creates
unnecessary overhead that is absolutely NOT needed. E-VPN multicast
packets already carries SH label (which as describe in etree-evpn draft)
is also used for root/leaf indication.

EVPN is the next gen solution which doesn't have the limitation of
existing vpls solution. It is extreemly flexible as it allows for pure
MPLS forwarding to a given AC without any MAC lookup (in either
direction). It allows for asymmetric MAC lookup operation (lookup in the
ingress PE but no lookup on the egress PE). Or it allows for lookup in
both directions. We don't want to contamiate such solution with the kludge
that we used for VPLS.

Cheers,
Ali 

On 9/21/12 7:31 PM, "Jiangyuanlong" <[email-masked]> wrote:

>couple of hands."
>to decide which way to take.
>
>Thanks,
>Yuanlong
>
>that it was better to have the same solution for VPLS and E-VPN, Ali
>stated that there was no benefit in the E-VPN case in using an additional
>tag (such as a VLAN).  No consensus was reached in the meeting.
>
>Giles
>
>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-00
>>.txt
>> Status:

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 25 Sep 2012 06:43:28 +0000

Hi Ali,

I am not sure whether "pure MPLS forwarding at the egress PE" is something we are pursuing or something true enough, but it seems to me the forwarding of EVPN is not so different from VPLS/VPWS in the description of EVPN document:

"

   Per EVI label assignment requires the least number of E-VPN labels,

   but requires a MAC lookup in addition to an MPLS lookup on an egress

   PE for forwarding. On the other hand, a unique label per <ESI,

   Ethernet Tag> or a unique label per MAC allows an egress PE to

   forward a packet that it receives from another PE, to the connected

   CE, after looking up only the MPLS labels without having to perform a

   MAC lookup. This includes the capability to perform appropriate VLAN

   ID translation on egress to the CE.

"

That is, if label per EVI is allocated, forwarding is based on MAC lookup (like VPLS), otherwise, if label per Ethernet segment or per MAC is allocated, the forwarding is like in VPWS, and VLAN translation is allowed further. Why an extra VLAN translation operation breaks?

For the 2nd question, I could not find SH label in the etree-evpn draft, were you referring to ESI MPLS label?

Thanks,

Yuanlong

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Tuesday, September 25, 2012 7:42 AM
To: Jiangyuanlong; Giles Heron
Cc: [email-masked]
Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Jiangyuanlong,

that we used for VPLS.

Cheers,

Ali

>          Not many people.  But even fewer who want multiple.  Checked to

>see if

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 25 Sep 2012 07:02:17 +0000

Hi all,

I don't think E-VPN control plane can solve all the problem of E-Tree.
For the following two scenarios data plane indication of E-Tree is needed:
1. Per EVI label is assigned, and there are multiple PEs with both Leaf AND Root sites;
2. Per <ESI, Ethernet Tag> label is assigned, and there are multiple Ethernet segments with both Leaf AND Root sites;
Using 2 labels (EVI MPLS label or ESI MPLS label respectively) is an option, but maybe OAM is a challenge.

Assigning label per MAC for E-Tree will not need this indication, but at expense of scalability.

Regards,
Yuanlong

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
Sent: Tuesday, September 25, 2012 7:42 AM
To: UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron
Cc: [email-masked]; Jiangyuanlong
Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Jim, Aldrin, Josh:

Cheers,
Ali

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 25 Sep 2012 08:08:45 +0000

Ali,
Sorry for a naive question - but your response seems to imply that E-VPN uses a separate application label per DMAC per VSI per remote PE (similar to the what BGP/MPLS VPN can do in one of its flavors where application label is allocated and distributed for each locally reachable prefix).

This would be indeed very different from VPLS where (regardless of the label distribution method) uses one application label per VSI per remote peer.

If this is the case, you indeed need any tagging to support E-Tree. 
But you can easily run into scalability problems (what if you need more than 1M of MACs?) not to mention OAM problems.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Ali Sajassi (sajassi) [[email-masked]]
Sent: Tuesday, September 25, 2012 1:41 AM
To: UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron
Cc: [email-masked]; Jiangyuanlong
Subject: Re: New Version Notification for       draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Jim, Aldrin, Josh:

Cheers,
Ali

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 26 Sep 2012 05:55:14 +0000

Hi Yuanlong,

MPLS forwarding is one of the forwarding mode in E-VPN that cannot be compromised. I would highly suggest that you read E-VPN drat again before making any suggestions. The reasons that I gave you previously regarding why the use of vlan-tag doesn't make sense for E-VPN still holds and if needed I can go over the E-VPN solution the next time we meet. But I won't be able to provide a tutorial over the email. As I mentioned before the E-VPN forwarding plane already supports E-TREE without any changes to the forwarding behavior. And changing the E-VPN forwarding behavior to do something that it already supports, doesn't make any sense. But you have heard that from multiple people already.

Cheers,
Ali

From: Jiangyuanlong <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 24, 2012 11:43 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, Giles Heron <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Hi Ali,

I am not sure whether "pure MPLS forwarding at the egress PE” is something we are pursuing or something true enough, but it seems to me the forwarding of EVPN is not so different from VPLS/VPWS in the description of EVPN document:

"

"

Thanks,

Yuanlong

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Tuesday, September 25, 2012 7:42 AM
To: Jiangyuanlong; Giles Heron
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Jiangyuanlong,

that we used for VPLS.

Cheers,

Ali

>On 21 Sep 2012, at 10:16, Jiangyuanlong <[email-masked]<mailto:[email-masked]>> wrote:

>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 26 Sep 2012 06:14:31 +0000

Hi Yuanlong, 

If one understood the operation of SH filtering in E-VPN, he would have
seen that it exactly covers both of these cases that are mentioned below.

Also, E-VPN allows for policy-based forwarding on a per MAC basis without
scale issue. As I said previously, I won't be able to provide E-VPN
tutorial over the email.

Cheers,
Ali

On 9/25/12 12:02 AM, "Jiangyuanlong" <[email-masked]> wrote:

>2. Per <ESI, Ethernet Tag> label is assigned, and there are multiple
>Ethernet segments with both Leaf AND Root sites;
>>>Of
>>>Rogers, Josh

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 26 Sep 2012 06:28:25 +0000

Hi Alex,

E-VPN operation is very similar to IP-VPN and it can basically support the
modes that are in IP-VPN; however, for E-TREE we don't need to use such
modes and we don't need to assign label per prefix (MAC in here) since
E-VPN uses the notion of a label per site (per ESI) for its SH filtering.
And for E-TREE we simply color the site (ESI) with two labels (one to
indicate root and another to indicate leaf) and we basically use the same
SH filtering logic here.

Cheers,
Ali

On 9/25/12 1:08 AM, "Alexander Vainshtein"
<[email-masked]> wrote:

>Ali,
>Sorry for a naive question - but your response seems to imply that E-VPN
>uses a separate application label per DMAC per VSI per remote PE (similar
>to the what BGP/MPLS VPN can do in one of its flavors where application
>label is allocated and distributed for each locally reachable prefix).
>
>This would be indeed very different from VPLS where (regardless of the
>label distribution method) uses one application label per VSI per remote
>peer.
>
>But you can easily run into scalability problems (what if you need more
>than 1M of MACs?) not to mention OAM problems.
>
>
>
>Telecom. If you have received this transmission in error, please inform
>us by e-mail, phone or fax, and then delete the original and all copies
>thereof.
>

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 26 Sep 2012 09:31:00 +0000

Ali,

On the one hand, you said E-VPN solution doesn't have the limitation of data-plane forwarding and inherently support E-Tree, on the other hand, you agreed that 2 labels are introduced specially for E-Tree for these two cases. Furthermore, forwarding behaviors for these two labels are different (for root label, split horizon + forward to both root & leaf ports; for leaf label, split horizon + forward only to leaf ports) from the E-VPN itself (split horizon only).
But my main concern is whether OAM is needed for E-VPN, if yes, how it can be implemented in practical?

Regards,
Yuanlong

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
Sent: Wednesday, September 26, 2012 2:15 PM
To: Jiangyuanlong; UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron
Cc: [email-masked]
Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Hi Yuanlong, 

Cheers,
Ali

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 26 Sep 2012 14:45:11 +0000

Yuanlong, Ali, and all,

I think that we have really 3 aspects of E-Tree that should be explicitly presented for each solution approach:

1. Change of the PE Type:
    - Root-only to Mixed and vice versa
    - Leaf-only to Mixed and vice versa
    - Root-only to Leaf-only and vice versa
2. OAM - how it is supposed to work and how the defects it detects are handled.
    This becomes non-trivial in the 2PW solution and its analogs if one of the two PWsfails IMHO
3. Interworking with Ethernet-only E-Tree.

My 2c,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] on behalf of Jiangyuanlong [[email-masked]]
Sent: Wednesday, September 26, 2012 11:31 AM
To: Ali Sajassi (sajassi); UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron
Cc: [email-masked]
Subject: RE: New Version Notification for       draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Ali,

Regards,
Yuanlong

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Wednesday, September 26, 2012 2:15 PM
To: Jiangyuanlong; UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron
Cc: [email-masked]
Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Hi Yuanlong,

Cheers,
Ali

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 27 Sep 2012 18:39:53 +0000

Sigh! 

When split-horizon label is used in E-VPN, the stack consists of three
labels (tunnel label,vpn label, and SH label). For E-TREE application, the
same three labels are used and the SH label is used for SH filtering
and/or root/leaf filtering.

In E-VPN, the SH label is used for filtering of packets on the egress
interface of the egress PE based on the site of origin. In E-TREE
application, we use SH label for exactly the same purpose - filtering on
the egress interface of the egress PE based on the site of origin (that
can also represent  leaf/root).

That is why I have been saying in every email on this thread that the
forwarding behavior of the E-VPN remains unchanged and that's why it
doesn't make sense to add vlan-tag kluge (and as the result change the
forwarding behavior) for something that is already supported.

Regarding OAM aspects, we have always treated OAM work independently and
we don't want to tie it with a single application of E-VPN. E-VPN has many
applications such as VPLS, VPWS, E-TREE, DCI, DCN/cloud and the OAM MUST
apply to all of them. We have started on OAM work for E-VPN and one draft
was published before last IETF meeting and more will be coming; however,
E-VPN OAM work will be done independent.

Cheers,
Ali   

On 9/26/12 2:31 AM, "Jiangyuanlong" <[email-masked]> wrote:

>Ali,
>
>On the one hand, you said E-VPN solution doesn't have the limitation of
>data-plane forwarding and inherently support E-Tree, on the other hand,
>you agreed that 2 labels are introduced specially for E-Tree for these
>two cases. Furthermore, forwarding behaviors for these two labels are
>different (for root label, split horizon + forward to both root & leaf
>ports; for leaf label, split horizon + forward only to leaf ports) from
>the E-VPN itself (split horizon only).
>>>>>>> This I-D probes how the 2VLAN approach can be used to support
>>>>>>>E-Tree
>>>>>>>in E-VPN and it seems not a big issue.
>>>>>>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vl
>>>>>>>a
>>>>>>>n
>>>>>>>-
>>>>>>>0
>>>>>>>0.txt
>>>>>>> Status:

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 27 Sep 2012 18:45:51 +0000

Sasha,

There is no notion of PWs E-VPN. E-VPN operation is analogous to IP-VPN.
Regarding the OAM aspects, the work has already started and it will be
covered separately. Since E-VPN covers many applications such as VPLS,
VPWS, E-TREE/VPMS, DCI, DCN/cloud, its corresponding OAM MUST cover all
these applications well.

Cheers,
Ali

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 27 Sep 2012 18:49:00 +0000

That is another benefit of E-VPN that is overlooked.. The fact that the transport across the core is the same as in L3VPN is very desirable from a consistency point of view across all of our services..

Jim Uttaro

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
Sent: Thursday, September 27, 2012 2:46 PM
To: Alexander Vainshtein; Jiangyuanlong; UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron
Cc: [email-masked]
Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Sasha,

Cheers,
Ali

---

From: Jiangyuanlong <[email-masked]>
Date: Sat, 29 Sep 2012 08:01:02 +0000

Ali,

Thank you for the reply, I got your idea. Maybe "split-horizon label" can be clearly defined in the next version of E-VPN draft, so that it can be understood better.
Especially how it is constructed for E-Tree service.
 
Regards,
Yuanlong

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
Sent: Friday, September 28, 2012 2:40 AM
To: Jiangyuanlong; UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron
Cc: [email-masked]
Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Sigh! 

Cheers,
Ali