Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

["Joel M. Halpern" <[e-mail]>]

On the one hand, as is attributed to Milo Medin, with sufficient thrust 
pigs will fly.  So I can not assert that something can not be made to work.

But I have not seen any clear demonstrationthat header insertion in a 
controlled domain is actually safe.   Even if you upgrade all the hosts 
and routers in the domain (a quite significant and difficult to achieve 
hurdle) many of the problems with header insertion by nodes other than 
the origin still apply.  For example, even if the origin "knows" what 
may happen, that does not mean it can properly attribute or respond to 
errors it receives caused by modifications it did not make to the packet.

But the important question is why is it even desirable.  No, 8200 is not 
a religious text.  But it is the product of our standards effort.  We 
reached an agreement that this was not a good idea.  As such, it seems 
to me it requires clear and explicit need before we agree to change the 
rules, even in "controlled domain".  We do not have an IETF agreement 
that "controlled domains" get an arbitrary pass.  We sometimes relax 
some requirements when a need can be shown.   That has not been shown here.

Yours,
Joel

On 12/7/2019 5:30 AM, [e-mail] wrote:
> Joel,
> 
>> The TI-LFA task can clearly be done with encapsulation.  That the proponents do not desire to do so is clear and understood.  Not desiring to do so is not a reason to violate a Full Standard RFC.
>>
>> That is why I asked what the purpose was for header insertion.  And citing the TI-LFA draft does not answer the quesiton.
> 
> The point I tried to make was that propopents of EH insertiona had a slightly more nuanced motivation for doing what they are doing,
> than what Fernando portray in this paragraph:
> 
>>> 3) Besides the technical arguments against EH insertion (which have been
>>> codified in draft-smith-6man-in-flight-eh-insertion-harmful, I have
>>> asked *lots* of times what's the technical motivation for doing EH
>>> insertion. It boils down to "to save 40 bytes", which doesn't seem to me
>>> as a compelling argument to violate the spec -- even less in a design
>>> that employs 128-bit waypoints and is claimed to be operated in a
>>> limited domain.
> 
> I see it necessary to speak up when I see participants consistently arguing against strawman.
> And call upon higher deities (RFC8200).
> 
> Strawman #1:
> The proponents of EH insertion proposes to do insertion/deletion directly on user (Internet) traffic.
> 
> => There may be a suspicion that this is what they want, but it is not what they have written down, nor claim.
> 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?
> 
> Ole
> 
> 
>