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

[Mark Smith <[e-mail]>]

Hi Tom,

Sorry not to get back to you sooner.

On 7 December 2017 at 08:32, Tom Herbert <[e-mail]> wrote:
> On Wed, Dec 6, 2017 at 11:52 AM, Mark Smith <[e-mail]> wrote:
>> Hi Tom,
>>
>> On 6 December 2017 at 07:24, Tom Herbert <[e-mail]> wrote:
>>> On Tue, Dec 5, 2017 at 11:59 AM, Mark Smith <[e-mail]> wrote:
>>>> On 5 December 2017 at 08:28, Bob Hinden <[e-mail]> wrote:
>>>>>
>>>>>> On Dec 2, 2017, at 2:15 PM, Brian E Carpenter <[e-mail]> wrote:
>>>>>>
>>>>>> On 03/12/2017 08:53, Robert Raszuk wrote:
>>>>>>>>
>>
>> <snip>
>>
>>>>>
>>>>> I will add that swapping flow labels as I think Tom Herbert was proposing has much less side effects than inserting and processing extension headers.
>>>>
>>>> Which would then violate the Flow Label spec unless the Flow Label
>>>> value is zero.
>>>>
>>> Mark,
>>>

<snip>

>> I can think of a number of ways that SR segments can be identified
>> that would be compatible with IPv6 forwarding that would reduce the
>> size of the SRH EH
>>
>> - as suggested before, unique /64 per device, with the /64 carried in
>> the SRH TLV, reducing the TLV size by 8 octets.
>>
>> - well known or locally selected single /64 for the SR function, then
>> unique 64 bit IID per device, with the 64 bit IID carried in the SRH
>> TLV, reducing the TLV size by 8 octets. This could be automatically
>> generated via a PRNG. It would be safer to check for collisions,
>> although probably not necessary.
>>
>> - well known or locally selected single /64 for the SR function,
>> segment IDs 20 bits to match SR-MPLS IDs, 20 bits carred in the SRH
>> TLV, reducing the TLV size by 13 octets.
>>
> Mark,
>
> I don't see how that's going to help much. The authors of this draft
> have already stated that in order to doing EH insertion they will need
> to encapsulate when packets enter the SR domain, so that's forty-bytes
> of overhead right of the bat. And then there's the fixed overhead of
> the EH before we finally get to the savings of compressing the EH
> data.
>

So my understanding of the fundamental problem SR is trying to solve
is to remove (MPLS) path state and path monitoring RSVP load from the
control plane. I think this is a good idea, as I think packet networks
scale by pushing complexity out of the network and towards the edge
("dumb network, smart hosts").

The path information is instead shifted to the each packet, carried in
the SRH. While I think using IPv6 addresses to identify hops in an
IPv6 networks is an obvious first choice, it does add considerable
per-packet overhead. 128 bits hop identifiers aren't necessary if
SR-MPLS only needs and uses 20 bits for the same purpose. The schemes
I suggested before would still carrying IPv6 forwarding compatible hop
identifiers while reducing this overhead.

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.



> 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).

> 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.

Regards,
Mark.