Subject: [mpls-tp] last call comment for draft-ietf-mpls-tp-data-plane-01

From: Curtis Villamizar <[email-masked]>
Date: Fri, 09 Apr 2010 01:12:18 -0400

This is a thankfully short I-D, but to the point and well written
IMHO.  I would like to see the one change listed below in the context
diff.

This change puts the multipath aka ECMP/CL/LAG status at the same
level as PHP.  It is not entirely prohibited but is disabled by
default.  Multipath should not prohibited for non-TP MPLS that
coexists with MPLS-TP LSP.  How that coexistance is accomplished would
be out of scope for a framework document.

Curtis

--- draft-ietf-mpls-tp-data-plane-01.txt
+++ draft-ietf-mpls-tp-data-plane-01.txt.modified
@@ -308,18 +308,20 @@
    The Uniform model is outside the scope of the MPLS-TP.
 
    Per-platform, per-interface or other context-specific label space
    [RFC5331] MAY be used for MPLS-TP LSPs.  Downstream [RFC3031] or
    upstream [RFC5331] label allocation schemes MAY be used for MPLS-TP
    LSPs.  Note that the requirements of a particular LSP type may
    dictate which label spaces or allocation schemes it can use.
 
-   Per-packet Equal-Cost Multi-Path (ECMP) load-balancing is outside the
-   scope of the MPLS-TP.
+   MPLS-TP LSP must be excluded by default from Equal Cost Multi-Path
+   (ECMP) load balancing or any form of composite link or link
+   aggregation load balancing.  Per-packet load balancing is outside the
+   scope of MPLS-TP.
 
    Penultimate Hop Popping (PHP) MUST be disabled by default on MPLS-TP
    LSPs.
 
 3.1.2.  LSP Payloads
 
    The MPLS-TP includes support for the following LSP payload types:

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 09 Apr 2010 07:42:21 +0100

Curtis Villamizar wrote:
> +   (ECMP) load balancing 
OK to here

> or any form of composite link or link
> +   aggregation load balancing.  
... but I this is not an MPLS-TP property, it is a property of the 
MPLS-TP's server layer.

Section 5 specifies that the server layer must be suitable. If we need 
to spell out the ECMP case, it should be included as an example there.

> Per-packet load balancing is outside the
> +   scope of MPLS-TP.
>  
Stewart

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 10 Apr 2010 23:34:43 -0400

In message <[email-masked]>
> >     The MPLS-TP includes support for the following LSP payload types:

It doesn't quite go far enough without the full statement.

The way you have is worded, if two Ethernet links exists, you exclude
MPLS-TP from ECMP by default if the two do not form a LAG, but if a
LAG (or CL) is formed then there is no statement.  Note that the
statement "by default" allows a vendor to provide a knob and allows
the provider to make a choice.

Curtis

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 11 Apr 2010 12:48:12 -0700

Hi Curtis,
you've brought up issue that I've tried to understand - applicability of a
certain MPLS functionality or technique to MPLS-TP that is referred as
"disabled by default". If an operator chooses to enable such feature, would
the network still be considered MPLS-TP compliant? It will certainly can be
referred as MPLS, but what about MPLS-TP brand? Can we put it on if PHP is
enabled? In my view there's nothing wrong with building MPLS, not MPLS-TP,
network if that what operator wants. I know that I'm getting little bit into
non-technical, perhaps marketing domain, but I'm still trying to fully
understand our interpretation of relationship with MPLS-TP things that we
say are disabled by default in MPLS-TP.

Regards,
Greg

On Sat, Apr 10, 2010 at 8:34 PM, Curtis Villamizar <[email-masked]> wrote:

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

---

From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
Date: Mon, 12 Apr 2010 10:00:09 +0200

Hi Greg
That is irrelevant in my opinion  as to where a deployed network is MPLS or MPLS-TP compliant. There are no official test suits that can perform test and then stamp the network either fail or partial fail or pass as certified MPLS-TP compliancy.

The question I think we are a bit struggling with is will all the MPLS-TP  features that can be switched (controlled) off and on, make the network to operate and report under all (considered) situations?

./
Lieven

From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: 11 April 2010 21:48
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] last call comment for draft-ietf-mpls-tp-data-plane-01

Hi Curtis,
you've brought up issue that I've tried to understand - applicability of a certain MPLS functionality or technique to MPLS-TP that is referred as "disabled by default". If an operator chooses to enable such feature, would the network still be considered MPLS-TP compliant? It will certainly can be referred as MPLS, but what about MPLS-TP brand? Can we put it on if PHP is enabled? In my view there's nothing wrong with building MPLS, not MPLS-TP, network if that what operator wants. I know that I'm getting little bit into non-technical, perhaps marketing domain, but I'm still trying to fully understand our interpretation of relationship with MPLS-TP things that we say are disabled by default in MPLS-TP.

Regards,
Greg
On Sat, Apr 10, 2010 at 8:34 PM, Curtis Villamizar <[email-masked]<mailto:[email-masked]>> wrote:

In message <[email-masked]<mailto:[email-masked]>>

Curtis

_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Dan Frost <[email-masked]>
Date: Tue, 13 Apr 2010 18:09:23 +0100

> the provider to make a choice.

Current text reads:

  Equal-Cost Multi-Path (ECMP) load-balancing is not applicable
  to MPLS-TP LSPs. MPLS-TP MAY operate over a server layer that
  supports load-balancing, but this load-balancing MUST operate in
  such a manner that it is transparent to MPLS-TP.

This is a compromise between allowing load-balancing at the server layer
and providing the required degree of isolation between that server layer
and MPLS-TP.

- Dan/Stewart

---

From: "BUSI ITALO" <[email-masked]>
Date: Tue, 13 Apr 2010 23:58:01 +0200

Stewart, Dan,

what do you actually mean by saying that load balancing in the server layer is "transparent" to MPLS-TP? Does it mean that it does not cause re-ordering of packets sent over MPLS-TP LSP?

Thanks, Italo

P.S. Please note my new email address, [email-masked], effective since 1 November 2009.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dan Frost
> Sent: martedì 13 aprile 2010 19.09
> To: [email-masked]
> Cc: [email-masked]
> This is a compromise between allowing load-balancing at the 
> server layer and providing the required degree of isolation 
> between that server layer and MPLS-TP.
> 
> - Dan/Stewart
> 
> > Curtis

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 14 Apr 2010 08:53:17 +0300

Italo, and all,
To the best of my understanding, the best one can hope for is that a flow of packets with the same label stack 
would not be reordered. 

This seems to be good enough for most applications.
One notable exception is packet loss measurement: adding the GAL to the LSP stack may result in re-ordering between user traffic and loss measurement packets. As a consequence, the results of the measurement will be skewed.

Do I miss something?

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BUSI ITALO
Sent: Wednesday, April 14, 2010 12:58 AM
To: Dan Frost; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] last call comment for draft-ietf-mpls-tp-data-plane-01

Stewart, Dan,

Thanks, Italo

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Apr 2010 02:03:00 -0400

In message <[email-masked]>
Greg Mirsky writes:
>  
>  
> Hi Curtis,
>  
> you've brought up issue that I've tried to understand - applicability
> of a certain MPLS functionality or technique to MPLS-TP that is
> referred as "disabled by default". If an operator chooses to enable
> such feature, would the network still be considered MPLS-TP compliant?
> It will certainly can be referred as MPLS, but what about MPLS-TP
> brand? Can we put it on if PHP is enabled? In my view there's nothing
> wrong with building MPLS, not MPLS-TP, network if that what operator
> wants. I know that I'm getting little bit into non-technical, perhaps
> marketing domain, but I'm still trying to fully understand our
> interpretation of relationship with MPLS-TP things that we say are
> disabled by default in MPLS-TP.
>  
> Regards,
> Greg

Greg,

I don't think an operator would care if it was considered MPLS-TP
compliant or not, nor would a vendor.  Its just nice to have documents
that match reality.

If the equipment is not capable of disabling PHP or not capable of
disabling multipath features, etc, then the operator might care.

In the case of PHP counters and OAM context is lost.  Without the OAM
context the ability to operate without a CP may be lost.  With
multipath enabled LM is somewhat inaccurate (but that accuracy is less
important over long time scale) and fate sharing can be an issue.  The
"disabled by default" just allows providers to decide for themselves
rather than have their decisions forced by committee decision.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Apr 2010 02:57:57 -0400

> and providing the required degree of isolation between that server layer

I will agree with that only if the following is added.

Changed to:

>   such a manner that it is transparent to MPLS-TP as long as LSP are
>   identified as MPLS-TP LSP requiring treatment as an single flow.

I don't think we need to add "through control plane or management
plane" to the end.

The point is as long as *some* LSP don't identify themselves as
MPLS-TP requiring a single flow, then some load balancing can be done
without bin-packing issues.  Also note that this allows LSP larger
than any component link if they don't identify themselves as requiring
treatment as an single flow.

It also requires that we add some means in the control plane for an
LSP to identify itself as "an LSP requiring treatment as an single
flow".

In this case all MPLS does not identify itself in this way and so
existing behavior does not change, only new MPLS-TP behaviour.

Curtis

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 14 Apr 2010 08:46:55 +0100

> what do you actually mean by saying that load balancing in the server layer is "transparent" to MPLS-TP? Does it mean that it does not cause re-ordering of packets sent over MPLS-TP LSP?
Strictly it means that MPLS-TP cannot tell that the LB has occurred. So 
no re-ordering (as you say), OAM fate shares with user data etc.

Stewart