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

[Anton Smirnov <[e-mail]>]

    Hi Alvaro, Shraddha,

 > 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

    Tags may or may not be opaque to OSPF. This depends both on the use 
case and device implementation & configuration.
    If we consider use case of MPLS TE placement from the document then 
tags are opaque to OSPF (both for originators and routers running 
computation). MPLS TE is the consumer.
    OTOH if we consider rLFA use case then tags are opaque for routers 
originating them but they are NOT opaque to OSPF on routers running rLFA 
computation. In this case OSPF is configured with policy to check tags 
advertised by a node considered as candidate rLFA terminating point and 
accept or reject candidate based on tags advertised by that node and 
local policy.
    So IMO there do exist use cases where OSPF is consumer of tags and 
at least couple of example use cases in the document fall into this 
category.

    Note that above I assume rLFA functionality to be part of OSPF. One 
may lay argument that rLFA is not an OSPF but is as external to OSPF as 
MPLS TE.
    To cover possible use cases and differences in implementations I 
prefer we do not assume that users of tags are always outside of OSPF.

Anton


On 10/15/2015 06:47 AM, Shraddha Hegde wrote:
> 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.
>
>