Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt

[Tom Herbert <[e-mail]>]

> EH insertion to avoid tunnelling overhead as a response to a large SRH
> header because of 128 bit hop identifiers is just shifting complexity
> that has been moved out of the control plane by SR back into the
> network, and into the forwarding plane. I think IPv6 SR looses a lot
> of value if it shifts complexity in the network rather than removing
> it.
>
I suspect that if EH insertion can't be done without encapsulation
then the value proposition for using extension headers here largely
evaporates The overhead of encapsulation is not insignifanct and the
issues of incompatibility of using any EH are still present. An
alternative is to put the routing information as payload of the
encpasulation instead of EH. That is the approach taken by BIER for
instance. For the cost of an eight byte UDP header they get
compatability on any network (and with IPv4 for that matter).

>
>
>> But even more important than the size of the headers, is the
>> processing cost. Processing fixed encapsulation at high speed is
>> expensive.
>
> I don't think that's avoidable (although it has occurred to me that
> when IPv6 becomes ubiquitous, it might be possible to use it directly
> as a the layer 2 on-the-wire frame format).
>
Considering that everything is pretty much layer 3 switched point to
point links you could do that. But probably more hassle to change
everything than it's worth.

>> Processing open ended header chains and TLVs is _really_
>> expensive to the point that they to date they are undeployable.
>
> Agree. This is why the divide-and-conquer approach of pushing
> complexity to the edge of the network and into the hosts helps us
> build faster and faster networks.
>
> The simpler the processing in the network, the faster it can be done
> and it's also less prone to error because there are less things that
> can go wrong.
>
> With NAT and middleboxes in IPv4, we've ended up with more complexity
> in the network and I've had enough experiences with that that I want
> to the simplicity of IPv4 networks before NAT and middleboxes back in
> IPv6.
>
>
>
>> While
>> I appreciate the optimism of the authors that the problem of
>> processing EH TLVs at line rate has been solved, I must admit I am
>> skeptical. It is hard to ignore a long history which has not been kind
>> to header chains or TLVs in IP.
>>
>> The obvious value of using something like the flow label is that it is
>> a zero overhead solution in the wire protocol. No encpasulation and no
>> EH. The route lookup for this could be implemented in a TCAM on
>> src,dst,flow label and the action is just to write a 20 bit value.
>
> Using the flow label has the advantages you mention, however updating
> it is still putting complexity back into the forwarding plane, and is
> a fork lift upgrade of the forwarding plane to get it.
>
> The use of the flow label for ECMP also faces this forwarding plane
> upgrade problem, although much less so - the upgrade to gain it is
> localised to the parts of the network where you need it. You don't
> need to universally upgrade all your forwarding plane devices just to
> gain flow label ECMP balancing across multiple links between two of
> your forwarding plane devices.
>
> Broadly, there seems to be a view that flag day upgrades are
> acceptable for new network technologies. That's a far more expensive
> and disruptive way to upgrade the capabilities network than the
> piecemeal, incremental and localised method that has been used to
> build the Internet since the ARPANET flag day. I don't think it should
> be preferred, I think it should be the last resort.
>
>
>> ILA, which serves the overlay network use case, is even simpler-- this
>> is a fixed length lookup on the destination and a write back to the
>> destination address. Flow label is not used and no change to standard
>> protocols is required,
>>
>
> Agree. I think ILA's techniques are much better because they leave the
> core forwarding plane alone, with the ILA changes occurring either in
> the host or in the first hop network device. The IPv6 forwarding plane
> remains conventional, simpler and standard.
>
Less is more!

Tom

> Regards,
> Mark.