Subject: [mpls-tp] Internal inconsistency in draft-ietf-mpls-tp-framework-06

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 27 Oct 2009 11:02:48 -0400

Following Rahul's talk at the MPLS conference, he and I discovered an
internal inconsistency in draft-ietf-mpls-tp-framework-06, section
3.4. That section only lists MPLS labels and PWs as clients to
MPLS-TP, but the text in section 3.4.2 clearly includes IP as a client
as well. We suggest including IP to the list in section 3.4.

Thanks,
Andy

---

From: Lou Berger <[email-masked]>
Date: Tue, 27 Oct 2009 12:51:44 -0400

Andy,
	The latest text reads:
   3.4. MPLS-TP Client Adaptation

   This document specifies the architecture for two types of client
   adaptation:

   o  A PW
   o  An MPLS Label

So the text has been fixed to address adaptation layers for clients
rather than the clients themselves.  I've also asked (privately) for the
following change:
OLD:
   When the client is a PW, the MPLS-TP client adaptation functions
   include the PW encapsulation mechanisms, including the PW control
   word.  When the client is operating at the network layer the
   mechanism described in Section 3.4.2 is used.
NEW:
   When the client adaptation is via a PW, the
   mechanisms described in Section 3.4.1 are used.
   When the client adaptation is via a MPLS label, the
   mechanisms described in Section 3.4.2 are used.

Which, I believe, should address the rest of your comment.

Lou

On 10/27/2009 11:02 AM, Andrew G. Malis wrote:
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 
> 
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 27 Oct 2009 14:00:07 -0400

Lou,

Actually, that's better, but just part-way there. Since IP is
specificallly discussed in section 3.4.2, your second sentence should
probably read:

>   When the client adaptation is via a MPLS label or
>    a network layer protocol such as IP, the

Cheers,
Andy

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 27 Oct 2009 11:23:30 -0700

Andy,

The MPLS label under discussion is the label at the bottom of the MPLS TP server stack, which identifies the client network layer protocol.  The client network layer protocol can be IP, MPLS, etc.

So, Lou's formulation is correct, although the distinction between an L1/L2 client using a pseudo-wire adaptation and an L3 client using an MPLS label adaptation is not made until you get to the sections themselves.

Thanks,

John 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andrew G. Malis
> Sent: Tuesday, October 27, 2009 11:00 AM
> To: Lou Berger
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] Internal inconsistency 
> indraft-ietf-mpls-tp-framework-06
> 
> Lou,
> 
> specificallly discussed in section 3.4.2, your second 
> sentence should probably read:
> 
> > rather than the clients themselves.  I've also asked 
> (privately) for 
> > the following change:
> > OLD:
> >> MPLS-TP, but the text in section 3.4.2 clearly includes IP as a 
> >> client as well. We suggest including IP to the list in section 3.4.
> >>
> >> Thanks,
> >> Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 27 Oct 2009 14:28:41 -0400

John,

Thanks, I got it now! That was a big help.

Cheers,
Andy

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 27 Oct 2009 21:41:47 +0000

Would it help is we said earlier

> >   o  An MPLS Label used to identify a network layer protocol
         such as IP or MPLS.

Then use "Lou's New text".

- Stewart

Drake, John E wrote:
>>>> Following Rahul's talk at the MPLS conference, he and I 
>>>>         
>> discovered an 
>>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 27 Oct 2009 17:50:10 -0400

Stewart.

That works for me!

Thanks,
Andy

On Tue, Oct 27, 2009 at 5:41 PM, Stewart Bryant <[email-masked]> wrote:
> The MPLS label under discussion is the label at the bottom of the MPLS TP
> server stack, which identifies the client network layer protocol.  The
> client network layer protocol can be IP, MPLS, etc.
>
> So, Lou's formulation is correct, although the distinction between an L1/L2
> client using a pseudo-wire adaptation and an L3 client using an MPLS label
> adaptation is not made until you get to the sections themselves.
>
> Thanks,
>
> John
>
>
>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 27 Oct 2009 23:52:33 +0100

Stewart,

Do we need the protocol label if we use the entire LSP only for IP
traffic?

Best regards,

Nurit

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Stewart Bryant
Sent: Tuesday, October 27, 2009 11:42 PM
To: Drake, John E
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Internal
inconsistencyindraft-ietf-mpls-tp-framework-06

         such as IP or MPLS.

- Stewart

Drake, John E wrote: 

Andy,
 
The MPLS label under discussion is the label at the bottom of the MPLS
TP server stack, which identifies the client network layer protocol.
The client network layer protocol can be IP, MPLS, etc.
 
So, Lou's formulation is correct, although the distinction between an
L1/L2 client using a pseudo-wire adaptation and an L3 client using an
MPLS label adaptation is not made until you get to the sections
themselves.
 
Thanks,
 
John 

	-----Original Message-----
	From: [email-masked] 
	[mailto:[email-masked]] On Behalf Of Andrew G. Malis
	Sent: Tuesday, October 27, 2009 11:00 AM
	To: Lou Berger
	Cc: [email-masked];
[email-masked]
	 
	Lou,

	Cheers,
	Andy
	 
	On Tue, Oct 27, 2009 at 12:51 PM, Lou Berger <[email-masked]>
<mailto:[email-masked]>  wrote:

		Andy,
		       The latest text reads:
		 
		  This document specifies the architecture for two types
of client
		  adaptation:
		 
		  o  A PW
		  o  An MPLS Label
		 
		So the text has been fixed to address adaptation layers
for clients 
		rather than the clients themselves.  I've also asked 

	(privately) for 

		the following change:
		OLD:
		  When the client is a PW, the MPLS-TP client adaptation
functions
		  include the PW encapsulation mechanisms, including the
PW control
		  word.  When the client is operating at the network
layer the
		  mechanism described in Section 3.4.2 is used.
		NEW:
		  When the client adaptation is via a PW, the
		  mechanisms described in Section 3.4.1 are used.
		  When the client adaptation is via a MPLS label, the
		  mechanisms described in Section 3.4.2 are used.
		 
		Which, I believe, should address the rest of your
comment.
		 
		Lou

			Following Rahul's talk at the MPLS conference,
he and I 

	discovered an 

			internal inconsistency in
draft-ietf-mpls-tp-framework-06, section 
			3.4. That section only lists MPLS labels and PWs
as clients to 
			MPLS-TP, but the text in section 3.4.2 clearly
includes IP as a 
			client as well. We suggest including IP to the
list in section 3.4.
			 
			Thanks,
			Andy

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 27 Oct 2009 23:40:03 +0000

If it's ONLY IP then no, but IP often comes with support
protocols, in which case you need a protocol identifier.
However it's also useful to have a service identifier label
and the text says "Note that the functions of the Encap label
and the Service Label may represented by a single label"

- Stewart

Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
> ------------------------------------------------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *ext Stewart Bryant
> *Sent:* Tuesday, October 27, 2009 11:42 PM
> *To:* Drake, John E
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [mpls-tp] Internal 
>> From: [email-masked] <mailto:[email-masked]> 
>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>> On Tue, Oct 27, 2009 at 12:51 PM, Lou Berger <[email-masked]> <mailto:[email-masked]> wrote:
>>     
>>> Andy,
>>>        The latest text reads:
>>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Oct 2009 10:37:01 +0200

Stewart and all,
Do I read that correctly that if I want to run IP traffic in MPLS-TP I have to use at least two different encapsulation labels:
- one to identify IP traffic proper
- another to identify whatever accompanying protocols (ARP, IPCP, InvARP etc.) are used?

What is going to happen if native IP uses different Layer 2 techniques at different ends of such a tunnel?

In MPLS this is known as "ARP mediation" and discussed in detail in draft-ietf-l2vpn-arp-mediation.
I believe that the problem that this draft tries to resolve is equally valid for MPLS-TP, but a new toolset is required.

My 2c,
     Sasha

> [mailto:[email-masked]] On Behalf Of Stewart Bryant
> Sent: Wednesday, October 28, 2009 1:40 AM
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Cc: [email-masked]; [email-masked]
> > The MPLS label under discussion is the label at the bottom 
> of the MPLS TP server stack, which identifies the client 
> network layer protocol.  The client network layer protocol 
> can be IP, MPLS, etc.
> >  
> > So, Lou's formulation is correct, although the distinction 
> between an L1/L2 client using a pseudo-wire adaptation and an 
> L3 client using an MPLS label adaptation is not made until 
> you get to the sections themselves.
> >  
> > Thanks,
> >  
> > John 
> >  
> >   
> >> Cc: [email-masked] 
> <mailto:[email-masked]>; 
> >> On Tue, Oct 27, 2009 at 12:51 PM, Lou Berger 
> <[email-masked]> <mailto:[email-masked]> wrote:
> >>     
> >>> Andy,
> >>>        The latest text reads:

