Re: SRH insertion vs SRH insertion + encapsulation

[Mark Smith <[e-mail]>]

On Sat, 7 Sep 2019 at 22:40, Robert Raszuk <[e-mail]> wrote:
>
> Hi,
>
> Mark, Fernando, Tom - many thx indeed.
>
> For me word "insertion" was not a reserved word. I think I now start to understand the rationale on how and why you reacted like you did. Especially if you say that "insertion" by definition is/must be anonymous.
>

It's also the splitting apart of existing packets. That is not an
standard IPv6 operation. Only encapsulation/de-encapsulation is.

Splitting packets apart is far more complicated than encapsulation
particularly when there may be existing EHs in the packet, and more
complicated than identifying packets to be de-encapsulated and
processed just by their Destination Address, which is the standard
IPv6 (and IPv4) way to identify packets that are to be processed by
the local node other than using forwarding.

Note the RFC 8200 definition of a router and a host, which are
functional definitions (although we all would usually think of them as
devices):

  router       a node that forwards IPv6 packets not explicitly
                addressed to itself.  (See Note below.)

   host         any node that is not a router.  (See Note below.)

(For completeness, part of the Note

"Note: it is possible for a device with multiple interfaces to be
   configured to forward non-self-destined packets arriving from some
   set (fewer than all) of its interfaces and to discard non-self-
   destined packets arriving from its other interfaces.")

If an SR device is using something else other than a packet's DA to
determine whether to process the packet beyond the IPv6 fixed header
locally, or to forward it, then it isn't an IPv6 router or an IPv6
host. It's undefined, and quite probably a middle box. (It may
physically look like a router, but it's functions that matter in the
context of protocols.)

Regards,
Mark.

