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

From: "Jari Arkko" <[email-masked]>
Date: Wed, 04 May 2016 14:12:29 -0700

Jari Arkko has entered the following ballot position for
draft-ietf-isis-node-admin-tag-10: Discuss

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-isis-node-admin-tag/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Peter Yee's Gen-ART review raised this issue which I agree with. Can this
be defined in a more clear fashion? Or is there already a definition
somewhere else that I had not seen?

Page 5, section 4.2, 2nd paragraph, 1st sentence: The sentence states:
"Being part of the Router CAPABILITY TLV, the node administrative tag
sub-TLV MUST be reasonably small and stable."  If you're going to make
this
a MUST, you've got to at least give a definition of "reasonably small"
and
perhaps even "stable" in the context of this specification.  As it
stands,
there's no test for whether the MUST is enforceable or understandable
between parties.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 4 May 2016 18:45:59 -0400

Jari,

I think I need to push back a bit on this one.

I will note that the OSPF version of this same extension (RFC 7777)  uses
exactly
this same text " Being part of the RI LSA, the Node Admin Tag TLV must be
reasonably
   small and stable.  In particular, implementations supporting node
   administrative tags MUST NOT be used to convey attributes of the
   routing topology or associate tags with changes in the network
   topology (both within and outside the OSPF domain) or reachability of
   routes."
Of course, different reviewers find different concerns and that's quite
reasonable.

The sentences following "small and stable" certainly provide guidance on
what is definitely not considered stable "In particular, but not
   limited to, implementations supporting the node administrative tags
   MUST NOT associate advertised tags to changes in the network topology
   (both within and outside the IS-IS domain) or the reachability of
   routes."

Since the total length of sub-TLVs is constrained to no more than 250 bytes
(as specified in RFC 4971 - a normative reference),I think it's clear that
that the
data must be small.  While one can argue about how much of that space
should
be consumed by Node Administrative tags, that does end up being a local
domain decision.

I did see back and forth in the discussion between Peter and Pushpasis about
how specific to be in terms of what number to specify.  Are you looking for
clarification such as:

 "There are only 250 bytes [RFC4971-bis] available for sub-TLVs in the
Router
Capability TLV; the maximum number of different Administrative Tags
advertised
should be limited to permit other necessary sub-TLVs to be advertised.  The
decision on how many Administrative Tags are acceptable is a decision for
the
deploying network."

Regards,
Alia

---

From: "Peter Yee" <[email-masked]>
Date: Wed, 4 May 2016 16:55:23 -0700

Alia,

                See my comments below prefixed with PEY>.

                Thanks.

                                -Peter

From: Alia Atlas [mailto:[email-masked]] 
Sent: Wednesday, May 04, 2016 3:46 PM
To: Jari Arkko
Cc: The IESG; [email-masked]; Peter Yee; Christian Hopps; [email-masked]; [email-masked]
Subject: Re: Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)

Jari,

I will note that the OSPF version of this same extension (RFC 7777)  uses exactly

this same text " Being part of the RI LSA, the Node Admin Tag TLV must be reasonably

Of course, different reviewers find different concerns and that's quite reasonable.

(as specified in RFC 4971 - a normative reference),I think it's clear that that the 

data must be small.  While one can argue about how much of that space should 

be consumed by Node Administrative tags, that does end up being a local domain decision.

PEY> But I believe we’ve also agreed that there can be multiple Node Administrative Tag sub-TLVs, so I’m not sure what the 250 byte limit gives us here other than to make a single sub-TLV fit within a single Router CAPABILITY TLV.  Section 4.3 (paragraph 1) indicates that multiple sub-TLVs may be carried in multiple Router CAPABILITY TLVs, so we already have the ability to exceed the 250 byte boundary for a set of tags.  As for the stability of the set of tags, I don’t think the sentence following “small and stable” wholly addresses that topic.  It does give a useful example of what not to do with the tags, but doesn’t really tie that to a concept of stability unless there’s some definition of how often IS-IS may change the network topology or how frequent route reachability.  Is there a threshold?  (But, see my next reply below before bothering to comment.)

clarification such as:

 "There are only 250 bytes [RFC4971-bis] available for sub-TLVs in the Router

Capability TLV; the maximum number of different Administrative Tags advertised

decision on how many Administrative Tags are acceptable is a decision for the

deploying network."

PEY> Actually, my concern was never over the ability to convey other sub-TLVs in the presence of a large Node Administrative Tag sub-TLV.  It was only with the statement that about the tag set being small and stable.  Nothing else in the document seems to care about how many tags there are or how often they change, so I’d prefer to remove that statement since it has a MUST without a definition.  Perhaps start the relevant paragraph at “implementations” in the 2nd sentence.  That provides the desired guidance without giving an untestable imperative.

PEY> And I’m not a routing expert by any stretch of the imagination, so if the text makes sense in the broader IS-IS or general routing world, by all means discount my comment.  I just don’t like MUSTs where I can’t determine whether I’ve violated the statement.

Regards,

Alia

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 5 May 2016 00:04:54 +0000

Alia –

Sorry, have to jump in on this one.

The fact that IS-IS TLVs/sub-TLVs have an eight bit length only means that in a single TLV/sub-TLV the size is limited. This does NOT mean that multiple TLVs/sub-TLVs cannot be used to advertise the same type of data. The suggestion below that since no more than 250 bytes will fit in a sub-TLV therefore that limits the number of admin tags which could be advertised is therefore simply incorrect.

I did not follow closely the final review of RFC 7777 (apologies) but the choice of language “small and stable” is quite unfortunate. “Stable” is a legitimate concern of course. But “small” suggests that we need to limit the number of admin tags to some arbitrary number. I simply do not see the need to define that.

   Les

From: Isis-wg [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Wednesday, May 04, 2016 3:46 PM
To: Jari Arkko
Cc: Peter Yee; [email-masked]; Christian Hopps; [email-masked]; The IESG; [email-masked]
Subject: Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)

Jari,

Regards,
Alia

On Wed, May 4, 2016 at 5:12 PM, Jari Arkko <[email-masked]<mailto:[email-masked]>> wrote:
Jari Arkko has entered the following ballot position for
draft-ietf-isis-node-admin-tag-10: Discuss

---

From: Alia Atlas <[email-masked]>
Date: Wed, 4 May 2016 20:22:15 -0400

Les & Peter,

True, one can have multiple Router Capability TLVs.

I do think that stable is a MUST.   I don't see a need for further
clarification, but am happy to see other text.

As for small, I don't think that specifying an arbitrary number is needed.
  At the same time, by specifying "small",
it's there's no expectation that this is a good way of transfering a
database via IS-IS.

As I said, this is the same text as in the OSPF RFC and I do see it as both
useful and close to sufficient.
Do you have more clear words to suggest?

Thanks,
Alia

On Wed, May 4, 2016 at 8:04 PM, Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> The fact that IS-IS TLVs/sub-TLVs have an eight bit length only means that
> in a single TLV/sub-TLV the size is limited. This does NOT mean that
> multiple TLVs/sub-TLVs cannot be used to advertise the same type of data.
> The suggestion below that since no more than 250 bytes will fit in a
> sub-TLV therefore that limits the number of admin tags which could be
> advertised is therefore simply incorrect.
>
>
>
> I did not follow closely the final review of RFC 7777 (apologies) but the
> choice of language “small and stable” is quite unfortunate. “Stable” is a
> legitimate concern of course. But “small” suggests that we need to limit
> the number of admin tags to some arbitrary number. I simply do not see the
> need to define that.
>
>
>
>    Les
>
>
>
>
>
> *From:* Isis-wg [mailto:[email-masked]] *On Behalf Of *Alia
> Atlas
> *Sent:* Wednesday, May 04, 2016 3:46 PM
> *To:* Jari Arkko
> *Cc:* Peter Yee; [email-masked]; Christian Hopps;
> [email-masked]; The IESG; [email-masked]
> *Subject:* Re: [Isis-wg] Jari Arkko's Discuss on
> draft-ietf-isis-node-admin-tag-10: (with DISCUSS)
>
>
>
> Jari,
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 5 May 2016 00:45:34 +0000

Alia –

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

   Les

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

Les & Peter,

I do think that stable is a MUST.   I don't see a need for further clarification, but am happy to see other text.

As for small, I don't think that specifying an arbitrary number is needed.   At the same time, by specifying "small",
it's there's no expectation that this is a good way of transfering a database via IS-IS.

As I said, this is the same text as in the OSPF RFC and I do see it as both useful and close to sufficient.
Do you have more clear words to suggest?

