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

[Alia Atlas <[e-mail]>]

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, <[e-mail]> wrote:

> 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.
>
>