Subject: [mpls-tp] LC comments on sections 3.4.2 and 3.4.3 of draft-ietf-mpls-tp-framework-10

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 18 Feb 2010 14:23:26 +0200

Hi all,
I have a couple of LC comments/questions on Sections 3.4.2 and 3.4.3 of the draft.

Figure 8 in Section 3.4.2 describes format of several types of MPLS-TP packets:

<quote>
+-------------------+     /===================\   /===================\
 |  Client Layer     |     H     OAM PDU       H   H     OAM PDU       H
 /===================\     H-------------------H   H-------------------H
 H     PW Encap      H     H      GACh         H   H      GACh         H
 H-------------------H     H-------------------H   H-------------------H
 H   PW Demux (S=1)  H     H PW Demux (S=1)    H   H    GAL (S=1)      H
 H-------------------H     H-------------------H   H-------------------H
 H     LSP Demux(s)  H     H  LSP Demux(s)     H   H  LSP Demux(s)     H
 \===================/     \===================/   \===================/
 |    Server Layer   |     |   Server Layer    |   |   Server Layer    |
 +-------------------+     +-------------------+   +-------------------+

     User Traffic                 PW OAM                  LSP OAM
<end quote>

I assume that in this diagram the "LSP demux" label is terminated by the box that 
looks at PW demux and/or GAL, i.e., its corresponding entry in the ILM is valid and
contains the following NHLFE:
- Next Hop: this box (i.e., its loopback interface)
- Label stack action: Pop.

This works just fine with the user traffic and PW OAM packets, because differentiation
Between user traffic and OAM packets is not based on any labels.

However, the LSP OAM packet will be recognized as such only by looking at GAL after 
the LSP demux label has been popped.

RFC 3031 states in Section 3.9:
<quote>
   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.
<quote>

It is not clear to me how can an RFC 3031-compliant LSR refer an
LSP OAM packet to a specific LSP without violating this rule.
One way to assure it would be by encoding the LSP identifier in the
body of each OAM packet; if, as I suspect, this is the only way,
it should be explicitly mentioned both in this draft and in the
MPLS-TP OAM framework.

Similar problem exists with proposed usage of Service LSP demux
labels that are introduced in Section 3.4.3 for carrying IP and
its "helper" non-IP protocols (e.g., IS-IS) over MPLS-TP LSPs,
see Figure 10:
<quote>

                           /===================\
                           H     OAM PDU       H
 +-------------------+     H-------------------H   /===================\
 |  Client Layer     |     H      GACh         H   H     OAM PDU       H
 /===================\     H-------------------H   H-------------------H
 H    Encap Label    H     H      GAL (S=1)    H   H      GACh         H
 H-------------------H     H-------------------H   H-------------------H
 H   SvcLSP Demux    H     H SvcLSP Demux (S=0)H   H    GAL (S=1)      H
 H-------------------H     H-------------------H   H-------------------H
 H     LSP Demux(s)  H     H  LSP Demux(s)     H   H  LSP Demux(s)     H
 \===================/     \===================/   \===================/
 |   Server Layer    |     |   Server Layer    |   |   Server Layer    |
 +-------------------+     +-------------------+   +-------------------+

     User Traffic            Service LSP OAM               LSP OAM
<end quote>

This situation is worse, IMHO, because the box that terminates the LSP demux
Label should be able to treat it as a "context label" that defines a common context for IP
and its helper protocols distinguished by their appropriate service LSP demux labels...
The method proposed for OAM packets will not help here. One possibility to resolve this
problem would be by assigning a set of Service Demux labels in a way that preserves
their common context regardless of being received in the same LSP (i.e., place it
beyond MPLS-TP proper)...

One generic way out of the problems could be by using only upstream-allocated
labels in MPLS-TP. Upstream-allocated labels are not subject to restrictions defined in RFC 3031,
and RFC 5331 explicitly introduces "context labels" with upstream allocation
(at least, in certain specific situations). However, the scale on which context labels 
would be used in MPLS-TP goes far beyond what has been envisioned in RFC 5331. 
It is not clear to me how well this approach scales up.

Hopefully, these notes will be useful.

Regards,
     Sasha