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

From: "Sam Cao" <[email-masked]>
Date: Sat, 5 May 2012 10:08:58 +0800

Lucy/Yuanlong,

I agree that we can not say which approach is better simply, but I really
agree with Josh's comments. Multi-PW is easy to implement E-Tree.

First of all, we discussed 2 approaches for a long time and many rounds, and
for me, there are no pending issues on Multi-PW till now or co-authors of
multi-PW have given reasonable reply to L2VPN members' questions, but there
are still pending issues for Dual-VLAN. Please trace the mailing list.

Second, Sasha has his concern in NP, or forwarding performance. Compared to
current VPLS, Multi-PW has a little effect on forwarding performance since
it reuse PW label as AC indicator; Dual-VLAN will have higher side effect on
forwarding performance because it SHOULD use additional indicator. Is there
one prototype for Dual-VLAN? BTW, there is no reply on chip limit.

Third, the difference between Multi-PW and dual-VLAN is, transport ingress
traffic in one "LSP" or 2 "LSP". Multi-PW classifies and transforms ingress
traffic into right "path", and egress just pop-out PW label and forward the
frame to ACs. Dual-VLAN has more work on ingress PE or egress PE. 

Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. Only
4094 VLAN ID are available, so only 2K E-Tree instances can be supported on
one PE for Dual-VLAN approach. There is no such limit for Multi-PW approach,

Finally, in this thread we don't make agreement on VLAN ID allocation. We
also have questions on VLAN ID negotiation among PEs (signaling protocol).
Yuanlong wishes to update, but there is no update till now.

For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL :), and
it has label, it also wish to use label to identify AC types. I think that
both solutions need much time to be perfect. Mutli-PW has less extension
work to do. But now we are focusing on technical details and can not move
forward :).  

Thanks,

Sam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, May 04, 2012 10:31 PM
To: [email-masked]
Subject: L2vpn Digest, Vol 96, Issue 15

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: The status of the approaches to the E-Tree solution?
      (Rogers, Josh)

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

Message: 1
Date: Fri, 4 May 2012 14:16:36 +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: <2691CE0099834E4A9C5044EEC662BB9D330E9114@dfweml505-mbx>
Content-Type: text/plain; charset="iso-8859-2"

Josh,

You simply say that you don't like IEEE Tree solution. IEEE Tree solution is
for ingress port to mark and for egress port to filter.

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 10:30:38 -0400
From: "Rogers, Josh" <[email-masked]>
To: Lucy yong <[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: <[email-masked]>
Content-Type: text/plain; charset="iso-8859-2"

To be more accurate, I like it less than the multi-PW solution.  I'd be
happy to use the 2VLAN solution in the real world, if it was ratified as
the standard.

On 5/4/12 9:16 AM, "Lucy yong" <[email-masked]> wrote:

>Josh,
>
>You simply say that you don't like IEEE Tree solution. IEEE Tree solution
>is for ingress port to mark and for egress port to filter.
>
>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.

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
[email-masked]
https://www.ietf.org/mailman/listinfo/l2vpn

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

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 7 May 2012 03:59:06 +0000

Sam, please see my comments in line. I changed the Subject to reflect the topic.

Regards
Yuanlong

-----Original Message-----
From: Sam Cao [mailto:[email-masked]] 
Sent: Saturday, May 05, 2012 10:09 AM
To: [email-masked]
Cc: Lucy yong; 'Rogers, Josh'; Jiangyuanlong; 'Alexander Vainshtein'; 'Daniel Cohn'
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Lucy/Yuanlong,

[JY] Do you have any solution for the PW OAM issue? It was raised in the IETF 83rd meeting and included in the minutes.

[JY] During the exchange of emails, it turned out that CW or 2PW based approach is highly dependent on the specific implementation of devices. I failed to understand your assumption that "Multi-PW has a little effect on forwarding performance since it reuse PW label as AC indicator; Dual-VLAN will have higher side effect on forwarding performance because it SHOULD use additional indicator." Are you referring to the Ethernet forwarding plane of a VSI or something else? Otherwise, what the side effect of VLAN to Ethernet forwarding plane? What you mean by chip limit? BTW, I think not only a prototype, but also field deployments is the goal of a valid solution.

[JY] Interesting. Setting up 2 PWs between a pair of PEs does not guarantee these PWs are tunnelled in separate LSPs. BTW, 2 LSPs or 2 PWs will pose greater challenge to the E-Tree OAMs, so I will rather consider it a disadvantage.
Moreover, with regard to the new work on E-Tree, 2PW needs:
1. An extra layer of abstraction is needed for E-Tree PWs, i.e., a logical bridge interface is introduced on the VSI for 2 PWs, let us assume, PW-R for root traffic and PW-L for leaf traffic, and the logical bridge interface is called LBI. Thus:
MAC learning and forwarding will be performed over AC, PW and LBI in parallel in a VSI.
Broadcasting or multicasting over LBI and then over both PW-R and PW-L must be provided.
2. Mapping of AC's E-Tree attribute <--> VSI internal R/L bit <--> PW-R/PW-L, and the R/L bit needs to be internally coded.
3. Split horizon must be applied over AC groups, PW groups, and PW + LBI groups, thus we will introduce more complexity in configuration of split horizon groups.
Is this really simpler compared with 2VLAN (after all, the latter only needs to add or translate a VLAN)?

[JY] That is the case only when a global VLAN space is used. In IEEE, the same discussions also happened before. But with VLAN translation and multiple VLAN spaces, Dual-VLAN approach is quite scalable, thus it was adopted in IEEE.

[JY] I don't think this WG has any agreements on any E-Tree solution yet...

[JY] I see no reason to associate a PW with a AC in VPLS (unlike VPWS, for VPLS, there are VSI modules which still work like a bridge module, and there even may be multiple bridge modules in a PE), and PW label only applies on the Pseudo-wire layer facing the core side. 
I agree with you that both solutions need time to be perfect, but at this stage, 2VLAN is more mature both in data plane and control plane. The comparison is meaningful only when they are at the same level of maturity.
 
Thanks,

Sam

---

From: Lucy yong <[email-masked]>
Date: Mon, 7 May 2012 19:58:06 +0000

Sam,

I conquer Yuanlong's reply on this. Please see inline.

Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Cao
Sent: Friday, May 04, 2012 9:09 PM
To: [email-masked]
Cc: Jiangyuanlong
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Lucy/Yuanlong,

I agree that we can not say which approach is better simply, but I really
agree with Josh's comments. Multi-PW is easy to implement E-Tree.
[[LY]] I don't get impression Josh state this.

[[LY]] I interpret this as people want to spend time to finalize dual VLAN solution. Multi-PW has some operation impact. How do operator to maintain this service and be able to trouble shooting. How do you expect traceroute work when using two PWs for one VPN? How do you expect PE report when there is an error on one of two PWs? Do you have one FEC or two FEC for a E-Tree in control plane?

[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree your statement here.

[[LY]] Don't understand the first part. When egress pop-out PW label, it find corresponding VSI first, then perform MAC lookup associated to all ACs. We can't assume there is one AC.
 
Fourth, maybe Giles has figured this out, Dual-VLAN has capacity limit. Only
4094 VLAN ID are available, so only 2K E-Tree instances can be supported on
one PE for Dual-VLAN approach. There is no such limit for Multi-PW approach,
[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for E-Tree. 

Finally, in this thread we don't make agreement on VLAN ID allocation. We
also have questions on VLAN ID negotiation among PEs (signaling protocol).
Yuanlong wishes to update, but there is no update till now.
[[LY]] This should not be the reason to judge on the solution.

[[LY]] VPN label is used for identify the VPN. It already has the purpose. Overloading with other meaning has high potential causing a problem. Hope you can investigate it more. Since you are very in favor of multi-pw solution, it is not proper for you to come out the conclusion which is better, because it is very biased. You are welcome to help on completing either solution.

Regards,
Lucy

Lucy

Thanks,

Sam

-----Original Message-----

Today's Topics:

Message: 1

Josh,

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]

-Josh

Message: 2

---

From: Lucy yong <[email-masked]>
Date: Mon, 7 May 2012 20:26:55 +0000

Sorry, I mean to say "concur", not "conquer" in previous mail. They sounds same but completely different meanings.
Lucy

-----Original Message-----
From: Lucy yong 
Sent: Monday, May 07, 2012 2:58 PM
To: 'Sam Cao'; [email-masked]
Cc: Jiangyuanlong
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Sam,

Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Cao
Sent: Friday, May 04, 2012 9:09 PM
To: [email-masked]
Cc: Jiangyuanlong
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Lucy/Yuanlong,

 

Regards,
Lucy

Lucy

Thanks,

Sam

-----Original Message-----

Today's Topics:

Message: 1

Josh,

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]

-Josh

Message: 2

---

From: "Rogers, Josh" <[email-masked]>
Date: Mon, 7 May 2012 17:21:57 -0400

Comments inline (and s/conquer/concur/)

On 5/7/12 2:58 PM, "Lucy yong" <[email-masked]> wrote:

>Sam,
>
>I concur with Yuanlong's reply on this. Please see inline.
>
>Lucy
>
>Sam Cao
>[[LY]] I interpret this as people want to spend time to finalize dual
>VLAN solution. Multi-PW has some operation impact. How do operator to
>maintain this service and be able to trouble shooting. How do you expect
>traceroute work when using two PWs for one VPN? How do you expect PE
>report when there is an error on one of two PWs? Do you have one FEC or
>two FEC for a E-Tree in control plane?
[JR] I don't see this any more of a problem than troubleshooting one.  If
LDP is used, a simple mols traceroute shows the path that ALL PW's to that
PE take, regardless of which service (this VPLS or another VPLS instance).
 If RSVP is used, there should be a route-object that shows me the path,
and allows me to troubleshoot.  Additionally, if I wanted to have traffic
engineering that impacted root-sourced and leaf-sourced traffic
differently, I can do that with multi-PW, where I could not (save for
ingress/egress) with the 2VLAN approach.  PE should report signaling on
second PW same as it does for the 100th PW between PE's.  Again, I don't
see the problem you are alluding to.
>[[LY]] Don't understand the first part. When egress pop-out PW label, it
>find corresponding VSI first, then perform MAC lookup associated to all
>ACs. We can't assume there is one AC.
>
[JR] I tend to agree.
>[[LY]] VPN label is used for identify the VPN. It already has the
>purpose. Overloading with other meaning has high potential causing a
>problem. Hope you can investigate it more. Since you are very in favor of
>multi-pw solution, it is not proper for you to come out the conclusion
>which is better, because it is very biased. You are welcome to help on
>completing either solution.
[JR] this is humorous to me, because at one time, VLAN-ID was used to
identify a single broadcast domain, and then later asymmetrical VID's were
used to limit communication between endpoints of a broadcast domain
(effectively creating two one-way broadcast domains, very similar to what
we're accomplishing with ETREE).   This should not be the reason to judge
on the solution.

>is
>(Wim);
>for
>for

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.

---

From: Lucy yong <[email-masked]>
Date: Mon, 7 May 2012 22:36:50 +0000

Josh,

Snip..

Additionally, if I wanted to have traffic

[[LY]]  You can use QoS to achieve that too. MEF discuss about this a lot. The trade-off in the use of different transport pipes is that you lose the ability to share the BW. However, you can argue to use over-subscription. But it makes operation more complex. After a long debate, MEF decide to use one transport pipe for both root and leaf traffic.

this is humorous to me, because at one time, VLAN-ID was used to

[[LY]] This is because applications become more complex. There are private LAN, community LAN, group LAN, etc.

Thanks,
Lucy

---

From: "Rogers, Josh" <[email-masked]>
Date: Mon, 7 May 2012 18:48:57 -0400

[[LY]]  You can use QoS to achieve that too. MEF discuss about this a lot.
The trade-off in the use of different transport pipes is that you lose the
ability to share the BW. However, you can argue to use over-subscription.
But it makes operation more complex. After a long debate, MEF decide to
use one transport pipe for both root and leaf traffic.

I could also argue to use aggregate policing.  Regardless, I don't think
this additional ability to traffic engineer by transport pipes is a worthy
note in this discussion.  At the end of the day, the application need is
to have additional granularity with forwarding traffic between AC's in a
VPLS, based on the source and destination AC.  ETREE requires only two AC
types, which both methods meet, and I still think both are valid solutions
(even though I prefer one over the other.)

-Josh

On 5/7/12 5:36 PM, "Lucy yong" <[email-masked]> wrote:

>[[LY]]  You can use QoS to achieve that too. MEF discuss about this a
>lot. The trade-off in the use of different transport pipes is that you
>lose the ability to share the BW. However, you can argue to use
>over-subscription. But it makes operation more complex. After a long
>debate, MEF decide to use one transport pipe for both root and leaf
>traffic.
>
>[[LY]] This is because applications become more complex. There are
>private LAN, community LAN, group LAN, etc.
>
>Thanks,
>Lucy
>
>>
>>Regards,
>>Lucy
>>
>>Lucy
>>
>>Thanks,
>>
>>Sam
>>
>>>>>>[mailto:[email-masked]]
>>>>>>[mailto:[email-masked]]

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 8 May 2012 04:04:27 +0000

Josh, 

Just some comments on this part:

I suppose you are referring to LSP Ping on the LSP layer, yes, it can oversee all the PWs in this LSP. If both root and leaf PW are in the same LSP, it can work. But there may well be multiple LSPs between a pair of PEs, and root/leaf PW may be transported on different LSPs. Another difficulty is, if ECMP is deployed and PW label as a bottom label is used for hashing, the OAM message may be load balanced on different paths.
With regard to TE, you could use DS-TE, just as Lucy said, two PW do not guarantee they are traffic engineered.

Thanks
Yuanlong

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 5:22 AM
To: Lucy yong; Sam Cao; [email-masked]
Cc: Jiangyuanlong
Subject: Re: L2vpn Digest, Vol 96, Issue 15

[JR] I tend to agree.

---

From: "Daniel Cohn" <[email-masked]>
Date: Tue, 8 May 2012 11:27:53 +0300

Yuanlong, isn't this orthogonal to the issues we are discussing? I mean,
there are different mechanisms to troubleshoot PWs, all of which are
applicable to root/leaf PWs as to any other PWs. Or is there any
specific limitation on root/leaf PW troubleshooting, compared to
"regular" PWs used in VPLSs?

Thanks,

Daniel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jiangyuanlong
Sent: Tuesday, May 08, 2012 7:04 AM
To: Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Josh, 

Just some comments on this part:
[JR] I don't see this any more of a problem than troubleshooting one.
If
LDP is used, a simple mols traceroute shows the path that ALL PW's to
that
PE take, regardless of which service (this VPLS or another VPLS
instance).
 If RSVP is used, there should be a route-object that shows me the path,
and allows me to troubleshoot.  Additionally, if I wanted to have
traffic
engineering that impacted root-sourced and leaf-sourced traffic
differently, I can do that with multi-PW, where I could not (save for
ingress/egress) with the 2VLAN approach.  PE should report signaling on
second PW same as it does for the 100th PW between PE's.  Again, I don't
see the problem you are alluding to.

I suppose you are referring to LSP Ping on the LSP layer, yes, it can
oversee all the PWs in this LSP. If both root and leaf PW are in the
same LSP, it can work. But there may well be multiple LSPs between a
pair of PEs, and root/leaf PW may be transported on different LSPs.
Another difficulty is, if ECMP is deployed and PW label as a bottom
label is used for hashing, the OAM message may be load balanced on
different paths.
With regard to TE, you could use DS-TE, just as Lucy said, two PW do not
guarantee they are traffic engineered.

Thanks
Yuanlong

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 5:22 AM
To: Lucy yong; Sam Cao; [email-masked]
Cc: Jiangyuanlong
Subject: Re: L2vpn Digest, Vol 96, Issue 15

>From: [email-masked] [mailto:[email-masked]] On Behalf
Of
>First of all, we discussed 2 approaches for a long time and many
rounds,
>and
[JR] I don't see this any more of a problem than troubleshooting one.
If
LDP is used, a simple mols traceroute shows the path that ALL PW's to
that
PE take, regardless of which service (this VPLS or another VPLS
instance).
 If RSVP is used, there should be a route-object that shows me the path,
and allows me to troubleshoot.  Additionally, if I wanted to have
traffic
engineering that impacted root-sourced and leaf-sourced traffic
differently, I can do that with multi-PW, where I could not (save for
ingress/egress) with the 2VLAN approach.  PE should report signaling on
second PW same as it does for the 100th PW between PE's.  Again, I don't
see the problem you are alluding to.
>
>Second, Sasha has his concern in NP, or forwarding performance.
Compared
>it reuse PW label as AC indicator; Dual-VLAN will have higher side
effect
>on
>4094 VLAN ID are available, so only 2K E-Tree instances can be
supported
>on
[JR] I tend to agree.
>
>For me, why IEEE uses VLAN ID to identify AC type? IEEE has no LABEL
:),
>and
[JR] this is humorous to me, because at one time, VLAN-ID was used to
identify a single broadcast domain, and then later asymmetrical VID's
were
used to limit communication between endpoints of a broadcast domain
(effectively creating two one-way broadcast domains, very similar to
what
we're accomplishing with ETREE).   This should not be the reason to
judge
on the solution.

>From: [email-masked] [mailto:[email-masked]] On Behalf
Of
you
to
to
>the use of the individual or entity to which it is addressed. If you
are
>contents of and attachments to this E-mail is strictly prohibited and
may
>be
>>psuedowire) on the ingress PE, rather than the egress.  The
distinction
>>>>shipping it everywhere and deciding whether to forward to the AC
when
>>>>it
>>>>traffic placed into two psuedowires, I have more flexibility and
ease
>>>>of
>>>>>[JY] This is not the case. If the total number is no more than
2047,
>>>>>it
>>>>>IOW, there needs to be a 1:1 mapping between 4094 S-VIDs in the
root
>>>>>AC
>>>>>S-VID. Since they have a 1:1 relationship it is straightfwd. You
need
>>>>>a
to
to
>the use of the individual or entity to which it is addressed. If you
are
>contents of and attachments to this E-mail is strictly prohibited and
may
>be

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.

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 8 May 2012 08:42:28 +0000

I don't think so. There may be different layers of OAM applicable to a service. Such as LSP layer, PW layer, and service layer.
Now you cannot use a single LSP OAM to monitor the server layer of the E-Tree service (as 2 LSP may be involved).
And the service layer of OAM for E-Tree may be distributed to different LSP paths.

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:28 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Thanks,

Daniel

-----Original Message-----

Josh, 

Thanks
Yuanlong

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 5:22 AM
To: Lucy yong; Sam Cao; [email-masked]
Cc: Jiangyuanlong
Subject: Re: L2vpn Digest, Vol 96, Issue 15

Of
rounds,
Compared
effect
supported
[JR] I tend to agree.
:),

