Re: [mpls] I-D Action: draft-ietf-mpls-mna-requirements-09.txt

["Matthew Bocci (Nokia)" <[e-mail]>]

Hi Tony

Thanks for your comments. Please see below.

Matthew

From: mpls <[e-mail]> on behalf of Tony Li <[e-mail]>
Date: Tuesday, 30 January 2024 at 22:31
To: Matthew Bocci (Nokia) <matthew.bocci=[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [mpls] I-D Action: draft-ietf-mpls-mna-requirements-09.txt

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.


[co-chair hat: OFF]

Hi Matthew, co-authors,

Thank you very much for these revisions.  I have a few comments:



     Requirement 53 in section 3.5 (Requirements on Ancillary Data) seems to
     prohibit an intermediate LSR which is pushing on labels and NAI from
     pushing on ancillary data along with them. Such a prohibition seems to
     be a contradict the WG agreements. Please fix.


Proposed resolution> Reword and split into the following:

- In-stack ancillary data MUST only be inserted in conjunction with pushing one or more labels
onto the top of stack.


I have a concern about this.  Suppose a node wishes to add an action to an existing label stack and there are
already NAS on the stack.  This would prevent the node from adding the action.  An example of this might be a
transit node that wants to add an entropy action because it is the start of an ECMP path.

MB> Is this a swap of the top label (or a pop and forward in the case of SR)? Or do you mean pushing a new top label for that downstream ECMP path? If the former, then I think that is contradictory to 3031 because we are inserting something below the forwarding label. At very least it is rewriting the NAS. If the latter, I don’t think that is precluded.


- Processing of ancillary data below a swapped label MAY include rewriting the ancillary data.
A solution to a use case that needs to change the size of the
ancillary data MUST analyze the implications on packet forwarding and specify how these are addressed..


I’m not following this text. The first sentence is fine. I’m not sure what a “solution to a use case” is. It really seems like
this is a requirement on the specific action.

MB> Agreed. We can change this to refer to the network action.


  In requirement 22 (apparently related to requirement 21) what does "in the
  way the imposing node intends" mean?   The text seems more specific than just
  understanding the operation to be performed.


Proposal resolution>

  22.  An NAI MUST NOT be imposed for delivery to a node
        unless it is known that the processing node can process the NAI correctly.


This is simply not tractable. How does anyone know (including the implementation's authors) whether an implementation is bug free?
Correctness is a bar that is far too high.


Suggested rewording:

An NAI MUST NOT be imposed for delivery to a node unless it is
        known that the node supports processing the NAI.

MB> Agreed.



Thanks,
Tony