Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

["Martin Vigoureux (Nokia)" <[e-mail]>]

Le 2024-04-05 à 16:30, Tom Herbert a écrit :
> 	
> CAUTION:This is an external email. Please be very careful when clicking 
> links or opening attachments. See the URL nok.it/ext for additional 
> information.
> 
> 
> 
> On Fri, Apr 5, 2024, 8:53 AM Antoine FRESSANCOURT 
> <antoine.fressancourt=[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Hello,
> 
>     After reading RFC 8754 and RFC 8986 together with the draft (version
>     14), it seems to me that the cases when the SRH will be omitted are
>     quite limited, and will happen among nodes sharing the same locator
>     block. We can assume that, in such cases, nodes exchanging packets
>     carrying a C-SID without SRH will be managed by a single entity and
>     that this entity can check whether some middlebox infer with packet
>     relaying.
> 
> 
> Antoine,
> 
> If it's such a limited use case then I have to ask if it's worth the 
> effort to make this a robust protocol? All we really need is a 
> deterministic way to distinguish SR packets from non-SR packets, which 
> could be accomplished by a minimum sized eight byte SRH. In other words, 
> it seems like this discussion is only about saving eight bytes on the 
> wire for a narrow use case.

Tom

considering an earlier message from Francois:

---
Specifically for the case of middleboxes attempting to verify the 
upper-layer checksum,

     An SRv6-unaware middlebox will not be able to verify the 
upper-layer checksum of SRv6 packets in flight, regardless of whether an 
SRH is present or not.
     An SRv6 and C-SID aware middlebox will be able to find the ultimate 
DA and verify the upper-layer checksum in flight, regardless of whether 
an SRH is present or not.
---

I'm not sure to understand the value of an SRH to distinguish SR packets 
from non-SR packets.

-m


> 
> Tom
> 
> 
> 
>     Then we could modify the text to mention that, if such an inference
>     is detected, the packet should use a SRH. In my view, being clear
>     about potential issue related with omitting the SRH and giving an
>     alternative is enough, and gives some freedom to people willing to
>     use C-SID without SRH in their context.
> 
>     Best regards,
> 
>     Antoine Fressancourt
> 
>     -----Original Message-----
>     From: spring <[e-mail]
>     <mailto:[e-mail]>> On Behalf Of Alvaro Retana
>     Sent: jeudi 28 mars 2024 13:06
>     To: SPRING WG List <[e-mail] <mailto:[e-mail]>>
>     Cc: 6man <[e-mail] <mailto:[e-mail]>>;
>     [e-mail] <mailto:[e-mail]>
>     Subject: [spring] Subject: Mandating SRH when using C-SIDs
>     (draft-ietf-spring-srv6-srh-compression)
> 
>     Focusing on the C-SID draft, some have suggested requiring the
>     presence of the SRH whenever C-SIDs are used. Please discuss whether
>     that is the desired behavior (or not) -- please be specific when
>     debating the benefits or consequences of either behavior.
> 
>     Please keep the related (but independent) discussion of requiring
>     the SRH whenever SRv6 is used separate. This larger topic may impact
>     several documents and is better handled in a different thread (with
>     6man and spring included).
> 
>     Thanks!
> 
>     Alvaro
>     -- for spring-chairs
> 
>     _______________________________________________
>     spring mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/spring
>     <https://www.ietf.org/mailman/listinfo/spring>
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>
>     --------------------------------------------------------------------
> 
> 
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring