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

[Greg Mirsky <[e-mail]>]

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
>