RE: Discussion on E-Tree and H-VPLS

[Jiangyuanlong <[e-mail]>]

Hi Sam,

Your statements are misleading at best IMHO, but let us go over the original question from YOU to see what problem is behind.

You believe it make no sense that:
>>For VPWS access, we should configure Root/Leaf for Spoke PW;
>>for VPLS access, we CAN NOT configure Root/Leaf for Spoke PW.

Not so correct, speaking more exactly, the dual-VLAN will:
In the 1st case, each root/leaf AC (attached to a PE-r) has a corresponding Spoke PW connecting to the PE-rs, so we configure the Root/Leaf attribute for the Spoke PW on the PE-rs;
In the 2nd case, all root/leaf AC (attached to a MTU-s) share a single Spoke PW connecting to the PE-rs, so we configure the Root/Leaf attribute for the AC on the MTU-s.

We exchanged several emails on this topic and reached no agreement on what you said, just simply take a snip from the email (thank Giles):
"
On 24/04/2012 10:25, "Sam Cao" <[e-mail]> wrote:

> Giles,
> > Configure Root/Leaf on MTU-s and have the MTU-s add the root/Leaf 
> VLAN. It is correct and reasonable for Fig. 3. We can not configure it 
> on PE1-rs anymore.

Right.
 
> In Fig. 4, shall we configure on PE-r? It seems not reasonable since 
> on PE-r, it is VPWS. So in Fig. 4, we will have to configure on 
> PE1-rs. PE1-rs has different behavior in the 2 cases. This does not make sense for me :).

For PE-r each spoke is root or leaf.  It can't be both.  And yes, it's VPWS not VPLS.  So it makes more sense to configure on the PE-rs.  Quite possibly the VPWS would be untagged in that instance...
"

Therefore, the fact is, two of us thought it make sense, and the third regarded it as non sense^&^

Let us go over your conclusion again:
>> Multi-PW has no problem on this: Configure Root or Leaf on PE1-rs in the 2
>> cases since it uses different PATH, not inferring context in frame.
It seems you prefer to configuring root/leaf attribute for Spoke PW on PE-rs in both cases.
>From the previous email to Lizhong, you agreed that in the 1st use case, configuration of root/leaf attribute for the ACs is further needed on the PE-r,
and I believe in the 2nd use case, configuration of root/leaf attribute for the ACs is also needed on the MTU-s (otherwise, how can the 2PW use different PATH?), so that 2 PWs can be set up to carry the E-Tree traffic.

Now we can compare the Dual-VLAN with 2PW approach to see what is different:
In the 1st case, both configure the Root/Leaf attribute for the Spoke PW on the PE-rs; and 2PW will further configure the Root/Leaf attribute for the AC on the PE-r.
In the 2nd case, both configure the Root/Leaf attribute for the AC on the MTU-s, and 2PW will further configure the Root/Leaf attribute for the Spoke PW on the PE-rs.
In both cases, configuration for Dual-VLAN is simpler, so, does a more complex configuration really make more sense to you?

Regards,
Yuanlong


----------------------------------------------------------------------
Date: Wed, 9 May 2012 09:40:12 +0800
From: "Sam Cao" <[e-mail]>
To: <[e-mail]>
Cc: [e-mail]
Subject: RE: Discussion on E-Tree and H-VPLS
Message-ID: <D8A170B760DE4CACA680B7C6737926BF@R01842>
Content-Type: text/plain;	charset="gb2312"

Hi Lizhong?

Thank you very much for your comments. I updated the result on this
question.

[Lizhong] agree with the above analysis. And we did not say it is a
technical problem, but it is an operational problem again.
[Sam] I agree. Dual-VLAN does not make sense. I also discussed this with
Giles and Yuanlong in another mail, and we reached agreement on this: MTU
should know the access mode, VPWS or VPLS, VPWS mode should configure VLAN
ID on MTU but VPLS mode can not. I thought this is NOT reasonable :), but we
can figure this out in draft. It seems ok.

[Lizhong] not fully understand. Do you mean,  when VPWS accessing for
H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW)
for each AC access?
[Sam] Yes.

