Re: WGLC for draft-rtgwg-mrt-frr-architecture

"Alvaro Retana (aretana)" <aretana@cisco.com> Wed, 09 December 2015 16:52 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B081ACE01 for <rtgwg@ietfa.amsl.com>; Wed, 9 Dec 2015 08:52:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 itYBmstdq8z8 for <rtgwg@ietfa.amsl.com>; Wed, 9 Dec 2015 08:52:39 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47E81ACDFE for <rtgwg@ietf.org>; Wed, 9 Dec 2015 08:52:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11676; q=dns/txt; s=iport; t=1449679958; x=1450889558; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eELPITiH2lDvZuuahRECTLs4DluKc8Pbg62GlejUo/k=; b=YNwl0Tfn+CzWIKKJprGUh7wZmrUBJXBkeGX76juk3tj+n0h7BYO48IEG TrM9+0oti5BYeD9J9yzCb5PT/QgB/6Gd1OF1XAhWZwjjSA3/jZI0CCWFJ AcxxF0AbfHscqoCf2dmW+lA81mczL0xVfPigZUdvMmV8GwkPBJlUwF8mG 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ArBQABXGhW/5RdJa1egm5Mf0IGuyuCGQENgWKGDwKBJzgUAQEBAQEBAYEKhDUBAQQMbRACAQgSLQcyFAMOAgQBDQUbiBTABwEBAQEBAQEBAQEBAQEBAQEBAQEBARiGVQGEfIQ0hQwFjWaFFoNtAY1CgVuXNoNyAR8BAUKCER2BVnKEL0OBBwEBAQ
X-IronPort-AV: E=Sophos;i="5.20,404,1444694400"; d="scan'208,217";a="215023012"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Dec 2015 16:52:14 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id tB9GqEXj025973 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Dec 2015 16:52:14 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 9 Dec 2015 10:52:13 -0600
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Wed, 9 Dec 2015 10:52:13 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com>
Subject: Re: WGLC for draft-rtgwg-mrt-frr-architecture
Thread-Topic: WGLC for draft-rtgwg-mrt-frr-architecture
Thread-Index: AQHRLff/OG2l5ZYqq0Km/2NhVgzqi569VdYAgAGG8oCAAAEXgIAABO+AgAIXR9CAACSycIAB2eeA
Date: Wed, 09 Dec 2015 16:52:13 +0000
Message-ID: <D28DC142.EE998%aretana@cisco.com>
References: <56608847.9040505@gmail.com> <327562D94EA7BF428CD805F338C31EF06C08630C@nkgeml512-mbx.china.huawei.com> <5665685D.2020507@gmail.com> <56656947.1070307@gmail.com> <56656D6B.6010600@gmail.com> <327562D94EA7BF428CD805F338C31EF06C0865EE@nkgeml512-mbx.china.huawei.com> <21567_1449586197_5666EE15_21567_14680_1_53C29892C857584299CBF5D05346208A0F6F7476@OPEXCLILM21.corporate.adroot.infra.ftgroup>
In-Reply-To: <21567_1449586197_5666EE15_21567_14680_1_53C29892C857584299CBF5D05346208A0F6F7476@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.5]
Content-Type: multipart/alternative; boundary="_000_D28DC142EE998aretanaciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/yL6BtHSqH2Xpl1E1EbHALUCfjr0>
Cc: "draft-ietf-rtgwg-mrt-frr-architecture@tools.ietf.org" <draft-ietf-rtgwg-mrt-frr-architecture@tools.ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>, Mike Shand <mike@mshand.org.uk>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Dec 2015 16:52:44 -0000

On 12/8/15, 9:49 AM, "bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>" <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> wrote:

[Speaking as an individual.]

[This is a little bit off the topic of draft-rtgwg-mrt-frr-architecture.  But worth discussing.]

As a general comment, we indeed have multiple FRR solutions ( e.g. TI-LFA, RLFA, RLFA node protection, TI-FRR, MRT, TI-LFA, RSVP-TE 1 hop link protection, end to end RSVP-TE FRR (multiple flavors and new additional extensions discussed in MPLS WG), some mid point to some other mid points RSVP-TE...) plus discussed in multiple WG (RTGWG and MPLS, a priori TI-LFA would be discussed in RTGWG rather than SPRING (although TI-FRR could possibly also be discussed in RTGWG rather than MPLS))
So there may be a question whether the IETF:
a) is fine with documenting multiple/many, independent solutions,
b) is fine with many solutions but want to evaluate them to see which one is the best fit depending on the deployment case
c) whether we need to choose N solutions based on technical merits

Even if we reduce the scope of the question from the IETF to the Routing Area or even a specific WG, the answer is probably going to be in line with your thoughts:

 Personally, I don't really have a strong preference, but they seem ranked from faster/easier to longer/harder. So far I assumed that "a" had been chosen. May be "b" would make sense, assuming I'm not the one doing the job ;-) . I'm afraid "c" would burn many times, for limited benefits. (I can already foresee some lengthy discussions just to pick the "right" value for N, before even starting the technical evaluation)

I agree.  "c" opens a can of worms that no one wants.

My personal opinion is that there's nothing wrong with "a" [*].

While you didn't explicitly say so, "b" could be interpreted as related to the Status (Standard, Experimental, Informational) of the work.  It may be interesting to evaluate which solution is the best fit [**], but then again, I don't see anything wrong with "a".  Even if a document is published as a Proposed Standard, it should never make it to an Internet Standard is people don't use it.

Having said that, I also think that (given that there's nothing wrong with "a"), a WG may decide on a specific Status based on the fit of the technology to the deployment case(s), the existence (or not) of other solutions, etc.    Just a personal opinion..

Alvaro.

[*] Unless a WG is explicitly chartered to provide a single solution, of course.
[**] That is probably another can of worms. :-(