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

[Hannes Gredler <[e-mail]>]

On 5/6/16 18:36, Les Ginsberg (ginsberg) wrote:
> Ohhh…forgot to reply to one point.
>
>
>
> I prefer the normative text
>
>
>
> /“node administrative tags MUST NOT be associated/
>
> /with something whose state can oscillate frequently”/
>
>
>
> This is something we really do want to forbid.

+1

>
>
>
> *From:*Isis-wg [mailto:[e-mail]] *On Behalf Of *Les
> Ginsberg (ginsberg)
> *Sent:* Friday, May 06, 2016 9:25 AM
> *To:* [e-mail]; Pushpasis Sarkar; Alia Atlas; Jari
> Arkko; Peter Yee
> *Cc:* [e-mail]; [e-mail];
> Christian Hopps; [e-mail]; The IESG
> *Subject:* Re: [Isis-wg] Jari Arkko's Discuss on
> draft-ietf-isis-node-admin-tag-10: (with DISCUSS)
>
>
>
> Bruno –
>
>
>
> I am sympathetic to the concerns you have raised.
>
>
>
> The issue has arisen in the context of two different IGP drafts recently
> - this one and the OSPF S-BFD draft.  In the case of the OSPF S-BFD
> draft I find the concern inappropriate since there has been much
> discussion that we have no idea how to deal with 2 S-BFD discriminators
> per node – let alone a larger number – and S-BFD discriminators are as
> likely to change as the address assigned to a node. However, in the case
> of admin tags, the use cases for tags is much more open – in theory a
> tag could be used to represent almost anything – so it does seem prudent
> to emphasize that we don’t want tags to be used to represent states that
> may change frequently.
>
>
>
> The base protocol specifications do not discuss equivalent concerns
> regarding objects like neighbors and prefixes – so it does give me pause
> as to why there now seems to be an assumption that any new advertisement
> requires text on this point. It is important to note that the base IGP
> specs do define mechanisms to insure that flooding of information is
> rate limited in a number of ways because we do not want routing updates
> to overwhelm forwarding – so it isn’t that the issue has not been
> carefully considered.
>
>
>
> In principle I am not averse to adding some generic text to RFC 4971-bis
> to discuss stability (my co-authors would need to weigh in as well).
> However I am not convinced this would eliminate the perceived need to
> add specific text to drafts like the node-admin tag draft. So while it
> may still be a good idea I suspect we still need to resolve the changes
> desired in the node-admin tag draft. If we do choose to modify RFC
> 4971-bis in this way I think RFC 7770 should be updated as well.
>
>
>
>    Les
>
>
>
>
>
> *From:*[e-mail] <mailto:[e-mail]>
> [mailto:[e-mail]]
> *Sent:* Friday, May 06, 2016 1:18 AM
> *To:* Les Ginsberg (ginsberg); Pushpasis Sarkar; Alia Atlas; Jari Arkko;
> Peter Yee
> *Cc:* [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 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] <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)
>
>
>
> 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.
>