Subject: [spring] CSID proposed clarifications

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 14 Oct 2021 12:53:48 +0000

The NEXT-C-SID and REPLACE-C-SID flavors are functionally very similar.
In both cases the SID in the IPv6 Destination Address (DA) contains an argument,
that argument is used to construct the next SID from the active segment in
the SRH Segment List.

I believe the following pseudocode is a much better description of their
segment endpoint processing. You’ll notice there is no manipulation of
the bits in the IPv6 DA.

I propose we replace the pseudocode in the draft with the following,
stand-alone pseudocode, for the NEXT-C-SID and REPLACE-C-SID flavors
of the END behavior (sections 4.1.1 and 4.2.1 respectively).

Equivalent changes can be completed for the NEXT-C-SID and REPLACE-C-SID
flavors of the END.X behavior (sections 4.1.2 and 4.2.2 respectively) and
NEXT-AND-REPLACE-C-SID flavor.

Comments are appreciated.

Thanks
  Darren

4.1.1.  End with NEXT-C-SID

When processing an IPv6 packet that matches a FIB entry locally
instantiated as an End SID with the NEXT-C-SID flavor, the SRH
processing described in Section 4.1 of [RFC8986] is replaced as
follows.

S.01 When an SRH is processed {
S.02  If (IPv6.DA.Argument == 0 and SRH.SegmentsLeft == 0) {
S.03     Stop processing the SRH, and proceed to process the next
         header in the packet, whose type is identified by
         the Next Header field in the routing header.
S.04  }

S.05  If (IPv6.HopLimit <= 1) {
S.06     Send an ICMP Time Exceeded message to the Source Address
         with Code 0 (Hop limit exceeded in transit),
         interrupt packet processing, and discard the packet.
S.07  }

S.08  # Determine the maximum SRH Last Entry
S.09  Set maxLE to ((SRH.HdrExtLen / 2) - 1)

S.10  Initialize 128-bit buffer memory S to 0.
S.11  Initialize local parameter Argument to the value of IPv6.DA.Argument

S.12  If (Argument == 0) {
S.13    If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)) {
S.14      Send an ICMP Parameter Problem to the Source Address
           with Code 0 (Erroneous header field encountered)
           and Pointer set to the Segments Left field,
           interrupt packet processing, and discard the packet.
S.15    }

S.16    Decrement SRH.SegmentsLeft by 1

S.17    Set S to the value of SRH.SegmentList[SRH.SegmentsLeft]
S.18  }
S.19  Else {
S.20    If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)) {
S.21      Send an ICMP Parameter Problem to the Source Address
          with Code 0 (Erroneous header field encountered)
           and Pointer set to the Segments Left field,
           interrupt packet processing, and discard the packet.
S.22    }

S.23    Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common locator block)

S.24    If (SRH.SegmentsLeft > SRH.LastEntry) {
S.25      Initialize local parameter ActiveSegment to the value of DA
S.26    }
S.27    Else {
S.28      Initialize local parameter ActiveSegment to the value
S.29       of SRH.SegmentList[SRH.SegmentsLeft]
S.30    }

S.31    Initialize local parameter BitLength to (CountTrailingZeros(ActiveSegment) +
                                                  AL - CountTrailingZeros(Argument))
S.32    Initialize local parameter BitIndex to (128 – BitLength)

S.33    Set S[B..B+BitLength-1] to the value of
         ActiveSegment[BitIndex..(BitIndex+BitLength-1)]
S.34  }

S.35  Set IPv6.DA to the value of S

S.36  Decrement IPv6.HopLimit by 1

S.37  Submit the packet to the egress IPv6 FIB lookup for transmission
       to the new destination.
S.38 }

4.1.1.1 Upper layer header processing

The upper-layer header processing described in Section 4.1.1 of
[RFC8986] is replaced as follows.

S.01  Initialize local parameter Argument to the value of IPv6.DA.Argument
S.02  If (Argument != 0) {
        # In this case, the SRH was not added by source
        # The source compressed it into the active segment in IPv6.DA
        # Build a pseudo header from the active segment in the IPv6.DA for use
      # during processing.
S.03    Initialize a 24-byte local SRH in memory to 0’s for use below
S.04    Set SRH.MaxHdrLen to 3
S.05    Set SRH.RoutingType to 4
S.06    Set SRH.SegmentsLeft to 0
S.07    Set SRH.SegmentList[0] to the value of IPv6.DA

S.08    Process the SRH as per section 4.1.1,
S.09     noting such processing is limited to the pseudo SRH
S.10     since Argument is not 0.
S.11  }

