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

From: "Alvaro Retana" <[email-masked]>
Date: Mon, 22 Jun 2015 07:41:46 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-rtgwg-lfa-manageability-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. The abstract mentions a lot of things that this document covers:
“provides operational feedback on LFA, highlights some limitations, and
proposes a set of refinements to address those limitations.  It also
proposes required management specifications.”  The Introduction presents
a quick guide to what some sections cover (good idea!), but not all
sections are mentioned there.

It would be nice to cover all the sections in the “document map” in the
introduction.

2. In section 3.1 it may not be clear to all readers why P4 is not an LFA
for P8.  In all the other cases there is an explicit statement (a
sentence or two) that explains and clarifies.

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.

4. The IS-IS overload bit is mentioned in several places as important to
consider.  Are there similar considerations related to the use of the
OSPF MaxLinkMetric or the R-bit?  If so, please include them..if not,
please explain why in the document.  [BTW, there is no reference pointing
to the OL bit.]

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 23 Jun 2015 13:44:21 +0000

On 6/23/15, 5:22 AM, "[email-masked]"
<[email-masked]> 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.

>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
>by just defining the requirements (specially if you¹re pointing at the

---

From: <[email-masked]>
Date: Wed, 24 Jun 2015 09:41:39 +0000

Hi Alvaro, Alia

> From Alvaro Retana> (aretana)
> Sent: Tuesday, June 23, 2015 3:44 PM
> To: LITKOWSKI Stephane SCE/IBNF
> Cc: [email-masked]; Brian Haberman; 
> [email-masked]; [email-masked]
> Subject: Re: Alvaro Retana's No Objection on draft-ietf-rtgwg-lfa-
> manageability-09: (with COMMENT)
> 
> >For the point #3, we had a comment from Alia on the list saying that 
> >we needed to point to some existing solutions.
> >
> > Link color information SHOULD be signalled in the IGP in order to 
> >limit configuration effort.  e.g.
> 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).

CURRENT text is:
 
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:[email-masked]] On Behalf Of Alia Atlas
> Sent: Friday, June 12, 2015 4:23 PM
> To: LITKOWSKI Stephane SCE/IBNF
> Cc: [email-masked]; [email-masked]
> 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:[email-masked]] 
Sent: Tuesday, June 23, 2015 15:44
To: LITKOWSKI Stephane SCE/IBNF
Cc: [email-masked]; [email-masked]; [email-masked]; Brian Haberman
Subject: Re: Alvaro Retana's No Objection on draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)

Stephane:

> Link color information SHOULD be signalled in the IGP in order to 
>limit configuration effort.  e.g.

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.

>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

_________________________________________________________________________________________________________________________

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.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 24 Jun 2015 10:34:09 -0400

I'm fine with clarifying that the existing mechanisms are an example and
not prescriptive.  On the other hand, if different implementations pick
different mechanisms, that's going to cause problems.  Frankly, there have
been admin-groups for a long time now and it's clear those are one of the
things that is meant.  However, the node admin tags have a specific
use-case for node-protecting RLFA - so having a pointer to them as a
possible mechanism is IMHO useful.

Alia

On Wed, Jun 24, 2015 at 5:41 AM, <[email-masked]> wrote:

> > is that this document is not specifying solutions, just requirements..if
> that is true, then don¹t point at the solutions.
> 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.
>
> 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:
> >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.
> Subject: Re: Alvaro Retana's No Objection on
> draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)
>
> 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.
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;