Re: [re-ECN] Conex charter - now in External Review

Stewart Bryant <stbryant@cisco.com> Thu, 29 April 2010 08:17 UTC

Return-Path: <stbryant@cisco.com>
X-Original-To: re-ecn@core3.amsl.com
Delivered-To: re-ecn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD0BF3A63C9 for <re-ecn@core3.amsl.com>; Thu, 29 Apr 2010 01:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.434
X-Spam-Level:
X-Spam-Status: No, score=-10.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLUXgwCbZWZe for <re-ecn@core3.amsl.com>; Thu, 29 Apr 2010 01:17:42 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 062953A6AB6 for <re-ecn@ietf.org>; Thu, 29 Apr 2010 01:17:35 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAHfQ2EtAZnwM/2dsb2JhbACdC3GiZIFhCwGYJ4UQBA
X-IronPort-AV: E=Sophos;i="4.52,294,1270425600"; d="scan'208";a="106214261"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Apr 2010 08:17:22 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3T8HLeH006970; Thu, 29 Apr 2010 08:17:21 GMT
Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o3T8HI626591; Thu, 29 Apr 2010 09:17:19 +0100 (BST)
Message-ID: <4BD9408E.7090201@cisco.com>
Date: Thu, 29 Apr 2010 09:17:18 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: John Leslie <john@jlc.net>
References: <4BD6F2DD.3040202@cisco.com> <20100427151601.GF16203@verdi> <EE00404438E9444D90AEA84210DC406793D9DB@pacdcexcmb05.cable.comcast.com> <A8B8C5AF-37C2-4DD6-BDDB-760FC616BE8F@g11.org.uk> <EE00404438E9444D90AEA84210DC406793DC75@pacdcexcmb05.cable.comcast.com> <20100428152122.GB14169@verdi>
In-Reply-To: <20100428152122.GB14169@verdi>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>, re-ecn@ietf.org
Subject: Re: [re-ECN] Conex charter - now in External Review
X-BeenThere: re-ecn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: re-inserted explicit congestion notification <re-ecn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/re-ecn>
List-Post: <mailto:re-ecn@ietf.org>
List-Help: <mailto:re-ecn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Apr 2010 08:17:42 -0000

>     (I also note that Stewart asked about MPLS forwarding: that's a
> quite separate question which may deserve more of an answer than
> I have already given...)
Let me explain why I keep asking about MPLS.

The stated purpose of CONEX is to provide visibility of congestion state 
within the network.

A very large fraction of provider networks use MPLS as their primary 
forwarding mechanism.

In those networks there will only be visibility of the congestion state 
at the network ingress and egress unless an MPLS solution is designed.

If the intent is to design a mechanism that works under the assumption 
that congestion state will normally only be visible at network 
boundaries, then that should be in the charter. If the intent is not to 
make that assumtion, then we should have a very high degree of 
confidence that we can find a viable MPLS solution.

Bob's answer to MPLS in Anaheim was to take it out of scope, but that 
does not address  the central of whether the technology is viable for 
deployment without MPLS support.

- Stewart