On Wed, Oct 23, 2013 at 10:47:05PM +0000, Acee Lindem wrote: | Hannes, | | On 10/23/13 12:27 AM, "Hannes Gredler" <[email protected]> wrote: | | >acee, | > | >i think that 16 is an unreasonable max threshold as we have proof point | >(e.g. link-colors) | >that even 32 colors are not enough - so support for 64 colors is the bare | >minimum | >that SPs are looking for. | >i fail to see the threat of overfilling the RI, with worst case 400 bytes | >(100 colors). | >furthermore it is an upper boundary number ... | | Will this limit be in the next revision of the draft?
yes; | >On Tue, Oct 22, 2013 at 08:05:09PM +0000, Acee Lindem wrote: | >| 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 | >| | >| | > | | | _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
