Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)

[<[e-mail]>]

Hi all,

I was fine with the original text as in the context of IS-IS/OSPF, I think the reader would get the picture.

Yet, out of this IGP context, Peter’s comment seems reasonable to me.

So, although I can live with the current proposed text, I don’t feel that changing “MUST be stable” into “MUST NOT […] oscillate frequently” really address the point. (Sorry to spoil the party while everybody is so nice)

A few questions to try to better identify the problem we want to address with this sentence:
- How much is this specific to admin-tag? I would expect this requirement (size & stability) to apply to many/most link state IGP advertisements. Can we refer to existing text?
- More specifically, IMO, this equally applies to the parent TLV (CAPABILITY) and any of its content. So what about moving this requirement there? Especially since its spec is being revised (draft-ietf-isis-rfc4971bis-01 has just passed WG last called).
- Although I’m all for IGP stability,  I’m not sure to see why this sub-TLV needs to be more stable than others, especially ones triggering re-routing computations. So as we allow for redistributing IP prefixes and even IP prefixes metric between IS-IS level, I’m not sure to see the basis for a “MUST NOT be associated with […] e.g., the reachability of a specific destination”.

In the meantime, I would propose:
- to put the normative text in draft-ietf-isis-rfc4971bis-01, possibly including text to require implementation to limit the frequency of the CAPABILITY TLV advertisement
- to put a non normative text in node-admin. e.g.
“Node administrative tags are expected to be associated with a stable
attribute. In particular, node administrative tags must not  be associated
with something whose state can oscillate frequently. The network operator should avoid have tag dependent on states external to the node, as this decrease the control of the stability and may even create cycle in advertisement.

While no specific limit on the number of node administrative tags that
may be advertised is defined, it is expected that only a modest number
of tags will be required in any deployment.”

-- Bruno

From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
Sent: Thursday, May 05, 2016 8:00 AM
To: Pushpasis Sarkar; Alia Atlas; Jari Arkko
Cc: Peter Yee; [e-mail]; Christian Hopps; [e-mail]; The IESG; [e-mail]
Subject: RE: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)

Thanx to everyone for the positive feedback.

Peter has been kind enough to provide some grammatical corrections – and polite enough to do it privately. Here is corrected text (any remaining grammatical issues are still mine):

““Node administrative tags are expected to be associated with a stable
attribute. In particular, node administrative tags MUST NOT be associated
with something whose state can oscillate frequently, e.g., the reachability
of a specific destination.

While no specific limit on the number of node administrative tags that
may be advertised is defined, it is expected that only a modest number
of tags will be required in any deployment.”

   Les


From: Pushpasis Sarkar [mailto:[e-mail]]
Sent: Wednesday, May 04, 2016 9:49 PM
To: Alia Atlas; Jari Arkko
Cc: Les Ginsberg (ginsberg); Peter Yee; [e-mail]<mailto:[e-mail]>; Christian Hopps; [e-mail]<mailto:[e-mail]>; The IESG; [e-mail]<mailto:[e-mail]>
Subject: Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)

Hi Les,

Thanks for suggesting the text..  I was wondering how to resolve this comment.. Especially since the text already appeared in RFC7777... :)

Hi Alia,

I will check with the other authors and come back if we are fine with this text or not..

Thanks and Regards,
-Pushpasis
On 5/5/16 6:24 AM, Alia Atlas wrote:
Les,

I also like this wording.  It's definitely an improvement.
Thanks for your help!  Let's see what the authors say as well.

Regards,
Alia

On Wed, May 4, 2016 at 8:49 PM, Jari Arkko <[e-mail]<mailto:[e-mail]>> wrote:

> How about replacing the second paragraph of Section 4.2 with:
>
> “Node administrative tags are expected to be associated with a stable
> attribute. In particular, node administrative tags MUST NOT be associated
> with something whose state can oscillate frequently e.g., the reachability
> to a specific destination.
>
> While no specific limit on the number of node administrative tags which
> may be advertised is defined, it is expected that only a modest number
> of tags will be required in any deployment.”
>

I’d find this an improvement, i.e., in particular more informative.

Jari



_________________________________________________________________________________________________________________________

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.