Re: IPv6 header insertion in a controlled domain

[[e-mail]]

Fernando,

Please stop hijacking every thread for your own purposes.

Ole

> On 8 Dec 2019, at 11:02, Fernando Gont <[e-mail]> wrote:
> 
> On 8/12/19 06:24, [e-mail] wrote:
>> Mark,
>> 
>> [...]
>> [renamed thread]
>> 
>>> Take an example of 3 routers A, B and C that is under the same control.
>>> Traffic travels from left to right.
>>> 
>>> A -- B -- C
>>> 
>>> A has a tunnel to C using ULA source and destination.
>>> A packet ingresses on A, is encapsulated and forwarded towards C.
>>> A has for reasons unknown to us outsourced a function to B. Where B insert an extension header in the packet originated by A.
>>> C is also in on the game, being a tunnel end-point, removing the encapsulating header and extension header.
>>> 
>>> If you can leave the nuances of SR and the whatever they propose on the shelf for a minute.
>>> 
>>> Do you agree in principle that this approach of "header insertion in a controlled domain" can be made to work,
>>> and should be indiscernible from A inserting the extension header itself?
>> 
>> Yes, there are obviously many ways of skinning this cat.
>> In this thread I don't want to try solve whatever problem the EH insertion camp wants solved. I don't think I understand it well enough.
> 
> That's a good thing. If you don't understand the problems that folks
> argue in order to do EH insertion solved, that's an indication that we
> should stay safe, and stick to consensus.
> 
> In fact, I'd believe that it's quite interesting that we're even
> bothering to talk about EH insertion when the folks proposing it didn't
> even bother to do a proper analysis, and argue why they need it, and why
> the problem can't be solved in any other way.
> 
> 
> Datapoint: As a measure of process fairness: when we were doing RFC7217,
> we were kind of required to do RFC7721 in order to eventually do
> RFC8064. (and we were talking about a host-local policy thing).
> 
> So it is quite nice to see that now you are open to screw up the
> architecture just because a big vendors wants it, with the only
> rationale for doing it, "the operator community want it".
> 
> Thanks,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492