Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 1 Feb 2010 18:59:57 +0200

Stewart, Dan, Matthew and all,
First of all I'd like to say that the need for clear-cut definition of the MPLS-TP data plane architecture has been quite clear to me.
The draft is clearly the necessary first step in the right direction, and I thank you for producing it.

That said, I think that quite a few issues have been left undecided in this -00 version of the draft.

I will make a (hopefully, short) list of items that IMHO require additional clarification and, eventually, codification.

 1.  LSP Merge:
    *   In MPLS, nothing prevents LSPs from merging at some point:
       *   One well-known usage of LSP merge is FRR
       *   PHP can be considered as a special case of LSP merge
    *   One of the often repeated mantras of MPLS-TP is that its LSPs cannot be merge.
    *   It is not clear (at least, to me):
       *   Whether this limitation has to be respected at the data plane level, and if yes, then how
       *   Whether it means that FRR cannot be used in MPLS-TP
    *   Status of this topic in the -00 draft: not mentioned at all
 2.  Per-Interface Label Space:
    *   The draft states that per-interface label space MAY be used in MPLS-TP
    *   AFAIK, in MPLS:
       *   This referred to data links (including bundles, e.g., produced by LAG). As a consequence, the number of label contexts has been reasonably low
       *   This has been only allowed on P2P links
    *   One of the problems with MPLS-TP is that in many cases it does not differentiate between data links and lower layer LSPs (see also my notes regarding Sections). As a consequence, it is not clear (to me) whether per-interface label space may become a label space per lower layer LSP. (To the best of my understanding this is explicitly prohibited by RFC 3031).
    *   Status of this topic in the -00 draft: requires clarification, preferably aligned with RFC 3031.
 3.  Sections:
    *   The draft states that Sections could be data links (level 0 sections) or LSPs with N labels (level N Sections).
    *   The following is not clear to me:
       *   Can LAN-like data links be Sections in MPLS-TP (The Editors ask this question themselves when they discuss MAC addresses)
       *   Which types of LSPs can be Sections (e.g., can a P2P unidirectional LSP be a Section? Can an associated bi-directional LSP be a section? etc.).
       *   If associated bi-directional LSPs can be Sections, can we treat the LSPs rumming over these Sections as co-routed bidirectional?
       *   Per-data link (interface) label space is supported in MPLS. Does MPLS-Tp allow per-Section label space (see above)?
    *   Status of this topic in the -00 draft: requires clarification, one aspect already recognized as such by the Editors. IMHO and FWIW preferred resolution would be to equate Sections with data links
 4.  Label Allocation Schemes:
    *   MPLS recognizes two label allocation schemes, each with its own area of applicability:
       *   Downstream label allocation as per RFC 3031
       *   Upstream label allocation as per RFC 5331
    *   IMHO the label allocation scheme is essentially a data plane issue:
       *   Label allocation scheme is reflected in the Ethertype in the case of Ethernet encapsulation etc.
       *   Packets with invalid labels must be silently discarded etc.
    *   It is not clear to me, which label allocation schemes can be used in MPLS-TP.
       *   This includes applicability of these schemes, e.g., can we use upstream label allocation
       *   This issue is closely related to proposed usage of a well-known multicast MAC destination address for P2P LSPs)
    *   Status of this topic in the -00 draft: requires clarification
 5.  MAC addresses on Ethernet data links in MPLS-TP:
    *   The draft discusses this topic, and proposes using a well-known multicast DA in Ethernet encapsulations for for P2P LSPs
    *   IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of  well-known multicast DA is not compatible with the downstream label allocation scheme.
    *   Status of this topic in the -00-draft: partially recognized by the Editors, there seems to be a bug in the proposed solution.

Hopefully, these notes will be useful.

Regards,
     Sasha

    *

---

From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
Date: Wed, 3 Feb 2010 08:06:03 +0100

Hello Shasha
Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> Label alloc. Schemes in data-plane-draft'

In my view - This is a control plane issue and not a data plane issue. How the labels are assigned is outside the scope of the draft.

./
Lieven

 1.  Label Allocation Schemes:

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: 01 February 2010 18:00
To: [email-masked]; 'Dan Frost'; Bocci, Matthew (Matthew)
Cc: [email-masked]; [email-masked]
Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00

 1.  LSP Merge:

 1.  Per-Interface Label Space:

 1.  Sections:

 1.  Label Allocation Schemes:

 1.  MAC addresses on Ethernet data links in MPLS-TP:

Regards,
     Sasha

    *

---

From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
Date: Wed, 3 Feb 2010 08:06:15 +0100

Hello Shasha
Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> Per-interface label space in data-plane-draft'
I agree with the fact that the interface limitation is a bit flue in terms of the client server model.
So the question would be what is an "interface" - what relevance does it have for MPLS-TP when a server layer interface is bundled or is another LSP?  I appreciate the impact on the LAG hashing algorithms potentially including more than just the MAC address fields.
I agree with your suggestion.
./
Lieven
Per-Interface Label Space:
o    The draft states that per-interface label space MAY be used in MPLS-TP
o    AFAIK, in MPLS:
§  This referred to data links (including bundles, e.g., produced by LAG). As a consequence, the number of label contexts has been reasonably low
§  This has been only allowed on P2P links
o    One of the problems with MPLS-TP is that in many cases it does not differentiate between data links and lower layer LSPs (see also my notes regarding Sections). As a consequence, it is not clear (to me) whether per-interface label space may become a label space per lower layer LSP. (To the best of my understanding this is explicitly prohibited by RFC 3031).
o    Status of this topic in the -00 draft: requires clarification, preferably aligned with RFC 3031.

 1.  LSP Merge:

 1.  Sections:

Regards,
     Sasha

    *

---

From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
Date: Wed, 3 Feb 2010 08:06:34 +0100

Hello Shasha
Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> LSP merging in data-plane-draft'

On the topic of LSP merging... I think we need to define merging or elaborate on what merging is.
Afai understand the LSP are not merged continuously. But only when/if a failure has occurred.
So, for the concern when the FRR is operationally up and used, the other (primary) LSP is down, so in that case, I'm not sure we can still call it merging.

PHP is by default not allowed in the MPLS-TP and I think that is clear in the frame work document.
Suggestion - worth to mention but a non- issue.

./
Lieven
1.      LSP Merge:
o    In MPLS, nothing prevents LSPs from merging at some point:
§  One well-known usage of LSP merge is FRR
§  PHP can be considered as a special case of LSP merge
o    One of the often repeated mantras of MPLS-TP is that its LSPs cannot be merge.
o    It is not clear (at least, to me):
§  Whether this limitation has to be respected at the data plane level, and if yes, then how
§  Whether it means that FRR cannot be used in MPLS-TP
o    Status of this topic in the -00 draft: not mentioned at all

