Hi Robert, I imagine that a management plane, e.g., IPFIX, can use the IPv6 dataplane as the underlay.
Regards, Greg On Thu, Feb 8, 2024 at 3:45 PM Robert Raszuk <rob...@raszuk.net> wrote: > 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 <gregimir...@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 <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
