MIME-Version: 1.0
References: 
 <178160939557.539091.17610779556377688514@dt-datatracker-f9b87776f-8pmmg>
In-Reply-To: 
 <178160939557.539091.17610779556377688514@dt-datatracker-f9b87776f-8pmmg>
From: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Date: Tue, 23 Jun 2026 12:19:01 -0400
Message-ID: 
 <CAMZsk6dguTT3nt1yQgt3-s=jizGUw+mikWEEowxKWJTj+Z8jKQ@mail.gmail.com>
To: Chongfeng Xie <xiechf@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="000000000000a0b3f90654ee1e2f"
Message-ID-Hash: JTLT47ZJGJRN2BTT2JRBXG2CFILSD4QF
CC: ops-dir@ietf.org, draft-ietf-mpls-mna-ps-hdr.all@ietf.org,
 last-call@ietf.org, mpls@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bmpls=5D_Re=3A_draft-ietf-mpls-mna-ps-hdr-08_ietf_last_call_Opsd?=
	=?utf-8?q?ir_review?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/mpls/AdTk479sf7cZx_4iGJtdIfOYuW8>

--000000000000a0b3f90654ee1e2f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Chongfeng,

Thank you for the detailed Opsdir review and suggestions.

We have updated the work in progress revision (09) that addresses your
comments.

Please see replies inline with <RG>...


On Tue, Jun 16, 2026 at 7:33=E2=80=AFAM Chongfeng Xie via Datatracker <
noreply@ietf.org> wrote:

> Document: draft-ietf-mpls-mna-ps-hdr
> Title: Post-Stack MPLS Network Action (MNA) Header Specification
> Reviewer: Chongfeng Xie
> Review result: Has Issues
>
> Hi,
>
> I have been selected as the Operational Directorate (opsdir) reviewer for
> this
> Internet-Draft.
>
> The Operational Directorate reviews all operational and management-relate=
d
> Internet-Drafts to ensure alignment with operational best practices and
> that
> adequate operational considerations are covered.
>
> A complete set of _"Guidelines for Considering Operations and Management =
in
> IETF Specifications"_ can be found at
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.
>
> While these comments are primarily for the Operations and Management Area
> Directors (Ops ADs), the authors should consider them alongside other
> feedback
> received.
>
> - Document: [draft-ietf-mpls-mna-ps-hdr-08]
>
> - Reviewer: [Chongfeng Xie]
>
> - Review Date: [June 17, 2026]
>
> - Intended Status: [Proposed Standard]
>
> ---
>
> ## Summary
>
> Choose one:
>
> - Has Issues: I have some minor concerns about this document that I think
> should be resolved before publication.
>
> ## General Operational Comments Alignment with RFC 5706bis
>
> > This document defines a mechanism to influence packet forwarding
> decisions
> based on the additional
>     information in the MPLS packet, or perform user-defined operations.
> While
>     the technical approach is sound,  the document lacks the consideratio=
n
> on
>     how the mechanism would be deployed and managed, and it is recommende=
d
> that
>     a section on operational considerations be added to aligh with
> RFC57606 bis.
>

<RG> We have added the following section.


*8.  Operational Considerations   The operational considerations in
[I-D.ietf-mpls-mna-hdr] also apply   to this document.   Performance and
scale assessments are outside the scope of this   document; the authors of
any future PS MNA application documents are   encouraged to address
them.8.1.  Manageability Considerations   A PS MNA implementation MAY
collect the following counters:   *  MNA Sub-Stacks with P flag received
 *  MNA Sub-Stacks with P flag processed   *  PS MNA per-network-action
counters   *  Packets with PSMH dropped due to unknown actions   *  Packets
with PSMH skipped due to unknown actions   *  Packets with PSMH dropped due
to malformed PSMH   Additionally, tracking both successful invocations and
failures for   each specific post-stack network action is RECOMMENDED to
provide   granular visibility.  Nodes MAY generate rate-limited
notifications   or alarms for significant operational events, such as
sustained high   rates of PS MNA packet drops or frequent encounters of
malformed   PSMH, to alert operators to potential issues.  Comprehensive
logging   of PS MNA processing details and outcomes can aid in the network
 diagnostics and post-mortem analysis.*


>
> ## Major Issues
>
>  > No major issues found.
>
> ---
>
> ## Minor Issues
>
> List non-blocking but important clarifications (e.g., ambiguous
> terminology or
> incomplete examples).
>
> > This document currently uses full terms and their abbreviations
> interchangeably (e.g., =E2=80=9CPost-Stack MPLS Header=E2=80=9D and =E2=
=80=9CPSMH=E2=80=9D). To avoid
> redundancy, it is recommended to adopt a single consistent form throughou=
t,
> otherwise, defining the abbreviation is unnecessary.
>