2.   LSP Merge:
o  In MPLS, nothing prevents LSPs from merging at some point:
§  One well-known usage of LSP merge is FRR
§  PHP can be considered as a special case of LSP merge
o  One of the often repeated mantras of MPLS-TP is that its LSPs cannot be merge.
o  It is not clear (at least, to me):
§  Whether this limitation has to be respected at the data plane level, and if yes, then how
§  Whether it means that FRR cannot be used in MPLS-TP
o  Status of this topic in the -00 draft: not mentioned at all
3.   Per-Interface Label Space:
o  The draft states that per-interface label space MAY be used in MPLS-TP
o  AFAIK, in MPLS:
§  This referred to data links (including bundles, e.g., produced by LAG). As a consequence, the number of label contexts has been reasonably low
§  This has been only allowed on P2P links
o  One of the problems with MPLS-TP is that in many cases it does not differentiate between data links and lower layer LSPs (see also my notes regarding Sections). As a consequence, it is not clear (to me) whether per-interface label space may become a label space per lower layer LSP. (To the best of my understanding this is explicitly prohibited by RFC 3031).
o  Status of this topic in the -00 draft: requires clarification, preferably aligned with RFC 3031.
4.   Sections:
o  The draft states that Sections could be data links (level 0 sections) or LSPs with N labels (level N Sections).
o  The following is not clear to me:
§  Can LAN-like data links be Sections in MPLS-TP (The Editors ask this question themselves when they discuss MAC addresses)
§  Which types of LSPs can be Sections (e.g., can a P2P unidirectional LSP be a Section? Can an associated bi-directional LSP be a section? etc.).
§  If associated bi-directional LSPs can be Sections, can we treat the LSPs rumming over these Sections as co-routed bidirectional?
§  Per-data link (interface) label space is supported in MPLS. Does MPLS-Tp allow per-Section label space (see above)?
o  Status of this topic in the -00 draft: requires clarification, one aspect already recognized as such by the Editors. IMHO and FWIW preferred resolution would be to equate Sections with data links
5.   Label Allocation Schemes:
o  MPLS recognizes two label allocation schemes, each with its own area of applicability:
§  Downstream label allocation as per RFC 3031
§  Upstream label allocation as per RFC 5331
o  IMHO the label allocation scheme is essentially a data plane issue:
§  Label allocation scheme is reflected in the Ethertype in the case of Ethernet encapsulation etc.
§  Packets with invalid labels must be silently discarded etc.
o  It is not clear to me, which label allocation schemes can be used in MPLS-TP.
§  This includes applicability of these schemes, e.g., can we use upstream label allocation
§  This issue is closely related to proposed usage of a well-known multicast MAC destination address for P2P LSPs)
o  Status of this topic in the -00 draft: requires clarification
6.   MAC addresses on Ethernet data links in MPLS-TP:
o  The draft discusses this topic, and proposes using a well-known multicast DA in Ethernet encapsulations for for P2P LSPs
o  IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of  well-known multicast DA is not compatible with the downstream label allocation scheme.
o  Status of this topic in the -00-draft: partially recognized by the Editors, there seems to be a bug in the proposed solution.
Hopefully, these notes will be useful.

Regards,
     Sasha

    *

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 4 Feb 2010 15:12:01 +0200

Lieven,
Lots of thanks for a prompt response.

IMHO and FWIW the label allocation scheme is not just a control plane issue.
Please note that, as per RFC 5332, MPLS packets with upstream-allocated labels use a different code point on Ethernet links and GRE tunnels.
To me this is a data plane issue.

What is more, upstream-allocated labels must refer to a certain context by the downstream router. And context resolution is part of the data plane as well.

Regards,
     Sasha

________________________________
From: LEVRAU, LIEVEN (LIEVEN) [mailto:[email-masked]]
Sent: Wednesday, February 03, 2010 9:06 AM
To: Alexander Vainshtein; [email-masked]; 'Dan Frost'; Bocci, Matthew (Matthew)
Cc: [email-masked]; [email-masked]
Subject: Label alloc. Schemes in data-plane-draft'

Hello Shasha

./
Lieven

 1.  LSP Merge:

 1.  Sections:

Regards,
     Sasha

    *

---

From: <[email-masked]>
Date: Thu, 4 Feb 2010 16:58:21 -0000

One remark....
 
Sasha wrote 04 February 2010 13:12

	Lieven,
	 
	IMHO and FWIW the label allocation scheme is not just a control
plane issue.
	Please note that, as per RFC 5332, MPLS packets with
upstream-allocated labels use a different code point on Ethernet links
and GRE tunnels.
	To me this is a data plane issue.
	 
	What is more, upstream-allocated labels must refer to a certain
context by the downstream router. And context resolution is part of the
data plane as well.

NH=> Indeed it is.  I'd refer to this as the requirement for the DP
traffic units to have consistent characteristic information (CI)
...which is more than the label of course, but the label is the most
functionally overworked field in an MPLS traffic unit.  One can at least
mitigate the effects of poor DP CI design by adding a consistent OAM CV
flow to every LSP.

Aside=> In a transport network context I think the MPLS-TP label only
needs to have 2 types of semantic:
-	forwarding semantic if value >15...swapped per hop
(label-swapping is not ideal, the best forwarding labels are like the
ones used in a cl-ps network like IP or Ethernet, ie network unique and
not swapped per hop...this mitigates misconnectivity even without any
adjunct CV OAM flow)
-	globally well-known functional action semantic if value
0-15...never swapped

regards, Neil
	 
	Regards,
	     Sasha

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 05 Feb 2010 11:59:46 +0100

Sasha,
 
There can/will be many labels in the label stack on MPSL-TP interfaces. 
Is the Ethernet code point application only to the top of stack label, or to
all labels in the stack?
 
I would expect that the code point only applies to the top of stack label
and not to the non-top of stack labels; is this correct?
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Vainshtein
Sent: donderdag 4 februari 2010 14:12
To: LEVRAU, LIEVEN (LIEVEN)
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Label alloc. Schemes in data-plane-draft'

Lieven,
 
IMHO and FWIW the label allocation scheme is not just a control plane issue.
Please note that, as per RFC 5332, MPLS packets with upstream-allocated
labels use a different code point on Ethernet links and GRE tunnels.
To me this is a data plane issue.
 
What is more, upstream-allocated labels must refer to a certain context by
the downstream router. And context resolution is part of the data plane as
well.
 