Of
you
>>>>S-VID. Since they have a 1:1 relationship it is straightfwd. You
need a
to
to
are
may
distinction
when
ease
2047,
root
need
to
to
are
may

---

From: "Daniel Cohn" <[email-masked]>
Date: Tue, 8 May 2012 11:49:22 +0300

Inline

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 11:42 AM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

I don't think so. There may be different layers of OAM applicable to a
service. Such as LSP layer, PW layer, and service layer.

[DC] Agreed

Now you cannot use a single LSP OAM to monitor the server layer of the
E-Tree service (as 2 LSP may be involved).
And the service layer of OAM for E-Tree may be distributed to different
LSP paths.

[DC] For E-Tree service OAM, you would perform OAM actions from MEPs
associated to root or leaf ACs, so the E-OAM frames would naturally
follow the root or leaf pseudowires and the LSPs that transport them. I
don't see a limitation here.

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:28 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Thanks,

Daniel

-----Original Message-----

Josh, 

Thanks
Yuanlong

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 5:22 AM
To: Lucy yong; Sam Cao; [email-masked]
Cc: Jiangyuanlong
Subject: Re: L2vpn Digest, Vol 96, Issue 15

Of
rounds,
Compared
effect
supported
[JR] I tend to agree.
:),

Of
you
need a
to
to
are
may
distinction
when
ease
2047,
root
need
to
to
are
may

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 8 May 2012 12:18:21 +0000

