Re: [spring] C-SIDs and upper layer checksums (draft-ietf-spring-srv6-srh-compression)

[Ketan Talaulikar <[e-mail]>]

Hi Robert,

Please check inline below for some clarifications.

On Tue, Apr 9, 2024 at 12:06 AM Robert Raszuk <[e-mail]> wrote:

> Hi Ketan,
>
>
>> a) SR Source Node: the node originating the packet - it may have an SRH
>> or may skip it (section 4.1)
>> b) Transit Node: node doing IPv6 forwarding
>> c) (Ultimate) Destination Node (from RFC8200): the final node to which
>> the packet is destined
>>
>
> All you said seems true valid, but the above three node categories do miss
> a fourth one - randomly plugged sniffer, or any other way to selectively
> capture subset of packets for troubleshooting.
>

KT> I believe we need to build on existing IETF standards RFCs and that is
what is important here as we are working through the publication process
for the C-SID document on standards track.


>
> I do think this is a bit of an obstacle to require that before such an
> analyzer is connected to process live or offline traffic captures it needs
> to be configured with given's network's SRv6 dedicated locator(s) and/or
> SID blocks.
>

KT> Since you asked for my perspective, I am not sure if this is really an
issue - at least I have not heard of it. Aren't there other ways to detect
transport bit errors instead of parsing/processing all the way to upper
layer checksums in transit nodes? If it is, we need to understand those
requirements better and those "tools" need to be made SRv6 and CSID aware
to support SRv6 operators. That is beyond the scope of this document though
and a separate SRv6 ops discussion.


>
> We clearly do not have such a requirement today for any other
> transport protocol.
>

KT> All RHs need these "sniffers" to be aware of them -
https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-3
... and such "upper layer checksum validation" is also not possible for
IPSec ESP.


>
> Maybe this is a good topic for SRv6OPS WG ?
>

KT> Indeed, I agree with you here.


> I said maybe as there clearly seems to be a group of folks who say do not
> care about SRv6 or CSIDs and would like to continue using same operational
> tools for troubleshooting bare IPv6 protocol. Well in the network where
> both are running in parallel lacking a clear demux flag seems to make it a
> bit of a challenge ... especially if any endpoints talking native SRv6 with
> uSIDs would also talk native IPv6.
>

KT> Since these "group of folks" don't care about SRv6/CSID, they wouldn't
be deploying it and therefore aren't SRv6 operators? Therefore, there is
nothing to demux for these "group of folks" in their networks (for at least
those amongst them that are operators) since they won't have SRv6 in their
limited domains. SRv6 operators are already doing this demux using the
recommendation of RFC8754/8986 (SRv6 SID block) in their deployments - that
said, we may be digressing from the main topic of this thread.

Thanks,
Ketan


>
> Can you kindly share your perspective on this ?
>
> Cheers,
> Robert
>
>
>
>> The CSID document in section 6.5 does not change or update the text in
>> RFC8200 sec 8.1. It is simply stating what the "final destination" is going
>> to be when CSID is used because RFC8200 does not talk about RHs in sec 8.1.
>> RFC8754 covered this aspect by specifying that the last segment is the
>> "final destination" but this needs to be specified when using C-SID (with
>> or without SRH) and for all C-SID flavors/behaviors.
>>
>> I find the current text in section 6.5 to be necessary and sufficient for
>> implementations that claim (or need to) support SR Source Node behavior for
>> C-SIDs.
>>
>> The CSID document does not change any behavior at the Transit Node or for
>> the (Ultimate) Destination Node. Therefore, the discussion of Transit Nodes
>> is outside the scope of this document - just as it was outside the scope
>> for RFC8754.
>>
>> Now, if some "Special Transit Node" wants to go beyond RFC8200 and do
>> things like upper layer checksum validation enroute then they can refer to
>> the same text in section 6.5 to first understand CSID processing and to do
>> what is necessary for their packet processing enroute. This requires such
>> "Special Transit Nodes" to be aware of first SRv6 and now C-SID - this is
>> the same for any new packet encoding  technology.
>>
>> It seems like we are putting the cart before the horse when raising
>> concerns about existing implementations that are not SRv6 and C-SID aware
>> of not being able to do their processing. Let us publish the C-SID document
>> so implementers of those "Special Transit Nodes" (also being referred to as
>> middleboxes on some threads) have a reference to upgrade for C-SID support.
>>
>> Finally, I’ve not heard of issues related to these "Special Transit
>> Nodes" from operators that have deployed SRv6. That may be a good
>> discussion to have (again outside the scope of this document and perhaps in
>> srv6ops?) - so operators who have SRv6 deployment experience can share
>> their learnings and best practices.
>>
>> Thanks,
>> Ketan
>>
>>
>> On Thu, Mar 28, 2024 at 5:34 PM Alvaro Retana <[e-mail]>
>> wrote:
>>
>>> Section 6.5 of draft-ietf-spring-srv6-srh-compression describes the
>>> behavior when an originating node inside an SRv6 domain creates a
>>> packet with a C-SID as the final destination. This description differs
>>> from the text in Section 8.1 of RFC8200.
>>>
>>> We plan to send the draft to the 6man WG for review and explicitly
>>> highlight this difference.
>>>
>>> Please comment on the text in Section 6.5. Does anything need to be
>>> added, deleted, changed, or clarified?
>>>
>>> We want to ask for feedback soon; please send comments on this topic
>>> by April 5th.
>>>
>>> Thanks!
>>>
>>> Alvaro.
>>> -- for spring-chairs
>>>
>>> _______________________________________________
>>> spring mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
>>
>