Subject: Re: [PWE3] comments on draft-delord-pwe3-cw-bit-etree-02

From: Jiang Yuanlong <[email-masked]>
Date: Fri, 02 Apr 2010 12:05:43 +0800

Hi Simon,

It seems no one has answered this question, so I throw out my 2 cents just for discussion.

IMO, both PEs will need two VSIs to support the multi-root E-Tree, i.e., the PE1 will split
the root traffic and leaf traffic into seperate VSIs, and by way of seperate PWs, into the
two corresponding VSIs in PE2. There is no need for an internal connection between the two 
VSIs in a PE.
Therefore, this use case is different from A.8-A.10 in your draft.
I hope Shahram, Luca or someone else will clarify this point.

Regards
Yuanlong

  ----- Original Message ----- 
  From: Simon Delord 
  To: pwe3 
  Sent: Thursday, April 01, 2010 7:09 AM
  Subject: [PWE3] comments on draft-delord-pwe3-cw-bit-etree-02

  Dear all,

  I'm just going through the IETF77 PWE3 minutes and would like to understand more regarding questions raised during the presentation of draft-delord-pwe3-cw-bit-etree-02.

  Extract from minutes

  "Shahram Davari: why can you use two PWs for this one for leave, one for root."

  [SD] Shahram, when you say 2 PWs, one for leave one for root, do you mean the solution described in Appendix A.10 of draft-key-l2vpn-etree-frwk? 

  (

  http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-02#appendix-A) 
  If not, is it A.8 or A.9 or something different?

  Regards,

  Simon 

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

  _______________________________________________
  pwe3 mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/pwe3

---

From: Simon Delord <[email-masked]>
Date: Wed, 7 Apr 2010 13:32:03 +1000

Hi Dave,

Some follow-up regarding the presentation of
draft-delord-pwe3-cw-bit-etree-02 during last IETF meeting.

Extract from PWE3 minutes
Dave Allan: No it isn't. Using a CW to demultiplex and
forward changes existing behavior and breaks OAM.  Two
PWs are simpler and don't break anything.

[SD] Our proposed solution does not use control word to
demultiplex (no change from current standard, demultiplex
based on PW label only). Please see
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02#section-4.3

[SD] Can you explain a bit more on why our proposed solution
"breaks OAM"?

[SD] Is the "Two PWs" approach you mentioned similar to
the "Separate PWs" described in Appendix A.10 of
http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-02#appendix-A
If not, is it similar to the "Separate VSI" in A.8 or A.9,
or something totally different?

Regards,
Simon

---

From: David Allan I <[email-masked]>
Date: Wed, 7 Apr 2010 09:30:29 -0400

Hi Simon:

Thanks for following up on this....

I have trouble with the concept of a single VSI as both root and leaf, as I'd consider it to be a rare case that this would occur in a practical implementation/practical deployment scenario. Adds, moves and changes mitigate against any sustained consolidation of such functions on a common sub-system in a PE. What it means to me is setting aside ports any time a customer port is added on the expectation that I may have an opportunity to consolidate VSIs at some undetermined point in the future. That does not strike me as an economically practical model.

My comments stem from the implications of this...I suspect there is a misunderstanding on my part as I assume in the common VSI model of fig 1 there is no intention to use the L bit for steering of traffic within a chassis. I now understand it is only used internal to a consolidated VSI. hence for the IMO rare case where both root and leaf ports are on a common sub-system on a common line facing card. My bad.

The reference to OAM is that currently MPLS MIBs maintain counters for a label (including PWs), if there is an extra bit involved (L bit), then the traffic to root or leaf cannot be disambiguated for OAM purposes without instantating separate counters above and beyond that which already exists.

My reference to "two PWs" is predicated on separate VSIs. IMO clean separation of role, OAM etc. I do not actually see an example in Appendix A of the framework that provides separate VSIs for root or leaf ports.

So I am still not a fan of the "L" bit as it is solving a problem that IMO a carrier needs to work hard to make exist...Separate VSIs fits the operational model much more tractably..and simply uses what exists today. And according to my math, for every leaf co-located with a root but implemented as a separate VSI adds two PWs (one for each direction) to any spared roots. If I assume #of leaves >> # of roots, the overally reduction of the number of PWs using the L bit is trivial...

hope that clarifies my comments...
Dave

________________________________
From: Simon Delord [mailto:[email-masked]]
Sent: Tuesday, April 06, 2010 11:32 PM
To: pwe3; David Allan I
Subject: Re: comments on draft-delord-pwe3-cw-bit-etree-02

Hi Dave,

Regards,
Simon

---

From: Simon Delord <[email-masked]>
Date: Wed, 14 Apr 2010 08:54:51 +1000

Dave,
thanks for your reply, please see some comments in-line.
sante!

Simon

2010/4/7 David Allan I <[email-masked]>

> I have trouble with the concept of a single VSI as both root and leaf,
> as I'd consider it to be a rare case that this would occur in a practical
> implementation/practical deployment scenario. Adds, moves and changes
> mitigate against any sustained consolidation of such functions on a common
> sub-system in a PE. What it means to me is setting aside ports any time a
> customer port is added on the expectation that I may have an opportunity to
> consolidate VSIs at some undetermined point in the future. That does not
> strike me as an economically practical model.
>
> My comments stem from the implications of this...I suspect there is a
> misunderstanding on my part as I assume in the common VSI model of fig
> 1 there is no intention to use the L bit for steering of traffic within a
> chassis. I now understand it is only used internal to a consolidated VSI.
> hence for the IMO rare case where both root and leaf ports are on a common
> sub-system on a common line facing card. My bad.
>

 [SD] excellent, we're on the same page regarding the use of the L-bit
in the CW proposal then.

>
> The reference to OAM is that currently MPLS MIBs maintain counters for a
> label (including PWs), if there is an extra bit involved (L bit), then the
> traffic to root or leaf cannot be disambiguated for OAM purposes without
> instantating separate counters above and beyond that which already exists.
>
> My reference to "two PWs" is predicated on separate VSIs. IMO clean
> separation of role, OAM etc. I do not actually see an example in Appendix A
> of the framework that provides separate VSIs for root or leaf ports
>

 [SD] actually A8 and A9 present two options using two VSIs.

A8 is showing the case where one PE connects  Roots into one VSI and Leafs
into another VSI (PE2), and the other PE has a single VSI for both roots and
leaf (PE1).
Because the leafs on PE2 also need to talk to the roots on PE2 (and vice
versa), there is an "internal" connection between the two VSIs on PE2.

A9 presents a similar case but instead of using an internal connection
between the two VSIs on PE2, there is one "external" physical link.

The more generic case of multiple VSIs on multiple PEs can then be extended
from these two by replicating PE2 several times, but maybe this is not clear
enough from the diagrams, what do you think?

>  .
>
> So I am still not a fan of the "L" bit as it is solving a problem that IMO
> a carrier needs to work hard to make exist...Separate VSIs fits the
> operational model much more tractably..and simply uses what exists today.
> And according to my math, for every leaf co-located with a root but
> implemented as a separate VSI adds two PWs (one for each direction) to any
> spared roots. If I assume #of leaves >> # of roots, the overally reduction
> of the number of PWs using the L bit is trivial...
>

 [SD] actually, we've just published another document of requirements
related to E-Tree (
http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-00). This
'requirement draft' hopefully can be used as a base for 'solution-neutral'
discussion on whether there is a requirement to enhance VPLS or not. We'd
appreciate if you could review and give comments.

>  ------------------------------
> *From:* Simon Delord [mailto:[email-masked]]
> *Sent:* Tuesday, April 06, 2010 11:32 PM
> *To:* pwe3; David Allan I
> *Subject:* Re: comments on draft-delord-pwe3-cw-bit-etree-02
>
>   Hi Dave,
>

---

From: David Allan I <[email-masked]>
Date: Wed, 14 Apr 2010 06:39:41 -0400

HI Simon:

[SD] excellent, we're on the same page regarding the use of the L-bit in the CW proposal then.

[DA] yes, but as I've indicated, I think it is for a case that will be incredibly rare if simply allowed to happen due to random chance, and uneconomical to explicitly operationalize around. And IMO the disadvantages (loss of disambiguation of OAM counts) outweigh the advantages (two less PWs)...

My reference to "two PWs" is predicated on separate VSIs. IMO clean separation of role, OAM etc. I do not actually see an example in Appendix A of the framework that provides separate VSIs for root or leaf ports

[DA] I was looking for an example whereby the root and leaf VSIs were distinct function. This is still combined root/leaf in one VSI, even if more than one on a platform.

A8 is showing the case where one PE connects  Roots into one VSI and Leafs into another VSI (PE2), and the other PE has a single VSI for both roots and leaf (PE1).
Because the leafs on PE2 also need to talk to the roots on PE2 (and vice versa), there is an "internal" connection between the two VSIs on PE2.

A9 presents a similar case but instead of using an internal connection between the two VSIs on PE2, there is one "external" physical link.

The more generic case of multiple VSIs on multiple PEs can then be extended from these two by replicating PE2 several times, but maybe this is not clear enough from the diagrams, what do you think?

[DA] it always presents the IMO very rare complex cases (roots and leaves co-located on common sub-system) instead of the likely high runners. Leaf on one PE, root on another.
.

[SD] actually, we've just published another document of requirements related to E-Tree (http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-00). This 'requirement draft' hopefully can be used as a base for 'solution-neutral' discussion on whether there is a requirement to enhance VPLS or not. We'd appreciate if you could review and give comments.

[DA] I'll give it a look

best
D

________________________________
From: Simon Delord [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, April 06, 2010 11:32 PM
To: pwe3; David Allan I
Subject: Re: comments on draft-delord-pwe3-cw-bit-etree-02

Hi Dave,

Regards,
Simon

---

From: "Mallette, Edwin" <[email-masked]>
Date: Wed, 14 Apr 2010 07:55:49 -0400

Dave,

If I understand you correctly, you're asserting that the case where you would have root and leaf AC on the same PE to be rare?  Speaking as an operator, 25%+ of our E-Tree requests do in fact have leaf and root ACs landing on the same PE.   Certainly other operators may have varying observations, but this specific case is certainly not incredibly rare as you suggest.

Just my 2c.

-          Ed

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, April 14, 2010 6:40 AM
To: Simon Delord
Cc: pwe3
Subject: Re: [PWE3] comments on draft-delord-pwe3-cw-bit-etree-02

HI Simon:

[DA] I'll give it a look

best
D

Hi Dave,

Regards,
Simon

________________________________
CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.

________________________________
CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.

---

From: David Allan I <[email-masked]>
Date: Wed, 14 Apr 2010 08:29:06 -0400

HI Edwin:

Appreciate the input...

"Same PE" I can believe if we are discussing BRAS sized PE's (e.g. 30000 customer facing ports)....or services with significant numbers of leaves....I'm be curious as to some aspects of your network simply as a reality check....

Same subsystem on a specific PE IMO would require a front end grooming system (e.g. non-blocking Ethernet switching) and virtualization on the UNI facing PE interfaces to specifically line them up. Again possible and not necessarily what I was thinking of... but then the architecture is starting to simplify as most of the ETREE is actually in the grooming system (the front end spokes)....

D

________________________________
From: Mallette, Edwin [mailto:[email-masked]]
Sent: Wednesday, April 14, 2010 7:56 AM
To: David Allan I; Simon Delord
Cc: pwe3
Subject: RE: comments on draft-delord-pwe3-cw-bit-etree-02

Dave,

Just my 2c.

-          Ed

HI Simon:

[DA] I'll give it a look

best
D

Hi Dave,

Regards,
Simon

---

From: "Mallette, Edwin" <[email-masked]>
Date: Wed, 14 Apr 2010 08:37:49 -0400

David,

Not a problem.  In my world I'm looking at a (or multiple) GEPON access with hundreds up to a thousand customer-facing ports aggregated up from the PON ethernet access layer to directly-connected PE.  Both leafs and roots in that scenario could exist either off the layer-2 access PON system or the root (at higher BW tiers GIG+) would exist directly off the intelligent PE.  Even if the GEPON system or 10GPON system (future) were MPLS/VPLS capable we would have a similar case where we may have 10 or 20 leaf ACs and one root AC off the same PE - in this case it would be the GEPON or 10GPON system acting as PE running multiple VSIs.

And I agree we certainly not talking about quite the same thing, though in mind they are similar enough.

I hope this helps.

Regards,

Ed

From: David Allan I [mailto:[email-masked]]
Sent: Wednesday, April 14, 2010 8:29 AM
To: Mallette, Edwin; Simon Delord
Cc: pwe3
Subject: RE: comments on draft-delord-pwe3-cw-bit-etree-02

HI Edwin:

Appreciate the input...

D

Just my 2c.

-          Ed

HI Simon:

[DA] I'll give it a look

best
D

Hi Dave,

Regards,
Simon

---

From: David Allan I <[email-masked]>
Date: Wed, 14 Apr 2010 09:41:24 -0400

Yes with a bit of front end grooming you could just about eliminate the concept of leaf entirely....PON already giving you most of the split horizon you need and the grooming ensuring all leaf CEs have direct L2 access to a root...

;-)
D

Sent: Wednesday, April 14, 2010 8:38 AM

David,

I hope this helps.

Regards,

Ed

HI Edwin:

Appreciate the input...

D

Just my 2c.

-          Ed

HI Simon:

[DA] I'll give it a look

best
D

Hi Dave,

Regards,
Simon

---

From: "Mallette, Edwin" <[email-masked]>
Date: Wed, 14 Apr 2010 10:03:26 -0400

I agree with your point in (from my perspective) a relatively narrow case - there were a number of switching vendors that came out with similar grooming techniques in the past - though assume for the moment that you have multiple layer-2 systems aggregating into the same PE such as....

LEAF----PON-L2-1 ----- PE ------ 10GROOT-AC(ROOT)
                                             /
ROOT---PON-L2-2----/

Now assume a set of leafs are attached to PON-L2-1 and a set of leafs and root are attached to PON-L2-2, now in this case (which tends to be relatively common) the PE would need to see the AC between PON-L2-1 as a leaf and PON-L2-2 as a root AC.   The other relatively common use case is the same as above but a 10G AC as root in the same PE that is used to connect to the PON-L2-1 and PON-L2-2.

I still don't agree that its incredibly rare, though certainly in the case of root and leaf all on the same PON-L2-AGG, you would be right.  Though the case where root and all leafs that land in the same facility all also participate in the same PON-L2 agg would be very rare.

Just some additional thought - while trying not to belabor this point too much.

-          Ed

From: David Allan I [mailto:[email-masked]]
Sent: Wednesday, April 14, 2010 9:41 AM
To: Mallette, Edwin; Simon Delord
Cc: pwe3
Subject: RE: comments on draft-delord-pwe3-cw-bit-etree-02

;-)
D

I hope this helps.

Regards,

Ed

HI Edwin:

Appreciate the input...

D

Just my 2c.

-          Ed

HI Simon:

[DA] I'll give it a look

best
D

Hi Dave,

Regards,
Simon

---

From: Phil Bedard <[email-masked]>
Date: Wed, 14 Apr 2010 11:14:49 -0400

Just to add another operator perspective, we have PEs which serve to aggregate Ethernet endpoints from different access technologies (HFC, EoSONET, legacy Ethernet platforms, etc) into a single multipoint service via L2 handoffs, so the leaf and root on the same PE can be more the norm than the exception for us.  Most of those access technologies do not provide native multipoint services.  

Phil 

On Apr 14, 2010, at 7:55 AM, Mallette, Edwin wrote:

> Dave,
>  
> If I understand you correctly, you’re asserting that the case where you would have root and leaf AC on the same PE to be rare?  Speaking as an operator, 25%+ of our E-Tree requests do in fact have leaf and root ACs landing on the same PE.   Certainly other operators may have varying observations, but this specific case is certainly not incredibly rare as you suggest.
>  
> Just my 2c.
>  
> -          Ed
>  
> [DA] yes, but as I've indicated, I think it is for a case that will be incredibly rare if simply allowed to happen due to random chance, anduneconomical to explicitly operationalize around. And IMO the disadvantages (loss of disambiguation of OAM counts) outweigh the advantages (two less PWs)... 
>