Subject: RE: L2vpn Digest, Vol 96, Issue 18

From: "Sam Cao" <[email-masked]>
Date: Sat, 5 May 2012 12:11:23 +0800

I guess the following case is what Josh mentioned,

PE1 has Root AC and Leaf AC, but PE2 has leaf-AC only. Both methods should
setup PW between PE1 and PE2. So one unknown or broadcast frame originated
from Leaf AC on PE1 will be forwarded to PE2, but this is really not
necessary. 

Sam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Saturday, May 05, 2012 8:21 AM
To: [email-masked]
Subject: L2vpn Digest, Vol 96, Issue 18

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/l2vpn

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send L2vpn mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/l2vpn
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of L2vpn digest..."

Today's Topics:

   1. RE: The status of the approaches to the E-Tree solution?
      (Lucy yong)
   2. Re: Interest in IS-IS VPLS (Aldrin Isaac)

----------------------------------------------------------------------

Message: 1
Date: Fri, 4 May 2012 20:42:21 +0000
From: Lucy yong <[email-masked]>
To: "Rogers, Josh" <[email-masked]>, Jiangyuanlong
	<[email-masked]>, Daniel Cohn <[email-masked]>,
"Fedyk,
	Donald (Don)" <[email-masked]>, "Henderickx, Wim
	(Wim)"	<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: The status of the approaches to the E-Tree solution?
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D330E933A@dfweml505-mbx>
Content-Type: text/plain; charset="iso-8859-2"

Hi Josh,

I don't understand your following statement.

- Both methods have inefficiencies (one duplicates traffic for transport,
while the other transports where it doesn't need to go).  

Both method allows the optimization to avoid transporting where it doesn't
need to go.

Regards,
Lucy

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Friday, May 04, 2012 7:27 AM
To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim);
Lucy yong
Cc: [email-masked]
Subject: Re: The status of the approaches to the E-Tree solution?

