Subject: Re: [Isis-wg] Comments on draft-ietf-isis-node-admin-tag-00

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 24 Feb 2015 07:17:59 +0000

Hi Les,

Many many thanks for providing the valuable comments. Please find few
comments inline. I will post a new revision soon with all the comments
accepted.

Thanks
-Pushpasis

On 2/23/15, 8:55 PM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

>I have a number of comments on this draft - a few editorial - most
>substantive.
>
>Abstract
>-----------
>s/ofthe/of the
[Pushpasis] Will take care of.

>
>Introduction
>----------------
>I think the last sentence should be removed. It is providing an example
>of a use case - and as such is more appropriate for Section 5.
[Pushpasis] I will see how best to take care of.

>
>Section 2 - First paragraph
>---------------------------------
>I would like to see the last statement revised so that it is more general.
>Also, node-tags are a property of the node - not of the routing protocol
>used to advertise them - I would like to see this point explicitly
>stated. Perhaps something like:
>
>"Per-node administrative tags are used to advertise an attribute of the
>node. As such they are independent of the routing protocol used to
>advertise them. Because per-node administrative tags may be used to
>advertise many different attributes, associating the advertisement to
>TLVs specific to  a particular use case (e.g. IS-Neighbors TLVs in the
>case of TE path selection) is not appropriate."
[Pushpasis] Thanks. I will re-orient the text as suggested.

>
>Section 2 Second Paragraph
>----------------------------------
>Last sentence is grammatically incomplete. Consistent w previous comment
>regarding use cases this sentence should be moved to Section 5.
[Pushpasis] Will take care of.

>
>Section 2 Third Paragraph
>----------------------------------
>Neither L1 nor L2 LSPs as defined in ISO 10589 have "domain-wide"
>flooding scope. Domain-wide flooding of TLV 242 information is achieved
>by leaking the TLV from L2 into L1. This behavior is well defined in RFC
>4971 - you need not discuss it here other than to say that node-tags can
>be flooded domain-wide if appropriate using the mechanisms defined in RFC
>4971.
[Pushpasis] What we meant by Œglobal¹ scope is the scope of Node-admin
tags and not the LSPs themselves. I will reword this to something more
appropriate.

>
>Section 2 Fourth and Fifth Paragraphs
>------------------------------------------------
>I don't agree with the content of these paragraphs.  It may be perfectly
>acceptable to use the same tag value domain-wide - it depends upon the
>functionality associated w the tag. I think these two paragraphs should
>be deleted.
[Pushpasis] I am assuming you are asking that a tag value that has been
used in a Œper-level¹ scope can also be re-used in Œdomain-wide¹ scope. Is
that right? 
Regarding removal of these paragraphs, these paragraphs were put in as per
requests from few members who think this MUST be explicitly mentioned for
interoperability cases. So I don¹t think removing them will be right thing
to do.

>
>Section 2 Sixth Paragraph
>--------------------------------
>You are repeating a description contained in RFC 4971 - and your
>description is not as clear. There is no need for this. A reference to
>RFC 4971 is all that is required.
[Pushpasis] Agree there is repetition from RFC 4971. But we think it gives
enough clarifications for implementors. I will add some reference to RFC
4971 here.

>
>Section 2 Final Paragraph
>---------------------------------
>The advertisement of tags (and Router Capabilities in general) is NOT
>topology specific. The restriction you describe in this paragraph is
>undetectable and unenforceable. The use of node-tags is configuration
>specific - it is only in that context that you can choose to make a
>particular tag value have significance in either one topology or all
>topologies. This paragraph should be removed as well.
[Pushpasis] This paragraph addresses a previous comment from Uma C, that
seeked details on how node-admin-tags shuold be supported in MT
deployments. Also we think this section is valuable for implementors as
well.

>
>Section 4 Paragraph 5
>----------------------------
>Consistent w my comments above this paragraph should be removed.
[Pushpasis] Again, these paragraphs were put in as per requests from few
members who think this MUST be explicitly mentioned for interoperability
cases. So I don¹t think removing them will be right thing to do.

>
>Section 4 Paragraph 6
>------------------------------
>This states 
>
>" The per-node administrative tags are not meant to be extended by the
>   future IS-IS standards."
>
>I do not understand what you are trying to say here.
[Pushpasis] What we meant is unlike other well-known capabilities
advertised using Router-Cap TLVs that can be added one-by-one in future
(needing new TLV definitions, and IANA code point allocations), the
Node-admin tag TLV need not be redefined in future to carry newer
capabilities/attributes. I will try to explain this in the text more.

