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 the follow-up and great discussion.


Pls see in-line.

I believe normative language is necessary in some cases (although it uses local policy) in order to get interoperable implementations among vendors.
Otherwise, implementations may claim document compliance and may not follow the suggestions in the document which will be expensive to discover for
the operators. 


Rgds
Shraddha

-----Original Message-----
From: Alvaro Retana (aretana) [mailto:[e-mail]] 
Sent: Thursday, October 15, 2015 5:03 PM
To: Shraddha Hegde <[e-mail]>; The IESG <[e-mail]>
Cc: Acee Lindem (acee) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)

On 10/15/15, 12:47 AM, "Shraddha Hegde" <[e-mail]> wrote:

Shraddha:


Hi!

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

That statement is a contradiction to me.  The bottom line is that if the "node-tags can be used to express and apply locally-defined network policies", and you're applying rules/regulations to them, then you're limiting the ability of the operator to describe the policy they may want.

<Shraddha> It does not limit the ability of the operator to deploy any of the use-cases requiring node-tags. Node tags are generic enough and multiple tags can be associated with
                      A node so it doesn't harm to introduce one more new tag into the domain when certain objectives cannot be achieved 
                    For ex: Operator wants to apply policy based on 
                      Tag A comes before tag B. Operator has to introduce two new tags C and D in the network and send C when A comes before B. Send D when B comes before A and on the receiver write rules for C and D.

If the tags are truly opaque..then the meaning is a local interpretation..and the use of that meaning in a policy (or any subsequent action, or not) is completely dependent on the interpretation.  In fact, anyone should be able to  communicate any "attribute associated with the node" using these tags, which should leave its use and interpretation up to the operator.


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

This is a good point to talk about.  I understand the potential problems with re-origination/refresh -- one of them being that the document doesn't specify anything related to the ordering of the tags in the TLV.  In fact, the only text that I could find related to origination of the information is this:

   When there is a change or removal of an administrative affiliation of
   a node, the node MUST re-originate the RI LSA with the latest set of
   node administrative tags.


..it says nothing about how the set is ordered: random, chronological, some type of numeric order, etc.  While it might have been nice (for some
applications) to have some type of predictability/persistence, not having an order is ok.  The text in 3.2 that reads:

<Shraddha> There is no need to specify the order. Implementations are free to pick any order since the receiver's actions are based on tag set and not on the order.
I believe, this is clarified in section 3.2 in details.


   The semantics of the tag order has no meaning.  That is, there is no
   implied meaning to the ordering of the tags that indicates a certain
   operation or set of operations that need to be performed based on the
   ordering.


...is also fine, and it (implicitly) covers the risk.

The piece of text I have a problem with is this:

   The administrative tag list within the TLV MUST be considered an unordered list. 

As you hinted above, because the draft doesn't provide guidance on ordering, an implementation can choose to do so without harming applications that assume nothing -- an operator may want to take advantage of this "ordering feature" (for whatever purpose), but this document would say "MUST be considered unordered"..limiting future policy implementations.

<Shraddha> As explained in the response above, I believe admin tags are generic enough to support a case when policy is to be based on order.

As with the discussion (in the other thread) about the potential definition of well-known values (change from "MUST NOT" to "not expected"), this is also a case where the use of normative (rfc2119) language makes no sense (at least to me).

<Shraddha> This is changed to "are not expected to" in the latest update.

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

3.2, right? 

<Shraddha> -08 version has section 3.2.1. Pls see attached.

To hopefully speed the process up, let me be specific about the other
rfc2119 occurrences in 3.2 that I have an issue with (in order of
appearance):

1. "Each tag MUST be treated as an independent identifier that MAY be used in policy to perform a policy action."

Ben already mentioned that the "MAY" seems more descriptive than normative..  I agree.

<Shraddha> ok. Changing "MAY" to descriptive "may".

However, there is still the "MUST".  All the tags are about a node, so they are in fact all related.  Also, because these are opaque tags, the operator can encode and interpret them anyway they want.  Again, the "MUST" makes no sense.
<Shraddha>changing it to must.

2. "Tags carried by the administrative tag TLV SHOULD be used to indicate independent characteristics of a node."

With this statement you're trying to limit what the operator can use the tags for.  Operationally this sentence is easy to ignore because there's no definition of what an "independent characteristic" is..so the use of "SHOULD" makes no sense.
<Shraddha>Changing to should


3. "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)."

Already discussed above.


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

Why not?

Given that all the tags are subject to local interpretation, it is very possible than an operator could use the same value to mean different things at the different scopes.

[I know that we have 32 bits...but it is obviously easier for anyone to look at the TLV and remember what the value "5" means than to have to remember ranges between 34322-34332..or other numbers for the different scopes.]

<Shraddha> That's the exact point this statement is trying to make. There is no need to associate meaning based on flooding scope. If such a feature is needed operator can very well use different tags. I believe such rules help the vendors to define and implement local policies and operators to plan and work in a framework. Otherwise the policy rule space becomes huge and not all vendors will implement all of them.

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

I don't have a real problem with this one..but (going back to the same
point) if the tags are subject to local interpretation and use, then advertising anything is ok..so I think that the "MAY" is really descriptive, and shouldn't be normative.


6. "Being part of the RI LSA, the per-node administrative tag TLV must be reasonably small and stable...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."

Again, why not?  I know the point is stability.  Just as an example, the application described in Section 4.4. (Mobile back-haul network service
deployment) says that the tags could represent a ring..which will obviously change if the topology changes.
<Shraddha> Ring nodes are assigned tag values based on configuration and if one of the links breaks and the ring is no more a closed ring, the admin tag associated with the ring
                       Nodes does not change. It changes only by changing the configuration on that node.
                     

In this case it is obviously ok to describe the potential impact of too many changes..but trying to control it with the "MUST NOT" is just something that can't be enforced.

<Shraddha> I believe normative language is necessary to enforce otherwise implementations will be free to say compliance to this document and not follow any of these suggestions. Many of the inter-op issues would be discovered only via testing which is expensive. 

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

Not a problem with this one either..but you're probably missing a "per flooding scope" somewhere.
<Shraddha > All RI LSA instances includes all flooding scopes.


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

The computation/processing is locally dependent and may not require repeating even if the values changed -- much less if the set changed but
not the values.   The action should be to at least check if the change
impact the application, but I think the "MUST" is out of place.

<Shraddha> Changing it as below.
" When an RI LSA is received that changes the set of tags applicable to any originating node, a receiving node which has features depending on node administrative tags MUST repeat any computation or processing that is based on those administrative tags


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

Yes.

Thanks!

Alvaro.