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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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.

> 
> >
> >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. :-)


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

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