[mpls] Re: Mohamed Boucadair's Discuss on draft-ietf-mpls-mna-hdr-18: (with DISCUSS and COMMENT)

["Jaganbabu Rajamanickam (jrajaman)" <[e-mail]>]

Hello Med,

Thank you for the clarifications. We have updated the draft accordingly and uploaded the new version.
We have also added my comments to your latest ones, tagged as [Auth-2].

Thanx,
Jags


Get Outlook for Mac <https://aka.ms/GetOutlookForMac>

From: [e-mail] <[e-mail]>
Date: Tuesday, February 3, 2026 at 1:15 AM
To: Jaganbabu Rajamanickam (jrajaman) <[e-mail]>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Tarek Saad (tsaad) <[e-mail]>
Subject: RE: Mohamed Boucadair's Discuss on draft-ietf-mpls-mna-hdr-18: (with DISCUSS and COMMENT)

Hi Jags,

Thank you for the follow-up and changes. I think that we are almost there.

Please see inline.

Cheers,
Med

De : Jaganbabu Rajamanickam (jrajaman) <jrajaman=[e-mail]>
Envoyé : lundi 2 février 2026 23:49
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; The IESG <[e-mail]>
Cc : [e-mail]; [e-mail]; [e-mail]; Tarek Saad (tsaad) <[e-mail]>
Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-mpls-mna-hdr-18: (with DISCUSS and COMMENT)


Hello Med,

Thank you for your detailed review. We have updated your comments and attached the diff along with the new draft version to this email. Our responses are included inline below, marked as [Auth].

Thanx,
Jags


Get Outlook for Mac<https://aka.ms/GetOutlookForMac>
From: Mohamed Boucadair via Datatracker <[e-mail]<mailto:[e-mail]>>
Date: Monday, February 2, 2026 at 1:06 PM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Tarek Saad (tsaad) <[e-mail]<mailto:[e-mail]>>
Subject: Mohamed Boucadair's Discuss on draft-ietf-mpls-mna-hdr-18: (with DISCUSS and COMMENT)
Mohamed Boucadair has entered the following ballot position for
draft-ietf-mpls-mna-hdr-18: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-hdr/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Jaganbabu, Rakesh, Royi, Haoyu, and Kireeti,

Thank you for the effort put into this specification.

Thanks to Tianran and Joe for the OPSDIR reviews. Thank also to the authors for
engaging and making changes to address main comments.

Please find below some easy-to-fix DISCUSS points:

# Internal consistency

Section 8:
   The encapsulating node is the node that pushes a NAS on to the Label
   stack.

Section 9.2
   The transit node is the node that processes a NAS in the Label stack
   but does not push any new NAS.

Section 9.1
   If the encapsulating node is also a transit node, then it MUST also
   follow the rules set out in Section 9.2.

Given the definition of these nodes, I don’t understand when 9.1 would work.

Is the intent here to refer to a node that may have different roles for
distinct frames? Else?

I would simply delete the sentence in 9.1.

[Auth] Updated
[Med] ACK


# Normative references

CURRENT:

   function, the MNA reserved label MUST NOT be used as a key for the
   load-balancing function, as specified in Section 4.3 of [RFC6790].

17.2.  Informative References
..

   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
              RFC 6790, DOI 10.17487/RFC6790, November 2012,
              <https://www.rfc-editor.org/info/rfc6790>.

## RFC6790 should be listed as normative.

## I think the same applies for 3270 and 8126. Please check how references are
classified.

[Auth] Updated
[Med] ACK



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Sample applications

CURRENT:
   There are applications
   that require MPLS packets to perform special network actions and
   carry optional Ancillary Data (AD) that can affect the packet
   forwarding decision or trigger Operations, Administration, and
   Maintenance (OAM) logging, for example.

## Please consider adding a pointer to where such applications are discussed.
If not, please add examples directly here.


[Auth] Updated

[Med] Thanks



## I appreciate this is not relevant at this stage in the document, but this
requirement has scalability and performance implications. It would be useful to
mention those or add a pointer where these are discussed.



[Auth] It is expected that this would be covered in the relevant MNA application documents in future.

[Med] As these are direct implications of the MNA design, would it be possible to have these aspects explicitly mentioned under Operational Considerations. You can indicate that further assessment of these matters is out of scope but encouraged to be cover in MNA application documents.

 [Auth-2]  created a new section "Performance and Scale Considerations” and updated the section.

# Slice Identifier

CURRENT:
   Ancillary Data can be used
   to carry additional information, such as a network slice identifier

There is no “network slide identifier“ defined yet in the IETF. I suggest this
change:




CURRENT:
   Ancillary Data can be used
   to carry additional information, for network slice purposes [RFC5943]

[Auth] Updated

[Med] ACK

# Please introduce Ingress/Egress nodes early in the document (Section 2,
typically).


[Auth] Added a new section 2.3 to cover the above terminology


# The organization in term of various formats requires some attention to be
digested. It would be helpful to consider a summary of these (and design
rationale) in the overview section (Section 3).


[Auth] Added “The new LSE formats allow to carry 7 bits of network action opcodes and variable size of opcode specific ancillary data.” To section 3

[Med] This is a minimalist text, but this is better :-). I was hoping to see an overview of the various Format x, though.

[Auth-2] Updated as below.

"                          Three new LSE formats are defined to carry 7  

                     bits of network action opcodes and varying amounts of opcode-specific      
                     ancillary data.  Specifically, Format-B LSE carries up to 13 bits of 
                     ancillary data, Format-C LSE carries up to 20 bits of ancillary data 
                     in a single LSE, and Format-D LSEs are used when more than 20 bits of      
                     ancillary data are needed
“



# These are not sides notes; please format as plain text

CURRENT:
   NOTE: A Format A and a Format B LSE MUST be present when a Format C
   LSE is carried in the NAS.

(and similar ones)


[Auth] Updated

[Med] Thanks.


# Section 9.1

CURRENT:
   The encapsulating node MUST NOT add a NAS to the label stack if the
   egress node does not support MNA.

Isn’t this part of the limitations in Section 8?


[Auth] Do you want to remove this sentence from section 9.1 ?

[Med] For me this is an implication of this part in Section 8



  The encapsulating node MUST make sure that the NAS can be processed

   by the transit and egress nodes.



Also, it is not clear why only egress nodes are cited in 9.1, while the parent requirement applies for transit as well.

[Auth-2]  you are right,
“The encapsulating node MUST make sure that the NAS can be processed by the transit and egress nodes.” is covered in section 8, so we will remove the “ The encapsulating node MUST NOT add a NAS to the label stack if the egress node does not support MNA.” From section 8 to avoid confusion.


# Section 14

Thanks for the discussion in Backward compatibility Section. I think that this
is better positioned as a subsection of Section 14.


[Auth] The renamed the section 14 to “Manageability Considerations” as it only contains counters

[Med] I prefer the OLD name of the section to follow the guidance in draft-ietf-opsawg-rfc5706bis. Backward compatibility (migration matters) and manageability falls under OPS considerations. Thanks.


[Auth-2] reverted back to “Operational Consideration” and moved “Backward compatibility” under this section.

# You may consider moving the examples into an appendix.


[Auth] Moved the example into appendix

[Med] Thanks.


Cheers,
Med



____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.