Inline

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 11:42 AM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

[DC] Agreed

[JY] Now you need to monitor two LSPs and/or two PWs between mixed PEs for this E-Tree.
Besides the UP MEPs (associated with access port) as you mentioned, DOWN MEPs may also be needed (facing core) where both root and leaf traffic cross, not sure how you will configure OAM for them.

Regards,
Yuanlong

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:28 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Thanks,

Daniel

-----Original Message-----

Josh, 

Thanks
Yuanlong

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 5:22 AM
To: Lucy yong; Sam Cao; [email-masked]
Cc: Jiangyuanlong
Subject: Re: L2vpn Digest, Vol 96, Issue 15

Of
rounds,
Compared
effect
supported
[JR] I tend to agree.
:),

Of
you
need a
to
to
are
may
distinction
when
ease
2047,
root
need
to
to
are
may

---

From: "Daniel Cohn" <[email-masked]>
Date: Tue, 8 May 2012 16:22:38 +0300

Yuanlong, where in RFC 6136 (or anywhere else) do you see a requirement
for down MEPs in a PE?
As I see it, down MEPs in a PE should be MPLS MEPs and not E-OAM MEPs,
since the core cannot always be assumed to be Ethernet. 

Daniel

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 3:18 PM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Inline

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 11:42 AM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

