RE: The status of the approaches to the E-Tree solution?

[Jiangyuanlong <[e-mail]>]

Could you or any other co-authors of 2PW give some more hints so that it can be better understood? 

In draft-ram-l2vpn-etree-multiple-pw-01, I can only find a single sentence most to the point:
  "An egress PE SHALL NOT deliver a frame originated at a leaf AC to
   another leaf AC."

But it seems there is not a description of "traffic is split/separated (by psuedowire) on the ingress PE" at all.

On the contrary, in draft-jiang-l2vpn-vpls-pe-etree-05, Section 5.3.3 details the scenario and forwarding plane how the leaf traffic is seperated and filtered on the ingress PE, and Section 6 details the specific supports in the control plane.

Thanks
Yuanlong


-----Original Message-----
From: Rogers, Josh [mailto:[e-mail]] 
Sent: Friday, May 04, 2012 8:27 PM
To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong
Cc: [e-mail]
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" <[e-mail]> wrote:

>Josh, thank you for the comments, please see my further comments with
>[JY2].
>
>-----Original Message-----
>From: Rogers, Josh [mailto:[e-mail]]
>Sent: Thursday, May 03, 2012 11:27 PM
>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim
>(Wim); Lucy yong
>Cc: [e-mail]
>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" <[e-mail]> wrote:
>
>>Josh, please see my comments in line.
>>
>>Thanks
>>Yuanlong
>>
>>-----Original Message-----
>>From: Rogers, Josh [mailto:[e-mail]]
>>Sent: Thursday, May 03, 2012 10:51 AM
>>To: Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim
>>(Wim); Lucy yong
>>Cc: [e-mail]
>>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" <[e-mail]> 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:[e-mail]]
>>>Sent: Wednesday, May 02, 2012 8:01 PM
>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy
>>>yong;
>>>[e-mail]
>>>Cc: [e-mail]
>>>Subject: RE: The status of the approaches to the E-Tree solution?
>>>
>>>Inline.
>>>
>>>-----Original Message-----
>>>From: Jiangyuanlong [mailto:[e-mail]]
>>>Sent: Wednesday, May 02, 2012 12:30 PM
>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong;
>>>[e-mail]
>>>Cc: [e-mail]
>>>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:[e-mail]]
>>>Sent: Wednesday, May 02, 2012 3:55 PM
>>>To: Jiangyuanlong; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy
>>>yong; [e-mail]
>>>Cc: [e-mail]
>>>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:[e-mail]]
>>>Sent: Wednesday, May 02, 2012 5:07 AM
>>>To: Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong;
>>>[e-mail]
>>>Cc: [e-mail]
>>>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:[e-mail]]
>>>Sent: Monday, April 30, 2012 10:34 PM
>>>To: Fedyk, Donald (Don); Henderickx, Wim (Wim); Lucy yong;
>>>Jiangyuanlong; [e-mail]
>>>Cc: [e-mail]
>>>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:[e-mail]]
>>>Sent: Monday, April 30, 2012 5:21 PM
>>>To: Henderickx, Wim (Wim); Daniel Cohn; '[e-mail]';
>>>'[e-mail]'; '[e-mail]'
>>>Cc: '[e-mail]'
>>>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: '[e-mail]'; '[e-mail]';
>>>'[e-mail]'; Fedyk, Donald (Don);
>>>'[e-mail]'
>>>Cc: '[e-mail]'
>>>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:[e-mail]]
>>>Sent: Monday, April 30, 2012 02:51 PM
>>>To: Henderickx, Wim (Wim); Lucy yong <[e-mail]>;
>>>Jiangyuanlong <[e-mail]>; Fedyk, Donald (Don); Rogers,
>>>Josh <[e-mail]>
>>>Cc: [e-mail] <[e-mail]>
>>>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:[e-mail]]
>>>Sent: Monday, April 30, 2012 3:35 PM
>>>To: Daniel Cohn; Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers,
>>>Josh
>>>Cc: [e-mail]
>>>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:[e-mail]]
>>>Sent: maandag 30 april 2012 14:35
>>>To: Henderickx, Wim (Wim); Lucy yong; Jiangyuanlong; Fedyk, Donald
>>>(Don); Rogers, Josh
>>>Cc: [e-mail]
>>>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:[e-mail]]
>>>Sent: Monday, April 30, 2012 3:27 PM
>>>To: Daniel Cohn; Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers,
>>>Josh
>>>Cc: [e-mail]
>>>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: [e-mail] [mailto:[e-mail]] On Behalf
>>>Of Daniel Cohn
>>>Sent: maandag 30 april 2012 13:41
>>>To: Lucy yong; Jiangyuanlong; Fedyk, Donald (Don); Rogers, Josh
>>>Cc: [e-mail]
>>>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: [e-mail] [mailto:[e-mail]] On Behalf
>>>Of Jiangyuanlong
>>>Sent: Wednesday, April 25, 2012 9:21 PM
>>>To: Fedyk, Donald (Don; Rogers, Josh
>>>Cc: [e-mail]
>>>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.