>
>Section 5
>-------------
>
>This section, while useful, is not normative. I would like to see it
>moved to an Appendix.
[Pushpasis] This section is a contribution from a number of members who
feel such usecases should be mentioned explicitly for better guidance to
network operators and implementors. Also, this section was copied from
draft-ietf-ospf-node-admin-tag on request from few members. I don¹t see a
reason to move this to an Appendix. A separate section dedicated to the
usability/application of Node-admin-tags seem more apt.

>
>   Les
>
>
>_______________________________________________
>Isis-wg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 24 Feb 2015 08:15:12 +0000

Pushpassis -

Thanx for the prompt reply.
Please see my responses inline.

> -----Original Message-----
> From: Pushpasis Sarkar [mailto:[email-masked]]
> Sent: Monday, February 23, 2015 11:18 PM
> To: Les Ginsberg (ginsberg); [email-masked]; draft-ietf-isis-node-admin-
> [email-masked]
> Subject: Re: [Isis-wg] Comments on draft-ietf-isis-node-admin-tag-00
> 
> Hi Les,
> 
> >Also, node-tags are a property of the node - not of the routing
> >protocol used to advertise them - I would like to see this point
> >explicitly stated. Perhaps something like:
> >
> >Last sentence is grammatically incomplete. Consistent w previous
> >comment regarding use cases this sentence should be moved to Section 5.
> >4971 - you need not discuss it here other than to say that node-tags
> >can be flooded domain-wide if appropriate using the mechanisms defined
> >in RFC 4971.
> >I don't agree with the content of these paragraphs.  It may be
> >perfectly acceptable to use the same tag value domain-wide - it depends
> >upon the functionality associated w the tag. I think these two
> >paragraphs should be deleted.
> [Pushpasis] I am assuming you are asking that a tag value that has been used
> in a Œper-level¹ scope can also be re-used in Œdomain-wide¹ scope. Is that
> right?

[Les:] Well yes, though I would use the term "can be used" rather than "re-used".  Perhaps what you are trying to say is that if the use case for a tag is within an area (for example), that you should not use the same tag for a different use case with domain-wide scope? If so, it is very hard to parse that from what is written because a tag with domain-wide scope is indeed flooded "within a level and across levels".

How about this text:

"A given tag MAY be advertised with level-specific scope (Level-1 and/or Level-2) or with domain-wide scope, but MUST NOT be advertised in both scopes."

???

> requests from few members who think this MUST be explicitly mentioned
> for interoperability cases. So I don¹t think removing them will be right thing to
> do.
> 
> 
> 
> >
[Les:] Please don't try to repeat what RFC 4971 says. Simply reference it. As I often comment, there are only two outcomes when you attempt to paraphrase/repeat what is in another specification:

1)You get it right - in which case the text is redundant
2)You get it wrong and now you have introduced ambiguity

> deployments. Also we think this section is valuable for implementors as well.
> 
[Les:]  Depending on the use case, it may be quite appropriate to use the same tag in all topologies. For example, if I want to use a tag to identify a router's physical location (what city, what country, what continent...) this is topology independent. Yet, the draft as currently written says this is forbidden. Further, an implementer of this specification cannot enforce any topology context because the advertisement does not have a topology identifier - so this is of no value to the implementers.

The usefulness of the mechanism defined in this draft is enhanced by its simplicity. The IGP is simply a transport for an identifier. How the identifier is used is completely outside the scope of the transport. Please don’t clutter it up with restrictions that the transport can neither enforce nor detect and which are in fact not real restrictions.

> cases. So I don¹t think removing them will be right thing to do.

[Les:] See my comments above regarding scope.

> (needing new TLV definitions, and IANA code point allocations), the Node-
> admin tag TLV need not be redefined in future to carry newer
[Les:] So you mean unlike a bitfield w unused bits, node-tags are simply a 32 bit number and therefore we cannot set aside certain bits for a dedicated purpose?
Just because there are other sub-TLVs advertised in Router Capability TLV and some of them have bit-fields does not say anything about any other sub-TLV format. 

I think this could be more succinctly put by modifying the description of the Value field in Section 3.1 to say:

"One or more 32 bit tag values."