[DC] Agreed

[JY] Now you need to monitor two LSPs and/or two PWs between mixed PEs
for this E-Tree.
Besides the UP MEPs (associated with access port) as you mentioned, DOWN
MEPs may also be needed (facing core) where both root and leaf traffic
cross, not sure how you will configure OAM for them.

Regards,
Yuanlong

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:28 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Thanks,

Daniel

-----Original Message-----

Josh, 

Thanks
Yuanlong

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 5:22 AM
To: Lucy yong; Sam Cao; [email-masked]
Cc: Jiangyuanlong
Subject: Re: L2vpn Digest, Vol 96, Issue 15

Of
rounds,
Compared
effect
supported
[JR] I tend to agree.
:),

Of
you
need a
to
to
are
may
distinction
when
ease
2047,
root
need
to
to
are
may

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 8 May 2012 13:22:33 +0000

Daniel,

RFC 6136 provides the VPLS OAM reqs and framework, and Sec. 10.1. gives the typical VPLS OAM Operational Scenarios:

      ---                                                   ---
     /   \         ------      -------      ----           /   \
     | A CE--     /      \    /       \    /    \       --CE A |
     \   /   \   /        \  /         \  /      \     /   \   /
      ---     --UPE       NPE          NPE        UPE--     ---
                 \        /  \         /  \      /
                  \      /    \       /    \    /
                   ------      -------      ----

                           Customer OAM Domain
   (C)    MEP---MIP--------------------------------MIP---MEP

                    Service Provider (SP) OAM Domain
   (D)          MEP--------MIP-----------MIP-------MEP

                   SP OAM       SP OAM       SP OAM
   (D1)         MEP-MIP--MEP|MEP-------MEP|MEP-----MEP
                   domain       domain       domain

                   Operator    Operator     Operator
   (E)          MEP-MIP--MEP|MEP-------MEP|MEP-----MEP
                  OAM domain   OAM domain   OAM domain

                                MPLS OAM   MPLS OAM
   (F)                      MEP--MIP-----MEP--MIP--MEP
                                 domain      domain

             Figure 10: VPLS OAM Domains, MEPs, and MIPs