Regards,
     Sasha

 

  _____  

To: Alexander Vainshtein; [email-masked]; 'Dan Frost'; Bocci, Matthew
(Matthew)

Hello Shasha

Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> Label
alloc. Schemes in data-plane-draft'

In my view - This is a control plane issue and not a data plane issue. How
the labels are assigned is outside the scope of the draft.

./

Lieven

*	MPLS recognizes two label allocation schemes, each with its own area
of applicability: 

*	Label allocation scheme is reflected in the Ethertype in the case of
Ethernet encapsulation etc. 

*	It is not clear to me, which label allocation schemes can be used in
MPLS-TP. 

*	This includes applicability of these schemes, e.g., can we use
upstream label allocation 

*	This issue is closely related to proposed usage of a well-known
multicast MAC destination address for P2P LSPs) 

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexander Vainshtein

First of all I'd like to say that the need for clear-cut definition of the
MPLS-TP data plane architecture has been quite clear to me.

The draft is clearly the necessary first step in the right direction, and I
thank you for producing it.

That said, I think that quite a few issues have been left undecided in this
-00 version of the draft.

I will make a (hopefully, short) list of items that IMHO require additional
clarification and, eventually, codification.

1.	LSP Merge: 

*	One of the often repeated mantras of MPLS-TP is that its LSPs cannot
be merge.  

*	Whether this limitation has to be respected at the data plane level,
and if yes, then how 

*	The draft states that per-interface label space MAY be used in
MPLS-TP 

*	AFAIK, in MPLS: 

*	This referred to data links (including bundles, e.g., produced by
LAG). As a consequence, the number of label contexts has been reasonably low

*	One of the problems with MPLS-TP is that in many cases it does not
differentiate between data links and lower layer LSPs (see also my notes
regarding Sections). As a consequence, it is not clear (to me) whether
per-interface label space may become a label space per lower layer LSP. (To
the best of my understanding this is explicitly prohibited by RFC 3031). 

*	Status of this topic in the -00 draft: requires clarification,
preferably aligned with RFC 3031. 

3.	Sections: 

*	The draft states that Sections could be data links (level 0
sections) or LSPs with N labels (level N Sections). 

*	Can LAN-like data links be Sections in MPLS-TP (The Editors ask this
question themselves when they discuss MAC addresses) 

*	Which types of LSPs can be Sections (e.g., can a P2P unidirectional
LSP be a Section? Can an associated bi-directional LSP be a section? etc.). 

*	If associated bi-directional LSPs can be Sections, can we treat the
LSPs rumming over these Sections as co-routed bidirectional? 

*	Per-data link (interface) label space is supported in MPLS. Does
MPLS-Tp allow per-Section label space (see above)? 

*	Status of this topic in the -00 draft: requires clarification, one
aspect already recognized as such by the Editors. IMHO and FWIW preferred
resolution would be to equate Sections with data links 

*	MPLS recognizes two label allocation schemes, each with its own area
of applicability: 

*	Label allocation scheme is reflected in the Ethertype in the case of
Ethernet encapsulation etc. 

*	It is not clear to me, which label allocation schemes can be used in
MPLS-TP. 

*	This includes applicability of these schemes, e.g., can we use
upstream label allocation 

*	This issue is closely related to proposed usage of a well-known
multicast MAC destination address for P2P LSPs) 

*	The draft discusses this topic, and proposes using a well-known
multicast DA in Ethernet encapsulations for for P2P LSPs 

*	IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of
well-known multicast DA is not compatible with the downstream label
allocation scheme. 

*	Status of this topic in the -00-draft: partially recognized by the
Editors, there seems to be a bug in the proposed solution. 

Regards,

     Sasha

*

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 5 Feb 2010 20:28:25 +0200

Maarten,
Lots of thanks for an EXCELLENT question.

I do not think I can answer it in full, but the following considerations may be useful.

 1.  Downstream label allocation scheme is explicitly defined as the default  in RFC 5331 and 5332. Hence, IMHO, if the code point of the data link defines the top label as downstream-assigned, the router terminating this label will treat the next one(s) as downstream-assigned - unless it has been explicitly aware that they are upstream-assigned. In other words, the LSR terminating the top label must explicitly bind it to a context space for upstream-allocated ones.
 2.  The primary usage of upstream-allocated labels in MPLS (but not necessary in MPLS-TP) is MPLS multicast, and the dedicated codepoints are used in conjunction with multicast datalink addresses (or their analogs as in the case of MPLS-in-GRE). This means that, generally speaking, more than one router can terminate the top upstream-allocated label and look at the next one. And this is only compatible with the upstream allocation scheme for the next label.

Does this help? Did I miss something important?

Regards,

     Sasha

________________________________
From: Maarten Vissers [[email-masked]]
Sent: Friday, February 05, 2010 12:59 PM
To: Alexander Vainshtein; 'LEVRAU, LIEVEN (LIEVEN)'
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft'

Sasha,

There can/will be many labels in the label stack on MPSL-TP interfaces.
Is the Ethernet code point application only to the top of stack label, or to all labels in the stack?

I would expect that the code point only applies to the top of stack label and not to the non-top of stack labels; is this correct?

Regards,
Maarten

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein

Lieven,

Regards,
     Sasha

Hello Shasha
Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> Label alloc. Schemes in data-plane-draft’

./
Lieven

 1.  LSP Merge:

 1.  Sections:

Regards,
     Sasha

    *

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 6 Feb 2010 14:56:06 +0200

Resending as plain text due to size limitations.

Regards,
     Sasha

From: Alexander Vainshtein
Sent: Saturday, February 06, 2010 11:14 AM
To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)'
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft'

Maarten, Lieven and all,
On the second thought, it seems that if the data link code point indicates the downstream label allocation scheme for the top label, then the next label MUST be downstream-allocated as well.

This is because processing of this label, as defined in 3031, MUST NOT depend on any labels that have been present above it in the label stack and terminated (popped) by the LSR that looks it up.

The relevant text in Section 3.9 states:

Although, as we shall see, MPLS supports a hierarchy, the processing of a labeled packet is completely independent of the level of hierarchy.  The processing is always based on the top label, without regard for the possibility that some number of other labels may have   been "above it" in the past, or that some number of other labels may be below it at present.
In other words, downstream label allocation scheme does not support "context labels" defined in 5331. They are only compatible with the upstream label allocation scheme.
The bottom line:
If the data link code point indicates downstream label allocation of the top label, then all the labels in the stack MUST be downstream-allocated (by the appropriate LSRs)
If the data link code point indicates upstream label allocation of the top label, then both upstream-allocated and downstream-allocated labels MAY appear in the stack. In certain situations such a mix can result in undesirable behavior.
Regards,
     Sasha

