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

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 24 Sep 2012 08:12:45 +0000

Yuanlong hi!
Lots of thanks for a prompt response.
Please see some responses in line below.

Regards,
     Sasha

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

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.

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

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

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

[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?

[[[Sasha]]] You do not really have to negotiate usage of the Leaf  flag in the CW. At most you have to negotiate usage of the CW, which is well defined (including the latest standard for changes in the preferred CW usage:-). And you would locally configure your VPLS instance to be an E-Tree on and hence setting the Leaf flag on Tx to peers and respecting the value of this flag received from your peers. A regular VPLS instance (equivalent to Root only) would never set this flag on Tx and ignore it on Rx - so you would have complete backward compatibility at no cost.

As for the new forwarding plane: IMHO you need some modifications in the forwarding plane to mark Leaf-originated traffic on Tx and to block Leaf-to-Leaf traffic regardless of how you identify it. I do not see how you can avoid it taking into account that E-Tree forwarding behavior is different from a plain old Layer 2 switch.

Regarding preservation of C-VLANs - would you not need to push the Root/Leaf VLAN tag on top of the C-tag you are going to preserve? This may result in backward compatibility issues when you have Root-only PEs that now have to be aware of these additional VLAN tags (push them on Tx and pop them on Rx).

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

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

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

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

> 00.txt

> 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

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

> wrote:

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

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

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.

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.

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 11:38:39 +0000

Hi Sasha,

Just snips of it:

[JY] Yes, you are right that only CW negotiation is needed. Though I am not sure if a PE has no capability of CW support, how can this approach be backward compatible?

[JY] Consider the access may well be an Ethernet network, 2VLAN should be supported there or in the bridge module, thus there is no need to introduce new forwarding paradigms in the VSI.

For the same reason, if CW solution is adopted, except the new modifications in VSI, 2VLAN may still be needed on the bridge module side.

[JY] That is not the case. You can have a look at Section 5.3.2 of draft-ietf-l2vpn-vpls-pe-etree-00, it says raw PW should be used, thus no root or leaf VLAN tag is needed on the PW.

Thanks,

Yuanlong

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, September 24, 2012 4:13 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 hi!

Regards,
     Sasha

Hi Sasha,

Thanks,
Yuanlong

Yuanlong.

- No OAM issues

Regards.

Sasha.

Thanks,
Yuanlong

My 2c,

     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 24 Sep 2012 12:07:34 +0000

Hi Yuanlong,

Please see some answers inline below (bold magenta italics).

Regards,

     Sasha

Sent: Monday, September 24, 2012 1:38 PM

Hi Sasha,

Just snips of it:

[[[Sasha]]] You do not really have to negotiate usage of the Leaf  flag in the CW. At most you have to negotiate usage of the CW, which is well defined (including the latest standard for changes in the preferred CW usage:-). And you would locally configure your VPLS instance to be an E-Tree on and hence setting the Leaf flag on Tx to peers and respecting the value of this flag received from your peers. A regular VPLS instance (equivalent to Root only) would never set this flag on Tx and ignore it on Rx – so you would have complete backward compatibility at no cost.

[[Sasha]] If PE does not support the CW, it can only act as a Root-only PE, and treated as scuh by its peers. (I assume that a given PE either supports CW vs. any peer, or does not support CW at all, so there should not be any contradiction.)

[[Sasha]] I see it a bit differently: if your access is Ethernet, you need two ACs between your PE and its adjacent access device, one for Root and one for Leaf. No need to involve the bridge module of the PE into access behavior, especially if you want to run xSTP in your access network IMO.

Regarding preservation of C-VLANs – would you not need to push the Root/Leaf VLAN tag on top of the C-tag you are going to preserve? This may result in backward compatibility issues when you have Root-only PEs that now have to be aware of these additional VLAN tags (push them on Tx and pop them on Rx).

[[Sasha]] I am not sure I understand, will look up the draft and respond.

Thanks,

Yuanlong

Yuanlong hi!

Regards,
     Sasha

Hi Sasha,

Thanks,
Yuanlong

Yuanlong.

- No OAM issues

[[[Sasha]]] You do not really have to negotiate usage of the Leaf  flag in the CW. At most you have to negotiate usage of the CW, which is well defined (including the latest standard for changes in the preferred CW usage:-). And you would locally configure your VPLS instance to be an E-Tree on and hence setting the Leaf flag on Tx to peers and respecting the value of this flag received from your peers. A regular VPLS instance (equivalent to Root only) would never set this flag on Tx and ignore it on Rx – so you would have complete backward compatibility at no cost.

Regarding preservation of C-VLANs – would you not need to push the Root/Leaf VLAN tag on top of the C-tag you are going to preserve? This may result in backward compatibility issues when you have Root-only PEs that now have to be aware of these additional VLAN tags (push them on Tx and pop them on Rx).

Regards.

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 12:36:41 +0000

Hi Sasha,

Just snips of it:

[JY] The group have discussed quite a lot in the last few months around the scenarios of E-Tree and I don't think it is that simple (except in a pure MPLS network of course). BTW, Appendix of draft-ietf-l2vpn-vpls-pe-etree-00 have a brief discussion on the support of them. Just as an example, how can H-VPLS with QinQ spoke be supported? How can E-NNI be supported?

Thanks,

Yuanlong

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 24 Sep 2012 14:09:58 +0000

Yuanlong,

I did not perform complete analysis of all the interworking MPLS vs. Ethernet network) cases for E-Tree.

My gut feeling is that it can be always reduced to the trivial case of two ACs between a VPLS PE and its adjacent Ethernet network PE (which is a CE from the VPLS point of view), these ACs being represented either as two VLANs on the same port or by two C-VLANs in the QinQ case (with the same S-VLAN). I am aware3 of some VPLS implementations that can treat any given pair of VLAN tags (for QinQ) as a separate AC, not sure how common this functionality is. The Ethernet side may be more problematic. E.g., it is not quite clear to me what are the expectations of the Ethernet edge device in your example of QinQ  for H-VPLS in order to support E-Tree; nor am I sure that IEEE has a ready answer for that.

Do I miss something?

Regards,
     Sasha

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

Hi Sasha,

Just snips of it:

Thanks,

Yuanlong

---

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

Sasha,

As the co-author of vlan-tag solution for VPLS, I must admit that I sympathize with your concern regarding vlan-tag solution; however, among the three proposals (vlan-tags, control word, and PWs), IMO, vlan-tag is less of an evil (although it is subjective :-). As you mention, we need to modify data-forwarding behavior regardless of which of these three models we go with and all three models break the model described in bridge-interop RFC.

With E-VPN, the ETREE service can inherently be supported with the existing forwarding model without introducing any new mechanism !! And that's why it doesn't make sense to add any other mechanism on top of E-VPN.

As the co-author of vlan-tag solution for VPLS, I think this drat needs cleaning and we will do that in subsequent revisions.

Cheers,
Ali

From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 24, 2012 1:12 AM
To: Jiangyuanlong <[email-masked]<mailto:[email-masked]>>, Giles Heron <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[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

Yuanlong hi!

Regards,
     Sasha

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

Hi Sasha,

Thanks,
Yuanlong

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

Yuanlong.

- No OAM issues

Regards.

Sasha.

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

Thanks,
Yuanlong

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

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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]