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

"Alvaro Retana (aretana)" <> Tue, 23 June 2015 13:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B26DA1B2C21; Tue, 23 Jun 2015 06:44:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8q6Tc4SKjXxY; Tue, 23 Jun 2015 06:44:23 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 172141B2C20; Tue, 23 Jun 2015 06:44:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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-AV: E=Sophos;i="5.13,665,1427760000"; d="scan'208";a="5847904"
Received: from ([]) by with ESMTP; 23 Jun 2015 13:44:22 +0000
Received: from ( []) by (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 ([]) by ([]) with mapi id 14.03.0195.001; Tue, 23 Jun 2015 08:44:22 -0500
From: "Alvaro Retana (aretana)" <>
To: "" <>
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: <>
References: <> <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-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, Brian Haberman <>, "" <>, "" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Jun 2015 13:44:30 -0000

On 6/23/15, 5:22 AM, ""
<> wrote:


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 :
>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].
> 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 doesn¹t
explicitly say that the solutions are not in scope.



>3. In Section 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