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

[Robert Raszuk <[e-mail]>]

So your point is not about transit via SRv6 C-SID enabled domains but about
hosts sending native SRv6 packets ? On the latter I let C-SID authors to
comment. But the former seems no issue and this is what I wanted to
clarify.

Just to note that even if so we already have an RFC 8754 which
explicitly allows that:

3.1.  <https://datatracker.ietf.org/doc/html/rfc8754#section-3.1>SR Source
Node <https://datatracker.ietf.org/doc/html/rfc8754#name-sr-source-node>

A SR source node is any node that originates an IPv6 packet with a segment
(i.e., SRv6 SID) in the destination address of the IPv6 header. *The packet
leaving the SR source node may or may not contain an SRH.* This includes
either:¶ <https://datatracker.ietf.org/doc/html/rfc8754#section-3.1-1>

   - A host originating an IPv6 packet, or¶
   <https://datatracker.ietf.org/doc/html/rfc8754#section-3.1-2.1>
   - An SR domain ingress router encapsulating a received packet in an
   outer IPv6 header, followed by an optional SRH.¶
   <https://datatracker.ietf.org/doc/html/rfc8754#section-3.1-2.2>




On Mon, Mar 25, 2024 at 4:47 PM Andrew Alston - IETF
<[e-mail]> wrote:

> If the text indeed states that we always encapsulate – and then clarifies
> that the checksum on encap is set to zero – in clear umambiguous text – no
> problem.
>
>
>
> However, unless I missed something – it does NOT say that we push an
> additional header.  If I am wrong on this, please feel free to correct me
> with citation to relevant drafts.  In fact, I believe things were carefully
> written to allow hosts in the domain to use SRv6 without extra encap –
> again – please correct me with the citations if I’m wrong.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
> Internal All Employees
> From: Robert Raszuk <[e-mail]>
> *Date: *Monday, 25 March 2024 at 18:43
> *To: *Andrew Alston - IETF <[e-mail]>
> *Cc: *Tom Herbert <tom=[e-mail]>, Ron Bonica
> <rbonica=[e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: [spring] Chair Review of
> draft-ietf-spring-srv6-srh-compression-11
>
> Andrew,
>
>
>
> So my understanding is that there is *always* a new IPv6 header pushed on
> the packet when it travels via the SRv6 "limited domain". With or without
> SRH.
>
>
>
> If we do not - oh yes then your concerns are correct.
>
>
>
> If we however do - do you see any issue
> with draft-ietf-spring-srv6-srh-compression ?
>
>
>
> Thx,
>
> R.
>
>
>
>
>
> On Mon, Mar 25, 2024 at 4:35 PM Andrew Alston - IETF
> <[e-mail]> wrote:
>
> It does mean the packet is NOT encapsulated.
>
>
>
> An SRv6 packet without an SRH has no encapsulation unless you are talking
> about applying a separate Ipv6 header to the packet that is stripped off at
> the end.  Encapsulation is defined as “The action of enclosing something in
> aor as if in a capsule”. An SRv6 packet without an SRH is not enclosed in
> anything – it is an outer layer header that you are mangling along the path.
>
>
>
> Hence – unless you are proposing adding an encapsulation header – that
> paragraph in 8200 does not apply
>
>
>
> Andrew
>
>
>
>
>
>
>
> Internal All Employees
>
> From: Robert Raszuk <[e-mail]>
> *Date: *Monday, 25 March 2024 at 18:32
> *To: *Andrew Alston - IETF <[e-mail]>
> *Cc: *Tom Herbert <tom=[e-mail]>, Ron Bonica
> <rbonica=[e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: [spring] Chair Review of
> draft-ietf-spring-srv6-srh-compression-11
>
> The fact that there is no SRH does not mean that we have mangled the
> raw/original IPv6 packets.
>
>
>
> Just read the subject spec's abstract:
>
>
>
> Such compression significantly reduces the size of the *SRv6
> encapsulation* needed to steer packets over long segment lists.¶
> <https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression#section-abstract-1>
>
>
>
> On Mon, Mar 25, 2024 at 4:27 PM Andrew Alston - IETF
> <[e-mail]> wrote:
>
> Hi Robert,
>
>
>
> Yet in this case we are explicitly talking about srv6 without an SRH –
> where exactly is the tunnel encap here?
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
>
>
> Internal All Employees
>
> From: Robert Raszuk <[e-mail]>
> *Date: *Monday, 25 March 2024 at 18:23
> *To: *Andrew Alston - IETF <[e-mail]>
> *Cc: *Tom Herbert <tom=[e-mail]>, Ron Bonica
> <rbonica=[e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: [spring] Chair Review of
> draft-ietf-spring-srv6-srh-compression-11
>
> Hi Andrew,
>
>
>
> Note that very section also says:
>
>          As an exception to the default behavior, protocols that use UDP
>
>          as a tunnel encapsulation may enable zero-checksum mode for a
>
>          specific port (or set of ports) for sending and/or receiving.
>
>          Any node implementing zero-checksum mode must follow the
>
>          requirements specified in "Applicability Statement for the Use
>
>          of IPv6 UDP Datagrams with Zero Checksums" [RFC6936 <https://datatracker.ietf.org/doc/html/rfc6936>].
>
>
>
>
>
> Many thx,
>
> Robert
>
>
>
>
>
>
>
> On Mon, Mar 25, 2024 at 4:21 PM Andrew Alston - IETF
> <[e-mail]> wrote:
>
> Robert,
>
>
>
> By RFC8200 Section 8.1 Second paragraph of Page 28 –
>
>
>
> “Ipv6 receiveers must discard UDP packets containing a zero checksum and
> should log the error”
>
>
>
> Note – Receivers here does not say end points – a transit router still
> receives the packet.  Therefore – if we went with zero checksums – by the
> letter of 8200 – no UDP packets without an SRH would flow, because 8200
> clearly says that they must be dropped.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
>
>
> Internal All Employees
>
> From: Robert Raszuk <[e-mail]>
> *Date: *Monday, 25 March 2024 at 18:16
> *To: *Tom Herbert <tom=[e-mail]>
> *Cc: *Andrew Alston - IETF <[e-mail]>, Ron Bonica <rbonica=
> [e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: [spring] Chair Review of
> draft-ietf-spring-srv6-srh-compression-11
>
> All,
>
>
>
> It looks like previous discussions on this topic are lost again and we
> keep starting over and over every few weeks from scratch.
>
>
>
> It has been established that the checksum issue is moot for 99.9% of this
> discussion as we are talking about tunneled packets encapsulated with new
> header. Checksum there should be set to zero on the basis of
> RFC6935/RFC6936 or RFC7676 etc ...
>
>
>
> I do fail to understand why RFC8986 is silent on this. If it is not, I
> hope someone will send a quote.
>
>
>
> So the only issue could be about SRv6 packets with cSIDs originating
> within the network (not encapsulated) - for example ICMP replies. But are
> there such packets in the first place ? Can't they just use SR less default
> routed path towards the src ?
>
>
>
> Many thx,
>
> Robert
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Mar 25, 2024 at 3:32 PM Tom Herbert <tom=
> [e-mail]> wrote:
>
>
>
>
>
> On Mon, Mar 25, 2024 at 5:37 AM Andrew Alston - IETF
> <[e-mail]> wrote:
>
> 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.
>
>
>
> Andrew,
>
>
>
> I don't think it works on two accounts:
>
>
>
> 1) In order to compute the checksum a device would need to understand the
> Hop-by-Hop Option. So the checksum would still be broken for any
> intermediate device that tries to verify it (in particular, NICs that do
> protocol specific checksum offload wouldn't support this option so it
> doesn't help).
>
> 2) The point of not using the SRH is to save bytes on the wire. Sending a
> HBH option instead would negate that benefit. An alternative might be to
> send SRH with a single entry in the route list or maybe a "special" RH with
> minimum length to serve a break for intermediate devices attempting to
> compute the checksum. It's more likely that intermediate devices will skip
> over HBH than skip over RH for computing a checksum (HBH isn't expected to
> have any bearing on the addresses).
>
>
>
> OTOH, I still maintain that doing segment routing without an SRH is simply
> a form of NAT so the checksum should be adjusted in flight like in RFC2663.
> Even if there is an SRH, IMO intermediate nodes should be able to verify
> the transport layer checksum by deducing the final destination address from
> the last address in the route list (which would mean that address needs to
> be self-identifying and can't be compressed using an external state). In
> other words, if any packet contains TCP, UDP, or ICMP it seems like a good
> invariant that the transport layer checksum can always be verified *solely*
> on the contents of the packets.
>
>
>
> Tom
>
>
>
>
>
> 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.
>
>
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
>