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

[Pushpasis Sarkar <[e-mail]>]

Hi Les,

Sorry for the late response. Please find answers inline.


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

>Pushpasis -
>
>(Finally spelled your name correctly - my apologies for my earlier errors)
>
>> -----Original Message-----
>> From: Pushpasis Sarkar [mailto:[e-mail]]
>> Sent: Tuesday, February 24, 2015 12:41 AM
>> 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,
>> 
>> 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.
>
>
>[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.
[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.

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

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

>
>   Les
>
>> 
>> >
>> >
>> >> >
>> >> >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
>> >
>