Re: [OSPF] Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)

[Shraddha Hegde <[e-mail]>]

Alvaro,

Thanks for reviewing the document.
As indicated in other thread, we need rules/regulation on how to interpret the tags and how to use them to get interoperable implementations.

> Although , the actual values of node admin tags do not need to be standardized and is left to the operator's discretion to allocate values and assign meanings to it, It's necessary to layout certain rules/regulations and guidelines on how the tags can be used and how
they cannot be used. That will help in getting interoperable implementations from vendors and avoid surprises in the field.
For ex:  We have a statement administrative tag order has no meaning. If this document does not specify such a statement, there I every possibility some implementation will have policies that will look at the order in which the tags are encoded. Some other implementation which does not care about the order of the tag might keep changing it at every LSA refresh so it's hard to get them to interoperate.

Added below text in section 3.2.1
" This section describes general rules/ regulations 
and guidelines for using and interpreting an administrative tag which will
 facilitate interoperable implementations by vendors."



Related to the DISCUSS:  Section 3.2 says that the "meaning of the Node administrative tags is generally opaque to OSPF", are there cases where the meaning is not opaque?  Even if the application is well known there is no indication that the tag is not opaque.  Yes, this is a nit with the word "generally".
<Shraddha> There are no known cases where OSPF needs to look into the tags but I do not rule out the possibility in future where OSPF uses tags for some of its functionality

All the references related to rfc4970 should be changed to draft-ietf-ospf-rfc4970bis.
<Shraddha> Is it OK to reference drafts as Normative refrence?

Rgds
Shraddha

-----Original Message-----
From: Alvaro Retana [mailto:[e-mail]] 
Sent: Tuesday, October 13, 2015 7:51 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-ospf-node-admin-tag-07: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-node-admin-tag/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 3.2. (Elements of procedure) says that the "interpretation of tag values is specific to the administrative domain of a particular network operator", which makes them opaque and obviously locally significant.  I then have an issue with the following text, which tries to (using rfc2119
keywords) specify how to interpret the tags, which doesn't make sense to me given the text above:

   Each tag MUST be treated as an independent identifier that MAY be
   used in policy to perform a policy action.  Tags carried by the
   administrative tag TLV SHOULD be used to indicate independent
   characteristics of a node.  The administrative tag list within the
   TLV MUST be considered an unordered list.  Whilst policies may be
   implemented based on the presence of multiple tags (e.g., if tag A
   AND tag B are present), they MUST NOT be reliant upon the order of
   the tags (i.e., all policies should be considered commutative
   operations, such that tag A preceding or following tag B does not
   change their outcome).

   To avoid incomplete or inconsistent interpretations of the per-node
   administrative tags the same tag value MUST NOT be advertised by a
   router in RI LSAs of different scopes.  The same tag MAY be
   advertised in multiple RI LSAs of the same scope, for example, OSPF
   Area Border Router (ABR) may advertise the same tag in area-scope RI
   LSAs in multiple areas connected to the ABR.
. . .
   Being part of the RI LSA, the per-node administrative tag TLV must be
   reasonably small and stable.  In particular, but not limited to,
   implementations supporting the per-node administrative tags MUST NOT
   tie advertised tags to changes in the network topology (both within
   and outside the OSPF domain) or reachability of routes.
. . .
   instances of the RI LSA.  The node administrative tags associated
   with a node that originates tags for the purpose of any computation
   or processing at a receiving node SHOULD be a superset of node
   administrative tags from all the TLVs in all the received RI LSA
   instances originated by that node.When an RI LSA is received that
   changes the set of tags applicable to any originating node, a
   receiving node MUST repeat any computation or processing that is
   based on those administrative tags.

If the tags are opaque, I don't think that anything can be mandated as to how they are interpreted or what they're used for.  That is the point I want to talk about with this DISCUSS.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Related to the DISCUSS:  Section 3.2 says that the "meaning of the Node administrative tags is generally opaque to OSPF", are there cases where the meaning is not opaque?  Even if the application is well known there is no indication that the tag is not opaque.  Yes, this is a nit with the word "generally".

All the references related to rfc4970 should be changed to draft-ietf-ospf-rfc4970bis.