From: [email-masked] [[email-masked]] On Behalf Of Alexander Vainshtein [[email-masked]]
Sent: Friday, February 05, 2010 8:28 PM
To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)'
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft'

Maarten,

Downstream label allocation scheme is explicitly defined as the default  in RFC 5331 and 5332. Hence, IMHO, if the code point of the data link defines the top label as downstream-assigned, the router terminating this label will treat the next one(s) as downstream-assigned - unless it has been explicitly aware that they are upstream-assigned. In other words, the LSR terminating the top label must explicitly bind it to a context space for upstream-allocated ones. 
The primary usage of upstream-allocated labels in MPLS (but not necessary in MPLS-TP) is MPLS multicast, and the dedicated codepoints are used in conjunction with multicast datalink addresses (or their analogs as in the case of MPLS-in-GRE). This means that, generally speaking, more than one router can terminate the top upstream-allocated label and look at the next one. And this is only compatible with the upstream allocation scheme for the next label.

Regards,
     Sasha

Sasha,

Regards,
Maarten

Lieven,

Regards,
     Sasha

Hello Shasha

./
Lieven
Label Allocation Schemes: 
MPLS recognizes two label allocation schemes, each with its own area of applicability: 
Downstream label allocation as per RFC 3031 
Upstream label allocation as per RFC 5331 
IMHO the label allocation scheme is essentially a data plane issue: 
Label allocation scheme is reflected in the Ethertype in the case of Ethernet encapsulation etc. 
Packets with invalid labels must be silently discarded etc. 
It is not clear to me, which label allocation schemes can be used in MPLS-TP. 
This includes applicability of these schemes, e.g., can we use upstream label allocation 
This issue is closely related to proposed usage of a well-known multicast MAC destination address for P2P LSPs) 
Status of this topic in the -00 draft: requires clarification 

LSP Merge: 
In MPLS, nothing prevents LSPs from merging at some point: 
One well-known usage of LSP merge is FRR 
PHP can be considered as a special case of LSP merge 
One of the often repeated mantras of MPLS-TP is that its LSPs cannot be merge.  
It is not clear (at least, to me): 
Whether this limitation has to be respected at the data plane level, and if yes, then how 
Whether it means that FRR cannot be used in MPLS-TP 
Status of this topic in the -00 draft: not mentioned at all 
Per-Interface Label Space: 
The draft states that per-interface label space MAY be used in MPLS-TP 
AFAIK, in MPLS: 
This referred to data links (including bundles, e.g., produced by LAG). As a consequence, the number of label contexts has been reasonably low 
This has been only allowed on P2P links 
One of the problems with MPLS-TP is that in many cases it does not differentiate between data links and lower layer LSPs (see also my notes regarding Sections). As a consequence, it is not clear (to me) whether per-interface label space may become a label space per lower layer LSP. (To the best of my understanding this is explicitly prohibited by RFC 3031). 
Status of this topic in the -00 draft: requires clarification, preferably aligned with RFC 3031. 
Sections: 
The draft states that Sections could be data links (level 0 sections) or LSPs with N labels (level N Sections). 
The following is not clear to me: 
Can LAN-like data links be Sections in MPLS-TP (The Editors ask this question themselves when they discuss MAC addresses) 
Which types of LSPs can be Sections (e.g., can a P2P unidirectional LSP be a Section? Can an associated bi-directional LSP be a section? etc.). 
If associated bi-directional LSPs can be Sections, can we treat the LSPs rumming over these Sections as co-routed bidirectional? 
Per-data link (interface) label space is supported in MPLS. Does MPLS-Tp allow per-Section label space (see above)? 
Status of this topic in the -00 draft: requires clarification, one aspect already recognized as such by the Editors. IMHO and FWIW preferred resolution would be to equate Sections with data links 
Label Allocation Schemes: 
MPLS recognizes two label allocation schemes, each with its own area of applicability: 
Downstream label allocation as per RFC 3031 
Upstream label allocation as per RFC 5331 
IMHO the label allocation scheme is essentially a data plane issue: 
Label allocation scheme is reflected in the Ethertype in the case of Ethernet encapsulation etc. 
Packets with invalid labels must be silently discarded etc. 
It is not clear to me, which label allocation schemes can be used in MPLS-TP. 
This includes applicability of these schemes, e.g., can we use upstream label allocation 
This issue is closely related to proposed usage of a well-known multicast MAC destination address for P2P LSPs) 
Status of this topic in the -00 draft: requires clarification 
MAC addresses on Ethernet data links in MPLS-TP: 
The draft discusses this topic, and proposes using a well-known multicast DA in Ethernet encapsulations for for P2P LSPs 
IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of  well-known multicast DA is not compatible with the downstream label allocation scheme. 
Status of this topic in the -00-draft: partially recognized by the Editors, there seems to be a bug in the proposed solution. 
Hopefully, these notes will be useful.

Regards,
     Sasha

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 08 Feb 2010 08:30:03 +0100

Sasha,

If I am thinking of a set of p2mp PWs and/or service LSPs carried in a p2mp
LSP carried over a p2p LSP. The oter p2p LSP is set up prior to service
requests, and uses downstream allocated labels, whereas the p2mp
PWs/serviceLSPs must use upstream allocated labels. The intermediate p2mp
LSP can use downstream allocated labels.

This implies that I have the top two labels with downstream allocated and
the bottom label with upstream allocated. Correct?

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: zaterdag 6 februari 2010 13:56
To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)'
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Label alloc. Schemes in data-plane-draft'

Regards,
     Sasha

Maarten, Lieven and all,
On the second thought, it seems that if the data link code point indicates
the downstream label allocation scheme for the top label, then the next
label MUST be downstream-allocated as well.

This is because processing of this label, as defined in 3031, MUST NOT
depend on any labels that have been present above it in the label stack and
terminated (popped) by the LSR that looks it up.

Although, as we shall see, MPLS supports a hierarchy, the processing of a
labeled packet is completely independent of the level of hierarchy.  The
processing is always based on the top label, without regard for the
possibility that some number of other labels may have   been "above it" in
the past, or that some number of other labels may be below it at present.
In other words, downstream label allocation scheme does not support "context
labels" defined in 5331. They are only compatible with the upstream label
allocation scheme.
The bottom line:
If the data link code point indicates downstream label allocation of the top
label, then all the labels in the stack MUST be downstream-allocated (by the
appropriate LSRs) If the data link code point indicates upstream label
allocation of the top label, then both upstream-allocated and
downstream-allocated labels MAY appear in the stack. In certain situations
such a mix can result in undesirable behavior.
Regards,
     Sasha

