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

From: Jiangyuanlong <[email-masked]>
Date: Wed, 2 May 2012 02:06:43 +0000

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

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

---

From: "Daniel Cohn" <[email-masked]>
Date: Wed, 2 May 2012 10:55:21 +0300

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.

Relying on PBB-VPLS imposes additional limitations on backward
compatibility.

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]

Hi Daniel,

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,

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]';

Hi Dan

Let me try to explain.

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]';

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]>;

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]

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

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]

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

Yuanlong,

Thanks,

DC

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

Hi Don and Josh,

Regards,
Yuanlong

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 2 May 2012 09:30:15 +0000

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,

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

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]

Hi Daniel,

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;

Hi Don,

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]';

Hi Dan

Let me try to explain.

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]';

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]>;

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]

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

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]

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

Yuanlong,

Thanks,

DC

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

Hi Don and Josh,

Regards,
Yuanlong

---

From: "Daniel Cohn" <[email-masked]>
Date: Wed, 2 May 2012 15:01:00 +0300

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]

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

Hi Daniel,

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;

Hi Don,

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]';

Hi Dan

Let me try to explain.

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]';

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]>;

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]

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

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]

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

Yuanlong,

Thanks,

DC

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

Hi Don and Josh,

Regards,
Yuanlong

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 3 May 2012 02:30:58 +0000

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]

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

Hi Yuanlong,

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]

Hi Daniel,

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;

Hi Don,

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]';

Hi Dan

Let me try to explain.

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]';

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]>;

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]

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

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]

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

Yuanlong,

Thanks,

DC

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

Hi Don and Josh,

Regards,
Yuanlong

---

From: "Rogers, Josh" <[email-masked]>
Date: Wed, 2 May 2012 22:51:19 -0400

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.

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)

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.

I hope we can move forward with one of these soon,
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
>

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: Thu, 3 May 2012 05:07:34 +0000

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.

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

[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? 

[JY] me too.

Josh

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 3 May 2012 06:56:22 +0000

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,

[JY] Indeed, we had discussed this approach during the f2f meeting in Paris. But there are restrictions as you mentioned, furthermore:
1) some vendors already use S-VLANs to distinguish their VSIs in a PE;
2) the forwarding plane of a PE needs to be revised to be aware of this VLAN and process it accordingly.
Therefore, it seemed that this approach is not a good option compared with other means.

[JY] As I am aware, configuring two S-VLANs for E-Tree E-NNI is one of the service requirements from the MEF, and it has nothing to do with the solution we used, that is, no matter what solution we adopt, the configuration of two S-VLAN is needed for E-Tree E-NNI. BTW, if configuring or signalling 2PWs for more nodes (both T-PEs and S-PEs in MS-PW) is not a problem, why configuring or signalling 2VLANs for less nodes (only T-PEs) will become a problem? Furthermore, if PW OAM is to be deployed, configuring OAM for 2PW means double our configuration work.

[JY] Are you suggesting to develop a totally new forwarding plane rather than using the Ethernet forwarding plane? I am also not sure whether "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" is a unique advantage for 2PW approach: if the egress PE is attached with pure leafs, 2VLAN approach can also separate the leaf traffic in the forwarding plane of the ingress PE and filter it; if the egress PE is attached with pure roots or with both roots and leafs, then all traffic must be transported to the egress PE and be filtered there, I see no difference for these solutions. 

[JY] Me too:)

Josh

---

From: "Rogers, Josh" <[email-masked]>
Date: Thu, 3 May 2012 11:26:52 -0400

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

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.

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:

