Re: [Isis-wg] Comments on draft-ietf-isis-node-admin-tag-00
"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 25 February 2015 07:14 UTC
Return-Path: <ginsberg@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466A21A1BC7 for <isis-wg@ietfa.amsl.com>; Tue, 24 Feb 2015 23:14:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CS74b40taRj for <isis-wg@ietfa.amsl.com>; Tue, 24 Feb 2015 23:14:23 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DBE31A1B6A for <isis-wg@ietf.org>; Tue, 24 Feb 2015 23:14:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18496; q=dns/txt; s=iport; t=1424848463; x=1426058063; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1dzvr9dPKfkiPtLZxEfCcJSH2Lcz7fj40ieYK8fmt0k=; b=LlOzMwbzd6MDSNlJUYCkW8lizSyGCJiru18wIY/IvBvGApEeaCIf5mwD QkKPiJRSjscZ7ozijIGwO+1GDAjbnieYT+QaCpmZ8xyGzHDwJ5vQqIFjp n/Iti15LaScLUN8zBsfTt8kHvM/4H6Q6yNDD+554RnwIDeWv5RhtaYAXu w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BTBQAhde1U/51dJa1RCoMDUloEgwS+foEZCoVwAhyBBUMBAQEBAQF8hA8BAQEEAQEBIBE6FwQCAQgOAwQBAQECAgYdAwICAiULFAEICAIEARIIiCcNuxuDF5YUAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIYh0foQSKxYiBoJiL4EUBYVkiXeKYIMZiDmDEIM+IoICHIFQb4FEfwEBAQ
X-IronPort-AV: E=Sophos;i="5.09,643,1418083200"; d="scan'208";a="399263175"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 25 Feb 2015 07:14:22 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t1P7EMLC011842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Feb 2015 07:14:22 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.138]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Wed, 25 Feb 2015 01:14:21 -0600
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Pushpasis Sarkar <psarkar@juniper.net>, "isis-wg@ietf.org" <isis-wg@ietf.org>, "draft-ietf-isis-node-admin-tag@tools.ietf.org" <draft-ietf-isis-node-admin-tag@tools.ietf.org>
Thread-Topic: [Isis-wg] Comments on draft-ietf-isis-node-admin-tag-00
Thread-Index: AQHQUAIEq/+eeisYnEW624mzAaezbpz/Zn7ggAB5cICAAQ8+4A==
Date: Wed, 25 Feb 2015 07:14:20 +0000
Message-ID: <F3ADE4747C9E124B89F0ED2180CC814F4EF321BC@xmb-aln-x02.cisco.com>
References: <D1121C1C.20EE1%psarkar@juniper.net> <F3ADE4747C9E124B89F0ED2180CC814F4EF2FBA3@xmb-aln-x02.cisco.com> <D11232E4.20F4E%psarkar@juniper.net>
In-Reply-To: <D11232E4.20F4E%psarkar@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.24.181.81]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/-tzW-8ioLNtaXBL3SJazvIm3vnA>
Subject: Re: [Isis-wg] Comments on draft-ietf-isis-node-admin-tag-00
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2015 07:14:26 -0000
Pushpasis - (Finally spelled your name correctly - my apologies for my earlier errors) > -----Original Message----- > From: Pushpasis Sarkar [mailto:psarkar@juniper.net] > Sent: Tuesday, February 24, 2015 12:41 AM > To: Les Ginsberg (ginsberg); isis-wg@ietf.org; draft-ietf-isis-node-admin- > tag@tools.ietf.org > 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)" <ginsberg@cisco.com> > wrote: > > >Pushpassis - > > > >Thanx for the prompt reply. > >Please see my responses inline. > > > >> -----Original Message----- > >> From: Pushpasis Sarkar [mailto:psarkar@juniper.net] > >> Sent: Monday, February 23, 2015 11:18 PM > >> To: Les Ginsberg (ginsberg); isis-wg@ietf.org; > >>draft-ietf-isis-node-admin- > >> tag@tools.ietf.org > >> 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)" <ginsberg@cisco.com> > >> 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 > >> >Isis-wg@ietf.org > >> >https://www.ietf.org/mailman/listinfo/isis-wg > >
- [Isis-wg] Comments on draft-ietf-isis-node-admin-… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Comments on draft-ietf-isis-node-ad… Pushpasis Sarkar
- Re: [Isis-wg] Comments on draft-ietf-isis-node-ad… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Comments on draft-ietf-isis-node-ad… Pushpasis Sarkar
- Re: [Isis-wg] Comments on draft-ietf-isis-node-ad… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Comments on draft-ietf-isis-node-ad… Pushpasis Sarkar