---

From: Jiang Yuan-long <[email-masked]>
Date: Wed, 28 Oct 2009 18:45:56 +0800

Sasha,

I think the scenario as you described is covered in Sec. 3.4.1 of 
draft-ietf-mpls-tp-framework-06,
which says:" When providing...IPLS,  pseudowires MUST be used to carry the 
client service."

Regards
Yuanlong

----- Original Message ----- 
From: "Alexander Vainshtein" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, October 28, 2009 4:37 PM
Subject: Re: [mpls-tp] Internal 

> Stewart and all,
> Do I read that correctly that if I want to run IP traffic in MPLS-TP I 
> have to use at least two different encapsulation labels:
> I believe that the problem that this draft tries to resolve is equally 
> valid for MPLS-TP, but a new toolset is required.
>
> My 2c,
>     Sasha
>
>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Oct 2009 13:27:58 +0200

Yuanlong,
Lots of thanks for a prompt response.

However, I am not sure what exactly the quoted statement from the framework draft means:
- Are various protocols that accompany IP on different links (ARP, InvARP, IPCP etc.) considered to be part of the client service?
- What happens if the links at two sides of a P2P IP service (let's start from the simplest use case) are different? 
  E.g., IP over Ethernet vs. IP over PPP?

Regards,
     Sasha

> From: Jiang Yuan-long [mailto:[email-masked]] 
> Sent: Wednesday, October 28, 2009 12:46 PM
> To: Alexander Vainshtein; [email-masked]
> Cc: [email-masked]
> > - another to identify whatever accompanying protocols (ARP, 
> IPCP, InvARP 
> > etc.) are used?
> >
> > What is going to happen if native IP uses different Layer 2 
> techniques at 
> > different ends of such a tunnel?
> >

---

From: Jiang Yuan-long <[email-masked]>
Date: Wed, 28 Oct 2009 20:10:19 +0800

Sasha, please see my comments in-line.

Regards
Yuanlong

----- Original Message ----- 
From: "Alexander Vainshtein" <[email-masked]>
To: "Jiang Yuan-long" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 28, 2009 7:27 PM
Subject: RE: [mpls-tp] Internal 

Yuanlong,

However, I am not sure what exactly the quoted statement from the framework 
draft means:
- Are various protocols that accompany IP on different links (ARP, InvARP, 
IPCP etc.) considered to be part of the client service?
[JYL] I don't think so. These protocols should be terminated on the local 
PE, rather than transported accross the network, as
shown in the arp-mediation draft. The necessary info. such as IP address 
should be notified across the SCC channel which is defined in 
draft-ietf-mpls-tp-gach-dcn.

- What happens if the links at two sides of a P2P IP service (let's start 
from the simplest use case) are different?
  E.g., IP over Ethernet vs. IP over PPP?
[JYL] Similar to the above, both end PEs should terminate its local client's 
control protocols such as Ethernet or PPP.

Regards,
     Sasha

> =

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Oct 2009 14:17:27 +0200

Yuanlong,

The approach you've taken makes sense to me.
However, please note that:
1.   actual format of ARP mediation messages in the SCC and ARP mediation protocol itself
      over SCC have tobe redefined
2. Service traffic (IP) would only start running across an MPLS-TP domain after ARP mediation is completed
3. Known limitations of the ARP mediation draft probably apply "as is" to this case
4. the PW label will NOT be used as the payload type discriminator.

Regards,
     Sasha

> Sent: Wednesday, October 28, 2009 2:10 PM
> To: Alexander Vainshtein
> Cc: [email-masked]; [email-masked]
> > > In MPLS this is known as "ARP mediation" and discussed in 
> detail in
> > > draft-ietf-l2vpn-arp-mediation.
> <mailto:[email-masked]>

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 28 Oct 2009 10:55:32 -0700

The baseline is configuration, which means no ARP, which means no mediation.

> [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
> Sent: Wednesday, October 28, 2009 4:28 AM
> To: Jiang Yuan-long; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls-tp]Internal 
> - Are various protocols that accompany IP on different links 
> (ARP, InvARP, IPCP etc.) considered to be part of the client service?
> - What happens if the links at two sides of a P2P IP service 
> (let's start from the simplest use case) are different? 
> > draft-ietf-mpls-tp-framework-06, which says:" When 
> providing...IPLS,  
> > pseudowires MUST be used to carry the client service."
> > 
> > Regards
> > Yuanlong
> > 
> protocols, 
> > >> in which case you need a protocol identifier.
> > >> However it's also useful to have a service identifier 
> label and the 
> > >> text says "Note that the functions of the Encap label and the 
> > >> Service Label may represented by a single label"
> > >>
> > >> - Stewart
> > >>
> > >>
> > >>
> > >> of the MPLS TP server stack, which identifies the client network 
> > >> layer protocol.  The client network layer protocol can 
> be IP, MPLS, 
> > >> etc.
> > >> >
> > >> L3 client using an MPLS label adaptation is not made 
> until you get 
> > >> to the sections themselves.
> > >> >
> > >> > Thanks,
> > >> >
> > >> > John
> > >> >
> > >> >

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Oct 2009 21:01:31 +0200

John,
Not sure I understand what this means.

Consider a case when two routers are connected to adjacent MPLS-TP Edge devices using PPP (in some form).
Assume further that IP traffic is carried thru the MPLS-TP network, but LCP and IPCP are terminated on the client side
of the MPLS-TP PE devices. 

In order for the client's routers PPP links to reach their UP state, MPLS-TP devices would have to act as 
"proxy IPCP" terminators, and for that each of them should be aware of the IP addresses used by the router at the remote end.

Do you want to say that these IP addresses (owned by the client of an MPLS-TP service!) 
must be statically configured in the MPLS-TP edge devices in order to make the service work?

More interesting cases include:
- non-homogeneous connections (one side uses PPP and the other one - Ethernet)
- IS-IS that the client routers expect to run between them...

Regards,
     Sasha
> From: Drake, John E [mailto:[email-masked]] 
> Sent: Wednesday, October 28, 2009 7:56 PM
> To: Alexander Vainshtein; Jiang Yuan-long; [email-masked]
> Cc: [email-masked]
> Subject: RE: [mpls-tp]Internal 
> > > >> Cc: [email-masked]; 
> [email-masked]

---

From: Lou Berger <[email-masked]>
Date: Wed, 28 Oct 2009 19:41:21 -0400

Sasha,
	I think you've got the essence of this right.  When using labels (not
PWs) as the client 'adaptation' layer, the (sub-)network layer protocol
needs to be terminated at the client interface of the PE.  This means
that either some configuration needs to take place or a mediation
function can be used.  The latter is an option, and not required.  The
network layer traffic (e.g., IP or MPLS) is then transported across the
MPLS-TP service.

If this service isn't interesting to you, then don't use/sell it.  I
don't think anyone expects that everyone will want such a service.  On
the other hand, there are certain providers out there who will only use
TP in this fashion.

BTW WRT ISIS, see RFC5309.

Lou

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 29 Oct 2009 07:07:33 +0200

Lou,
Lots of thanks for the clarification.

Regarding IS-IS: 

I am aware of 5309 that defined how a physical LAN interface can be presented as a P2P on 
(numbered or unnumbered). What I had in mind is that IS-IS packets are not IP and hence
some way to run them parallel to IP service must b found.

Regards,
     Sasha

> From: Lou Berger [mailto:[email-masked]] 
> Sent: Thursday, October 29, 2009 1:41 AM
> To: Alexander Vainshtein
> Cc: Drake, John E; Jiang Yuan-long; [email-masked]; 
> [email-masked]
> > Consider a case when two routers are connected to adjacent 
> MPLS-TP Edge devices using PPP (in some form).
> > Assume further that IP traffic is carried thru the MPLS-TP 
> network, but LCP and IPCP are terminated on the client side
> > In order for the client's routers PPP links to reach their 
> UP state, MPLS-TP devices would have to act as 
> > "proxy IPCP" terminators, and for that each of them should 
> be aware of the IP addresses used by the router at the remote end.
> >

---

From: Lou Berger <[email-masked]>
Date: Thu, 29 Oct 2009 07:25:14 -0400

Sasha,
	See section 3.4.2 of the tp-fw document. As I read it, you'd have two
Encap labels (one for IP one for IS-IS) over at least one Service/node
label.

Stewart,

I think there's one additional note that may be helpful.

OLD:
Note that the functions of the Encap label and the Service Label may
represented by a single label

NEW:
Note that the functions of the Encap label and the Service Label may
represented by a single label, and that the functions of Transport
Service and Path Layer labels may also be represented by a single label.

Yes this does mean that all three labels may be combined into a single
label.  That's not to say that this will be the norm, just what is
permitted.  I believe this is consistent with the rest of the text
already in the section.

Lou