From: [email-masked] [[email-masked]] On Behalf Of Alexander
Vainshtein [[email-masked]]
Sent: Friday, February 05, 2010 8:28 PM
To: Maarten Vissers; 'LEVRAU, LIEVEN (LIEVEN)'
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft'

Maarten,

I do not think I can answer it in full, but the following considerations may
be useful.

Downstream label allocation scheme is explicitly defined as the default  in
RFC 5331 and 5332. Hence, IMHO, if the code point of the data link defines
the top label as downstream-assigned, the router terminating this label will
treat the next one(s) as downstream-assigned - unless it has been explicitly
aware that they are upstream-assigned. In other words, the LSR terminating
the top label must explicitly bind it to a context space for
upstream-allocated ones. 
The primary usage of upstream-allocated labels in MPLS (but not necessary in
MPLS-TP) is MPLS multicast, and the dedicated codepoints are used in
conjunction with multicast datalink addresses (or their analogs as in the
case of MPLS-in-GRE). This means that, generally speaking, more than one
router can terminate the top upstream-allocated label and look at the next
one. And this is only compatible with the upstream allocation scheme for the
next label.

Regards,
     Sasha

Sasha,

Regards,
Maarten

Lieven,

Regards,
     Sasha

Hello Shasha

./
Lieven
Label Allocation Schemes: 
MPLS recognizes two label allocation schemes, each with its own area of
applicability: 
Downstream label allocation as per RFC 3031 
Upstream label allocation as per RFC 5331 
IMHO the label allocation scheme is essentially a data plane issue: 
Label allocation scheme is reflected in the Ethertype in the case of
Ethernet encapsulation etc. 
Packets with invalid labels must be silently discarded etc. 
It is not clear to me, which label allocation schemes can be used in
MPLS-TP. 
This includes applicability of these schemes, e.g., can we use upstream
label allocation 
This issue is closely related to proposed usage of a well-known multicast
MAC destination address for P2P LSPs) 
Status of this topic in the -00 draft: requires clarification 

LSP Merge: 
In MPLS, nothing prevents LSPs from merging at some point: 
One well-known usage of LSP merge is FRR 
PHP can be considered as a special case of LSP merge 
One of the often repeated mantras of MPLS-TP is that its LSPs cannot be
merge.  
It is not clear (at least, to me): 
Whether this limitation has to be respected at the data plane level, and if
yes, then how 
Whether it means that FRR cannot be used in MPLS-TP 
Status of this topic in the -00 draft: not mentioned at all 
Per-Interface Label Space: 
The draft states that per-interface label space MAY be used in MPLS-TP 
AFAIK, in MPLS: 
This referred to data links (including bundles, e.g., produced by LAG). As a
consequence, the number of label contexts has been reasonably low 
This has been only allowed on P2P links 
One of the problems with MPLS-TP is that in many cases it does not
differentiate between data links and lower layer LSPs (see also my notes
regarding Sections). As a consequence, it is not clear (to me) whether
per-interface label space may become a label space per lower layer LSP. (To
the best of my understanding this is explicitly prohibited by RFC 3031). 
Status of this topic in the -00 draft: requires clarification, preferably
aligned with RFC 3031. 
Sections: 
The draft states that Sections could be data links (level 0 sections) or
LSPs with N labels (level N Sections). 
The following is not clear to me: 
Can LAN-like data links be Sections in MPLS-TP (The Editors ask this
question themselves when they discuss MAC addresses) 
Which types of LSPs can be Sections (e.g., can a P2P unidirectional LSP be a
Section? Can an associated bi-directional LSP be a section? etc.). 
If associated bi-directional LSPs can be Sections, can we treat the LSPs
rumming over these Sections as co-routed bidirectional? 
Per-data link (interface) label space is supported in MPLS. Does MPLS-Tp
allow per-Section label space (see above)? 
Status of this topic in the -00 draft: requires clarification, one aspect
already recognized as such by the Editors. IMHO and FWIW preferred
resolution would be to equate Sections with data links 
Label Allocation Schemes: 
MPLS recognizes two label allocation schemes, each with its own area of
applicability: 
Downstream label allocation as per RFC 3031 
Upstream label allocation as per RFC 5331 
IMHO the label allocation scheme is essentially a data plane issue: 
Label allocation scheme is reflected in the Ethertype in the case of
Ethernet encapsulation etc. 
Packets with invalid labels must be silently discarded etc. 
It is not clear to me, which label allocation schemes can be used in
MPLS-TP. 
This includes applicability of these schemes, e.g., can we use upstream
label allocation 
This issue is closely related to proposed usage of a well-known multicast
MAC destination address for P2P LSPs) 
Status of this topic in the -00 draft: requires clarification 
MAC addresses on Ethernet data links in MPLS-TP: 
The draft discusses this topic, and proposes using a well-known multicast DA
in Ethernet encapsulations for for P2P LSPs 
IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of  well-known
multicast DA is not compatible with the downstream label allocation scheme. 
Status of this topic in the -00-draft: partially recognized by the Editors,
there seems to be a bug in the proposed solution. 
Hopefully, these notes will be useful.

Regards,
     Sasha=

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 8 Feb 2010 10:45:19 +0200

Maarten,
In short: NOT CORRECT.
The construction you present violates the MPLS data plane architecture as defined in 3031.

The LSR that terminates the outer P2P LSP cannot know that the next label it looks-up  
is upstream-allocated (and hence to be looked-up in a different context): 
- the data link does not indicate that (otherwise the top label would be upstream-allocated)
- the terminated label CANNOT be used as the context label. It must be processed 
  regardless of its position in the label stack.

Aside: 
Early LSRs have used a physical loopback interface for multiple label look-ups.
I.e., when they received a labeled packet with two or more labels in the stack and wanted
to look at the 2nd label, they physically popped the top label and forwarded the packet
to a dedicated looped-back physical interface. The packet received from that interface would
have the former 2nd label as the top one, and would then process it as any other top label.
Of course, the top label and the original ingress interface would be lost in this operation.
MPLS (and PW) architecture has been designed to allow this type of processing.
Modern LSRs do not usually use a physical loopback interface for multiple label lookups, 
but neither do they prevent their downstream peers from using it as long as the downstream 
label allocation scheme is used. 

Hopefully this clarification will be helpful.

