RE: L2vpn Digest, Vol 96, Issue 25

["Sam Cao" <[e-mail]>]

Yuanlong,

I have one clear idea on this, but I need time to discuss this with other
co-authors on details first. This is not PW issue. If we add an attribute
for the PW, and data plane can forward the frames from Leaf-Only AC to PW or
drop it. We need a little extension to data plane. There is not much work to
support this by NP, but I am not sure whether it is big work on chip or not.

Thanks,

Sam

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Monday, May 07, 2012 4:08 PM
To: [e-mail]
Subject: L2vpn Digest, Vol 96, Issue 25

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
	[e-mail]

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
	[e-mail]

You can reach the person managing the list at
	[e-mail]

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?
      (Jiangyuanlong)


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

Message: 1
Date: Mon, 7 May 2012 08:05:30 +0000
From: Jiangyuanlong <[e-mail]>
To: Daniel Cohn <[e-mail]>, "Rogers, Josh"
	<[e-mail]>, "Fedyk, Donald (Don)"
	<[e-mail]>, "Henderickx, Wim (Wim)"
	<[e-mail]>, Lucy yong
<[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: The status of the approaches to the E-Tree solution?
Message-ID:
	
<[e-mail]>
	
Content-Type: text/plain; charset="iso-8859-2"

Interesting observation. Could you explain a bit more how to avoid setup of
a PW in this scenario? Or could you just point to the exact sentences in
your I-D? 

-----Original Message-----
From: Daniel Cohn [mailto:[e-mail]] 
Sent: Monday, May 07, 2012 3:11 PM
To: Jiangyuanlong; Rogers, Josh; Fedyk, Donald (Don); Henderickx, Wim (Wim);
Lucy yong
Cc: [e-mail]
Subject: RE: The status of the approaches to the E-Tree solution?

It seems to be that the optimization required to avoid unnecessary
transmission of leaf-only traffic over the network is significantly more
complex in the 2-VLAN solution, as you need the data plane to maintain
per-PW "leaf-onlyness" information (whether a specific PW leads to a
leaf-only PE or not) to decide when to drop these frames, whereas in the
multi-PW solution this is handled solely by the control plane (by avoiding
the setup of a PW in this scenario).

DC

-----Original Message-----
From: Jiangyuanlong [mailto:[e-mail]] 
Sent: Monday, May 07, 2012 9:34 AM
To: Rogers, Josh; 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?


-----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.

  - 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.

  - 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". 

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.


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

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


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