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

Like Hannes I +1 this ...

--- tony

On Fri, May 6, 2016 at 9:36 AM, Les Ginsberg (ginsberg) <ginsberg@cisco.com>
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.
>
>
>
>    Les
>
>
>
>
>
> *From:* Isis-wg [mailto:isis-wg-bounces@ietf.org] *On Behalf Of *Les
> Ginsberg (ginsberg)
> *Sent:* Friday, May 06, 2016 9:25 AM
> *To:* bruno.decraene@orange.com; Pushpasis Sarkar; Alia Atlas; Jari
> Arkko; Peter Yee
> *Cc:* draft-ietf-isis-node-admin-tag@ietf.org; isis-chairs@ietf.org;
> Christian Hopps; isis-wg@ietf.org; 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:* bruno.decraene@orange.com [mailto:bruno.decraene@orange.com
> <bruno.decraene@orange.com>]
> *Sent:* Friday, May 06, 2016 1:18 AM
> *To:* Les Ginsberg (ginsberg); Pushpasis Sarkar; Alia Atlas; Jari Arkko;
> Peter Yee
> *Cc:* isis-wg@ietf.org; Christian Hopps;
> draft-ietf-isis-node-admin-tag@ietf.org; The IESG; isis-chairs@ietf.org
> *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:ginsberg@cisco.com
> <ginsberg@cisco.com>]
> *Sent:* Thursday, May 05, 2016 8:00 AM
> *To:* Pushpasis Sarkar; Alia Atlas; Jari Arkko
> *Cc:* Peter Yee; isis-wg@ietf.org; Christian Hopps;
> draft-ietf-isis-node-admin-tag@ietf.org; The IESG; isis-chairs@ietf.org
> *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:pushpasis.ietf@gmail.com
> <pushpasis.ietf@gmail.com>]
> *Sent:* Wednesday, May 04, 2016 9:49 PM
> *To:* Alia Atlas; Jari Arkko
> *Cc:* Les Ginsberg (ginsberg); Peter Yee; isis-wg@ietf.org; Christian
> Hopps; draft-ietf-isis-node-admin-tag@ietf.org; The IESG;
> isis-chairs@ietf.org
> *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 <jari.arkko@piuha.net> 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.
>
>
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
>
>

-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky