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