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

Robert Raszuk <robert@raszuk.net> Wed, 16 November 2011 23:01 UTC

Return-Path: <robert@raszuk.net>
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 6A6DD11E8083 for <idr@ietfa.amsl.com>; Wed, 16 Nov 2011 15:01:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.967
X-Spam-Level:
X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.632, 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 4+Ib-O-gbwuX for <idr@ietfa.amsl.com>; Wed, 16 Nov 2011 15:01:30 -0800 (PST)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id A6A1E11E807F for <idr@ietf.org>; Wed, 16 Nov 2011 15:01:30 -0800 (PST)
Received: (qmail 15456 invoked by uid 399); 16 Nov 2011 23:01:29 -0000
Received: from unknown (HELO ?10.0.1.3?) (130.129.67.115) by mail1310.opentransfer.com with ESMTP; 16 Nov 2011 23:01:29 -0000
X-Originating-IP: 130.129.67.115
Message-ID: <4EC440CA.9070904@raszuk.net>
Date: Thu, 17 Nov 2011 00:01:30 +0100
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Rob Shakir <rjs@rob.sh>
References: <B04EDD60-8998-4085-97CC-885A65AA47BA@juniper.net> <CAMXVrt55AJ2b80_kTBQUJ1ZCo6ewm_NMfmhwUxH48kktLTTi6w@mail.gmail.com> <B383DA80-7CF1-453A-AEDA-8D3F33A40E5B@rob.sh>
In-Reply-To: <B383DA80-7CF1-453A-AEDA-8D3F33A40E5B@rob.sh>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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
Reply-To: robert@raszuk.net
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 23:01:31 -0000

Hi Rob,

While I may even agree with your points reg considerations for a 
software upgrade on the PEs - which in many cases may just not be 
available due to given's vendor software release strategy - I do not 
agree that this is so hard to enhance your provisioning system to update 
the rr-group command on the RR when you are adding/deleting/modifying a 
RT on the PE given RR is serving.

And if you do that there is no need for inbound signalling like proposed 
in this draft.

Rgs,
R.


> 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.
>
>
> _______________________________________________ Idr mailing list
> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
>
>