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

[Jiangyuanlong <[e-mail]>]

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:[e-mail]] 
Sent: Friday, September 28, 2012 2:40 AM
To: Jiangyuanlong; UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron
Cc: [e-mail]
Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt


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" <[e-mail]> 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).
>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:[e-mail]]
>Sent: Wednesday, September 26, 2012 2:15 PM
>To: Jiangyuanlong; UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles
>Heron
>Cc: [e-mail]
>Subject: Re: New Version Notification for
>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
>
>
>
>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" <[e-mail]> wrote:
>
>>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:[e-mail]]
>>Sent: Tuesday, September 25, 2012 7:42 AM
>>To: UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron
>>Cc: [e-mail]; Jiangyuanlong
>>Subject: Re: New Version Notification for
>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
>>
>>
>>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" <[e-mail]> 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
>>>)..
>>>
>>>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: [e-mail] [mailto:[e-mail]] On Behalf
>>>Of
>>>Rogers, Josh
>>>Sent: Saturday, September 22, 2012 7:03 PM
>>>To: UTTARO, JAMES; Aldrin Isaac; Giles Heron
>>>Cc: [e-mail]; Jiangyuanlong
>>>Subject: Re: New Version Notification for
>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
>>>
>>>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" <[e-mail]> 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
>>>>
>>>>-----Original Message-----
>>>>From: [e-mail] [mailto:[e-mail]] On Behalf
>>>>Of
>>>>Rogers, Josh
>>>>Sent: Saturday, September 22, 2012 12:49 PM
>>>>To: Aldrin Isaac; Giles Heron
>>>>Cc: [e-mail]; Jiangyuanlong
>>>>Subject: Re: New Version Notification for
>>>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
>>>>
>>>>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" <[e-mail]> 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.
>>>>>
>>>>>
>>>>>
>>>>>On Sep 21, 2012, at 9:09 AM, Giles Heron wrote:
>>>>>
>>>>>> 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]>
>>>>>>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]]
>>>>>>> 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-2vl
>>>>>>>a
>>>>>>>n
>>>>>>>-
>>>>>>>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 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 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.
>>>
>>>
>>>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.
>>
>