Re: SRH insertion vs SRH insertion + encapsulation

[Fernando Gont <[e-mail]>]

On 7/9/19 14:08, Robert Raszuk 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 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. 

Since it has become kind of a tradition for proponents of EH insertion
to have interesting interpretations of standards, let me repeat:

If you originate a packet, you can include you EHs (within the
constraints of RFC8200) because it is a *new* packet. That's not called
"insertion".

If you are not the origin of the packet, you cannot insert EHs in the
packet you received -- RFC8200 forbids EH insertion for the reasons
mentioned in the relevant threads.



> 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

So you are telling me that the document that proposes EH insertion
doesn't contain the rationale for it, and we should go and look elsewhere?

Besides, I've just looked at the I-D you reference. The only thing there
about insertion is that there are folks that have deployed it.

So.. let me try to understand: A vendor went ahead and implemented what
they pleased, violating existing standards. They now come to 6man and
claim that we should modify the standard because even when what they are
proposing is forbidden in our specs, they have already deployed it.

Are we being taken seriously?



> #2 
> 
> *EH insertion will increase the MTU of the packet. *

*and* attribution of the possible errors -- for whatever reason.

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

The packet is bigger. But in the event of errors, they are delivered to
the originator of the packet. That's how our "architecture" works.




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

That doesn't answer the question. PLease let me rephrase: what are you
doing with EH insertion that you couldn't do with encap/decap?



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

You are breaking IPv6 ent to endness. A node that receives an error will
receive a packet it never sent.




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

THat's something that you can't guarantee at the protocol level, but
have to do it operationally. And, operationally, s* happens.



> 
> I think now it is up to 6man WG and chairs how they choose to continue
> this dialogue. 

6man already have this dicussion, and I don't see any new elements being
added to it, to be honest.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492