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

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

Yuanlong,

You're welcome. In the next rev of evpn-etree draft I will add additional
text to describe why forwarding behavior of evpn remains intact when doing
E-TREE (e.g., by using the same ESI label).

Cheers,
Ali

On 9/29/12 1:01 AM, "Jiangyuanlong" <[e-mail]> wrote:

>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-2v
>>>>>>>>l
>>>>>>>>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.
>>>
>>
>