Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

[Tom Herbert <[e-mail]>]

On Fri, Oct 15, 2021 at 12:14 AM Mark Smith <[e-mail]> wrote:
>
>
>
> On Fri, 15 Oct 2021, 17:18 , <[e-mail]> wrote:
>>
>> Hi Joel , all,
>>
>> C-SID is no more than another mechanism that relies on some algorithmic mapping embedded in the IPv6 address. We do have already many of such algorithmic approaches: RFC6052, RFC7597, etc.
>
>
>
> That's not correct.
>
> DAs aren't expected to change in fight, otherwise they will break all of the transport layer protocols for which packet addresses are included in the transport layer checksum.

Mark, they already do change courtesy of routing headers. Transport
layer checksums are end to end and there's no requirement that the
intermediate nodes can correctly compute transport layer checksums.
NAT translation maintains the correct checksum, but routing headers do
not, so unless an intermediate node is able to discern the final
destination of the packet it won't be able to compute the correct
checksum (this is a practical problem we are seeing with NICs that
still insist on doing protocol specific checksum offload, in the
presence of routing headers these devices can fail to offload RX
checksum).
>
> In fight changing DAs also will break AH protection of the IPv6 header.

SRH already breaks AH ;-) It's fixable and changing DAs in flight is
compatible if it's prescribed that both the source and destination see
the same destination address for AH processing.

Tom