Thanks,
Alia

On Wed, May 4, 2016 at 8:04 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Alia –

   Les

From: Isis-wg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alia Atlas
Sent: Wednesday, May 04, 2016 3:46 PM
To: Jari Arkko
Cc: Peter Yee; [email-masked]<mailto:[email-masked]>; Christian Hopps; [email-masked]<mailto:[email-masked]>; The IESG; [email-masked]<mailto:[email-masked]>
Subject: Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)

Jari,

Regards,
Alia

---

From: Jari Arkko <[email-masked]>
Date: Wed, 4 May 2016 20:49:25 -0400

> of tags will be required in any deployment.”

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

Jari

---

From: Alia Atlas <[email-masked]>
Date: Wed, 4 May 2016 20:54:55 -0400

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

---

From: "Peter Yee" <[email-masked]>
Date: Wed, 4 May 2016 18:02:20 -0700

Certainly works to address my concern.  A couple of grammar nits, but that’s just me. ;-)

                                -Peter

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

Les,

Regards,

Alia

Jari

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 5 May 2016 10:18:32 +0530

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:
> On Wed, May 4, 2016 at 8:49 PM, Jari Arkko <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 5 May 2016 06:00:09 +0000

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:[email-masked]]
Sent: Wednesday, May 04, 2016 9:49 PM
To: Alia Atlas; Jari Arkko
Cc: Les Ginsberg (ginsberg); Peter Yee; [email-masked]; Christian Hopps; [email-masked]; The IESG; [email-masked]
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

Regards,
Alia

Jari

---

From: <[email-masked]>
Date: Fri, 6 May 2016 08:18:21 +0000

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.

-- Bruno

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

   Les

Cc: Les Ginsberg (ginsberg); Peter Yee; [email-masked]<mailto:[email-masked]>; Christian Hopps; [email-masked]<mailto:[email-masked]>; The IESG; [email-masked]<mailto:[email-masked]>

Hi Les,

Hi Alia,

Thanks and Regards,
-Pushpasis

Regards,
Alia

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.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Fri, 6 May 2016 14:02:29 +0530

Hi Jari, Peter, Les, Alia et al,

I was in the process of preparing the next version.. I will greatly 
appreciate your comments on the following proposal from Bruno. :)

Thanks and Regards,
-Pushpasis

On Friday 06 May 2016 01:48 PM, [email-masked] wrote:
> 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)
>
> - 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”.
>
> - 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
>
> 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.
>
> *From:*Les Ginsberg (ginsberg) [mailto:[email-masked]]
> *Sent:* Thursday, May 05, 2016 8:00 AM
> *To:* Pushpasis Sarkar; Alia Atlas; Jari Arkko
> *Subject:* RE: [Isis-wg] Jari Arkko's Discuss on 
> 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):
>
> *From:*Pushpasis Sarkar [mailto:[email-masked]]
> *Sent:* Wednesday, May 04, 2016 9:49 PM
> *To:* Alia Atlas; Jari Arkko
> *Cc:* Les Ginsberg (ginsberg); Peter Yee; [email-masked] 
> <mailto:[email-masked]>; Christian Hopps; 
> [email-masked] 
> <mailto:[email-masked]>; The IESG; 
> [email-masked] <mailto:[email-masked]>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 6 May 2016 16:24:44 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 06, 2016 1:18 AM
To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Alia Atlas; Jari Arkko; Peter Yee
Cc: [email-masked]; Christian Hopps; [email-masked]; The IESG; [email-masked]
Subject: RE: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)

Hi all,

-- Bruno

   Les

Hi Les,

Hi Alia,

Thanks and Regards,
-Pushpasis

Regards,
Alia

Jari

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 6 May 2016 16:36:13 +0000

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:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, May 06, 2016 9:25 AM
To: [email-masked]; Pushpasis Sarkar; Alia Atlas; Jari Arkko; Peter Yee
Cc: [email-masked]; [email-masked]; Christian Hopps; [email-masked]; The IESG
Subject: Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)

Bruno –

   Les

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, May 06, 2016 1:18 AM
To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Alia Atlas; Jari Arkko; Peter Yee
Cc: [email-masked]<mailto:[email-masked]>; Christian Hopps; [email-masked]<mailto:[email-masked]>; The IESG; [email-masked]<mailto:[email-masked]>
Subject: RE: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)

