Re: Alvaro Retana's No Objection on draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)

"Alvaro Retana (aretana)" <aretana@cisco.com> Tue, 23 June 2015 13:44 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 B26DA1B2C21; Tue, 23 Jun 2015 06:44:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 8q6Tc4SKjXxY; Tue, 23 Jun 2015 06:44:23 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172141B2C20; Tue, 23 Jun 2015 06:44:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2192; q=dns/txt; s=iport; t=1435067063; x=1436276663; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VjOyFiMOu2AQB5PpiKHDLPyzpPMPfFL3f6kxJh0M5nI=; b=bMu6b2FVmYDMM3fd43xXVfNQQYmDZ4escXcSJNlZnWWpgpMP4kG6Ij86 yQm9Jla7Sxd2VaJbAo1m2psSnAHq6SiHdUWUkBWOOTt2LlNUmm+xbDOyt 54n76RgGtS89t32ej54G4fAbw2+5yDoUKuotWkKyRXeDMGbV0GhJ8EBQq k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AxBQC4YYlV/5pdJa1bgxCBMwa5NIwSAoFKOxEBAQEBAQEBgQqEIwEBBHkQAgEIRjIlAgQOBRuIFMw8AQEBAQEBAQEBAQEBAQEBAQEBGotKgU+CX1gHhCsBBIxGhF6CWwGHLoQigTqEEJJrJmOBKRwVgT1vgQRCgQIBAQE
X-IronPort-AV: E=Sophos;i="5.13,665,1427760000"; d="scan'208";a="5847904"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 23 Jun 2015 13:44:22 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t5NDiMJn008770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Jun 2015 13:44:22 GMT
Received: from xmb-aln-x15.cisco.com ([169.254.9.106]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Tue, 23 Jun 2015 08:44:22 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>
Subject: Re: Alvaro Retana's No Objection on draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)
Thread-Topic: Alvaro Retana's No Objection on draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)
Thread-Index: AQHQrPmUYR1MUFPl8EGUi6oA7PA/5526JgmAgAAGLgA=
Date: Tue, 23 Jun 2015 13:44:21 +0000
Message-ID: <D1AED6D1.B96B9%aretana@cisco.com>
References: <20150622144146.17459.58140.idtracker@ietfa.amsl.com> <18969_1435051333_55892544_18969_971_1_9E32478DFA9976438E7A22F69B08FF9216677F92@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <18969_1435051333_55892544_18969_971_1_9E32478DFA9976438E7A22F69B08FF9216677F92@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.117.15.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <1D10EED4BDFC1344B9847DFA58701CB0@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/eVqocSvoKUCB04CXWWANByzdS_s>
Cc: "draft-ietf-rtgwg-lfa-manageability@tools.ietf.org" <draft-ietf-rtgwg-lfa-manageability@tools.ietf.org>, Brian Haberman <brian@innovationslab.net>, "iesg@ietf.org" <iesg@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
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: Tue, 23 Jun 2015 13:44:30 -0000

On 6/23/15, 5:22 AM, "stephane.litkowski@orange.com"
<stephane.litkowski@orange.com> wrote:

Stephane:

I¹m looping everyone else back in..I know Brian had the same comment.

>For the point #3, we had a comment from Alia on the list saying that we
>needed to point to some existing solutions.
>
>We propose to change the text as follows :
>BEFORE :
>Link color information SHOULD be signalled in the IGP.  How
>   signalling is done is out of scope of the document but it may be
>   useful to reuse existing admin-groups from traffic-engineering
>   extensions or link attributes extensions like in
>   [I-D.ietf-ospf-prefix-link-attr].
>NEW TEXT :
> Link color information SHOULD be signalled in the IGP in order to limit
>configuration effort.  e.g.
>   [I-D.ietf-ospf-prefix-link-attr], [RFC5305], [RFC3630] ...
>
>Does it work ?

Honestly, both options point at the same thing: the suggestion (at least)
of a solution.  I am completely in favor of reusing
technology/ideas/drafts if they will help solve the problem.  My point is
that this document is not specifying solutions, just requirements..if that
is true, then don¹t point at the solutions.  OTOH, if this document is to
specify solutions, then lets do that.

Having said all that, I can defer to Alia.  However, please at least make
it clear that the solutions you are pointing to are just that (pointers).
In the text above I would rather keep the original text that clearly
states that solutions are out of scope.  The text in 6.2.4.4 doesn¹t
explicitly say that the solutions are not in scope.

Thanks!

Alvaro.



>3. In Section 6.2.4.2 the document talks about signaling color
>information, it includes a set of requirements..and it reads ³How
>signaling is done is out of scope of the document², but then you go on
>and point to a specific solution.  Even if there might be a high
>certainty that the solution you point at is moving on in the process, is
>good, should be used, etc..  I think this document would be better served
>by just defining the requirements (specially if you¹re pointing at the
>solution as out of scope).   You do the same in 6.2.4.4.