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

[Greg Mirsky <[e-mail]>]

Hi Tony,
thank you for your kind consideration of my notes and thoughtful proposed
updates. I've added several notes inline tagged by GIM>>.

Regards,
Greg

On Thu, Jan 5, 2023 at 12:25 PM Tony Li <[e-mail]> wrote:

>
> Hi Greg,
>
> I can’t speak for the authors, but I’m happy to propose text changes to
> them.  Let’s see if we can reach rough consensus on changes that would
> address your questions.
>
>
>    - 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)?
>
>
> How about we add this:
>
> A node that removes the last NAS that references post-stack
> data MUST also remove the post-stack data.
>
GIM>> It is clearer. Do you think that a small tweak will help a bit more:
Tony's text:
A node that removes the last NAS that references post-stack
data MUST also remove the post-stack data.
Greg's text:
A node that removes the last NAS that references post-stack
data MUST also remove that post-stack data.


>
>    - s/OAM logging/OAM action/?
>
>
> I think you’re referring to the text in the introduction. The intent here
> was to refer to the actual result of the OAM action, not the action itself.
>
GIM>> Although sometimes an OAM action triggers logging a message, that is
not always the case. Was it in reference to a specific 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?
>
>
> I don’t understand the concern. This document reserves code points for
> user-defined actions.  Beyond that, it’s completely up to the users to
> document such actions. It’s a completely blank slate and I’m not sure what
> more can be said. The whole point it to leave it as open as possible.
>
GIM>> As Loa suggested, having a new document is reasonable. I'd be happy
to note that the user-defined actions are outside the scope of this
document and are for further study.

>
>
>    - Would NASes be a better plural form of NAS?
>
>
> Yes, that would be more in keeping with normal English rules. Done.
>
>
>    - What is the purpose of the Overview section? Could it be merged with
>    the Introduction?
>
>
> The intent was to provide an overview of the solution and to start
> introducing normative text.  The introduction is meant to be only
> informative.
>
>
>    - 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.
>
>
>
> This text was motivational and explains why we did not re-use the TC and
> TTL fields in Format A LSEs.  It would have been nice to have used those
> fields for per-NAS values, but a legacy penultimate node would then corrupt
> the NAS, with the practical outcome of a trashed NAS and subsequent
> unintended behavior.
>
>
>    - 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?
>
>
> That seems reasonable. Done.
>
>
>    - 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?
>
>
> That is left to the definition of the associated action.
>
> One could, for example, have an action that counts the number of times the
> packet was placed in a non-empty transmission queue.
>
> One could also have an action that counts the number of routers on the
> path that are located in a country ending with the letter ‘X’.
>
>
>
>    - Perhaps s/multiple NASs may be/multiple NASs MAY be/?
>
>
> I think you’re referring to section 5.3.  Sure.
>
>
>    - 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"?
>
>
>
> As described in section 7, there may be multiple copies of a NAS in the
> label stack. The text here was to be very explicit and prevent the removal
> of the last copy of a HBH NAS.  Now, to be sure, the penultimate node
> should not receive multiple copies of a HBH NAS, but we were trying to be
> extremely clear.
>
> How about “… the penultimate node MUST NOT remove a HBH NAS”?
>
GIM>> That's clearer, thank you.

>
>
>    - 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.
>
>
>
> As I mentioned on the call, I2E scope is largely redundant with Select
> scope.  To implement I2E scope, a Select NAS can be added to the stack with
> the label that is popped by the ultimate node.  Yes, this may require
> adding an additional label to the stack.  Then, to implement the ordering
> that you suggest, the Select NAS should be placed ahead of the HBH NAS.
>
GIM>> Thank you for pointing out to me that I2E might be considered a
special case of the Select scope. As that is the case, is it practical not
to introduce the I2E scope at all?

>
>
>    - 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?
>
>
>
> Certain people are adamant that they not be restricted to in-order
> processing.  I will not defend their position, please take it up with them
> directly.
>
>
>    - 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.
>
>
> Opcode 1 is provided to give design flexibility to those working on PSD.
> It is not an intent to mandate or even suggest how that should be done.
>
>
>    - A couple of questions on Flag based NAIs with AD (Opcode == 3):
>       - Can the same Format C's LSE combine NAI and associated AD?
>
>
> No. Format C LSEs only carry NAI (when used with this opcode).  Text
> clarified.
>
GIM>> Thanks

