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

<stephane.litkowski@orange.com> Wed, 24 June 2015 09:41 UTC

Return-Path: <stephane.litkowski@orange.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 B96E31B32CA; Wed, 24 Jun 2015 02:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 G68sNdS4a74e; Wed, 24 Jun 2015 02:41:43 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928F01B32CE; Wed, 24 Jun 2015 02:41:42 -0700 (PDT)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 19B6737472C; Wed, 24 Jun 2015 11:41:41 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id E8C6638404A; Wed, 24 Jun 2015 11:41:40 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0235.001; Wed, 24 Jun 2015 11:41:40 +0200
From: <stephane.litkowski@orange.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, "Alia Atlas (akatlas@gmail.com)" <akatlas@gmail.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: AQHQrPmWzLjTqK7rnkOxz3uuHivU2Z26JgmAgAAGLgCAASp9AA==
Date: Wed, 24 Jun 2015 09:41:39 +0000
Message-ID: <21634_1435138901_558A7B54_21634_3497_16_9E32478DFA9976438E7A22F69B08FF921667862D@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <20150622144146.17459.58140.idtracker@ietfa.amsl.com> <18969_1435051333_55892544_18969_971_1_9E32478DFA9976438E7A22F69B08FF9216677F92@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <D1AED6D1.B96B9%aretana@cisco.com>
In-Reply-To: <D1AED6D1.B96B9%aretana@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.24.74215
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/eD9ZZVoxUPXd9fHhnFMSm5995ys>
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: Wed, 24 Jun 2015 09:41:45 -0000

Hi Alvaro, Alia

> From Alvaro Retana> (aretana)
> Sent: Tuesday, June 23, 2015 3:44 PM
> To: LITKOWSKI Stephane SCE/IBNF
> Cc: draft-ietf-rtgwg-lfa-manageability@tools.ietf.org; Brian Haberman; 
> iesg@ietf.org; rtgwg@ietf.org
> Subject: Re: Alvaro Retana's No Objection on draft-ietf-rtgwg-lfa-
> manageability-09: (with COMMENT)
> 
> 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.

CURRENT text is:
   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].
 
My understanding is that you are calling for removing the pointer to the solution (and do the same thing for the node color section) or pushing for solutions.

CANDIDATE1: we can limit the text to :
"Link color information SHOULD be signaled in the IGP.  " and do the same thing for the node color.


We would be ok for this, but, this seems like a different direction compared to a previous comment from Alia who had previously proposed to _add_ reference to solution drafts, including  ospf-prefix-link-attr:
> From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alia Atlas
> Sent: Friday, June 12, 2015 4:23 PM
> To: LITKOWSKI Stephane SCE/IBNF
> Cc: draft-ietf-rtgwg-lfa-manageability@tools.ietf.org; rtgwg@ietf.org
> Subject: Re: AD Review of draft-ietf-rtgwg-lfa-manageability
[...]
> 4) In Sec 6.2.7, you might be interested in the link/node-attribute drafts that are being finished.
> [SLI] Could you give me the pointers of drafts you are thinking about ?
>You have the ISIS one for node admin tags.  I was also thinking of 
>draft-ietf-ospf-node-admin-tag-02  and 
>draft-ietf-ospf-prefix-link-attr-06.  For ISIS, it looks like the similar draft  only provides for prefix attributes and not link ones.

Since you deferred to Alia, and "would rather keep the original text", our current understanding is to keep CURRENT text which has been revised as per Alia's comment.
Alia, Alvaro, please advise/propose text if this you prefer something different.


Best regards,


-----Original Message-----
From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] 
Sent: Tuesday, June 23, 2015 15:44
To: LITKOWSKI Stephane SCE/IBNF
Cc: rtgwg@ietf.org; draft-ietf-rtgwg-lfa-manageability@tools.ietf.org; iesg@ietf.org; Brian Haberman
Subject: Re: Alvaro Retana's No Objection on draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)

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.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.