Re: [spring] draft-ietf-spring-srv6-srh-compression
Robert Raszuk <robert@raszuk.net> Thu, 08 February 2024 23:45 UTC
Return-Path: <robert@raszuk.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C64C14F5FC for <spring@ietfa.amsl.com>; Thu, 8 Feb 2024 15:45:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbhWUr7qagqk for <spring@ietfa.amsl.com>; Thu, 8 Feb 2024 15:45:36 -0800 (PST)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A948C14F5FF for <spring@ietf.org>; Thu, 8 Feb 2024 15:45:36 -0800 (PST)
Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2d0a4e1789cso4474151fa.3 for <spring@ietf.org>; Thu, 08 Feb 2024 15:45:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1707435934; x=1708040734; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SGNrMT3JRH++4/L/O8y8gBN25OXohE8umJPaT9L4GCk=; b=TjVW+dT0J6WrMFlOJNJL3soBp5dVPY4HaAIo2D6oM6B+PgAQ/YOnpOMWd011+v0yRC jauvcv221s9wRPW1pxoC9Wd8wQNTHh62NTi2BGEC12Pv+sWHoQVNUwlHsWn2nm/dy7RT wfVWsNaTKL0Ii45IiOikP2xmYTVkM1DTufQOcgROqE8an7AQ1wermQr0MHjd1ubHX4r5 NRJ1O8DbTTg8zKPApBjaViOUqtZTIowVQP+Pxl50H5ApuWojPcxjZbf7fft4MCkKB82e kiFHwqjLvk6iyICwcDUG42dF3BmGteFsTQhAP9I1vFDlbW2Mj2qHP6YcKERsss6+Hhrp LztA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707435934; x=1708040734; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SGNrMT3JRH++4/L/O8y8gBN25OXohE8umJPaT9L4GCk=; b=cs8jeIzqTpo4DoapklPPUbSbii83bLGvN7q2RZha1dfK9DNPh9nQFZ08esQ3GyB+1k b9WKnxhZqg4dsEpuhUu/5uqYQJyXTnOFi5cwAS2ggxrgasbYG+GoukZqQNICRJRgTPPw vWZoyCUh6MYapEQBx4VNs/WUl6uss6In/jkGguMluJmz27U5lIkfWClwtCq7Du2YRB/6 iCWC5w4dD2n6YlfiNPI/NRsZsTOBlBXA0Wtj+J8MUvuhvVcl5fytuzMF+jLCdbHyJstW NBBHNuGJJ2csqzejSm06jt16iIK1OW9pXq572Ruf9bY+gAi7sDhDO27D8XcXYbRg1ACR rzdw==
X-Gm-Message-State: AOJu0Ywtw8BVu47GDLlflHAhrZNY55HXMSW4qUCPnw9KHCGpZf2jcxRf V2r7aD956SgVSgYgMEdw0w+2jguMYAGnh6YocNGkgcjUCXB6iNAawpqnFurQlJp7WpbW3mbMkts cdi7yWKY/EjDC8DMHGkdMNYmScAFb+yjsxXqdKA==
X-Google-Smtp-Source: AGHT+IESZX55WdSL7+8uEz/oAnnKWJFdZUq74OuGkV3FqKp6GTyrK681DEolnX09G3esq5nknBesfa0+xar2ZQxbgg0=
X-Received: by 2002:a2e:b5d7:0:b0:2d0:a817:4525 with SMTP id g23-20020a2eb5d7000000b002d0a8174525mr39980ljn.42.1707435933853; Thu, 08 Feb 2024 15:45:33 -0800 (PST)
MIME-Version: 1.0
References: <DU2PR03MB8021764E2F17F0D527E3FA3CFA472@DU2PR03MB8021.eurprd03.prod.outlook.com> <BL0PR05MB53163A098023244520ADCEEBAE472@BL0PR05MB5316.namprd05.prod.outlook.com> <CAOj+MMEc1R8fZZwgOEF2-mK8S0+PE+zBR3Yz9vwXBh-umQPAjQ@mail.gmail.com> <CAO42Z2z1Y_OH0yCi0yiMnHvwQRBHK+UYHxJJw+X5EfHfJgiGNw@mail.gmail.com> <CAOj+MMGxox-TDsqhdped8=8EhqHJOyyLBBk0HK8ZU5-qrV-zYA@mail.gmail.com> <CAO42Z2zm_XtV6CqiO6idX_-=HnZDCz4grgpQV=FJQ3H6qDsKKQ@mail.gmail.com> <CAOj+MMESaauKhEtY_6uqTt6Bw72j_nTkddsgsZLWVvDpmMRx8Q@mail.gmail.com> <CA+RyBmUYrPMi7gLZdHTY0fX08iw7b-jp6pTUrXsu-eS7fNZqrQ@mail.gmail.com> <CAOj+MMFCedBsJS_3KcPXcjOu97OsOkNt6D=rjR+foE-tDWHPgw@mail.gmail.com> <CA+RyBmWX8mvdZDs97hh-hjW6bcFrebz_3jbE-QxfCaSd5og=Ng@mail.gmail.com>
In-Reply-To: <CA+RyBmWX8mvdZDs97hh-hjW6bcFrebz_3jbE-QxfCaSd5og=Ng@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 09 Feb 2024 00:45:22 +0100
Message-ID: <CAOj+MMELcQLUFtfOMsWwSmMEbYKpP42atXuFuUhp_+thmRy=sg@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Mark Smith <markzzzsmith@gmail.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, Andrew Alston - IETF <andrew-ietf=40liquid.tech@dmarc.ietf.org>, SPRING WG <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000507f1c0610e76826"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/IPpXuCEsL9zS3Woioua95zKSRhw>
Subject: Re: [spring] draft-ietf-spring-srv6-srh-compression
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Feb 2024 23:45:40 -0000
Hi Greg, Just one nit ... > that reporting on-path telemetry can be done over the management plane Just for clarity I did not mean to report on mgmt plane. Just like MPLS networks were using IP data plane so here SRv6 networks are using IPv6 data plane. So I would actually prefer not to use mgmt plane for reporting OAM but regular data plane. Best, R. On Fri, Feb 9, 2024 at 12:37 AM Greg Mirsky <gregimirsky@gmail.com> wrote: > Hi Robert, > thank you for your clarification. I agree with you that reporting on-path > telemetry can be done over the management plane. I don't see any issues > with using C-SID specific to use of a two-way active measurement protocol > like STAMP. > > Regards, > Greg > > On Thu, Feb 8, 2024 at 1:45 PM Robert Raszuk <robert@raszuk.net> wrote: > >> Greg, >> >> The doubt here is not about test path which truley you are correct to be >> useful MUST follow data plane of real user traffic, but node on the path >> simply reporting the error or reporting the measurements to the collector. >> Hence those packets can be just IPv6 (modulo some VPN where we would need >> to identify such VPN within the payload of the reply). >> >> Do you see any issue with STAMP packets in networks using C-SIDs ? If so >> can you kindly describe it in detail ? >> >> Many thx, >> R. >> >> >> >> >> >> >> >> >> >> On Thu, Feb 8, 2024 at 10:30 PM Greg Mirsky <gregimirsky@gmail.com> >> wrote: >> >>> Hi Robert, >>> could you clarify "can be used"? Is it MAY, SHOULD or MUST? >>> If we use an active performance measurement protocol, e.g., STAMP, then >>> it is expected that the path of the reflected STAMP test packet traverses >>> the same set of nodes and links as the original STAMP test packet. Thus, >>> the Session-Reflector must use encapsulation that ensures the path >>> coroutedness for the reflected test packet, e.g., C-SIDs. >>> >>> Regards, >>> Greg >>> >>> On Wed, Feb 7, 2024 at 4:14 AM Robert Raszuk <robert@raszuk.net> wrote: >>> >>>> Hi, >>>> >>>> Actually for OAM responses in vast majority of cases vanilla IPv6 >>>> packets can be used. >>>> >>>> Kind regards, >>>> R. >>>> >>>> On Wed, Feb 7, 2024, 10:58 Mark Smith <markzzzsmith@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On Wed, 7 Feb 2024, 20:08 Robert Raszuk, <robert@raszuk.net> wrote: >>>>> >>>>>> Hi Mark, >>>>>> >>>>>> > however UDP and ICMPv6 would be for OAM per RFC 9269 >>>>>> >>>>>> I do agree if we are talking about no SRH containing packets. >>>>>> >>>>> >>>>> I think it would also occur with an SRH if a middlebox is ignoring the >>>>> SRH EH (e.g. unaware of how to handle it, or ignoring some or all IPv6 EHs) >>>>> and validating the pseudo-header checksum when the packet's current DA >>>>> isn't the final one, which of course it may not be if the packet is >>>>> somewhere where in flight between the origin SA and the final DA. >>>>> >>>>> For a middlebox to validate the L4 pseudo header checksum somewhere >>>>> during flight, it would have to determine the final DA for the calculation >>>>> by digging it out of the SRH rather than using the packet's current DA. >>>>> >>>>> Without an SRH the middlebox would have to process the C-SIDs in the >>>>> packet's DA field until it could identify the final DA before then >>>>> performing the L4 pseudo-header calculation and validation. >>>>> >>>>> The would be conditional on the SRv6 payload being TCP, UDP or ICMPv6 >>>>> and the middlebox being SRv6 aware (i.e. understand SRH when present) and >>>>> SR configured to identify C-SID DAs (SRH'less). >>>>> >>>>> So I don't really see how including an SRH in OAM packets solves the >>>>> problem unless the middlebox is SRv6 aware. >>>>> >>>>> And this is precisely why I said "vast majority of packets" not "all >>>>>> packets" >>>>>> >>>>> >>>>>> Glad that you nailed it on the list. >>>>>> >>>>>> Cheers, >>>>>> R. >>>>>> >>>>>> PS. What Ron suggests is too big of a hammer. Instead I see no reason >>>>>> why OAM packets should not contain SRH and resolve the nit that way. >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 7, 2024 at 5:44 AM Mark Smith <markzzzsmith@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, 6 Feb 2024, 03:17 Robert Raszuk, <robert@raszuk.net> wrote: >>>>>>> >>>>>>>> Hi Ron, >>>>>>>> >>>>>>>> Is there a problem ? >>>>>>>> >>>>>>>> If I read RFC8200 L4 checksum is computed by the packet *originator >>>>>>>> and validated by the packet's ultimate receiver. * >>>>>>>> >>>>>>>> In all SPRING work to the best of my knowledge the vast majority of >>>>>>>> packets are only encapsulated by transit nodes. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> If the payload of the SRv6 packet is another IP packet or layer 2 >>>>>>> frame e.g. Ethernet, common for L2 and L3 VPNs, then the layer 4 checksum >>>>>>> issue probably wouldn't occur, because those protocols don't include the >>>>>>> IPv6 pseudo-header fields in their checksum calculations if they even have >>>>>>> a checksum at all - RFC 2473 IPin IPv6 doesn't, and in GRE it is optional. >>>>>>> >>>>>>> However, if SRv6 was used to to directly carry an upper layer >>>>>>> transport layer protocol PDU like UDP, TCP or ICMPv6, then that's when the >>>>>>> checksum/middlebox issue arises, because they do include the IPv6 >>>>>>> pseudo-header in their checksum, which would therefore include the SRv6 SA >>>>>>> and DAs. >>>>>>> >>>>>>> Not sure if TCP would be commonly carried directly in an SRv6 >>>>>>> packet, however UDP and ICMPv6 would be for OAM per RFC 9269. >>>>>>> >>>>>>> So your SRv6 L2 or L3 VPN might be able to carry customer traffic >>>>>>> successfully through a middle box, however you may not be able to SRv6 >>>>>>> traceroute or ping across it successfully, or have ICMPv6 error >>>>>>> successfully sent between SRv6 nodes. >>>>>>> >>>>>>> Regards, >>>>>>> Mark. >>>>>>> >>>>>>> >>>>>>>> Is there any formal mandate in any of the RFCs that an >>>>>>>> encapsulating node must mangle the inner packet's L4 checksum ? I don't >>>>>>>> think so but stand open to get my understanding corrected. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Robert >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Feb 5, 2024 at 5:04 PM Ron Bonica <rbonica= >>>>>>>> 40juniper.net@dmarc.ietf.org> wrote: >>>>>>>> >>>>>>>>> Folks, >>>>>>>>> >>>>>>>>> Has anyone proposed a solution to the L4 checksum problem that >>>>>>>>> Andrew talks about? >>>>>>>>> >>>>>>>>> Ron >>>>>>>>> >>>>>>>>> Juniper Business Use Only >>>>>>>>> ------------------------------ >>>>>>>>> *From:* spring <spring-bounces@ietf.org> on behalf of Andrew >>>>>>>>> Alston - IETF <andrew-ietf=40liquid.tech@dmarc.ietf.org> >>>>>>>>> *Sent:* Monday, February 5, 2024 5:21 AM >>>>>>>>> *To:* spring@ietf.org <spring@ietf.org> >>>>>>>>> *Subject:* [spring] draft-ietf-spring-srv6-srh-compression >>>>>>>>> >>>>>>>>> >>>>>>>>> [External Email. Be cautious of content] >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> (In capacity as a contributor and wearing no other hats) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> At this point I cannot support progression of this document until >>>>>>>>> the issues around the L4 Checksum have been resolved. It’s been clearly >>>>>>>>> stated in other emails on the list that in certain circumstances the >>>>>>>>> behavior described in this document break the L4 checksum as defined in >>>>>>>>> RFC8200. This requires an update to RFC8200 to fix it – and I’m not sure >>>>>>>>> that spring can update 8200 absent the consent of 6man, which I’m not sure >>>>>>>>> has been asked for, nor am I sure that a spring document can update >>>>>>>>> something like 8200 in an area so fundamental as the checksum without a >>>>>>>>> -BIS, which would have to be done via 6man. The L4 checksum issue though >>>>>>>>> is real – and it cannot simply be ignored. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I also have deep concerns that the compression document creates >>>>>>>>> something that (in a similar way to SRv6) creates something that is >>>>>>>>> completely non-conformant with RFC4291. There are multiple references to >>>>>>>>> this in draft-6man-sids, and should draft-6man-sids become an RFC I would >>>>>>>>> argue that it should probably be a normative reference in this document – >>>>>>>>> on the logic that this document relies on similar RFC4291 violations that >>>>>>>>> srv6 itself does (and for the record, just because SRv6 itself violates >>>>>>>>> RFC4291 as is clearly documented in draft-6man-sids – does not make it >>>>>>>>> acceptable to do so in yet another draft without clear and unambiguously >>>>>>>>> stating the deviations and ideally updating RFC4291 to allow for said >>>>>>>>> deviations) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I believe these two issues alone are sufficient that to pass this >>>>>>>>> document would create still further tensions about the relationship between >>>>>>>>> SRv6 and IPv6 and lead to confusion. As such – I believe these issues need >>>>>>>>> to be adequately dealt with – and the solutions to them need to be approved >>>>>>>>> by 6man as the working group that holds responsibility for ipv6 maintenance. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Andrew Alston >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Internal All Employees >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> >>>>>>> _______________________________________________ >>>> spring mailing list >>>> spring@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spring >>>> >>>
- [spring] draft-ietf-spring-srv6-srh-compression Andrew Alston - IETF
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Ron Bonica
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Robert Raszuk
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Andrew Alston - IETF
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Nick Buraglio
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Antoine FRESSANCOURT
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Andrew Alston - IETF
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Tal Mizrahi
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Eduard Metz
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Nick Hilliard
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Nick Buraglio
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Ron Bonica
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Nick Hilliard
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Andrew Alston - IETF
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Robert Raszuk
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Miya Kohno
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Francois Clad
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Robert Raszuk
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Nick Buraglio
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Robert Raszuk
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Gyan Mishra
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Francois Clad
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Robert Raszuk
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Robert Raszuk
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Greg Mirsky
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Eduard Metz
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Robert Raszuk
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Francois Clad
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Mark Smith
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Mark Smith
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Greg Mirsky
- Re: [spring] draft-ietf-spring-srv6-srh-compressi… Greg Mirsky