Re: SRH insertion vs SRH insertion + encapsulation

[Robert Raszuk <[e-mail]>]

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

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.

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.

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.


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

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.

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 ?


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

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 ?



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


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

I am sure it did ... I will try to search for it as clearly I must have
missed it fully or partially.

Thx a lot,
R.