Regards,
     Sasha

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Maarten Vissers
> Sent: Monday, February 08, 2010 9:30 AM
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of Alexander Vainshtein
> upstream-allocated
> From: LEVRAU, LIEVEN (LIEVEN) 
> [mailto:[email-masked]]
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 08 Feb 2010 13:10:41 +0100

Sasha,

An interesting limitation in the MPLS data plane architecture.
>From a transport network perspective one should not expect such limitation.

E.g. in OTN I can set up a p2p HO ODU3 connection over which I carry a p2mp
LO ODU2 connection, which carries up to 8 p2mp ODU0 signals with e.g. 1GE
clients.

And in an Ethernet network I can set up a p2p Ethernet VP connection over
which I carry a p2mp Ethernet VC connection, which carries a number of p2mp
Ethernet VLANs.

The fact that both OTN and Ethernet can support the example, I am wondering
if it is the MPLS data plane architecture that is not capable, or if it are
the existing MPLS equipment that are not capable?

Regards,
Maarten 

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: maandag 8 februari 2010 9:45
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; 'LEVRAU, LIEVEN (LIEVEN)'
Subject: RE: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft'

Maarten,
In short: NOT CORRECT.
The construction you present violates the MPLS data plane architecture as
defined in 3031.

The LSR that terminates the outer P2P LSP cannot know that the next label it
looks-up is upstream-allocated (and hence to be looked-up in a different
context): 
- the data link does not indicate that (otherwise the top label would be
upstream-allocated)
- the terminated label CANNOT be used as the context label. It must be
processed
  regardless of its position in the label stack.

Aside: 
Early LSRs have used a physical loopback interface for multiple label
look-ups.
I.e., when they received a labeled packet with two or more labels in the
stack and wanted to look at the 2nd label, they physically popped the top
label and forwarded the packet to a dedicated looped-back physical
interface. The packet received from that interface would have the former 2nd
label as the top one, and would then process it as any other top label.
Of course, the top label and the original ingress interface would be lost in
this operation.
MPLS (and PW) architecture has been designed to allow this type of
processing.
Modern LSRs do not usually use a physical loopback interface for multiple
label lookups, but neither do they prevent their downstream peers from using
it as long as the downstream label allocation scheme is used. 

Regards,
     Sasha

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Maarten Vissers
> If I am thinking of a set of p2mp PWs and/or service LSPs carried in a 
> p2mp LSP carried over a p2p LSP. The oter p2p LSP is set up prior to 
> service requests, and uses downstream allocated labels, whereas the 
> p2mp PWs/serviceLSPs must use upstream allocated labels. The 
> intermediate p2mp LSP can use downstream allocated labels.
> 
> This implies that I have the top two labels with downstream allocated 
> and the bottom label with upstream allocated. Correct?
> 
> Regards,
> Maarten
> 
> 
> On the second thought, it seems that if the data link code point 
> indicates the downstream label allocation scheme for the top label, 
> then the next label MUST be downstream-allocated as well.
> 
> depend on any labels that have been present above it in the label 
> stack and terminated (popped) by the LSR that looks it up.
> 
> Although, as we shall see, MPLS supports a hierarchy, the processing 
> of a labeled packet is completely independent of the level of 
> hierarchy.  The processing is always based on the top label, without 
> regard for the
> In other words, downstream label allocation scheme does not support 
> "context labels" defined in 5331. They are only compatible with the 
> upstream label allocation scheme.
> The bottom line:
> If the data link code point indicates downstream label allocation of 
> the top label, then all the labels in the stack MUST be 
> downstream-allocated (by the appropriate LSRs) If the data link code 
> point indicates upstream label allocation of the top label, then both 
> upstream-allocated and downstream-allocated labels MAY appear in the 
> stack. In certain situations such a mix can result in undesirable 
> behavior.
> Regards,
>      Sasha
>  
> 
> 
> 
> 
> From: [email-masked] [[email-masked]] On Behalf Of 
> Alexander Vainshtein [[email-masked]]
> Downstream label allocation scheme is explicitly defined as the 
> default  in RFC 5331 and 5332. Hence, IMHO, if the code point of the 
> data link defines the top label as downstream-assigned, the router 
> terminating this label will treat the next one(s) as 
> downstream-assigned - unless it has been explicitly aware that they 
> are upstream-assigned. In other words, the LSR terminating the top 
> label must explicitly bind it to a context space for 
> upstream-allocated ones.
> conjunction with multicast datalink addresses (or their analogs as in 
> the case of MPLS-in-GRE). This means that, generally speaking, more 
> than one router can terminate the top upstream-allocated label and 
> look at the next one. And this is only compatible with the upstream 
> allocation scheme for the next label.
> 
> I would expect that the code point only applies to the top of stack 
> label and not to the non-top of stack labels; is this correct?
> 
> Regards,
> Maarten
> 
> 
> 
> 
> [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
> Behalf Of
> =

---

From: <[email-masked]>
Date: Mon, 8 Feb 2010 12:22:59 -0000

Maarten,

As I remarked in my last mail to Sasha, I am not sure MPLS-TP will be
delivering a transport network solution.  It *could* do this (as CCAMPs
folks have proved with GMPLS) but here it is a conscious choice not to
do this....and the decisions that are being taken cannot appeal to
technical naivety IMO.  The difficulty I can see is that MPLS-TP is
trying to be seen as a transport network whilst still retaining certain
behaviours from MPLS that are not behaviours of a transport network.

It's a pity IMO but it is an outcome I could see happening.

regards, Neil

> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: 08 February 2010 12:11
> To: 'Alexander Vainshtein'
> Subject: Re: [mpls-tp] [mpls] Label alloc. Schemes in 
> data-plane-draft'
> 
> Sasha,
> 
> E.g. in OTN I can set up a p2p HO ODU3 connection over which 
> I carry a p2mp LO ODU2 connection, which carries up to 8 p2mp 
> ODU0 signals with e.g. 1GE clients.
> 
> And in an Ethernet network I can set up a p2p Ethernet VP 
> connection over which I carry a p2mp Ethernet VC connection, 
> which carries a number of p2mp Ethernet VLANs.
> 
> The fact that both OTN and Ethernet can support the example, 
> I am wondering if it is the MPLS data plane architecture that 
> is not capable, or if it are the existing MPLS equipment that 
> are not capable?
> 
> Regards,
> Maarten 
> 
> The LSR that terminates the outer P2P LSP cannot know that 
> the next label it looks-up is upstream-allocated (and hence 
> to be looked-up in a different
> context): 
> I.e., when they received a labeled packet with two or more 
> labels in the stack and wanted to look at the 2nd label, they 
> physically popped the top label and forwarded the packet to a 
> dedicated looped-back physical interface. The packet received 
> from that interface would have the former 2nd label as the 
> top one, and would then process it as any other top label.
> Modern LSRs do not usually use a physical loopback interface 
> for multiple label lookups, but neither do they prevent their 
> downstream peers from using it as long as the downstream 
> > Is the Ethernet code point application only to the top of 
> stack label, 
> > or to all labels in the stack?
> > 
> > IMHO and FWIW the label allocation scheme is not just a 
> control plane 
> > issue.
> > context by the downstream router. And context resolution is part of 
> > the data plane as well.
> > 
> > Regards,
> >      Sasha
> > 
> >  
> >  
> >  
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Changed title from Comments on
> > draft-fbb-mpls-tp-data-plane-00 -> Label alloc. Schemes in 
> > data-plane-draft'
> > 
> > In my view - This is a control plane issue and not a data 
> plane issue. 
> > How the labels are assigned is outside the scope of the draft.
> > 
> > ./
> > Lieven
> > MPLS recognizes two label allocation schemes, each with its 
> own area 
> > of
> > applicability: 
> > Downstream label allocation as per RFC 3031 Upstream label 
> allocation 
> > as per RFC 5331 IMHO the label allocation scheme is 
> essentially a data 
> > plane issue:
> > This includes applicability of these schemes, e.g., can we use 
> > upstream label allocation This issue is closely related to proposed 
> > usage of a well-known multicast MAC destination address for 
> P2P LSPs) 
> > First of all I'd like to say that the need for clear-cut 
> definition of 
> > the MPLS-TP data plane architecture has been quite clear to me.
> > The draft is clearly the necessary first step in the right 
> direction, 
> > and I thank you for producing it.
> > 
> > That said, I think that quite a few issues have been left 
> undecided in 
> > this -00 version of the draft.
> > 
> > I will make a (hopefully, short) list of items that IMHO require 
> > additional clarification and, eventually, codification.
> > 
> > LSP Merge: 
> > One well-known usage of LSP merge is FRR PHP can be considered as a 
> > special case of LSP merge One of the often repeated mantras 
> of MPLS-TP 
> > is that its LSPs cannot be merge.
> > Whether this limitation has to be respected at the data 
> plane level, 
> > and if yes, then how Whether it means that FRR cannot be used in 
> > MPLS-TP Status of this topic in the -00 draft: not mentioned at all 
> > This referred to data links (including bundles, e.g., produced by 
> > LAG). As a consequence, the number of label contexts has been 
> > reasonably low This has been only allowed on P2P links One of the 
> > problems with MPLS-TP is that in many cases it does not 
> differentiate 
> > between data links and lower layer LSPs (see also my notes 
> regarding 
> > Sections). As a consequence, it is not clear (to me) whether 
> > per-interface label space may become a label space per lower layer 
> > LSP. (To the best of my understanding this is explicitly 
> prohibited by 
> > RFC 3031).
> > question themselves when they discuss MAC addresses) Which types of 
> > LSPs can be Sections (e.g., can a P2P unidirectional LSP be 
> a Section? 
> > Can an associated bi-directional LSP be a section? etc.).
> > If associated bi-directional LSPs can be Sections, can we treat the 
> > Status of this topic in the -00 draft: requires clarification, one 
> > aspect already recognized as such by the Editors. IMHO and FWIW 
> > preferred resolution would be to equate Sections with data 
> links Label 
> > Allocation Schemes:
> > MPLS recognizes two label allocation schemes, each with its 
> own area 
> > of
> > applicability: 
> > Downstream label allocation as per RFC 3031 Upstream label 
> allocation 
> > as per RFC 5331 IMHO the label allocation scheme is 
> essentially a data 
> > plane issue:
> > This includes applicability of these schemes, e.g., can we use 
> > upstream label allocation This issue is closely related to proposed 
> > usage of a well-known multicast MAC destination address for 
> P2P LSPs) 
> > Status of this topic in the -00 draft: requires clarification MAC 
> > addresses on Ethernet data links in MPLS-TP:
> > The draft discusses this topic, and proposes using a well-known 
> IMHO and FWIW 
> > if LAN interfaces are allowed in MPLS-TP, usage of  well-known 
> > Status of this topic in the -00-draft: partially recognized by the 
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 8 Feb 2010 14:38:32 +0200

