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

[Alexander Vainshtein <[e-mail]>]

Lars, Scott and all,

First, a piece of history.

Congestion control considerations have been a major point of contention between the (then) leadership of the Transport Area and the PWE3 WG (that has started in the Transport Area, then migrated to Internet Area and finally arrived to the Routing Area).  A congestion control framework document is still listed as one of the goals of this WG even if the target date has passed and the draft that was supposed to deal with the subject (https://datatracker.ietf.org/doc/draft-ietf-pwe3-congestion-frmwk) has expired almost 4 years ago.

TDM PWs which, for historical reasons, have always included encapsulations over UDP/IP, have been one of the focal points of this contention with DISCUSS by one of the then Transport Area directors in the process of the IESG approval of the first of these documents. Eventually, this contention has been resolved by adding a dedicated Congestion Control section to RFC 4553. This section introduced several guards against congestion being created by excessive deployment of TDM PWs and provided specific guidelines for  implementing a congestion prevention mechanism (specific to TDM PWs). 

Going back to the draft in question...

Encapsulating  MPLS in UDP looks to me like a far-going extension of running TDM PWs over UDP/IP. The main differences, as I see them, are:

- General MPLS-in-UDP flows can be "BW-greedy" while TDM PWs are not
- Congestion detection for these flows by the encapsulation endpoints (presumably called "applications using MPLS/UDP encapsulation" in the ) is much more problematic, nor is it clear to me, how backpressure  between these endpoints can operate even if congestion were detected

The text I have found in the Congestion Considerations section of the draft recognizes potential for congestion created by MPLS/UDP flows, and even calls for a mandatory additional congestion control mechanism. However, I could not find any guidelines (or even hints) that would help an implementer to create such a mechanism.  So I'd say that with regard to congestion control this draft does not meet the standard that has been expected (years ago from now) from the TDM PW drafts. 

My 2c,
       Sasha 
Email: [e-mail]
Mobile: [phone]

> -----Original Message-----
> From: mpls [mailto:[e-mail]] On Behalf Of Eggert, Lars
> Sent: Saturday, January 11, 2014 8:23 AM
> To: Scott Brim
> Cc: [e-mail]; IETF
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating
> MPLS in UDP) to Proposed Standard
> 
> Hi,
> 
> On 2014-1-10, at 22:32, Scott Brim <[e-mail]> wrote:
> > OK good point - so we invoke the end-to-end argument on MPLS's behalf.
> 
> look at it the other way. From the viewpoint of the rest of the net, you are an
> application using UDP. Such applications need to follow a set of principles we
> have IETF consensus on (RFC5405).
> 
> By encapsulating MPLS in UDP, you are changing the game. That traffic can
> now appear on any Internet path, and not just inside provisioned networks.
> Because of that, you need a mechanism to detect if you are causing
> congestion, and a mechanism to react to it.
> 
> And it *is* a requirement on the encapsulator, because from the perspective
> of the rest of the net, that is the application that generates the UDP traffic.
> 
> Lars