In message
<72381AF1F18BAE4F890A0813768D992817FD35E1(_at_)sdcexchms(_dot_)au(_dot_)logicalis(_dot_)com>
Greg Daley writes:
Hi Joel,
-----Original Message-----
From: ietf [mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Joel M.
Halpern
Sent: Friday, 24 January 2014 1:32 PM
To: Joe Touch; Edward Crabbe
Cc: mpls(_at_)ietf(_dot_)org; Noel Chiappa; IETF discussion list
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
(Encapsulating
MPLS in UDP) to Proposed Standard
Joe, while your argument is internally consistent, it is not consistent with
history. We have not demanded that tunnel entries behave fully like source
hosts for any of the other myriad kinds of tunnels we have done over the
years.
Actually, many of the tunnel protocols on the standards track have
been either for upper-layer IP or Transport protocols or require
congestion mitigation:
RFC 4448 for EoMPLS, and 5994 for Ethernet pseudowires over MPLS
each ask that tunnelled protocols support congestion mechanisms,
RFC5085 and 5586: VCCV and BFD with VCCV define congestion
considerations for pseudowire tunnels. RFC 4719 updated by RFC
5641: Ethernet pseudowires over L2TP (a UDP encapsulated protocol)
permit packet loss indications to take down the active circuit.
RFC 4454: ATM over L2TPv3 indicates that inelastic flows are
stopped when congestion occurs.
They (ATM over L2TPv3 and Ethernet PW over L2TPv3) also require usage
over a traffic engineered network.
RFC 4817 MPLS over L2TPv3 requires non-IP upper layer protocols not to
exceed the offered load of a typical TCP application on the same path.
For those protocols which have IP, UDP, TCP, SCCP or DCCP this is just
passing the buck to the upper layer protocol (which is OK, so long as
the application protocol in UDP has congestion measures). For
environments where this cannot be relied upon, additional protocol
specification and applicability statements have previously been
applied.
If we take your logic as stated, then the usage of IPSec over UDP would be
required to apply congestion control unless it knew that all the
content traffic was TCP. Is that really your intent?
Actually, one of the compelling use cases for running MPLS over UDP
(or L2TPv3) would be to encapsulate the traffic in ESP in order to
combat passive snooping.
For ESP I believe the implicit assumption (via the Traffic Selectors
in IKE) was that the upper layer protocol is IP or in transport mode
another protocol such as TCP, UDP etc.
Sincerely,
Greg Daley
gdaley(_at_)au(_dot_)logicalis(_dot_)com
Reality check time.
To get the PW over MPLS drafts past the TSV AD there is a SHOULD
regarding congestion control.
AFAIK: No service providers ask for it. No one implements it. If
they did implement it no one would deploy it.
PW over MPLS is generally carrying relatively low volumes of high
priority traffic. The TC bits (MPLS flavor of Diffserv DSCP) are used
to enforce the higher priority. If congestion occurs other traffic on
that infrastructure (typically plain old Internet) sees loss. That is
intended. This is the reality of how PW over MPLS is deployed.
Anyone who knows of implementation or deployment of congestion control
for PW over MPLS can correct me.
I don't know about the "over GRE" or "over L2TP" tunneling.
Curtis