Thanks,

Sam

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Monday, May 07, 2012 3:00 AM
To: [e-mail]
Subject: L2vpn Digest, Vol 96, Issue 21

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

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

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



Send L2vpn mailing list submissions to
	[e-mail]

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

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

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


Today's Topics:

   1. RE: Discussion on E-Tree and H-VPLS (Lizhong Jin)
   2. RE: Discussion on E-Tree and H-VPLS (Lizhong Jin)


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

Message: 1
Date: Sun, 6 May 2012 18:22:14 +0800
From: Lizhong Jin <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: Discussion on E-Tree and H-VPLS
Message-ID:
	<CAH==cJxWepSvxeGshyQMcyUR7z1k-iuqu9=[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"

Hi Sam,
See inline below.

Thanks
Lizhong

----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 24 Apr 2012 11:51:26 +0800
> From: "Sam Cao" <[e-mail]>
> To: "'Jiangyuanlong'" <[e-mail]>
> Cc: [e-mail]
> Subject: RE: Discussion on E-Tree and H-VPLS
> Message-ID: <DDFE90371E3C40D988E43EB0DA2FCB78@R01842>
> Content-Type: text/plain;       charset="GB2312"
>
> Yuanlong,
>
> Ok. Go on H-VPLS discussion although there are so many pending issues on
> Dual-VLAN.We can go one by one, :) I thought this for many times, it may
be
> disadvantage of Dual-VLAN.
>
> In general, if MTU can NOT support Layer 2 switching, we will use P2P
> access
> (I called this as VPWS access); if MTU can support Layer 2 switching, we
> can
> use P2P or MP2MP access (I called the later as VPLS spoke access). Both
are
> active deployment. Josh has given us one real deployment in real network.
> We
> can hold the opposite opinions, but this is really requirements from
> carriers. In Josh's example, even if MTU-s can support L2 switching, it
> also
> should work in VPWS mode.
>
> As I know, most vendors support 2 deployments. Then focus on VPWS
> deployment
> and PE-rs (Fig.4), we should appoint one VPWS access (On PE-r, it is VPWS;
> on PE1-rs, it is really Spoke PW. In this case, there is 1 or more PWs
> between PE-r AND PE1-rs) Root or Leaf. As you know, we can not appoint on
> PE-r since we have no extension to VPWS. You explained it in your reply to
> Josh's mail. I agree. Then go to Fig. 3. MTU-s can support L2 switching,
so
> only 1 PW (1 PW is requirement from RFC 4762, but 2 or more PWs has no
> problem) between MTU-s and PE1-rs. This is also spoke PW. Can we appoint
> Root/Leaf for the Spoke PW? No. The root cause is, we can not appoint
> access
> type, Root or Leaf, anymore since MTU-s has added S-VLAN-ID into frame.
> This
> is my question: For VPWS access, we should configure Root/Leaf for Spoke
> PW;
> for VPLS access, we CAN NOT configure Root/Leaf for Spoke PW.
>
[Lizhong] agree with the above analysis. And we did not say it is a
technical problem, but it is an operational problem again.

>
> Multi-PW has no problem on this: Configure Root or Leaf on PE1-rs in the 2
> cases since it uses different PATH, not inferring context in frame.
>
[Lizhong] not fully understand. Do you mean,  when VPWS accessing for
H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf PW)
for each AC access?


