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

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

Hi Tony

I don’t think this is trying to preclude rewriting the NAS – at least that is not the intent. What we are precluding is the more extreme cases. For example, inserting a new NAS deep in the stack where one did not previously exist at an LSR that is just swapping the top label.

The issue with the original requirement (53) was a standard definition of LER (there isn’t really one), so we needed to spell this out without using the term LER. Requirement (51) describes processing of the ancillary data at any LSR. How about adding a forward reference to both 49 and 50, something like the following?:

49. In-stack ancillary data MUST only be inserted in conjunction with pushing one or more labels onto the top of stack and MAY be processed at any LSR (see Requirement 51).

50.  Post-stack ancillary data MUST only be inserted where a new label with the S-bit set is pushed and MAY be processed at any LSR (see Requirement 51).


Matthew


From: Tony Li <[e-mail]> on behalf of Tony Li <[e-mail]>
Date: Thursday, 1 February 2024 at 18:11
To: Matthew Bocci (Nokia) <[e-mail]>
Cc: Matthew Bocci (Nokia) <matthew.bocci=[e-mail]>, [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.



Hi Matthew,

     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.


As currently worded, you have precluded just rewriting the NAS.  You are insisting that additional labels be pushed. I’m not sure why, but I certainly don’t understand the rationale. This seems much more restrictive than the language in -08.

Tony