Re: SRH insertion vs SRH insertion + encapsulation

[Mark Smith <[e-mail]>]

On Sat, 7 Sep 2019 at 21:09, Robert Raszuk <[e-mail]> wrote:
>
> Hello,
>
> I took liberty to start a new thread to focus on hopefully technical discussion regarding the subject.
>
> For the other long thread we have had between WGs to me the conclusion and maybe even IETF rough consensus is that SRH insertion when done at the same time with IPv6 encapsulation is ok.

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