It seems OAM configurations in Scenario D1) and E) for 2PW approach will be much complicated and error prone, since E-Tree OAM now needs to interwork with one of these two PWs' OAM (maybe both, I am afraid).  For scenario F), the concatanation of two MPLS OAM also needs to be very careful as 4 PWs and 3 types (i.e, root/leaf/normal) may be involved there.

Regards,
Yuanlong

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:49 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Inline

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 11:42 AM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

[DC] Agreed

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:28 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Thanks,

Daniel

-----Original Message-----

Josh, 

Thanks
Yuanlong

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 5:22 AM
To: Lucy yong; Sam Cao; [email-masked]
Cc: Jiangyuanlong
Subject: Re: L2vpn Digest, Vol 96, Issue 15

Of
rounds,
Compared
effect
supported
[JR] I tend to agree.
:),

Of
you
need a
to
to
are
may
distinction
when
ease
2047,
root
need
to
to
are
may

---

From: "Daniel Cohn" <[email-masked]>
Date: Tue, 8 May 2012 16:29:26 +0300

Yuanlong,

I don't see the additional complexity. Existing PW maintenance processes
at the operator can take care of the additional root/leaf PWs exactly
like they do today. Only they will have some more PWs to maintain (not
twice as much, since most PEs are typically leaf-only and therefore have
only a root PW per E-Tree instance)
And service maintenance processes should be extended to maintain root
and leaf services using E-OAM, both for the 2-VLAN and multi-PW
solutions.

DC

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:23 PM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Daniel,

RFC 6136 provides the VPLS OAM reqs and framework, and Sec. 10.1. gives
the typical VPLS OAM Operational Scenarios:

      ---                                                   ---

                           Customer OAM Domain

                   SP OAM       SP OAM       SP OAM

                                MPLS OAM   MPLS OAM

It seems OAM configurations in Scenario D1) and E) for 2PW approach will
be much complicated and error prone, since E-Tree OAM now needs to
interwork with one of these two PWs' OAM (maybe both, I am afraid).  For
scenario F), the concatanation of two MPLS OAM also needs to be very
careful as 4 PWs and 3 types (i.e, root/leaf/normal) may be involved
there.

Regards,
Yuanlong

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:49 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Inline

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 11:42 AM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

[DC] Agreed

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:28 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Thanks,

Daniel

-----Original Message-----

Josh, 

Thanks
Yuanlong

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 5:22 AM
To: Lucy yong; Sam Cao; [email-masked]
Cc: Jiangyuanlong
Subject: Re: L2vpn Digest, Vol 96, Issue 15

Of
rounds,
Compared
effect
supported
[JR] I tend to agree.
:),

Of
you
need a
to
to
are
may
distinction
when
ease
2047,
root
need
to
to
are
may

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 8 May 2012 13:28:53 +0000

RFC 6136 explicitly calls out IEEE Std. 802.1ag-2007. 
Please also refer to Fig.10 of RFC 6136 and Section 10.1:
   "Inside the network operator OAM domain, [IEEE802.1ag] and [Y.1731]
   Ethernet OAM mechanisms can also be applied across MEs in (E) in
   Figure 10 to meet the functional requirements identified in Section
   7."

Regards
Yuanlong

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 9:23 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Daniel

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 3:18 PM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Inline

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 11:42 AM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

[DC] Agreed

Regards,
Yuanlong

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:28 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Thanks,

Daniel

-----Original Message-----

Josh, 

Thanks
Yuanlong

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 5:22 AM
To: Lucy yong; Sam Cao; [email-masked]
Cc: Jiangyuanlong
Subject: Re: L2vpn Digest, Vol 96, Issue 15

Of
rounds,
Compared
effect
supported
[JR] I tend to agree.
:),

Of
you
need a
to
to
are
may
distinction
when
ease
2047,
root
need
to
to
are
may

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 8 May 2012 13:37:35 +0000

