Subject: [mpls-tp] Is LMP needed for mpls-tp?

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 4 Aug 2008 11:48:42 +0200

As you know LMP is a key component in GMPLS enable networks, it used for
several purposes such as link correlation, control channel maintenance,
etc etc.

It is also useful in address resolution when, as it happens in GMPLS
networks, data plane and control plane addresses are separated see
RFC4990.

Now I'm wondering if any of the LMP capability can be useful in mpls-tp.

Moreover it is sure that for OAM purposes the OAM packets must follow
the same path as the data packet but that is not true in case of SCC or
MCC.

If SCC and MCC traffic can be decoupled from the actual path of the data
then a mechanism like LMP could be useful.

What is your view on that?

BR

D

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

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 04 Aug 2008 08:55:16 -0400

The original intent for MPLS-TP was to be a ³profile² of MPLS (not
GMPLS) ‹ in essence a subset of functionality that could be implemented
using ³stock² MPLS hardware/software. The intent was never to spin off into
a superset.

    --Tom

On 8/4/08 5:48 AM, "Diego Caviglia" <[email-masked]> wrote:

> several purposes such as link correlation, control channel maintenance, etc
> etc.
>  
> It is also useful in address resolution when, as it happens in GMPLS networks,
> data plane and control plane addresses are separated see RFC4990.
>  
> Now I¹m wondering if any of the LMP capability can be useful in mpls-tp.
>  
> Moreover it is sure that for OAM purposes the OAM packets must follow the same
> path as the data packet but that is not true in case of SCC or MCC.
>  
> If SCC and MCC traffic can be decoupled from the actual path of the data then
> a mechanism like LMP could be useful.
>

---

From: "Francesco Fondelli" <[email-masked]>
Date: Mon, 4 Aug 2008 15:06:12 +0200

On Mon, Aug 4, 2008 at 2:55 PM, Thomas Nadeau <[email-masked]> wrote:
>
>     The original intent for MPLS-TP was to be a "profile" of MPLS (not
> GMPLS) — in essence a subset of functionality that could be implemented
> using "stock" MPLS hardware/software. The intent was never to spin off into
> a superset.
>
>     --Tom

Hi Tom,

sure, but

--- draft-blb-mpls-tp-framework-00 ---

   The MPLS-TP control plane is based
   on the MPLS control plane for pseudowires and the GMPLS control plane
   for MPLS-TP LSPs, respectively.

---

and LMP is a GMPLS building block.  LMP IMHO might
be useful in MPLS-TP too (in case of control channel separation).

Ciao
FF

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 04 Aug 2008 09:08:03 -0400

I disagree with that bit then as we seem to be getting some feature
creep now.

    --Tom

---

From: "Howard Green" <[email-masked]>
Date: Mon, 4 Aug 2008 15:16:33 +0200

Tom
As I understand it, MPLS-TP cannot possibly be "a subset of MPLS
functionality" since the whole point of it is to satisfy some
requirements which the current MPLS suite does not. Admittedly, some of
those requirements involve subsetting things (no PHP, no merge, prevent
ECMP), but some require extensions. The requirements for MPLS-TP clearly
imply the need (in some but not all deployments) for an out-of-band
control plane, and the use of GMPLS for this is envisaged both by the
JWT slideset and the framework draft. I do not currently have an opinion
as to whether LMP is a necessary part of this toolkit. To some degree,
the ACH functionality can be used to perform similar functions. I
certainly think we ought to have clarity about any overlap, and
understand some use cases.
regards Howard Green

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Thomas Nadeau
	Sent: 04 August 2008 14:55
	To: Diego Caviglia; [email-masked]
	Subject: Re: [mpls-tp] Is LMP needed for mpls-tp?

	    The original intent for MPLS-TP was to be a "profile" of
MPLS (not GMPLS) - in essence a subset of functionality that could be
implemented using "stock" MPLS hardware/software. The intent was never
to spin off into a superset.
	
	    --Tom

	On 8/4/08 5:48 AM, "Diego Caviglia"
<[email-masked]> wrote:

		As you know LMP is a key component in GMPLS enable
networks, it used for several purposes such as link correlation, control
channel maintenance, etc etc.
		 
		It is also useful in address resolution when, as it
happens in GMPLS networks, data plane and control plane addresses are
separated see RFC4990.
		 
		Now I'm wondering if any of the LMP capability can be