This is also consistent with the text in Section 2.
RFC 5130 is a good reference/example here.

I really think you don’t need all of this text in Section 4. 
 
> usability/application of Node-admin-tags seem more apt.

[Les:] I did not say remove the section - I agree it is useful. But it is not part of the normative specification. Putting it in an Appendix clearly indicates that.
BTW, I also made the same comment on the OSPF draft in a post to the OSPF WG list. :-)

   Les

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 24 Feb 2015 08:41:29 +0000

Hi Les,

On 2/24/15, 1:45 PM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

>>used
>[Les:] Well yes, though I would use the term "can be used" rather than
>"re-used".  Perhaps what you are trying to say is that if the use case
>for a tag is within an area (for example), that you should not use the
>same tag for a different use case with domain-wide scope? If so, it is
>very hard to parse that from what is written because a tag with
>domain-wide scope is indeed flooded "within a level and across levels".
>
>How about this text:
>
>"A given tag MAY be advertised with level-specific scope (Level-1 and/or
>Level-2) or with domain-wide scope, but MUST NOT be advertised in both
>scopes."
>
>???
[Pushpasis] Yes this is exactly what we intended to say :) Thanks once
again. I will update the text accordingly.

>[Les:] Please don't try to repeat what RFC 4971 says. Simply reference
>it. As I often comment, there are only two outcomes when you attempt to
>paraphrase/repeat what is in another specification:
>
[Pushpasis] Ok. I will modify the text to remove any ambiguity.

>[Les:]  Depending on the use case, it may be quite appropriate to use the
>same tag in all topologies. For example, if I want to use a tag to
>identify a router's physical location (what city, what country, what
>continent...) this is topology independent. Yet, the draft as currently
>written says this is forbidden. Further, an implementer of this
>specification cannot enforce any topology context because the
>advertisement does not have a topology identifier - so this is of no
>value to the implementers.
[Pushpasis] The text here says even in multiple topology case a
node-admin-tag associated with a node cannot signify separate attributes
under separate topologies. So a node-admin-tag MUST NOT be used to signify
separate attribute/purpose under different topologies.

>
>The usefulness of the mechanism defined in this draft is enhanced by its
>simplicity. The IGP is simply a transport for an identifier. How the
>identifier is used is completely outside the scope of the transport.
>Please don’t clutter it up with restrictions that the transport can
>neither enforce nor detect and which are in fact not real restrictions.
[Pushpasis] I feel the MT deployment is unique to ISIS and this draft
should clarify it as well.

>>Node-
>[Les:] So you mean unlike a bitfield w unused bits, node-tags are simply
>a 32 bit number and therefore we cannot set aside certain bits for a
>dedicated purpose?
>Just because there are other sub-TLVs advertised in Router Capability TLV
>and some of them have bit-fields does not say anything about any other
>sub-TLV format. 
>
[Pushpasis] Actually these texts were all added based on discussion on
WG-mailing lists. There were suggestions to use bit-flields like
well-defined bits that needed new definitions to be added as and when new
capabilities needed. We did not want that and so to be specific these
explicit texts were added. And we would like to continue keeping the text.
Maybe I will try to massage the text to remove any disambiguity.

>[Les:] I did not say remove the section - I agree it is useful. But it is
>not part of the normative specification. Putting it in an Appendix
>clearly indicates that.
[Pushpasis] I saw that too :) I had a discussion with Shraddha. We still
think that keeping it as a section is more apt. However if majority WG
members feel that this should be moved to an Appendix, we will reconsider
it.

Thanks once again,
-Pushpasis

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 25 Feb 2015 07:14:20 +0000

Pushpasis -

(Finally spelled your name correctly - my apologies for my earlier errors)

