Re: [mpls] Do you care about MNA? [Was: 2nd Working Group Last call on draft-ietf-mpls-mna-requirements]

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

Greg

Thanks for your detailed comments. Please see below.

Matthew

From: Greg Mirsky <[e-mail]>
Date: Friday, 29 March 2024 at 02:58
To: [e-mail] <[e-mail]>
Cc: mpls <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [mpls] Do you care about MNA? [Was: 2nd Working Group Last call on draft-ietf-mpls-mna-requirements]

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 Adrian,
thank you for your thoughtful reminder. I've read the current version and support its publication. Below, please find my non-blocking comments and questions:

  *   Abstract. I am not sure that LSR and LER are well-known acronyms. Perhaps it is safer to use the expanded form.
MB> Ack. I know there was a discussion on the list, but I think for the sake of clarity these should just be expanded on first use.


  *   A general question. Should the capitalization be used in "MPLS network action" as that is the name of a general mechanism? I've noticed some inconsistency in using capitalization and the abbreviated form NA.
MB> Agreed. I will capitalize it.

  *   I have a question about the first type of expected documents that will be the outcome of the draft under discussion. Do we expect that a single document will define "a common protocol that supports all forms of MPLS Network Actions"? The current wording seems to suggest that that will be a single specification. As per our discussions, I think that there's a viable scenario when an additional specification of MNA using the PSD principle would be produced. WDYT?
MB> I am not sure the requirements draft needs to specify the document structure for the solution(s). For example, the base solution could be described in a document for specifying an ISD solution and a document specifying a PSD solution, and something else specifying the common parts (like an MNA alert mechanism),  as long as those are consistent with each other and at least the common part is available when either the ISD or PSD is progressed.

  *   Section 1.1. Perhaps s/other protocol structure/post-stack header/?
MB> Agreed

  *   The last paragraph in Section 3 reads like an introduction to a discussion of the current state of HW capabilities. I think that the requirements must not be bounded by the available today technology leaving the decision to implementors and users.
MB> I don’t read it that way, but on the other hand there is no point designing a protocol that cannot be implemented and deployed in a real scenario in the time frame that the solutions are published (I thought ‘running code’ was still a valid part of how the IETF works 😉). I thik the current text is fine and is just saying ‘be careful how you design this’.

  *   The first sentence in requirement #1 is a statement, not a requirement. It could be moved out and used as an informational text.

MB> I would suggest rephasing the requirement as follows:
“Any MNA and Network Action solution MUST maintain the properties of extensibility, flexibility, and efficiency inherent in the split between the control plane context and simple data plane used in MPLS, and SHOULD describe how this is achieved.”

  *   Reading requirement #4, I asked myself, Do we have a well-understood definition of "coexistence with existing mechanism X"? Is that another way to say that introducing MNA MUST NOT require an update of all nodes in an MPLS domain?
MB> It means that, and in addition it means ‘don’t break an existing MPLS mechanism if you deploy it together’. I am not sure we should change this text as it is sufficiently generic.

  *   A couple of notes on requirement #12:

     *   s/to the PE/by the LER/ or s/to the PE to the LSRs/by the PE to P nodes/
MB> Ack

     *   Do you think splitting this requirement in two will make it easier to check a solution's conformance?
MB> I am not sure it makes any difference as they are both ‘MUST NOT’s, but I will split this if it is clearer as they are slightly different.

  *   It seems like the first MUST in requirement #17 is automatically satisfied if a solution conforms to the second MUST. Can the requirement be edited to use only the minimization clause without respect?
MB> Something like?: “Special Purpose Labels (SPLs) are a mechanism of last resort, and therefore an MNA solution that uses them MUST minimise the number of new SPLs that are allocated.”

  *   Is "immediate forwarding (reference #19) another form of "forwarding at line rate"? I don't think that "immediate forwarding" is a usual term.
MB> No. This was text crafted around a previous discussion about ‘slow path’ vs ‘fast path’.

  *   The second MUST in requirements ## 21 and 22 seems like a reworded version of a more general requirement #3.
MB> Agreed. This is a duplicate of #3. We can delete the second MUST in 21 and 22.

  *   Could you help me understand why it is SHOULD and not MUST in requirements ##23, 28, and 31?
MB> #23, one could envisage a new data plane operation that is implementable in forwarders but is not a traditional push/pop/swap/mark etc. I don’t think we should exclude that.
#28, because a given NA may not be applicable to all LSP types.
#31, Agreed, this could be a MUST.

  *   I am not familiar with what "in-use control and management planes" are.
MB> I think this is saying that it must be possible to extend existing control planes (LDP, RSVP, ISIS/OSPF, BGP-LS and so on) and management planes (NetConf – with a YANG model) to expose this information to the ingress LER so it can determine the capability of downstream LSRs.

  *   What do you see as a value of requirement #44? Can it be turned into an informational text or removed altogether?
MB> I am not sure there would be consensus to remove this.

  *   It seems like "must" in requirement #45 is really a MUST.
MB> Agreed

  *   Would any ISD-only MNA solution automatically conform to requirement #46?
MB> That depends on whether there is any interaction with the GAL/G-ACH.

  *   Is requirement #49 another way (less general in my opinion) of expressing requirement #37?
MB> No, I think we should keep both. #37 was explicitly trying to address the risk of orphaned ancillary data not being cleaned up properly when the NAIs were removed due to some upstream operation at an LSR.

  *   Perhaps splitting requirement #52 in two could help validate the conformance of a solution in the future.
MB> Agreed
To reiterate. I believe that all my questions and comments are editorial and are non-blocking the progress of the draft.

Regards,
Greg