<RG> Fixed.


>
> > It is recommended to change the definition of IHS as below,
>
>   OLD:
>       IHS (2 Bits): The In-Stack NAS for each scope with the P bit set
>       has a corresponding Post-Stack MPLS Header.
>
>   NEW:
>     IHS (2 Bits): The scope of all the network actions for the In-Stack N=
AS
>     with the P bit set.
>

<RG> Updated as following:


*   *  IHS (2 Bit): The scope of all the NAIs encoded in the NAS as well
  as in the corresponding PSMH.*


>
> > In section 3.1, the definition of the S flag should be relocated to
> precede
> that of the U flag, and the text can be changed to "Same to the definitio=
n
> of S
> flag in section 4.2 of [I-D.ietf-mpls-mna-hdr]"
>

<RG> Added as following:


*The following fields are carried in an NAS as defined in
 [I-D.ietf-mpls-mna-hdr] and shown in Figure 1. *


*   *  S (1 Bit): The BoS.   *  NASL (4 Bits): The Network Action Sub-Stack
Length.   *  NAL (3 Bits): The Network Action Length.*


>
> > Regarding the title of section 3.2.1, since the struct in figure 2
> contains
> not only header type, but also PFN and PSMH-Len, it is more suitable to u=
se
> "Post-Stack MPLS Base Header", instead of "Post-Stack MPLS Header Type".
>

<RG> Updated.


>
> >In section 3.2.3, I think the addreviation of "PSMHT" can be removed, to=
o
> many
> abbreviations, particularly those without substantive meaning, do not
> contribute much to the draft.
>

<RG> Removed PSMHT and replaced with Base.


>
> >The title of section 4.1 can be simplified as,
>      OLD:
>           In-Stack Network Action Opcode for PSMH Start Offset for MNA
>      NEW:
>           Opcode for PSMH Start Offset for MNA
>

<RG> Updated to:
*4.1.  Opcode for PSMH Start Offset*


> >The title of section 4.2 can be simplified as,
>     OLD:
>       In-Stack Network Action Opcode for Offset of End of Post-Stack MPLS
>       Header for MNA
>
>     NEW:
>      Opcode for Offset of End of Post-Stack MPLS Header for MNA
>


<RG> Updated to:
*4.2.  Opcode for PSMH End Offset*


> > In section 5.3,  "ingress node" is used to refer to the node that adds =
a
> Post-Stack MPLS Header, to avoid duplicative terms., it is suggested to
> change
> it to "Encapsulating node" , and the terms of "participating node" and
> "egress
> node" can be changed to "encapsulating node" and "decapsulating node"
> repectively.
> ---
>

<RG> Updated.

Thanks,
Rakesh (for authors)


>
> ## Nits
>
> > No Nits found.
>
> ---
>
> Chongfeng Xie
>
>
> _______________________________________________
> mpls mailing list -- mpls@ietf.org
> To unsubscribe send an email to mpls-leave@ietf.org
>

--000000000000a0b3f90654ee1e2f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div>Hi=C2=A0Chongfeng,<=
/div><div><br></div><div>Thank you for the detailed Opsdir review and sugge=
stions.</div><div><br></div><div>We have updated the work in progress revis=
ion (09) that addresses your comments.</div><div><br></div><div>Please see =
replies inline with &lt;RG&gt;...</div><div><br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jun 16, 2026=
 at 7:33=E2=80=AFAM Chongfeng Xie via Datatracker &lt;<a href=3D"mailto:nor=
eply@ietf.org" target=3D"_blank">noreply@ietf.org</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">Document: draft-ietf-mpls-=
mna-ps-hdr<br>
Title: Post-Stack MPLS Network Action (MNA) Header Specification<br>
Reviewer: Chongfeng Xie<br>
Review result: Has Issues<br>
<br>
Hi,<br>
<br>
I have been selected as the Operational Directorate (opsdir) reviewer for t=
his<br>
Internet-Draft.<br>
<br>
The Operational Directorate reviews all operational and management-related<=
br>
Internet-Drafts to ensure alignment with operational best practices and tha=
t<br>
adequate operational considerations are covered.<br>
<br>
A complete set of _&quot;Guidelines for Considering Operations and Manageme=
nt in<br>
IETF Specifications&quot;_ can be found at<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/" =
rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/doc/draft=
-ietf-opsawg-rfc5706bis/</a>.<br>
<br>
While these comments are primarily for the Operations and Management Area<b=
r>
Directors (Ops ADs), the authors should consider them alongside other feedb=
ack<br>
received.<br>
<br>
- Document: [draft-ietf-mpls-mna-ps-hdr-08]<br>
<br>
- Reviewer: [Chongfeng Xie]<br>
<br>
- Review Date: [June 17, 2026]<br>
<br>
- Intended Status: [Proposed Standard]<br>
<br>
---<br>
<br>
## Summary<br>
<br>
Choose one:<br>
<br>
- Has Issues: I have some minor concerns about this document that I think<b=
r>
should be resolved before publication.<br>
<br>
## General Operational Comments Alignment with RFC 5706bis<br>
<br>
&gt; This document defines a mechanism to influence packet forwarding decis=
ions<br>
based on the additional<br>
=C2=A0 =C2=A0 information in the MPLS packet, or perform user-defined opera=
tions. While<br>
=C2=A0 =C2=A0 the technical approach is sound,=C2=A0 the document lacks the=
 consideration on<br>
