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

[Mark Smith <[e-mail]>]

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:
>>>>
>>>> Right, the idea is that at each node the input flow label and dst map
>>>> to an output flow label. All the flow label tables are constructed to
>>>> provide give loop free forwarding and multipath selection.
>>>
>>>
>>> That's essentially SR-MPLS :)
>>
>> If you look at the early history of the flow label, which predated MPLS,
>> this isn't a big surprise. (IPng-ologists also remember CATNIP,
>> https://tools.ietf.org/html/rfc1707.)
>>
>>>
>>> SRH would be unneeded in this solution.
>>>
>>>
>>> True - but I was just counting in general node's forwarding capabilites.
>>>
>>> I think the less moving parts we standardize the better :)
>>
>> It's true, but the flow label is already in every packet, albeit
>> with different semantics.
>>
>
> 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.

I think the less fiddling with packets in flight the better. Change
creates opportunities for failure, so the less change the better.
Encapsulation/decapsulation is much less change than EH insertion or
modification (and restoration if the original value was non-zero) of
the flow label. Change in the network, if necessary, should be
minimised.

The IPv6 SRH EH is obese because of the use of full 128 IPv6 addresses
as segment identifiers. It is not a requirement to use 128 bit values
as segment identifiers as in SR-MPLS they are only 20 bits i.e. the
MPLS label size.

Fix the SRH obesity problem and then there is no need to make a very
fundamental change to IPv6 EH processing, and no need force customers
to forklift upgrade their existing IPv6 networks to adopt SR
(tunnelled SR is an incremental upgrade, as SR implementations can be
plugged in on the side of existing IPv6 forwarding devices, similar to
the way Ipsilon added IP routing capabilities to ATM switches.)

The network wide forklift upgrade required to adopt this SR via EH
insertion will impact its rate of adoption. The cost of the solution
needs to be significantly cheaper than the cost of continuing to deal
with the problem to encourage adoption. Incremental upgrades rather
than forklift upgrades are cheaper in both capex and opex.

Regards,
Mark.