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

[Stefano Salsano <[e-mail]>]

Il 2017-12-01 23:07, Mark Smith ha scritto:

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

Hi Mark,

with the first tunneling operation you create a new packet that 
originates in your SR domain.

We definitely want it, so the further SR insertion will only be applied 
to such packets (and hosts outside the domain will not receive 
unexpected ICMP...) and we believe that it is worth paying the tunneling 
overhead here.

We think that for further operations that require adding of SRH 
information to such packets originating in your SR domain, the SR 
insertion is more efficient than tunnelling into a new packet.

This is both from the point of view of the packet size (and increase of 
packet headers size) and from the point of view of the cost of packet 
manipulation operations.

There can be scenarios in which you have more than one such operation to 
be applied to the packet, let us assume two. If you go for tunnelling 
you have the first encapsulation, then two more IPv6-in-IPv6 
encapsulation in the same packet, for a total of 3 encapsulations. If 
you go for tunneling + SR insertion you only have the first 
encapsulation and then "simple" mangling of SRH header.

ciao
Stefano

> 
> 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.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


-- 
*******************************************************************
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : [e-mail]
Cell.   : [phone]
Office  : (Tel.) [phone] (Fax.) [phone]
*******************************************************************