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

[Curtis Villamizar <[e-mail]>]

Lars,

We seem to be in an endless loop here.

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.

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.

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.

The document might as well reflect reality, despite reality not
conforming to your notions of architectural purity.

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.

If we are still arguing over two instances of SHOULD vs MUST we have
wasted a lot of bandwidth on those two words.

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.

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.

Curtis


In message <[e-mail]>
"Eggert, Lars" writes:
 
> Hi,
>  
> On 2014-1-16, at 18:06, joel jaeggli <[e-mail]> wrote:
> > These tunnels are stateless
>  
> yep. (But they don't have to be.)
>  
> >  The endpoints not the encapsulators have visibility into the
> > end-to-end loss latency properties of the path.
>  
> Yep. But when you tunnel some L2 in UDP, apps that were limited to L2 =
> domains - where not reacting to congestion may be OK - can now go over =
> the wider Internet, where this is not OK.
>  
> I'd be great if those apps would change. But in the meantime, it's the =
> duty of the encapsulator - who enables this traffic to break out of an =
> L2 domain and go over the wider net - to make sure the traffic it emits =
> conforms to our BCPs.
>  
> >  the encapsulator is an intermediate hop, similar to any other router
> > in the path.
>  
> It's not. For the rest of the network, that encapsulator is =
> indistinguishable from any other app that sends UDP traffic.
>  
> UDP is a transport-layer protocol, and we have practices how it is to be =
> used on the net. If you want to use it for encapsulation, you bind =
> yourself to these BCPs.
>  
> Look at it the other way: if transport area folks would want to send =
> MPLS packets into the network in some problematic way, I'm sure the =
> routing and ops folks would not be amused.
>  
> Lars