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

[Shraddha Hegde <[e-mail]>]

<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. 

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