=C2=A0 =C2=A0 how the mechanism would be deployed and managed, and it is re=
commended that<br>
=C2=A0 =C2=A0 a section on operational considerations be added to aligh wit=
h RFC57606 bis.<br></blockquote><div><br></div><div>&lt;RG&gt; We have adde=
d the following section.</div><div><i><br></i></div><div><i>8.=C2=A0 Operat=
ional Considerations<br><br>=C2=A0 =C2=A0The operational considerations in =
[I-D.ietf-mpls-mna-hdr] also apply<br>=C2=A0 =C2=A0to this document.<br><br=
>=C2=A0 =C2=A0Performance and scale assessments are outside the scope of th=
is<br>=C2=A0 =C2=A0document; the authors of any future PS MNA application d=
ocuments are<br>=C2=A0 =C2=A0encouraged to address them.<br><br>8.1.=C2=A0 =
Manageability Considerations<br><br>=C2=A0 =C2=A0A PS MNA implementation MA=
Y collect the following counters:<br><br>=C2=A0 =C2=A0* =C2=A0MNA Sub-Stack=
s with P flag received<br>=C2=A0 =C2=A0* =C2=A0MNA Sub-Stacks with P flag p=
rocessed<br>=C2=A0 =C2=A0* =C2=A0PS MNA per-network-action counters<br>=C2=
=A0 =C2=A0* =C2=A0Packets with PSMH dropped due to unknown actions<br>=C2=
=A0 =C2=A0* =C2=A0Packets with PSMH skipped due to unknown actions<br>=C2=
=A0 =C2=A0* =C2=A0Packets with PSMH dropped due to malformed PSMH<br><br>=
=C2=A0 =C2=A0Additionally, tracking both successful invocations and failure=
s for<br>=C2=A0 =C2=A0each specific post-stack network action is RECOMMENDE=
D to provide<br>=C2=A0 =C2=A0granular visibility.=C2=A0 Nodes MAY generate =
rate-limited notifications<br>=C2=A0 =C2=A0or alarms for significant operat=
ional events, such as sustained high<br>=C2=A0 =C2=A0rates of PS MNA packet=
 drops or frequent encounters of malformed<br>=C2=A0 =C2=A0PSMH, to alert o=
perators to potential issues.=C2=A0 Comprehensive logging<br>=C2=A0 =C2=A0o=
f PS MNA processing details and outcomes can aid in the network<br>=C2=A0 =
=C2=A0diagnostics and post-mortem analysis.</i><br><br></div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
## Major Issues<br>
<br>
=C2=A0&gt; No major issues found.<br>
<br>
---<br>
<br>
## Minor Issues<br>
<br>
List non-blocking but important clarifications (e.g., ambiguous terminology=
 or<br>
incomplete examples).<br>
<br>
&gt; This document currently uses full terms and their abbreviations<br>
interchangeably (e.g., =E2=80=9CPost-Stack MPLS Header=E2=80=9D and =E2=80=
=9CPSMH=E2=80=9D). To avoid<br>
redundancy, it is recommended to adopt a single consistent form throughout,=
<br>
otherwise, defining the abbreviation is unnecessary.<br></blockquote><div><=
br></div><div>&lt;RG&gt; Fixed.</div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">
<br>
&gt; It is recommended to change the definition of IHS as below,<br>
<br>
=C2=A0 OLD:<br>
=C2=A0 =C2=A0 =C2=A0 IHS (2 Bits): The In-Stack NAS for each scope with the=
 P bit set<br>