>
>
>    - Can the same Format D's LSE be used to list additional NAIs as well
>       as associated AD?
>
>
> No, flags must appear in a format C LSE.  Text clarified.
>
GIM>> Thanks

>
>
>    - 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?
>
>
> That’s why we have this paragraph:
>
> If a flag contained within this opcode is unknown and is skipped per Section
> 5.4 <https://datatracker.ietf.org/doc/html/draft-jags-mpls-mna-hdr-04#UOH>,
> then the length of its associated ancillary data will also be unknown. Any
> subsequent flags within the opcode will not have the correct associated
> ancillary data, so all subsequent flags SHOULD be treated as unknown
> actions and also skipped.¶
> <https://datatracker.ietf.org/doc/html/draft-jags-mpls-mna-hdr-04#section-6.4-6>
>
>
> GIM>> Thanks for the clarification. I agree. It is a pragmatic approach.

> Once you hit a unsupported NAI, you should just skip to the next opcode or
> drop the packet, depending on the setting of the U bit.
>
>
>    - Could MNA be used in an LDP-based IP/MPLS network, as it is excluded
>    from mentioning in the text?
>
>
> Added a reference to LDP.
>
>
>    - 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:
>
>
> The definition of a NAS is found in the framework document:
>
>    An NAS
>    consists of a special label, optionally followed by LSEs that specify
>    which network actions are to be performed on the packet, and the in-
>    stack ancillary data for each indicated network action.
>
> So, in particular the NAS includes the LSE containing the 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"?
>
>
>
> First, it should NOT be necessary to use multiple NASes of the same scope
> to specify ordering.  The only case I can think of where you might want
> multiple NASes of the same scope that did not start off as copies is if you
> exceed the length limitations of a single NAS.
>
> In the context of section 7, the text is trying to point out that for the
> purposes of NAS placement, the encoding node should ensure that all of the
> LSEs in the NAS are within the processing node’s stack inspection depth,
> not just the first LSE. It would be problematic if the transit node could
> see only a subset of the NAS.
>
GIM>> Thank you for the clarification. Got it.

>
>
>    - 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?
>
>
> Select scope may be used with both ISD and PSD or just ISD.
>
>
>    - 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?
>
>
> We should specify that.  Text added.
>
> If a node is to process multiple NASes, it
> should process them in the order that they appear in the label
> stack.
>
>
>    - In Section 9.1 seems like s/each LSP/each LSE/ is needed.
>
>
> Fixed, thanks.
>
>
>    - 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.
>
>
>
> AFAIK, there are no LSE in PSD, by definition.  PSD is not part of the
> label stack.
>
>
>    - In Section 10, it seems like "must" and "should" need to be
>    capitalized.
>
>
> Agreed.  I also propose that several of the “should”s should actually be
> MUSTs.
>
>
>    - It seems like captions for Table 4 and Table 5 need to be swapped.
>
>
> Yes, thanks.
>
>
>    - 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.
>
>
> Right now, it’s not necessary. Since opcode 3 can only encode 20 bits, we
> only made the registry that large initially.  If this is insufficient, we
> will need to allocate additional opcodes for additional bits.  At that
> time, we can also increase the size of the registry.
>
GIM>> OK

>
>
> 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?
>
>
> The use of multiple NASes is not restricted to SR.  Yes, you COULD do some
> very strange things. We are trying to write a minimalist specification, so
> that these odd things are not precluded.
>
GIM>> I wonder if the definition of a PSD belongs in
draft-jags-mpls-mna-hdr or draft-song-mpls-extension-header. WDYT?

>
>
>    - Also, for the SR-MPLS case that uses PSD. Would there be a single
>    PSD or a copy for every ISD NAS?
>
>
> That should not be necessary.  AFAICT, you can put everything into a
> single PSD structure, unless you want to do more odd things.
>
>
>    - If there's a single PSD for all NASes in the stack, which node must
>    remove the PSD?
>
>
> The node that removes the last NAS that indicates that there is PSD
> present.
>
>
>    - 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.
>
>
> Agreed. And that’s very painful but not impossible. I would avoid PSD per
> NAS, if possible.
>
>
> Thank you for your kind consideration of my notes and questions. Looking
> forward for our discussion.
>
>
>
> Thank you for your comments and questions.
>
> T
>
>
>