On Fri, Apr 5, 2024, 8:53 AM Antoine FRESSANCOURT <antoine.fressancourt= 40huawei....@dmarc.ietf.org> 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 > > 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 <spring-boun...@ietf.org> On Behalf Of Alvaro Retana > Sent: jeudi 28 mars 2024 13:06 > To: SPRING WG List <spring@ietf.org> > Cc: 6man <i...@ietf.org>; spring-cha...@ietf.org > 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 > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