S.12  If (Upper-Layer header type is allowed by local configuration) {
S.13    Proceed to process the Upper-Layer header
S.14  } Else {
S.15    Send an ICMP Parameter Problem to the Source Address
         with Code 4 (SR Upper-layer Header Error)
         and Pointer set to the offset of the Upper-Layer header,
         interrupt packet processing, and discard the packet.
S.16  }

4.2.1.  End with REPLACE-C-SID

When processing an IPv6 packet that matches a FIB entry locally
instantiated as an End SID with the REPLACE-C-SID flavor, the SRH
processing described in Section 4.1 of [RFC8986] is replaced as
follows.

S.01 When an SRH is processed {
S.02  If (IPv6.DA.Argument == 0 and SRH.SegmentsLeft == 0) {
S.03    Stop processing the SRH, and proceed to process the next
        header in the packet, whose type is identified by
        the Next Header field in the routing header.
S.04  }

S.05  If (IPv6.HopLimit <= 1) {
S.06    Send an ICMP Time Exceeded message to the Source Address
        with Code 0 (Hop limit exceeded in transit),
        interrupt packet processing, and discard the packet.
S.07  }

S.08  # Determine the maximum SRH Last Entry
S.09  Set maxLE to ((SRH.HdrExtLen / 2) - 1)

S.10  Initialize 128-bit buffer memory S to 0.
S.11  Initialize local parameter Argument to the value of IPv6.DA.Argument
S.12  Initialize local parameter ActiveSegment to SRH.SegmentList[SRH.SegmentsLeft]

S.13  If (Argument == 0) {
S.14    If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)) {
S.15      Send an ICMP Parameter Problem to the Source Address
          with Code 0 (Erroneous header field encountered)
          and Pointer set to the Segments Left field,
          interrupt packet processing, and discard the packet.
S.16    }

S.17    Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common locator block)

S.18    Decrement SRH.SegmentsLeft by 1

S.19    Set Argument to (128 / NF - 1)
S.20  }
S.21  Else {
S.22    If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry)) {
S.23      Send an ICMP Parameter Problem to the Source Address
          with Code 0 (Erroneous header field encountered)
          and Pointer set to the Segments Left field,
          interrupt packet processing, and discard the packet.
S.24    }

S.25    Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common locator block)

S.26    Decrement Argument by 1
S.27  }

S.28  Initialize local parameter BitLength to the value of NF
S.29  Initialize local parameter BitIndex to (Argument * NF)

S.30  Set S[B..B+BitLength-1] to the value of
       ActiveSegment[BitIndex..(BitIndex+BitLength-1)]
S.32  Set S[B+BitLength..B+BitLength+A-1] to the value of Argument

S.33  Set IPv6.DA to the value of S

S.34  Decrement IPv6.HopLimit by 1

S.35  Submit the packet to the egress IPv6 FIB lookup for transmission
S.36   to the new destination.
S.37 }

4.2.1.1.  Upper layer header processing

The upper-layer header processing described in Section 4.1.1 of [RFC8986] is unchanged and reproduced below.

S.01  If (Upper-Layer header type is allowed by local configuration) {
S.02    Proceed to process the Upper-Layer header
S.03  } Else {
S.04    Send an ICMP Parameter Problem to the Source Address
        with Code 4 (SR Upper-layer Header Error)
        and Pointer set to the offset of the Upper-Layer header,
        interrupt packet processing, and discard the packet.
S.05  }

---

From: Andrew Alston <[email-masked]>
Date: Thu, 14 Oct 2021 14:42:29 +0000

(Apologies if this appears twice - seems something went screwy with my outbound address so the other version of this is moderated)

Darren,

I'm a little confused here reading this - but all said and done - on the next behavior - how is this different from doing something along the lines of

Da[loc_bits/8] << sid_size

Because - when I trace this all out into actual C code - that's pretty much what it seems to summarize down to - more specifically - it could be done something like this:

(taking out all the comparisons and error checking)

__m128i vec;
__u8 output[16];

