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

[Greg Mirsky <[e-mail]>]

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
>>>
>>