Maarten,
Lots of thanks for a good example.

I assume that you speak about Ethernet "VP" and "VC" you mean PBB (a.k.a. MAC-in-MAC or802.1ah).
If this is correct, then your example illustrates the difference between the Ethernet
and MPLS data planes. MAC addresses are absolute, and outer MAC address can provide context
for the inner one - by design.

MPLS data plane has been designed differently. Whether one should or should not expect
certain limitations, they exist.

The difference between an architectural limitation and limitation imposed by the (majority of) existing
implementations is, of course, important. And things can go any each way:
- some things are architecturally possible but not, typically, not used. E.g., AFAIK, this is the case with L-LSPs
  which are perfectly OK from the architecture point of view but rarely used due to scalability problems.
- some others are architecturally disallowed but may be supported by certain implementations.

We should clearly understand where we stand on each such issue.

Regards,
     Sasha

> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Monday, February 08, 2010 2:11 PM
> To: Alexander Vainshtein
> I carry a p2mp
> connection over
> I am wondering
> the next label it
> labels in the
> for multiple
> > control plane issue.
> > draft-fbb-mpls-tp-data-plane-00 -> Label
> > plane issue. How
> > own area of
> > definition of the
> > direction, and I
> > undecided in this
> > own area of

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 09 Feb 2010 07:50:38 +0100

Sasha,

See inline.. 

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: maandag 8 februari 2010 13:39
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; 'LEVRAU, LIEVEN (LIEVEN)'
Subject: RE: [mpls] [mpls-tp] Label alloc. Schemes in data-plane-draft'

Maarten,

I assume that you speak about Ethernet "VP" and "VC" you mean PBB (a.k.a.
MAC-in-MAC or802.1ah).
If this is correct, then your example illustrates the difference between the
Ethernet and MPLS data planes. MAC addresses are absolute, and outer MAC
address can provide context for the inner one - by design.

