I think we are in a circular argument here and I'm not discuss this independently with each of the authors. Either you have to limit the number of tags, define a new LSA, or do the work to make RI LSA multi-instance. All are viable alternatives with differing pros and cons - including it in the existing RI LSA is not a viable alternative. Remember to request a session if you plan to present it at IETF 88. Thanks, Acee
On 10/21/13 12:49 PM, "Shraddha Hegde" <[email protected]> wrote: >The "Applicability" section of the draft talks about why RI LSA is chosen >as the node-tag TLV carrier instead of TE LSA. > >The point I am trying make here is, if the link-color is carried in a TLV, >Node color could also be carried in TLV and we don't need a new LSA for >that. > >Rgds >Shraddha > >-----Original Message----- >From: Acee Lindem [mailto:[email protected]] >Sent: Tuesday, October 22, 2013 12:53 AM >To: Shraddha Hegde >Cc: Acee Lindem; Hannes Gredler; OSPF List; Rob Shakir; Harish Raghuveer >Subject: Re: [OSPF] Review Request: New Version Notification for >draft-hegde-ospf-node-admin-tag-00.txt > > >On Oct 21, 2013, at 3:12 PM, Shraddha Hegde wrote: > >> <Acee> Actually, I think separate LSAs is a better alternative. >> >> <Shraddha> Node-tag is a just another property of the node. OSPFv2/v3 >> have achieved the desired functionality using numerous link/node >>properties using TLVs in TE-LSA so I don't see an absolute necessity of >>going with a new LSA. > >Shraddha - If you think the Router-Information LSA is the same as the TE >LSA you have not read RFC 4970. > >Acee > > >> >> Rgds >> Shraddha >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf >> Of Acee Lindem >> Sent: Monday, October 21, 2013 8:55 PM >> To: Hannes Gredler >> Cc: OSPF List; Rob Shakir; Harish Raghuveer >> Subject: Re: [OSPF] Review Request: New Version Notification for >> draft-hegde-ospf-node-admin-tag-00.txt >> >> >> On Oct 21, 2013, at 11:08 AM, Hannes Gredler wrote: >> >>> 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. >> >> Actually, I think separate LSAs is a better alternative. >> >> >> >>> >>> | 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. >> >> Right. >> >> Thanks, >> Acee >> >> >>> >>> 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 >> >> _______________________________________________ >> 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
