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 <rob...@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 <gregimir...@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 <rob...@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 <markzzzsm...@gmail.com> wrote: >>> >>>> >>>> >>>> On Wed, 7 Feb 2024, 20:08 Robert Raszuk, <rob...@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 <markzzzsm...@gmail.com> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, 6 Feb 2024, 03:17 Robert Raszuk, <rob...@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....@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-boun...@ietf.org> on behalf of Andrew >>>>>>>> Alston - IETF <andrew-ietf=40liquid.t...@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 mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
