Re: [mpls] This is not a last call! draft-ietf-mpls-mna-requirements-08.txt

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

Hi Joel

Thanks for your detailed review and comments. Please see below.

Best regards

Matthew

On 04/01/2024, 16:41, "Joel Halpern" [e-mail]<mailto:[e-mail]> wrote:

I appreciate the wording of requirement 7 in section 3.1 (General
Requirements).  That seems to make clear the scoping of these requirements.

Major:

     I keep re-reading requirement 34 that indication of post-stack data must
     be consistent with RFC 3031 and I am left very confused as to what it
     means.  It doesn't say that there MUST be an indication in the stack.
     It seems to allow for it being magically known?   That doesn't seem like
     a requirement.  Please clarify or remove.


MB> I agree that there should be an indication in the stack that something
follows BoS, and I think we should be explicit about this, but for E2E MNA
with post-stack data the end points could just agree that something follows
without the need for any in stack indicator (similar to PW CW).
Alternatively, you could have a post-stack specific MNA alert mechanism and
then you look below stack for an NAI, similar to the way GAL/GACH works. I am
not advocating that. I am just using it as a counterpoint. But I agree that
in-stack may be desirable for intermediate LSRs.

What about?: “  If a network action requires post-stack ancillary
data, it must be implicitly or explicitly indicated in the stack using a method
consistent with  [RFC3031].”


     Requirement 43 in section 3.5 (Requirements on Ancillary Data) is either
     an unclear restatement that in-stack or post-stack data MUST have
     indications, or it is some other requirement not consistent with our
     ongoing work.  I recommend removing it.  This seems related to
     requirement 44, which I would also recommend removing.

MB> This requirement was intended to apply to post-stack ancillary data, where the stack could
be popped (so discarding the NAI) prior to the packet reaching the egress LER. It is consistent
with section 3.6.1 (First Nibble considerations) of the framework. I suggest rephrasing to:

"A common preamble for post-stack ancillary data MUST be defined so that a
        node receiving the ancillary data can determine whether to
        process, ignore, skip over or discard it according to network or
        local policies.


I agree that 43 is possibly not needed if the NAI gives you enough
context to find the AD, whether it is post-stack or in-stack. But that assumes the
NAI is present at the receiving node, which it may not be in the case of post-stack
where the stack is popped before reaching the terminating node e.g. in PHP

MB> I think 44
is needed. The in-stack AD needs to be structured so that a forwarder can skip over
it and correctly find the bottom of stack, for example. This is consistent with the framework.

     I find requirement 50 in section 3.5 (Requirements on Ancillary Data)
     which claims to require a means to "verify the integrity of ancillary
     data processed by LSR" to be confusing. Despite what we may or may not
     have written in RFC 3552 we do not have as far as I know means to verify
     the integrity of anything related to MPLS.  I can vaguely imagine an OAM
     mechanism implied by this requirement, but I doubt that is what is
     meant.  Please clarify or remove?

MB> Yes, agreed but we do need to mention this issue. I would suggest rephrasing to be
more of a commentary and moving it to the security considerations and out of the requirements part.

     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.

MB> The root cause of this issue is that LER is not well defined, and . I
would rather we talked about the functions rather than the nodes. I would
suggest breaking this down and rephrasing splitting into something like:

- 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.

- Post-stack ancillary data MUST only be inserted where a new bottom of stack label is pushed.
and MAY be processed at any LSR.

- Processing 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.


Minor:

  Is requirement 5 of section 3.1 (General Requirements) intended to prevent
  MNA from covering Entropy.  It seems to, as it says that MNA solutions MUST
  NOT obsolete existing MPLS mechanisms (e.g. ELI / EL)? This also seems
  related to requirement 41.


MB> No. It is intended to prevent MNA from obsoleting basic forwarding
mechanisms in MPLS. It does not prevent MNA from offering an alternative
entropy mechanism if that makes sense in an overall set of solutions.

Would it be helpful to elaborate requirement 21 in section 3.4 (Requirements
on Network Action Indicators) to include text that control or management
mechanisms may be used to meet this requirement?

MB> A precedent for this is the signaling involved in Entropy Label
Capability. I am not sure we should spell out such mechanisms here as this is
a requirements draft rather than a solutions draft.

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.

MB> It means don’t send MNA to a node that you don’t know what it will do
with it or will not handle it in a way that is acceptable to you. This is
because it may affect forwarding and the AD may contain metadata form the
payload. Potentially, the receiving node may just drop the whole packet if it
doesn’t recognise at least the MNA indicator. Does the following rephrasing help?:

22.  An imposing node MUST NOT insert an NAI
        unless it knows that any node that processes it has indicated that it can do so
        in the way the imposing node intends.


Requirement 47 in section 3.5 (Requirements on Ancillary Data) seems vacuous.
I can not see how its presence would affect any solution proposal.

MB> This necessary advisory text, and is the result of discussions in the OpenDT. I
propose that we change the MUST to a SHOULD as it probably doesn't matter for E2E port-stack
AD that is not intended for processing by intermediate LSRs.

Nit:

MNA should be expanded upon first use.  (It appears in requirement 2 of
section 3.1, General Requirements, but does not appear in section 1.1,
Terminology. It appears expanded as the title of section 3, but without the
acronym.)

MB> Ack

Is requirement 23 redundant with requirement 24?

MB> No. 23 is talking about the overall NAI design, but 24 is talking about
the solution to a given use case. I think this could be made clearer.

Does requirement 25 allowing solutions with only on scope contradict
requirement 23?  Or 24?

MB> It is not intended to. We should add “… or any combination of scopes.”

The final "this" in requirement 36 is a little vague.  I think it means "this
ancillary data"

MB> Yes. I will replace the offending ‘this’.

Is requirement 49 in section 3.5 (Requirements on Ancillary Data) needed?  It
seems to be covered by requirement 19 that actions need to be clear about
their relationship to processing / mis-ordering.

MB> Agreed. I think we can delete 49.