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

[Alexander Vainshtein <[e-mail]>]

Dan, Stewart, Matthew and all,
Lots of thanks for a detailed response to my comments.
Most of them seem to be addressed fully.

However, I would highly appreciate your clarification on the 
relationship between the PST and the UNIFORM model.

The text in Section 3.2 of draft-ietf-mpls-tp-oam-framework says:

<quote>
   1) The PST would use the uniform model of TC code point copying 
      between sub-layers for diffserv such that the E2E markings and 
      PHB treatment for the transport path was preserved by the PST. 

   2) The PST would use the pipe model for TTL handling such that MIP 
      addressing for the E2E entity would be not be impacted by the 
      presence of the PST.
<end quote>

The first statement looks correct

The 2nd statement looks incorrect to me, since pipe model for the PST means that E2E MIPs in the nodes within a PST will become non-addressable, and E2E MISs in the nodes after the PST termination will change their "addressing".

So stating that UNIFORM model is NOT REQUIRED in MPLS-TP sounds to me as "PST is NOT REQUIRED in MPLS-TP".
I am actually OK with this statement, but should it not be made explicitly? And how would it correlate with the requirement in Section 2.1.1. of the (approved for publication) draft-ietf-mpls-tp-oam-requirements-06:

<quote>
	The protocol solution(s) MUST be applicable end-to-end and to segments
<end quote

Regards,
     Sasha


-----Original Message-----
From: Dan Frost [mailto:[e-mail]] 
Sent: Tuesday, April 13, 2010 2:46 PM
To: Alexander Vainshtein
Cc: [e-mail]
Subject: Re: [PWE3] MPLS working group last call on draft-ietf-mpls-tp-data-plane-01.txt

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