[maarten] I am not speaking of PBB. I am referring to deployment of stacked
Ethernet VLANs in operator networks today. Operators require from their
vendors that the equipment can insert up to 2 or 3 VLAN Tags onto every
incoming VLAN signal. Some operators give those additional VLAN Tags the
81-00 EtherType value, some give it the 88-a8 EtherType value, some give it
proprietary values (e.g. 91-00, 91-01, 91-02). Operators can do this because
in their networks they use NMS and/or GMPLS to set up their internal VLAN
connections (Ethernet VC connections, Ethernet VP connections, Ethernet VS
connections). Because of this, there is no use of the 802.1Q control plane
protocols that prevented the unrestricted stacking of VLANs, and stacking is
no longer a problem in Ethernet networks. Furthermore, those operators run
those stacked VLANs within their own networks; i.e. on their Intra Domain
Interfaces (IaDIs), and on those interfaces operators have full control of
the frame formats. Vendors are more then happy to support the opertor
controlled configuration of the TPID fields in their VLAN Tag headers to
enable this stacked VLAN approach.

[maarten] This stacked VLAN based Ethernet data plane is as such very
similar to the MPLS data plane... Ethernet uses stacked VLAN Tag headers,
MPLS uses stack label stack entry headers...

MPLS data plane has been designed differently. Whether one should or should
not expect certain limitations, they exist.

The difference between an architectural limitation and limitation imposed by
the (majority of) existing implementations is, of course, important. And
things can go any each way:
- some things are architecturally possible but not, typically, not used.
E.g., AFAIK, this is the case with L-LSPs
  which are perfectly OK from the architecture point of view but rarely used
due to scalability problems.
- some others are architecturally disallowed but may be supported by certain
implementations.

[maarten] to me it seems that the limitation desribed by you of the MPLS
data plane is not a fundamental limitation, as it is not present in the OTN
and Ethernet cases. So important in my opinion to understand is if this
limitation can be removed from the MPLS data plane.

Regards,
Maarten

Regards,
     Sasha

> E.g. in OTN I can set up a p2p HO ODU3 connection over which I carry a 
> p2mp LO ODU2 connection, which carries up to 8 p2mp ODU0 signals with 
> e.g. 1GE clients.
>
> And in an Ethernet network I can set up a p2p Ethernet VP connection 
> over which I carry a p2mp Ethernet VC connection, which carries a 
> number of p2mp Ethernet VLANs.
>
> The fact that both OTN and Ethernet can support the example, I am 
> wondering if it is the MPLS data plane architecture that is not 
> capable, or if it are the existing MPLS equipment that are not 
> capable?
>
> Regards,
> Maarten
>
> The LSR that terminates the outer P2P LSP cannot know that the next 
> label it looks-up is upstream-allocated (and hence to be looked-up in 
> a different
> context):
> I.e., when they received a labeled packet with two or more labels in 
> the stack and wanted to look at the 2nd label, they physically popped 
> the top label and forwarded the packet to a dedicated looped-back 
> physical interface. The packet received from that interface would have 
> the former 2nd label as the top one, and would then process it as any 
> other top label.
> Modern LSRs do not usually use a physical loopback interface for 
> multiple label lookups, but neither do they prevent their downstream 
> peers from using it as long as the downstream label allocation scheme 
> is used.
>
> > upstream-allocated labels use a different code point on Ethernet 
> > links and GRE tunnels.
> > In my view - This is a control plane issue and not a data plane 
> > issue. How the labels are assigned is outside the scope of the 
> > draft.
> >
> > ./
> > Lieven
> > allocation as per RFC 5331 IMHO the label allocation scheme is 
> > essentially a data plane issue:
> > usage of a well-known multicast MAC destination address for P2P 
> > LSPs) Status of this topic in the -00 draft: requires clarification
> >
> >

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 09 Feb 2010 07:58:48 +0100

Neil,

The internet drafts and RFCs assocaited with MPLS-TP are describing a tool
set. Elements of this tool set can be used to construct a true packet
transport network. It seems that such construction is outside the scope of
IETF 9see the reactions to my proposals to add construction descriptions to
the MPLS-TP framework). This implies that each operator is obliged to define
its own packet transport network construct using the appropriate elements of
the mpls-tp toolset and combine those with elements from other technologies,
e.g. Ethernet and OTN.

My recommendation to you is to define with your colleagues a BT packet
transport network construct. 
My recommendation would be to use an Ethernet VC based transport service
layer that supports all customer services and combine this with MPLS-TP VP,
Ethernet VP and OTN VP based transport path layers. Manage it by means of
NMS and GMPLS and you have an **excellent** packet transport network.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 8 februari 2010 13:23
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [mpls] Label alloc. Schemes in data-plane-draft'

Maarten,

As I remarked in my last mail to Sasha, I am not sure MPLS-TP will be
delivering a transport network solution.  It *could* do this (as CCAMPs
folks have proved with GMPLS) but here it is a conscious choice not to do
this....and the decisions that are being taken cannot appeal to technical
naivety IMO.  The difficulty I can see is that MPLS-TP is trying to be seen
as a transport network whilst still retaining certain behaviours from MPLS
that are not behaviours of a transport network.

regards, Neil

---

From: <[email-masked]>
Date: Tue, 9 Feb 2010 09:08:22 -0000

A couple of observations Sasha/Maarten:

1	You are now getting round to discussing the detail that
underpins why I believe that the carrying-over of the *arbitrary*
sublayering of MPLS into a MPLS-TP transport network is not a sensible
thing to do.  However, this (S bit sublayering) is such an ingrained
behaviour of MPLS that it seems too hard for many to let go of it. The
TTL function is a similar issue.  And so is the PW's CW 1st nibble ECMP
hack (see 2 also below) and its 16 bit Seq No.s......and of course there
is the rather larger, and actually far more important, observation that
PWs themselves are not required.  All we do here is generate a new form
of 'MPLS-TP' that:
(i) uses a different signalling protocol (which is an unnecessary
duplication of function),
(ii) promotes a bizarre form of access point addressing of a PW layer
network, ie the AII stuff....which IMO is the real reason for the
different signalling protocol, and
(ii) inserts an essentially redundant 4 octet CW in the DP.

All these things are quite unnecessary if MPLS-TP was designed correctly
as a transport network.  But it is now quite clear that this is not
going to be the case.  

2	If a fundamental architectural behaviour of MPLS is that one
forwards only on the outer label and looks no deeper, then can someone
explain to me how ECMP sits with this statement?    

regards, Neil

> Sent: 09 February 2010 06:51
> connection 
> > The construction you present violates the MPLS data plane 
> architecture 
> > as defined in 3031.
> >
> > - the data link does not indicate that (otherwise the top 
> label would 
> > be
> > upstream-allocated)
> labels in 
> > Of course, the top label and the original ingress interface 
> would be 
> > lost in this operation.
> [mailto:[email-masked]]
> > > MPLS recognizes two label allocation schemes, each with 
> its own area 
> > > of
> > > applicability: