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: Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com
Mobile: 054-9266302
-----Original Message-----
From: mpls [mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of Eggert, Lars
Sent: Saturday, January 11, 2014 8:23 AM
To: Scott Brim
Cc: mpls(_at_)ietf(_dot_)org; 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 <scott(_dot_)brim(_at_)gmail(_dot_)com>
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