Notes on draft-jags-mpls-mna-hdr-04

Dear All,
firstly, many thanks to the draft authors for their dedication and hard
work on this document. I've read the latest version, and below you can find
my notes (and nits):

   - the scope of the draft is characterized in the Abstract as the
   "solution for carrying Network Actions and Ancillary Data in the label
   stack" and as "This document defines the syntax and semantics of network
   actions encoded within an MPLS Label Stack" in the Introduction. That may
   be viewed as excluding handling of a post-stack placing of MNA and AD. In
   particular, how is a PSD-based MNA disposed of (more use cases below)?
   - s/OAM logging/OAM action/?
   - User-defined actions are mentioned twice in the document. Considering
   the extent of the document, a new document documenting user-defined
   actions, their scope, etc., would be a reasonable format. What do you think?
   - Would NASes be a better plural form of NAS?
   - What is the purpose of the Overview section? Could it be merged with
   the Introduction?
   - What could be the practical outcome of this case:

   If the node performing this copy is not

   aware of MNA, this could overwrite the values in the first LSE of the

   MNA sub-stack.


   - As indicated in Section 6.3, Format D may be used to list MAIs without
   ancillary data. If that is the case, then the title of Section 4.4 LSE
   Format D: Additional Ancillary Data seems to not reflect that use case.
   Perhaps removing "ancillary" be acceptable?
   - What could be the reason for the modification of the AD by a transient
   node, as suggested in the second paragraph of Section 5.2? Which use cases
   listed in draft-ietf-mpls-mna-usecases
   <https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-usecases/> (minus
   APN, as the group agreed) requires AD modification by a transient node?
   - Perhaps s/multiple NASs may be/multiple NASs MAY be/?
   - It is not clear what is the scope of the "last copy" in the following
   requirement:

penultimate node MUST NOT remove the last copy of a HBH NAS

Could it be that the "penultimate node MUST NOT remove NAS that includes
MNA of HBH scope"?


   - Could it be that the following requirement restricts how MNAs are
   processed at the egress node:

   An I2E scope NAS MUST be encoded after any HBH or Select scope NASs.

I imagine that some I2E NAS has to be processed by the egress before the
particular HBH NAS. It looks like the requirement prohibits that.


   - The following text defines the interpretation of O-bit being set:

   If the 'O' bit is set in a Format B LSE (Section 4.2) then it
   indicates that the network actions encoded in the NAS MUST be
   processed in the order that they appear in the NAS, from the top of
   the NAS to the bottom.

Is there a particular interpretation of the case when the O bit is cleared?
If there is no particular order of processing NASes, perhaps there is no
practical need for the O bit, and the processing rule can be defined as the
general requirement?


   - It seems like Opcode == 1 is intended, at least partially, to handle
   PSD MNA for non-IP payload, i.e., PW. I am not sure that encoding PSD as
   part of the PW payload is the best option.
   - A couple of questions on Flag based NAIs with AD (Opcode == 3):
      - Can the same Format C's LSE combine NAI and associated AD?
      - Can the same Format D's LSE be used to list additional NAIs as well
      as associated AD?
      - Consider that Format D's LSEs are used to encode ancillary data for
      a number of NAIs. Can a node that supports only some of these NAIs find
      ancillary data for NAIs it does support if there's no uniform format for
      the ISD-based AD?
   - Could MNA be used in an LDP-based IP/MPLS network, as it is excluded
   from mentioning in the text?
   - What constitutes the "entire NAS" that is mentioned in Section 7? AS I
   understand it, NAS is defined as a sequence of LSE following a new bSPL:

   In stack actions and ancillary data are contained in a
   Network Action Sub-Stack (NAS), which is recognized by a new base
   Special Purpose Label (bSPL) (value TBA).

Furthermore, multiple NASes may be used to signal specific ordering of
NAIs. If that is the case, then what is the  "entire NAS"?


   - Some questions about the Select scope of NAS.
      - What are the restrictions of using the Select scope in NAS? For
      example. is the Select scope associated with only ISD or PSD or
both types
      may be used in the same NAS?
      - Furthermore, if HBH and Select scopes are used in subsequent NASes,
      then is there a recommended order similar to the requirement in
Section 5.3
      for I2E?
   - In Section 9.1 seems like s/each LSP/each LSE/ is needed.
   - Is the following requirement equally apply to the ISD- and PSD-located
   ancillary data:

   A transit node MAY change the Ancillary Data found in the least
   significant 8 bits of an LSE.


   - In Section 10, it seems like "must" and "should" need to be
   capitalized.
   - It seems like captions for Table 4 and Table 5 need to be swapped.
   Also, if the initial allocation in the "Network Action Flags Without
   Ancillary Data" registry is 0-469, it seems logical to do the same for the
   "Network Action Flags With Ancillary Data" regstry.

And here are some questions about use cases. Pleased let me know if any of
them is real or I'm way off:

   - As I understand it, MNA can be used in SR-MPLS. In that case, multiple
   NASes may be present in the label stack. Since I couldn't find any
   restrictions for use of multiple NASes, these might be different, i.e.,
   include different NAI and/or different ADs. Is that right?
   - Also, for the SR-MPLS case that uses PSD. Would there be a single PSD
   or a copy for every ISD NAS?
   - If there's a single PSD for all NASes in the stack, which node must
   remove the PSD?
   - If there the PSD is per NAS then the node that disposes of NAS must
   remove corresponding PSD. Right? But that might affect the offset from BoS
   for remaining PSD.

Thank you for your kind consideration of my notes and questions. Looking
forward for our discussion.

Happy New Year and Best Wishes to All!

Regards,
Greg

_______________________________________________
Pals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pals