> Thanks,
>
> Sam
>
> -----Original Message-----
> From: Jiangyuanlong [mailto:[e-mail]]
> Sent: Monday, April 23, 2012 7:23 PM
> To: Sam Cao
> Cc: [e-mail]
> Subject: Discussion on E-Tree and H-VPLS
>
> Sam,
>
> Please see my comments in line. I also change the title to reflect the
> topic.
>
> Regards
> Yuanlong
>
> -----Original Message-----
> From: Sam Cao [mailto:[e-mail]]
> Sent: Monday, April 23, 2012 11:28 AM
> To: Jiangyuanlong
> Cc: [e-mail]
> Subject: RE: L2vpn Digest, Vol 95, Issue 58
>
> Yuanlong,
>
> I do apologize for my unclear description. I try to make it clear.
>
> VPWS or Spoke PW, PE-rs will take the PW as Spoke PW. Or say, PE-rs really
> does NOT care remote access is VPWS access (point-to-point, Fig. 3) or
VPLS
> spoke access (Fig. 4). PE-rs just know it is spoke PW and it is ENOUGH,
and
> does NOT care customer payload. is this correct?  At least it is correct
in
> RFC 4762.
> [JY] why divide the remote access to VPWS access and VPLS access?
>
> But, if remote is VPWS access (Fig. 3), PE-rs SHOULD configure AC-type for
> remote VPWS access although it is still spoke PW in E-Tree. Please refer
to
> your answer to Josh's question. It seems reasonable. Ok, we think another
> case in Fig. 4. In Fig. 4, PE-rs CAN NOT configure AC-type at all in this
> case. In fact, on MTU-s it is VPLS and we should configure AC type on
> MTU-s.
> [JY] Quite opposite, in case of Fig.4, IMHO, it is better to configure the
> E-Tree attribute on the PE-rs since the PE-r does not support any bridging
> functions. I think this case is provided in RFC4762 just to be compatible
> with some legacy routers.
>
>
> Ok, problem came up for me. For spoke PW on PE-rs, in one case it should
> configure AC type and work as agent; in another case, it can NOT configure
> AC type and can not work as agent. In fact, PE-rs knows it is spoke PW, it
> is enough; why spoke-PW has different configuration in same VPLS instance
> on
> same PE? I am confused although I know why we should configure in that
way.
>
> I prefer not to configure AC type on PE-rs since we can take it as
> "Switching PE" (NOT pefact here and it is not real "Switching Point")
which
> does NOT aware customer payload. Extension to VPWS? Seems not reasonable.
> [JY] Not sure I got your points. PE-rs will terminate the PW and switch
the
> Ethernet frames. IMO, whether configuring the E-Tree service on a PE-rs or
> a
> MTU-s is dependent on the topology of the service and how they are
> attached.
> H-VPLS can be seen as a transparent transport network, or as a service
> itself.
>
> Thanks,
>
> Sam
>
> -----Original Message-----
> From: Jiangyuanlong [mailto:[e-mail]]
> Sent: Monday, April 23, 2012 9:59 AM
> To: Sam Cao
> Cc: [e-mail]
> Subject: RE: L2vpn Digest, Vol 95, Issue 58
>
> Hi Sam,
>
> If E-Tree service is provided in a scenario as Fig. 3 and Fig 4 in RFC
> 4762,
> then a CE (leaf or root) is connected to the MTU-s or PE-r, thus the AC
> should be terminated and the E-Tree service should be encapsulated by the
> MTU-s or PE-r. I don't quite understand why you need to "take VPWS PW as
> one
> AC", but even in that case, the attribute of the AC may be configured at
> the
> PE-rs. So what is the problem for H-VPLS?
>
> Thanks
> Yuanlong
>
> Date: Sun, 22 Apr 2012 22:03:52 +0800
> From: "Sam Cao" <[e-mail]>
> To: "'Jiangyuanlong'" <[e-mail]>
> Cc: [e-mail]
> Subject: RE: The status of the approaches to the E-Tree solution?
> Message-ID: <962A848896EF4678B17D76C826A7EAEF@v2comsam>
> Content-Type: text/plain;       charset="us-ascii"
>
> Yuanlong,
>
> I just collect all issues we discussed before, and we still can not make
> agreement. I gave my comments on 2 items below. I will think other items
> over and give my comments tomorrow.
>
> 2) HVPLS: If we follow Fig 3 or Fig 4 in RFC 4762 to deploy HVPLS,
> PE-rs works in different manner, PE-rs should figure out AC type in VPWS
> case, but can NOT configure it at all in Spoke PW case;
> [JY] In the first place, why PE-rs need to figure out the AC type for a
> spoke? The VLAN should be processed in the MTU, not in the PE-rs.
> [Sam] Yuanlong, I understand your idea. It does NOT make sense for me.
> First, Fig. 3 and Fig 4 in RFC 4762 are different cases. For VPWS (Fig.
3),
> we can take VPWS PW as one AC. You know, PE-rs is termination of VPWS, so
> it
> will add VLAN-ID to identify Root/Leaf. BTW, you will map several VLAN IDs
> into one Root-VLAN ID or Leaf-VLAN ID on PE-rs, so we need to configure
> Root/Leaf on PE-rs (Refer to your reply to Josh's comments).
>
> 4)  Encapsulation mode: If deploy HVPLS with Spoke PW mode, PE-rs
> should work in tagged mode, otherwise PE-rs or egress PE will stripe
S-VLAN
> ID;
> [JY] Is anything not working with tagged PW mode?
> [Sam] Tagged mode works.
>
> Regards,
>
> Yuqun (Sam) Cao
> E-mail: [e-mail]
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/l2vpn/attachments/20120506/db58240c/at
tachment.htm>

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

