[mpls] Comments on draft-jags-mpls-mna-hdr-02

[Stewart Bryant <[e-mail]>]

Dear Authors

An interesting and well written draft that seems to capture what we need above the BoS in the MNA work.

I think that we should be adopting this and bringing it into the MPLS WG process.

I have a few questions and comments which I note below.

Best regards

Stewart

==========

1) How is Entropy handled. Do you see it as keeping the ELI/EL mechanism, or being included via an MNA Action. I can see a case for both, but the text should certainly talk about this.
2) Rather than requiring the user to parse the PSD to find out what to execute we should consider an opcode of the form = Execute PSD at offset X This would allow us to specify what PSD functions get executed at each hop in the same way that we specify ISD/Flag related functions.


Abbreviations

3) I have not checked by this section should not copy across from the other referenced documents as there is scope for conflicting definitions. The terms could usefully include references to definitions.

4)  NASS Scope:

   This indicates the scope (HBH / Select / I2E) of NASS for different
   nodes (e.g., midpoint nodes and egress node) where it needs to be
   processed.
SB> I don’t see a definition of “Select" scope.

5)   NASL (Network Action Sub-Stack Length):

   This is a 4-bit field in the TTL.  This indicates the total length of
   the current NASS.  This value does not include the first two LSEs in
   the NASS.  This value is used by the ASICs to process the NASS.

SB> I am not sure that this is specific to ASICs


6)

    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Label                    | TC  |S|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      NASI=bSPL (TBA1)                 | TC  |S|    TTL        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | NAI-Opcode    |    Ancillary Data     |R|NAL|S|P,H|IHS|  NASL |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | NAI-Opcode    |    Ancillary Data     |R|NAL|S| Ancillary Data|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 2: MPLS Label Stack Entry (LSE) Format

SB> I comment on this again later, but I think there is a problem if the first NAI-Opcode needs flags. I think the way to address this is to have a NULL Opcode that gets skipped. Which then carries P,H|IHS|  NASL
7)
   *  Apart from the Label field, part of AD is also carried in the
      8-bit TTL field except for the 2nd LSE in the NASS.  If an
      application needs only 12-bit of AD, then 2nd LSE can be used for
      NAI-Opcode otherwise it can use the next LSE for 20-bit of AD.
SB> Presumably otherwise the Opcode is NULL
8)

   NOTE: ECMP Hash Using Label Stack:

      A midpoint node may use the entire MPLS Label Stack for ECMP hash
      computation hence the In-Stack MPLS extension header MUST NOT
      change the Label Field part of the Ancillary Data within the same
      traffic flow.  But the TTL part of In-Stack Ancillary Data can
      change for the same traffic flow without affecting the ECMP hash.
      The In-Stack Network Action encoding defined above ensures this.
SB> I think that we need to have a longer discussion about entropy as in the long run it makes sense to include it in the NAI system.

9)

   NAI-Opcode value of 0 is marked as invalid to avoid the label value
   from aliasing with the reserved bSPLs.

SB> It is marked reserved in IANA. I think it needs to be marked as not to be used.
SB> Reserved implies available for extensions, and could be “borrowed” whilst what we need to say is the using it breaks MPLS.


10)

5.  Post-Stack MPLS Network Action Encoding

   Based on the P and H flags, the Post-Stack Network Actions are
   processed.  The details of the Post-Stack Network Action Extension
   Header encoding is specified in [I-D.song-mpls-extension-header].
SB> I am OK with this if the ISD incudes information on what is in the PSD and is applicable to the node processing TOS. However if we not so this then I think we need to look at the PSD design in draft song with a view to starting it with a manifest.

11) 6.2.  Post-Stack NA Processing Order

   Post-Stack NAs follow ordering specified in
   [I-D.song-mpls-extension-header].
SB> We could address that by pointing to the components in the draft-song structure

12) 7.  Handling of Unsupported Network Actions

   When a node encounters an unsupported NAI-Opcode in the NASS it is
   processing, the node skips processing that NAI-Opcode using the NAL
   field and moves to processing the next NAI-Opcode.
SB> Should we specify skip or stop as a sub-action?
13) 8.  MNA for Segment Routing Label Stack

   For packets with Segment Routing [RFC8662] MPLS label stack, a copy
   of NASS with HBH and Select scope is placed at regular depth
   throughout the MPLS label stack, with the understanding that the
   current copy of the NASS will eventually rise to the top of the label
   stack.
SB> Presumably to be popped? We need to specify this, but also make as statement about any ISD collected along the path and what is t happen to it.
SB> I think that there needs to be text about the sub stacks if labels are pushed.
14) For HBH scope, every node processes the current copy of the NASS and
   the node that pops the forwarding label that exposes the NASS will
   not remove it but forward it to the next node (i.e., segment endpoint
   node).  
SB> This is not clear - are you talking about the SWAP case, or the PHP case or if something else how does the packet get forwarded?
15) The segment endpoint node that receives the NASS at the top
   of the label stack has to remove it.

   For I2E scope, only one copy of NASS needs to be added and it is
SB> 12E or E2E?
16)10.  Security Considerations

   The security considerations in [RFC3032] also apply to the procedures
   defined in this document.  The NASI Label (bSPL TBA1) MUST NOT be
   exposed on the node which does not support it.
SB> It is clearly more involved than that. The action set is more easily used to corrupt the forwarding behaviour and also the AD is easier to corrupt and may be more sensitive than an MPLS label.


17) 13.  IANA Considerations

   Below are the IANA actions which this document is requesting.

   The registries created by this document will be collected in a new
   registry grouping called "MPLS Network Action," which will be located
   at https://www.iana.org/assignments/mpls-network-action.
SB> Surely they should be within the Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters Namespace
SB> It makes no sense to put them in a completely new namespace
18)
          +=======+=============================+===============+
          | Value | Description                 | Reference     |
          +=======+=============================+===============+
          | 0     | Reserved                    | This document |
          +-------+-----------------------------+---------------+
          | 1     | Offset of start of Post-    | This document |
          |       | Stack Network Action Header |               |
          +-------+-----------------------------+---------------+
          | 2     | Flag-Based Network Action   | This document |
          |       | Indicators with No AD       |               |
          +-------+-----------------------------+---------------+
          | 3     | Flag-Based Network Action   | This document |
          |       | Indicators with AD          |               |
          +-------+-----------------------------+---------------+
          | 4     | Post-Stack Network Action   | This document |
          |       | Indicator                   |               |
          +-------+-----------------------------+---------------+
          | 255   | Opcode Range Extension      | This document |
          |       | Beyond 255                  |               |
          +-------+-----------------------------+---------------+

               Table 6: I2E In-Stack Network Action Indicator
                               Opcode Values
SB> I think it should be indicated that using zero will break the protocol so “not to be used” would be better than Reserved.

19) SB> I think you need to declare a NULL opcode incase first Opcode needs ISD
20) SB> I suspect that we are also going to need an entropy Opcode
21)
   IANA is requested to create a new registry with name "HBH and Select
   In-Stack MPLS Network Action Indicator Opcodes" to assign IS-NAI-
   Opcode values.  This registry is also used for Select scope.  
SB> What is select scope?
   All
   code-points in the range 1 through 175 in this registry shall be
   allocated according to the "IETF Review" procedure as specified in
   [RFC8126].  
22)
SB> The table should call out 0 as a special case below.
   Code points in the range 176 through 239 in this registry
   shall be allocated according to the "First Come First Served"
   procedure as specified in [RFC8126].  Remaining code-points are
   allocated according to Table 5:

          +===========+=========================+===============+
          | Value     |       Description       | Reference     |
          +===========+=========================+===============+
          | 0 - 175   |       IETF Review       | This document |
          +-----------+-------------------------+---------------+
          | 176 - 239 | First Come First Served | This document |
          +-----------+-------------------------+---------------+
          | 240 - 251 |     Experimental Use    | This document |
          +-----------+-------------------------+---------------+
          | 252 - 254 |       Private Use       | This document |
          +-----------+-------------------------+---------------+

               Table 7: HBH and Select In-Stack MPLS Network
                     Action Indicator Opcodes Registry

23)

          +=======+=============================+===============+
          | Value | Description                 | Reference     |
          +=======+=============================+===============+
          | 0     | Reserved                    | This document |
          +-------+-----------------------------+---------------+
          | 1     | Offset of start of Post-    | This document |
          |       | Stack Network Action Header |               |
          +-------+-----------------------------+---------------+
          | 2     | Flag-Based Network Action   | This document |
          |       | Indicators with No AD       |               |
          +-------+-----------------------------+---------------+
          | 3     | Flag-Based Network Action   | This document |
          |       | Indicators with AD          |               |
          +-------+-----------------------------+---------------+
          | 4     | Post-Stack Network Action   | This document |
          |       | Indicator                   |               |
          +-------+-----------------------------+---------------+
          | 255   | Opcode Range Extension      | This document |
          |       | Beyond 255                  |               |
          +-------+-----------------------------+---------------+

              Table 8: HBH and Select In-Stack Network Action
                          Indicator Opcode Values
SB> Same comment regarding value 0
=============