Re: Other use cases for header insertion (was Re: Header Insertion and TI-FA)

[Fernando Gont <[e-mail]>]

Hello, Uma,

On 13/5/20 16:15, Uma Chunduri wrote:
[....]
>         That should be an indication that you should probably accept it, do 
> 
>         other smarts to reduce overall overhead,
> 
> This is relatively the easier part of the story. And we have already 'n' 
> (almost) proposal out there.
> 
> The one being discussed 
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-15 and 
> various other proposals

As far as I understand, e.g. this proposal doesn't propose header insertion.

And yes, if I were to do this, and was concerned about header size, I 
would certainly use smaller labels (as opposed to 128-bit labels) as in 
this document.



[..]
> 
> So, I see you are simply saying it's not possible to have both 
> efficiency and new requirements in a reasonable way (I know the 
> disagreement on

No. What I'm saying is that, if your concerned about overhead, avoid 
introducing it (as in the segment-routing header). Introducing overhead 
and then screwing up the architecture to make up for it is a no-go, IMO.



>   discussions. Given the barrier to change internet STD/8200 (even for a 
> clarification), we are kind of boxed with the current extensibility 
> constructs

My take is that, before screwing up the architecture, one should better 
do proper engineering where bits can be more easily saved, leading to a 
clean architecture.

IMO, al the TI-FA/PSP and earlier insertion proposals are horrible hacks 
mean to deal with:

* Boxes that claim to be IPv6-compatible but cannot even handle an IPv6 
header chain

* The overhead introduced with core blocks of the technology, such as 
the segment-routing header.

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