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

[Fernando Gont <[e-mail]>]

On 13/5/20 12:28, Uma Chunduri wrote:
> 
> 
>     On Wed, May 13, 2020 at 3:50 AM Stewart Bryant
>     <[e-mail] <mailto:[e-mail]>> wrote:
> 
>         I am glad that we accept the NP is not SR!  Although it took a
>         long time to get there, both in terms of the disintertwining and
>         realisation that the concept was needed. It is a long time since
>         I read it, but I am concerned about whether it has the full
>         generality of the opaque instruction that MPLS has.
> 
> I guess, it has.
> 
>         Assuming that it has the next issue and it is one we are
>         discussing here is the overhead of adding a new instruction to a
>         packet in flight.
> 
> That overhead per 8200 is 40 bytes aka encapsulation (with all good 
> reasons raised again and again why it has to be like that in L3), where in
> 
> L2.5 it is 4 bytes.  Though we may never get to 4 bytes we don't want it 
> to be 40 bytes, that's the holy grail of insert discussion (push).

So you want IPv6, but don't want 40 bytes of overhead. Well, I tell you 
what: those 40 bytes of overhead *are* IPv6.

That should be an indication that you should probably accept it, do 
other smarts to reduce overall overhead, or you might need to look at a 
different protocol.

I find it amusing to use 128-bit labels for what's pretending to be a 
limited domain, and then be concerned about the overhead of the ipv6 header.

As much as I find amusing to have nodes that claim to support IPv6 (and 
hence should be able to ignore a RH that has a SL==0) but they violate 
the spec and fail miserably, so then there's a proposal to violate the 
spec (PSP) to cope with that.


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