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

["Ali Sajassi (sajassi)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>>
Date: Monday, September 24, 2012 1:12 AM
To: Jiangyuanlong <[e-mail]<mailto:[e-mail]>>, Giles Heron <[e-mail]<mailto:[e-mail]>>, Cisco Employee <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

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

Regards,
     Sasha

From: Jiangyuanlong [mailto:[e-mail]]
Sent: Monday, September 24, 2012 9:44 AM
To: Alexander Vainshtein; Giles Heron; Ali Sajassi
Cc: [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Monday, September 24, 2012 2:25 PM
To: Jiangyuanlong; Giles Heron; Ali Sajassi
Cc: [e-mail]<mailto:[e-mail]>
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 [[e-mail]<mailto:[e-mail]>]
Sent: Monday, September 24, 2012 4:22 AM
To: Alexander Vainshtein; Giles Heron; Himanshu Shah; Ali Sajassi
Cc: [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Sunday, September 23, 2012 4:25 PM
To: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi
Cc: [e-mail]<mailto:[e-mail]>
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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf

> Of Jiangyuanlong

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

> To: Giles Heron

> Cc: [e-mail]<mailto:[e-mail]>

> 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:[e-mail]]

> Sent: Friday, September 21, 2012 9:09 PM

> To: Jiangyuanlong

> Cc: [e-mail]<mailto:[e-mail]>

> 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 <[e-mail]<mailto:[e-mail]>>

> 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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]

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