Except PW numbers, now PW attributes also needs to be considered: root, leaf or normal.
Can the root or leaf PW be connected to the normal PW? Or just connect root to root, and leaf to leaf?
Without signalling, this will pose a great challenge to configure the OAM correctly.

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 9:29 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Yuanlong,

DC

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:23 PM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Daniel,

      ---                                                   ---

                           Customer OAM Domain

                   SP OAM       SP OAM       SP OAM

                                MPLS OAM   MPLS OAM

Regards,
Yuanlong

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:49 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Inline

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 11:42 AM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

[DC] Agreed

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:28 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Thanks,

Daniel

-----Original Message-----

Josh, 

Thanks
Yuanlong

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 5:22 AM
To: Lucy yong; Sam Cao; [email-masked]
Cc: Jiangyuanlong
Subject: Re: L2vpn Digest, Vol 96, Issue 15

Of
rounds,
Compared
effect
supported
[JR] I tend to agree.
:),

Of
you
need a
to
to
are
may
distinction
when
ease
2047,
root
need
to
to
are
may

---

From: "Daniel Cohn" <[email-masked]>
Date: Tue, 8 May 2012 16:59:16 +0300

>From the PW maintenance point of view, all PWs are the same. There is no
difference in the maintenance operations for root/leaf/normal PW.

Root/leaf is signaled in LDP so mismatch can be detected and notified to
operator.

DC

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:38 PM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Except PW numbers, now PW attributes also needs to be considered: root,
leaf or normal.
Can the root or leaf PW be connected to the normal PW? Or just connect
root to root, and leaf to leaf?
Without signalling, this will pose a great challenge to configure the
OAM correctly.

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 9:29 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Yuanlong,

DC

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:23 PM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Daniel,

      ---                                                   ---

                           Customer OAM Domain

                   SP OAM       SP OAM       SP OAM

                                MPLS OAM   MPLS OAM

Regards,
Yuanlong

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:49 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Inline

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 11:42 AM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

[DC] Agreed

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:28 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Thanks,

Daniel

-----Original Message-----

Josh, 

Thanks
Yuanlong

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 5:22 AM
To: Lucy yong; Sam Cao; [email-masked]
Cc: Jiangyuanlong
Subject: Re: L2vpn Digest, Vol 96, Issue 15

Of
rounds,
Compared
effect
supported
[JR] I tend to agree.
:),

Of
you
need a
to
to
are
may
distinction
when
ease
2047,
root
need
to
to
are
may

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 9 May 2012 02:26:34 +0000

Daniel,

I change the Subject to reflect the discussion.
Let me give an example adapted simply from fig.10 of RFC 6136 to show what is the problem for 2PW, assume both UPEs are mixed with root and leaf, and we need to monitor the connectivity between L1 (leaf) and R1 (root).

      ---                                                   ---
     /   \         ------      -------      ----           /   \
     |L1 CE--     /      \    /       \    /    \       --CE R1|
     \   /   \   /        \  /         \  /      \     /   \   /
      ---     --UPE       NPE          NPE        UPE--     ---
                 \        /  \         /  \      /
                  \      /    \       /    \    /
                   ------      -------      ----
                           Customer OAM Domain
   (C)    MEP---MIP--------------------------------MIP---MEP

                   SP OAM       SP OAM       SP OAM

                                MPLS OAM   MPLS OAM

If we find a problem in the Customer OAM domain for (L1-R1), and server layer need to be inverstigated further to locate the network problem.

In the 2PW approach, we have 2 PWs (root PW and leaf PW) in every Operator OAM domain and need to associate one (maybe both?) with this customer service.

Just consider a single OAM domain:
In the forward direction, the traffic is from leaf to root, it seems the leaf PW needs to be associated with this service.
On the other hand, in the reverse direction, the traffic is from root to leaf, it seems the root PW needs to be associated with this service.
But how can you configure a pair of MEPs across both root and leaf PWs? (I believe both root and leaf PW have a pair of MEPs respectively)

If multiple MPLS OAM domains are considered, things will become more interesting.

Further comments are in line.

Thanks,
Yuanlong

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 9:59 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

difference in the maintenance operations for root/leaf/normal PW.
[JY] it is true for a single PW in a single OAM domain, but when they are coupled to provide an end to end E-Tree service, things will be quite different as shown above.

Root/leaf is signaled in LDP so mismatch can be detected and notified to
operator.
[JY] LDP seems work in a single OAM domain, and mismatch point is inter-OAM-domain. Moreover, mismatch is supposed to be detected by OAM. Did I miss something?

DC

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 9:29 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Yuanlong,

