I don't disagree that the typical use case is a single tag with the likelihood of mult-tag use cases diminishing exponentially as the number of tags increases. My point is that unbounded TLVs MUST NOT be included in the OSPF RI LSA. What part of that is hard to understand? I think that 16 is a reasonable maximum and that beyond 16 would imply encoding ulterior information that should have its own TLV or LSA anyway. Acee
On Oct 22, 2013, at 3:48 PM, Anton Smirnov wrote: > Hi Acee, > it looks to me that the most probable deployment will use 1 tag. Router > advertising 100 tags already sounds unreasonable. > Defining new LSID to originate LSA with (typically) only 4 bytes of useful > information is not optimal. Choice of RI LSA to advertise some small data is > reasonable. > RI LSA is far from getting too big. If there is a concern of RI LSA > overfilling then we can extend range of opaque IDs - but is it really > necessary at this point? > > Anton > > > On 10/21/2013 09:55 PM, Acee Lindem wrote: >> 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 >> _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