> Sent: Tuesday, February 24, 2015 12:41 AM
> >> comments inline. I will post a new revision soon with all the
> >> comments accepted.
> >>
> >> Thanks
> >> -Pushpasis
> >>
> >> >I think the last sentence should be removed. It is providing an
> >> >example of a use case - and as such is more appropriate for Section 5.
> >> >"Per-node administrative tags are used to advertise an attribute of
> >> >the node. As such they are independent of the routing protocol used
> >> >to advertise them. Because per-node administrative tags may be used
> >> >to advertise many different attributes, associating the
> >> >advertisement to TLVs specific to  a particular use case (e.g.
> >> >IS-Neighbors TLVs in the case of TE path selection) is not appropriate."
> >> >flooding scope. Domain-wide flooding of TLV 242 information is
> >> >achieved by leaking the TLV from L2 into L1. This behavior is well
> >> >defined in RFC
> >> >can be flooded domain-wide if appropriate using the mechanisms
> >> >defined in RFC 4971.
> >> [Pushpasis] What we meant by Œglobal¹ scope is the scope of
> >> Node-admin tags and not the LSPs themselves. I will reword this to
> >> something more appropriate.
> >>
> >>
> >>
> >> >
> >> >perfectly acceptable to use the same tag value domain-wide - it
> >> >depends upon the functionality associated w the tag. I think these
> >> >two paragraphs should be deleted.
> >> [Pushpasis] I am assuming you are asking that a tag value that has
> >>been used  in a Œper-level¹ scope can also be re-used in Œdomain-wide¹
> >>scope. Is that  right?
> >
> [Pushpasis] Yes this is exactly what we intended to say :) Thanks once again. I
> will update the text accordingly.
> 
> >
> >> Regarding removal of these paragraphs, these paragraphs were put in
> >>as per  requests from few members who think this MUST be explicitly
> >>mentioned  for interoperability cases. So I don¹t think removing them
> >>will be right thing to  do.
> >>
> >>
> >>
> >> >
> >> >description is not as clear. There is no need for this. A reference
> >> >to RFC 4971 is all that is required.
> >> [Pushpasis] Agree there is repetition from RFC 4971. But we think it
> >>gives  enough clarifications for implementors. I will add some
> >>reference to RFC
> >> 4971 here.
> >>
> >1)You get it right - in which case the text is redundant 2)You get it
> >wrong and now you have introduced ambiguity
> >> >The advertisement of tags (and Router Capabilities in general) is
> >> >NOT topology specific. The restriction you describe in this
> >> >paragraph is undetectable and unenforceable. The use of node-tags is
> >> >configuration specific - it is only in that context that you can
> >> >choose to make a particular tag value have significance in either
> >> >one topology or all topologies. This paragraph should be removed as
> well.
> >> [Pushpasis] This paragraph addresses a previous comment from Uma C,
> >>that  seeked details on how node-admin-tags shuold be supported in MT
> >[Les:]  Depending on the use case, it may be quite appropriate to use
> >the same tag in all topologies. For example, if I want to use a tag to
> [Pushpasis] The text here says even in multiple topology case a node-admin-
> tag associated with a node cannot signify separate attributes under separate
> topologies. So a node-admin-tag MUST NOT be used to signify separate
> attribute/purpose under different topologies.

[Les:] The draft says:

"...configuring the same per-node administrative tag across different
   topologies, SHOULD NOT be allowed.  Advertising the same tag value
   across multiple topologies..."

How would I indicate that a tag is associated with a particular topology when I advertise it? The answer is "I can't" because the advertisement of tags has no topology context. This makes the text above meaningless.
Please remove it.

> 
> >
> >The usefulness of the mechanism defined in this draft is enhanced by
> >its simplicity. The IGP is simply a transport for an identifier. How
> >the identifier is used is completely outside the scope of the transport.
> [Pushpasis] I feel the MT deployment is unique to ISIS and this draft should
> clarify it as well.

[Les:] You aren't clarifying - you are discussing MT for a sub-TLV that isn't "topology aware" - which is simply confusing (and incorrect).
And MT is NOT unique to IS-IS - see RFC 4915. :-)

> >> [Pushpasis] Again, these paragraphs were put in as per requests from
> >> few members who think this MUST be explicitly mentioned for
> >> interoperability cases. So I don¹t think removing them will be right thing to
> do.
> >>
> >
> >>advertised using Router-Cap TLVs that can be added one-by-one in
> >>future  (needing new TLV definitions, and IANA code point
> >>allocations), the
> >>Node-
> >[Les:] So you mean unlike a bitfield w unused bits, node-tags are
> >simply a 32 bit number and therefore we cannot set aside certain bits
> >for a dedicated purpose?
> >Just because there are other sub-TLVs advertised in Router Capability
> >TLV and some of them have bit-fields does not say anything about any
> >other sub-TLV format.
> >
> >I think this could be more succinctly put by modifying the description
> >of the Value field in Section 3.1 to say:
> >
> [Pushpasis] Actually these texts were all added based on discussion on WG-
> mailing lists. There were suggestions to use bit-flields like well-defined bits
> that needed new definitions to be added as and when new capabilities
> needed. We did not want that and so to be specific these explicit texts were
> added. And we would like to continue keeping the text.