useful in mpls-tp.
		 
		Moreover it is sure that for OAM purposes the OAM
packets must follow the same path as the data packet but that is not
true in case of SCC or MCC.
		 
		If SCC and MCC traffic can be decoupled from the actual
path of the data then a mechanism like LMP could be useful.

		BR
		 
		D

________________________________

---

From: <[email-masked]>
Date: Mon, 4 Aug 2008 19:00:03 +0200

Hi all.

Tom, I don't really catch your point. GMPLS RFCs already encompass Packet Switching Capabilities, so LMP is already applicable to MPLS and MPLS-TP.

To get back to Diego's initial request, the actual question was about the need. Personnally, I also believe that LMP may be useful, depending on the type of control channels implemented in the network. Deployments are likely to use a mix of single hop in-band, multi-hop in-band and out-of-band control channels, especially to increase their availability in case of failure. As a result, LMP will be useful in this field.

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau

    --Tom

On 8/4/08 9:06 AM, "Francesco Fondelli" <[email-masked]>
wrote:

>> GMPLS) < in essence a subset of functionality that could be implemented

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 04 Aug 2008 14:17:07 -0400

Should we call it G-MPLS-TP?

    --Tom

On 8/4/08 1:00 PM, "[email-masked]"
<[email-masked]> wrote:

> Hi all.
> 
> Tom, I don't really catch your point. GMPLS RFCs already encompass Packet
> Switching Capabilities, so LMP is already applicable to MPLS and MPLS-TP.
> 
> To get back to Diego's initial request, the actual question was about the
> need. Personnally, I also believe that LMP may be useful, depending on the
> type of control channels implemented in the network. Deployments are likely to
> use a mix of single hop in-band, multi-hop in-band and out-of-band control
> channels, especially to increase their availability in case of failure. As a
> result, LMP will be useful in this field.
> 
> Regards,
> 
> Julien
> 
>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 04 Aug 2008 20:32:05 +0200

Why give it a different name?
GMPLS was designed for use in Transport Networks; i.e. GMPLS is designed for
networks with a Transport 'Profile'. 
Transport network technologies have been extended and will include SDH, OTN,
Ethernet and MPLS-TP. 

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomas Nadeau
Sent: 04 August 2008 20:17
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Is LMP needed for mpls-tp?

    --Tom

On 8/4/08 1:00 PM, "[email-masked]"
<[email-masked]> wrote:

> Hi all.
> 
> Tom, I don't really catch your point. GMPLS RFCs already encompass 
> Packet Switching Capabilities, so LMP is already applicable to MPLS and
MPLS-TP.
> 
> To get back to Diego's initial request, the actual question was about 
> the need. Personnally, I also believe that LMP may be useful, 
> depending on the type of control channels implemented in the network. 
> Deployments are likely to use a mix of single hop in-band, multi-hop 
> in-band and out-of-band control channels, especially to increase their 
> availability in case of failure. As a result, LMP will be useful in this
field.
>      I disagree with that bit then as we seem to be getting some 
> feature creep now.
> 
>     --Tom
> 
> 
>>> GMPLS) < in essence a subset of functionality that could be 
>>> implemented using "stock" MPLS hardware/software. The intent was 
>>> never to spin off into a superset.
>>> 
>>>     --Tom
>> 
>> Hi Tom,
>> 
>> sure, but
>> 
>> and LMP is a GMPLS building block.  LMP IMHO might be useful in 
>> MPLS-TP too (in case of control channel separation).
>> 
>> Ciao
>> FF
>

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Mon, 4 Aug 2008 14:51:41 -0400

Hi Tom,

GMPLS was identified in the JWT report:
http://www.ietf.org/internet-drafts/draft-bryant-mpls-tp-jwt-report-00.t
xt

And..
http://www.ietf.org/internet-drafts/draft-bryant-mpls-tp-jwt-report-00.p
df
(slide 28)

Deborah 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Thomas Nadeau
Sent: Monday, August 04, 2008 9:08 AM
To: Francesco Fondelli
Cc: [email-masked]
Subject: Re: [mpls-tp] Is LMP needed for mpls-tp?

    --Tom

>> GMPLS) < in essence a subset of functionality that could be
implemented

---

From: "Diego Caviglia" <[email-masked]>
Date: Tue, 5 Aug 2008 10:38:42 +0200

