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
