Hi,
On 2014-1-17, at 18:19, Curtis Villamizar
<curtis(_at_)ipv6(_dot_)occnc(_dot_)com> wrote:
You have made your assertions about your desire to uphold the purity
of any new UDP applications and adhere to the BCP you wrote.
You appear to be very nearly alone in this argument and certainly no
one that works with MPLS is siding with you.
the reason we wrote the RFC when I was TSV AD was that we were seeing a whole
bunch of questionable uses of UDP over the eyars and we were having the same
arguments over and over. That's why we decided to write down the practices we
expect users of UDP to follow. This is yet another such questionable use.
(Also, I don't appreciate you turning this into a personal argument.)
In the end we can put anything we want in the RFC *but* IETF has never
truly had the final word on what vendors and operators do in provider
networks.
Aka the "take my toys and go home" argument. Heard it many times.
In this case, regardless of what changes are made to the draft,
implementations will offer at least the option for non-RFC behavior by
using zero checksums and not using any congestion control. And
providers will make use of it, perhaps exclusively.
And there's nothing wrong with that - the BCP even says that one SHOULD NOT use
congestion control for some deployment cases.
But for others, one SHOULD. For those, a mechanism needs to be available, i.e.,
it needs to be specified and implemented.
The document might as well reflect reality, despite reality not
conforming to your notions of architectural purity.
I'm sorry, but we have certain architectural principles in the Internet that we
have IETF consensus on. At least since RFC2914, that includes the need to have
congestion control in place.
There are always special deployment scenarios where these principles do not
apply, and we typically explain in applicability statements when out
specifications can only be safely used under certain conditions. I don't see
any such statement in draft-ietf-mpls-in-udp, which to me means it's targeted
at general Internet-wide use.
The best course of action is to put a SHOULD in regarding checksums
and put a SHOULD in regarding congestion avoidance. Even the BCP does
not go any further than to say a tunneling protocol SHOULD use
congestion control and there were reasons that the word MUST was not
acceptable in the BCP.
The SHOULD for congestion control needs to actually describe a mechanism that can be used
when needed. It can't be a blanket "you SHOULD use something but we don't tell you
what it is"-statement.
If we are still arguing over two instances of SHOULD vs MUST we have
wasted a lot of bandwidth on those two words.
It's not SHOULD vs. MUST. It's two SHOULDs, but in both cases it needs to be
specified what is to be done. In the case of checksums, that's obvious
(calculate it and check it); in the case of congestion control, some actual
mechanism needs to be described (e.g., a circuit breaker).
IMHO The only remaining question is whether the document can go forward
with the definition of congestion control for MPLS over UDP left out
of scope and for another document if a need arises.
In my opinion, it cannot.
If this is not acceptable to you (I doubt it is) please indicate what
you would like to see in the document and since this is IETF last call
where consensus matters and no one individual has veto power, we'll
have to see if there is consensus behind your proposed changes.
I would like the document to specify at the very least a circuit breaker
mechanism, that stops the tunneled traffic if severe packet loss is detected
along the path.
And this isn't about an "individual veto". This is about a document that is at
the moment in violation of IETF consensus at least as far back as RFC2914.
Lars