Hi Hannes,
> would be interesting to hear others' opinion on that.
My opinion is that in future defining a new well-known admin tag
value is by definition requires new IETF draft/RFC. But if new draft is
being written then it is cleaner to define data container which suits
the new feature best, be it new capability bit, new RI LSA TLV, new data
in another LSA or combination of above.
Problems with defining well-known tag values:
- It will be necessary to sacrifice a range of tag values for future
well-known tags
- It will be necessary to define behavior of implementation receiving
unknown tag
Benefits of defining well-known tags vs. defining in future new TLVs
for features as needed:
- Well, I can't think of any.
So my opinion is that there should be no well-known tags (neither in WG
nor internally to an implementation) and tag values should have meaning
in the context of policy of a particular network. Very much like there
are no well-known values for tags attached to external LSAs.
Anton
On 09/03/2014 04:45 PM, Hannes Gredler wrote:
hi dhruv,
On Wed, Sep 03, 2014 at 07:39:58PM +0530, Dhruv Dhody wrote:
| Hi Shraddha,
|
| Thanks for your reply, snipping to the open point...
|
| > Also, it should be stated
| > - if are more than one instance of this TLV in RI LSA are allowed.
| >
| > <Shraddha>More than one instance of the TLV can be added in same RI-LSA or
in a multiple instance as defined
| > In draft-acee-ospf-rfc4970bis-00.txt
| >
| Okay, text may be added to reflect this.
|
| > (2) It should be explicitly stated that - No IANA registry is required to
store the meaning or interpretation of.the tag values.
| >
| > <Shraddha> It's mentioned in the section 4.2 that no well known tag values
will be defined by this document.
| >
| Since in the mailing list there is a discussion about possibility of
| having well known tag value assigned by IANA. This document should
| clarify (based on WG consensus) if admin tags can be assigned by IANA
| in future documents or not. And if the answer is yes, a suitable range
| should be set to avoid conflict.
i have no concerns with that -
however peter seems in favor of using CAP Bits for well-known applications;
would be interesting to hear others' opinion on that.
/hannes
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf