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

["Eric Gray" <[e-mail]>]

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: [e-mail]
[mailto:[e-mail]] 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: [e-mail]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

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: [e-mail]
[mailto:[e-mail]] On Behalf Of Drake, John E
Sent: Wednesday, January 28, 2009 3:38 PM
To: Rahul Aggarwal; Malis, Andrew G. (Andy)
Cc: [e-mail]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

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 

>-----Original Message-----
>From: Rahul Aggarwal [mailto:[e-mail]] 
>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); [e-mail]; Weingarten,Yaacov (NSN - 
>IL/Hod HaSharon)
>Subject: RE: [Mpls-interop] MPLS over MPLS-TP
>
>
>Hi Andy,
>
>On Wed, 28 Jan 2009, Malis, Andrew G. (Andy) wrote:
>
>> 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.
>>
>
>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
>
>> Cheers,
>> Andy
>>
>> -----Original Message-----
>> From: Drake, John E [mailto:[e-mail]]
>> Sent: Wednesday, January 28, 2009 2:41 PM
>> To: Malis, Andrew G. (Andy); Eric Gray; Rahul Aggarwal; Sprecher, 
>> Nurit (NSN - IL/Hod HaSharon)
>> Cc: [e-mail]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
>> Subject: RE: [Mpls-interop] MPLS over MPLS-TP
>>
>> 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
>>
>> >-----Original Message-----
>> >From: Malis, Andrew G. (Andy) [mailto:[e-mail]]
>> >Sent: Wednesday, January 28, 2009 11:31 AM
>> >To: Eric Gray; Rahul Aggarwal; Sprecher, Nurit (NSN - IL/Hod 
>> >HaSharon)
>> >Cc: [e-mail]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
>> >Subject: Re: [Mpls-interop] MPLS over MPLS-TP
>> >
>> >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: [e-mail]
>> >[mailto:[e-mail]] On Behalf Of Eric Gray
>> >Sent: Wednesday, January 28, 2009 1:48 PM
>> >To: Rahul Aggarwal; Sprecher, Nurit (NSN - IL/Hod HaSharon)
>> >Cc: [e-mail]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
>> >Subject: Re: [Mpls-interop] MPLS over MPLS-TP
>> >
>> >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: [e-mail]
>> >[mailto:[e-mail]] On Behalf Of Rahul Aggarwal
>> >Sent: Wednesday, January 28, 2009 12:05 PM
>> >To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
>> >Cc: [e-mail]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
>> >Subject: Re: [Mpls-interop] MPLS over MPLS-TP
>> >
>> >
>> >Hi Nurit,
>> >
>> >On Wed, 28 Jan 2009, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
>> >
>> >> Better demarcation between the MPLS and the MPLS-TP layers....
>> >>
>> >
>> >What precisely is meant by "better demarcation"?
>> >
>> >rahul
>> >
>> >> -----Original Message-----
>> >> From: [e-mail] 
>> >> [mailto:[e-mail]] On Behalf Of ext
>> >Rahul Aggarwal
>> >> Sent: Wednesday, January 28, 2009 04:09
>> >> To: [e-mail]
>> >> 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
>> >>
>> >>
>> >> _______________________________________________
>> >> Mpls-interop mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/mpls-interop
>> >>
>> >>
>> >_______________________________________________
>> >Mpls-interop mailing list
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/mpls-interop
>> >_______________________________________________
>> >Mpls-interop mailing list
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/mpls-interop
>> >_______________________________________________
>> >Mpls-interop mailing list
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/mpls-interop
>> >
>>
>>
>
_______________________________________________
Mpls-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-interop
_______________________________________________
Mpls-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-interop
_______________________________________________
Mpls-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-interop