Message: 2
Date: Sun, 6 May 2012 18:25:59 +0800
From: Lizhong Jin <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: Discussion on E-Tree and H-VPLS
Message-ID:
	<CAH==[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"

>
>
> ------------------------------
>
> Date: Tue, 24 Apr 2012 11:59:33 +0800
> From: "Sam Cao" <[e-mail]>
> To: "'Alexander Vainshtein'" <[e-mail]>,
>        "'Jiangyuanlong'" <[e-mail]>
> Cc: [e-mail]
> Subject: RE: Discussion on E-Tree and H-VPLS
> Message-ID: <F2158A3367414E3E82DE340F17186FE7@R01842>
> Content-Type: text/plain;       charset="GB2312"
>
> Sasha,
>
> Just as we discussed for many times, 3 approaches use different
> identifiers.
> For me, Multi-PW uses different PATH (Multi-PW), but CW or Dual-VLAN uses
> inferring context in frames.
>
> So CW also has same HVPLS deployment problem.
>
[Lizhong]  no, the CW approach is OK. The PE-r with VPWS could support CW,
and add leaf/root indication in the packet.

Thanks
Lizhong


> Thanks,
>
> Sam
>
> -----Original Message-----
> From: Alexander Vainshtein [mailto:[e-mail]]
> Sent: Monday, April 23, 2012 7:33 PM
> To: Jiangyuanlong; Sam Cao
> Cc: [e-mail]
> Subject: RE: Discussion on E-Tree and H-VPLS
>
> Sam, Yuanlong and all,
>
> ------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/l2vpn/attachments/20120506/0c223327/at
tachment.htm>

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

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


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



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

Message: 2
Date: Wed, 9 May 2012 02:26:34 +0000
From: Jiangyuanlong <[e-mail]>
To: Daniel Cohn <[e-mail]>, "Rogers, Josh"
	<[e-mail]>, Lucy yong <[e-mail]>, Sam Cao
	<[e-mail]>, "[e-mail]" <[e-mail]>
Subject: OAM problem for 2PW
Message-ID:
	<[e-mail]>
	
Content-Type: text/plain; charset="us-ascii"

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

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:[e-mail]] 
Sent: Tuesday, May 08, 2012 9:59 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [e-mail]
Subject: RE: L2vpn Digest, Vol 96, Issue 15


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

Message: 3
Message-ID: <[e-mail]>

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 c=
oupled to provide an end to end E-Tree service, things will be quite differ=
ent 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 s=
omething?

DC

-----Original Message-----
From: Jiangyuanlong [mailto:[e-mail]]=20
Sent: Tuesday, May 08, 2012 4:38 PM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [e-mail]
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:[e-mail]]=20
Sent: Tuesday, May 08, 2012 9:29 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [e-mail]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

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:[e-mail]]=20
Sent: Tuesday, May 08, 2012 4:23 PM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [e-mail]
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:

      ---                                                   ---
     /   \         ------      -------      ----           /   \
     | 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:[e-mail]]=20
