Re: SRH insertion vs SRH insertion + encapsulation

[Robert Raszuk <[e-mail]>]

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.

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