Re: [spring] Question about SRv6 Insert function

[Fernando Gont <[e-mail]>]

On 4/9/19 09:58, Ole Troan wrote:
> Fernando,
> 
>>>> Since there have been plenty of attempts to do EH insertion or
>>>> leave the IPv6 standard ambiguous in this respect, and the IETF has
>>>> had consensus that EH insertion is not allowed, I think it would be
>>>> bad, wastefull, tricky, and even dangerous to let a document go
>>>> through the whole publication process, and just rely on the AD to
>>>> keep the "DISCUSS" button pressed.
>>>>
>>>> Put another way: what'd be the rationale for having a draft-ietf
>>>> and have the corresponding wg ship the document with something that
>>>> clearly goes against IETF consensus, and that the relevant AD has
>>>> declared that wouldn't let pass?
>>>
>>> In short, this is not the case. I am *not* the relevant AD for the
>>> SRv6 Network Programming draft. If this document was in 6man I would
>>> have flagged it much earlier like I did for the SRH draft.
>>
>> Sorry, what I meant by "relevant AD" is: "one of the responsible ADs for
>> the spec that's being violated".
>>
>> i.e., isn't there in the IETF process -- whether formal or informal --
>> for this sort of thing to be flagged before documents get too far in the
>> publication process?  ("Hey, this document in your area is actually
>> breaking a spec of one of my wgs" sort of thing...)
> 
> I would prefer that we calmed down a bit on the protocol policing.

Sorry, but this has nothing to do with protocol policing. It has to do
with respecting the consensus this wg and the ietf as a whole had on the
topic. i.e., that EHs must not be inserted in the network.

We'd go into an interesting path to insanity if we publish specs, and
subsequently publish conflicting specs that simply ignore previous ietf
consensus.

If folks want to do EH insertion, the #1 step is to publish a document
that updates RFC8200 such that the "EHs must not be inserted..." is
replaced with something else or eliminated.



> We know that header insertion breaks unsuspecting source hosts if done by the network.
> It breaks (at least) PMTUD, ICMP errors and AH.
> 
> What we have said in the past is; explain how those issues are dealt with or do not apply to your proposal.

That's what you and others may have said or thought. But the consensus
is what's in the standard (RFC8200). And the standard says that EHs
cannot be inserted in the network. If you want to do it, the first step
is to update RFC8200.



> And some form of "doing on behalf of" is not necessarily problematic.

It is rightaway problematic specs-wise when it violates a crystal-clear
requirement in RFC8200, that we arrived to after a very heated debate,
and lots of enegery and time from all the involved people.

The fact that after all the long story behind publication of rfc8200 as
standard (and the ongoing srv6 document we're doing here, which was
adopted on the condition that it wouldn't do eh-insertion), we can live
with other wgs violating specs that we produced here with so much effort
and time, is kind of amusing.

If folks want to allow EH-insertion (i.e., formally allowing middleboxes
to fiddle with packets), RFC8200 should be updated, and the work should
be done in 6man.

I don't think it's SPRING's call how the IPv6 protocol works.



> It's the "blind" "Thou shalt not do" that I object to. As opposed to arguing on technical grounds.
> 
> Ensuring interoperability is our purpose. Not protect 8200 as if it's a religious text.

My #1 concern (not that I don't have others) is one related to fairness
of the standardization process. I don't think we should simply
rubberstamp anything a big vendor wants to sell, no matter how big the
vendor is, or how much money may be involved.

And if this working group (and the IETF as a whole) published a spec on
which there was consensus, ignoring the spec and doing whatever one
pleases is not the way to go. Firstly, make e the case for updating
RFC8200. Then come up with the proposal to fiddle with packets in the
network.

P.S.: I've never been into the camp of protecting X (whether rfc8200 or
any other document) as if it was religious text. Quite ironically, I
have experienced such religious opposition in 6man itself (for instance,
your argument of "don't fix slaac-renumbering because ipv6 has not been
designed to support flash renumbering" seems pretty much a religious
argument against work that would not result in any major modifications
to any of the protocols involved -- as opposed to EH insertion).

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