[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can
also separate the leaf traffic in the ingress PE and filter it there
(already detailed in the Optimization Mode in the I-D); if the egress PE
is attached with pure roots or with both roots and leafs, it seems all
traffic must be transported to the egress PE and be filtered there, I see
no difference in behaviour for these solutions. Or did I miss something?

The point is with the multi-PW method the traffic is split/separated (by
psuedowire) on the ingress PE, rather than the egress.  The distinction is
2VLAN will 'classify' the frame on the ingress PE, so that the egress PE
knows how to forward it to the appropriate AC's.

Both methods have inefficiencies (one duplicates traffic for transport,
while the other transports where it doesn't need to go).  I like the idea
of classify and forwarding on the ingress PE, rather than marking it on
the ingress, and deciding on the egress.

-Josh

On 5/3/12 8:20 PM, "Jiangyuanlong" <[email-masked]> wrote:

>Josh, thank you for the comments, please see my further comments with
>[JY2].
>
>-----Original Message-----
>From: Rogers, Josh [mailto:[email-masked]]
>Sent: Thursday, May 03, 2012 11:27 PM
>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim
>(Wim); Lucy yong
>Cc: [email-masked]
>Subject: Re: The status of the approaches to the E-Tree solution?
>
>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service
>requirements from MEF, it has nothing to do with the solutions. Could you
>give a hint on how you can provision this service E-NNI otherwise? BTW, if
>configuring or signalling two PWs is not a problem, why configuring or
>signalling two VLANs will become a problem? After all, more nodes may need
>to be configured or signalled for 2PW (T-PEs and S-PEs) compared with
>2VLAN (only T-PEs).
>
>
>There is no other way (if both MPLS domains are part of the same ETREE,
>rather than doing something more like H-VPLS, where one domain has point
>to points to the other domain which handles the ETREE instance) if you are
>using an ENNI.  The other method, (not mentioned earlier) is tying the two
>MPLS domains together via labeled unicast (much preferred over E-NNI in my
>opinion)
>
>Configuring two VLAN's isn't really a 'problem' any more than two PW's.  I
>wasn't saying that configuring two VLAN's was difficult, I was objecting
>to the statement that configuring two PW's is difficult.
>
>[JY2] Thanks, I see your point. I take the example of 2PW configuration
>just to show that using fixed global values to simplify configuration
>makes no sense. Personally I also don't think configuration is a problem
>for both solutions.
>
>I find the differences between these two methods rather slight.  The
>'tie-breaker' for me is by placing the forwarding decision on the ingress
>PE (as with multi-PW) rather than the egress PE (as with 2VLAN), you get
>more control over where the traffic goes, and in my mind it provides a
>cleaner destination between customer traffic and forwarding plane.  I'm
>accustomed to looking at a psuedowire and knowing where its going, with
>the 2vlan method, I can see the psuedowire, but must go to the egress PE
>to see if it will be dropped there, or forwarded to one or more AC's.
>
>[JY2] if the egress PE is attached with pure leafs, 2VLAN approach can
>also separate the leaf traffic in the ingress PE and filter it there
>(already detailed in the Optimization Mode in the I-D); if the egress PE
>is attached with pure roots or with both roots and leafs, it seems all
>traffic must be transported to the egress PE and be filtered there, I see
>no difference in behaviour for these solutions. Or did I miss something?
>
>Again, the difference here is slight, and I would honestly be happy to see
>either of them come to fruition.  Please don't infer that I think the
>2vlan method is 'bad' or has intrinsic problems, because I don't believe
>that.   I just prefer the multi-PW method.
>
>
>-Josh
>
>
>On 5/3/12 12:07 AM, "Jiangyuanlong" <[email-masked]> wrote:
>
>>Josh, please see my comments in line.
>>
>>Thanks
>>Yuanlong
>>
>>-----Original Message-----
>>From: Rogers, Josh [mailto:[email-masked]]
>>Sent: Thursday, May 03, 2012 10:51 AM
>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim
>>(Wim); Lucy yong
>>Cc: [email-masked]
>>Subject: Re: The status of the approaches to the E-Tree solution?
>>
>>Yuanlong,
>>
>>Or better yet, include in the draft a 'standard' value for root sourced
>>VID and leaf sourced VID.  i.e., 4093=root, 4094=leaf.  You would also
>>have to require the the implementation NOT use global VLAN's, however
>>(since each instance would be using the same values).  In this way, no
>>signaling or manual configuration is required for remote PE's to know how
>>to classify traffic.
>>[JY] Indeed, we discussed this possibility during the f2f meeting in
>>Paris. But, there are some restrictions as you mentioned, and
>>furthermore:
>>1) Some vendors already used S-VLAN to distinguish their VSIs in the PE;
>>2) Forwarding plane of a PE needs to be revised to be aware of this VLAN
>>ID.
>>Therefore, this 'standard value' approach seems more disruptive compared
>>with the other means and not a good candidate option.
>>
>>Regarding switching PE's?  Multi-PW means more than one PW, yes.  I don't
>>see this as a real problem.  In general, design should try and avoid
>>using
>>S-PE's, but if you must, its going to mean extra work, no matter how you
>>look at it.  Two PW's for each Etree being switched instead of one is not
>>alarming or concerning to me.  On the other hand, if you use a dot1q
>>(E-NNI) between MPLS domains, you have to deal with two ingress VLAN's an
>>two egress VLAN's if you want the Etree to be handled on both sides (and
>>if you use the 'standard' VID's as I mentioned above, you'd have to do
>>mapping to non-standard and back)
>>[JY] Configuring two S-VLANs for an E-Tree E-NNI is one of the service
>>requirements from MEF, it has nothing to do with the solutions. Could you
>>give a hint on how you can provision this service E-NNI otherwise? BTW,
>>if configuring or signalling two PWs is not a problem, why configuring or
>>signalling two VLANs will become a problem? After all, more nodes may
>>need to be configured or signalled for 2PW (T-PEs and S-PEs) compared
>>with 2VLAN (only T-PEs).
>>
>>In general, I still prefer multi-PW, primarily because I prefer the
>>separation of the traffic in the network's forwarding plane, rather than
>>shipping it everywhere and deciding whether to forward to the AC when it
>>gets to the egress PE.  I'm having a hard time putting my finger exactly
>>on what it is, or articulating the idea, but it seems that by having the
>>traffic placed into two psuedowires, I have more flexibility and ease of
>>configuration when it comes to E-NNI's, service multiplexed UNI's, and
>>H-VPLS (both psuedowire based and vlan based).    Of course my 'ease of
>>configuration' statement assumes BGP-VPLS, as was pointed out earlier
>>LDP-VPLS w/out AD and/or some sort of signaling to handle the setup of
>>PW's could really change that perception.
>>[JY] Are you saying that we need to develop a totally new forwarding
>>plane rather than using the Ethernet forwarding plane as described in the
>>existing work?
>>
>>I hope we can move forward with one of these soon,
>>[JY] me too.
>>
>>Josh
>>
>>
>>On 5/2/12 9:30 PM, "Jiangyuanlong" <[email-masked]> wrote:
>>
>>>Daniel,
>>>
>>>Not aware that we had a discussion on this before, but IMHO the
>>>allocation of internal S-VLAN can be automatic, and manuel configuration
>>>of this mapping may not be needed at all. For example, an S-VLAN
>>>allocation module in the management plane in a PE can do this kind of
>>>job, allocating two internal S-VLAN IDs for a E-Tree service (with a
>>>single external S-VLAN ID) in a topdown, bottom-up, or just any random
>>>way from a free S-VLAN ID pool. Once the interal S-VLANs are allocated,
>>>the mapping is determined and no other configuration is needed.
>>>
>>>The only difference from RFC 6246 is, for E-LAN, we only need to
>>>allocate
>>>a single S-VLAN in the VPLS domain, but for E-Tree, we need to allocate
>>>two S-VLANs in the VPLS domain.
>>>
>>>On the other hand, for the multi-PW approach, two PWs need to be
>>>configured for a E-Tree service. When MS-PW is used in the network, for
>>>every S-PE, we need to configure two ingress PW segments and two egress
>>>PW segments. In this case, I don't think we need to use fixed PW labels
>>>across the network for fear of configuration complexity.
>>>
>>>Regards,
>>>Yuanlong
>>>
>>>-----Original Message-----
>>>From: Daniel Cohn [mailto:[email-masked]]
>>>Sent: Wednesday, May 02, 2012 8:01 PM
>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy
>>>yong;
>>>[email-masked]
>>>Cc: [email-masked]
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Inline.
>>>
>>>-----Original Message-----
>>>From: Jiangyuanlong [mailto:[email-masked]]
>>>Sent: Wednesday, May 02, 2012 12:30 PM
>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong;
>>>[email-masked]
>>>Cc: [email-masked]
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Hi Daniel, Please see my comments in line.
>>>
>>>
>>>-----Original Message-----
>>>From: Daniel Cohn [mailto:[email-masked]]
>>>Sent: Wednesday, May 02, 2012 3:55 PM
>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy
>>>yong; [email-masked]
>>>Cc: [email-masked]
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Hi Yuanlong,
>>>
>>>The problem is not with the total number of S-VLAN IDs, I agree that
>>>normally there won't be more than 2047. The problem is that if you don't
>>>support all VLAN IDs, you need S-VLAN space coordination with the
>>>providers, e.g. "I can only transparently preserve S-VLAN ID 1 to 2047".
>>>Which won't always be in line with an existing deployment.
>>>[JY] This is not the case. If the total number is no more than 2047, it
>>>surely can be supported. The S-VLAN space of user domain is totally
>>>different from the S-VLAN in the provider domain and they can be
>>>overlapped, I don't see why we need S-VLAN space coordination between
>>>them.
>>>
>>>[DC] If we use global S-VIDs in the VPLS (to simply mapping
>>>provisioning), then the IEEE S-VID to VPLS S-VID mapping should be
>>>fixed, and therefore the IEEE S-VID that can be supported is also fixed.
>>>
>>>Of course you can configure the mapping in each PE according to operator
>>>requirements but as we discussed before this increases complexity.
>>>
>>>Relying on PBB-VPLS imposes additional limitations on backward
>>>compatibility.
>>>[JY] If the SPs really have to support so many S-VLANs in a E-Tree, I
>>>think they may well need MAC-in-MAC in their networks for the
>>>scalability issue. As you know, only PBB VPLS can provide both.
>>>
>>>Daniel
>>>
>>>-----Original Message-----
>>>From: Jiangyuanlong [mailto:[email-masked]]
>>>Sent: Wednesday, May 02, 2012 5:07 AM
>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong;
>>>[email-masked]
>>>Cc: [email-masked]
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Hi Daniel,
>>>
>>>As you can see, both cases are discussed in the I-D.
>>>
>>>With regard to case 1) (that is, S-VLAN translation), since the access
>>>VLAN and the E-Tree attributes (root/leaf) are services' attributes,
>>>they need to be configured on a PE anyway, and as the past emails by
>>>Lucy, Don and Wim indicated, the access S-VLAN can be recovered by 1:1
>>>mapping.
>>>
>>>With regard to S-VID space reduction, the constraint is valid only when
>>>a global VLAN space is used per PE, in fact, multi-VLAN space is more
>>>typical and with no such limits as we already discussed in the f2f
>>>meeting.
>>>
>>>Even if there are 4094 S-VLANs in a single E-Tree access as you
>>>described (not sure this is a valid use case in real life), PBB-VPLS can
>>>still be used.
>>>
>>>Regards,
>>>Yuanlong
>>>
>>>-----Original Message-----
>>>From: Daniel Cohn [mailto:[email-masked]]
>>>Sent: Monday, April 30, 2012 10:34 PM
>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong;
>>>Jiangyuanlong; [email-masked]
>>>Cc: [email-masked]
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Hi Don,
>>>
>>>I was referring all the time to case 1). And Wim's e-mail clarified the
>>>mapping solution when he wrote that the S-VID space is reduced in half.
>>>Which confirms that S-VID preservation in the 2-VLAN solution is only
>>>supported with additional requirements - either constraining the S-VIDs
>>>supported to a reduced subset, or by using PBB (not sure I understand
>>>how PBB overcomes the previous limitation but let's leave it for another
>>>thread).
>>>
>>>Thanks,
>>>
>>>DC
>>>
>>>-----Original Message-----
>>>From: Fedyk, Donald (Don) [mailto:[email-masked]]
>>>Sent: Monday, April 30, 2012 5:21 PM
>>>To: Henderickx, Wim (Wim); Daniel Cohn; [email-masked]';
>>>[email-masked]'; [email-masked]'
>>>Cc: [email-masked]'
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Hi Dan
>>>
>>>Let me try to explain.
>>>I think you are mixing the case 1) where there is a single core Etree
>>>and multiple S-VLANs multiplex on that tree with the case 2) where there
>>>are multiple core E-Trees one per S-VLAN.
>>>
>>>In case 1) You need to encapsulate. You encapsulate based on local
>>>context of Root or Leaf.  The Core Etree though is the superset of the
>>>all the multiplexed E-Trees and would need to push on Ingress (in some
>>>form) the S-VID and Pop on egress (in some form) the S-VID. You can use
>>>a single Root S-VID(or other encapsulation ) and Single Leaf S-VID (or
>>>other encapsulation ) in the core.
>>>
>>>In case 2) You have a dedicated E-Tree per S-VLAN. On Ingress you
>>>translate based on local context of root or leaf but the mapping is 1:1
>>>and on egress you translate back with 1:1. There are multiple S-VIDs per
>>>leaf and root as Wim points out the S-VID space is halved.
>>>
>>>Both cases use local service context to determine root /leaf behavior.
>>>The frame format differs in the two cases. (Data overhead varies)
>>>But the biggest difference in the two cases is whether or not you can
>>>prune the encapsulated tree within the core or only on the edge.  If the
>>>core is transparent (can't internally prune) then the dedicated Etree
>>>case 2) is more efficient.  If the core can do some form of DPI or other
>>>then Case 1 can also be data efficient.
>>>By data efficient I mean not sending frames to Edges only to be dumped.
>>>This matters because root to leaf data is often multicast.
>>>
>>>In the IEEE the S-VLAN and PBB forms are both case 2)  1:1 mapping on
>>>the edge (S-VID <-> S-VID(Root/Leaf) or S-VID<->I-SID (Root/Leaf)) from
>>>a service perspective.  But PBB case also encapsulates with an outer
>>>single B-VLAN and in certain implementations can be made to be data
>>>efficient (for example with SPB).
>>>
>>>Hope that clears it up,
>>>Don
>>>
>>>-----Original Message-----
>>>From: Henderickx, Wim (Wim)
>>>Sent: Monday, April 30, 2012 8:54 AM
>>>To: [email-masked]'; [email-masked]';
>>>[email-masked]'; Fedyk, Donald (Don);
>>>[email-masked]'
>>>Cc: [email-masked]'
>>>Subject: Re: The status of the approaches to the E-Tree solution?
>>>
>>>The procedure halfs the s-vid space since you need 1 for root and one
>>>for leaf. If this is not enough pbb solves the issue. This is how ieee
>>>proposes this to work afaik.
>>>
>>>Cheers,
>>>Wim
>>>_________________
>>>sent from blackberry
>>>
>>>----- Original Message -----
>>>From: Daniel Cohn [mailto:[email-masked]]
>>>Sent: Monday, April 30, 2012 02:51 PM
>>>To: Henderickx, Wim (Wim); Lucy yong <[email-masked]>;
>>>Jiangyuanlong <[email-masked]>; Fedyk, Donald (Don); Rogers,
>>>Josh <[email-masked]>
>>>Cc: [email-masked] <[email-masked]>
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Can you explain this 1:1 relationship? Assuming any S-VID value can be
>>>received at any root or leaf AC, the S-VID that replaces it at the
>>>ingress PE must be such that the egress PE can recover the original
>>>S-VID plus the root/leaf ingress AC attribute. I don't see how this can
>>>be accomplished with the same number of bits.
>>>
>>>IOW, there needs to be a 1:1 mapping between 4094 S-VIDs in the root AC
>>>plus 4094 S-VIDs in a leaf AC to 4094 internal S-VIDs. I don't see how
>>>that is accomplished.
>>>
>>>What am I missing here?
>>>
>>>DC
>>>
>>>-----Original Message-----
>>>From: Henderickx, Wim (Wim) [mailto:[email-masked]]
>>>Sent: Monday, April 30, 2012 3:35 PM
>>>To: Daniel Cohn; Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers,
>>>Josh
>>>Cc: [email-masked]
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>The internal S-VID which is pushed is popped/replaced with the original
>>>S-VID. Since they have a 1:1 relationship it is straightfwd. You need a
>>>mapping on ingress PE of the VPLS and on the egress PE.
>>>
>>>-----Original Message-----
>>>From: Daniel Cohn [mailto:[email-masked]]
>>>Sent: maandag 30 april 2012 14:35
>>>To: Henderickx, Wim (Wim); Lucy yong; Jiangyuanlong; Fedyk, Donald
>>>(Don); Rogers, Josh
>>>Cc: [email-masked]
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Because I still didn't see an explanation on how the egress PE knows
>>>which S-VID to push when sending the frame to the AC, if the original
>>>S-VID was popped at the ingress PE.
>>>Lucy answered that the egress PE " knows which S-VLAN ID is used on an
>>>AC", which seems to assume a single S-VLAN per root/leaf AC. So I still
>>>didn't get an answer to my question.
>>>
>>>Regards,
>>>
>>>DC
>>>
>>>-----Original Message-----
>>>From: Henderickx, Wim (Wim) [mailto:[email-masked]]
>>>Sent: Monday, April 30, 2012 3:27 PM
>>>To: Daniel Cohn; Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers,
>>>Josh
>>>Cc: [email-masked]
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Daniel, as Don pointed out the 2-VLAN solution works also with multiple
>>>S-VLANS. I am not sure why we are going in circles on this?
>>>
>>>-----Original Message-----
>>>From: [email-masked] [mailto:[email-masked]] On Behalf
>>>Of Daniel Cohn
>>>Sent: maandag 30 april 2012 13:41
>>>To: Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh
>>>Cc: [email-masked]
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Yuanlong,
>>>
>>>So the 2-VLAN solution, for the S-VLAN tagged port, works only when
>>>there is a single S-VID per AC?
>>>
>>>Thanks,
>>>
>>>DC
>>>
>>>-----Original Message-----
>>>From: [email-masked] [mailto:[email-masked]] On Behalf
>>>Of Jiangyuanlong
>>>Sent: Wednesday, April 25, 2012 9:21 PM
>>>To: Fedyk, Donald (Don; Rogers, Josh
>>>Cc: [email-masked]
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Hi Don and Josh,
>>>
>>>draft-jiang-l2vpn-vpls-pe-etree-05 discussed S-VLAN access in the
>>>following way:
>>>"...
>>>For an S-VLAN tagged port, the S-VLAN tag in the Ethernet frames
>>>received from the root ACs can be translated to the root S-VLAN in the
>>>VPLS network domain. Alternatively, the PBB VPLS PE model (where an IEEE
>>>802.1ah bridge module is embedded in the PE) as described in [PBB-VPLS]
>>>can be used, and a root B-VLAN or leaf B-VLAN can be added in this case.
>>>In a similar way, the traffic from the leaf ACs is tagged and
>>>transported on the leaf C-VLAN, S-VLAN or B-VLAN.
>>>"
>>>It seems option B is in line with the 1st sentence, not sure where
>>>option A came from, but do you have any concerns with the description in
>>>the 2nd sentence?
>>>
>>>Regards,
>>>Yuanlong
>>>
>>>----------------------------------------------------------------------
>>
>>
>>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.

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.

------------------------------

Message: 2
Date: Fri, 4 May 2012 20:20:24 -0400
From: Aldrin Isaac <[email-masked]>
To: Lucy yong <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, sajassi <[email-masked]>
Subject: Re: Interest in IS-IS VPLS
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Hi Lucy,

Please see inline

On May 4, 2012, at 11:07 AM, Lucy yong wrote:

> Hi Isaac,
> 
> Thank you for the reply. Please see inline.
> 
> Regards,
> Lucy
> 
> -----Original Message-----
> From: Aldrin Isaac [mailto:[email-masked]] 
> Sent: Thursday, May 03, 2012 10:50 PM
> To: Lucy yong
> Cc: sajassi; Giles Heron; Nabil Bitar; [email-masked]
> Subject: Re: Interest in IS-IS VPLS
> 

... 

> E-VPN also supports policy based-topologies versus simple point-to-point,
flat or tree VLANs.  It can support point-to-point, tree, mesh, one-way, or
pretty much any other "complex" or overlapped topologies (depending on how
you like to see it).  An example is ability to natively recreate private
vlan, community vlan topologies (which happen to be quite common in DC
networks) and any number of combinations of these simultaneously to a single
port.  A BGP E-VPN VPN is also decoupled from the edge EVI/ESI such that it
is not limited to a single tenant/vlan but can span tenants/vlans (l2
extranet) if so required.  This is native to E-VPN.
> [[LY]] Such policy based-topologies are useful for service provider
network, but may too complex for intra DCs. One reason that customers often
want to choose with L2VPN service is "it is simple". However, L3VPN have its
applications although some operators often complain the complexities to
configure these policies. Typical example is the a firewall only placed at a
location. Could you share why operator want such policy based-topology for
L2VPN?

Policy-based topologies are generally complex when used to interconnect IP
networks because there are generally multiple prefixes in a vrf, and often
different prefixes need to be associated to different VPNs or routing
behavior.  In the DC, L2VPN role is to interconnect host ports so the
policies for basic are very simple --- list of import route targets and list
of export route targets where each import/export pair correspond to a VPN
(tenant, service, ...).  An example of how a DC operator might use this for
example is to meet a requirement for private vlan and community vlans which
are very common for DMZs.  Hopefully you are familiar with these very common
use cases.  It is even possible to recreate more complex switch "features"
like MVR (in addition to private VLANs which are also considered "features")
using E-VPN.  It took me three years to get the MVR feature into a
particular vendor's switch to meet a business need.  I'll sacrifice
plug-and-play simplicity for busi
 ness agility.  I'm sure my peers are with me on this one.

If simple "plug-and-play" is important, one could imagine RRs sending out an
"RR TLV" such that RRs in an IGP area auto-connect with each other and
RR-clients connect to the closest RR based on SPF (some details like
peer-group, etc would need to be factored in to make it more powerful).
Other BGP/MPLS configuration is, IMHO, trivial unless you CHOOSE to use more
advanced capabilities (i.e. not locked in).  

Maybe the reason why MPLS comes across as complex is because of how IETF
deals with requirements lately by creating point solutions.  E-VPN tries to
put new capabilities on the table while trying not to take existing value
off the table.  There is no reason why a solution can't bring more value
than what the standards body calls for.

> E-VPN supports interconnecting end-stations or interconnecting L2
networks.  Procedures to easily span STP based networks across an E-VPN
network without loops comes with the base spec.  Extensions to E-VPN, such
as PBB-EVPN, simplify the fully functional spanning of non-EVPN networks
across an E-VPN network.
> [[LY]] current L2VPN support all these except active-active mode which
causes the loop.

Base E-VPN spec will natively deal with the STP case through an
active/standby mode and BPDU-snooping -- detect root bridge and use that as
ESI (ethernet segment id) to indicate unique STP network with active/standby
bit set to ensure only one forwarding link among links with same ESI.  Tags
(vlans) can potentially each have a different active link within the member
links of an ESI allowing for automatic tag(tenant)/vlan level load-balancing
into an STP network.  Edge networks that don't have mac-move issue will be
able to take full advantage of active-active load-balancing without need for
LAG/MLAG.

> An SVI/IRB interface can also be a member of both an E-VPN EVI and an IP
VRF allowing for easily bringing together virtual L2 and L3 topologies
anywhere in the network without a physical port.
> [[LY]] Could you please share how operator plan to use this? Which service
will you sell to customer in this case?

The service will be where a customer wants to communicate to a destination
network that is not in his subnet.  Operators most interested in EVPN
already have IPVPN services on their network.  This is the gateway point
between the EVPN virtual networks and [existing] IPVPN virtual networks.  No
physical port required.

> E-VPN builds on top of years of work in the IETF; traffic engineering,
scaling with route reflectors and RT constrain, multicast via NG-MVPN, etc.
> [[LY]] Agree. These are useful features for service provider network.
However, these functions may not necessary within DC although they had been
proved works well. 

I'm not sure how eventually re-inventing these capabilities (yes it will
happen) on behalf of a new protocol will be better than simply leveraging
proven technology.  Vendors don't need to implement every MPLS RFC ever
written to be able to implement the basic E-VPN.