Sent: Tuesday, May 08, 2012 4:49 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [e-mail]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Inline

-----Original Message-----
From: Jiangyuanlong [mailto:[e-mail]]=20
Sent: Tuesday, May 08, 2012 11:42 AM
To: Daniel Cohn; Rogers, Josh; Lucy yong; Sam Cao; [e-mail]
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:[e-mail]]=20
Sent: Tuesday, May 08, 2012 4:28 PM
To: Jiangyuanlong; Rogers, Josh; Lucy yong; Sam Cao; [e-mail]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

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: [e-mail] [mailto:[e-mail]] On Behalf
Of Jiangyuanlong
Sent: Tuesday, May 08, 2012 7:04 AM
To: Rogers, Josh; Lucy yong; Sam Cao; [e-mail]
Subject: RE: L2vpn Digest, Vol 96, Issue 15

Josh,=20

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

...snipped....


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

Message: 4
Date: Wed, 9 May 2012 10:38:56 +0800
From: "Sam Cao" <[e-mail]>
To: <[e-mail]>
Subject: RE: L2vpn Digest, Vol 96, Issue 23
Message-ID: <264B3435378241FA9BE008620B246DEA@R01842>
Content-Type: text/plain;	charset="gb2312"

Josh,

Optimization on ingress PE is possible. Last week I thought this over and
have a clear idea. We maybe discuss this in another mail, and if all agree,
we can add this into new draft. As you know, Multi-PW negotiates AC type via
signal protocol, so one PE can know AC types of its peer, and then we can
solve the problem you raised.

Thanks,

Sam


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

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

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

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



Send L2vpn mailing list submissions to
	[e-mail]

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

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

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


Today's Topics:

   1. Re: The status of the approaches to the E-Tree solution?
      (Rogers, Josh)
   2. RE: The status of the approaches to the E-Tree solution?
      (Jiangyuanlong)


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

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

So, if you can imagine three PE's, PE1, PE2 and PE3.  PE1 has a root AC,
R1 and a leaf AC, L1.  PE2 also has a root AC, R2, and a leaf AC, L2.  PE3
has a leaf AC, L3.

Consider an unknown unicast frame from the leaf site L1, and also another
unknown unicast frame from R1 entering.

With the 2VLAN method (to my best understanding):
  - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3,
arrives at PE2 which decides that it should be flooded out all Root AC's,
based on the S-tag.  It also arrives at PE3, where it is dropped because
there are no root AC's.
  - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3,
arrives at PE2 which decides that it should be flooded out all AC's, based
on S-tag.  It also arrives at PE3 where it is forwarded to all root AC's.

With Multi-PW method:
  - frame from L1 enters PE1, which decides to forward the frame out the
'root' PW to PE2, which in turn floods out all Root AC's, based on
arriving PW type.  Frame is NOT sent to PE3, since there is no PW built to
the PE which has no root AC's.
  - frame from R1 enters PE1, which decides to flood out both 'root' PW
and 'leaf' PW to PE2, which in turn floods out the same AC types, based on
arriving PW type.  It also arrives at PE3 where it is forwarded to all
root AC's.

I suppose optimization could be done on the ingress PE to decide that
there is no need to 'flood' root-sourced frames to two PW's that have the
same egress PE, but instead to only forward to the 'root' type PW, when
both exist, because we know that the egress PE will flood frames from
root-sourced PW's out both leaf and root AC's.

In this example, the same frame from R1 is duplicated on the PE1-PE2 path
(if no optimization is done.), where it would not be with the 2VLAN method.

With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's,
otherwise how would we classify source AC-type?), which means there is
overhead on EVERY frame to add the s-tag for the sole purpose of
classifying the frame.  If optimization is done, then each ingress PE
knows what types of AC's are on each egress PE, and only forwards the
appropriate frame, if no optimization then it is dropped at the egress PE.

In short, both are either not 100% inefficient, or are additionally
complex due to 'optimization'.

I may have gotten my details off on the optimization piece of the 2VLAN
method, please correct me if I didn't get the details 100% correct.


