Subject: Re: [Mpls-interop] MPLS over MPLS-TP

From: Stewart Bryant <[email-masked]>
Date: Sun, 25 Jan 2009 16:00:48 +0000

Drake, John E wrote:
>  
>
>   
>> -----Original Message-----
>> From: Ben Niven-Jenkins [mailto:[email-masked]] 
>> Sent: Wednesday, December 10, 2008 2:41 PM
>> To: [email-masked]
>> Subject: [Mpls-interop] MPLS over MPLS-TP
>>
>> Colleagues,
>>
>> What's the current view of how to support MPLS over MPLS-TP?
>>
>> Do we put a PW in the middle (like draft-bryant) or do we just 
>> use the label stack and have MPLS directly over MPLS-TP?
>>     
>
> JD:  I always thought this was a terrible idea. 
John, which one or both?

>  Since MPLS-TP is a
> particular MPLS profile and since we said that the MPLS dataplane
> wouldn't be touched, I think we would either add entries to the stack
> (MPLS), or place an IP packet after the stack (IP).
>   
PWs run over MPLS and don't often carry IP, at least not directly, so PW 
after
the stack is also allowed.

MPLS-TP is a profile of PW over MPLS, so using an intermediate PW of some
kind is within scope.

The argument for greater isolation than is achieved by simply pushing more
labels comes from the service provider community. We therefore need to
determine from them whether that are happy with a single contiguous
label stack in the MPLS-TP carriers case. If they are, then that is the 
way to go.
If they are not, we need to design an encapsulation that gives them the
degree of isolation they are looking for.

Stewart

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

---

From: "Drake, John E" <[email-masked]>
Date: Sun, 25 Jan 2009 11:15:16 -0800

Stewart,

I think you're starting at the beginning of a long e-mail thread.  I
think we ended up with a pair of label stacks (service provider stack,
customer stack), applied recursively as needed, with each stack being be
manipulated independently. 

The presence of a customer MPLS packet with its label stack, as opposed
to a PWE packet or an IP packet, would be indicated either by a unique
value or values in the first nibble of the customer packet (i.e., the
first nibble of the top label cannot have any of the currently defined
values), or with a reserved bottom most label (payload is MPLS) in the
service provider stack.

Thanks,

John 

>From: Stewart Bryant [mailto:[email-masked]] 
>Sent: Sunday, January 25, 2009 8:01 AM
>To: Drake, John E
>Cc: Ben Niven-Jenkins; [email-masked]
>Subject: Re: [Mpls-interop] MPLS over MPLS-TP
>
>Drake, John E wrote:
>>  
>>
>>   
>>> Do we put a PW in the middle (like draft-bryant) or do we just use 
>>> the label stack and have MPLS directly over MPLS-TP?
>>>     
>>
>PWs run over MPLS and don't often carry IP, at least not 
>directly, so PW after the stack is also allowed.
>
>MPLS-TP is a profile of PW over MPLS, so using an intermediate 
>PW of some kind is within scope.
>
>The argument for greater isolation than is achieved by simply 
>pushing more labels comes from the service provider community. 
>We therefore need to determine from them whether that are 
>happy with a single contiguous label stack in the MPLS-TP 
>carriers case. If they are, then that is the way to go.
>If they are not, we need to design an encapsulation that gives 
>them the degree of isolation they are looking for.
>
>Stewart
>
>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 25 Jan 2009 20:35:56 +0100

Hi John,
As a matter of fact, as I recall we had a long discussion on this issue
on the mailing list but with no real conclusion. 
I am not sure what the real difference between using a reserved label
and using a PW label is (except for the value of the label). Why is not
it better to use the already existing mechanism (PWE3) to demark between
the service provider and the customer information in the frame.
We need to address also he question of MPS-TP over MPLS. 
Best regards,
Nurit 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Drake, John E
Sent: Sunday, January 25, 2009 21:15
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Stewart,

Thanks,

John

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 26 Jan 2009 07:06:27 +0000

How does using a new first nibble Vs a reserved bottom label compare with
existing implementation behaviour?

Will an existing implementation discard both variants?

Ben

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 26 Jan 2009 06:30:35 -0800

Ben,

I think either is fine.

An LSP within a SP MPLS LSP would be established using either control
plane or management plane protocols, and it would be policy to not use
any of the defined values in the first nibble of that LSP's label.
(Another alternative would be to define a first nibble value that means
'MPLS LSP'.)  Intermediate nodes will only perform ECMP if the packet is
IPv4 or IPv6.

A new reserved label would only be used and understood by the SP MPLS
LSP endpoints and clients.  The language in RFC 3032 indicates that the
bottom most label should provide an indication of the payload type and
there are already implicit null labels defined for IPv4 and IPv6.  What
this is doing is effectively creating separate LSPs for each payload
type.

The only points of discussion are whether the ingress SP MPLS LSP
endpoint can set the label without help from the ingress client, which I
think is required, and whether a payload type indication is passed to
the egress client, which I think is required because if this isn't done
the reserved label is pretty useless.  I.e., clients care about the
payload type but the SP MPLS LSP endpoints don't.

Thanks,

John

>Sent: Sunday, January 25, 2009 11:06 PM
>To: Drake, John E; [email-masked]
>How does using a new first nibble Vs a reserved bottom label 
>compare with existing implementation behaviour?
>
>> customer stack), applied recursively as needed, with each 
>stack being 
>> be manipulated independently.
>> 
>> The presence of a customer MPLS packet with its label stack, as 
>> opposed to a PWE packet or an IP packet, would be indicated 
>either by 
>> a unique value or values in the first nibble of the customer packet 
>> (i.e., the first nibble of the top label cannot have any of the 
>> currently defined values), or with a reserved bottom most label 
>> (payload is MPLS) in the service provider stack.
>> 
>> Thanks,
>> 
>> John
>> 
>>> MPLS-TP is a profile of PW over MPLS, so using an 
>intermediate PW of 
>>> some kind is within scope.
>>> 
>>> The argument for greater isolation than is achieved by 
>simply pushing 
>>> more labels comes from the service provider community.
>happy with 
>>> a single contiguous label stack in the MPLS-TP carriers 
>case. If they 
>>> are, then that is the way to go.
>>> If they are not, we need to design an encapsulation that gives them 
>>> the degree of isolation they are looking for.
>>> 
>>> Stewart
>>> 
>>> 
>
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 26 Jan 2009 14:42:05 +0000

John,

