MIME-Version: 1.0
From: Tony Przygienda <tonysietf@gmail.com>
Date: Fri, 3 Jul 2026 16:23:06 +0200
Message-ID: 
 <CA+wi2hN6JjSTHomu82OQQHeO7PMG7sJ9Bt7K20dvi4uYT783dQ@mail.gmail.com>
To: rtg-dir@ietf.org, draft-ietf-mpls-mna-ps-hdr@ietf.org, mpls@ietf.org
Content-Type: multipart/alternative; boundary="000000000000fdc5570655b5ab7d"
Message-ID-Hash: OAO56KUZCDKLDJ5XWL6IFAMGVZP52J5S
Precedence: list
Subject: =?utf-8?q?=5Bmpls=5D_RtgDir_review=3A_draft-ietf-mpls-mna-ps-hdr-08?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/mpls/oSgrG2rVc6fJvz7C5L2rlR0GmKg>

--000000000000fdc5570655b5ab7d
Content-Type: text/plain; charset="UTF-8"

I have been selected as the Routing Directorate reviewer for this draft.

Document:  draft-ietf-mpls-mna-ps-hdr-08
Reviewer: Tony Przygienda
Intended Status: Standards Track

Summary:

I do think the document needs to clarify how it would work with multicast
and specifically BIER before it can be progressed, especially on standards
track.

Comments:

Major Issues:

    - I struggle to understand how post stack data will work with deployed
RFC8296 which mandates S bit being set to BoS which would make 2 labels
having S set
      which AFAIS has no valid semantics. Even if we could somehow assume
that it's possible I don't see how a reasonable offset can be chosen
      for the post stack data. It cannot be in front of the BIER label
since BIER label is in the case of MPLS a label with S set itself.
      It cannot follow the BIER label since a reserved NIBBLE is expected
after BIER label.
      Then, BIER itself indicates the carried PROTO
      which can be MPLS again so if the intention is to carry it after
whatever BIER carries (which may be MPLS with post stack data again) it
would
      mandate parsing of post stack possibly at 9K+ boundaries which seems
infeasible in any reasonable silicon. I didn't analyze any further use
      cases but it seems to me that anything that can encapsulate a further
frame behind a BoS label
      will push the post stack data very far back into the stack (assuming
the two BoS problem can be architecturally resolved at all).

    - The draft does not explain any of the implications of multicast but
neither does mna-hdr so it is unclear whether in case of a label
      triggering multicast replication it is expected that it's BoS and
hence stack before it (plus any data is discarded) or in case of
      multicast label producing multiple copies with a stack behind it the
data is supposed to be preserved.

  - I omit further comments where the document contradicts IMO other drafts
progressing on standards track since they seem to have undergo
    discussions on the list already

--- tony

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

<div dir=3D"ltr"><div>I have been selected as the Routing Directorate revie=
wer for this draft.=C2=A0</div><div><br></div><div>Document: =C2=A0draft-ie=
tf-mpls-mna-ps-hdr-08</div>Reviewer: Tony Przygienda<br>Intended Status: St=
andards Track<br><br>Summary:<br><br>I
 do think the document needs to clarify how it would work with multicast
 and specifically BIER before it can be progressed, especially on=20
standards track.=C2=A0=C2=A0<br><br>Comments:<br><br>Major Issues:<br>=C2=
=A0<br>=C2=A0 =C2=A0 - I=20
struggle to understand how post stack data will work with deployed=20
RFC8296 which mandates S bit being set to BoS which would make 2 labels=20
having S set<br>=C2=A0 =C2=A0 =C2=A0 which AFAIS has no valid semantics. Ev=
en if we=20
could somehow assume that it&#39;s possible I don&#39;t see how a reasonabl=
e=20
offset can be chosen <br>=C2=A0 =C2=A0 =C2=A0 for the post stack data. It c=
annot be in=20
front of the BIER label since BIER label is in the case of MPLS a label wit=
h
 S set itself. <br>=C2=A0 =C2=A0 =C2=A0 It cannot follow the BIER label sin=
ce a reserved NIBBLE is expected after BIER label.<br>=C2=A0 =C2=A0 =C2=A0 =
Then, BIER itself indicates the carried PROTO <br>=C2=A0
 =C2=A0 =C2=A0 which can be MPLS again so if the intention is to carry it a=
fter=20
whatever BIER carries (which may be MPLS with post stack data again) it=20
would <br>=C2=A0 =C2=A0 =C2=A0 mandate parsing of post stack possibly at 9K=
+ boundaries
 which seems infeasible in any reasonable silicon. I didn&#39;t analyze any=
=20
further use <br>=C2=A0 =C2=A0 =C2=A0 cases but it seems to me that anything=
 that can encapsulate a further frame behind a BoS label <br><div>=C2=A0
 =C2=A0 =C2=A0 will push the post stack data very far back into the stack=
=20
(assuming the two BoS problem can be architecturally resolved at all).</div=
><div><br></div>=C2=A0 =C2=A0 -
 The draft does not explain any of the implications of multicast but=20
neither does mna-hdr so it is unclear whether in case of a label <br>=C2=A0=
 =C2=A0
 =C2=A0 triggering multicast replication it is expected that it&#39;s BoS a=
nd=20
hence stack before it (plus any data is discarded) or in case of <br><div>=
=C2=A0 =C2=A0 =C2=A0 multicast label producing multiple copies with a stack=
 behind it the data is supposed to be preserved.</div><div><br></div><div>=
=C2=A0 - I omit further comments where the document contradicts IMO other d=
rafts progressing on standards track since they seem to have undergo=C2=A0<=
/div><div>=C2=A0 =C2=A0 discussions on the list already=C2=A0</div><div><br=
></div><div>--- tony=C2=A0</div></div>

--000000000000fdc5570655b5ab7d--