Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document?

Rob Shakir <rjs@rob.sh> Wed, 16 November 2011 18:20 UTC

Return-Path: <rjs@rob.sh>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C21721F94D1 for <idr@ietfa.amsl.com>; Wed, 16 Nov 2011 10:20:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level:
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKgSttwFKLAl for <idr@ietfa.amsl.com>; Wed, 16 Nov 2011 10:20:35 -0800 (PST)
Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 939EF21F94B5 for <idr@ietf.org>; Wed, 16 Nov 2011 10:20:35 -0800 (PST)
Received: from [93.97.180.64] (helo=latte.config) by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from <rjs@rob.sh>) id 1RQk4A-0004he-QX; Wed, 16 Nov 2011 18:18:34 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Rob Shakir <rjs@rob.sh>
In-Reply-To: <CAMXVrt55AJ2b80_kTBQUJ1ZCo6ewm_NMfmhwUxH48kktLTTi6w@mail.gmail.com>
Date: Wed, 16 Nov 2011 18:20:30 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <B383DA80-7CF1-453A-AEDA-8D3F33A40E5B@rob.sh>
References: <B04EDD60-8998-4085-97CC-885A65AA47BA@juniper.net> <CAMXVrt55AJ2b80_kTBQUJ1ZCo6ewm_NMfmhwUxH48kktLTTi6w@mail.gmail.com>
To: Pedro Marques <pedro.r.marques@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: "idr@ietf.org List" <idr@ietf.org>
Subject: Re: [Idr] Adoption of draft-l3vpn-legacy-rtc-00 as IDR WG document?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2011 18:20:36 -0000

On 16 Nov 2011, at 17:19, Pedro Marques wrote:

> -1
> 
> I believe that the "legacy" is now the fact that rt-constraint is
> supported by the most common implementations.
> 
> The proposed procedures for legacy PEs have a level of complexity that
> seems significantly higher than qualifying a new software release.

While this if of course a valid argument, I believe that there are some operational constraints that make this untrue. 

In an ideal world, all deployed PEs would be running current hardware, and with software trains under active development. Unfortunately, this is not always the case - and hence the requirement is more than a software qualification to support RTC. The options here are migration to new hardware platforms, which comes with significant operational costs, or put up with some operational complexity to better utilise existing assets whilst allowing network growth elsewhere, and delay expenditure. 

I realise that such non-technical requirements may fall outside of the consideration of IETF working groups - but I feel strongly that there is some trade-off to be made that sacrifices some absolute correctness to provide technologies that allow operators to meet their network's commercial requirements. 

We should (of course) consider the extent to which such compromises compromise network robustness - but I can't say that I agree that this draft upsets the complexity/benefit balance. I would be interested to hear if you do.

Kind regards,
r.