Re: [CCAMP] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document

[Alexander Vainshtein <[e-mail]>]

Loa,
I think that such a draft is absolutely required.
At the same time I think the -00 revision is somewhat problematic.
In particular, the proposal to use a well-known multicast MAC address for encapsulation of MPLS-TP
packets over Ethernet *simply will not work* together with the combination of:
(a) LAN interfaces between MPLS-TP routers (quite a common case for Ethernet) and 
(b) Downstream label assignment (which presumably is going to be used for P2P LSPs in MPLS-TP).

I've already sent my comments on this (and some other points) to the authors and the mailing lists (attached).

IMHO at least the problem of Ethernet encapsulation should be acknowledged (and resolved?) before the draft is accepted as a WG document.

Regards,
	Sasha



> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Loa Andersson
> Sent: Tuesday, February 09, 2010 6:06 PM
> To: [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]; Adrian Farrel
> Subject: [mpls-tp] poll on making 
> draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document
> 
> All,
> 
> This is to start two week poll on making
> draft-fbb-mpls-tp-data-plane-00.txt
> an mpls working group document.
> 
> Send a mail to the [e-mail] mailing list,
> indicating "yes/support" or "no/do not support".
> 
> Note that this ID is a starting point for what needs to
> be documented on the MPLS data plane for the MPLS-TP
> project. The ID is largely based on the data plane specific
> text from the framework, together with some notes concerning
> how the Transport Profile of MPLS might operate over Ethernet.
> 
> 
> /Loa
> 
> 
> -- 
> 
> 
> Loa Andersson                         email: 
> [e-mail]
> Sr Strategy and Standards Manager            [e-mail]
> Ericsson Inc                          phone: [phone]
>                                               [phone]
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 

--- Begin Message ---

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

    *

--- End Message ---