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

[Pushpasis Sarkar <[e-mail]>]

Hi Les,

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

>Pushpassis -
>
>Thanx for the prompt reply.
>Please see my responses inline.
>
>> -----Original Message-----
>> From: Pushpasis Sarkar [mailto:[e-mail]]
>> Sent: Monday, February 23, 2015 11:18 PM
>> To: Les Ginsberg (ginsberg); [e-mail];
>>draft-ietf-isis-node-admin-
>> [e-mail]
>> Subject: Re: [Isis-wg] Comments on draft-ietf-isis-node-admin-tag-00
>> 
>> 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)" <[e-mail]>
>> 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?
>
>[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.

>
>> 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.
>> 
>[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
[Pushpasis] Ok. I will modify the text to remove any ambiguity.

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

>
>> 
>> 
>> >
>> >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.
>> 
>
>[Les:] See my comments above regarding scope.
>
>> >
>> >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.
>>
>[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.
[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.

> 
> 
>> >
>> >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:] 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. :-)
[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
>> >
>> >
>> >_______________________________________________
>> >Isis-wg mailing list
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/isis-wg
>