> Can also use IP for transport tunnel.  But my understanding is that
popular merchant silicon has support for MPLS push/pop/swap these days (?).
This was captured by EVPN at it's inception, which is why the PE is referred
to as MES (MPLS-enabled switch) in E-VPN.
> [[LY]] Yes, current draft aims on MPLS solution only. But it states the
potential to extend to the use of IP tunnel. 
> The way I see it, a major reason why STP-based LANS are fickle and don't
scale well is on account of insufficient decoupling of core from edge
created by requirement for plug-and-play and how that played out over time.
Conversely the reason (among other things) why IP networks are more stable
is because they are not inherently plug-and-play, and with MPLS/BGP allows
excellent decoupling of core and edge.  I don't know enough about TRILL or
PBB to comment on those -- I just know that I'm not interested for enough
good reasons.  E-VPN enables a dynamic edge over a stable decoupled core
while giving each operator room for service differentiation.  It is
especially interesting to operators that have invested in MPLS technology
and operations.  I can find a lot of folks that understand BGP/MPLS IPVPN
and in short order have them know the ins and outs of basic E-VPN.  It's
quite hard for me to find non-vendor folk who really actually understand the
other technologies used to spa
 n Ethernet aside from basic STP. 
> [[LY]] Thank you to share this in the mailing list. 
> 
> This is an operator perspective.
> [[LY]]  This is great!
> 
> 
> On May 3, 2012, at 4:31 PM, Lucy yong wrote:
> 
>> Hi Ali,
>> 
>> 
>> "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that
>> emulates an Ethernet (V)LAN across a PSN. E-VPN supports
>> load-sharing across multiple connections from a Layer-2 site
>> to an L2VPN service. E-VPN is primarily targeted to support
>> large-scale L2VPNs with resiliency requirements not satisfied
>> by other L2VPN solutions"
>> 
>> [[LY]] IMO, E-VPN enhancement is to support multi-homing with
active-active mode. Load-sharing across multiple connections from a layer-2
site is desired when this mode is used. Current VPLS can provide resiliency
requirement when the multi-homing site configured with active-standby mode.
>> Regards,
>> Lucy
>> Cheers,
>> Ali  

------------------------------

_______________________________________________
L2vpn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/l2vpn

End of L2vpn Digest, Vol 96, Issue 18
*************************************