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

[Gyan Mishra <[e-mail]>]

Hi Andrew

I am not sure if you are aware of this draft in Spring WG regarding L4
checksum updating RFC 8200.

Unfortunately maybe the draft should be re spun in 6MAN

https://datatracker.ietf.org/doc/html/draft-mizrahi-spring-l4-checksum-srv6-00

3 <https://datatracker.ietf.org/doc/html/draft-mizrahi-spring-l4-checksum-srv6-00#section-3>.
Checksum Computation Update

   This document updates the following text from Section 8.1 of
   [RFC8200] <https://datatracker.ietf.org/doc/html/rfc8200#section-8.1>
as follows:


   OLD:

If the IPv6 packet contains a Routing header, the Destination Address
   used in the pseudo-header is that of the final destination.  At the
   originating node, that address will be in the last element of the
   Routing header; at the recipient(s), that address will be in the
   Destination Address field of the IPv6 header.

   NEW:

   If the IPv6 packet contains a Routing header, the Destination Address
   used in the pseudo-header is that of the final destination.  At the
   recipient(s), that address will be in the Destination Address field
   of the IPv6 header.  At the originating node, that address will be
   the Destination Address as it is expected to be received by the
   destination.  Note, that if segment list compression
   [I-D.ietf-spring-srv6-srh-compression
<https://datatracker.ietf.org/doc/html/draft-mizrahi-spring-l4-checksum-srv6-00#ref-I-D.ietf-spring-srv6-srh-compression>]
is used, then the Destination
   Address as received by the destination may be different than the last
   element of the Routing header.  Similarly, if segment list
   compression is used without using the Routing header, then the
   Destination Address used in the pseudo-header is the address that is
   expected to be received by the destination.


AFAIK my interpretation of the problem and agree the fix is to update RFC
8200 with a bis to resolve as described below comparing SRv6 and SRv6 Next
SID processing behavior explaining how the draft above can fix the problem.

As pointed out in the draft SRv6 does not violate RFC 8200 L4 checksum on
the pseudo IPv6 header where the destination address is the final
destination and At originating node will be the last segment in the routing
header and at recipient the final destination address in the IPv6 header.
During SRv6 PGM pseudo code processing the last segment is copied from SRH
to DA and SL is decremented.  So the DA address matches the last segment
and do the L4 checksum is successful and the packet is not dropped.

With SRv6 C-SID Next SID at each SRv6 uN node sid SRv6 processing underlay
hop the uSID carrier is shifted by 16 bits and then the packet is forwarded
to new DA address.  In doing so the last segment in the C-SID Next SID
carrier does not match the final destination address due to the 16 bit uN
shift resulting in a new DA address to forward to and thus L4 checksum
fails .
So now if we step back for a second let’s analyze if the update to RFC 8200
is necessary and warranted given the use case of SRv6 compression C-SID
Next SID endpoint behavior.

I would like to now explain why AFAIK the L4 checksum issue I believe is
not applicable to the SRv6 compression draft.

When we talk about L4 checksum, we are talking about the transport layer /
Application layer of OSI model or TCP/IP model which sits in the overlay or
from a data plane perspective SRv6 IPv6 H.Encap.Red is the SRv6 C-SID
packet IPv6 outer header encapsulated "payload" which is the case for both
SRv6 as well as SRv6 Compression C-SID Next SID endpoint flavor ( uSID).

SRv6 CSID layering - routing protocol layering

(Underlay)      / (Overlay)
(ISIS/OSPF)    / (BGP)

SRv6 C-SID Frame format

Outer Header / Inner Header
{SRv6 C-SID} / {Payload - IPV4 / IPv6}
{IPv6 header} / {Ethernet / IPv4 or IPv6 header / TCP/UDP}

>From a routing protocol layering perspective the IGP - OSPF / ISIS are at
the underlay transport layer - think of “global routing  table GRT” ==>
SRv6 and C-SID sits at this layer.

This translates into the underlay transport layer SRv6 PGM RFC 8986
topological SIDs End ( Prefix sid) and End.X (Adj SID) ==> "global routing
table"

>From a routing protocol layering perspective BGP sits at the overlay layer
which in MPLS terms 2 level label stack is the L2 L3 VPN service layer BOS
(Bottom is Stack) S bit set analogous to SRv6 which has a flattened single
level label stack so to speak where the transport layer correlates to the
SRv6  Locator and the service layer L2 VPN EVPN and L3 VPN label at data
plane layer are encoded into Func/Arg field at data plane layer and control
plane layer defined in SRv6 BGP Service  Overlay RFC 9252 where the L2 and
L3 VPN Service SID is encoded into BGP prefix sid and for the optional BGP
update packing transposition scheme common part locator encoded into BGP
prefix sid and non common part Func/Arg L2 / L3 VPN label encoded into the
NLRI.

So the application layer where the L4 checksum mentioned in RFC 8200
section 8.1 would reside for SRv6 compression Next SID (uSID) is at the
overlay layer BGP routing and thus end to end application flow would be
unfettered untouched and preserved end to end intra-as or inter-as.  AFAIK
no L4 checksum issue.

I would like to provide some clarity related to RFC 3234 Middle boxes
taxonomy and middleware and applicability to SRv6 & SRv6 compression
draft.

Middle boxes in a heterogeneous environment could possibly exist in the
SRv6 core or data center or any network and could be a firewall, load
balancer CGNAT appliance etc or in a cloud native NFV virtualized
environment could be a Kubernetes K8 worker node container CNF or RHEL
Openshift or docker container.  All of these possible middle box appliance
use cases would be attached to the global table underlay which provides the
linkage between SRv6 fabric and middle box device.  The middle box device
could be vanilla SRv6 unaware and in that case the packet that traverses
the middle box would be a simple IPv6 packet.  For a middle box device that
is SRv6 capable would be connected to the global table like any other SRv6
node and perform the C-SID Next SID endpoint function Ua shift 16 bits and
forward.  The application layer in this scenario  with the middle boxes
providing service chaining would be in the L2 VPN or EVPN overlay payload
 layer which remains unfettered untouched end to end and thus the L4
checksum completes successfully for any application flow.

Middleware -  sits as well at the application payload layer and thus no
impact to L4 checksum which completes successfully.

What is middleware?

Middleware
<https://www.techtarget.com/searchdatamanagement/news/252496430/Matillion-raises-100M-for-ETL-to-enable-data-middleware>
 is software that is used to bridge the gap between applications and
operating systems. Middleware sits between an operating system and the
applications that run on it to provide a method of communication and data
management
<https://www.techtarget.com/searchdatamanagement/definition/data-management>.
This is useful for applications that otherwise would not have any way to
exchange data -- such as with software tools and databases.

Middleware is used commonly, as many organizations and developers use
middleware to build applications more efficiently. For example, middleware
can be used in application integrations to link both applications together.
Organizations that use multi-cloud
<https://www.techtarget.com/searchcloudcomputing/definition/multi-cloud-strategy>
 and containerized environments will often also use middleware as a more
cost-effective way to develop and scale applications.

Some examples of middleware activities include its use in handling data and
API
<https://www.techtarget.com/searchapparchitecture/definition/application-program-interface-API>
 management, authentication and messaging services.
Why is it called middleware?

The name *middleware* stems from it being software that sits between the
client-side requests on the front end
<https://www.techtarget.com/whatis/definition/front-end> and the back-end
resource being requested.
Hopefully this helps clear up questions and why RFC 8200 section 8.1 L4
checksum is not applicable to any real world use cases for SRv6 compression
deployments.

*draft-6man-SIDs is on its way to progressing to RFC and agree should be a
normative reference to this compression draft.  Agreed.  I think this would
be beneficial to the SRv6 compression draft publication. *

https://datatracker.ietf.org/doc/draft-ietf-6man-sids/

One key point to note with SRv6 and SRv6 compression is the applicability
to only closed domain or OAD (One Adminstrative Domain).  Please keep that
in mind in regards to these two issues.

The draft does a good job making it clear that SRv6 SIDs are to be used
only for forwarding and not delivering packets to end hosts.  That is
exactly the point I am making that the underlay which is where SRv6
compression draft C-SID resides and the L2 / L3 VPN or global table BGP
overlay is where delivery of packets to end hosts resides.

As I mentioned above in the L4 checksum and its applicability to the
overlay payload and not underlay transport.  The same applies to the SRv6
SIDs and their locator addressing and that their sole purpose in life is
forwarding using topological sids as they are not applicable to any
interface on any router, appliance or host endpoint.

IPv6 addressing defined in RFC 4291 is for standard interface addressing
for any router, appliance or host endpoint which is completely not
applicable to SRv6 compression C-SID draft.

Section 4 nicely describes C-SID addressing below:

[CSID
<https://www.ietf.org/archive/id/draft-ietf-spring-srv6-srh-compression-09.txt>
] introduces an encoding for compressed segment lists (C-SIDs), and
describes how to use a single entry in the Segment list as a container for
multiple SIDs. A node taking part in this mechanism accomplishes this by
using the ARG part [RFC8986 <https://www.rfc-editor.org/info/rfc8986>] of
the Destination Address of the IPv6 header to derive a new Destination
Address. i.e., the Destination Address field of the packet changes at a
segment endpoint in a way similar to how the address changes as the result
of processing a segment in the SRH.¶
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids-05#section-4-1>

One key thing to note here is that the Locator Block at the beginning of
the address does not get modified by the operations needed for supporting
compressed SIDs. As we have established that the SRv6 SIDs are being
treated simply as routing prefixes on transit nodes within the SR domain
this does not constitute a modification to the IPv6 data plane on such
transit nodes and any changes are restricted to SR aware nodes.¶
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids-05#section-4-2>
Maybe some of section 4 verbiage could be even applied to the C-SID draft
operational considerations section.

Kind Regards

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*



On Mon, Feb 5, 2024 at 5:22 AM Andrew Alston - IETF <andrew-ietf=
[e-mail]> wrote:

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