I get all that.  What I was thinking was more, if I have an existing MPLS
router somewhere that doesn't have MPLS/MPLS-TP over MPLS/MPLS-TP
implemented (or a MPLS/MPLS-TP router that doesn't have MPLS-TP enabled),
what will it do with one of these packets?

If it doesn't understand it it should drop it.  For a reserved label I
assume the default is to drop packets with labels that are not understood.
I do not know if that is the same for the 1st nibble.

Ben

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 26 Jan 2009 06:42:09 -0800

Comments inline. 

>From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
>[mailto:[email-masked]] 
>Sent: Sunday, January 25, 2009 11:36 AM
>Cc: [email-masked]; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
>Subject: RE: [Mpls-interop] MPLS over MPLS-TP
>
>Hi John,
>As a matter of fact, as I recall we had a long discussion on 
>this issue on the mailing list but with no real conclusion. 
>I am not sure what the real difference between using a 
>reserved label and using a PW label is (except for the value 
>of the label). Why is not it better to use the already 
>existing mechanism (PWE3) to demark between the service 
>provider and the customer information in the frame.

JD:  *Requiring* a PW header in order to transport an MPLS payload over
an MPLS LSP strikes me as an IQ test that one has failed.

This is an e-mail I sent to Andy Malis on Dec 11th, to which he
expressed agreement:

Andy,

Great.  So, it is up to the client endpoints of the MPLS TP LSP to
understand the payload contents and we could have as payloads, for
example, MPLS packets with their own label stack, IP packets, or
ethernet PW packets which in turn contain, for example, MPLS packets or
IP packets.

Thanks,

John   
>I think you're starting at the beginning of a long e-mail 
>thread.  I think we ended up with a pair of label stacks 
>(service provider stack, customer stack), applied recursively 
>as needed, with each stack being be manipulated independently. 
>
>The presence of a customer MPLS packet with its label stack, 
>as opposed to a PWE packet or an IP packet, would be indicated 
>either by a unique value or values in the first nibble of the 
>customer packet (i.e., the first nibble of the top label 
>cannot have any of the currently defined values), or with a 
>reserved bottom most label (payload is MPLS) in the service 
>provider stack.
>
>Thanks,
>
>John 
>
>>PWs run over MPLS and don't often carry IP, at least not directly, so 
>>PW after the stack is also allowed.
>>
>>MPLS-TP is a profile of PW over MPLS, so using an intermediate PW of 
>>The argument for greater isolation than is achieved by simply pushing 
>happy with a 
>>single contiguous label stack in the MPLS-TP carriers case. If they

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 26 Jan 2009 07:02:54 -0800

Ben,

Are you talking about intermediate or endpoint routers?  I was assuming
that the endpoint routers would need to be upgraded, and that control
plane or management plane protocols would ensure that they were.  If an
egress router were not, presumably it would would drop the packets.

As I tried to indicate in my e-mail, an intermediate router would be
oblivious to either scheme.

Thanks,

John  

>Sent: Monday, January 26, 2009 6:42 AM
>I get all that.  What I was thinking was more, if I have an 
>existing MPLS router somewhere that doesn't have MPLS/MPLS-TP 
>over MPLS/MPLS-TP implemented (or a MPLS/MPLS-TP router that 
>doesn't have MPLS-TP enabled), what will it do with one of 
>these packets?
>
>If it doesn't understand it it should drop it.  For a reserved 
>label I assume the default is to drop packets with labels that 
>are not understood.
>> (Another alternative would be to define a first nibble value that 
>> means 'MPLS LSP'.)  Intermediate nodes will only perform ECMP if the 
>> packet is
>> IPv4 or IPv6.
>> 
>> LSP endpoints and clients.  The language in RFC 3032 indicates that 
>> the bottom most label should provide an indication of the 
>payload type 
>> and there are already implicit null labels defined for IPv4 
>and IPv6.  
>> What this is doing is effectively creating separate LSPs for each 
>> payload type.
>> 
>> endpoint can set the label without help from the ingress 
>client, which 
>> I think is required, and whether a payload type indication is passed 
>> to the egress client, which I think is required because if 
>this isn't 
>> done the reserved label is pretty useless.  I.e., clients care about 
>> the payload type but the SP MPLS LSP endpoints don't.
>> 
>> Thanks,
>> 
>> John
>> 
>>> How does using a new first nibble Vs a reserved bottom 
>label compare 
>>> with existing implementation behaviour?
>>> 
>thread.  I

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 26 Jan 2009 15:57:22 +0000

Drake, John E wrote:
>> Sent: Thursday, December 11, 2008 8:55 AM
>> To: ext Ben Niven-Jenkins; [email-masked]
>> The first option also allows you to have better trouble 
>> shooting in case of a problem (thanks to the clear separation).
>>     
>
> JD:  Regardless of whether you have MPLS TP/PW/MPLS *or* MPLS TP/MPLS,
> you will have two label stacks.  The only difference is whether the last
> label in the provider's stack is an PW label *or* an MPLS label.  This
> was the point in Andy's first e-mail, which as I read it, said that
> there was nothing magic about that label being a PW label.
>   
John

The more important difference is that in MPLS-TP  the PW label is followed
by a CW which  is an object that cannot be forwarded.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 26 Jan 2009 16:26:13 +0000

John
> an MPLS LSP strikes me as an IQ test that one has failed.

I always fail those - I take it to indicate a faulty test methodology :)

The CW will poison the packet anywhere other than where a CW is expected.

Stewart

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 26 Jan 2009 08:28:52 -0800

>Sent: Monday, January 26, 2009 7:57 AM
>To: Drake, John E
>Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Ben 
>Niven-Jenkins; [email-masked]
>>> The first option also allows you to have better trouble shooting in 
>>> case of a problem (thanks to the clear separation).
>>>     
>>
>> you will have two label stacks.  The only difference is whether the 
>> last label in the provider's stack is an PW label *or* an 
>MPLS label.  
>> This was the point in Andy's first e-mail, which as I read it, said 
>> that there was nothing magic about that label being a PW label.
>>   
>John
>
>The more important difference is that in MPLS-TP  the PW label 
>is followed by a CW which  is an object that cannot be forwarded.
>
>Stewart

JD:  Stewart, in either case, the 'end of stack' bit will be set.  I
don't see how you can assert that an implementation which does not
respect the 'end of stack' bit will consider the CW to be sacrosanct.

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 26 Jan 2009 08:38:32 -0800

Please see my other e-mail reply to you.  You cannot assert apriori what
a rogue implementation will do.

>Sent: Monday, January 26, 2009 8:26 AM
>To: Drake, John E
>Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); 
>[email-masked]; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
>> JD:  *Requiring* a PW header in order to transport an MPLS payload 
>> over an MPLS LSP strikes me as an IQ test that one has failed.
>

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Mon, 26 Jan 2009 11:41:54 -0500

Stewart,

Boy, talk about dredging up old emails ...

I've been thinking some more about this issue since our discussion last
week in Ipswich.  The question I asked there was whether what we gain
from putting a PW label and CW in the stack to separate the MPLS-TP
stack and the MPLS stack are worth the cost:

- 64 additional bits in the packet header (obviously)
- LDP signaling between the PW endpoints to distribute the PW label

As I see it, what we gain is:

- a clear demark (although you would get that as well with the S bit)
- a serial number so that the MPLS PW can be kept in-order (although you
have been arguing against using the serial number in your last few
emails)
- a non-IP first nibble and a zero TTL in the CW (assuming that a serial
number is not used) to "poison the stack" in case there's a provisioning
problem

So it really comes down to having the "poison" in the stack in the
unlikely case of a provisioning mismatch in an endpoint switch. I'm
still not convinced that it's worth the cost, although I could possibly
still be convinced. Are there any other advantages that I've missed?

Cheers,
Andy

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Monday, January 26, 2009 11:26 AM
To: Drake, John E
Cc: [email-masked]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

John
> JD:  *Requiring* a PW header in order to transport an MPLS payload
over

The CW will poison the packet anywhere other than where a CW is
expected.

Stewart

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 26 Jan 2009 08:54:12 -0800

Andy,

Per RFC 4448, the control word is optional for Ethernet PWs, so its
presence cannot be counted on.  If it is present, the sequence number
field may be used so that the bottom sixteen bits may not be zero.

Given that we are talking about a rogue implementation that does not
respect the 'end of stack' bit, I don't see much utility.

Thanks,

John  

>From: Malis, Andrew G. (Andy) [mailto:[email-masked]] 
>Sent: Monday, January 26, 2009 8:42 AM
>To: [email-masked]; Drake, John E
>I've been thinking some more about this issue since our 
>discussion last week in Ipswich.  The question I asked there 
>was whether what we gain from putting a PW label and CW in the 
>stack to separate the MPLS-TP stack and the MPLS stack are 
>worth the cost:
>
>- a serial number so that the MPLS PW can be kept in-order 
>(although you have been arguing against using the serial 
>number in your last few
>emails)
>- a non-IP first nibble and a zero TTL in the CW (assuming 
>that a serial number is not used) to "poison the stack" in 
>case there's a provisioning problem
>
>So it really comes down to having the "poison" in the stack in 
>the unlikely case of a provisioning mismatch in an endpoint 
>switch. I'm still not convinced that it's worth the cost, 
>although I could possibly still be convinced. Are there any 
>other advantages that I've missed?
>
>Cheers,
>Andy
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 26 Jan 2009 16:58:06 +0000

> - LDP signaling between the PW endpoints to distribute the PW label
Except when you are statically configured.

> still be convinced. Are there any other advantages that I've missed?
Same label stack for OAM (0001 in CW  vs additional label 13).

Stewart

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Mon, 26 Jan 2009 12:01:01 -0500

John,

This would be for an MPLS PW, which we have not yet defined (a new MPLS
PW draft would be required). Thus, we are free to make up the rules.

Note that I'm still pretty much in agreement that we don't need an MPLS
PW to run MPLS over MPLS-TP (I'm still awaiting further arguments from
Stewart or anyone else that wants to argue in favor of using a PW). 

However, I do think that we would need an MPLS-TP PW if we wanted to run
MPLS-TP over MPLS (that came up last week as well). The primary issue
here is that MPLS-TP over MPLS would require in-order delivery, so it
has to avoid ECMP.

Cheers,
Andy

-----Original Message-----
From: Drake, John E [mailto:[email-masked]] 
Sent: Monday, January 26, 2009 11:54 AM
To: Malis, Andrew G. (Andy); [email-masked]
Cc: [email-masked]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
Subject: RE: [Mpls-interop] MPLS over MPLS-TP

Andy,

Thanks,

John

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 26 Jan 2009 09:14:14 -0800

Andy,

I'm sorry, this is the first I have heard of a proposal to invent a new
PW type for transporting MPLS over MPLS.  However, it doesn't change my
opinion that it is totally useless, unless you are of the opinion that a
technology isn't complete until it includes PWs.

As I understand it, as long as the first nibble does not indicate that
the packet is either an IPv4 or IPv6 packet, ECMP will be disabled.  As
I indicated in my note to Ben, the control plane or management plane can
insure this requirement for any LSPs established over the SP MPLS LSP.

Thanks,

