Re: [mpls] Fwd: Notes on draft-jags-mpls-mna-hdr-04

[John E Drake <[e-mail]>]

Greg,

You had previously asked a question about opcode 3 (section 6.4) which you asked again in today's DT meeting, viz, for the LSEs which follow the opcode 3 LSE, how does a node distinguish between an LSE that contains additional network action flags and an LSE that contains AD?  As I indicated in today's DT meeting, in response to your initial asking of the question, we had decided to restrict the network action flags to only the opcode 3 LSE.  This means that any subsequent LSEs by definition contain only AD.  Unfortunately the text in section 6.4 is not completely clear on this.

Our thinking was that if we run out of room in the opcode 3, we can just define another opcode with the same semantics to contain the additional network action flags, and repeat this process as more network action  are defined.  This has two advantages, 1) it partitions the network action flags by opcode so that the ingress node only needs to specify the opcodes for the network actions in which it is interested and 2) it would allow us to define custom sets for the most commonly used network actions regardless of the time order in which they were defined.

Yours Irrespectively,

John



Juniper Business Use Only
From: mpls <[e-mail]> On Behalf Of Greg Mirsky
Sent: Thursday, January 5, 2023 10:21 AM
To: mpls <[e-mail]>
Subject: [mpls] Fwd: Notes on draft-jags-mpls-mna-hdr-04

[External Email. Be cautious of content]

Happy New Year to All, and apologies for missing sending my notes to the MPLS WG.

Regards,
Greg
---------- Forwarded message ---------
From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Sun, Jan 1, 2023 at 4:06 PM
Subject: Notes on draft-jags-mpls-mna-hdr-04
To: <[e-mail]<mailto:[e-mail]>>, MPLS Working Group <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, DetNet WG <[e-mail]<mailto:[e-mail]>>

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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-mpls-mna-usecases/__;!!NEt6yMaO-gk!A9Ca9huYFlCTpBVlsrcnvXtGzlbM81LKurzfP85mh-2ylWweGf6aUG9Vdjy_PhycJriZX6ZKZ71tVIoJxtb9$> (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