Re: [spring] draft-ietf-spring-srv6-srh-compression

[Robert Raszuk <[e-mail]>]

Oh I see ... I have understood that you are talking about the OOB mgmt
plane.

So we are all in sync !

Best,
R.

On Fri, Feb 9, 2024 at 12:50 AM Greg Mirsky <[e-mail]> wrote:

> 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 <[e-mail]> 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 <[e-mail]>
>> 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 <[e-mail]> 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 <[e-mail]>
>>>> 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 <[e-mail]>
>>>>> 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 <[e-mail]> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, 7 Feb 2024, 20:08 Robert Raszuk, <[e-mail]> 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 <[e-mail]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, 6 Feb 2024, 03:17 Robert Raszuk, <[e-mail]>
>>>>>>>>> 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=
>>>>>>>>>> [e-mail]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Folks,
>>>>>>>>>>>
>>>>>>>>>>> Has anyone proposed a solution to the L4 checksum problem that
>>>>>>>>>>> Andrew talks about?
>>>>>>>>>>>
>>>>>>>>>>>                                           Ron
>>>>>>>>>>>
>>>>>>>>>>> Juniper Business Use Only
>>>>>>>>>>> ------------------------------
>>>>>>>>>>> *From:* spring <[e-mail]> on behalf of Andrew
>>>>>>>>>>> Alston - IETF <andrew-ietf=[e-mail]>
>>>>>>>>>>> *Sent:* Monday, February 5, 2024 5:21 AM
>>>>>>>>>>> *To:* [e-mail] <[e-mail]>
>>>>>>>>>>> *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
>>>>>>>>>>> [e-mail]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> spring mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>> spring mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>>>
>>>>>