=C2=A0 =C2=A0 =C2=A0 has a corresponding Post-Stack MPLS Header.<br>
<br>
=C2=A0 NEW:<br>
=C2=A0 =C2=A0 IHS (2 Bits): The scope of all the network actions for the In=
-Stack NAS<br>
=C2=A0 =C2=A0 with the P bit set.<br></blockquote><div><br></div><div>&lt;R=
G&gt; Updated as following:</div><div><br></div><div><i>=C2=A0 =C2=A0* =C2=
=A0IHS (2 Bit): The scope of all the NAIs encoded in the NAS as well<br>=C2=
=A0 =C2=A0 =C2=A0 as in the corresponding PSMH.</i><br><br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt; In section 3.1, the definition of the S flag should be relocated to pr=
ecede<br>
that of the U flag, and the text can be changed to &quot;Same to the defini=
tion of S<br>
flag in section 4.2 of [I-D.ietf-mpls-mna-hdr]&quot;<br></blockquote><div><=
br></div><div>&lt;RG&gt; Added as following:</div><div><br></div><div>=C2=
=A0 =C2=A0<i>The following fields are carried in an NAS as defined in<br>=
=C2=A0 =C2=A0[I-D.ietf-mpls-mna-hdr] and shown in Figure 1.=C2=A0</i></div>=
<div><i><br>=C2=A0 =C2=A0* =C2=A0S (1 Bit): The BoS.<br><br>=C2=A0 =C2=A0* =
=C2=A0NASL (4 Bits): The Network Action Sub-Stack Length.<br><br>=C2=A0 =C2=
=A0* =C2=A0NAL (3 Bits): The Network Action Length.</i></div><div><br></div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt; Regarding the title of section 3.2.1, since the struct in figure 2 con=
tains<br>
not only header type, but also PFN and PSMH-Len, it is more suitable to use=
<br>
&quot;Post-Stack MPLS Base Header&quot;, instead of &quot;Post-Stack MPLS H=
eader Type&quot;.<br></blockquote><div><br></div><div>&lt;RG&gt; Updated.</=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt;In section 3.2.3, I think the addreviation of &quot;PSMHT&quot; can be =
removed, too many<br>
abbreviations, particularly those without substantive meaning, do not<br>
contribute much to the draft.<br></blockquote><div><br></div><div>&lt;RG&gt=
; Removed PSMHT and replaced with Base.</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">
<br>
&gt;The title of section 4.1 can be simplified as,<br>
=C2=A0 =C2=A0 =C2=A0OLD:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In-Stack Network Action Opcode for PSMH =
Start Offset for MNA<br>
=C2=A0 =C2=A0 =C2=A0NEW:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Opcode for PSMH Start Offset for MNA<br>=
</blockquote><div><br></div><div>&lt;RG&gt; Updated to:</div><div><i>4.1.=
=C2=A0 Opcode for PSMH Start Offset</i><br><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">
<br>
&gt;The title of section 4.2 can be simplified as,<br>
=C2=A0 =C2=A0 OLD:<br>
=C2=A0 =C2=A0 =C2=A0 In-Stack Network Action Opcode for Offset of End of Po=
st-Stack MPLS<br>
=C2=A0 =C2=A0 =C2=A0 Header for MNA<br>
<br>
=C2=A0 =C2=A0 NEW:<br>
=C2=A0 =C2=A0 =C2=A0Opcode for Offset of End of Post-Stack MPLS Header for =
MNA<br></blockquote><div><br></div><div><br></div><div>&lt;RG&gt; Updated t=
o:</div><div><i>4.2.=C2=A0 Opcode for PSMH End Offset</i><br><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt; In section 5.3,=C2=A0 &quot;ingress node&quot; is used to refer to the=
 node that adds a<br>
Post-Stack MPLS Header, to avoid duplicative terms., it is suggested to cha=
nge<br>
it to &quot;Encapsulating node&quot; , and the terms of &quot;participating=
 node&quot; and &quot;egress<br>
node&quot; can be changed to &quot;encapsulating node&quot; and &quot;decap=
sulating node&quot;<br>
repectively.<br>
---<br></blockquote><div><br></div><div>&lt;RG&gt; Updated.</div><div><br><=
/div><div>Thanks,</div><div>Rakesh (for authors)</div><div><br></div><div><=
br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>
<br>
## Nits<br>
<br>
&gt; No Nits found.<br>
<br>
---<br>
<br>
Chongfeng Xie<br>
<br>
<br>
_______________________________________________<br>
mpls mailing list -- <a href=3D"mailto:mpls@ietf.org" target=3D"_blank">mpl=
s@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:mpls-leave@ietf.org" targ=
et=3D"_blank">mpls-leave@ietf.org</a><br>
</blockquote></div></div>
</div>

--000000000000a0b3f90654ee1e2f--