Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

[Joe Touch <[e-mail]>]

+1 on all points.

I suspect if more people in transport had the time to track this 
protracted discussion, you'd get the same from them too.

Joe

On 1/21/2014 5:22 AM, Eggert, Lars wrote:
> Hi,
>
> On 2014-1-17, at 18:19, Curtis Villamizar <[e-mail]> 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
>