Re: [OSPF] Review Request: New Version Notification for draft-hegde-ospf-node-admin-tag-00.txt

[Anton Smirnov <[e-mail]>]

    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" <[e-mail]> 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:[e-mail]]
>> 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: [e-mail] [mailto:[e-mail]] 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
>>>> | &quot;unreasonable&quot; 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 &quot;you won't ever need more than
>>>> |      32&quot; 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 &quot; Advertising per-node
>>>> |      administrative tags in OSPF&quot; 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: [e-mail] [mailto:internet-
>>>> |      [e-mail]]
>>>> |      | >>> 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
>>>> |      | >>> [e-mail]
>>>> |      | >>> https://www.ietf.org/mailman/listinfo/ospf
>>>> |      | >>
>>>> |      | >> _______________________________________________
>>>> |      | >> OSPF mailing list
>>>> |      | >> [e-mail]
>>>> |      | >> https://www.ietf.org/mailman/listinfo/ospf
>>>> |      | >>
>>>> |      | >>
>>>> |      | >
>>>> |      | >
>>>> |      |
>>>> |      |
>>>> |      |
>>>> |
>>>> |
>>>>
>>>> _______________________________________________
>>>> OSPF mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ospf
>>>
>>>
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ospf
>>
>>
>>
>>
>
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf
>