Re: [spring] Regaining Focus on SRv6 and SRv6+

[Robert Raszuk <[e-mail]>]

Hey Ron,

You may need to rethink your argument. (That is, except for the part where
> you said that I was smart!)
>

;-)


> The SRv6+ PPSI does replaces something int SRv6. But it does not replace
> the SRH’s tags, flags or TLVs. It replaces the low order bits in the last
> SID. More specially, it identifies a function to be executed by SR egress
> node. It replaces functions like END.DT4, END.DT6, END.DX4, END.DX6, etc.)
>
>
>
> As Tom says,  the CRH is much simpler to parse that the SRH. It contains
> only five fields, four of which are mandated by RFC 8200. (The other is the
> SID list.)
>


The point is that CRH alone is not enough to make any jugement about SRv6+
complexity.



> Unlike TLVs, the PPSI is fixed length (32 bits). It identifies an
> instruction to be executed on the SR egress node. Carries the same
> information as an MPLS service label or the low order bits of the final SID
> in as SRv6 SID list.
>

When you can provide pointer to SFC document describing how it would work
with SRv6+ similar to
https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-00 which
does require many elements from SRH we will resume the discussion.


What you say about the IPv6 Option registry being nearly full may be a bit
> of an exaggeration. This is because the CHG bit is meaningful of hop-by-hop
> options, but is totally meaningless for Destination options. So, for
> destination options, the IPv6 option registry is actually 6 bits wide.
>

Are you proposing to split this registry into two ? to get 32 more values
for your destination options types ? And then what ?

Best,
R.

PS from your last mail ...

> Prepend an IPv6 header with its own Routing header

So this is exactly what I was concluding. The packet under TI-LFA
protection in SRv6+ will end up with three IPv6 fixed headers, min two CRH
headers, and anywhere from zero to two (depending on the functions
required) Dest Options header before Routing Header.