[mpls] Re: draft-ietf-mpls-mna-hdr-17 ietf last call Rtgdir review

[Jaganbabu Rajamanickam <[e-mail]>]

Thanks Matthew, We will upload the latest draft.

Thanx,
Jags

On Tue, Jan 13, 2026 at 8:16 AM Matthew Bocci (Nokia) <matthew.bocci=
[e-mail]> wrote:

> Hi Jags
>
> Thank you for considering my comments and updating the draft. I am good
> with all the resolutions.
>
> Best regards
>
> Matthew
>
> *From: *Jaganbabu Rajamanickam (jrajaman) <[e-mail]>
> *Date: *Tuesday, 13 January 2026 at 12:35
> *To: *Matthew Bocci (Nokia) <[e-mail]>, [e-mail] <
> [e-mail]>
> *Cc: *[e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: draft-ietf-mpls-mna-hdr-17 ietf last call Rtgdir review
>
> You don't often get email from [e-mail]. Learn why this is
> important <https://aka.ms/LearnAboutSenderIdentification>
>
> *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.
>
>
> Hello Matthew,
>    Thanks for your feedback.
>    We have updated the draft with your feedback.
>    We are attaching the diff  and the our response to your feedback.
>
>    Please let us know if you have any questions.
>
> Thanx,
> Jags
>
> Get Outlook for Mac <https://aka.ms/GetOutlookForMac>
> *From: *Matthew Bocci via Datatracker <[e-mail]>
> *Date: *Friday, December 19, 2025 at 11:38 AM
> *To: *[e-mail] <[e-mail]>
> *Cc: *[e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>
> *Subject: *draft-ietf-mpls-mna-hdr-17 ietf last call Rtgdir review
>
> Document: draft-ietf-mpls-mna-hdr
> Title: MPLS Network Action (MNA) Sub-Stack Solution
> Reviewer: Matthew Bocci
> Review result: Has Issues
>
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The
> Routing Directorate seeks to review all routing or routing-related drafts
> as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the Routing
> ADs.
> For more information about the Routing Directorate, please see
> https://wiki.ietf.org/en/group/rtg/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would
> be helpful if you could consider them along with any other IETF Last Call
> comments that you receive, and strive to resolve them through discussion
> or by
> updating the draft.
>
> Document: draft-ietf-mpls-mna-hdr-17
> Reviewer: Matthew Bocci
> Review date: 18-12-2025
>
> Summary
> -------
> In general, the draft is clear and readable. Thank you!
> I appreciate that the draft is the a part of a wider set of protocol
> extensions
> required to achieve MPLS Network Actions, so I have primarily reviewed this
> from the context of the header format and processing that it defines,
> rather
> than broader questions of the overall trajectory of the MNA design. I
> believe
> my comments are fairly minor but these should be resolved before
> progressing
> the draft.
>
> Detailed Comments.
> -----------------
> Comments are embedded below, prefixed by MB>. Line numbers are generated by
> id-nits.
>
> 2       MPLS Working Group                                  J.
> Rajamanickam, Ed.
> 3       Internet-Draft                                            R.
> Gandhi, Ed.
> 4       Intended status: Standards Track                     Cisco
> Systems, Inc.
> 5       Expires: 4 June 2026                                           R.
> Zigler
> 6
> Broadcom
> 7
> H. Song
> 8                                                         Futurewei
> Technologies
> 9                                                                    K.
> Kompella
> 10                                                              Juniper
> Networks
> 11                                                               1
> December 2025
>
> 13                    MPLS Network Action (MNA) Sub-Stack Solution
> 14                             draft-ietf-mpls-mna-hdr-17
>
> MB> Can the title of the document better reflect its content? The draft
> specifies the MNA Sub-stack, including support for in-stack data, but not
> support for post-stack data. Also, it is not an MNA solution as described
> in
> RFC9782 Section 2, but is primarily a header specification. I would suggest
> updating the title to something like: "MPLS Network Action (MNA) Sub-Stack
> Specification including In-Stack Network Action Indicators and In-Stack
> Data.",
> or something along those lines.
>
> 16      Abstract
>
> 18         This document defines the MPLS Network Actions (MNA) sub-stack
> 19         solution for carrying Network Actions and Ancillary Data in the
> MPLS
> 20         label stack.  MNA can be used to influence packet forwarding
> 21         decisions, carry additional Operations, Administration, and
> 22         Maintenance information in the MPLS packet or perform
> user-defined
> 23         operations.  The solution specified in this document addresses
> the
> 24         requirements for In-stack network action and In-stack data
> found in
> 25         RFC 9613.  This document follows the architectural framework
> for the
>
> MB> I suggest re-phrasing to:
>
> 8          This document specifies the MPLS Network Actions (MNA) sub-stack
> 19         for carrying Network Actions and Ancillary Data in the MPLS
> 20         label stack.  MNA can be used to influence packet forwarding
> 21         decisions, carry additional Operations, Administration, and
> 22         Maintenance information in the MPLS packet or perform
> user-defined
> 23         operations.  This document addresses the
> 24         requirements for In-stack network actions and In-stack data
> found in
> 25         RFC 9613.
>
> [snip]
>
> 115     1.  Introduction
>
> 117        [RFC3032] defines the encoding of the MPLS label stack, the
> basic
> 118        structure used to define a forwarding path.  Forthcoming
> applications
>
> MB> The term "forthcoming" could become outdated very rapidly. Rather than
> saying "Forthcoming applications" it would be clearer to move the
> reference to
> RFC9791 up front and say "There are applications that... ".
>
> 119        require MPLS packets to perform special network actions and
> carry
> 120        optional Ancillary Data (AD) that can affect the packet
> forwarding
> 121        decision or trigger Operations, Administration, and Maintenance
> (OAM)
> 122        logging, for example.  Ancillary Data can be used to carry
> additional
> 123        information, such as a network slice identifier or an entropy
> value
> 124        for load-balancing.  Several MPLS Network Actions (MNA)
> applications
> 125        are described in [RFC9791].
>
> 127        The solution specified in this document addresses the
> requirements
> 128        for In-stack network action and In-stack data (ISD) found in
> 129        [RFC9613].
>
> 131        This document defines the syntax and semantics of network
> actions and
> 132        ancillary data encoded in an MPLS label stack.  In-stack
> actions and
> 133        ancillary data are contained in a Network Action Sub-Stack
> (NAS),
> 134        which is recognized by a new base Special Purpose Label
> (bSPL).  This
> 135        document follows the framework specified in [RFC9789].
>
> [snip]
>
> 201     3.  Overview
>
> 203        The MPLS Network Action Sub-Stack (NAS) is a set of Label Stack
> 204        Entries (LSEs) that appear as part of an MPLS label stack and
> serve
> 205        to encode information about the network actions that should be
> 206        invoked for the packet.  Multiple NASes may appear in a label
> stack
> 207        and be placed as described in Section 5.
>
> 209        This document describes how network actions and their optional
> 210        ancillary data are encoded as part of an NAS as a stack of LSEs.
>
> MB> s/an NAS/a NAS
> MB> I think it is worth adding a statement that this document defines new
> LSE
> formats beyond RFC3032 that define behaviors or are processed in different
> ways
> to MPLS labels as defined in RFC3031.
>
> 211        Mechanisms that allow sharing of ancillary data (AD) between
> multiple
> 212        network actions encoded in the same NAS can be described in
> other
> 213        documents and do not rely on any explicit provision in the
> encodings
> 214        described in this document.
>
> 216     4.  Label Stack Entry Formats
>
> 218        The NAS uses a variety of different formats of LSEs for
> different
> 219        purposes.  This section describes the syntax of the various
> formats
> 220        while the overall structure of the NAS and the semantics of the
> 221        various LSEs are described in the sections below.
>
> 223     4.1.  LSE Format A: The MNA Sub-Stack Indicator
>
> 225        LSE Format A is an LSE as described in [RFC3032] and
> [RFC5462].  The
> 226        label value is an IANA-assigned value (TBA) for the MNA bSPL
> label
> 227        from the "Base Special-Purpose MPLS Label Values" registry to
> 228        indicate the presence of MNA in the packet and the beginning of
> an
> 229        MNA Sub-Stack in the label stack.
>
> 231         0                   1                   2                   3
> 232         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> 233
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 234        |      MNA-Label=bSPL                   | TC  |S|    TTL
> |
> 235
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> 237                 Figure 1: LSE Format A: The MNA Sub-Stack Indicator
>
> 239        *  S (1 bit): The Bottom of Stack [RFC3032].  MUST be set to 0
> on
> 240           transmitted packets.  If a packet is received with an LSE
> 241           containing the bSPL (value TBA) and with S bit set to 1,
> then the
> 242           packet MUST be dropped.
>
> 244     4.2.  LSE Format B: The initial opcode
>
> 246        LSE Format B is used to encode the first opcode in the NAS,
> plus a
> 247        number of other fields about the NAS.  This LSE can carry up to
> 13
> 248        bits of ancillary data.
>
> 250         0                   1                   2                   3
> 251         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> 252
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 253        |   Opcode    |        13-bit Data      |R|IHS|S|  NASL |U| NAL
> |
> 254
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> 256                      Figure 2: LSE Format B: The initial opcode
>
> 258        *  Opcode (7 bits): The operation code for this LSE.  See
> 259           Section 5.1.
>
> 261        *  Data (13 bits): Opcode-specific ancillary data.
>
> 263        *  R (1 bit): Reserved.  This bit MUST be transmitted as zero
> and
> 264           ignored upon receipt.
>
> MB> Suggest rephrasing to "This bit MUST be set to zero on transmission and
> ignored upon receipt." to be more consistent with other MPLS RFCs.
>
> 266        *  IHS (2 bits): The scope of the sub-stack.  See Section 5.3.
>
> MB> Isn't this the scope of the network action rather than the sub-stack?
> That
> would be consistent with RFC9613 and Section 5.3.
>
> 268        *  S (1 bit): The Bottom of Stack [RFC3032].  If NASL value is
> non-
> 269           zero, then S bit MUST be 0.  If a packet is received with S
> bit
> 270           set to 1 and a non-zero NASL value, then the packet MUST be
> 271           dropped.  The encapsulating node MUST ensure that the S bit
> is set
> 272           to 1 only in the Last LSE in the MPLS header.
>
> [snip]
>
> 338        *  S (1 bit): The Bottom of Stack [RFC3032].  If this is not
> the last
> 339           LSE for the Network Action based on the NAL value and if S
> bit is
> 340           set to 1 then the packet MUST be dropped.  If this is not
> the last
> 341           LSE in the NAS and if S bit is set to 1 then the packet MUST
> be
> 342           dropped.  The encapsulating node MUST ensure that the S bit
> is set
> 343           to 1 only in the Last LSE.
>
> 345        *  Data (22 bits + 8 bits): Opcode-specific ancillary data
>
> MB> Full stop/period is missing at the end of the above bullet.
>
> 347        NOTE: A Format A and a Format B LSE MUST be present when a
> Format D
> 348        LSE is carried in the NAS.
>
> 350     5.  The MNA Sub-Stack
>
> 352        The MNA Sub-Stack begins with a Format A LSE (Section 4.1).  The
> 353        label value of the LSE contains the MNA bSPL (value TBA) to
> indicate
> 354        the presence of the MNA Sub-Stack.
>
> [snip]
>
> 371        The Format B LSE (Section 4.2) could optionally carry
> additional data
> 372        in Format D (Section 4.4) LSEs, up to the length encoded in the
> LSE's
> 373        NAL value.
>
> 375        An NAS MAY contain more Format C (Section 4.3) and Format D
>
> MB> s/An NAS/A NAS.
>
> 376        (Section 4.4) LSEs, up to the length encoded in the NASL
> value.  All
> 377        Format D LSEs MUST follow a Format C or B LSE and be included
> in that
> 378        LSE's NAL value.
>
> 380     5.1.  Opcodes
>
> 382        The opcode is a 7-bit field that indicates the semantics of its
> LSE.
> 383        Several opcodes are assigned special semantics (Section 6),
> others
> 384        act as Network Action Indicators and are assigned through IANA
> 385        (Section 10 and Section 14.4).
>
> 387     5.2.  Ancillary Data
>
> 389        The data field carries opcode-specific data that is ancillary
> data
> 390        for a network action.  In the case of opcode 1, the data field
> 391        carries Flag-Based Network Action Indicators without ancillary
> data.
>
> 393        Legacy implementations might use the label value (most
> significant 20
>
> MB> I am not sure you mean "Leagacy implementations" since this document
> does
> not obsolete RFC3031 or any other RFC. Label based hashing is a perfectly
> valid
> way of ensuring ECMP behavior does not lead to out of order packet
> delivery on
> an MPLS-based service, and it is very widely deployed. Maybe rephrase to:
> "The
> label value (most significant 20 bits) in one or more consecutive LSEs is
> commonly used for load balancing data flows in an ECMP environment."
>
> 394        bits) in one or more consecutive LSEs when load-balancing data
> flows
> 395        in an ECMP environment.  Modifying the first 20 bits in an LSE
> might
> 396        alter that packet's path and result in out-of-order delivery of
> 397        packets.  To maintain the stability of deployed services in ECMP
>
> MB> The sentence above doesn't quite capture what it is trying to say, I
> think.
> I suggest modifying to: "Modifying the first 20 bits in an LSE might alter
> a
> packet's path and result in out-of-order delivery of packets belonging to a
> given flow."
>
> 398        environments that rely on label value information for
> load-balancing,
> 399        care must be taken when encoding network action data in the
> given
> 400        LSE.  If the network action data may differ among packets in
> the same
> 401        flow or change during forwarding across the MPLS network, it
> MUST NOT
> 402        be placed in the most significant 20 bits of a Format B LSE
> 403        (Section 4.2), a Format C LSE (Section 4.3), or a Format D LSE
> 404        (Section 4.4).  Thus, the available bits for data that can
> change by
> 405        a transit node or differ among packets of the same flow in
> Format A
> 406        and Format B LSEs are 0, Format C LSE is 7 (bits 20-22 and
> 25-28) and
> 407        Format D LSE is 11 (bits 20-22 and 24-31).
>
> [snip]
>
> 426     5.3.  Scope
>
> 428        The IHS field in the Format B LSE indicates the scope of all
> the NAIs
> 429        encoded in the NAS.  Scope defines which nodes along the MPLS
> path
> 430        should perform the network actions found within the NAS.  The
> 431        specific values of the IHS field are as follows:
>
> 433                         +======+=========================+
> 434                         | Bits | Scope                   |
> 435                         +======+=========================+
> 436                         | 00   | I2E                     |
> 437                         +------+-------------------------+
> 438                         | 01   | HBH                     |
> 439                         +------+-------------------------+
> 440                         | 10   | Select                  |
> 441                         +------+-------------------------+
> 442                         | 11   | Reserved for future use |
> 443                         +------+-------------------------+
>
> 445                             Table 2: IHS Scope Values
>
> 447           Ingress To Egress (I2E) - The NAS MUST NOT be processed by
> any
> 448           node except the egress node.
>
> MB> Is it the NAS or the network action (or NAI) that is scoped? The
> terminology in RFC9789 seems to suggest that it is the NA. I suggest
> aligning
> the definitions in this section with that RFC.
>
> 450           Hop-By-Hop (HBH) - All nodes along the path MUST process the
> NAS.
>
> 452           Select - Only specific nodes along the path that brings NAS
> to top
> 453           of the stack will perform the action.
>
> 455        A single NAS carries only one of the three scopes
> (I2E/HBH/Select).
> 456        To support multiple scopes for a single packet, multiple NASes
> MAY be
> 457        included in a single label stack.
>
> MB> Ah OK. So now you say it is the NAS that is scoped. Would it be more
> recise
> to say that a given NAS can only carry NAIs with the same scope?
>
> 459        The egress node is included in the HBH scope.  This implies
> that the
> 460        penultimate node MUST NOT remove a HBH NAS.  The egress node MAY
> 461        receive an NAS at the top of the label stack as discussed in
> 462        Section 10.
>
> 464        An I2E scope NAS, if present, MUST be encoded after any HBH or
> 465        Select-scope NASes.  This makes it easier for the transit nodes
> to
> 466        process a NAS with HBH or Select scope.
>
> 468        If a packet is received with the IHS scope set to "Reserved for
> 469        future use", the packet is processed based on the U bit in the
> Format
> 470        B LSE in the NAS.
>
> [snip]
>
> 565     7.  NAS placement in the Label Stack
>
> 567        The node adding an NAS to the label stack places a copy of the
> NAS
> 568        where the relevant nodes can read it.  Each downstream node
> along the
> 569        path has a Readable Label Depth (RLD).  If the NAS is to be
> processed
> 570        by a downstream MNA-capable node, then the entire NAS MUST be
> placed
> 571        so that it is within RLD by the time the packet reaches the
> 572        downstream MNA-capable node.
>
> 574        If the label stack is deep, several copies of the NAS may need
> to be
> 575        encoded in the label stack.
>
> 577        For an NAS with HBH scope, every node will process the top copy
> of
>
> MB> s/an NAS/a NAS
>
> 578        the NAS, but the NAS MUST NOT appear at the top of the stack at
> any
> 579        MNA-incapable node on the path.
>
> 581        An NAS MUST NOT appear at the top of the stack after popping the
> 582        forwarding label on an MNA-incapable node on the path.
>
> MB> Can you provide more guidance on how the MNA capable inress LER can
> ensure
> this if the downstream node is MNA incapable?
>
> 584        The node behaviour, where an NAS with I2E and HBH scopes is also
> 585        removed along with popping the forwarding label on a PHP node,
> is
> 586        outside the scope of this document.
>
> 588        For an NAS with Select scope, it is processed by the node that
> brings
>
> MB> s/an NAS/a NAS
>
> 589        it to the top of stack (for example, in the case of using MPLS
> label
> 590        pop operation in Segment Routing) and then the NAS is removed
> from
> 591        the stack.  The select-scoped NAS needs to be inserted after the
> 592        forwarding label and before the next forwarding label.  It
> could be
> 593        inserted before or after a HBH NAS.  Note that the case of an
> NAS
> 594        with Select scope with MPLS label swap operation (for example,
> with
> 595        RSVP Traffic Engineering LSPs) is for future study.
>
> [snip]
>
> 614     7.1.  Actions when Pushing Labels
>
> 616        An MNA-capable node may need to push additional labels as well
> as
> 617        push new network actions onto a received packet.
>
> 619        While pushing additional labels on to the label stack of the
> received
> 620        packet, the MNA-capable node MUST verify that the entire
> top-most NAS
> 621        with HBH scope is still within the RLD of the downstream
> MNA-capable
> 622        nodes.  If required, the MNA-capable node MAY create a copy of
> the
> 623        top-most NAS with HBH scope and insert it within the RLD of the
> 624        downstream MNA-capable nodes on the label stack.
>
> 626        When an MNA-capable node needs to push a new NAS with HBH scope
> on to
> 627        a received packet that already has an NAS with HBH scope, it
> SHOULD
> 628        copy (and merge) the network actions (including their Ancillary
> Data)
> 629        from the received top-most NAS with HBH scope in the new NAS
> with HBH
> 630        scope.  The new NAS MUST be placed within the RLD of the
> downstream
> 631        MNA-capable nodes.  This behavior can be based on local policy.
>
> 633        The new network actions added MUST NOT conflict with the network
> 634        actions in the received NAS with HBH scope.  The mechanism to
> resolve
> 635        such conflicts depend on the network actions and can be based on
> 636        local policy.  The MNA-capable node that pushes entries MUST
> 637        understand any network actions which it is pushing which may
> result
> 638        in a conflict, and MUST resolve any conflicts between new and
> 639        received network actions.  In the usual case of a conflict of
> 640        duplicating a network action, the definition of the network
> action
> 641        will generally give guidance on likely resolutions.
>
> MB> The last sentence above is unclear. Also, I think this should be more
> prescriptive so that such that the resolution of conflicts is
> deterministic. I
> propose rephrasing to "The definition of a network action MUST give
> guidance on
> confict resolution."
>
> 643     8.  Node Capability Signaling
>
> 645        The Encapsulating Node is the node that pushes an NAS on to the
> Label
> 646        stack.
>
> MB> 'encapsulating node' to be consistent wiht the captulaisation below.
>
> 648        The encapsulating node MUST make sure that the NAS can be
> processed
> 649        by the transit and egress nodes.
>
> 651        *  The node responsible for selecting a path through the MPLS
> network
> 652           needs to know and consider the MNA-capabilities and RLD of
> the
> 653           transit nodes, and the MNA-capabilities of the end point.
>
> 655        *  Information about the capabilities of the nodes may be
> configured,
> 656           collected through management protocols, or distributed by
> control
> 657           protocols (such as advertising by routing protocols).
>
> 659        *  The mechanisms by which the capabilities of the nodes are
> known by
> 660           the node responsible for selecting a path through the MPLS
> network
> 661           are out of scope for this document.
>
> 663        *  In the case of MPLS Segment Routing (SR-MPLS), as well as
> the,
> 664           RLD, the path computation system needs to know the MSD
> [RFC8664]
> 665           that can be imposed at the ingress node of a given SR path.
> This
> 666           ensures that the label stack depth of a computed path does
> not
> 667           exceed the maximum number of labels (i.e., MSD) the node is
> 668           capable of imposing and the maximum number of labels that
> can be
> 669           read by the MNA-processing nodes in the path.  The MSD needs
> to
> 670           include the MNA Sub-Stacks to be added.
>
> MB> I think this is 'MUST include'.
>
> 672     9.  Processing the Network Action Sub-Stack
>
> 674        This section defines the specific responsibilities for nodes
> along an
> 675        LSP [RFC3031].
>
> 677     9.1.  Encapsulating Node Responsibilities
>
> 679        The encapsulating node MAY add NASes to the label stack in
> accordance
> 680        with its policies, the placement restrictions in Section 7, and
> the
> 681        limitations learned from Section 8.
>
> 683        The encapsulating node MUST NOT add an NAS to the label stack
> if the
> 684        egress node does not support MNA.
>
> MB> s/an NAS/a NAS
>
> 686        If there is an existing label stack, the encapsulating node
> MUST NOT
> 687        modify the first 20 bits of any LSE in the label stack when the
> ECMP
> 688        technique in the network is using the hashing of the labels on
> the
> 689        label stack.
>
> 691        If the encapsulating node is also a transit node, then it MUST
> also
> 692        follow the rules set out in Section 9.2.
>
> [snip]
>
> 724        The following information MUST be defined for a new Network
> Action
> 725        Indicator opcode request in the document that specifies the
> Network
> 726        Action.
>
> 728        A request for a new NAI opcode MUST include the following
> 729        information:
>
> 731        *  Format: The definition of the new Network Action MUST
> specify the
> 732           LSE Formats.  The opcode can define Network Action in Format
> B or
> 733           C or both Format B and C.  Both Format B and C LSEs MAY
> optionally
> 734           carry Format D LSEs.
>
> 736        *  Scope: The definition of the new Network Action MUST specify
> at
> 737           least one scope (I2E, HBH, Select) for the Network Action,
> and MAY
> 738           specify more than one scope.
>
> 740        *  Ancillary Data: The definition of the new Network Action MUST
> 741           specify the quantity, syntax, and semantics of any associated
> 742           Ancillary Data.  The Ancillary Data MAY be variable length,
> but
> 743           the length MUST be computable based on the data present in
> the
> 744           NAS.
>
> 746        *  Processing: The definition of the new Network Action MUST
> specify
> 747           the detailed procedure for processing the network action.
>
> 749        *  Interactions: The definition of the new Network Action MUST
> 750           specify its interaction with other currently defined Network
> 751           Action if there is any.
>
> MB> Including any considerations in merging network actions?
>
> 753        An assignment for an NAI MAY make requests from any combination
> of
> 754        the "Network Action Opcodes" or "Network Action Flags Without
> 755        Ancillary Data" assignments.  This decision should optimize for
> 756        eventual encoding efficiency.  If the NAI does not require any
> 757        ancillary data, then a flag is preferred as only one bit is
> used in
> 758        the encoding.
>
> 760     11.  Backward Compatibility
>
> 762        This section discusses interactions between MNA-capable and
> legacy,
> 763        MNA-incapable nodes.
>
> MB> remove the work 'legacy' in this section as suggested above. It is just
> 'MNA-incapable'.
>
> 765        An MNA-encapsulating node MUST ensure that the MPLS Network
> Action
> 766        Sub-Stack indicator is not at the top of the MPLS label stack
> when
> 767        the packet arrives at an MNA-incapable node.  If such a packet
> did
> 768        arrive at an MNA-incapable node, it will most likely be dropped
> as
> 769        described in Section 2.1.1 of [RFC7325].
>
> 771        Legacy nodes may scan the label stack, potentially looking for a
> 772        label value containing a bSPL.  To ensure that the LSE formats
>
> MB> *any* node cold scan the label stack looking for a bSPL.
>
> 773        described herein do not appear to contain a bSPL value, the
> opcode
> 774        value of 0 has been reserved.  By ensuring that there is a
> non-zero
> 775        value in the high order 7 bits, we are assured that the high
> order 20
> 776        bits cannot be misinterpreted as containing a bSPL value (0-15).
>
> 778        The TC and TTL values of the Format A LSE are not re-purposed
> for
> 779        encoding, as the penultimate node on the MPLS packet path may
> 780        propagate TTL from the transport (or forwarding) label to the
> next
> 781        label on the label stack, overwriting the TTL on the next
> label.  If
> 782        the penultimate node is a legacy node, it might perform this
> action,
> 783        potentially corrupting other values stored in the TC and TTL
> values.
> 784        To protect against this, we retain the TC and TTL values in the
> 785        Format A LSE.
>
> 787        When adding the Entropy Label Identifier (ELI) (bSPL 7) and
> Entropy
>
> MB> Entropy Label Identifier / Entropy Label Indicator
>
> 788        Label (EL) as defined in [RFC6790], along with an MNA NAS, the
> RLD
> 789        MUST be considered for the placement of both, and they both can
> be
> 790        placed in any order.  If a transit LSR chooses to use as much
> of the
> 791        whole label stack as feasible as keys for the load-balancing
> 792        function, the MNA reserved label MUST NOT be used as a key for
> the
> 793        load-balancing function, as specified in Section 4.3 of
> [RFC6790].
> 794        Note that the behavior of an MNA-incapable transit LSR that
> scans the
> 795        label stack for ELI and EL but encounters a different,
> unrecognized
> 796        reserved label first, is not modified by this document.
>
> 798        Similarly, when adding the Flow-ID Label Indicator (FLI)
> (including
> 799        the extension label 15) and Flow-ID Label (FL) as defined in
> 800        [RFC9714], along with an MNA NAS, the RLD MUST be considered
> for the
> 801        placement of both, and they both can be placed in any order.
> Note
> 802        that the behavior of an MNA-incapable transit LSR that scans the
> 803        label stack for FLI (including the extension label 15) and FL,
> but
> 804        encounters a different, unrecognized reserved label first, is
> not
> 805        modified by this document.
>
> 807        However, as the existing behavior is not specified for transit
> LSRs,
> 808        upon encountering any unrecognized bSPLs or eSPLs below the top
> of
> 809        the label stack, some existing implementations may have chosen
> to
> 810        implement non-standardized actions, such as discarding
> packets.  Any
> 811        uses of a new bSPL or eSPL would cause issues with such existing
> 812        implementations using the non-standardized actions upon
> encountering
> 813        unrecognized bSPLs or eSPLs below the top of the label stack.
> Since
> 814        this is a generic problem, any clarifications for the treatment
> of
> 815        unrecognized bSPL or eSPL are outside the scope of this
> document.
>
> 817     12.  Implementation Status
>
> 819        [Note to the RFC Editor - remove this section before
> publication, as
> 820        well as remove the reference to [RFC7942]]
>
> 822        This section records the status of known implementations of the
> 823        protocol defined by this specification at the time of posting
> of this
> 824        Internet-Draft, and is based on a proposal described in
> [RFC7942].
> 825        The description of implementations in this section is intended
> to
> 826        assist the IETF in its decision processes in progressing drafts
> to
> 827        RFCs.  Please note that the listing of any individual
> implementation
> 828        here does not imply endorsement by the IETF.  Furthermore, no
> effort
> 829        has been spent to verify the information presented here that was
> 830        supplied by IETF contributors.  This is not intended as, and
> must not
> 831        be construed to be, a catalog of available implementations or
> their
> 832        features.  Readers are advised to note that other
> implementations may
> 833        exist.
>
> 835     12.1.  University of Tuebingen Implementation
>
> 837        The solution defined in the document draft-ietf-mpls-mna-hdr-08
> has
> 838        been implemented using P4 pipeline.  The implementation code
> can be
> 839        found at https://github.com/uni-tue-kn/P4-MNA.
>
> MB> General comment: It would be useful to record the above implementation
> status somewhere public after it is removed from this document. The text
> should
> also be clear as to what value of bSPL is used by this implementation to
> avoid
> the risks of clashes in the wild, since there is no early allocation for
> the
> MNA bSPL.
>
> 841     13.  Security Considerations
>
> 843        The security considerations in [RFC3032] and [RFC9789] also
> apply to
> 844        this document.
>
> 846        In addition, MNA-creates a new dimension in security concerns:
>
> 848        *  The actions of an encapsulating node can affect any or all
> of the
> 849           nodes along the path.  In the most common and benign
> situations,
> 850           such as a syntactically incorrect packet could result in
> packet
> 851           loss or corruption.
>
> 853        *  The semantics of a network action are unbounded and may be
> 854           insecure.  A network action could be defined that made
> arbitrary
> 855           changes to the memory of the forwarding router, which could
> then
> 856           be used by the encapsulating node to compromise every
> MNA-capable
> 857           router in the network.  The IETF needs to ensure that only
> secure
> 858           network actions are defined.
>
> 860        *  The MNA architecture supports locally-defined network
> actions.
> 861           For such actions, there will be limited oversight to ensure
> that
> 862           the semantics do not create security issues.  Implementors
> and
> 863           network operators will need to ensure that the
> locally-defined
> 864           network actions do not compromise the security of the
> network.
>
> 866        *  The MPLS domain border nodes MUST ensure that the MPLS
> packets
> 867           with MNA from any domain with a different administrative
> control
> 868           can be filtered to prevent entering the provider MPLS
> domain.  The
> 869           filtering capability MAY be enabled on a per network action
> basis
> 870           and it can be based on a local policy.  The filtering
> capability
> 871           MUST be implemented on those nodes before deploying MNA in
> the
> 872           provider MPLS domain.  The RLD on the filtering node MUST be
> 873           higher than the RLD on all other nodes in the provider MPLS
> 874           domain.
>
> 876        *  The MNA architecture supports modifying the AD on the
> intermediate
> 877           nodes, so the critical network functions should either not
> rely on
> 878           the data or should be aware of the risks and use other means
> to
> 879           verify the security of the whole network.
>
> 881        *  The "private Use" opcodes in "Network Action Opcodes"
> Section 14.4
> 882           and "Network Action Flags Without Ancillary Data" Section
> 14.3
> 883           Registry are subject to the considerations described in
> [RFC8126].
>
> 885        *  System designers must be aware that information included in
> 886           Ancillary Data may be transmitted "in the clear."  Network
> actions
> 887           that require the exchange of sensitive data, must be defined
> in
> 888           such a way that the data is encrypted in transit.
>
> MB> MNA can define new forwarding actions. Mis-delivery of a packet due to
> malformed forwarding action data could be considered a security risk. I
> suggest
> adding this.
>
> 890     14.  IANA Considerations
> 891     14.1.  MNA bSPL Label
>
> 893        This document requests that IANA allocate a value (TBA) for the
> MNA
> 894        bSPL label from the "Base Special-Purpose MPLS Label Values"
> registry
> 895        to indicate the presence of an MNA Sub-Stack in the label
> stack.  The
> 896        description of the value should be "MPLS Network Actions".  The
> 897        reference should be this document.
>
> 899     14.2.  MPLS Network Actions Parameters
>
> 901        This document requests that IANA create a new category called
> "MPLS
> 902        Network Actions Parameters" within the "Multiprotocol Label
> Switching
> 903        Architecture (MPLS)" category.  The registries described below
> should
> 904        belong to this new category.
>
> [snip]
>
>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>