On Oct 21, 2013, at 9:51 AM, Hannes Gredler wrote: On Mon, Oct 21, 2013 at 01:32:54PM +0000, Acee Lindem wrote: | Hannes, | | On Oct 21, 2013, at 9:26 AM, Hannes Gredler wrote: | | > acee, | > | > why should we give an upper boundary on things which | > - might be subject to change and | > - which have a historic track record of being underestimated. | | You don't have to - just request a separate OSPFv2 opaque LSA and IPv6 OSPFv3 LSA from IANA. | Another alternative would be to extend the RI LSA to be multi-instance and relegate the variable length tags to an instance other than instance 0.
again the question why i do have to ? i can perfectly fit in single-digit as well as a few dozens of colors in a single RI LSA - what is your concern - except that we may use inappropriate large space for TE ? any reasonable implementation SHOULD restrict the node color set, such that overwhelming the 64K of RI LSPs is not going to happen. We don't want a standard that leaves room for "unreasonable" implementations ;^). I think the policy in RFC 4970 is clear. Here is an excerpt: 3. Router Information LSA Opaque Usage and Applicability The purpose of the Router Information (RI) LSA is to advertise information relating to the aggregate OSPF router. Normally, this should be confined to TLVs with a single value or very few values. It is not meant to be a generic container to carry any and all information. The intent is to both limit the size of the RI LSA to the point where an OSPF router will always be able to contain the TLVs in a single LSA and to keep the task of determining what has changed between LSA instances reasonably simple. Hence, discretion and sound engineering judgment will need to be applied when deciding whether newly proposed TLV(s) in support of a new application are advertised in the RI LSA or warrant the creation of an application specific LSA. Anyway, this hasn't even been presented or accepted as a WG document. Thanks, Acee | > the 'per-link' admin-groups serve as a good example here: | > initially conceived as "you won't ever need more than 32" we have | > now arrived at a variable length (unbounded) extension. | > | > http://tools.ietf.org/html/draft-osborne-mpls-extended-admin-groups-00 | > | > for a humorous take to it, have a look at | > http://tools.ietf.org/html/rfc1925 | > rule (9) and (10) | > | > /hannes | > | > On Oct 21, 2013, at 3:12 PM, Acee Lindem wrote: | > | >> Hi Shraddha, | >> Since the size of the tag data is unbounded, could you either put it in a separate OSPFv2 opaque LSA and OSPFv3 LSA or limit the size to some maximum number of tags, e.g., 16? | >> Thanks, | >> Acee | >> On Oct 21, 2013, at 7:05 AM, Shraddha Hegde wrote: | >> | >>> Hi All, | >>> | >>> We have posted a draft on " Advertising per-node administrative tags in OSPF" and would like to hear your views on it. Please feel free to raise any suggestion/comment on the content. | >>> | >>> Rgds | >>> Shraddha | >>> | >>> -----Original Message----- | >>> From: [email protected]<mailto:[email protected]> [mailto:[email protected]] | >>> Sent: Monday, October 21, 2013 4:24 PM | >>> To: Harish Raghuveer; Shraddha Hegde; British Telecom; Hannes Gredler; Rob Shakir | >>> Subject: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt | >>> | >>> | >>> A new version of I-D, draft-hegde-ospf-node-admin-tag-00.txt | >>> has been successfully submitted by Shraddha Hegde and posted to the IETF repository. | >>> | >>> Filename: draft-hegde-ospf-node-admin-tag | >>> Revision: 00 | >>> Title: Advertising per-node administrative tags in OSPF | >>> Creation date: 2013-10-21 | >>> Group: Individual Submission | >>> Number of pages: 6 | >>> URL: http://www.ietf.org/internet-drafts/draft-hegde-ospf-node-admin-tag-00.txt | >>> Status: http://datatracker.ietf.org/doc/draft-hegde-ospf-node-admin-tag | >>> Htmlized: http://tools.ietf.org/html/draft-hegde-ospf-node-admin-tag-00 | >>> | >>> | >>> Abstract: | >>> This document describes an extension to OSPF protocol [RFC2328] to | >>> add an optional operational capability, that allows tagging and | >>> grouping of the nodes in an OSPF domain. This allows | >>> simplification,ease of management and control over route and path | >>> selection based on configured policies. | >>> | >>> This document describes the protocol extensions to disseminate per- | >>> node admin-tags to the OSPFv2 and OSPFv3 protocols. | >>> | >>> | >>> | >>> | >>> | >>> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>. | >>> | >>> The IETF Secretariat | >>> | >>> | >>> | >>> _______________________________________________ | >>> OSPF mailing list | >>> [email protected]<mailto:[email protected]> | >>> https://www.ietf.org/mailman/listinfo/ospf | >> | >> _______________________________________________ | >> OSPF mailing list | >> [email protected]<mailto:[email protected]> | >> https://www.ietf.org/mailman/listinfo/ospf | >> | >> | > | > | | |
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
