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

Dear Alvaro,Thank you very much for your review. We appreciate your feedback and will promptly address your comments and suggestions.Best regards, Weiqiang

---原始邮件---

 发件人: Alvaro Retana  <aretana.ietf@gmail.com>
 发送时间:  2024-02-08 03:18:26
 收件人:  "draft-ietf-spring-srv6-srh-compression@ietf.org" <draft-ietf-spring-srv6-srh-compression@ietf.org>
 抄送:  SPRING WG List  <spring@ietf.org>
"spring-chairs@ietf.org" <spring-chairs@ietf.org>
 主题: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

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]

_______________________________________________

spring mailing list

spring@ietf.org

https://www.ietf.org/mailman/listinfo/spring