vec = __mm_loadl_epi64((void *)da[loc_size/8])
if(sid_size == 16) {
              vec = _mm_bsrli_si128(vec, 2)
} else {
              vec = _mm_bsrli_si128(vec, 4)
}
_mm_store_u_si128((__m128i*)output, vec);
memcpy(da[loc_size/8], output, 16-(loc_size/8));

(think I got that pretty much right)

Andrew

From: spring <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Thursday, October 14, 2021 3:54 PM
To: SPRING WG <[email-masked]>
Subject: [spring] CSID proposed clarifications

I believe the following pseudocode is a much better description of their
segment endpoint processing. You'll notice there is no manipulation of
the bits in the IPv6 DA.

Thanks
  Darren

S.31    Initialize local parameter BitLength to (CountTrailingZeros(ActiveSegment) +
                                                  AL - CountTrailingZeros(Argument))
S.32    Initialize local parameter BitIndex to (128 - BitLength)

4.1.1.1<http://4.1.1.1> Upper layer header processing

S.03    Initialize a 24-byte local SRH in memory to 0's for use below

4.2.1.1<http://4.2.1.1>.  Upper layer header processing

---

From: Andrew Alston <[email-masked]>
Date: Thu, 14 Oct 2021 14:22:42 +0000

Darren,

__m128i vec;
__u8 output[16];

Andrew

Thanks
  Darren

---

From: Andrew Alston <[email-masked]>
Date: Thu, 14 Oct 2021 14:33:52 +0000

Darren,

__m128i vec;
__u8 output[16];

Andrew

Thanks
  Darren

---

From: Ron Bonica <[email-masked]>
Date: Fri, 22 Oct 2021 16:35:54 +0000

Authors,

Could you update the draft to reflect the new pseudocode, below. It is essential to the 6man review.

                                                                                              Ron

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Thursday, October 14, 2021 8:54 AM
To: SPRING WG <[email-masked]>
Subject: [spring] CSID proposed clarifications

[External Email. Be cautious of content]

Thanks
  Darren

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 23 Oct 2021 15:47:05 -0400

Darren & Authors

The CSID proposed clarifications looks excellent.

In the current draft revision it was clear that both Next and Replace use
the IPv6 IID portion of the address as the container to index the C-SID
using  Argument portion SRv6 SID,  Next having 16 bit NF and 64 bit
argument, and  Replace having 32 bit NF and 16 bit Argument.

For Replace the Argument is 16 bit followed by 0s section 4.2, is that
correct?    So is the field actually 64 bit that the CSID entires reside?

I agree End.x adj-sid strict path has no change to the SRv6 processing as
the SID in SRH gets copied directly to DA, so no complex indexing of the
SID from Argument portion of SRv6 SID in the SRH.

The difference between End.x and End is End Prefix sid is global in IGP
where End.x is local not in IGP.

Note that the very long strict paths is what requires compression End.x
versus End endpoint behaviors, although both endpoints for overall
compression solution  is  required.

I believe a lot of the contention is with End and not End.x as far as
violation of IPv6 specification, indexing of the CSID within the SRH SID,
argument portion of the address.

The End, prefix sid SRv6 processing is more complicated as the indexed SID
is copied from the SRH Argument portion of the SRv6 address to DA.

Excerpt below from your pseudocode below really helps clarify the exact
differences of the bits within the C-SID container that gets copied  to DA
for End endpoint for both Next and Replace flavors.

Comparing the Next and Replace pseudocode below side by side for the
critical copy function of what bits get copied from SRH Argument to DA.

Replace has 1 extra step s32 which helps clearly spell out the difference
between the two flavors difference in replace copying from bottom of
container to top.

I was referencing uSID for Next and G-SID for Replace but there are some
slight differences so this updated pseudocode really helps.

NEXT-C-SID

S.31    Initialize local parameter BitLength to
(CountTrailingZeros(ActiveSegment) +

                                                  AL -
CountTrailingZeros(Argument))

S.34  }

REPLACE-C-SID

Kind Regards

Gyan

On Thu, Oct 14, 2021 at 8:54 AM Darren Dukes (ddukes) <ddukes=
[email-masked]> wrote:

> *4.1.1.  End with NEXT-C-SID*
>
>
>
> *4.1.1.1 Upper layer header processing*
>
>
>
> *4.2.1.  End with REPLACE-C-SID*
>
>
>
> *4.2.1.1.  Upper layer header processing*
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*