Hi all,

-- Bruno

   Les

Hi Les,

Hi Alia,

Thanks and Regards,
-Pushpasis

Regards,
Alia

Jari

Thank you.

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 6 May 2016 19:12:06 +0200

On 5/6/16 18:36, Les Ginsberg (ginsberg) wrote:
> /“node administrative tags MUST NOT be associated/
>
> /with something whose state can oscillate frequently”/
>
>
>

+1

>
>
>
> *From:*Isis-wg [mailto:[email-masked]] *On Behalf Of *Les
> Ginsberg (ginsberg)
> *Sent:* Friday, May 06, 2016 9:25 AM
> *To:* [email-masked]; Pushpasis Sarkar; Alia Atlas; Jari
> Arkko; Peter Yee
> *Cc:* [email-masked]; [email-masked];
> Christian Hopps; [email-masked]; The IESG
> 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:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]]
> *Sent:* Friday, May 06, 2016 1:18 AM
> *To:* Les Ginsberg (ginsberg); Pushpasis Sarkar; Alia Atlas; Jari Arkko;
> Peter Yee
> *Cc:* [email-masked] <mailto:[email-masked]>; Christian Hopps;
> that changing “MUST be stable” into “MUST NOT […] oscillate frequently”
> really address the point. (Sorry to spoil the party while everybody is
> so nice)
>
>
>
> 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”.
>
>
>
> 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.
>
>
>
> *Cc:* Peter Yee; [email-masked] <mailto:[email-masked]>; Christian
> Hopps; [email-masked]
> 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):
>
>
>
> 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;
>

---

From: <[email-masked]>
Date: Mon, 9 May 2016 09:00:37 +0000

Les,

Thanks for the additional info.
Your text works for me.

Thanks,
-- Bruno

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, May 06, 2016 6:36 PM
To: DECRAENE Bruno IMT/OLN; Pushpasis Sarkar; Alia Atlas; Jari Arkko; Peter Yee
Cc: [email-masked]; [email-masked]; Christian Hopps; [email-masked]; The IESG
Subject: RE: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)

   Les

From: Isis-wg [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, May 06, 2016 9:25 AM
To: [email-masked]<mailto:[email-masked]>; Pushpasis Sarkar; Alia Atlas; Jari Arkko; Peter Yee
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Christian Hopps; [email-masked]<mailto:[email-masked]>; The IESG
Subject: Re: [Isis-wg] Jari Arkko's Discuss on draft-ietf-isis-node-admin-tag-10: (with DISCUSS)

Bruno –

   Les

Hi all,

-- Bruno

   Les

Hi Les,

Hi Alia,

Thanks and Regards,
-Pushpasis

Regards,
Alia

Jari

Thank you.

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 9 May 2016 14:27:09 -0700

Like Hannes I +1 this ...

--- tony

On Fri, May 6, 2016 at 9:36 AM, Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> *“node administrative tags MUST NOT be associated*
>
> *with something whose state can oscillate frequently”*
>
>
>
> *From:* Isis-wg [mailto:[email-masked]] *On Behalf Of *Les
> Ginsberg (ginsberg)
> 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.
>
>
>
> 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
> 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.
>
>
>
> 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:* [email-masked] [mailto:[email-masked]
> <[email-masked]>]
> *Cc:* [email-masked]; Christian Hopps;
> 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)
>
>
>
> - 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?
>
> (CAPABILITY) and any of its content. So what about moving this requirement
> there? Especially since its spec is being revised
> 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”.
>
>
>
> 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.
>
>
>
> *From:* Les Ginsberg (ginsberg) [mailto:[email-masked]
> <[email-masked]>]
> *From:* Pushpasis Sarkar [mailto:[email-masked]
> <[email-masked]>]
> *Cc:* Les Ginsberg (ginsberg); Peter Yee; [email-masked]; Christian
> Hopps; [email-masked]; The IESG;
> [email-masked]
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> 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

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 10 May 2016 08:59:27 +0530

Hi Jari,

I have uploaded version-11 addressing all the comments below. Please let 
me know if you have any more comments.

Thanks and Regards,

-Pushpasis

---

From: Jari Arkko <[email-masked]>
Date: Tue, 10 May 2016 00:57:18 -0400

I cleared the discuss.

Jari