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

[Ben Niven-Jenkins <[e-mail]>]

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



On 28/01/2009 21:36, "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>
wrote:

> 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