Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

[Fernando Gont <[e-mail]>]

On 28/5/20 19:49, Kamran Raza (skraza) wrote:
[...]
>   
> I do not support the WG adoption of this document.
>   
> In addition to numerous technical and other points made by others on the list already, I would like to highlight the tax this proposal puts on ASICs/hardware:

It is interesting, because the PSP behaviour that Spring shipped in 
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-15 
is apparently meant to deal with implementations that cannot even ignore 
a RH where SL==0, as required by RFC8200.

If anything, it would seem to me that shorter headers would make life 
easier when it comes to processing the headers.




> 2) VPN Service's DOH header processing:
> For CRH based solution, the VPN context is encoded in a Dest Opt header located after the CRH which adds the following challenges:
> - At the egress PE, the packet arrives with both CRH and Dest Opt headers. The egress PE first needs to process the CRH to see whether SL = 0 and ignore the rest of it.
> - Then, it needs to process DoH and the options within it. This overall combination will be challenging for many ASICs.

Welcome to the IPv6 world. If you can't handle this, you are not 
compliant with RFC8200.

As before, these comments are neither in favor nor against CRH, but 
rather against about bogus arguments.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492