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

[<[e-mail]>]

Hi Alvaro, Alia

> From Alvaro Retana> (aretana)
> Sent: Tuesday, June 23, 2015 3:44 PM
> To: LITKOWSKI Stephane SCE/IBNF
> Cc: [e-mail]; Brian Haberman; 
> [e-mail]; [e-mail]
> Subject: Re: Alvaro Retana's No Objection on draft-ietf-rtgwg-lfa-
> manageability-09: (with COMMENT)
> 
> On 6/23/15, 5:22 AM, "[e-mail]"
> <[e-mail]> 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:[e-mail]] On Behalf Of Alia Atlas
> Sent: Friday, June 12, 2015 4:23 PM
> To: LITKOWSKI Stephane SCE/IBNF
> Cc: [e-mail]; [e-mail]
> 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:[e-mail]] 
Sent: Tuesday, June 23, 2015 15:44
To: LITKOWSKI Stephane SCE/IBNF
Cc: [e-mail]; [e-mail]; [e-mail]; 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, "[e-mail]"
<[e-mail]> 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.