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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Greg Daley writes:
 
> Hi Joel, 
>  
> > -----Original Message-----
> > From: ietf [mailto:[e-mail]] On Behalf Of Joel M. Halpern
> > Sent: Friday, 24 January 2014 1:32 PM
> > To: Joe Touch; Edward Crabbe
> > Cc: [e-mail]; 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
> [e-mail]


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