[mpls] FW: I-D Action: draft-ietf-mpls-mna-requirements-09.txt

WG

We have just posted a new revision of draft-ietf-mpla-mna-requirements. This revision addresses comments from Greg and Joel on the list. It does not yet address comments from Haoyu, which I propose to address in a subsequent pass of the draft.

A diff relative to v08 is available here: Diff: draft-ietf-mpls-mna-requirements-08.txt - draft-ietf-mpls-mna-requirements-09.txt<https://author-tools.ietf.org/iddiff?url1=draft-ietf-mpls-mna-requirements-08&url2=draft-ietf-mpls-mna-requirements-09&difftype=--html>

Below is a list of the resolutions that we worked through with Joel to address his comments.

Best regards

Matthew

On 04/01/2024, 16:41, "Joel Halpern" <jmh@joelhalpern.com> 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.

Proposed resolution> Replace with the following two requirements:

- All indicators MUST be consistent with [RFC3031].

- If there is post-stack AD, there MUST be an indication of its presence in the label stack.

     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.

Proposed resolution> Replace both 43 and 44 with:

"The structure of the NAI and any associated ancillary data must enable skipping of
unknown action indicators and associated ancillary data.""

     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?

Proposed resolution> Added the following into the security considerations and removed the offending requirements:
"This creates an implicit trust relationship between the LSR whose forwarding behavior is being changed
and the upstream LSR inserting the data causing that change."

     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.

Proposed resolution> Reword and split into the following:

- In-stack ancillary data MUST only be inserted in conjunction with pushing one or more labels
onto the top of stack.

- Post-stack ancillary data MUST only be inserted where a new label with the S-bit set is pushed.

- Processing of ancillary data below a swapped label 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.

Proposed resolution> Remove (5) as we should not constrain future debate in the WG.

  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?

Proposed resolution> Reword to:
21.  Without constraining the mechanism, an MNA solution MUST enable a node inserting or modifying NAIs
        to determine if the target of the NAI, or any other LSR that may
        expose the NAI, can accept and process a packet containing the
        NAI.

  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.

Proposal resolution>

  22.  An NAI MUST NOT be imposed for delivery to a node
        unless it is known that the processing node can process the NAI correctly.

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

Proposed resolution> Delete requirement 47

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.

Proposed resolution>
24.  A given NAI specification MUST specify which scope or scopes are applicable to the NAI.

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

Proposed resolution> 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"

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

Proposed resolution> delete 49.

Yours,

Joel Halpern

On 1/3/2024 10:20 AM, Matthew Bocci (Nokia) wrote:
> Hi WG
>
> Thank you to everyone who reviewed the previous version of the draft and
> provided valuable comments.
>
> There were many comments embedded in the WG last call discussions on the
> list and we made numerous changes to address these, as well as some other
> editorial improvements to the text. This made it a challenge to track all
> the improvements.
>
> Please refer to the following diff to see where changes were made:
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-mpls-mna-requirements-
> 07&url2=draft-ietf-mpls-mna-requirements-08&difftype=--html
>
> We would greatly appreciate feedback on the updates and any further
> comments on the draft.
>
> Best regards Matthew
>

> On 11/12/2023, 14:26, "Adrian Farrel" <adrian@olddog.co.uk
> <mailto:adrian@olddog.co.uk>> wrote:
>

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

> The authors have been busy making changes based on the extensive review
> comments and discussions arising from the first last call for this
> document.
>

> It would be really helpful if people could start to look through the
> document and see which of their concerns have been addressed and what is
> still outstanding.
>

> Given the volume of comments, it would be no surprise if the authors need
> to make a further round of adjustments, but starting to look at the text
> (and possibly focusing on the diffs) might speed things along.
>

> Thanks, Adrian
>

> -----Original Message----- From: I-D-Announce
> <i-d-announce-bounces@ietf.org <mailto:i-d-announce-bounces@ietf.org>> On
> Behalf Of internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> Sent:
> 11 December 2023 12:05 To: i-d-announce@ietf.org
> <mailto:i-d-announce@ietf.org> Cc: mpls@ietf.org <mailto:mpls@ietf.org>
> Subject: I-D Action: draft-ietf-mpls-mna-requirements-08.txt
>

> Internet-Draft draft-ietf-mpls-mna-requirements-08.txt is now available. It
> is a work item of the Multiprotocol Label Switching (MPLS) WG of the IETF.
>

> Title: Requirements for Solutions that Support MPLS Network Actions
> Authors: Matthew Bocci Stewart Bryant John Drake Name:
> draft-ietf-mpls-mna-requirements-08.txt Pages: 11 Dates: 2023-12-11
>

> Abstract:
>

> This document specifies requirements for the development of MPLS network
> actions which affect the forwarding or other processing of MPLS packets.
> These requirements are informed by a number of proposals for additions to
> the MPLS information in the labeled packet to allow such actions to be
> performed, either by a transit or terminating LSR (i.e. the LER).
>

> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-requirements/
> <https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-requirements/>
>

> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-requirements-08
> <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-requirements-08>
>

> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-mpls-mna-requirements-
> 0
> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-mpls-mna-requirements
> -0> 8
>

> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>

> _______________________________________________ I-D-Announce mailing list
> I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
> https://www.ietf.org/mailman/listinfo/i-d-announce
> <https://www.ietf.org/mailman/listinfo/i-d-announce>
>

> _______________________________________________ mpls mailing list
> mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls

From: I-D-Announce <i-d-announce-bounces@ietf.org> on behalf of internet-drafts@ietf.org <internet-drafts@ietf.org>
Date: Monday, 29 January 2024 at 16:57
To: i-d-announce@ietf.org <i-d-announce@ietf.org>
Cc: mpls@ietf.org <mpls@ietf.org>
Subject: I-D Action: draft-ietf-mpls-mna-requirements-09.txt

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.

Internet-Draft draft-ietf-mpls-mna-requirements-09.txt is now available. It is
a work item of the Multiprotocol Label Switching (MPLS) WG of the IETF.

   Title:   Requirements for Solutions that Support MPLS Network Actions
   Authors: Matthew Bocci
            Stewart Bryant
            John Drake
   Name:    draft-ietf-mpls-mna-requirements-09.txt
   Pages:   11
   Dates:   2024-01-29

Abstract:

   This document specifies requirements for the development of MPLS
   network actions which affect the forwarding or other processing of
   MPLS packets.  These requirements are informed by a number of
   proposals for additions to the MPLS information in the labeled packet
   to allow such actions to be performed, either by a transit or
   terminating LSR (i.e. the LER).

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-requirements/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-requirements-09

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-mpls-mna-requirements-09

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce