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

[Andrew Alston - IETF <[e-mail]>]

I Think that’s a very solid idea.

What that means is that in the absence of an SRH when using a compressed SID – we apply an HBH with the final destination in it.  While this technically will not solve the violation of 8200 – since 8200 explicitly states “If the Ipv6 packet contains a Routing header, the destination address used in the pseudo-header is that of the final destination” – it does solve the checksum issue with an easy path to resolution, and it would also make for a very simple update to 8200 so we wouldn’t have to debate about the text of said update.

Thanks

Andrew




Internal All Employees

From: Ron Bonica <rbonica=[e-mail]>
Date: Monday, 25 March 2024 at 15:33
To: Andrew Alston - IETF <[e-mail]>, [e-mail] <[e-mail]>, Tom Herbert <[e-mail]>
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
Andrew,

Tom Herbert (copied on this message)  raised the same issue regarding another draft on the 6man mailing list a few months ago. I suggested that if this problem ever needed to be solved, it could be solved with a new Hob-by-hop option. This option would contain the IPv6 address of the ultimate destination, so the checksum could be calculated in flight.

The beauty of this option is that it can be included, when needed and excluded, when not needed.

It may be time to specify the new option. What do you think?

                                                                                            Ron


Juniper Business Use Only


Internal All Employees

________________________________
From: spring <[e-mail]> on behalf of Andrew Alston - IETF <andrew-ietf=[e-mail]>
Sent: Monday, March 25, 2024 8:05 AM
To: [e-mail] <[e-mail]>
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

[External Email. Be cautious of content]


So I’ve given a lot of thought to the checksum issue – and here is where my thinking is currently sitting.



Firstly – RFC8200 does not mention the word middlebox or middleware anywhere.  Nor does RFC8200 specify anywhere that the checksum should not be verifable in flight.



Indeed, section 8.1 actually details how to handle extension headers as well – in order to make the checksum valid (Last paragraph page 27)



Now, while there are specific uses cases for in flight validation of checksums which I’m not at liberty to discuss here, surfice to say that they exist and stem from the need to verify that packet changes aren’t occuring in flight – I believe that’s kinda besides the point.  The point here is that as it stands, the draft violates RFC8200.  This leaves two options in my view a.) Either update 8200 – with the agreement of 6man – or pass an RFC8200 BIS through 6man.



Either way – if you are violating a standard held by another working group – and this does violate section 8.1 – you should be updating the standard that is being violated or alternatively BIS’ing it to avoid the violation.   But both require that 6man is in full agreement, since SPRING is not chartered to make updates or violate standards put forward by another working group.  Hence – my suggestion would be to take this to 6man and go through the process, though at minimum I fail to see how this cannot update RFC8200.



In fact, let me be clear here – any attempt to pass this document WITHOUT correct review by 6man will result in an appeal.



Thanks



Andrew







Internal All Employees
From: spring <[e-mail]> on behalf of Francois Clad <[e-mail]>
Date: Monday, 18 March 2024 at 17:50
To: Alvaro Retana <[e-mail]>
Cc: SPRING WG List <[e-mail]>
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Some people who received this message don't often get email from [e-mail]. Learn why this is important<https://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!NEt6yMaO-gk!HRpiQWU2pUWihCzpYT-zhnqmYyOb_iF_IIRZXx6AIXfOS90KBBq-2eWcXLMj5bZ1-KrV-coZZLQWNsXNpLFMYETMlX2PtX8$>

CAUTION: This email has originated from a free email service commonly used for personal email services, please be guided accordingly especially if this email is asking to click links or share information.



Dear Alvaro,



We have integrated the remainder of your feedback in revision -14.



Detailed replies inline. These include your follow-up comments as well as the review items that we missed in the first pass.



Please let us know if you have any further feedback.



Thanks,

Francois



> ...

> > > 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.

> >

> > We added a paragraph providing such operational guidance in revision -12, and

> > further clarified it in revision -13.

> >

> > | SRv6 is intended for use in a variety of networks that require

> > | different prefix lengths and SID numbering spaces. Each of the two

> > | flavors introduced in this document comes with its own

> > | recommendations for Locator-Block and C-SID length, as specified in

> > | Section 4.1 and Section 4.2. These flavors are best suited for

> > | different environments, depending on the requirements of the network.

> > | For instance, larger C-SID lengths may be more suitable for networks

> > | requiring ample SID numbering space, while smaller C-SID lengths are

> > | better for compression efficiency. The two compression flavors allow

> > | the compressed segment list encoding to adapt to a range of

> > | requirements, with support for multiple compression levels. Network

> > | operators can choose the flavor that best suits their use case,

> > | deployment design, and network scale.

>

> I don't consider this paragraph enough.  I understand that "different

> environments, depending on the requirements of the network" *may*

> result in a different choice.  I want to understand how "operators can

> choose the flavor that best suits their use case, deployment design,

> and network scale."

>

> Let me illustrate with an example.  The text above says that "larger

> C-SID lengths may be more suitable for networks requiring ample SID

> numbering space, while smaller C-SID lengths are better for

> compression efficiency".  Ok, what are my choices?

>

>    §4.1: "An implementation MUST support...a 16-bit C-SID length (LNFL) for

>           NEXT-C-SID flavor SIDs, and may support any other...C-SID length."

>

>    §4.2: "This document defines the REPLACE-C-SID flavor for 16-bit and 32-bit

>           C-SID lengths (LNFL). An implementation MUST support a 32-bit C-SID

>           length for REPLACE-C-SID flavor SIDs."

>

> Judging from the *required* implementations, it looks like if an

> operator wants a C-SID length that is "better for compression

> efficiency" then it should use the NEXT-C-SID flavor (because 16-bit

> may only be supported there).



We need some agreement for interoperability so that all implementers support at least one common C-SID length for each of the flavors. For this, the length that is most efficient and suitable has been picked for each flavor. That's it; nothing more. At least that's the intention here.



> However, if we assume that vendors will offer other options, for

> example 16-bit C-SIDs for the REPLACE-C-SID flavor, what next?  Which

> C-SID should I chose?

>

> I know that this document is not a deployment guide and that it cannot

> cover all cases.  But the current guidance is basically non-existent

> given the large amount of choice.



There are likely to various other considerations besides the C-SID lengths. They may be a mix of technical and/or non-technical. Perhaps the SRv6 Ops forum will produce some deployment and operational guidelines for the technical aspects. It is not in the scope of this document to serve as a deployment or design guide.



> ...

> > > [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?

> >

> > Deployments may use any Locator-Block and C-SID length. However, the C-SID

> > compression relies on common Locator-Block and consistent C-SID length, so

> > using inconsistent ones, while possible, will lead to reduced compression

> > efficiency.

>

> Please add this information to the draft.  Note that clarifying this

> option is good operational guidance.  Also, it appears several times

> in the document.

>

> "Because you can doesn't mean you should."



We added this in revision -14.



Section 4.1:

| A deployment should use a consistent Locator-Block length and C-SID

| length for all SIDs of the SR domain.  Heterogeneous lengths, while

| possible, may impact the compression efficiency.



Section 4.2:

| A deployment should use a consistent Locator-Block length and C-SID

| length for all SIDs of the SR domain.  Heterogeneous C-SID lengths,

| while possible, may impact the compression efficiency.



> ...

> > > 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.

> >

> > This statement does not impose any requirement on future behaviors.

> >

> > The argument of the NEXT-C-SID flavor SIDs defined in this document only

> > contains the following C-SIDs in the container, for which an endpoint node

> > must accept any value.

> >

> > A future document defining another NEXT-C-SID flavor SID whose argument

> > contains other pieces of information will need to define the structure of

> > that argument and acceptable values. Most likely, the part of the argument

> > carrying the following C-SIDs will follow the same rule as stated here.

>

> The text doesn't point at the requirement (MUST) applying to only the

> SIDs in this document.  If that is the case then please be explicit.



Fixed in revision -14.



| An SR segment endpoint node instantiating a SID of this document with

| the NEXT-C-SID flavor MUST accept any Argument value for that SID.



> ...

> > > 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).

> > >

> >

> > The SRH processing is performed when the packet contains an SRH. The sentence

> > that you quoted (and the corresponding step described in appendix) covers the

> > cases where it does not. This may occur when the SRH is omitted in the SRv6

> > encapsulation (section 4.1 of RFC 8754 or section 5 of RFC 8986) or when it

> > is removed before the ultimate destination (section 4.16.1 of RFC 8986).

>

> I see.

>

> This point is related to the still-open issue of L4 checksums when no

> SRH is present.  If that discussion results in a requirement to always

> carry the SRH then we'll need to remove the text; otherwise, something

> will need to be added to §6.5 about it.



Section 6.5 already covers this case.



| This applies regardless of

| whether an SRH is present in the IPv6 packet or omitted.



> > > 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!

> >

> > This pseudocode specifies a dataplane behavior implemented in the forwarding

> > path of routers, where every operation matters. For that reason, sanity

> > checks are strictly limited to the fields used as part of the packet

> > processing. For instance, the value in the Segments Left field is only

> > validated when it is used or modified.

>

> Ok -- the problem remains.  Without the SL check, for example, packets

> could be forwarded that shouldn't.  Given the performance expectation,

> it would be good to add a note about any potential risk/threat.



Any node whose processing may fail due to an invalid SL value or malformed SRH will check the fields before using them. This also aligns with RFC 8754 and RFC 8986, which do not perform a sanity check when the SL value is 0, although the SRH may still be malformed.



> ...

> > > 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).

> >

> > We clarified the requirements and recommendations in revision -13.

> >

> > | The REPLACE-C-SID flavor SIDs support any Locator-Block length (LBL),

> > | depending on the needs of the operator, as long as it does not exceed

> > | 128-LNFL-ceiling(log_2(128/LNFL)) (ceiling(x) is the least integer

> > | greater than or equal to x [GKP94]), so that enough bits remain

> > | available for the C-SID and Argument. A Locator-Block length of 48,

> > | 56, 64, 72, or 80 bits is RECOMMENDED for address planning reasons.

>

> Related to the operational guidance  I'm looking for -- what "address

> planning reasons"?  How does my address planning influence the

> decision?

>

> Looks like there is no required LBL implementation support.  IOW, the

> RECOMMENDED values are from the deployment point of view, right?  If

> so, then there's no interoperability-related need to use normative

> language.  s/RECOMMENDED/recommended



We updated this in revision -14.



| The REPLACE-C-SID flavor SIDs support any Locator-Block length (LBL),

| depending on the needs of the operator, as long as it does not exceed

| 128-LNFL-ceiling(log_2(128/LNFL)) (ceiling(x) is the least integer

| greater than or equal to x [GKP94]), so that enough bits remain

| available for the C-SID and Argument.  A Locator-Block length of 48,

| 56, 64, 72, or 80 bits is recommended for easier reading in

| operation.



> ...

> > > 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?

> >

> > This document sets the length of Arg.FE2 to 16 bits for the End.DT2M with

> > REPLACE-C-SID SID. We clarified this in revision -13.

> >

> > | The value of Arg.FE2 is 16-bit long. The SR segment endpoint node

> > | obtains the value Arg.FE2 from the 16 most significant bits of

> > | DA.Argument if DA.Arg.Index is zero, or from the 16 least significant

> > | bits of the next position in the current C-SID container (Segment

> > | List[Segments Left][DA.Arg.Index-1]) otherwise (DA.Arg.Index is non-

> > | zero).

>

> s/The value of Arg.FE2 is 16-bit long./The value of Arg.FE2 is 16-bit

> long when used with the REPLACE-C-SID C-SID.



Fixed in revision -14.



| For any End.DT2M SID with the REPLACE-C-SID flavor, the value of

| Arg.FE2 is 16-bit long.



> ...

> > > 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

> >

> > In general, an implementation could identify a locally instantiated SRv6 SID

> > with argument by installing multiple /128 FIB entries, one for each valid

> > argument value. However, such method is not suited for NEXT-C-SID and

> > REPLACE-C-SID flavor SIDs given than any argument value is valid. We

> > clarified this in revision -13.

> >

> > | Section 4.3 of [RFC8754] defines how an SR segment endpoint node

> > | identifies a locally instantiated SRv6 SID. To ensure that any valid

> > | argument value is accepted, an SR segment endpoint node instantiating

> > | a NEXT-C-SID or REPLACE-C-SID flavor SID SHOULD install a

> > | corresponding FIB entry that matches only the Locator and Function

> > | parts of the SID (i.e., with a prefix length of LBL + LNL + FL).

>

> My opinion is still that rfc8754 already covers what this section

> wants to convey.

>

> If you want to keep it you should maintain the "spirit" of the text in

> §4.3/rfc8754 and avoid using normative language (s/SHOULD

> install/installs), OR, explain when is it ok to not "install a

> corresponding FIB entry...". IOW, why is this action recommended and

> not required?



Indeed this paragraph is merely an advice for implementers. We removed the normative language in revision -14.



> ...

> > > 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?

> >

> > We clarified in revision -13 that this is "the same forwarding path".

> >

> > The length of a segment list is the number of elements that it contains.

> >

> > > 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.

>

> The requirement is: "MUST...result in the same forwarding path as the

> original segment list."  BUT a method that produces "a compressed

> segment list of equal or shorter length than the uncompressed segment

> list is compliant".

>

> I understand the intent, but given that it is a requirement, how can

> "the same forwarding path" be enforced?  If the path is loose, how can

> "the same forwarding path" be guaranteed?

>

> Suggestion>

>

>    The segment list that the SR source node pushes onto the packet MUST

>    comply with the rules in Section 6.3 and Section 6.4 and should result

>    in the same forwarding path as the original segment list.



That's a good point. However, "should result in the same forwarding path" may be too loose.



How about "MUST [...] result in the same *set of possible forwarding paths* as the original segment list"?



> ...

> > > 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?

> >

> > A similar check is performed inline on line S03 of the first pseudocode in this section.

>

> Yes, similar, but not the same.  ConCheck explicitly checks if the

> same SID structure is shared -- why isn't that needed here?



In this case, only the Locator-Blocks need to match. There is no requirement that the C-SID lengths be the same.



> 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.



One may argue that whatever belongs to 4.1.1 also belongs to the parent section 4.1. Regardless, we have added an explicit reference to 4.1.1 in revision -14.



| Regardless of how a compressed segment list is produced, the SR

| source node writes it in the IPv6 packet as described in Sections 4.1

| and 4.1.1 of [RFC8754].  The text is reproduced below for reference.



> 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?



These requirements are a part of how the SR source node builds the compressed segment list and the SR source node is sole responsible for enforcing them.



As goes with any SRv6 segment list, the other nodes along the path can only validate that the next SID matches a local FIB entry.



The impact if these rules are not followed are the same as any other incorrect value in an SRv6 segment list: the packet may get dropped or misrouted.



> ...

> 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"?



The sentence in the draft is correct. This rule is meant to property identify the local 16-bit C-SIDs advertised in combination with a global C-SID (see Section 8).



> 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



Fixed in revision -14.



> ...

> 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.



Resolved in revision -12.



> ...

> 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?



If you are asking about an IETF draft then none has been disclosed currently that I am aware of.



> ...

> 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?



Same as previous comment.



> ...

> 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.



Fixed in revision -14.



| *  BGP [RFC9252], [RFC9514], [I-D.ietf-idr-sr-policy-safi]

|

| *  BGP-LS [I-D.ietf-idr-bgp-ls-sr-policy]



> ...

> 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.



This is covered in section 6.1. In particular:



| When compressing a segment list, the SR source node MUST treat an

| invalid SID structure as unknown, and treats the SID as

| incompressible.



Not sure how that can be a security threat, though.



> [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.



The SID structure requirement only applies when those SIDs are advertised in a control plane protocol.



While it is desirable to extend the existing control and management plane mechanisms for those remaining SIDs, it really falls outside the scope of this document.



> ...

> 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



Fixed in revision -14.



> ...

> 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/<https://urldefense.com/v3/__https://www.iana.org/assignments/segment-routing/__;!!NEt6yMaO-gk!HRpiQWU2pUWihCzpYT-zhnqmYyOb_iF_IIRZXx6AIXfOS90KBBq-2eWcXLMj5bZ1-KrV-coZZLQWNsXNpLFMYETMd6az628$>) 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      +-------+-----------------------------------------+-----------+



Fixed in revision -12.



> ...

> 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<https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc9259__;!!NEt6yMaO-gk!HRpiQWU2pUWihCzpYT-zhnqmYyOb_iF_IIRZXx6AIXfOS90KBBq-2eWcXLMj5bZ1-KrV-coZZLQWNsXNpLFMYETMM1rWuPY$>>.

>

> [minor] This reference can be Informative.



Fixed in revision -14.



> 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<https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc9350__;!!NEt6yMaO-gk!HRpiQWU2pUWihCzpYT-zhnqmYyOb_iF_IIRZXx6AIXfOS90KBBq-2eWcXLMj5bZ1-KrV-coZZLQWNsXNpLFMYETMRynQXik$>>.

>

> [minor] This reference can be Informative.



Fixed in revision -14.