DC

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:23 PM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Daniel,

      ---                                                   ---

                           Customer OAM Domain

                   SP OAM       SP OAM       SP OAM

                                MPLS OAM   MPLS OAM

Regards,
Yuanlong

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:49 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Inline

-----Original Message-----
From: Jiangyuanlong [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 11:42 AM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

[DC] Agreed

-----Original Message-----
From: Daniel Cohn [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 4:28 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [email-masked]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Thanks,

Daniel

-----Original Message-----

Josh, 

Thanks
Yuanlong

...snipped....

---

From: "Sam Cao" <[email-masked]>
Date: Wed, 9 May 2012 22:36:15 +0800

Lucy, Josh,

Thank you very much for your insight comments. Sorry for late reply for busy
day job :).

I picked your comments below and see my comments inline.

[JR] I don't see this any more of a problem than troubleshooting one.  If
LDP is used, a simple mols traceroute shows the path that ALL PW's to that
PE take, regardless of which service (this VPLS or another VPLS instance).
 If RSVP is used, there should be a route-object that shows me the path,
and allows me to troubleshoot.  Additionally, if I wanted to have traffic
engineering that impacted root-sourced and leaf-sourced traffic
differently, I can do that with multi-PW, where I could not (save for
ingress/egress) with the 2VLAN approach.  PE should report signaling on
second PW same as it does for the 100th PW between PE's.  Again, I don't
see the problem you are alluding to.
[Sam] Lucy, I agree with your comments, and both approaches need time to
finalize. I answered to your questions one by one, and wish this is clear.
First, there is no problem on traceroute or trouble-shooting or LSP ping.
Josh has given some insight comments, and yes, we have 2 PWs, but we just
repeat the OAM work twice, and there is no difference. If there is an error
on one of 2 PWs, ok, OAM just report the error on the corresponding PW. For
example, if Leaf PW has an error, OAM detects Leaf PW error. Finally, in
control plane we don't introduce new FEC. Only one FEC for an E-Tree
instance, FEC 128 or FEC 129.

>[[LY]] in VPLS, PW label is used as VSI indicator, not AC. I disagree
[Sam] Lucy, first of all, PW label is NOT used as VSI indicator. In RFC
4762, "In a VPLS, we use a VCID to identify an emulated LAN segment (from
RFC 4762)", and VPLS identifier is not carried in frame; in RFC 4761, Route
Target is used as VPLS identifier. PW label (ILM) can be taken as PW
identifier. What I mean is, one frame from Root AC on PE 1 to PE 2, for
example, Dual-VLAN will add 2 identifiers in the frame, Root-VLAN ID to
identifier the frame from Root; PW label means which PW will carry the
frame. But for Multi-PW, we only need one PW label, and it is enough.

>ACs. We can't assume there is one AC.
[Sam] Same description as above. Dual-VLAN uses one PW to carry frames from
Root-AC or Leaf-AC, but Multi-PW uses one to carry frames from Root and one
carry frames from Leaf. MAC lookup is basic bridge function and both should
use this. We can ignore this first. Multi-PW popped the PW label out, then
do MAC lookup; But dual-VLAN popped the PW label out, it should check VLAN
identifier, and then do MAC lookup. If we implement it in NP, obviously it
will cost more time and decrease forwarding performance.

>[[LY]] If 4K VLAN ID is not an issue for VPLS, it is not an issue for
[Sam] If we use tagged mode, yes, I agree with your idea. But if we use raw
mode, generally Multi-PW can supports more, but IMO Dual-VLAN can not. This
is my point.

>[[LY]] This should not be the reason to judge on the solution.
[JR] I tend to agree.
[Sam] I don't make myself understood. If I don't know the VLAN ID allocation
solution, I will have no correct comments on it. Yes, I agree this is not
the reason to judge on the solution.

[JR] this is humorous to me, because at one time, VLAN-ID was used to
identify a single broadcast domain, and then later asymmetrical VID's were
used to limit communication between endpoints of a broadcast domain
(effectively creating two one-way broadcast domains, very similar to what
we're accomplishing with ETREE).   This should not be the reason to judge
on the solution.
[Sam] Same as above. PW label identify the PW. For example, we can use label
2000 to identify Root PW, label 2001 to identify Leaf PW. This does not
identify E-Tree, although the 2 PWs belong to one E-Tree instance.

Wish this is clear. Again thank you for your time,

Regards,
 
Yuqun (Sam) Cao
E-mail: [email-masked] 

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 5:22 AM
To: Lucy yong; Sam Cao; [email-masked]
Cc: Jiangyuanlong
Subject: Re: L2vpn Digest, Vol 96, Issue 15

[JR] I tend to agree.