With regard to service chaining, with either SRv6 or SRv6+, the
interoperable mechanism for service function chaining is to carry NSH.
Carrying the content of the NSH header in SRv6 SRH PDUs, while
technically doable, is complexity that is not needed.
Yours,
Joel
On 9/7/2019 6:54 PM, Robert Raszuk wrote:
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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