John
>Sent: Monday, January 26, 2009 9:01 AM
>This would be for an MPLS PW, which we have not yet defined (a 
>new MPLS PW draft would be required). Thus, we are free to 
>make up the rules.
>
>Note that I'm still pretty much in agreement that we don't 
>need an MPLS PW to run MPLS over MPLS-TP (I'm still awaiting 
>further arguments from Stewart or anyone else that wants to 
>argue in favor of using a PW). 
>
>However, I do think that we would need an MPLS-TP PW if we 
>wanted to run MPLS-TP over MPLS (that came up last week as 
>well). The primary issue here is that MPLS-TP over MPLS would 
>require in-order delivery, so it has to avoid ECMP.
>
>Cheers,
>Andy
>
>Per RFC 4448, the control word is optional for Ethernet PWs, 
>so its presence cannot be counted on.  If it is present, the 
>sequence number field may be used so that the bottom sixteen 
>bits may not be zero.
>
>Given that we are talking about a rogue implementation that 
>does not respect the 'end of stack' bit, I don't see much utility.
>
>Thanks,
>
>John  
>
>discussion last 
>>- a serial number so that the MPLS PW can be kept in-order (although 
>>you have been arguing against using the serial number in your last few
>>emails)
>>- a non-IP first nibble and a zero TTL in the CW (assuming that a 
>>serial number is not used) to "poison the stack" in case there's a 
>>provisioning problem
>>

---

From: George Swallow <[email-masked]>
Date: Mon, 26 Jan 2009 12:48:01 -0500

An MPLS PW is fine if you want to run MPLS-TP over MPLS or MPLS-TP.  However
if you want to run MPLS as it currently exists in 10s of thousands of
devices, then  you need a PW that can carry IP as well as all the control
and OAM depends on it.

So whatever solution we get to needs to carry both MPLS and IP.  And if that
is the case then relying on EOS is a non-starter.

...George

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 26 Jan 2009 09:56:23 -0800

George,

Are we not okay as long as we ensure that the first nibble of *any*
client MPLS label does not have the values '0', '1', '4' or '6'?  Or
better yet, define a new value that indicates 'payload is MPLS'?

Thanks,

John 

>From: George Swallow [mailto:[email-masked]] 
>Sent: Monday, January 26, 2009 9:48 AM
>To: Malis, Andrew G. (Andy); Drake, John E; [email-masked]
>An MPLS PW is fine if you want to run MPLS-TP over MPLS or 
>MPLS-TP.  However if you want to run MPLS as it currently 
>exists in 10s of thousands of devices, then  you need a PW 
>that can carry IP as well as all the control and OAM depends on it.
>
>So whatever solution we get to needs to carry both MPLS and 
>IP.  And if that is the case then relying on EOS is a non-starter.
>
>...George
>
>
>> This would be for an MPLS PW, which we have not yet defined (a new 
>> MPLS PW draft would be required). Thus, we are free to make 
>up the rules.
>> 
>> Note that I'm still pretty much in agreement that we don't need an 
>> MPLS PW to run MPLS over MPLS-TP (I'm still awaiting further 
>arguments 
>> from Stewart or anyone else that wants to argue in favor of 
>using a PW).
>> 
>> However, I do think that we would need an MPLS-TP PW if we wanted to 
>> run MPLS-TP over MPLS (that came up last week as well). The primary 
>> issue here is that MPLS-TP over MPLS would require in-order 
>delivery, 
>> so it has to avoid ECMP.
>> 
>> Cheers,
>> Andy
>> 
>>> I've been thinking some more about this issue since our discussion 
>>> last week in Ipswich.  The question I asked there was 
>whether what we 
>>> gain from putting a PW label and CW in the stack to separate the 
>>> MPLS-TP stack and the MPLS stack are worth the cost:
>>> 
>(although 
>>> still not convinced that it's worth the cost, although I could 
>>> possibly still be convinced. Are there any other advantages 
>that I've 
>>> missed?
>>> 
>>> Cheers,
>>> Andy
>>> 
>>> I always fail those - I take it to indicate a faulty test 
>methodology 
>>> :)
>>>

---

From: George Swallow <[email-masked]>
Date: Mon, 26 Jan 2009 13:04:12 -0500

Several points here.

First the reserve values you speak of are all reserved in the IP Protocol
number space.  I do not believe that the powers that be will be very please
with a proposal that says that we will use values that they may later define
as a new IP version.

Second, the we're okay happens only if I filter on the labels that the
client sends me.

I don't like the "better yet" as I want IP as well as MPLS.

...George

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Mon, 26 Jan 2009 13:14:43 -0500

George,

I think a picture may help here. This is the reference model that I have
in mind.

This is a traditional MPLS network that we operate now:

CE - PE - P(*) - PE -CE

Where P(*) is zero or more core provider routers.

With MPLS-TP, this picture changes to either of the following (where
T(*) is zero or more core MPLS-TP transport switches and TE is an edge
MPLS-TP transport switch):

CE - PE - P - TE - T(*) - TE - P - PE - CE 

- or -

CE - PE - TE - T(*) - TE - PE - CE

In either case, a T-T, T-TE, or TE-TE trunk uses an MPLS-TP label stack,
and the P-TE or PE-TE interfaces have MPLS on them, to be encapsulated
within MPLS-TP, so that MPLS-TP can transparently transport the MPLS
packets between the P or PE routers.

If we're all in agreement here on this model, then when you talk about
running MPLS as it currently exists, I don't think that's an issue,
since a T and TE are devices that don't yet exist in the marketplace,
and thus we are free to define their behavior, as long as that behavior
meets the MPLS-TP requirements draft.

Cheers,
Andy

-----Original Message-----
From: George Swallow [mailto:[email-masked]] 
Sent: Monday, January 26, 2009 12:48 PM
To: Malis, Andrew G. (Andy); Drake, John E; [email-masked]
Cc: [email-masked]; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

An MPLS PW is fine if you want to run MPLS-TP over MPLS or MPLS-TP.
However
if you want to run MPLS as it currently exists in 10s of thousands of
devices, then  you need a PW that can carry IP as well as all the
control
and OAM depends on it.

So whatever solution we get to needs to carry both MPLS and IP.  And if
that
is the case then relying on EOS is a non-starter.

...George

On 1/26/09 12:01 PM, "Malis, Andrew G. (Andy)"
<[email-masked]>

> This would be for an MPLS PW, which we have not yet defined (a new
MPLS
> Note that I'm still pretty much in agreement that we don't need an
MPLS
> However, I do think that we would need an MPLS-TP PW if we wanted to
run
>> methodology :)

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 26 Jan 2009 10:15:45 -0800

>Sent: Monday, January 26, 2009 10:04 AM
>To: Drake, John E; Malis, Andrew G. (Andy); [email-masked]
>First the reserve values you speak of are all reserved in the 
>IP Protocol number space.  I do not believe that the powers 
>that be will be very please with a proposal that says that we 
>will use values that they may later define as a new IP version.

JD:  Then how was PW able to get the values '0' and '1'?

>
>Second, the we're okay happens only if I filter on the labels 
>that the client sends me.

JD:  Who is 'I' and who is 'client'?  The endpoints will understand the
labels they have allocated, and it keeps intermediate nodes from
performing ECMP on MPLS payloads.  

>I don't like the "better yet" as I want IP as well as MPLS.

JD:  If one takes the position that MPLS is part of IP, then allocating
a nibble value to MPLS makes sense to me.  It also addresses the issue
you raised in your first paragraph, above, as well as your point about
running IP and MPLS (and PW) over the same SP MPLS LSP.
 
>MPLS-TP.  
>>> However if you want to run MPLS as it currently exists in 10s of 
>>> thousands of devices, then  you need a PW that can carry IP as well 
>>> as all the control and OAM depends on it.
>>> 
>IP.  And 
>>> if that is the case then relying on EOS is a non-starter.
>>> 
>>> ...George
>>> 
>>> 
>wanted to 
>discussion 
>>>>> you have been arguing against using the serial number in 
>your last 
>>>>> few
>>>>> emails)

---

From: George Swallow <[email-masked]>
Date: Mon, 26 Jan 2009 14:37:11 -0500

I don't understand the picture.  What is the link between the P(E) device
and the TE device?

...George

---

From: George Swallow <[email-masked]>
Date: Mon, 26 Jan 2009 14:45:01 -0500

> JD:  Then how was PW able to get the values '0' and '1'?

We got the values reserved as part of getting the PW control word RFC
approved.  There is no notation that these belong to PW per se.  It simply
reserves them from ever being allocated.

> performing ECMP on MPLS payloads.

The I is the server.  If the server network wants to make sure that nothing
will arrive that could be mistaken for IP or PW then it would need to filter
what the client sends.

Also, I should note that current implementation of Label allocators would
not be happy with new restrictions on what values can be used.  Nor would
most of us be happy about reducing the label space by 25%.

...George

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Mon, 26 Jan 2009 14:46:21 -0500

George,

That's the client signal interface on the TE device, connected to a
trunk interface on the P(E) router. It would typically have MPLS packets
encapsulated over GFP if it's a physical SONET/SDH interface, over G.709
if a physical OTN interface, or over Ethernet if it a physical
GE/10GE/100GE interface. Physically, it's identical to how one would
interconnect routers using TDM-based transport switches.

Cheers,
Andy

-----Original Message-----
From: George Swallow [mailto:[email-masked]] 
Sent: Monday, January 26, 2009 2:37 PM
To: Malis, Andrew G. (Andy); Drake, John E; [email-masked]
Cc: [email-masked]; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

I don't understand the picture.  What is the link between the P(E)
device
and the TE device?

...George

On 1/26/09 1:14 PM, "Malis, Andrew G. (Andy)"
<[email-masked]>

---

From: George Swallow <[email-masked]>
Date: Mon, 26 Jan 2009 16:26:52 -0500

Andy -

I still don't get the picture.  Saying "MPLS packets" means nothing to me.

Consider this picture.

P1 
 |
 TE1 - T(*) - TE2 - P3
 |
P2

Who is directly connected to P3 from a protocol point of view?  If P3 is a
peer of TE2, then TE2 is also acting a P router.

If P3 is a neighbor of P1, then there is some link interface between P1 and
P3 instantiated over the TE cloud.  A pw would work.

If P3 is a neighbor of both P1 and P2, then there is some sort of
multiplexed link interface between P3 and TE2 which gets mapped to links to
P1 and P2 by TE2.

Please clarify.

...George

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 26 Jan 2009 22:20:25 +0000

George,

I think you are articulating something similar (if not the same) to what I
tried (badly) to do.

I also think the range of possible solutions depends on what angle you are
coming at MPLS-TP - does one want to build new or does one want to evolve
their existing MPLS deployment.  For me it is definitely the latter

In other words does one assume that when run inband the CP(/MP) uses the
GACH or uses the current method of MPLS (i.e. Run IP CP parallel to MPLS),
while I understand the case for the GACH (OOB 'in path') I don't think we
can discount the latter.

I have tried to draw what I am thinking and have posted it here:
http://www.niven-jenkins.co.uk/MPLS-TP/MPLSoverMPLS.ppt

Ben

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 27 Jan 2009 08:46:30 +0000

> JD:  Then how was PW able to get the values '0' and '1'?
On the basis that we had a need, but would design the protocols such
that we would never go back and ask for more.

Both nibbles and reserved labels are a very scarce resource that
need to last us a long time, so we need to allocate them with great
care.

Stewart

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Tue, 27 Jan 2009 09:27:03 -0500

George,

In your diagram, P1, P2, and P3 are all protocol peers, and are (at the
protocol level) direct neighbors to each other.

The P routers are NOT peers of the TE/T switches. The P routers are
clients of the TE/T switches.

P3 is a neighbor of both P1 and P2. Yes, there is a multiplexed link
interface between TE2 and P3 which gets mapped to links to P1 and P2 by
TE2. A GE/10GE/100GE interface using VLAN for multiplexing would be an
example of such an interface, as is a channelized SONET/SDH interface.
Alternatively, virtual concatenation can be used with G.709 and GFP
packet framing to obtain multiplexing over a single physical interface. 

At least in VZ, we do not plan to run the P/PE routers and T/TE switches
as peers; the network of T/TE switches provides a packet transport
service to interconnect the P/PE routers.

Cheers,
Andy

-----Original Message-----
From: George Swallow [mailto:[email-masked]] 
Sent: Monday, January 26, 2009 4:27 PM
To: Malis, Andrew G. (Andy); Drake, John E; [email-masked]
Cc: [email-masked]; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Andy -

I still don't get the picture.  Saying "MPLS packets" means nothing to
me.

Consider this picture.

P1 
 |
 TE1 - T(*) - TE2 - P3
 |
P2

Who is directly connected to P3 from a protocol point of view?  If P3 is
a
peer of TE2, then TE2 is also acting a P router.

If P3 is a neighbor of P1, then there is some link interface between P1
and
P3 instantiated over the TE cloud.  A pw would work.

If P3 is a neighbor of both P1 and P2, then there is some sort of
multiplexed link interface between P3 and TE2 which gets mapped to links
to
P1 and P2 by TE2.

Please clarify.

...George

On 1/26/09 2:46 PM, "Malis, Andrew G. (Andy)"
<[email-masked]>

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Tue, 27 Jan 2009 09:49:47 -0500

Ben,

VZ plans to "build new" in your terminology (although "building new" may
mean adding packet interface cards to current optical transport
switches, not a complete new equipment build out). It also may mean
adding G.709 interfaces to existing routers, although much depends on
what's the most cost-effective physical interface (from both the router
and the optical switch side) - that could be G.709, GFP, or
GE/10GE/100GE. 

Your diagram was very helpful even though you don't really show the
option of running MPLS over MPLS-TP. I modified it to show two different
alternatives to running client MPLS (green) over server MPLS-TP (red),
and it looks like much depends on how you run the client MPLS control
traffic. 

In figure 1, if the client MPLS control traffic (IP) is in-band (in an
LSP), you can either use an MPLS PW or the S bit as the demark. This is
the situation that I've had in mind. 

However, as in figure 2, if you run the client control traffic out of
band, then it looks like a combination IP/MPLS PW may indeed be
required.

Thanks,
Andy

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Monday, January 26, 2009 5:20 PM
To: George Swallow; Malis, Andrew G. (Andy); Drake, John E;
[email-masked]

George,

I think you are articulating something similar (if not the same) to what
I
tried (badly) to do.

I also think the range of possible solutions depends on what angle you
are
coming at MPLS-TP - does one want to build new or does one want to
evolve
their existing MPLS deployment.  For me it is definitely the latter

In other words does one assume that when run inband the CP(/MP) uses the
GACH or uses the current method of MPLS (i.e. Run IP CP parallel to
MPLS),
while I understand the case for the GACH (OOB 'in path') I don't think
we
can discount the latter.

Ben

However
control
MPLS
MPLS
run

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Tue, 27 Jan 2009 09:50:26 -0500

Sorry, I forgot the enclosure.

Andy

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Malis, Andrew G.
(Andy)
Sent: Tuesday, January 27, 2009 9:27 AM
To: George Swallow; Drake, John E; [email-masked]
Cc: [email-masked]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

George,

Cheers,
Andy

-----Original Message-----
From: George Swallow [mailto:[email-masked]] 
Sent: Monday, January 26, 2009 4:27 PM
To: Malis, Andrew G. (Andy); Drake, John E; [email-masked]
Cc: [email-masked]; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Andy -

Consider this picture.

P1 
 |
 TE1 - T(*) - TE2 - P3
 |
P2

Please clarify.

...George

---

From: George Swallow <[email-masked]>
Date: Tue, 27 Jan 2009 12:21:45 -0500

Andy -

In that case there is no MPLS over MPLS-TP!  There is only MPLS over FOO
over MPLS-TP where FOO is any of the technologies you list below.

Note.  I am NOT being flip here.  The way the routers see each other as
physically adjacent is via a link protocol multiplexing - ppp over Sonet or
Ethernet (with ethertype).  So the boxes can do IP, CLNS between them as
well as MPLS.  Otherwise they won't bring up an adjacency, run routing
protocols, etc.

...George

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Tue, 27 Jan 2009 12:26:48 -0500

George,

I see your point and I agree. Also see the email I sent to Ben this
morning, and the enclosed diagram. I now see your point about a combined
IP and MPLS PW to bring up router adjacencies and run control protocols.

Cheers,
Andy

-----Original Message-----
From: George Swallow [mailto:[email-masked]] 
Sent: Tuesday, January 27, 2009 12:22 PM
To: Malis, Andrew G. (Andy); Drake, John E; [email-masked]
Cc: [email-masked]; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Andy -

Note.  I am NOT being flip here.  The way the routers see each other as
physically adjacent is via a link protocol multiplexing - ppp over Sonet
or
Ethernet (with ethertype).  So the boxes can do IP, CLNS between them as
well as MPLS.  Otherwise they won't bring up an adjacency, run routing
protocols, etc.

...George

On 1/27/09 9:27 AM, "Malis, Andrew G. (Andy)"
<[email-masked]>

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 27 Jan 2009 17:11:51 -0800

>Sent: Monday, January 26, 2009 11:45 AM
>>> First the reserve values you speak of are all reserved in the IP 
>>> Protocol number space.  I do not believe that the powers 
>that be will 
>>> be very please with a proposal that says that we will use 
>values that 
>>> they may later define as a new IP version.
>> 
>We got the values reserved as part of getting the PW control 
>word RFC approved.  There is no notation that these belong to 
>PW per se.  It simply reserves them from ever being allocated.

JD:  So, are you saying that we can re-use them?

>
>>> Second, the we're okay happens only if I filter on the labels that 
>>> the client sends me.
>> 
>> JD:  Who is 'I' and who is 'client'?  The endpoints will understand 
>> the labels they have allocated, and it keeps intermediate nodes from 
>The I is the server.  If the server network wants to make sure 
>that nothing will arrive that could be mistaken for IP or PW 
>then it would need to filter what the client sends.

JD:  This issue would arise only if the client were to re-use one of the
defined values in the first nibble of its label, and in that case the
server would not be able to detect it. 

>
>Also, I should note that current implementation of Label 
>allocators would not be happy with new restrictions on what 
>values can be used.  Nor would most of us be happy about 
>reducing the label space by 25%.

JD:  I think it actually reduces the size of the label space by a factor
of 16 (2**4), but who is counting?

If we can say definitively that ECMP will never be deployed in an MPLS
TP network, I would much prefer to go with using a reserved label at the
bottom of the server stack, as proposed by Neil.  

>> JD:  If one takes the position that MPLS is part of IP, then 
>> allocating a nibble value to MPLS makes sense to me.  It also 
>> addresses the issue you raised in your first paragraph, 
>above, as well 
>> as your point about running IP and MPLS (and PW) over the 
>same SP MPLS LSP.
>>  
>>> 
>>> ...George
>>> 
>>>

---

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 27 Jan 2009 18:09:10 -0800

Hi All,

Why is it not possible to use LSP hierarchy for carrying MPLS
over MPLS-TP? The client MPLS LSP would be carried in a server MPLS-TP LSP
using LSP hierarchy. Why can't this be the default behavior?

rahul

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 28 Jan 2009 14:24:49 +0100

Better demarcation between the MPLS and the MPLS-TP layers....

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Rahul Aggarwal
Sent: Wednesday, January 28, 2009 04:09
To: [email-masked]
Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Hi All,

Why is it not possible to use LSP hierarchy for carrying MPLS
over MPLS-TP? The client MPLS LSP would be carried in a server MPLS-TP
LSP
using LSP hierarchy. Why can't this be the default behavior?

rahul

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 28 Jan 2009 14:33:13 +0000

> using LSP hierarchy. Why can't this be the default behavior?
Rahul

You do not just have MPLS traffic between a pair of MPLS LSRs.

You have: IP traffic for control and OAM, routing traffic
which may be carried in IP or may be carried over the datalink
as in ISIS, you may have CDP or your oen variant etc etc.

Stewart

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 28 Jan 2009 08:58:47 -0800

Stewart,

If the client and server agree to share the same stack, there is no
reason that this would not work.  As an existence proof, we have MPLS
and non-MPLS traffic sharing links today.

Thanks,

John  

>Sent: Wednesday, January 28, 2009 6:33 AM
>To: Rahul Aggarwal
>Cc: [email-masked]; Malis, Andrew G. (Andy); Drake, 
>John E; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
>> Why is it not possible to use LSP hierarchy for carrying MPLS over 
>> MPLS-TP? The client MPLS LSP would be carried in a server 
>MPLS-TP LSP

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 28 Jan 2009 09:05:14 -0800

Hi Nurit,

> Better demarcation between the MPLS and the MPLS-TP layers....

What precisely is meant by "better demarcation"?

rahul

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 28 Jan 2009 12:48:24 -0600

Rahul,

	For one thing, as is implied in Stewart's response, we don't
have a mechanism for indicating that MPLS is being transported over
MPLS-TP (like we do for MPLS over PPP, ATM, FR and Ethernet).  If
we need to also transport "other stuff" over the same MPLS-TP LSP,
then we need to have a way to demux the MPLS tarffic from "other 
stuff."  Otherwise, we would need to have separate MPLS-TP LSPs to
transport separate traffic types...

--
Eric

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Rahul Aggarwal
Sent: Wednesday, January 28, 2009 12:05 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Hi Nurit,

rahul

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 28 Jan 2009 11:07:07 -0800

Hi Eric,

> transport separate traffic types...

Why is it not sufficient to use the same existing mechanisms that allow a
MPLS LSP to transport another MPLS LSP or a PW or an IP packet?

rahul

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 28 Jan 2009 11:26:18 -0800

Hi John,

> and non-MPLS traffic sharing links today.

Agreed!!

rahul

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Wed, 28 Jan 2009 14:30:54 -0500

Eric and Rahul,

That's a perfect introduction to relating a discussion that Stewart,
George, and I had on the phone today where we talked out a lot of these
issues. 

If you want to use an MPLS-TP transport pipe to interconnect a pair of
routers in order replace current inter-router links that currently use
PoS or Ethernet for framing and protocol delineation, then you need to
be able to transport everything that gets trunked between routers now -
not just MPLS packets, but also unlabeled IP, CLNP for IS-IS, private
protocols, and so on. So just a label stack with the S bit, or using
label hierarchy is insufficient, since we'll never interconnect routers
with ONLY MPLS, and operators require a clear demarcation between
provider and client protocol headers for a number of operational and in
some cases regulatory reasons.

We talked about various alternatives for the demarcation. It's obvious
that you could use an Ethernet or PPP PW, since both Ethernet and PPP
are currently used for router interconnection, but we would like to
avoid the baggage and overhead that goes along with them. So our
thinking is to write a new PWE3 draft for an efficient generic PW that
includes a protocol ID (from PPP) in the control word. Note that
defining a generic PW is already in the PWE3 charter. That will give us
a nice efficient demarcation point between the provider and client, and
it uses an already existing protocol registry (PPP protocol IDs).

Cheers,
Andy

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Wednesday, January 28, 2009 1:48 PM
To: Rahul Aggarwal; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Rahul,

--
Eric

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

Hi Nurit,

rahul

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 28 Jan 2009 13:35:15 -0600

Rahul,

	Well, I might be a little weak on the subject of how an LSR
knows
the difference between LSP/LSP verses PW/LSP - except at the end points
of the transported LSP or PW (where the terminating LSR is presumed to 
know what it is dealing with).

	But the difference here is that your talking about things in an 
inverted order.  We can distinguish LSP over LSP from IP over LSP both
by the BoS bit and the label.  In this case, MPLS/MPLS-TP is what we
are talking about (i.e. - an MPLS-TP transport service might be used 
to transport an MPLS LSP, OAM traffic, and maybe one or more PWs or IP 
packets).

	Because we can't be sure now that an MPLS-TP LSP will be exactly

the same as any other LSP, transporting an MPLS-TP LSP over an MPLS LSP 
MUST be considered (at least at this point) as potentially different 
from transporting an MPLS LSP over an MPLS-TP LSP.

--
Eric

-----Original Message-----
From: Rahul Aggarwal [mailto:[email-masked]] 
Sent: Wednesday, January 28, 2009 2:07 PM
To: Eric Gray
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked];
Weingarten,Yaacov (NSN - IL/Hod HaSharon)
Subject: RE: [Mpls-interop] MPLS over MPLS-TP
Importance: High

Hi Eric,

> transport separate traffic types...

Why is it not sufficient to use the same existing mechanisms that allow
a
MPLS LSP to transport another MPLS LSP or a PW or an IP packet?

rahul

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 28 Jan 2009 13:37:33 -0600

Again, this inverted.  We have MPLS and non-MPLS traffic sharing links
where demuxing is defined for this capability (i.e. - PPP, Ethernet, 
FR, ATM).

--
Eric 

-----Original Message-----
Sent: Wednesday, January 28, 2009 2:26 PM

Hi John,

Agreed!!

rahul

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 28 Jan 2009 13:39:23 -0600

Andy,

	Thanks!  This is a very good example of what I was trying to
get at...

--
Eric 

-----Original Message-----
From: Malis, Andrew G. (Andy) [mailto:[email-masked]] 
Sent: Wednesday, January 28, 2009 2:31 PM
To: Eric Gray; Rahul Aggarwal; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
Subject: RE: [Mpls-interop] MPLS over MPLS-TP
Importance: High

Eric and Rahul,

Cheers,
Andy

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

Rahul,

--
Eric

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

Hi Nurit,

rahul

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 28 Jan 2009 11:40:36 -0800

Andy,

What you write below is true *only* if there are separate client and
server stacks.  If the client and server share the same stack, you are
dealing with plain vanilla MPLS, as I replied to Stewart.

So, we only need to address the issue of carrying an MPLS payload if
there is a requirement for separate client and server stacks, and I
don't actually recall seeing such a requirement.

Thanks,

John  

>Sent: Wednesday, January 28, 2009 11:31 AM
>That's a perfect introduction to relating a discussion that 
>Stewart, George, and I had on the phone today where we talked 
>out a lot of these issues. 
>
>If you want to use an MPLS-TP transport pipe to interconnect a 
>pair of routers in order replace current inter-router links 
>that currently use PoS or Ethernet for framing and protocol 
>delineation, then you need to be able to transport everything 
>that gets trunked between routers now - not just MPLS packets, 
>but also unlabeled IP, CLNP for IS-IS, private protocols, and 
>so on. So just a label stack with the S bit, or using label 
>hierarchy is insufficient, since we'll never interconnect 
>routers with ONLY MPLS, and operators require a clear 
>demarcation between provider and client protocol headers for a 
>number of operational and in some cases regulatory reasons.
>
>We talked about various alternatives for the demarcation. It's 
>obvious that you could use an Ethernet or PPP PW, since both 
>Ethernet and PPP are currently used for router 
>interconnection, but we would like to avoid the baggage and 
>overhead that goes along with them. So our thinking is to 
>write a new PWE3 draft for an efficient generic PW that 
>includes a protocol ID (from PPP) in the control word. Note 
>that defining a generic PW is already in the PWE3 charter. 
>That will give us a nice efficient demarcation point between 
>the provider and client, and it uses an already existing 
>protocol registry (PPP protocol IDs).
>
>Cheers,
>Andy
>
>	For one thing, as is implied in Stewart's response, we 
>don't have a mechanism for indicating that MPLS is being 
>transported over MPLS-TP (like we do for MPLS over PPP, ATM, 
>FR and Ethernet).  If we need to also transport "other stuff" 
>over the same MPLS-TP LSP, then we need to have a way to demux 
>the MPLS tarffic from "other stuff."  Otherwise, we would need 
>to have separate MPLS-TP LSPs to transport separate traffic types...
>
>--
>Eric
>

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Wed, 28 Jan 2009 14:56:46 -0500

