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=40huawei....@dmarc.ietf.org <mailto: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

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 <spring-boun...@ietf.org
    <mailto:spring-boun...@ietf.org>> On Behalf Of Alvaro Retana
    Sent: jeudi 28 mars 2024 13:06
    To: SPRING WG List <spring@ietf.org <mailto:spring@ietf.org>>
    Cc: 6man <i...@ietf.org <mailto:i...@ietf.org>>;
    spring-cha...@ietf.org <mailto: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 <mailto:spring@ietf.org>
    https://www.ietf.org/mailman/listinfo/spring
    <https://www.ietf.org/mailman/listinfo/spring>

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    i...@ietf.org <mailto:i...@ietf.org>
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    <https://www.ietf.org/mailman/listinfo/ipv6>
    --------------------------------------------------------------------


_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to