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

["Dongjie (Jimmy)" <[e-mail]>]

Hi authors, Adrian and WG, 

Please find some additional response to the resolution of the comments in the appendix. Thanks.

Best regards,
Jie


> -----Original Message-----
> From: mpls [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Wednesday, July 27, 2022 6:14 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [mpls] 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
> 
> ===
> 
>    2.   The NAS abbreviation
> 
> [AF] OBE per 3

[Jie] This term is not used in the requirements, thus the change in abbreviation is out of scope of this document

> 
>    3.   non-use of NAS abbreviation
> 
> [AF] OK with resolution

[Jie] Agree to remove NAS from this document.

>    7.   ADI -> NAI
> 
> [AF] OK with resolution

[Jie] I don't think this is fully solved. The replacement of ADI with NAI has caused the problem of mixing up the requirements on two different levels of indicators. It is good to see in the -02 version of the requirement draft, separate subsections (3.2 and 3.3) are newly created for the two levels of indicators, while the text in each subsection needs to be reviewed to make sure they align with the title of each subsection. 

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

[Jie] The comments were about 3 requirements to be added:

	a) Solutions meeting the requirements set out in this document MUST be compatible with existing MPLS mechanisms.  

[Jie] As Adrian mentioned, this requirement is not reflected in current 3.1#1 to #4. Since it is a generic requirement and not only about the network action indicators, I'd suggested to add it to section 3.1. 

	b) Solutions meeting the requirements set out in this document MUST reuse existing MPLS mechanisms when possible. 
	
[Jie] I don't think this is covered by 3.1#1 to #4 either. Thus it is suggested to add it to section 3.1, probably use "SHOULD" to replace "MUST".

	c) For network actions which are developed or under development in IETF, the encoding and processing of the network action data MUST be reused.

[Jie] This is a requirement related to the network action data, thus it seems suitable to be added to section 3.4. It could also use "SHOULD" to replace "MUST".

> 
>    9.   Action Indicators without AD
> 
> [AF] OBE see #13

[Jie] The action indicator is now called NAI, not sure do we still need separate terms for NAI without data?

>    10.  AD definition
> 
> [AF] OK with resolution

[Jie] I'd like to reiterate that this is a change to the semantics of ancillary data. AD was used to represent the optional data associated with an MPLS packet, Now AD is used to represent the optional data associated with a specific network action. 

Personally I don' like this change as it caused confusions. At least the semantics about AD needs to be consistent throughout this document and also in other related documents.

> 
>    11.  Optional AD?
> 
> [AF] OK with resolution

[Jie] With the changes of the definition of AD, the term ISD and PSD will only cover the AD and the NAI is not included in either ISD or PSD. I'm not sure whether this is the intent, and whether this excludes the option of carrying NAIs post the stack. 

> 
>    12.  ADI and NAI are different
> 
> [AF] OBE see #13

[Jie] I think people realized that the "old" ADI is different from NAI. 

> 
>    13.  Retire ADI
> 
> [AF] OK with resolution

[Jie] OK, It has been replaced by two new terms. 

>    16.  Common requirement to carry AD
> 
> [AF] OK with resolution

[Jie] A similar requirement on post-stack data would be needed. 


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

[Jie] It shows that the requirement about pushing or popping a network action needs to be further elaborated, for example, whether it MUST be consistent with the operations in RFC 3031. 


>    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
> 
> [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".
> 
>    28.  Two types of indicators
> 
> [AF] OK with resolution

[Jie] Basically this comment reflects the need to have a separate term for the bSPL to avoid it being mixed up with NAI. 


>    29.  Second term needed
> 
> [AF] See #30
> 
>    30.  Propose text
> 
> [AF] OK with resolution

[Jie] This is related to the term "NAS", which will be removed from this document. 

The comment was that it has been discussed that there is possibility of having the bSPL + PSD in the packet, which cannot be covered by the term NAS. 

> 
>    31.  NAS not general enough
> 
> [AF] OK with resolution

[Jie] Same as the comments to #30.


>    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?
> 
>    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.
> 
>    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?
> 
> [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.
> 
>    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.
> 
> [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.
> 
>    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.
> 
>    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."
> 
>    61.  Loa: I have been thinking about a short text (1 or 2 paragraphs)
> 
> [AF] OK with resolution
> 
> _______________________________________________
> mpls mailing list
> [e-mail]

> https://www.ietf.org/mailman/listinfo/mpls