>
> DA changing in flight is NAT. I'd have thought the IETF had learnt that lesson by now.
>
> Perhaps people need to read RFC2993 again.
>
>>
>>
>> The internal structure would be problematic if it requires that every intermediate node on the path has to parse it, but this is not the case. The packet is forwarded based on the DA following conventional procedures. The procedure to determine the next SR hop is internal to an SR-capable node.
>>
>> Having examples of such SIDs in the draft would help to better understand the compression procedure, but no more than that as these will be displayed as IPv6 addresses!
>>
>> Cheers,
>> Med
>>
>> > -----Message d'origine-----
>> > De : ipv6 <[e-mail]> De la part de Joel M. Halpern
>> > Envoyé : mercredi 13 octobre 2021 09:37
>> > À : [e-mail]
>> > Cc : [e-mail]
>> > Objet : Typo correction Re: Question from SPRING regarding draft-
>> > filsfilscheng-spring-srv6-srh-compression
>> >
>> > There is a typo in the below which if not understood as a typo would be
>> > quite confusing.   I wrote that I raised the issue with
>> > "with the Internet ADs and SPRING chairs".
>> > That should have read "with the Internet ADs and 6man chairs".
>> > The SPRING co-chairs are recused, and the charter requirement leads to the
>> > 6man chairs.  Which is who I talked to.
>> >
>> > Also, I am sending a courtesy copy to the routing ADs, which I should have
>> > done originally.
>> >
>> > Thank you and enjoy.
>> > Yours,
>> > Joel
>> >
>> > On 10/12/2021 11:52 PM, Joel M. Halpern wrote:
>> > > The SPRING working group is in the midst of an adoption call on
>> > > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-
>> > compression/.
>> > >
>> > >
>> > > The SPRING charter has text that is explicit that modifications to
>> > > data planes and architectures standardized by other working groups may
>> > > not be modified in SPRING unless the chairs and ADs responsible for
>> > > that data plane and / or architecture agree.
>> > >
>> > > To complete the context, as my SPRING co-chairs are co-authors on the
>> > > document in question, they have recused themselves from decisional
>> > > activities regarding the document.  Therefore, this message is coming
>> > > just from my as the responsible SPRING co-chair managing this adoption
>> > > call.
>> > >
>> > > As you have seen, multiple questions have been raised about the
>> > > relationship of the document to the IPv6 defined data plane and
>> > > architecture (particularly RFC 4291 and 8200). In particular the
>> > > questions seem to revolve around what the document describes as the
>> > > NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6
>> > > standards.  (For those seeking more context without reading the full
>> > > document, a paraphrase and simplification of the NEXT-C_SID flavor is
>> > > provided as a postscript.)
>> > >
>> > > I raised the question of concurrence as required by the SPRING charter
>> > > with the Internet ADs and SPRING chairs.  They quite reasonably asked
>> > > me to write a note to 6man explaining the concerns as clearly as a
>> > > can, so that they can then determine how to proceed.
>> > >
>> > > The questions that prompted my inquiry are:
>> > >
>> > > 1) Does the placement of a list of sids in the IPv6 DA field change
>> > > the
>> > > IPv6 architectural description of that field.
>> > > 2) Does the operation of shifting information around in the IPv6
>> > > destination address field represent a modification or extension of the
>> > > IPv6 data plane.
>> > >
>> > > On a related note, the document in question also defines two other
>> > > flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.  The
>> > > NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID
>> > > flavor operation, so seems to be affected by the same question.
>> > >
>> > >  From my own reading, it appears that the REPLACE-C-SID flavor does
>> > > not raise issues requiring 6man leadership concurrence.
>> > >
>> > > Yours,
>> > > Joel M. Halpern for the SPRING working group
>> > >
>> > >
>> > > PS:
>> > > Clearly, understanding the question requires some understanding of
>> > > what the NEXT-C_SID flavor does.   This explanation is a
>> > > simplification for length and context.  Really, the best place to
>> > > understand it is the draft.  However, to give you enough information
>> > > to let you decide whether you care, I will try to provide a fair
>> > > summary.  My apologies in advance to the authors for necessary
>> > > liberties for length.  Also, discussion of the draft contents (as
>> > > distinct from the interaction with the IPv6 data plane and
>> > > architecture) belongs on the SPRING list, and should not clutter up
>> > 6man.
>> > >
>> > > SIDs are the identifiers used in segment routing.
>> > > In SRv6, as document in the current RFCs, these are 128 bits.   As
>> > > defined in the relevant RFCs, SIDs which identify endpoints to which
>> > > packets are directed are identified by endpoint SIDs.  These can have
>> > > behaviors (decapsulate and forward is one example).  They can have
>> > > flavors such as where the SRH is removed.
>> > >
>> > > The topic under discussion is means to compress these SIDs in the
>> > > packets on the wire.  The document under discussion provides three
>> > > flavors of compression.
>> > >
>> > > The fundamental mechanism of the draft is to use a single SRH entry as
>> > > a container for multiple SIDs.  In the NEXT-C_SID mechanism, when it
>> > > is first encountered the entire container is copied into the
>> > > desination address of the IPv6 packet.  The container has a common
>> > > routing prefix used for all the NEXT-C-SID SIDs.  It is followed by a
>> > > sequence of compressed SIDs of a configured length.  One could
>> > > configure 16, 24, or
>> > > 32 bits.  Or whatever length.  The routing advertisements are arranged
>> > > so that the IPv6 packet is directed to the node represented by the
>> > > first compressed SID on the basis of longest prefix match matching the
>> > > combination of the common routing prefix and that compressed SID.
>> > >
>> > > When the packet arrives at that node, it looks up the configured
>> > > portion, the compressed SID, and determines the behavior and flavor.
>> > > In the case of the NEXT-C-SID flavor, the resulting operation is to
>> > > shift the entire remaining contents of the IPv6 address (the bits past
>> > > the first compressed sid) so as to over-write the first compressed
>> > > SID.  0 bits are shifted into the low order positions.  If the result
>> > > is a non-zero new first compressed SID, then the packets is forwarded
>> > > and the process repeats.  When all that is left are 0s, if there is an
>> > > SRH, it is consulted to find the next SRH entry, which is, per normal
>> > > SRv6 processing, put into the IPv6 DA.
>> > > Note that in the common case where the SIDS needed all fit in to a
>> > > single container, the analysis also assumes the use of the reduced
>> > > encapsulation options which omits the SRH that is not needed as it
>> > > would have no entries.  This the packet contains a normal IPv6 header,
>> > > with a sequence of compressed SIDs (what one might or might not call a
>> > > source
>> > > route) in the IPv6 destination address field.
>> > >
>> > > PPS: If the authors of the NEXT-C-SID flavor feel I have
>> > > mis-represented the work, please, send clarifications or corrections.
>> > > Again, the best source of information is the draft itself.  I was
>> > > asked to provide extra context in this email.
>> >
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > [e-mail]
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>>
>> _________________________________________________________________________________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------