Re: [mpls-tp] [PWE3] MPLS working group last call on draft-ietf-mpls-tp-data-plane-01.txt

[Alexander Vainshtein <[e-mail]>]

Loa and all,
Here are my LC comments on draft-ietf-mpls-tp-data-plane-01.txt.

First of all, I'd like to note that most of the comments on draft-fbb-mpls-tp-data-plane-00 I've sent on 01-Feb-10 have been addressed in draft-ietf-mpls-tp-data-plane-01 in some way. 

There are several issues, both technical and editorial, that IMHO still should be taken care of.

Technical Issues
================

1. I concur with Dave Allan, the draft should not just reference RFC 3031, but explicitly map MPLS-TP data plane to its architectural elements: FTN, ILM and NHLFE. 

2. In Section, the draft states that
<quote>
   The Uniform model is outside the scope of the MPLS-TP.
<end quote>

However, it has been already mentioned on this list that Path Segment Tunnels (PST) MUST use the Uniform model.
This contradiction must be, IMHO resolved, one way or another, i.e., either by dropping the PST construct from MPLS-TP, or by explicitly allowing Uniform model at lease for PST.

3. In Section 3.1.3 the draft requires awareness of the reverse direction of a bi-directional LSP in appropriate nodes. To the best of my understanding, such awareness is not part of the MPLS-TP data plane since it does not affect encapsulation and forwarding of packets in any way, it is only required for OAM purposes. If this understanding is correct, IMHO it deserves an explicit clarification, e.g., providing an unambiguous answer to the following question:
	Can co-routed bi-directional LSPs use labels from per-platform label space?

4. In Section 3.2 the draft defines two types of Sections: data links (no labels required) and MPLS-TP LSPs.
This definition still leaves open one of my early questions:
	Does MPLS-TP allow per-Section label spaces for Sections that are not data links?
(The text in Section 3.1.1 mentions per-platform, per-interface and other - as per RFC 5331 - label spaces and hence is inconclusive). 

5. Treatment of GAL if/when it is exposed by popping another label seems to require some clarification.
In line with the description of processing LSP Ping Echo requests (see RFC 4379, Section 4.4, item 2) Section 4 should explicitly state that the LSR that exposed GAL in an incoming packet by popping some labels (in accordance with their disposition in the ILM) should note ingress interface and the entire (popped) label stack and pass this information complete with the contents of the packet to the appropriate processing entity. This clarification should be also considered as an update of RFC 5586.

6. LSP merge seems to be left out of scope of the updated draft. If this means that at the data plane level MPLS-TP does not do anything to prevent LSP merge, it is OK with me, may it should be stated explicitly.

Editorial issues
================

1. In Section 3.1.1 the text says that
<quote>
   Encapsulation and forwarding of packets traversing MPLS-TP LSPs MUST
   follow standard MPLS packet encapsulation and forwarding as defined
   in [RFC3031] and [RFC3032], except as explicitly stated otherwise in
   this document.
<end quote>

At the same time, the draft mentions encapsulations defined in RFC 5332 and "other context spaces" defined in RFC 5331. So maybe it is worth including the references to both in Section 3.1.1.


2. IMHO it would be useful to clarify the difference between data link-based Sections and LSP-based ones:
- the former can be used to carry all kind of traffic using protocol numbers statically allocated by an appropriate registration authority
- the latter are restricted to carrying MPLS-TP and PW packets and require allocation/distribution of the "service labels".

3. Last but not least, IMHO it makes sense to merge all the data plane-related sections from the MPLS-TP Framework draft into this one. The candidate sections include:
	- 3.3.2 "MPLS-TP Forwarding Functions" (including restriction of PW labels to per-platform space only) that has 		   been omitted in this draft
	- 3.6 "Generic Associated Channel" (strongly overlaps with its namesake section in this draft)

My 2c,
     Sasha

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Loa Andersson
Sent: Saturday, March 13, 2010 4:16 AM
To: MPLS-TP ad hoc team; [e-mail]; [e-mail]; [e-mail]; CCAMP
Subject: [PWE3] MPLS working group last call on draft-ietf-mpls-tp-data-plane-01.txt

All,

this is to start an MPLS working group last call on

http://pi.nu/~loa/draft-ietf-mpls-tp-data-plane-01.txt

As you can see it is not yet available on the IETF home page (we
missed the cut-off date with a few days), we try to place it in
the IETF repository as quickly as possible.

In the mean time it is available from the web page above.

Please send your comments to the [e-mail] mailing
list.

The working group last call ends on April 2nd.

/Loa
-- 


Loa Andersson                         email: [e-mail]
Sr Strategy and Standards Manager            [e-mail]
Ericsson Inc                          phone: [phone]
                                              [phone]
_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3