John,

Looks like I have another requirement to make sure is in the
requirements draft. :-)

More seriously, at least speaking from a Verizon point of view, we do
need a clear separation between client and provider stacks. That may not
be true for all providers, but it is in our case.

Cheers,
Andy

-----Original Message-----
From: Drake, John E [mailto:[email-masked]] 
Sent: Wednesday, January 28, 2009 2:41 PM
To: Malis, Andrew G. (Andy); Eric Gray; Rahul Aggarwal; Sprecher, Nurit
(NSN - IL/Hod HaSharon)

Andy,

Thanks,

John

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 28 Jan 2009 11:59:55 -0800

Hi John and Andy,

> dealing with plain vanilla MPLS, as I replied to Stewart.

I think what John calls the "separate client and server stacks" is the
key to this conversation.

> don't actually recall seeing such a requirement.

That is my understanding as well.

rahul

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 28 Jan 2009 12:09:38 -0800

Hi Andy,

> be true for all providers, but it is in our case.

What exactly is meant by "clear separation"? What constitutes this "clear
separation"?

When MPLS is carried over MPLS-TP why does the PW approach that you
describe below provide "a clear separation" between client and provider
stacks while MPLS LSP hierarchy does not?

Note that I am not arguing against using PWs for carrying PPP or ethernet
etc over MPLS-TP. All I am saying is that we should use MPLS LSP hierarchy
for carrying MPLS over MPLS-TP; PWs for carrying Layer 2 traffic over
MPLS-TP; and carry IP over MPLS-TP either directly or using an IP PW. In
other words use existing technology. If folks want optimizations to this
technology, that has to be optional.

rahul

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 28 Jan 2009 14:20:35 -0600

John,

	When you say "separate client and server stacks", you must mean
at the same layer (i.e. - both visible to the end-point routers), as
opposed to one transporting the other, right?

	If that is the case, then - if you allow that signaling is also
transported over the same router-router link as a transported service,
then (or course) there is a requirement for "separate client and server 
stacks"...

--
Eric

-----Original Message-----
From: Drake, John E [mailto:[email-masked]] 
Sent: Wednesday, January 28, 2009 2:41 PM
To: Malis, Andrew G. (Andy); Eric Gray; Rahul Aggarwal; Sprecher, Nurit
(NSN - IL/Hod HaSharon)

Andy,

Thanks,

John

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 28 Jan 2009 12:27:12 -0800

Eric,

No, I meant a server MPLS stack, followed by an MPLS payload, as opposed
to an IPv4, IPv6, or PW payload.

Thanks,

John  

>From: Eric Gray [mailto:[email-masked]] 
>Sent: Wednesday, January 28, 2009 12:21 PM
>To: Drake, John E; Malis, Andrew G. (Andy); Rahul Aggarwal; 
>Sprecher, Nurit (NSN - IL/Hod HaSharon)
>	When you say "separate client and server stacks", you 
>must mean at the same layer (i.e. - both visible to the 
>end-point routers), as opposed to one transporting the other, right?
>
>	If that is the case, then - if you allow that signaling 
>is also transported over the same router-router link as a 
>transported service, then (or course) there is a requirement 
>for "separate client and server stacks"...
>
>--
>Eric
>
>To: Malis, Andrew G. (Andy); Eric Gray; Rahul Aggarwal; 
>Sprecher, Nurit (NSN - IL/Hod HaSharon)
>What you write below is true *only* if there are separate 
>client and server stacks.  If the client and server share the 
>same stack, you are dealing with plain vanilla MPLS, as I 
>replied to Stewart.
>
>So, we only need to address the issue of carrying an MPLS 
>payload if there is a requirement for separate client and 
>server stacks, and I don't actually recall seeing such a requirement.
>
>Thanks,
>
>John  
>
>>defining a generic PW is already in the PWE3 charter.
>>That will give us a nice efficient demarcation point between the 
>>provider and client, and it uses an already existing protocol 
>registry 
>>(PPP protocol IDs).
>>
>>Cheers,
>>Andy
>>
>don't have a 
>>mechanism for indicating that MPLS is being transported over MPLS-TP 
>>(like we do for MPLS over PPP, ATM, FR and Ethernet).  If we need to 
>>also transport "other stuff"
>>over the same MPLS-TP LSP, then we need to have a way to 
>demux the MPLS 
>>tarffic from "other stuff."  Otherwise, we would need to have 
>separate 
>>MPLS-TP LSPs to transport separate traffic types...
>>
>>--
>>Eric
>>

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 28 Jan 2009 12:37:45 -0800

Rahul and Andy,

I think some very crisp requirements describing what is and is not
permitted in the data plane are needed.  For example, what exactly does
two label stack separated by a generic PW header actually buy you versus
either a shared label stack or two back to back stacks?

Thanks,

John 

>Sent: Wednesday, January 28, 2009 12:10 PM
>To: Malis, Andrew G. (Andy)
>Cc: Drake, John E; Eric Gray; Sprecher, Nurit (NSN - IL/Hod 
>HaSharon); [email-masked]; Weingarten,Yaacov (NSN - 
>IL/Hod HaSharon)
>> need a clear separation between client and provider stacks. That may 
>> not be true for all providers, but it is in our case.
>>
>
>What exactly is meant by "clear separation"? What constitutes 
>this "clear separation"?
>
>When MPLS is carried over MPLS-TP why does the PW approach 
>that you describe below provide "a clear separation" between 
>client and provider stacks while MPLS LSP hierarchy does not?
>
>Note that I am not arguing against using PWs for carrying PPP 
>or ethernet etc over MPLS-TP. All I am saying is that we 
>should use MPLS LSP hierarchy for carrying MPLS over MPLS-TP; 
>PWs for carrying Layer 2 traffic over MPLS-TP; and carry IP 
>over MPLS-TP either directly or using an IP PW. In other words 
>use existing technology. If folks want optimizations to this 
>> To: Malis, Andrew G. (Andy); Eric Gray; Rahul Aggarwal; Sprecher, 
>> Nurit (NSN - IL/Hod HaSharon)
>> >George, and I had on the phone today where we talked out a lot of 
>> >these issues.
>> >
>> >If you want to use an MPLS-TP transport pipe to interconnect a pair 
>> >of routers in order replace current inter-router links that 
>currently 
>> >use PoS or Ethernet for framing and protocol delineation, then you 
>> >need to be able to transport everything that gets trunked between 
>> >routers now - not just MPLS packets, but also unlabeled IP, 
>CLNP for 
>> >IS-IS, private protocols, and so on. So just a label stack 
>with the S 
>> >bit, or using label hierarchy is insufficient, since we'll never 
>> >interconnect routers with ONLY MPLS, and operators require a clear 
>> >demarcation between provider and client protocol headers 
>for a number 
>> >of operational and in some cases regulatory reasons.
>> >
>> >obvious that you could use an Ethernet or PPP PW, since 
>both Ethernet 
>> >and PPP are currently used for router interconnection, but we would 
>> >like to avoid the baggage and overhead that goes along with 
>them. So 
>> >our thinking is to write a new PWE3 draft for an efficient 
>generic PW 
>> >that includes a protocol ID (from PPP) in the control word. 
>Note that 
>> >registry (PPP protocol IDs).
>> >
>> >Cheers,
>> >Andy
>> >
>> >over the same MPLS-TP LSP, then we need to have a way to demux the 
>> >MPLS tarffic from "other stuff."  Otherwise, we would need to have 
>> >separate MPLS-TP LSPs to transport separate traffic types...
>> >
>> >--
>> >Eric
>> >

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 28 Jan 2009 12:48:05 -0800

E-mail from Neil that he asked me to send to the group, as he is having
trouble getting subscribed.

> From: Harrison,N,Neil,CXM R
> Sent: 28 January 2009 10:15
> To: 'Drake, John E'; [email-masked]; 
> Niven-jenkins,B,Ben,DMF R
> Cc: [email-masked]
> Thanks John,
> Well we simply have to deprecate ECMP....this is supposed to be a 
> *transport* network, so rule No. 1 is C/S transparency.
> This means several important things, but fundamentally it means a 
> server layer network must never try and guess the meaning of any 
> client layer symbols, and for sure never change them.  So it's not 
> even something we can debate....it must happen.
> 
> Likewise the other 2 must-have behaviours are:
> -	OOB CP/MP
> -	respect rules of a connection (principally single source).
> 
> So the above are the absolute min set of requirements on MPLS-TP....if

> it does not meet them then the work will be worthless and should be 
> abandoned IMO.
> 
> Now if you do this then there are 2 corollaries:
> -	there is no notion of a common CP instance (or any func 
> component instance) between C and S layers
> -	there is no reason to have PWs at all....but if they 
> are kept (political reasons) the thing that must not happen is the 
> creation of further co-ps layer network above MPLS-TP....that would be

