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

[Lucy yong <[e-mail]>]

Josh,

Thank you to provide the following needed PW for multi-PW solution. The left side of "=" sign represent PE->PE and the right side is needed PW. We are on the same table now. In addition, I add Dual VLAN for comparison.

Multi-PW                                     Dual-VLAN
Root-only -> any VSI = one PE               one PW
Leaf-only -> root-only = one PW             one PW and one leaf S-VLAN
Leaf-only -> Leaf-only = Zero PW            Zero PW
Leaf-only -> mixed = one PW                 one PW and one leaf S-VLAN
Mixed -> root-only = one PW                 one PW 
Mixed -> leaf-only = one PW                 one PW and one root S-VLAN
Mixed -> mixed = two PW                     one PW and one root S-VLAN and one leaf VLAN

Both methods let ingress PE marking and filtering all known unicast packets in mixed->mixed case. In the case, only a broadcast packet at mixed PE needs to be forwarded to another mixed PE with the mark, but the packet is sent once and no need to duplicate.

VPLS requires PW associating with a VSI not an AC.

Regards,
Lucy
-----Original Message-----
From: Rogers, Josh [mailto:[e-mail]] 
Sent: Monday, May 07, 2012 11:36 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?

Comment Inline:

On 5/7/12 1:34 AM, "Jiangyuanlong" <[e-mail]> wrote:

>
>-----Original Message-----
>From: Rogers, Josh [mailto:[e-mail]]
>Sent: Monday, May 07, 2012 12:09 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?
>
>So, if you can imagine three PE's, PE1, PE2 and PE3.  PE1 has a root AC,
>R1 and a leaf AC, L1.  PE2 also has a root AC, R2, and a leaf AC, L2.  PE3
>has a leaf AC, L3.
>
>Consider an unknown unicast frame from the leaf site L1, and also another
>unknown unicast frame from R1 entering.
>
>With the 2VLAN method (to my best understanding):
>  - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3,
>arrives at PE2 which decides that it should be flooded out all Root AC's,
>based on the S-tag.  It also arrives at PE3, where it is dropped because
>there are no root AC's.
>
>[JY] Since PE3 is a leaf-only node, the PW from PE1 to PE3 will work in
>Optimized-Mode. According to Section 5.3.3 of
>draft-jiang-l2vpn-vpls-pe-etree-05, it will be dropped before arriving at
>this PW. Therefore, this frame will not arrive at PE3.
[JR] Correct, in my example I was assuming no optimization.  See my later
comment about adding complexity for the sake of optimization (which is not
a problem, just an observation, the same observation holds true for
multi-PW method.)
>
>  - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3,
>arrives at PE2 which decides that it should be flooded out all AC's, based
>on S-tag.  It also arrives at PE3 where it is forwarded to all root AC's.
>
>With Multi-PW method:
>  - frame from L1 enters PE1, which decides to forward the frame out the
>'root' PW to PE2, which in turn floods out all Root AC's, based on
>arriving PW type.  Frame is NOT sent to PE3, since there is no PW built to
>the PE which has no root AC's.
>
>[JY] According to my understanding of the following description in
>draft-ram-l2vpn-etree-multiple-pw-01:
>  "It should be noted that in a full-mesh VPLS (as opposed to H-VPLS),
>   the following VSI pair types do not require two interconnecting PWs:
>   Root-only VSI <-> any VSI: only root PW required
>   Leaf-only VSI <-> leaf-only VSI: no PWs required"
>There should be 2 PWs be set up between PE1 and PE3, since this is a case
>of "Root & Leaf mixed VSI <-> leaf-only VSI" and not listed in the
>none-two- interconnecting-PWs criteria. Therefore, this frame will be
>sent to PE3 twice (one on root PW, another on leaf PW) IMO. Of course,
>the other authors of draft-ram-l2vpn-etree-multiple-pw-01 may have more
>to say on this point.
[JR] Remember that PW's are unidirectional, we should consider setup in
each direction independently:

root-only -> any VSI = one PW
Leaf-only -> root-only = one PW
Leaf-only -> Leaf-only = Zero PW
Leaf-only -> mixed = one PW
Mixed -> root-only = one PW
Mixed -> leaf-only = one PW
Mixed -> mixed = two PW

In our example, PE1 to PE3 would be mixed to leaf-only (one PW) in one
direction, and leaf-only to mixed (one PW) in the other, so I was mistaken
in my original depiction, and you are correct, it should be only one PW.
It would just be the mixed -> mixed where broadcast would be duplicated.
Also consider this list of scenarios, the only times that we have to
deviate from the typical 'any to any' VPLS is in the Leaf-only to
Leaf-only, and Mixed to Mixed PW's.  All others are a single PW.
[/JR]

>
>  - frame from R1 enters PE1, which decides to flood out both 'root' PW
>and 'leaf' PW to PE2, which in turn floods out the same AC types, based on
>arriving PW type.  It also arrives at PE3 where it is forwarded to all
>root AC's.
>
>[JY] It contradicts your first statement that "there is no PW built to
>the PE which has no root AC's".
[JR] Sorry, I got confused on my only topology and was thinking PE3 was
root-only.  Frame would arrive at PE3 (on the root-sourced PW) where it
would forward to all AC's.  Sorry I botched the explanation, I hope the
idea was not lost in the confusion.


>
>I suppose optimization could be done on the ingress PE to decide that
>there is no need to 'flood' root-sourced frames to two PW's that have the
>same egress PE, but instead to only forward to the 'root' type PW, when
>both exist, because we know that the egress PE will flood frames from
>root-sourced PW's out both leaf and root AC's.
>
>In this example, the same frame from R1 is duplicated on the PE1-PE2 path
>(if no optimization is done.), where it would not be with the 2VLAN
>method.
>
>With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's,
>otherwise how would we classify source AC-type?), which means there is
>overhead on EVERY frame to add the s-tag for the sole purpose of
>classifying the frame.  If optimization is done, then each ingress PE
>knows what types of AC's are on each egress PE, and only forwards the
>appropriate frame, if no optimization then it is dropped at the egress PE.
>
>In short, both are either not 100% inefficient, or are additionally
>complex due to 'optimization'.
>
>I may have gotten my details off on the optimization piece of the 2VLAN
>method, please correct me if I didn't get the details 100% correct.
>
>
>-Josh
>
>
>
>On 5/6/12 9:07 PM, "Jiangyuanlong" <[e-mail]> wrote:
>
>>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.
>
>
>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.