[Les:] With this sort of reasoning, every TLV that has a value encoded as an integer should explicitly state it should not be changed in the future to be encoded as a bit field (and vice versa). Maybe we should also state that it should not become a floating point number or an ASCII string...

OK. I am exaggerating to make a point. The discussion of capabilities bits w reserved meaning vs integer tags which acquired meaning only via configuration was a useful one - but that does not translate into a requirement to state that now that we chose to use integers that we are required to state that this MUST NOT become a bitfield in the future. That was not the point of the discussion. If we had decided to use a bitfield the format of the sub-TLV would have been defined differently. Once the draft is approved and published it becomes a standard and any change to the encoding would by definition violate the standard.  This text is unnecessary and confusing. The draft is better and more easily understood without it.

   Les

> >> [Pushpasis] This section is a contribution from a number of members
> >>who  feel such usecases should be mentioned explicitly for better
> >>guidance to  network operators and implementors. Also, this section
> >>was copied from  draft-ietf-ospf-node-admin-tag on request from few
> >>members. I don¹t see a  reason to move this to an Appendix. A separate
> >>section dedicated to the  usability/application of Node-admin-tags
> >>seem more apt.
> >
> >[Les:] I did not say remove the section - I agree it is useful. But it
> >is not part of the normative specification. Putting it in an Appendix
> >clearly indicates that.
> [Pushpasis] I saw that too :) I had a discussion with Shraddha. We still think
> that keeping it as a section is more apt. However if majority WG members
> feel that this should be moved to an Appendix, we will reconsider it.
> 
> 
> Thanks once again,
> -Pushpasis
> 
> >
> >   Les
> >
> >>
> >> >
> >> >   Les
> >> >
> >> >

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 26 Feb 2015 14:30:33 +0000

Hi Les,

Sorry for the late response. Please find answers inline.

On 2/25/15, 12:44 PM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

>>node-admin-
>How would I indicate that a tag is associated with a particular topology
>when I advertise it? The answer is "I can't" because the advertisement of
>tags has no topology context. This makes the text above meaningless.
>Please remove it.
[Pushpasis] You are right that the topology cannot be advertises along
with the node-admin tag. But the above statement is actually about the
config model for  provisioning node-admin tags. If the implementation
provides a per-topology knob for attaching and advertising node-admin tags
following are the possiblities
1. Operator my want to use node-admin tag A for topology T1 to
representing attribute A1 and use the same tag A for topology T2 to
representing attribute A2. This can cause confusion to the receiver of
such advertisement because it will not get wether it meant attribute A1 or
A2. So this paragraph prohibits implementations from letting operator to
set the same tag under multiple topologies. So in the above example
operator can use tag A for attribute A1 and tag B for attribute A2.
2. Operator may still want to advertise the same tag representing the same
attribute for all topologies under the same level. In such cases operators
shall be able to configure tag A at the per-level (and per-topology)
configuration that shall be advertised in level-specific LSP and still
represent the same attribute for all topologies under that level.

>[Les:] You aren't clarifying - you are discussing MT for a sub-TLV that
>isn't "topology aware" - which is simply confusing (and incorrect).
[Pushpasis] Hope I could clarify the need for this section. I don’t think
removing this will be a good option. But I will surely try to remove any
confusion it poses.

>>WG-
>[Les:] With this sort of reasoning, every TLV that has a value encoded as
>an integer should explicitly state it should not be changed in the future
>to be encoded as a bit field (and vice versa). Maybe we should also state
>that it should not become a floating point number or an ASCII string...
>
>OK. I am exaggerating to make a point. The discussion of capabilities
>bits w reserved meaning vs integer tags which acquired meaning only via
>configuration was a useful one - but that does not translate into a
>requirement to state that now that we chose to use integers that we are
>required to state that this MUST NOT become a bitfield in the future.
>That was not the point of the discussion. If we had decided to use a
>bitfield the format of the sub-TLV would have been defined differently.
>Once the draft is approved and published it becomes a standard and any
>change to the encoding would by definition violate the standard.  This
>text is unnecessary and confusing. The draft is better and more easily
>understood without it.
[Pushpasis] Like said before I will try massaging the text to remove any
disambiguity.

Thanks once again
-Pushpasis