> just plain madness given the effort to get MPLS-TP right.....so any 
> notion of PWs must go back to being an adaptation function.
> 
> The above are all 'must do', but there are other behaviours that are 
> important 'should do' too:
> -	the always-on defect detection/handling OAM should look 
> like normal traffic......it won't if they use label 13 as 'OAM 
> indicate' (right solution is that OAM indicate should be flag in the 
> normal traffic unit header), but I can live with that;
> -	we should be able to a C/S relationship with MPLS and 
> MPLS-TP over MPLS-TP.....and my strong opinion here is that this 
> should have a special DP label that the server layer inserts (in the 
> adaptation) to indicate a clear DP partitioning between the 2 MPLS 
> networks. Note - This is
> *only* necessary if we want to keep sublayering using the S bit....I 
> think this is daft (how many other transport networks do you know that

> use sublayering like this or even PWs?).....and I also urge great 
> caution in adopting TCM OAM stuff.....but it seems some vendors have 
> already made their minds up this stuff is going in here.
> -	there must be no notion of peer interworking any 
> network modes/technologies that are not top-of-stack.
> 
> If we do that lot then MPLS-TP will be in fine shape.  It cannot be 
> perfect, but it can claim to have removed most of the arch flaws that 
> currently exist in MPLS.
> 
> To be prefect it would need:
> -	a more functionally rich header, including SA, DA, 
> muxing ID, PID with no need for label-swapping...won't happen
> -	OAM indicate in normal header.....could happen, but won't
> -	a section layer specification (ie ability to modulate 
> an EM wave to 'put bits of the wire')....could happen, but won't (not 
> a trivial exercise)
> 
> regards, Neil	
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 28 Jan 2009 21:07:55 +0000

MPLS-TP must support the separation that Andy mentions.  It is essentially
the fundamental service provided by a transport network - i.e. Ability to
carry another party's (the client) network over the transport network
infrastructure while maintaining complete independence of the client's DP,
CP, MP from those of the transport network. This is what G.805 would refer
to as a client/server relationship.

I thought this was well understood.  The current requirements draft does not
explicitly state this as a requirement but it is somewhat hidden in the
other requirements.  Section 1.2. Transport Network overview states the
following

   An important attribute of a transport network is that it is able to
   function regardless of which clients are using its connection service
   or over which transmission media it is running.  The client,
   transport network and server layers are from a functional and
   operations point of view independent layer networks.

Ben

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Wed, 28 Jan 2009 16:36:18 -0500

Andy,

What type of label will be used on the client MPLS link? Will it be
assigned by the MPLS-TP border node? It would help also if you could
define your expectations for the control plane aspects of the MPLS
client/MPLS-TP server.

In CCAMP, there's several RFCs on supporting MPLS (MPLS control plane)
over MPLS (GMPLS control plane), and also there's the work on stitching
and hierarchy which cover MPLS over MPLS and how to handle the e2e
signaling. It's not so much the data plane aspects as the control
capabilities which need to be understood. The same will be true if using
a management plane. If one is using a vlan or SONET interface to
segregate traffic and no other grooming is needed then a simple data
plane mapping could be used. But if want grooming granularity and "TE
capabilities" then some control mapping/interworking will be needed at
the MPLS/MPLS-TP border node and also MPLS OAM support will be needed on
the link between the MPLS node and MPLS/MPLS-TP border node.

Also, in l3vpn, there's Kenji's document on
draft-ietf-l3vpn-e2e-rsvp-te-reqts which discusses providing an MPLS
service and includes security aspects which need to be considered:
"In terms of control plane, in the models of C-RSVP paths and C-TE 
   LSPs both, a PE receives IPv4 or IPv6 RSVP control packets from a CE.

   If the CE is an untrusted router for service providers, the PE MUST 
   be able to limit IPv4 or IPv6 RSVP control packets. If the CE is a 
   trusted router for service providers, the PE MAY be able to limit 
   IPv4 or IPv6 control packets.  
    
   In terms of data plane, in the model of C-TE LSPs, a PE receives 
   labeled IPv4 or IPv6 data packets from a CE. If the CE is an 
   untrusted router for service providers, the PE MUST be able to limit 
   labeled IPv4 or IPv6 data packets. If the CE is a trusted router for 
   service providers, the PE MAY be able to limit labeled IPv4 or IPv6 
   data packets. Specifically, the PE must drop MPLS-labeled packets if 
   the MPLS label was not assigned over the PE-CE link on which the 
   packet was received. The PE must also be able to police traffic to 
   the traffic profile associated with the LSP on which traffic is 
   received on the PE-CE link."

Deborah

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Drake, John E
Sent: Wednesday, January 28, 2009 3:38 PM
To: Rahul Aggarwal; Malis, Andrew G. (Andy)
Cc: [email-masked]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Rahul and Andy,

Thanks,

John

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 28 Jan 2009 17:05:13 -0600

Rahul,

	The PW approach provides the demux point I mentioned.

	What Andy and Ben have been talking about has nothing 
to do with optimizations.  Our customers are usually quite
clear on what they mean in defining the differences between
requirements and optimizations.

--
Eric 

-----Original Message-----
From: Rahul Aggarwal [mailto:[email-masked]] 
Sent: Wednesday, January 28, 2009 3:10 PM
To: Malis, Andrew G. (Andy)
Cc: Drake, John E; Eric Gray; Sprecher, Nurit (NSN - IL/Hod HaSharon);
[email-masked]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
Subject: RE: [Mpls-interop] MPLS over MPLS-TP

Hi Andy,

> need a clear separation between client and provider stacks. That may
not
> be true for all providers, but it is in our case.

What exactly is meant by "clear separation"? What constitutes this
"clear
separation"?

Note that I am not arguing against using PWs for carrying PPP or
ethernet
etc over MPLS-TP. All I am saying is that we should use MPLS LSP
hierarchy
for carrying MPLS over MPLS-TP; PWs for carrying Layer 2 traffic over
MPLS-TP; and carry IP over MPLS-TP either directly or using an IP PW. In
other words use existing technology. If folks want optimizations to this
technology, that has to be optional.

rahul

Nurit

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 28 Jan 2009 15:17:27 -0800

Eric,

Invoking PW to solve an MPLS issue seems to be intrinsically ill
considered.  I think Niel's solution, placing a reserved label at the
bottom of the server stack seems to be a natural extension to RFC 3032.

Thanks,

John   

>Sent: Wednesday, January 28, 2009 3:05 PM
>Cc: Drake, John E; Sprecher, Nurit (NSN - IL/Hod HaSharon);

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 28 Jan 2009 17:20:58 -0600

John,

	That also would provide a demux point, and would be quite
acceptable - at least from that perspective.  My answer below 
was simply addressing what the solution Andy mentioned does.

--
Eric 

-----Original Message-----
From: Drake, John E [mailto:[email-masked]] 
Sent: Wednesday, January 28, 2009 6:17 PM
To: Eric Gray; Rahul Aggarwal; Malis, Andrew G. (Andy)
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked];
Weingarten,Yaacov (NSN - IL/Hod HaSharon); [email-masked]
Subject: RE: [Mpls-interop] MPLS over MPLS-TP
Importance: High

Eric,

Thanks,

John

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 29 Jan 2009 00:01:09 +0000

Colleagues,

I am struggling to follow the thread which may be to do with my lack of
cycles to read everything properly.

I am struggling to understand who is proposing what and for each proposal:
- what scenario(s) it is addressing
- what scenario(s) it is not addressing
- what, if any, interactions are required between the client & server layer
networks.

The requirement Andy/I have is for example for BT's network to carry a link
between two VZ routers such that that link appears identical to VZ's routers
as though VZ had run a cable across the floor directly between them.

Ben

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 29 Jan 2009 00:10:56 +0000

John

Yes - today there is a PID in the datalink that is used to discriminate 
between
the MPLS encapsulated data, and the IP control and OAM traffic. If
it's ISIS we need to get the various hellos, LSPs etc over as well. Then
we might have CDP etc etc.

So to connect the two LSRs together over an MPLS-TP cloud you
need some multiplexing technique.

Today this multiplexing is achieved using a data link with a PID
carried over a physical link or a virtual physical link (PW).

How are you proposing to carry the additional packet types over
an MPLS-TP network with a path that is only constructed to
carry MPLS packets?

Stewart

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 28 Jan 2009 18:12:26 -0600

Deborah,

	Not sure how any of what you ask relates to the discussion.

	In a simple case, a router might have an Ethernet over SONET
connection to an MPLS-TP service providing a connection to an IP-
adjacent router.  The MPLS-TP service connection in this case would
require insertion of some defined label at each router for traffic
addressed to the other router, using the MPLS unicast over Ethernet
code point - and (since the service is defined as MPLS-TP) no other
encapsulation is allowed (or would result in properly delivered 
data).  Otherwise, the MPLS-TP transport service looks like a wire.

	In this case, the only way these two routers have to talk to
each other is to use the appropriate labels/encapsulation defined 
for the MPLS-TP service.  All sorts of traffic would be getting
sent back and forth across this MPLS-TP link, including - in the
case under discussion - IP packets used to signal MPLS LSP setup
for some finite but (effectively) arbitrary number of MPLS LSPs.

	From a purely layering perspective, there are a number of
clean ways to do this.  The two routers might have a configured
PPP connection over the MPLS-TP link (as Andy has suggested some
number of exchanges ago) and that would allow for the usual PPP
demultiplexing (which would, among other things, allow the two
routers to distinguish the IP signaling traffic from the MPLS
labeled traffic).  Other approaches might be used as well, such
as (for instance) Ethernet over PW over the MPLS-TP link.

	The advantage of these approaches is that routers already
talk to each other very well using a PPP or an Ethernet link
for the purposes we're talking about.  Defining interfaces and
configuring connections between routers using these approaches
is very likely to work for many different routers from many
different router vendors.

	But these approaches are wasteful in terms of overhead
required for the extra headers.

	We could cut out all of the extra stuff by simply having
MPLS directly over the MPLS-TP service - as Rahul and John have
(repeatedly) suggested - and that would even allow for a demux
between IP and MPLS (provided by the BoS bit).  But this is a
link between routers, and routers may do other nifty things 
other than IP and MPLS traffic - so how do you demultiplex any
thing other than IP and MPLS?  

	In addition, because the MPLS-TP LSP between two routers 
provides a "transport service", [IP | MPLS] over the MPLS-TP 
transport service is the logical equivalent of [IP | MPLS] over 
<wire>.  Who currently defines their interfaces that way?  What
are the management objects associated with management of such
interfaces?

	The bottom line is that - even in a nice simple case, with
none of the complications you mention below - the world is not 
the simple place that some people initially thought it was.

	Suggestions that reduce the amount of waste, while keeping
the ability to demultiplex different traffic types, should be
considered.  Completely eliminating the waste may be much harder
in the final analysis...

--
Eric

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A,
ATTLABS
Sent: Wednesday, January 28, 2009 4:36 PM
To: Drake, John E; Rahul Aggarwal; Malis, Andrew G. (Andy)
Cc: [email-masked]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Andy,

    

Deborah

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

Rahul and Andy,

Thanks,

John

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 29 Jan 2009 00:14:38 +0000

> as though VZ had run a cable across the floor directly between them.
In which case it's not just MPLS pkts that you have to exchange.

Stewart

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 29 Jan 2009 00:32:21 +0000

> In which case it's not just MPLS pkts that you have to exchange.

Correct.

Ben

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 28 Jan 2009 17:02:32 -0800

Stewart,

This is an e-mail I sent Andy last month, and again on Monday:

"Great.  So, it is up to the client endpoints of the MPLS TP LSP to
understand the payload contents and we could have as payloads, for
example, MPLS packets with their own label stack, IP packets, or
ethernet PW packets which in turn contain, for example, MPLS packets or
IP packets."

So, I was optimizing for the MPLS and IP traffic, and carrying the other
stuff in a PW.

Thanks,

John    

>Sent: Wednesday, January 28, 2009 4:11 PM
>To: Drake, John E
>Cc: Rahul Aggarwal; [email-masked]; Malis, Andrew G. 
>(Andy); Weingarten, Yaacov (NSN - IL/Hod HaSharon)
>Yes - today there is a PID in the datalink that is used to 
>discriminate between the MPLS encapsulated data, and the IP 
>control and OAM traffic. If it's ISIS we need to get the 
>various hellos, LSPs etc over as well. Then we might have CDP etc etc.
>
>Today this multiplexing is achieved using a data link with a 
>PID carried over a physical link or a virtual physical link (PW).
>
>How are you proposing to carry the additional packet types 
>over an MPLS-TP network with a path that is only constructed 
>to carry MPLS packets?
>
>Stewart
>
>

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 28 Jan 2009 17:31:15 -0800

Hi John and Ben,

> So, I was optimizing for the MPLS and IP traffic, and carrying the other

John's proposal was reusing existing technology. I believe the
above proposal meets Ben's requirement:

"The requirement Andy/I have is for example for BT's network to carry a
link between two VZ routers such that that link appears identical to VZ's
routers as though VZ had run a cable across the floor directly between
them."

One way to realize the above requirement is for BT to provide VZ, MPLS-TP
LSP as the service interface. This service interface can carry MPLS or PWs
or IP as described by John above.

rahul

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 29 Jan 2009 07:51:52 +0000

John

What you seem to be saying is that the MPLS-TP (i.e. server to the MPLS 
client) PE
dissects the traffic into three classes (one of which is a PW) and sends 
them in
a bespoke encapsulation to the remote PE which then merges them.

Is that correct?

Stewart

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Thu, 29 Jan 2009 08:50:34 -0500

Rahul,

If you were to put a data analyzer on an Ethernet or PPP/PoS link
between two routers, you would see more going on than just IP, MPLS, and
PWs, all at the same layer, for example CLNP packets for IS-IS. One
could perhaps construct a pseudowire for stuff that's not IP or MPLS,
but that would either require a major change to the routers being
interconnected, or add a lot of complexity to the client interface on
MPLS-TP switches. 

As Ben stated, a fundamental requirement for MPLS-TP is to be a swap-in
replacement for TDM PPP/PoS, Ethernet, or just a cable across the floor
in order to interconnect IP/MPLS routers as currently shipped by the
entire router industry. A generic PW meets that requirement with a
minimum of complexity in the MPLS-TP switches, and no changes in the
client routers. It also adds the ability to do end-to-end OAM at the PW
layer between the endpoint client interfaces, and to utilize PW-PW
stitching between MPLS-TP domains if necessary. 

Here's an example, where R1 and R2 are all routers belonging to Provider
1 (P1), but only R1 can physically interconnect to P1's MPLS-TP
transport network, and R2 needs to utilize a second provider's MPLS-TP
transport network:

Physical interconnections:  R1 ----- P1 MPLS-TP domain ---- P2 MPLS-TP
domain ---- R2
PW layer:                            |<-----  Generic PW   

-----Original Message-----
From: Rahul Aggarwal [mailto:[email-masked]] 
Sent: Wednesday, January 28, 2009 8:31 PM
To: Drake, John E
Cc: [email-masked]; [email-masked]; Malis, Andrew G. (Andy);
Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: RE: [Mpls-interop] MPLS over MPLS-TP

Hi John and Ben,

"The requirement Andy/I have is for example for BT's network to carry a
link between two VZ routers such that that link appears identical to
VZ's
routers as though VZ had run a cable across the floor directly between
them."

One way to realize the above requirement is for BT to provide VZ,
MPLS-TP
LSP as the service interface. This service interface can carry MPLS or
PWs
or IP as described by John above.

rahul

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Thu, 29 Jan 2009 08:54:51 -0500

Whoops, this got sent too soon , let me finish it ....

Rahul,

Here's an example, where R1 and R2 are both routers belonging to
Provider 1 (P1), but only R1 can physically interconnect to P1's MPLS-TP
transport network, and R2 needs to utilize a second provider's MPLS-TP
transport network:

Physical interconnections:  R1 ----- P1 MPLS-TP domain ---- P2 MPLS-TP
domain ---- R2
PW layer:                            |<-----  Stitched generic PW
---------->|
MPLS-TP layer:                       |<----LSP------->|
|<----LSP------->|

Cheers,
Andy

-----Original Message-----
From: Rahul Aggarwal [mailto:[email-masked]] 
Sent: Wednesday, January 28, 2009 8:31 PM
To: Drake, John E
Cc: [email-masked]; [email-masked]; Malis, Andrew G. (Andy);

Hi John and Ben,

rahul

---

From: Loa Andersson <[email-masked]>
Date: Thu, 29 Jan 2009 16:14:59 +0100

All,

I'm a little bit lost on what is discussed here; what is possible,
what is practical, what we want to do or what is desirable.

Today we can run ip, mpls and pws over mpls, consequently we
can (unless we do something to stop it) run ip, mpls and pws
over mpls-tp

We can also run mpls-tp over mpls.

As a matter of fact it is also possible to run mpls and mpls-tp
over ip, at least for the mpls case this has turned to be very
practical time and again.

When runing mpls-tp over mpls or mpls over mpls-tp, we have
three options.

- We can use a single label stack (just one bos)
- We can use the bos as a de-limiter (is that a word?), the bos is
   once for mpls-tp and once for mpls.
- We can use a pw

For me this is mostly a deployment or operational choice.

If we want to run mpls and ip in a pw, this needs to be defined
in the pwe3 wg, but other than that I don't see anything that
we need to do.

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 29 Jan 2009 08:26:23 -0800

Stewart,

No, the three types of packets are all multiplexed together across the
service interface.

I think there would need to be an indication across the service
interface that a given packet is an MPLS packet, so that the reserved
label could be set at the bottom of the server stack, since you and
George won't let the first nibble of the packet be used for this.

Thanks,

John 

>Sent: Wednesday, January 28, 2009 11:52 PM
>To: Drake, John E
>> ethernet PW packets which in turn contain, for example, MPLS packets 
>> or IP packets."
>>
>> So, I was optimizing for the MPLS and IP traffic, and carrying the 
>> other stuff in a PW.
>>
>> Thanks,
>>
>> John    
>>
>>   
>John
>
>dissects the traffic into three classes (one of which is a PW) 
>and sends them in a bespoke encapsulation to the remote PE 
>which then merges them.
>
>Is that correct?
>
>Stewart
>
>
>