On Mon, Oct 21, 2013 at 02:10:04PM +0000, Acee Lindem wrote: | | 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:
oh boy - i wish i could let the non-sense disappear just with good standard docs ;-) - but i hear you - so all you're asking for is an upper boundary ? - is 128 low enough to not scare you and be compliant to the below paragraph. | 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. which is not a reason why we should not discuss how to iron out the bumpy parts now. thanks ! /hannes | | > 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:internet- | [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. | | >>> | | >>> The IETF Secretariat | | >>> | | >>> | | >>> | | >>> _______________________________________________ | | >>> OSPF mailing list | | >>> [email protected] | | >>> https://www.ietf.org/mailman/listinfo/ospf | | >> | | >> _______________________________________________ | | >> OSPF mailing list | | >> [email protected] | | >> https://www.ietf.org/mailman/listinfo/ospf | | >> | | >> | | > | | > | | | | | | | | _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
