SRH insertion vs SRH insertion + encapsulation

[Robert Raszuk <[e-mail]>]

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 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
doyou 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 onthe
corridors had it that it had to do with one specific vendors havingissues
(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 theabstract is
"The network operator and vendor community has clearlyindicated 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 noidea
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 principleof
trying to avoid sending something unexpected and that the receiverwill 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.