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

[Dan Frost <[e-mail]>]

Hi Sasha,

Alexander Vainshtein <[e-mail]> writes:
> 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.

Thanks for your review!

> 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.

See earlier response to David on this point.

> 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.

Currently the text about the Uniform model in this document reads:
"Support for the Uniform model is NOT REQUIRED."  The current MPLS-TP
Framework draft has dropped the statement about PSTs and the Uniform
model.

> 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

We agree that this is really an OAM/control consideration rather than a
data plane one, and will move the statements about pairing awareness to
the MPLS-TP Framework.

> 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?

Yes.

> 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).

It is our understanding that the original use of the term "interface" in
RFC 3031 did not refer to an LSP.  The MPLS-TP data plane "is" the MPLS
data plane, and we're not aware of any use of per-LSP label spaces in
MPLS.  Therefore the concept of "per-Section label space" in the case of
Sections that are LSPs does not appear to be part of the current MPLS
architecture.  If a future need arises to define and use them in MPLS,
their use is not precluded in MPLS-TP.

> 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.

We have added the following text to the G-ACh section:

   An application processing a packet received over the G-ACh may require
   packet-specific context (such as the receiving interface or received
   label stack).  Data plane implementations MUST therefore provide
   adequate context to the application which is to process a G-ACh packet.
   The definition of the context required MUST be provided as part of the
   specification of the application.

> 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.

There has been a lot of discussion about "LSP merge" in the context of
MPLS-TP.  This is not a concept that appears in RFC 5654.  Our
understanding is that the relevant requirement concerns the types of LSPs
that may be created in an MPLS-TP network, and this document specifies
what those are.  We do not see the need to add further text enumerating
the things that the MPLS-TP data plane does not do.

> 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.

OK

> 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".

We have added the following text:

  An important difference exists between data-link-based sections and
  LSP-based sections.  A data-link-based section can carry additional
  packet context information such as a protocol type indication.  If an
  LSP-based section requires such context, then a service label (see
  [I-D.ietf-mpls-tp-framework]) must be used to provide it.


> 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)

We have done our best to do this in the current versions of the respective
drafts.

- Dan, Stewart and Matthew

> My 2c,
>      Sasha