Hi all,
       Julien is correct (as always :-)) my initial point was to discuss if LMP could be useful in mpls-tp or not.

My experience in transport network with GMPLS control plane tells me that LMP is useful.

There are requirements in draft-jenkins-mpls-mpls-tp-requirements-00 about the separation of physical and logical separation among data, control and management plane.

A possible way to obtain that separation is to use different addressing planes as it happens in GMPLS (see 4990) moreover the concept of control channels helps in maintaining the separation indicated in the requirement ID.

LMP in that context plays a 'glue' function between control channels and TE links.

Quoted from rfc4204
"LMP can also tell the signaling module the mapping between TE links and control channels.  Thus, LMP performs a valuable "glue" function in the control plane."

Last but not least is fully true that mpls-tp is a profile of mpls and is fully true that (quoted from requirement ID).

   o  MPLS-TP MUST offer as much commonality as possible with the MPLS
      data plane as defined by IETF.  When MPLS offers multiple options
      in this respect, MPLS-TP SHOULD select the minimum sub-set
      (necessary and sufficient subset) applicable to a transport
      network application.

But here we are not talking about data plane, we are talking about interaction among data plane control plane and management plane in a transport network.

The only reference I had for that scenario is Sonet/SDH/g.709 with gmpls.

BR

Diego

> Of [email-masked]
> Sent: lunedì 4 agosto 2008 19.00
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> type of control channels implemented in the network. Deployments are
> likely to use a mix of single hop in-band, multi-hop in-band and out-of-
> band control channels, especially to increase their availability in case
> of failure. As a result, LMP will be useful in this field.
> 
> Regards,
> 
> Julien
> 
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 5 Aug 2008 10:13:15 +0100

Hi,

Is LMP "necessary" in MPLS-TP? No.
It is not necessary in any other transport technology either.

Could LMP be useful in MPLS-TP? Yes.
It provides a function that would otherwise require configuration.

How should we handle this?

As with *all* of this work, the requirements need to talk about the 
requirements not the solutions! LMP is a solution. The control plane 
documents can discuss how to meet the requirements (such as exist) using 
different techniques such as configuration and LMP as appropriate.

A

----- Original Message ----- 
From: "Diego Caviglia" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 05, 2008 9:38 AM
Subject: Re: [mpls-tp] Is LMP needed for mpls-tp?

Hi all,
       Julien is correct (as always :-)) my initial point was to discuss if 
LMP could be useful in mpls-tp or not.

My experience in transport network with GMPLS control plane tells me that 
LMP is useful.

There are requirements in draft-jenkins-mpls-mpls-tp-requirements-00 about 
the separation of physical and logical separation among data, control and 
management plane.

A possible way to obtain that separation is to use different addressing 
planes as it happens in GMPLS (see 4990) moreover the concept of control 
channels helps in maintaining the separation indicated in the requirement 
ID.

LMP in that context plays a 'glue' function between control channels and TE 
links.

Quoted from rfc4204
"LMP can also tell the signaling module the mapping between TE links and 
control channels.  Thus, LMP performs a valuable "glue" function in the 
control plane."

Last but not least is fully true that mpls-tp is a profile of mpls and is 
fully true that (quoted from requirement ID).

But here we are not talking about data plane, we are talking about 
interaction among data plane control plane and management plane in a 
transport network.

BR

Diego

---

From: <[email-masked]>
Date: Tue, 5 Aug 2008 15:43:25 +0200

Hi Maarten, hi Tom.

It is not  only an issue of naming but also of consistency. GMPLS
generalizes MPLS *Control Plane* to handle connection-oriented data
planes (I'm not sure of the exact boundaries of "transport"). Thus a
GMPLS-controlled MPLS (TP or not) is still MPLS (TP or not), as any
GMPLS-controlled technology X remains technology X. In this context,
GMPLS-TP would be a nonsense concept (or a Terrible Reason Of Leveraging
Language)... ;-)

Cheers,

Julien

P.S.: Maarten, you forgot to mention WDM (LSC & FSC)...

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 

Why give it a different name?
GMPLS was designed for use in Transport Networks; i.e. GMPLS is designed
for
networks with a Transport 'Profile'. 
Transport network technologies have been extended and will include SDH,
OTN,
Ethernet and MPLS-TP. 

Regards,
Maarten

-----Original Message-----
Behalf

    --Tom

MPLS-TP.

field.