-Josh



On 5/6/12 9:07 PM, "Jiangyuanlong" <[e-mail]> wrote:

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


This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the
contents of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify the
sender immediately and permanently delete the original and any copy of this
E-mail and any printout.


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

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


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

So, if you can imagine three PE's, PE1, PE2 and PE3.  PE1 has a root AC,
R1 and a leaf AC, L1.  PE2 also has a root AC, R2, and a leaf AC, L2.  PE3
has a leaf AC, L3.

Consider an unknown unicast frame from the leaf site L1, and also another
unknown unicast frame from R1 entering.

With the 2VLAN method (to my best understanding):
  - frame from L1 enters PE1, goes into a PW to PE2 and a PW to PE3,
arrives at PE2 which decides that it should be flooded out all Root AC's,
based on the S-tag.  It also arrives at PE3, where it is dropped because
there are no root AC's.

[JY] Since PE3 is a leaf-only node, the PW from PE1 to PE3 will work in
Optimized-Mode. According to Section 5.3.3 of
draft-jiang-l2vpn-vpls-pe-etree-05, it will be dropped before arriving at
this PW. Therefore, this frame will not arrive at PE3.

  - frame from R1 enters PE1, goes into a PW to PE2 and a PW to PE3,
arrives at PE2 which decides that it should be flooded out all AC's, based
on S-tag.  It also arrives at PE3 where it is forwarded to all root AC's.

With Multi-PW method:
  - frame from L1 enters PE1, which decides to forward the frame out the
'root' PW to PE2, which in turn floods out all Root AC's, based on
arriving PW type.  Frame is NOT sent to PE3, since there is no PW built to
the PE which has no root AC's.

[JY] According to my understanding of the following description in
draft-ram-l2vpn-etree-multiple-pw-01:
  "It should be noted that in a full-mesh VPLS (as opposed to H-VPLS),
   the following VSI pair types do not require two interconnecting PWs:
   Root-only VSI <-> any VSI: only root PW required
   Leaf-only VSI <-> leaf-only VSI: no PWs required"
There should be 2 PWs be set up between PE1 and PE3, since this is a case of
"Root & Leaf mixed VSI <-> leaf-only VSI" and not listed in the none-two-
interconnecting-PWs criteria. Therefore, this frame will be sent to PE3
twice (one on root PW, another on leaf PW) IMO. Of course, the other authors
of draft-ram-l2vpn-etree-multiple-pw-01 may have more to say on this point.

  - frame from R1 enters PE1, which decides to flood out both 'root' PW
and 'leaf' PW to PE2, which in turn floods out the same AC types, based on
arriving PW type.  It also arrives at PE3 where it is forwarded to all
root AC's.

[JY] It contradicts your first statement that "there is no PW built to the
PE which has no root AC's". 

I suppose optimization could be done on the ingress PE to decide that
there is no need to 'flood' root-sourced frames to two PW's that have the
same egress PE, but instead to only forward to the 'root' type PW, when
both exist, because we know that the egress PE will flood frames from
root-sourced PW's out both leaf and root AC's.

In this example, the same frame from R1 is duplicated on the PE1-PE2 path
(if no optimization is done.), where it would not be with the 2VLAN method.

With 2VLAN, ethernet type PW's cannot be used (must be vlan type PW's,
otherwise how would we classify source AC-type?), which means there is
overhead on EVERY frame to add the s-tag for the sole purpose of
classifying the frame.  If optimization is done, then each ingress PE
knows what types of AC's are on each egress PE, and only forwards the
appropriate frame, if no optimization then it is dropped at the egress PE.

In short, both are either not 100% inefficient, or are additionally
complex due to 'optimization'.

I may have gotten my details off on the optimization piece of the 2VLAN
method, please correct me if I didn't get the details 100% correct.


-Josh



On 5/6/12 9:07 PM, "Jiangyuanlong" <[e-mail]> wrote:

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


This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the
contents of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify the
sender immediately and permanently delete the original and any copy of this
E-mail and any printout.


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

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


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



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

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


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