Re: [mpls] Closing on draft-ietf-mpls-mna-requirements adoption poll comments

[Adrian Farrel <[e-mail]>]

Thanks for the work, Matthew, and for the notification.

 

I've queued this to look at, but I am chronically busy for a few days.

 

A

 

From: Bocci, Matthew (Nokia - GB) <[e-mail]> 
Sent: 13 October 2022 11:36
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: Closing on draft-ietf-mpls-mna-requirements adoption poll
comments

 

Hi Adrian

 

Thank you for the extensive review and comments. I have just posted a new
revision of the draft where we have tried to address these as far as
possible. Please see below for some responses prefixed with Ed2.>

 

Regards

 

Matthew

 

 

From: Adrian Farrel <[e-mail] <mailto:[e-mail]> >
Date: Tuesday, 26 July 2022 at 23:14
To: [e-mail]
<mailto:[e-mail]>
<[e-mail]
<mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]>  <[e-mail]
<mailto:[e-mail]> >
Subject: Closing on draft-ietf-mpls-mna-requirements adoption poll comments

Hi authors,

Thanks for your work in advancing this document and especially for collating
the adoption poll comments in the Appendix.

I agree that this Appendix can now be removed, but concurrent with that I
thought it would be helpful to review your resolutions of the comments. It's
not clear who raised which comments, but I'm considering them all here.

Cheers,
Adrian

===

   1.   Normative Language

[AF] OK with resolution

   2.   The NAS abbreviation

[AF] OBE per 3

   3.   non-use of NAS abbreviation

[AF] OK with resolution

   4.   Section 3.2 typo

[AF] OK with resolution

   5.   Extra words

[AF] OK with resolution

   6.   Merging of drafts?

[AF] OK with resolution

   7.   ADI -> NAI

[AF] OK with resolution

   8.   Addition to section 3.1

        For backward compatibility and consistency, It is suggested to
        add the below items to section 3.1 as general requirements: a)
        Solutions meeting the requirements set out in this document MUST
        be compatible with existing MPLS mechanisms.  b) Solutions
        meeting the requirements set out in this document MUST reuse
        existing MPLS mechanisms when possible.  c) For network actions
        which are developed or under development in IETF, the encoding
        and processing of the network action data MUST be reused.

        Ed.> Requirements 1-4 already cover points a and b.  C is
        outside the scope of this document but we are not intending to
        limit or prescribe anything about existing standards.

[AF] I disagree that 3.1#1 is related to backward compatibility. It talks
about how the resultant solution must enable the functions currently
available in MPLS: that is not backward compatibility.
[AF] I disagree that 3.1#2 is about backward compatibility. It talks about
how the resultant architecture must remain generally applicable, but it does
not talk about backward compatibility.
[AF] I disagree that 3.1#3 is about backward compatibility. It talks about
extensions not being incompatible with the architecture, but it does not
imply backward compatibility.
[AF] Item 3.1#4 might be interpreted as being about backward compatibility,
but it is not quite clear that "coexist with" and "not obsolete" actually
means backward compatibility. That may be the authors' intention, but
backward compatibility would also mean that a legacy implementation
encountering a solution to these requirements must not have an undesired
response or there must be a way to prevent such an implementation seeing
such an encounter.

[AF] However, 3.3#2 and 3.3#3 do seem to cover this. So no further action.

   9.   Action Indicators without AD

[AF] OBE see #13

   10.  AD definition

[AF] OK with resolution

   11.  Optional AD?

[AF] OK with resolution

   12.  ADI and NAI are different

[AF] OBE see #13

   13.  Retire ADI

[AF] OK with resolution

   14.  AD generic?

[AF] OK with resolution

   15.  What ADI indicates

[AF] OBE see #13

   16.  Common requirement to carry AD

[AF] OK with resolution

   17.  Not discussed

[AF] OBE see #13

   18.  Discussed when draft presented in the Open DT

[AF] OBE see #13

   19.  Comment from Loa

[AF] OK with resolution

   20.  Keep using ADI

[AF] OK with resolution

   21.  Use of NSI

