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

[Mark Smith <[e-mail]>]

Hi Brian,

On 1 December 2017 at 11:15, Brian E Carpenter
<[e-mail]> wrote:
> On 01/12/2017 10:27, Mark Smith wrote:
>> On 1 Dec. 2017 6:35 am, "Robert Raszuk" <[e-mail]> wrote:
>>

<snip>

>
> What I'm seeing in this thread are rational arguments for and against
> the proposal. I agree about the logical fallacy in the abstract of the
> current draft, but that's fixable with a few seconds use of the cursor
> and Delete key. I'd like to see the rational arguments in the next version
> of the draft.
>

While they may have perhaps been lost in the discussion before, they
were asked for in the previous discussions of the -00 draft.

I asked numerous times (at least 3 from memory), what is wrong with
exclusively using tunnelling for this. I think eventually Robert said
because of the tunnelling overhead.

The trouble with this argument is that this draft doesn't exclusively
propose extension header insertion, it also describes using
tunnelling. The only distinction between which method to use is
whether the packet originates within the SR domain ("Source Domain and
Packet Journey") or originates externally to it ("Transit through a
Source Domain"). So tunnelling overhead is apparently quite acceptable
as long packets happen to come from outside the SR domain. I can't see
anything that explains why packets that originate internally can't or
must not be tunnelled.

So the example SR domains in the draft, which is presumably the same
domain, support both insertion and tunnelling to achieve the same and
single goal of adding SRH information to a packet. Seems unnecessarily
complex to support two methods that achieve the same functional
outcome. More prone to vendor bugs, harder to troubleshoot, more
things to learn and then forget if not used often.

More broadly, I assume the reason to try to use IPv6 for this, rather
than either sticking just with MPLS or inventing something new, is to
leverage IPv6's existence, widely available implementations and pretty
close to current and definite future commoditisation. Leveraging what
already exists for the cost and time benefit may mean making some
compromises to gain from commoditisation.

RFC8200 IPv6 forwarding and IPv6-in-IPv6 tunnelling are commodity,
because they're methods as old as RFCs 1883 and 2473, and are widely
implemented and deployed. Extension Header insertion is not, and
therefore using it is de-commodifying IPv6. The commodity benefits of
IPv6 disappear if fundamental changes are or need to be made to IPv6's
operation. EH insertion is a fundamental change.

I think the objection to tunnelling is really be because the IPv6 SRH
header is too large, because of the use of 128 bit IPv6 addresses as
segment identifiers. "Scrounging" bits somewhere else to try to
minimise overhead is avoiding solving the problem where it is caused.

The TRILL people had this problem, as they considered 7 octet IS-IS
IDs to be too large to include in the TRILL header. They solved it be
using 16 bit "nicknames".


"3.7.  RBridge Nicknames

   Nicknames are 16-bit dynamically assigned quantities that act as
   abbreviations for RBridges' IS-IS IDs to achieve a more compact
   encoding ..."

https://tools.ietf.org/html/rfc6325#section-3


Regards,
Mark.