Subject: Re: [mpls-tp] Requirement for context-specific labels

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 12 Jan 2009 16:33:15 -0800

Hi Adrian,

On Sun, 14 Dec 2008, Adrian Farrel wrote:

> Hi,
>
> In my review of the requirements I-D I noted...
>
> >> 4) "MPLS-TP MUST support MPLS labels that are assigned by the
> >> downstream (with respect to data flow) node per [RFC3031] and
> >> [RFC3473] and MAY support context-specific MPLS labels as
> >> defined in [RFC5331]."
> >>
> >> Comments: This is a solution requirement and is as bad as "must not
> >> support PHP".
> >> Can we convert this into a proper functional requirement? In order
> >> to do that you would need to think about the function that drives
> >> downstream on demand label allocation, and why context-specific
> >> labels were introduced.
>
> Ben responded...
>
> > It was Rahul who was keen on including this text on context-specific
> > labels
> > during the Boston Design Team meeting. Rahul, could you respond Adrian's
> > comment?
>

The requirement would be MPLS P2MP hierarchy. However to indicate the
forwarding plane implication, as MPLS-TP is supposedly a profile of MPLS,
a reference to RFC 5331 and context-specific labels is useful.

rahul

> Please note that I am not saying that context specific labels should not (or
> should) be supported.
>
> All I am saying is that we need to document the real requirements. These
> might be "MPLS-TP networks MUST support the inclusion of multi-access
> links."
>
> Cheers,
> Adrian
>
>
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: <[email-masked]>
Date: Tue, 13 Jan 2009 09:55:54 -0000

Hi Rahul....I have some observations and questions on your
response...please see in-line: 

Rahul Aggarwal observed 13 January 2009 00:33
> > >> [RFC3473] and MAY support context-specific MPLS labels 
> as defined 
> > >> in [RFC5331]."
> > >>
> > > labels during the Boston Design Team meeting. Rahul, could you 
> > > respond Adrian's comment?
> >
> 
> The requirement would be MPLS P2MP hierarchy. However to 
> indicate the forwarding plane implication, as MPLS-TP is 
> supposedly a profile of MPLS, a reference to RFC 5331 and 
> context-specific labels is useful.
> 
> rahul

Can you explain what you mean by a 'p2mp hierarchy' please?  I ask
because the only truly recursive topological element is a p2p one.  And
whilst a p2mp connection is valid (at the top of a network stack) it
clearly cannot be a recursive topological entity and so cannot be
considered as the basis for the creation of hierarchy.

Aside=> Although I can understand why a label field is having to take-on
multiple semantics in MPLS (eg MPLS does not have a SA field like a true
clp-ps mode traffic unit, nor PBB-TE which whilst co-ps does retain a SA
from its cl-ps traffic unit roots.....which has lots of advantages esp
wrt OAM) in a layer network we SHOULD have consistent characteristic
information, ie the traffic unit and all fields therein
generated/terminated at trail termination points should have the same
semantics.  One can of course change these semantics and under
defect-free conditions this works fine, but if there is any
misconnectivity there is a chance of misinterpreting fields that can
have varying semantics....this is even more so when we have sublayering
within a single layer network.

regards, Neil

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 13 Jan 2009 18:32:59 +0000

Surely for the purposes of this discussion it is a given that we need to 
have p2mp MPLS-TP delivery.
It's been in the requirements from day 1, although acknowledged as a 
phase 2 deliverable.

The standard way to do p2mp in MPLS is RFC5331

Stewart