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

Curtis Villamizar <curtis@ipv6.occnc.com> Wed, 15 January 2014 01:13 UTC

Return-Path: <curtis@ipv6.occnc.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A4B1AE119; Tue, 14 Jan 2014 17:13:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level:
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdF59sbrdKAy; Tue, 14 Jan 2014 17:13:55 -0800 (PST)
Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id C1A6C1ADFD1; Tue, 14 Jan 2014 17:13:54 -0800 (PST)
Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0F1DXSN005803; Tue, 14 Jan 2014 20:13:42 -0500 (EST) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201401150113.s0F1DXSN005803@maildrop2.v6ds.occnc.com>
To: Wesley Eddy <wes@mti-systems.com>
From: Curtis Villamizar <curtis@ipv6.occnc.com>
In-reply-to: Your message of "Tue, 14 Jan 2014 11:22:02 -0500." <52D5642A.7090103@mti-systems.com>
Date: Tue, 14 Jan 2014 20:13:33 -0500
Cc: Scott Brim <scott.brim@gmail.com>, "Eggert, Lars" <lars@netapp.com>, IETF discussion list <ietf@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: curtis@ipv6.occnc.com
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 01:13:56 -0000

In message <52D5642A.7090103@mti-systems.com>
Wesley Eddy writes:
 
> On 1/14/2014 11:06 AM, Eggert, Lars wrote:
> > Hi,
> > 
> > On 2014-1-14, at 16:39, Scott Brim <scott.brim@gmail.com> wrote:
> >> Lars, I know we're repeating arguments from the last decade. The
> >> choice is between (1) specifying congestion control around the
> >> substrate UDP that can be turned off if it causes problems, or (2)
> >> specifying nothing at this time and adding it later if operators want
> >> it.
> >>
> >> I guess if this can be written as a SHOULD, up to the implementor's
> >> discretion, then okay.
> > 
> > I don't think we can leave this up to implementors discretion. We've had IETF consensus that Internet communication requires congestion control at least since RFC2914. A circuit breaker mechanisms seems straightforward to implement.
> > 
> > As is, I object to this document going forward. The minor benefits of getting some better load balancing for MPLS are far outweighed by the risks.
> > 
> > (I'm also going to shut up now, and let others speak. I think I've said my bit.)
> > 
>  
>  
> I'm in basic agreement.
>  
> Assuming we might all agree that there are conceivable scenarios where
> a circuit breaker mechanism would be useful, is the real issue that
> we don't all agree that it could be implemented in a way that's not
> burdensome and doesn't degrade performance unnecessarily?
>  
> Or is there still fundamental disagreement about whether the scenarios
> where the circuit breaker is useful are even valid?


A circuit breaker (drop all traffic on sign of congestion) at the MPLS
over UDP level would be the worst thing you could specify and IMO it
would guarentee zero implementations.

A circuit breaker might be appropriate for TDM over PW but nothing
else.  This makes sense because TDM cannot change its bandwidth so the
only choice is to shut it off.  TDM over PW is an application that can
run over MPLS (or GRE or L2TP).  The best place to put that circuit
breaker (if anywhere at all) is in TDM over PW.

Curtis