>[JY] Indeed, we discussed this possibility during the f2f meeting in
>Paris. But, there are some restrictions as you mentioned, and
>furthermore:
>Therefore, this 'standard value' approach seems more disruptive compared
>with the other means and not a good candidate option.
>
>[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).
>
>[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?
>
>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: Fri, 4 May 2012 01:20:40 +0000

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?

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

[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?

-Josh

---

From: "Rogers, Josh" <[email-masked]>
Date: Fri, 4 May 2012 08:26:37 -0400

[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:

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

---

From: Lucy yong <[email-masked]>
Date: Fri, 4 May 2012 14:16:36 +0000

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?

-Josh

---

From: "Rogers, Josh" <[email-masked]>
Date: Fri, 4 May 2012 10:30:38 -0400

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
>
>>if
>>need

---

From: "Fedyk, Donald (Don)" <[email-masked]>
Date: Fri, 4 May 2012 09:49:49 -0500

Hi

We might do better to separate marking of the traffic from the transport mechanism in all cases.  In the 2 VLAN model in the IEEE there are multiple implementations that have varying degrees of efficiency as well. Compare for example shared VLAN learning on STP with QinQ versus PBB using SPB it is a similar argument Josh is making about efficiency.

Don

---

From: Lucy yong <[email-masked]>
Date: Fri, 4 May 2012 20:42:21 +0000

Hi Josh,

I don't understand your following statement.

- Both methods have inefficiencies (one duplicates traffic for transport,
while the other transports where it doesn't need to go).  

Both method allows the optimization to avoid transporting where it doesn't need to go.

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?

-Josh

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 7 May 2012 02:07:00 +0000

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:[email-masked]] 
Sent: Friday, May 04, 2012 8: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?

-Josh

---

From: "Rogers, Josh" <[email-masked]>
Date: Mon, 7 May 2012 00:09:07 -0400

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" <[email-masked]> wrote:

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

---

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

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Monday, May 07, 2012 12:09 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] 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.

With Multi-PW method:

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

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

-Josh

---

From: "Daniel Cohn" <[email-masked]>
Date: Mon, 7 May 2012 10:10:36 +0300

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

DC

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

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Monday, May 07, 2012 12:09 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?

With Multi-PW method:

-Josh

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 7 May 2012 08:05:30 +0000

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

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

DC

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

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Monday, May 07, 2012 12:09 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?

With Multi-PW method:

-Josh

---

From: "Daniel Cohn" <[email-masked]>
Date: Mon, 7 May 2012 11:19:44 +0300

In LDP, where PWs are established by the operator, it's part of the provisioning process. Section 6.2 provides guidelines, as follows:

   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:

   Leaf-only VSI <-> leaf-only VSI: no PWs required

   Where root-only VSI is a VSI where all ACs are of the root type, and
   leaf-only VSI is one where all ACs are of the leaf type.

Typically the NMS takes care of PW setup in LDP-VPLS so this would be part of the NMS logic.

In BGP, this can be part of the PW signaling logic following leaf-only signaling in the control flags (see sections 7.3 and 7.4). As you can see this was not defined in this version but it's a simple extension of the same logic that avoid PW setup between leaf-only PEs.

Regards,

Daniel

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

DC

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

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Monday, May 07, 2012 12:09 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?

With Multi-PW method:

-Josh

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 7 May 2012 08:31:23 +0000

It seems you had overlooked my replies to Josh. Actually, the case of PE1-PE3 as Josh described is "Root & Leaf mixed VSI <-> leaf-only VSI" and not listed in your guidelines.

But even if the guideline is complemented with this case, and no PW is set up between PE1 and PE3 as you said, how can you send root traffic (R1) from PE1 to PE3? And how can you send the leaf traffic (L3) from PE3 to PE1?

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

Regards,

Daniel

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

DC

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

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Monday, May 07, 2012 12:09 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?

With Multi-PW method:

-Josh

---

From: "Rogers, Josh" <[email-masked]>
Date: Mon, 7 May 2012 12:36:22 -0400

Comment Inline:

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

>[JY] Since PE3 is a leaf-only node, the PW from PE1 to PE3 will work in
>Optimized-Mode. According to Section 5.3.3 of
>draft-jiang-l2vpn-vpls-pe-etree-05, it will be dropped before arriving at
>this PW. Therefore, this frame will not arrive at PE3.
[JR] Correct, in my example I was assuming no optimization.  See my later
comment about adding complexity for the sake of optimization (which is not
a problem, just an observation, the same observation holds true for
multi-PW method.)
>There should be 2 PWs be set up between PE1 and PE3, since this is a case
>of "Root & Leaf mixed VSI <-> leaf-only VSI" and not listed in the
>none-two- interconnecting-PWs criteria. Therefore, this frame will be
>sent to PE3 twice (one on root PW, another on leaf PW) IMO. Of course,
>the other authors of draft-ram-l2vpn-etree-multiple-pw-01 may have more
>to say on this point.
[JR] Remember that PW's are unidirectional, we should consider setup in
each direction independently:

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

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

>the PE which has no root AC's".
[JR] Sorry, I got confused on my only topology and was thinking PE3 was
root-only.  Frame would arrive at PE3 (on the root-sourced PW) where it
would forward to all AC's.  Sorry I botched the explanation, I hope the
idea was not lost in the confusion.

>>>>2) Forwarding plane of a PE needs to be revised to be aware of this
>>>>VLAN
>>>>ID.

---

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

Josh,

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

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

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

VPLS requires PW associating with a VSI not an AC.

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

Comment Inline:

---

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

Lucy, you are correct here.  Some of what I stated in my email last night
was incorrect, due to late-night confusion on my part.  In a mixed to
mixed transmission of broadcast, depending on the source AC, the packet
will only be placed on one PW (a very important detail I overlooked), so
there is no duplication.

With 2VLAN, there is no considerable difference, the frame will be tagged
with the appropriate S-Tag based on the source AC type, and forwarded
across the PW once.

I apologize for the confusion I created, thank you for clearing it up.

Regarding the statement of VPLS requiring PW associating with VSI, not an
AC, I agree that is the current application of VPLS, and is fundamentally
what is wrong with VPLS.  By associating with an AC instead, we are
afforded the flexibility to do more interesting things...  Like ETREE.

-Josh

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

>Josh,
>
>Thank you to provide the following needed PW for multi-PW solution. The
>left side of "=" sign represent PE->PE and the right side is needed PW.
>We are on the same table now. In addition, I add Dual VLAN for comparison.
>
>Multi-PW                                     Dual-VLAN
>Both methods let ingress PE marking and filtering all known unicast
>packets in mixed->mixed case. In the case, only a broadcast packet at
>mixed PE needs to be forwarded to another mixed PE with the mark, but the
>packet is sent once and no need to duplicate.
>
>>>>>>[mailto:[email-masked]]
>>>>>>[mailto:[email-masked]]

---

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

Hi Josh, 

Correcting "fundamentally what is wrong with VPLS" is out scope of the current L2VPN charter, so let us discuss it no more.
But to support the scenario as you detailed (take P1-PE3 as an example) with just one PW as you proposed:
Leaf-only -> mixed = one PW
Mixed -> leaf-only = one PW
According to draft-ram-l2vpn-etree-multiple-pw-01: "Signaling of root and leaf PWs is required only when two PWs are used for interconnecting between pair of VSIs", so the PW would be just an traditional PW, but how can PE1 know that the only PW from PE3 is carrying leaf traffic?
Therefore, it seems inevitably 2PW approach needs to associate root/leaf attributes with every PW and store these attributes per PW in the forwarding plane so that the root/leaf traffic can be forwarded or dropped accordingly.
Thus it seems you need to change the control plane and data plane for 2PW to support this scenario.

Regards,
Yuanlong

-----Original Message-----
From: Rogers, Josh [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 5:26 AM
To: Lucy yong; Jiangyuanlong; Daniel Cohn; Fedyk, Donald (Don); Henderickx, Wim (Wim)
Cc: [email-masked]
Subject: Re: The status of the approaches to the E-Tree solution?

-Josh