[AF] OBE

   22.  Revise definition of NAS

[AF] OK with resolution

   23.  Popping NAS

        When you pop a stack in programming, the concept that MPLS
        borrowed, you pop the procedure indicator and the procedure
        parameters.  This is consistent with popping an NAS

        Ed.> No action

[AF] I think that what is hiding in this issue is a description of what is
required to happen to the ancillary data when the NAI is popped.
[AF] It looks like there is a requirement to "remove the whole block" (per
Kireeti's presentation today). That takes care of in-stack data and the NAI.
[AF] Something needs to be said about the post-stack data (that may be that
a solution may choose to leave it in place or strip it or null it).

   24.  More than a name change

[AF] OK with resolution

   25.  Writeable NAS

        I have some further questions.  NAS is something within the
        label stack but writable by intermediate nodes.  Is this the
        stack operation?  Besides, if NAS emerges at ToS, you said it'll
        be popped and discarded.  What if the NAS also needs to be
        applied to the labels below it?  Whatever measures you will take
        here, are those the stack operations?

        Ed.> NAS has been removed.

[AF] The fact that the term "NAS" has been removed is not material to this
point. You could re-read this issues with s/NAS/NAI and in-stack AD/

[AF] Thus the question is about whether actions indicated higher up the
stack can apply to hops lower down the stack. If so, there is a need to
"move" the NAI and in-stack AD when it gets to top of stack.


   26.  The NFRR use case

        I have several questions about the NFRR use case.  As I
        understand it, a point of local repair (PLR) imposes NAS with
        the NFRR indicator so that it becomes ToS at the merge node
        (MN).  If that is correct, then the MN will remove the NAS with
        the NFRR indicator as the packet is returned on the "normal"
        path.  Hence, I don't see why an intermediate node would need to
        write into an existing in the label stack NAS in support of
        NFRR.

        Ed.> NFRR is not discussed in this draft.

[AF] The point of the comment is to understand whether there is *any*
motivation for allowing an intermediate node to write into an existing
in-stack NAS or insert a new one. The requirements should be motivated by
use cases, and the comment says that this use case does not motivate this
requirement. See also #25

Ed2> Use cases could include writing timing info into the ancillary data


[AF] 3.3#1 certainly implies that NAIs and in-stack AD can be inserted by
intermediate nodes.

[AF] But see #27

   27.  Intermediate node re-writing

        I may not see a case for an intermediate node re-writing the
        existing NAI.  I think that the node should impose a new NAS.  I
        see the case for an intermediate node writing into PSD (e.g.,
        HbH IOAM though I think that is too expensive and the IOAM
        Direct Export or Hybrid Two-Step are a better choice).  To
        summarize, I don't see the need for an intermediate node to
        write into ISD and am open to discussing the node writing into
        PSD.

        Ed.> Added a requirement that network action specifications must
        describe whether ISD can be rewritten by an intermediate node.

[AF] This is 3.3#16
[AF] But, per #26, his seems to be hiding from the debate! You have allowed
"rewrite" without any specific use case that motivates it. Are there any
implications of "rewrite" or does it come for free? If it's free, why do we
even need to worry about the NA spec having to say yes or no? If there are
implications we should call them out, and consider whether we don't actually
want to rule out this "option".

Ed2.> A use case would be rewriting timing info in a packet


   28.  Two types of indicators

[AF] OK with resolution

   29.  Second term needed

[AF] See #30

   30.  Propose text

[AF] OK with resolution

   31.  NAS not general enough

[AF] OK with resolution

   32.  Use of ancillary data

[AF] OK with resolution

   33.  What the NAS contain

[AF] OK with resolution

   34.  User-defined actions

        user-defined network actions?  Should we mentione in the
        requirements doc?

        Ed.> The allocation policy should be specified in the draft that
        defines the IANA registry for the NAIs.

[AF] You have 3.3#19 covers this more precisely by saying that user-defined
NAs MAY be supported. No further action

   35.  draft-ietf-mpls-mna-requirements

[AF] OK with resolution

   36.  In the Abstract (1)

[AF] OK with resolution

   37.  In the Abstract (2)

        The term "application data" may be (is) confusing.  While you
        probably mean it to imply an application of MPLS, it may be
        confused with the type of application that runs end-to-end
        (i.e., on a host).  Although, reading some of the text, it does
        feel like some of the time you _are_ intending to imply that the
        application software may somehow be able to provide the
        ancillary data that is ultimately carried by MPLS.

        I think, in the Abstract, you could say...

        based on ancillary data that may be carried in or below the
        bottom of the label stack.

        ...but you should probably look through the rest of the text and
        consider the use of the word "application."  Maybe one approach
        would be to specifically call out the term near the top of the
        document in order to correctly set the context.

        Ed> OK agreed.

[AF] The Abstract is now clean, thanks.
[AF] Section 1.2 still talks about "applications" without qualifying the
meaning.

Ed2> Replaced the term with 'use cases'


   38.  In section 1 (1).

[AF] OK with resolution

   39.  In section 1 (2).

[AF] OK with resolution

   40.  In section 1.1 (1)

[AF] OK with resolution

   41.  In section 1.1 (2).

        *  Network Action: An operation to be performed on a packet.  A
           network action may affect router state, packet forwarding, or
           it may affect the packet in some other way.

        If the operation affects router state, is it really performed on
        the packet?

        Ed.> Yes.

[AF] Oh no it isn't! Router state is something held in the router and so the
action is "instructed," "motivated," or "indicated" by the packet, but not
performed *on* the packet.
[AF] This issue is not resolved. It is *probably* only editorial, but until
resolved it's not clear whether it is technical.

   42.  In section 1.1 (3)

[AF] OK with resolution

[AF] But note that the framework (and in-meeting discussion from Tarek)
refers to the NAS

   43.  In section 1.1 (4)

[AF] OK with resolution

   44.  In section 1.2 (1)

        s/number of new proposals/number of proposals/

[AF] Does not seem to have been applied

   45.  In Section 1.2 (2)

        for example In-situ OAM and Service Function Chaining (SFC)
        Might benefit from references for iOAM and SFC.

[AF] Does not seem to have been applied

   46.  In section 1.2 (3)

        [I-D.song-mpls-extension-header] summarises some of the issues
        with existing solutions to address these new applications (note
        that this document draws on the requirements and issues without
        endorsing a specific solution from
        [I-D.song-mpls-extension-header]):

        This gives more emphasis to the referenced draft than I think
        you intend.  If you intend that people read that draft to see
        the issues, it is a normative reference.  But if you are just
        mentioning it and have pulled the information into this
        document, then you need to reduce the emphasis.  How about...

        [I-D.song-mpls-extension-header] sets out some of the issues in
        how existing solutions address these new applications.  This
        document draws on the requirements and issues noted in that
        document without endorsing any specific solution.

        Ed.> New text is virtually identical.  The existing text is fine
        and is not intended to be normative.

[AF] If the new text is virtually identical, why do you object to the
change?

   47.  Section 2

        While I understand the desire to express the requirements in
        definitive language, BCP14 is not about requirements.  Rather it
        is intended to describe implementation behaviours.

        A way around this that is often used is to include a subsequent
        paragraph such as...

        Although this document is not a protocol specification, this
        convention is adopted for clarity of description of
        requirements.

        See, for example, RFC 4139, RFC 4687, or RFC 5862.

        Ed> Despite what BCP14 says, there is a long standing convention
        of using must and should in requirements documents because they
        specify requirements on protocol design.  Suggest no change to
        the existing text.

[AF] The convention extends to adding the proposed text. Why do you object
to it?

 

Ed2> Added sentence above to the requirements language section to clarify.


   48.  In section 3.2 (1)

[AF] OK with resolution

   49.  In section 3.2 (2)

[AF] OK with resolution

   50.  In section 3.2 (1)

        (3).  Any solution MUST respect the principle that Special
        Purpose Labels are the mechanism of last resort and therefore
        must minimise the number of new SPLs that are allocated.

        Presumably a minimum here would be zero?

        Loa: No we have considere this and decided that there is room to
        specify 1 bSPL for MNA.

        Ed.> Existing text is fine.

[AF] The existing text is not fine according to this definition. "Minimise"
means "strive for as low a number as possible". Zero would be such a number.

[AF] You mean "strive for no more than 1 bSPL".

        Loa: I also think that we should s/Special Purpose Labels/Base
        Special-Purpose Labels Note: for the Extended SPLs there sare no
        such reestriction.

        Ed.> Existing text is fine.

[AF] I agree with Loa that it is helpful to not use the term SPL unless that
is what is meant. In this case, what is meant is bSPL (i.e., not eSPL): if
the solution were to use a dozen ePSLs, I don't believe it would be an issue
at all.

Ed2> Regardless of the kind of SPL, we should minimise the number which
could be zero if user defined labels are used. We propose to keep the text
as is.


   51.  In section 3.2 bullet 5

[AF] OK with resolution

   52.  In section 3.2 (bullet, 5, 6 and 10)

        Bullet 10 is a wholly contained subset of bullet 5.  Actually,
        bullet 10 is a wholly contained subset of bullet 6.  Makes me
        think that bullets 5 and 6 possibly say the same thing as each
        other.

        Ed.> Will move 10 up the list to be closer to 5 / 6.  They are
        not the same but are related.

[AF] Slightly confusing to map this as the bullets have moved between
sections, but...
3.3#2 was 3.2#5
3.3#3 was 3.2#6
3.3#12 was 3.2#10
[AF] So it looks like 10 has not moved closer to 5 / 6 (i.e., 12 is not
closer to 2 / 3)

[AF] The three requirements read
   2.   An NAI MUST NOT be delivered to a node that is not capable of
        processing the indicated network action in a way that is
        acceptable to the imposing LER.

   3.   An NAI MUST NOT become top of stack at a node that does not
        understand how to perform a disposition operation on it.
        Disposition includes both processing and ignoring.

   12.  An MNA solution MUST enable a node inserting or modifying NAIs
        to determine if the far-end LER can accept and process a packet
        containing a given NAI.

[AF] The points here are that you cannot achieve 2 or 3 without 12. It is
not possible to stop the NAI being presented to a node that cannot process
it unless you know which nodes cannot process it.

[AF] With respect to 2 and 3 possibly being duplicates or overlapping, the
question is what the different is between "delivered to a node" and "become
top of stack at a node". How are they different?

Ed2.> 3 is a subset of 2. SO will delete it. 12 is a consequence of 2 so
will move it up to follow 2.


[AF] BTW, 3.2#6 reads...
   6.   If an MNA solution allows more than one scope, it must provide a
        mechanism MUST to specify the precedence of the scopes.
... which seems garbled.

Ed2.> OK fixed


   53.  In section 3.2 (2)

        (11).  NAIs SHOULD be supported for both P2P and P2MP paths, but
        any specific NAI may only be supported for one or the other.

        Really?  You can't have an NAI that is equally applicable for
        both P2P and P2MP?  Seems an odd restriction to impose.

        Ed.> The text is correct as written.
        Ed2.> It is a MAY, so the existing text is as intended. 'NAIs' means
NAIs in general, not a specific NAI, and then any given NAI may only apply
to on or the other type of LSP.


[AF] This is now 3.3#7

[AF] You need to explain how the "text is correct" at least in email, and
possibly in the document.

[AF] Perhaps it is that I just cannot parse this requirement easily. It
seems to say that when there is a required function, exactly two NAIs should
be defined: one for P2P and one for P2MP. But it says it very unclearly and
"supported" has an implication for implementation rather than for
specification!
[AF] 1. If my understanding is correct, perhaps the text could be clearer.
[AF] 2. If my understanding is correct, why?

   54.  In section 3.2 (3)

        (15).  NAIs can only be inserted at LERs, but MAY be processed
        at LSRs and LERs.  If it is required to insert an NAI at a
        transit LSR on an LSP, then a new label stack MUST be pushed.

        What does it mean to push a new label stack?  If you mean that
        we should support "MPLS in MPLS" encapsulation so that the
        packet has two bottom of stack bits set, I should point out that
        this was previously discussed and abandoned because the presence
        of an LSE immediately after a set bottom of stack bit was
        considered unacceptable because of the assumptions made by
        existing hardware about what follows the bottom of stack.

[AF] I don't see an answer to this in the Appendix, but I do see 3.3#13 and
#14
   13.  NAIs are normally inserted at LERs, but MAY be processed at LSRs
        and LERs.
   14.  If an network action needs to insert an NAI with in-stack
        ancillary data at a transit router on an LSP, then the new
        network action indicator and any required ancillary data MUST be
        pushed onto the MPLS label stack.

[AF] #14 has address the "new label stack" issue.

[AF] And #13 has reconciled the contradiction of what LSRs can do, but what
is "normally inserted"? Does it mean that on Tuesdays an LSR can perform
insertion? Does it mean that LSRs can do insertions, but in an abnormal way?

[AF] If you say the LSRs do not normally do insertion then any (and every!)
use case can claim that it is a special case and suddenly LSR insertion
becomes normal.

Ed2> This requirement was updated in the published draft following a lot of
discussion in the OpenDT calls.  Please see the new requirements in this
section.


   55.  In section 3.2 (4)

[AF] OK with resolution

   56.  In section 3.3 (1)

        (3.3/1) is surely already covered by 3.3/4

        Ed>These are correct but we have strengthened 3.3/1.

[AF] My bad. Should have read 3.3/1 is surely already covered by 3.1/4
[AF] In the new revision, these are 3.4#1 and 3.1#4

[AF] Nothing wrong with the text of either, but there seems to be repetition
from the "General Requirement" to the "AR Requirement"

   57.  In section 3.3 (2)

[AF] OK with resolution

   58.  Semantic Routing

[snip]

        We also set out to examine the challenges and concerns
        introduced by Semantic Routing in draft-king-irtf-challenges-in-
        routing and I think it would be good if this work was calibrated
        against those challenges.

        Loa: While semantic routing is intresting, and good be
        "calibrated" against MNA as a whole (guiding documents and
        solutions), I think it is out of scope for the requirement
        document.

        Ed.> Agree with Loa's response.

[AF] My point here is that you should look at
draft-king-irtf-challenges-in-routing specifically to motivate requirements
for inclusion here. I suspect, however, you are going to say that if I think
there are additional requirements then I sould raise them myself. I guess
that is the difference between an individual draft pre-adoption and a WG
draft that we have now.

Ed2.> Please provide specific text that you would like to add to the
requirements draft.


   59.  Understanding of Use Cases

[AF] Well, the use cases draft has now been adopted as well, so we are
beyond discussing this point.

   60.  Conflicting text in document

        I'm puzzled that some of the text in this document appears to
        limit itself to cases that require ancillary data, while other
        parts also consider the requirements for network functions that
        don't require ancillary data, but do still need to be encoded in
        the label stack in some way.  I suspect this is just editorial,
        but while the document title is "Requirements for MPLS Network
        Action Indicators and MPLS Ancillary Data" the Abstract says
        "This draft specifies requirements for indicators in the MPLS
        label stack to support ancillary data in the packet and high
        level requirements on that ancillary data," and the Introduction
        seems entirely focused on the ancillary data case.

        It would be good to be clear, at the point of adoption, which
        way we are jumping on this question.

        draft-andersson-mpls-mna-fwk seems to be fully behind 
        network actions some of which may also require ancillary data.

        Perhaps this document should reference that one for additional
        information?

        Ed> Updated abstract to focus on network actions.  Will check
        for inconsistencies in rest of document.

[AF] The edits here seem to have gone too far.
[AF] The Title still says "... and MPLS Ancillary Data" but the Abstract
makes no mention of ancillary data which sets it at odds.
[AF] The Introduction does not introduce ancillary data, but suddenly says
"... the encoding and use of the ancillary data."

Ed2.> Suggest generalising the title by just referring to MPLS Network
Actions.


   61.  Loa: I have been thinking about a short text (1 or 2 paragraphs)

[AF] OK with resolution