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

[Tom Herbert <[e-mail]>]

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,
>>
>> The exlcusion that the flow label might be change for "compelling
>> operational reasons" is in practice interpreted as the flow label may
>> change in flight (i.e. receivers and network nodes cannot assume flow
>> label doesn't change). So while doing something like this might be
>> against the spec as written, I have to think this is potentially much
>> less problematic and less churn than changing RFC8200 to allow
>> extension header insertion.
>>
>
> During the specification update of the Flow Label to better formalise
> it, I suggested Flow Label domains, with the analog being DSCP
> domains. That would have facilitated this sort of use. However, that
> was rejected - see Appendix A of RFC6436.
>
> I agree using the flow label is less intrusive than EH insertion,
> however it is still a fundamental change to IPv6 packet forwarding.
> It's already going to be a slow process to have IPv6 forwarding
> devices start using the Flow Label as a load balancing input.
>
> The idea to use the Flow Label for forwarding/switching goes back as
> far as 2004, and didn't get legs.
>
> https://datatracker.ietf.org/doc/draft-chakravorty-6lsa/
>
> I don't understand why the SRH header is considered set in concrete,
> or more specifically how segments are identified in an IPv6 network,
> while far more fundamental changes to IPv6 forwarding are considered
> fine. I don't think SR has been widely deployed, and probably less so
> over IPv6 networks using EH insertion. It's a technology that is only
> a 3 or 4 years old (or something like that), compared to IPv6 which is
> now more than 20 and easily accessible in as early as 1998 (I was
> playing with Linux's implementation then, and Cisco's implementation a
> year later). 20 year old IPv6 forwarding implementations and
> deployments would be 100% compatible with SR based on tunnelling.
>
> 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.

But even more important than the size of the headers, is the
processing cost. Processing fixed encapsulation at high speed is
expensive. Processing open ended header chains and TLVs is _really_
expensive to the point that they to date they are undeployable. 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.
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,

Tom