Re: SRH insertion vs SRH insertion + encapsulation

[Fernando Gont <[e-mail]>]

On 7/9/19 15:34, Robert Raszuk wrote:
> Hi Fernando,
> 
>     If you originate a packet, you can include you EHs (within the
>     constraints of RFC8200) because it is a *new* packet. 
> 
> 
> Ok glad we got that far :) 

I hope that there's no fancy interpretation behind.




> And honestly I would recommend NP document authors to clearly separate
> those two indeed. 
> 
>> That's not called "insertion"  
> 
> If it would be up to me where the NP document calls for EH insertion
> keep "insertion" where the document describes insertion + encap just
> rename it to imposition+encapsulation. 

It's just encapsulation.




> Just to avoid confusion ... 
> 
>     > 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?
> 
> Deployment experience is never part of standards track document. And it
> should never be. 

You miss the point. I look at the document that proposes EH insertion,
and there's no rationale there. And you point me at a different document.

The document that proposes EH insertion has to have minimal analysis
such as: why don't we use encap/decap, etc. If the document that
proposes insertion doesn't have that sort of rationale, I0m not sure why
we should even look at it.


Since you noted: Deployment experience can be part of the document. You
can even add a section noting that it should be removed by the RFC editor.


That said, the fact that somebody implemented something, and that
somebody deployed it is not a motivation for the IETF to work on that
idea, and standardize it.





>     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.
> 
> And why they deployed it. 

That's completely irrelevant.




>     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?
> 
> 
> Ok I admit I am new to 6man ... but not new to IETF. Say in IDR or other
> WGs you can not progress any document till you demonstrate interoperable
> implementations. That is why there is early code point allocation too. 

You are mixing to different things, and also your statement seems to be
incorrect.

Firstly, implementations and deployment experience are do not replace an
appripriate rationale and analysys for updating a standard. Normally,
one would expect that a spec elaborates why the update is needed ("we
want to do EH insertion... hence this document" is not a rationale), and
, in the presense of an obvious choice (such as encap/decap), why that
option is not acceptable to solve your problem.

draft-voyer-6man-extension-header-insertion completely lacks such rationale.


OTOH, as noted in Section 4.1.1. demonstration of interoperable
implementations is not a requirement for draft standard.




> If in 6man things work differently - if you have to prove on draft and
> slides that your idea may work instead of showing it works then that
> seems like different IETF process I am used to. 

You have to make a strong case why you want to update the spec. "Hey, we
did this code, it works, and we now want to update the current standard
with it" *is not* an appropriate rationale.



>     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.
> 
> Sure ... you still have originator of the inserted header too. So stops
> an implementation to inform such node that what he is doing hurts here ? 

An  implementation that receives an error that appears to have been
elicited by a packet it didn't send should normally be ignored.


>     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?
> 
> Nothing. All you can do with only insertion you can do with imposition +
> encap. Just that you just waisting min extra 40 bytes each time. 

This is probable the first or second sentence that should be in
draft-voyer-6man-extension-header-insertion.

Things are normally portrayed as "Oh! If we can't have EH-inertion, we
cannot do this and that!". -- where in reality you want to do EH
insertion to save 40 bytes of an IPv6 header.



>     You are breaking IPv6 ent to endness. A node that receives an error will
>     receive a packet it never sent.
> 
> I don't think so. Remeber SR inserts bits in the packets and removes
> them before handling the packet in original form further. 
> 
> So I guess the case which you are highlighting is this: 
> 
> 1. Packet comes to a domain 
> 2. Within domain without any encap someone is doing TI-LFA with pure
> insertion 
> 3. Nodes on the bypass path encounter the issue with the packet, can not
> recognize the SRH so start sending erors to original application src
> 4. Application src can not interpret those errors and we have a mess. 
> 
> Is this your thinking ? 
> 
> If so how about we would mandate that SRH insertion is allowed only if
> within domain original packet was already encapsulated ? 

That's certainly better than inserting when the packet wasn't
encapsulated. Still, there are other issues with insertion.
If you ask me, EH insertion is not worth it.




>     > 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.
> 
> 
> s* happens all the time. But if this is mandated in the spec you have a
> stick to smash your vendor with and get another vendor if they fail to
> listen to you. 

We have been there numerous times for different protocols. Truth is, s*
happens, and packets leak.

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