> So if this is what drives all of the opposition to place SRH into a IPv6 header without encapsulation then I think there easy ways to fix it.
>
> I will then talk to some other others about options they are willing to incorporate into relevant documents.
>
> Many thx,
> R.
>
>
>
>> Yes, however I don't consider there to be any "insertion" happening at
>> all in that scenario, and I don't think anybody else in the IPv6 6man
>> WG would either.
>>
>> "EH insertion" is splitting apart an existing IPv6 packet after the
>> IPv6 header and before the payload, inserting the EH, creating or
>> modifying an existing EH chain, leaving the packet's original source
>> and destination address as they were.
>>
>> This is why EH insertion is anonymous - the source address in the
>> packet is not the identity of the device that inserted the EH. The EH
>> insertion being anonymous is what causes all the problems - breaking
>> PMTUD, IPsec, ICMP in general, causing problems if the EH isn't
>> removed when it should be, and making troubleshooting much harder.
>>
>> Encapsulation in another new IPv6 packet creates the option to add,
>> not insert, new supplementary information via EHs.
>>
>> From RFC 2473, "Generic Packet Tunneling in IPv6 Specification"
>>
>>                             +----------------------------------//-----+
>>                             | Original |                              |
>>                             |          |   Original Packet Payload    |
>>                             | Header   |                              |
>>                             +----------------------------------//-----+
>>                              <            Original Packet            >
>>                                               |
>>                                               v
>>        <Tunnel IPv6 Headers> <       Original Packet                 >
>>
>>       +---------+ - - - - - +-------------------------//--------------+
>>       | IPv6    | IPv6      |                                         |
>>       |         | Extension |        Original Packet                  |
>>       | Header  | Headers   |                                         |
>>       +---------+ - - - - - +-------------------------//--------------+
>>        <                          Tunnel IPv6 Packet                 >
>>
>>                        Fig.3 Encapsulating a Packet
>>
>> SRH, OAM etc. EHs that are added to the original packet would go in
>> the "IPv6 Extension Headers" area shown in the lower packet of that
>> diagram, after the new outer tunnel header.
>>
>> Encapsulation/Decapsulation is an addition/subtraction operation of
>> new, non-original sender information. It preserves the original packet
>> as it was when it was originally sent.
>>
>> It provides a new source address field to identify the device that
>> performed the encapsulation and that added the supplementary
>> information via the added EHs.
>>
>> It provides a new destination address field to unambiguously identify
>> which device the added EH information is intended to be processed by.
>> There is no need for these EH processing devices to be looking beyond
>> the IPv6 fixed header to determine if there are any EHs for them to
>> process - if it is for them, it is a simple and IPv6 standard packet
>> DA to device DA match operation which answers that question. If it is
>> not for them, the forward it via their FIB.
>>
>> Yes encapsulation adds overhead, however that overhead makes
>> everything compliant with existing decades old methods, models, tools,
>> operations and troubleshooting techniques.
>>
>> Regards,
>> Mark.
>>
>>
>> >and if any document would like to take that path fwd there is no objections from 6man in regards to violation or not of any former 6man or IPv6 consensus.
>> >
>> > - - -
>> >
>> > So on the very topic let me summarize the observations made in various emails:
>> >
>> > #1
>> >
>> > The draft in question doesn't comment on the most basic question: why do
>> > you want to do EH-insertion as opposed to encap/decap into a new packet?
>> >
>> > I asked this question a number of times, and nobody answered.. Rumor on
>> > the corridors had it that it had to do with one specific vendors having
>> > issues (of some sort) with implementing this with doing encap/decap. --
>> >
>> > Looks to me like FUD at best - just suffice to read (with understanding)
>> >
>> > draft-matsushima-spring-srv6-deployment-status-01
>> >
>> > - - -
>> >
>> > #2
>> >
>> > EH insertion will increase the MTU of the packet.
>> >
>> > It sure will but as already stated this is done within a given domain so someone who is doing insertion better makes sure it is not causing packet drops. Otherwise his customers may be pretty unhappy.
>> >
>> > If you do EH insertion + encapsulation to my basic math skills it looks like you are creating even bigger packet. So you are more likely to face MTU bottleneck issues.
>> >
>> > - - -
>> >
>> > # 3
>> >
>> > I also have a nit about that draft. The very first line of the
>> > abstract is "The network operator and vendor community has clearly
>> > indicated that IPv6 header insertion is useful and required."
>> >
>> > I agree - such statements should not be in the IETF standards track document.  Such document should be judged on its technical merits not on a basis of crusade.
>> >
>> > - - -
>> >
>> > # 4
>> >
>> > The draft doesn't say why insertion is considered necessary. There is no justification presented.
>> >
>> > Well I can understand why one may say so if he does not follow years of FRR/LFA/R-LFA and now TI-LFA discussions. In a nut shell one technique of provide fast connectivity restoration is based on the fact of local repair with local bypass of the broken fragment of the network in a loop free manner. That requires some form of controlled packet steering around the failure.
>> >
>> > There are many techniques to achieve such steering SR is an elegant one for this specific application. The less bits you add to the packet the better. Usually you are fine with just one SID or in number of topologies you actually do not need any SID so just placing original dst address into SRH and applying new dst address may be all what is required.
>> >
>> > I understand that for some FRR techniques do not matter .. some may use completely different end to end techniques (I like those btw :) but for some it has been a necessity to provide best service to their customers.
>> >
>> > - - -
>> >
>> > #5
>> >
>> > There is no statement that says, "When using IPv6 tunnelling with 128 bit SIDs, the per packet overhead can become too high."
>> >
>> > The proposal to use insertion without encap saves you up front 320 bits. I think the less bits you put in *each* packet the better. As described in #4 - in vast majority of TI-LFA you only need one external anchor to safely bypass the failure so in fact no need for any SIDs as the original dst will be either in inner header or in inserted SRH. So your repair efficiency as far as extra packet size already  is more then 2 times less when doing SRH insertion vs SRH or CRH insertion with encapsulation.
>> >
>> > - - -
>> >
>> > # 6
>> >
>> > EH insertion is entirely anonymous. If something breaks, you have no
>> > idea of which device inserted the EH.
>> >
>> > If inserted SRH contains the routable identified of the network element which inserted the header does this address this point ?
>> >
>> >
>> > - - -
>> >
>> > # 7
>> >
>> > EH insertion sounds to me like it is breaking a fundamental principle
>> > of trying to avoid sending something unexpected and that the receiver
>> > will be confused by.
>> >
>> > If EH is removed within the domain it has been inserted end receiver never sees it.
>> >
>> > = = =
>> >
>> > I think I see why in general you all consider that EH insertion alone would be a bad thing. But I think here we are not talking about any insertion to be allowed. We are discussing a fixed and well defined extension which could be made sure that all valid hooks to address potential concerns are embedded in its encoding yet still maintaining forwarding efficiency.
>> >
>> >
>> > I think now it is up to 6man WG and chairs how they choose to continue this dialogue.
>> >
>> > Many thx,
>> > R.
>> >
>> >
>> >
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > [e-mail]
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------