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

[Greg Mirsky <[e-mail]>]

Hi Matthew,
thank you for your kind consideration of my notes and questions; much
appreciated. I agree with the proposed updates. As many said before me
"Ship it!"

Regards,
Greg

On Thu, Apr 4, 2024 at 3:28 AM Matthew Bocci (Nokia) <
[e-mail]> wrote:

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