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.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
