[spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[Alvaro Retana <[e-mail]>]

Dear authors:

In parallel with the WGLC I have reviewed this document.  Thank you
for the work you've put into it so far.

I have several comments (in-line below) that I would like to see
addressed.  In general, I think my comments should be relatively easy
to address.  I want to highlight one point up-front:

Operational Considerations/Guidance

   Dhruv brought up [1] the point of providing "guidance on when to use
   which flavor and with which C-SID lengths".  I fully agree!  The
   document contains (mostly in §4) recommendations, for example, about
   LBL and C-SID lengths, even if any other value is possible.  IOW, the
   possibilities are endless!  Please provide more operational
   considerations on how an operator can evaluate their needs and select
   the appropriate flavor/value for their deployment.

   I included some in-line comments below.


Thanks!

Alvaro.


[1] https://mailarchive.ietf.org/arch/msg/spring/p3GGcuoqOjHaLjrJJaQpKzURTn0



[Line numbers from idnits]

...
142	1.  Introduction
...
160	   The flavors defined in this document leverage the SRv6 data plane
161	   defined in [RFC8754] and [RFC8986], and are compatible with the SRv6
162	   control plane extensions for IS-IS [RFC9352], OSPF [RFC9513], and BGP
163	   [RFC9252].

[minor] rfc9252 is about SRv6-based BGP services -- is it the best
(general) BGP reference to use at this point?



165	2.  Terminology
...
188	   *  C-SID sequence: A group of one or more consecutive segment list
189	      entries carrying the common Locator-Block and at least one C-SID
190	      container.

[minor] It seems to me that this definition is a little off -- looking
at it from the point of view of a "C-SID sequence" having to be a
sequence of C-SIDs, not a of segment list entries.

> Suggestion:

   *  C-SID sequence: A group of one or more consecutive C-SIDs sharing
      a common Locator-Block and at least one C-SID container.


192	   *  Uncompressed SID sequence: A group of one or more uncompressed
193	      SIDs in a segment list.

[minor] The definition of a "C-SID sequence" pointed at the fact that
a sequence is "consecutive".  Is that the case here too?



...
229	3.  Basic Concepts
...
246	   A segment list can be encoded in the packet header using any
247	   combination of compressed and uncompressed sequences.  The C-SID
248	   sequences leverage the flavors defined in this document, while the
249	   uncompressed sequences use behaviors and flavors defined in other
250	   documents, such as [RFC8986].  An SR source node constructs and
251	   compresses the SID-list depending on the capabilities of each SR
252	   segment endpoint node that the packet should traverse, as well as its
253	   own compression capabilities.

[minor] "An SR source node constructs and compresses the SID-list
depending on the capabilities of each SR segment endpoint node that
the packet should traverse..."

Which "capabilities of each SR segment endpoint node" are you
referring to?  How does the SR source node learn about them?  Later in
the text you talk about advertising the C-SIDs and the SRv6 SID
Structure, but those are not "node capabilities".



...
261	4.  SR Segment Endpoint Flavors
...
291	   The SIDs of both flavors can co-exist in the same SR domain, on the
292	   same SR segment endpoint node, and even in the same segment list.
293	   However, it is RECOMMENDED, for ease of operation, that a single
294	   compressed encoding flavor be used in a given routing domain.  In a
295	   multi-domain deployment, different flavors MAY be used in different
296	   routing domains of the SR domain.

[major] s/MAY/may

The fact that two flavors exist allows for different ones being used
in different routing domains.  IOW, the use of "MAY" doesn't add any
normative value.



...
311	4.1.  NEXT-C-SID Flavor

313	   A C-SID sequence using the NEXT-C-SID flavor comprises one or more
314	   C-SID containers.  Each C-SID container is a fully formed 128-bit
315	   SID.  It carries a Locator-Block followed by a series of C-SIDs.  The
316	   Locator-Node and Function of the C-SID container are those of the
317	   first C-SID, and its Argument is the contiguous series of subsequent
318	   C-SIDs.  The second C-SID is encoded in the most significant bits of
319	   the C-SID container Argument, the third C-SID is encoded in the bits
320	   of the Argument that immediately follow the second C-SID, and so on.
321	   When all C-SIDs have the same length, a C-SID container can carry up
322	   to K C-SIDs, where K is computed as floor((128-LBL)/LNFL).  Each
323	   C-SID container for NEXT-C-SID is independent, such that contiguous
324	   C-SID containers in a C-SID sequence can be considered as separate
325	   C-SID sequences.

[major] It should be specified that any remaining bits MUST be 0-padded.


[major] Please add a reference or explanation of the floor function.
I know it may be clear to many, but no assumptions should be made
about future readers.


327	   The last C-SID in the C-SID sequence is not required to have the
328	   NEXT-C-SID flavor.  It can be bound to any behavior and flavor(s),
329	   including the REPLACE-C-SID flavor, as long as it meets the
330	   conditions defined in Section 6.

[minor] Which conditions exactly?  Pointing to a specific part of §6 may help.

332	   The structure of a SID with the NEXT-C-SID flavor is shown in
333	   Figure 1.  The same structure is also that of a C-SID container
334	   carrying NEXT-C-SID SIDs.

[nit] It would be nice to point at Figure 1 earlier in this section.

[] I don't understand what the second sentence is trying to say.


336	   +------------------------------------------------------------------+
337	   |     Locator-Block      |Loc-Node|            Argument            |
338	   |                        |Function|                                |
339	   +------------------------------------------------------------------+
340	    <-------- LBL ---------> < LNFL > <------------- AL ------------->

342	        Figure 1: Structure of a NEXT-C-SID flavor SID (scaled for a
343	     48-bit Locator- Block, 16-bit combined Locator-Node and Function,
344	                            and 64-bit Argument)

346	   An implementation SHOULD support a 32-bit Locator-Block length (LBL)
347	   and a 16-bit C-SID length (LNFL) for NEXT-C-SID flavor SIDs, and MAY
348	   support any other Locator-Block and C-SID length.  A deployment
349	   SHOULD use a consistent Locator-Block length and C-SID length for all
350	   SIDs of the SR domain.

[major] "SHOULD support a 32-bit Locator-Block length (LBL) and a
16-bit C-SID length (LNFL) for NEXT-C-SID flavor SIDs, and MAY support
any other Locator-Block and C-SID length"

What are you trying to specify here?

By only recommending the LBL/LNFL lengths, there is no requirement
that implementations will support that.  IOW, if you're trying to
define a mandatory-to-implement minimum, then s/SHOULD/MUST

The "MAY" has no normative value: s/MAY/may


[major] "SHOULD use a consistent Locator-Block length and C-SID length
for all SIDs of the SR domain"

When is it ok to not be consistent?  IOW, why is this recommended and
not required?  What are the effects of not being consistent?



...
355	   When processing an IPv6 packet that matches a FIB entry locally
356	   instantiated as a SID with the NEXT-C-SID flavor, the SR segment
357	   endpoint node applies the procedure specified in the one following
358	   subsection that corresponds to the SID behavior.  If the SID also has
359	   the PSP, USP, or USD flavor, the procedure is modified as described
360	   in Section 4.1.7.

[nit] s/in the one following subsection/in the following subsection


362	   An SR segment endpoint node instantiating a SID with the NEXT-C-SID
363	   flavor MUST accept any Argument value for that SID.

[major] Does this also mean that any future behavior cannot make use
of an Argument?  IOW, behaviors like End.DT2M cannot be used with the
NEXT-C-SID flavor.  If so, please be explicit about it.



...
377	4.1.1.  End with NEXT-C-SID
...
384	   The below pseudocode is inserted between lines S01 and S02 of the SRH
385	   processing in Section 4.1 of [RFC8986].  In addition, this pseudocode
386	   is executed before processing any extension header that is not an
387	   SRH, a Hop-by-Hop header or a Destination Option header, or before
388	   processing the upper-layer header, whichever comes first.

[major] "In addition..."

This sentence is not needed because S01 says "When an SRH is
processed", so we're already processing the SRH.  Also, this sentence
is paraphrasing the ordering in §4/rfc8200 -- which makes it
unnecessary as the behavior is already specified elsewhere.

Furthermore, Appendix A.1 shows the pseudocode being executed "before
processing the upper-layer header".  However, that upper-layer header
would only be processed *after* the SRH is processed (rfc8200) -- so
doing it again is unnecessary.

Please remove both the sentence above and the extra step in A.1
*before* the upper-layer header.

** Note that other descriptions in this section also contain the same
text and should be modified in the same way (including the
appendices).


390	   N01. If (DA.Argument != 0) {
391	   N02.   If (IPv6 Hop Limit <= 1) {
392	   N03.     Send an ICMP Time Exceeded message to the Source Address,
393	              Code 0 (Hop limit exceeded in transit),
394	              interrupt packet processing and discard the packet.
395	   N04.   }

[major] Why are the other checks not done?  For example, why are SL
not checked?  I understand that if the previous node didn't change it
then it should be ok -- but it may not!



...
400	   N07.   Decrement Hop Limit by 1.

[nit] s/Decrement Hop Limit by 1/Decrement IPv6 Hop Limit by 1



...
547	4.2.  REPLACE-C-SID Flavor
...
597	   The RECOMMENDED Locator-Block lengths (LBL) for REPLACE-C-SID flavor
598	   SIDs are 48, 56, 64, 72, or 80 bits, depending on the needs of the
599	   operator.

601	   The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths
602	   (LNFL).  A C-SID length of 32-bit is RECOMMENDED.

604	   Any other Locator-Block and C-SID length selection is possible, but
605	   may lead to suboptimal C-SID encoding in the C-SID containers (e.g.,
606	   presence of padding bits).

[major] The first two of the three paragraphs above suggest the use of
specific values, but it is not until the third paragraph that the
reasons become clear -- and it is clarified that any length selection
is possible.  This makes the initial paragraphs a little misleading
because it gives the impression that only specific lengths are
supported.

> Suggestion:

   The REPLACE-C-SID flavor supports any Locator-Block and C-SID
   length selection.  LBL values of 48, 56, 64, 72, or 80 bits,
   and C-SID lengths of 16- or 32-bits are RECOMMENDED to avoid
   suboptimal C-SID encoding in the C-SID containers (e.g.,
   presence of padding bits).


Open questions: How does an operator select the best LBL according to
its needs?  I imagine that the LBL selection is global (or at least
per routing domain or SR domain??) -- how are the nodes made aware of
the LBL used/selected?

How do the nodes in the network know which C-SID length is in use?  Is
there a consistency recommendation when using the REPLACE-C-SID
flavor?



608	   The Argument length (AL) for REPLACE-C-SID flavor SIDs is equal to
609	   128-LBL-LNFL.  The index value is encoded in the least significant X
610	   bits of the Argument, where X is computed as ceil(log_2(128/LNFL)).

[major] Please add a reference or explanation of the ceil function.  I
know it may be clear to many, but no assumptions should be made about
future readers.


[major] Part of the guidance above about how to chose the LBL and
C-SID length should include leaving enough bits in AL to encode the
index.  There are many cases, but a simple one is using an LBL of 96
and a 32-bit C-SID length, which leaves no room for the index.



...
642	4.2.1.  End with REPLACE-C-SID
...
652	   S02.   If (Segments Left == 0 and (DA.Arg.Index == 0 or
653	              Segment List[0][DA.Arg.Index-1] == 0)) {

[?] I don't understand why "DA.Arg.Index-1" (the "-1" part) is used.
If DA.Arg.Index points at the bits containing the index, what does
DA.Arg.Index-1 point to?



...
657	   R01. If (DA.Arg.Index != 0) {
658	   R02.   If ((Last Entry > max_LE) or (Segments Left > Last Entry)) {

[?] Should "Segments Left > Last Entry" be "Segments Left > Last Entry+1"?



...
823	4.2.7.  End.DX and End.DT with REPLACE-C-SID
...
831	   These SIDs differ from those defined in [RFC8986] by the presence of
832	   an Argument as part of the SID structure.  The Argument value is
833	   effectively ignored by the SR segment endpoint node.

[minor] s/value is effectively ignored/value is ignored



...
840	   The SR segment endpoint node obtains the value Arg.FE2 from the 16
841	   most significant bits of DA.Argument if DA.Arg.Index is zero, or from
842	   the 16 least significant bits of the next position in the current
843	   C-SID container (Segment List[Segments Left][DA.Arg.Index-1])
844	   otherwise (DA.Arg.Index is non-zero).

[?] Where does the 16-bit value come from?  rfc8986 doesn't specify
the size of Arg.FE2, and the related applications don't seem to match
in length.  What am I missing?



...
869	5.  C-SID Allocation
...
874	   In order to efficiently manage the C-SID numbering space, a
875	   deployment MAY divide it into two non-overlapping sub-spaces: a
876	   Global Identifiers Block (GIB) and a Local Identifiers Block (LIB).

[major] There's no normative value in "MAY": s/MAY/may



...
920	5.3.  GIB/LIB Usage
...
926	   The GIB number space is shared among all SR segment endpoint nodes
927	   using SRv6 locators under a Block space.  The more SIDs assigned from
928	   this space, per node, the faster it is exhausted.  Therefore its use
929	   is prioritized for global segments, such as SIDs that identify a
930	   node.

[nit] s/a Block space/a Locator-Block space



...
942	   Given the previous Locator-Block and C-SID length recommendations,
943	   the following GIB/LIB usage is RECOMMENDED:

[] s/RECOMMENDED/recommended



...
963	5.4.  Recommended Installation of C-SIDs in FIB

965	   An SR segment endpoint node instantiating a NEXT-C-SID or REPLACE-
966	   C-SID flavor SID SHOULD install the corresponding FIB entry to match
967	   only the Locator and Function parts of the SID (i.e., with a prefix
968	   length of LBL + LNL + FL).  Any other mean of identifying a locally
969	   instantiated SID is possible as long as it is compliant with
970	   Section 4.3 of [RFC8754] and accepts all valid Argument values for
971	   the SID.

[major] §4.3/rfc8754 doesn't use normative language.  It uses a
general statement that allows for different implementations:

   Without constraining the details of an implementation, the SR segment
   endpoint node creates Forwarding Information Base (FIB) entries for its
   local SIDs.

It seems to me that rfc8754 already covers what wants to be conveyed
in this document: the FIB entry has to uniquely identify the segment
endpoint.

As written, the text raises several questions:

When is it ok to not "install the corresponding FIB entry to match
only the Locator and Function parts of the SID"?  IOW, why is this
action recommended and not required?  Note that the entry has to at
least cover "a prefix length of LBL + LNL + FL".

The other means refer to §4.3/rfc8754, which (as shown above) says
that anything (including "install the corresponding FIB entry to match
only the Locator and Function parts of the SID") is ok.  This takes us
back to my original point: rfc8754 already covers what this section
wants to convey and it is not needed.

"all valid Argument values" -- most of the SIDs used don't use an
Argument, so which are the "valid Argument values"?   s/all valid
Argument values/any Argument value



973	   In addition, an SR segment endpoint node instantiating NEXT-C-SID
974	   flavor SIDs from both GIB and LIB MAY install combined "Global +
975	   Local" FIB entries to match a sequence of global and local C-SIDs in
976	   a single LPM lookup.

[major] The GIB/LIB constructs are not visible to the FIB, and there's
no requirement that one or the other, or both, be installed in it.
IOW, the "MAY" lacks any normative value.  s/MAY/may


[minor] Please expand LPM.



...
1080	6.2.  Segment List Compression
...
1086	   It is out of the scope of this document to describe the mechanism
1087	   through which an uncompressed segment list is derived.  As a general
1088	   guidance for implementation or future specification, such a mechanism
1089	   should aim to select the combination of SIDs that would result in the
1090	   shortest compressed segment list.  For example, by selecting a C-SID
1091	   flavor SID over an equivalent non-C-SID flavor SID or by consistently
1092	   selecting SIDs of the same C-SID flavor within each routing domain.

[minor] This paragraph is a little confusing.  It starts by saying
that "It is out of the scope of this document to describe the
mechanism through which an uncompressed segment list is derived."
While that is true, isn't an uncompressed segment list "normal
operation"?  IOW, it is out of scope but also already defined
elsewhere, right?

§8 says that "the controller provides the ordered segment list
comprising the uncompressed SIDs" and that "a node that does not
support this specification...handles it as described in the
corresponding control plane specification..."  I interpret this as
meaning that there's no change.

Am I missing something?

The text then goes on to talk about "the shortest compressed segment list"...


1094	   The segment list that the SR source node pushes onto the packet MUST
1095	   comply with the rules in Section 6.3 and Section 6.4 and result in a
1096	   path equivalent to the original segment list.

[major] "MUST...result in a path equivalent to the original segment list"

How is a "path equivalent to the original" defined?  The next
paragraph mentions "a compressed segment list of equal or shorter
length than the uncompressed segment list".  What does the length
refer to -- the number of Segment Lists in the SRH, the size of the
SRH, or something else?


1098	   If an SR source node chooses to compress the segment list, one method
1099	   is described below for illustrative purposes.  Any other method
1100	   producing a compressed segment list of equal or shorter length than
1101	   the uncompressed segment list is compliant.



...
1107	   *  When the compression method encounters a series of one or more
1108	      consecutive compressible NEXT-C-SID flavor SIDs, it compresses the
1109	      series as follows.  A SID with the NEXT-C-SID flavor is
1110	      compressible if its structure is known to the SR source node and
1111	      its Argument value is 0.

[major] Unlike the REPLACE-C-SID flavor (below), there's no check
equivalent to ConCheck for the NEXT-C-SID flavor SIDs.  Why isn't that
needed?



...
1183	      |  Note: When the last C-SID is an End.DT2M SID with the REPLACE-
1184	      |  C-SID flavor, if there is 0 or at least two C-SID positions
1185	      |  left in the current C-SID container, the C-SID is encoded as
1186	      |  described above and the value of the Arg.FE2 argument is placed
1187	      |  in the 16 least significant bits of the next C-SID position.
1188	      |  Otherwise (if there is only one C-SID position left in the
1189	      |  current C-SID container), the current C-SID container is pushed
1190	      |  onto the segment list (the value of the C-SID position 0
1191	      |  remains zero) and the End.DT2M SID with the REPLACE-C-SID
1192	      |  flavor is encoded in full SID format with the value of the
1193	      |  Arg.FE2 argument in the 16 most significant bits of the SID
1194	      |  Argument.

[minor] "if there is 0 or at least two C-SID positions left"

0?


1196	   *  In all remaining cases (i.e., when the compression method
1197	      encounters a SID in the uncompressed segment list that is not
1198	      handled by any of the previous subroutines), it pushes this SID as
1199	      is onto the compressed segment list.

[major] "In all remaining cases...pushes this SID as is onto the
compressed segment list."

One of these cases is a SID that is not a C-SID, or one without the
structure information, etc.  Why would these be put "onto the
compressed segment list"?


1201	   Regardless of how a compressed segment list is produced, the SR
1202	   source node writes it in the IPv6 packet as described in Section 4.1
1203	   of [RFC8754].  The text is reproduced below for reference.

1205	   |  A source node steers a packet into an SR Policy.  If the SR Policy
1206	   |  results in a Segment List containing a single segment, and there
1207	   |  is no need to add information to the SRH flag or add TLV; the DA
1208	   |  is set to the single Segment List entry, and the SRH MAY be
1209	   |  omitted.
1210	   |
1211	   |  When needed, the SRH is created as follows:
1212	   |
1213	   |  The Next Header and Hdr Ext Len fields are set as specified in
1214	   |  [RFC8200].
1215	   |
1216	   |  The Routing Type field is set to 4.
1217	   |
1218	   |  The DA of the packet is set with the value of the first segment.
1219	   |
1220	   |  The first element of the SRH Segment List is the ultimate segment.
1221	   |  The second element is the penultimate segment, and so on.
1222	   |
1223	   |  The Segments Left field is set to n-1, where n is the number of
1224	   |  elements in the SR Policy.
1225	   |
1226	   |  The Last Entry field is set to n-1, where n is the number of
1227	   |  elements in the SR Policy.
1228	   |
1229	   |  TLVs (including HMAC) may be set according to their specification.
1230	   |
1231	   |  The packet is forwarded toward the packet's Destination Address
1232	   |  (the first segment).
1233	   |
1234	   |  When a source does not require the entire SID list to be preserved
1235	   |  in the SRH, a reduced SRH may be used.
1236	   |
1237	   |  A reduced SRH does not contain the first segment of the related SR
1238	   |  Policy (the first segment is the one already in the DA of the IPv6
1239	   |  header), and the Last Entry field is set to n-2, where n is the
1240	   |  number of elements in the SR Policy.

[nit] The last two paragraphs belong to §4.1.1/rfc8754, and not
"Section 4.1 of [RFC8754]" as mentioned above.


1242	6.3.  Rules for segment lists containing NEXT-C-SID flavor SIDs

1244	   1.  If a Destination Option header would follow an SRH with a segment
1245	       list of more than one segment compressed as a single NEXT-C-SID
1246	       container, the SR source node MUST NOT omit the SRH.

1248	   2.  When the last Segment List entry (index 0) in the SRH is a C-SID
1249	       container representing more than one segment, the PSP operation
1250	       is performed at the segment preceding the first segment of this
1251	       C-SID container in the segment list.  If the PSP behavior should
1252	       instead be performed at the penultimate segment along the path,
1253	       the SR source node MUST NOT compress the ultimate segment of the
1254	       segment list into a C-SID container.

1256	   3.  If a Destination Option header would follow an SRH with a last
1257	       Segment List entry being a NEXT-C-SID container representing more
1258	       than one segment, the SR source node MUST ensure that the PSP
1259	       operation is not performed before the penultimate SR segment
1260	       endpoint node along the path.

1262	6.4.  Rules for segment lists containing REPLACE-C-SID flavor SIDs

1264	   1.  All SIDs compressed in a REPLACE-C-SID sequence MUST share the
1265	       same Locator-Block and the same compression scheme.

1267	   2.  All SIDs except the last one in a C-SID sequence for REPLACE-
1268	       C-SID MUST have the REPLACE-C-SID flavor.  If the last C-SID
1269	       container is fully filled (i.e., the last C-SID is at position 0
1270	       in the C-SID container) and the last SID in the C-SID sequence is
1271	       not the last segment in the segment list, the last SID in the
1272	       C-SID sequence MUST NOT have the REPLACE-C-SID flavor.

1274	   3.  When a REPLACE-C-SID flavor C-SID is present as the last SID in a
1275	       container that is not the last Segment List entry (index 0) in
1276	       the SRH, the next element in the segment list MUST be a REPLACE-
1277	       C-SID container in packed format carrying at least one C-SID.

[major] Are these requirements validated at any point?  For example,
if rule #3 is not implemented and the next Segment List is not "a
REPLACE-C-SID container in packed format".  Which node enforces the
fact that the specification is not followed?  It seems to me that the
only node in that position would be the one represented by the that
last SID.  Can any action be taken?  What is the impact?



...
1282	   When receiving a SID advertisement for a REPLACE-C-SID flavor SID
1283	   with LNL=16, FL=0, AL=128-LBL-NL-FL, and the value of the Argument is
1284	   all 0, the SR source node marks both the SID and its locator as using
1285	   16-bit compression.  All other SIDs allocated from this locator with
1286	   LNL=16, FL=16, AL=128-LBL-NL-FL, and the value of the Argument is all
1287	   0 are also marked as using 16-bit compression.  When receiving a SID
1288	   advertisement for a REPLACE-C-SID flavor SID with LNFL=32, AL=128-
1289	   LBL-NL-FL, and the value of the Argument is all 0, the SR source node
1290	   marks both the SID and its locator as using 32-bit compression.

[] "All other SIDs allocated from this locator with LNL=16, FL=16,
AL=128-LBL-NL-FL..."

Shouldn't this be "LNL=16, FL=0, AL=128-LBL-NL-FL"?


1292	6.5.  Upper-Layer Checksums
...
1297	   At the originating node, that address will be the Destination Address
1298	   as it is expected to be received by the ultimate destination.  When
1299	   the last element in the compressed segment list is a C-SID container,
1300	   this address can be obtained from the last element in the
1301	   uncompressed segment list or by repeatedly applying the segment
1302	   behavior as described in Section 9.2.  This applies regardless of
1303	   whether an SRH in present in the IPv6 packet or omitted.

[nit] s/SRH in present/SRH is present



...
1330	7.1.  End.PS: Prefix Swap
...
1340	   Each instance of an End.PS SID is associated with a target Locator-
1341	   Block B2/m.  The target Locator-Block is a local property of the
1342	   End.PS SID on the SR segment endpoint node.

[minor] Please explain what "Locator-Block B2/m" means.



...
1353	   The means by which an SR source node learns the target Locator-Block
1354	   associated with an End.PS SID are outside the scope of this document.
1355	   As examples, it could be learnt via configuration or using a
1356	   signaling protocol.

[?] Is there any work in progress to get this going?



...
1384	7.2.  End.XPS: L3 Cross-Connect and Prefix Swap
...
1400	   The means by which an SR source node learns the target Locator-Block
1401	   associated with an End.XPS SID are outside the scope of this
1402	   document.  As examples, it could be learnt via configuration or using
1403	   a signaling protocol.

[?] Is there any work in progress to get this going?



...
1433	8.  Control Plane
...
1447	   *  BGP [RFC9252], [RFC9514],
1448	      [I-D.ietf-idr-segment-routing-te-policy],
1449	      [I-D.ietf-idr-bgp-ls-sr-policy]

[nit] It might be useful to separate BGP from BGP-LS.



...
1458	   Signaling the SRv6 SID Structure is REQUIRED for all the SIDs
1459	   introduced in this document.  It is used by an SR source node to
1460	   compress a segment list as described in Section 6.  The node
1461	   initiating the SID advertisement MUST set the length values in the
1462	   SRv6 SID Structure to match the format of the SID on the SR segment
1463	   endpoint node.  For example, for a SID of this document instantiated
1464	   from a /48 SRv6 SID block and a /64 Locator, and having a 16-bit
1465	   Function, the SRv6 SID Structure advertisement carries the following
1466	   values.

[major] "Signaling the SRv6 SID Structure is REQUIRED..."

The SRv6 SID Structure TLVs are optional in rfc9352, rfc9513, rfc9514,
I-D.ietf-pce-segment-routing-ipv6, and
I-D.ietf-idr-segment-routing-te-policy.  Even if this document
requires the information to be advertised, the control protocols
don't.  What should the SR Source Node do if the SRv6 SID Structure is
not present?

Given that the SRv6 SID Structure TLVs are optional, a rogue node can
decide to not advertise the information -- the result would probably
be that SIDs would not be available to construct all the paths that
may be required, which may result in suboptimal routing, or even the
inability to construct paths to specific destinations.  Please include
something about this threat in the Security Considerations.


[major] "...the SRv6 SID Structure is REQUIRED for all the SIDs
introduced in this document."

This document defines, for example, the End.T behavior for both C-SID
flavors.  However, rfc9352, rfc9513, and rfc9514 don't define the
advertisement of End.T.  To illustrate, rfc9352 says this:

   9. SRv6 SID Structure Sub-Sub-TLV

     The SRv6 SID Structure sub-sub-TLV is an optional sub-sub-TLV of:

     *  SRv6 End SID sub-TLV (Section 7.2)

     *  SRv6 End.X SID sub-TLV (Section 8.1)

     *  SRv6 LAN End.X SID sub-TLV (Section 8.2)
     ...

No mention of End.T, or other behaviors mentioned in this document.

Also, from §7.2:

   Supported behavior values, together with parent TLVs in which they
   are advertised, are specified in Section 10 of this document. Please
   note that not all behaviors defined in [RFC8986] are defined in this
   document, e.g., End.T is not.


The above means that the requirement to advertise the SRv6 SID
Structure "for all the SIDs introduced in this document" can't be met
because the control plane protocols don't currently have the ability
to signal all the behaviors or because the SRv6 SID Structure is not a
valid option for them.

While I don't think this issue is a showstopper for this document, I'm
curious about the plan to extend/update the existing specifications.
Note that the implementations in §10 give the impression that no
exceptions exist -- of course, it is possible that other mechanisms
(manual configuration, for example) are used.  I am also curious about
any manageability-related plans to enhance YANG models.



...
1476	   A local C-SID MAY be advertised in the control plane individually
1477	   and/or in combination with a global C-SID instantiated on the same SR
1478	   segment endpoint node, with the End behavior, and the same Locator-
1479	   Block and flavor as the local C-SID.  A combined global and local
1480	   C-SID is advertised as follows.

[major] The use of local/global spaces is not visible to the control
plane, so the "MAY" doesn't have normative value.  s/MAY/may



...
1976	13.1.  SRv6 Endpoint Behaviors

1978	   This I-D. requests the IANA to update the reference of the following
1979	   registrations from the "SRv6 Endpoint Behaviors" registry under the
1980	   top-level "Segment Routing" registry-group
1981	   (https://www.iana.org/assignments/segment-routing/) with the RFC
1982	   number of this document once it is published, and transfer change
1983	   control to the IETF.

[major] you also need to ask for the assignment of the TBA values.

...
2113	      +-------+-----------------------------------------+-----------+
2114	      | TBA   | End.PS with NEXT-CSID                   | This I-D. |
2115	      +-------+-----------------------------------------+-----------+
2116	      | TBA   | End.PS with REPLACE-CSID                | This I-D. |
2117	      +-------+-----------------------------------------+-----------+
2118	      | TBA   | End.XPS with NEXT-CSID                  | This I-D. |
2119	      +-------+-----------------------------------------+-----------+
2120	      | TBA   | End.XPS with REPLACE-CSID               | This I-D. |
2121	      +-------+-----------------------------------------+-----------+



...
2136	15.1.  Normative References
...
2173	   [RFC9259]  Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M.
2174	              Chen, "Operations, Administration, and Maintenance (OAM)
2175	              in Segment Routing over IPv6 (SRv6)", RFC 9259,
2176	              DOI 10.17487/RFC9259, June 2022,
2177	              <https://www.rfc-editor.org/info/rfc9259>.

[minor] This reference can be Informative.


2179	   [RFC9350]  Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
2180	              and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
2181	              DOI 10.17487/RFC9350, February 2023,
2182	              <https://www.rfc-editor.org/info/rfc9350>.

[minor] This reference can be Informative.

[EoR -11]