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

["BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>]

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