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

[Shraddha Hegde <[e-mail]>]

Alvaro,

We closed on a few points but few more are still open.

<.... snipping to open points...>

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

The text in -08 still says:

   administrative tags.  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).

<Shraddha> -08 version is updated as below for the well known values. Is your comment about well known values or tag order?

"New OSPF
extensions are not expected to require use of per-node administrative
tags or define well-known tag values"
--------------------------------------------------------------------------------------------------

>From section 2 (updated text): "The choice of what scope at which to flood the group tags is a matter of local policy."  And form the new 3.2.1: "The meaning of a per-node administrative tag is defined by the network local policy and is controlled via the configuration."  Apparently not. :-(

BTW, I noticed that in -08 you also added:

   ... If a node
   administrative tag is received in different scopes, the conflicting
   tag SHOULD not be used and this situation SHOULD be logged as an
   error including the tag with conflicting scopes and the
   originator(s).


[I know this was put in to answer the SecDir review related to what should be done if the same value was received with different flooding scopes.]

Which is the "conflicting tag"?  Does it mean that for all scopes that specific value is not to be used? 
>From section 2 (updated text): "The choice of what scope at which to flood the group tags is a matter of local policy."  And form the new 3.2.1: "The meaning of a per-node administrative tag is defined by the network local policy and is controlled via the configuration."  Apparently not. :-(

BTW, I noticed that in -08 you also added:

   ... If a node
   administrative tag is received in different scopes, the conflicting
   tag SHOULD not be used and this situation SHOULD be logged as an
   error including the tag with conflicting scopes and the
   originator(s).


[I know this was put in to answer the SecDir review related to what should be done if the same value was received with different flooding scopes.]

Which is the "conflicting tag"?  Does it mean that for all scopes that specific value is not to be used?  

<Shraddha> Tags are associated with nodes which advertise them. There is no need to associate tags with scopes for any policy action. If an operator has any such usecase new tags can be associated with such a use-case.


If so, what about policies in which the operator is looking for two (or maybe more) tags to be present to take an action?  

<Shraddha> The issue being described here is about same tag appearing in different scopes on a non-ABR. It's perfectly valid to associate multiple tags with a node.
 
If all the tags for all scopes are declared conflicting then you may be breaking more than one policy -- and depending on the expected action the disruption may be significant

-------------------------------------------------------------------------------------------------------------------------------------------------

The real problem is not whether the tags are configured to change when the topology does, the real problem is for the tags to change a lot and become unstable.  The only reason the tags will become unstable due to topology changes is if the topology is unstable itself.  However, there may be other reasons for tag instability.  For example, what it someone decides they want a tag to reflect available bandwidth (or any other constantly changing parameter)?

My point here is that it is ok for you to put in the suggestion about stability.  It would be even better if you talked about rate limiting the origination of the TLVs with updated/changed tags (which is the stability you seem to want to enforce); you can even make that normative. However, you're trying (again) to limit potential applications that may not result in the stability problem that you're trying to prevent..and at the same time leaving the door open to other potential stability issues.

In short, if stability is your concern, then address it directly!

<Shraddha> The paragraph begins with below statement.

"Being part of the RI LSA, the per-node administrative tag
TLV must be reasonably small and stable."

I think that should address the stability problems.


---------------------------------------------------------------------------------------------------------------------------------------


Rgds
Shraddha

-----Original Message-----
From: Alvaro Retana (aretana) [mailto:[e-mail]] 
Sent: Friday, October 16, 2015 5:20 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/16/15, 5:20 AM, "Shraddha Hegde" <[e-mail]> wrote:

Shraddha:

Hi!

I'm just leaving in the still outstanding issues.

Thanks!

Alvaro.




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

At the expense of complicating the policy definition, configuration, management, etc..  Contrary to what you wrote in the Abstract: "This allows simplification, ease of management and control.."


I think we agree that order doesn't have to be specified.

What we're not in agreement on is the fact that if an implementation chooses to implement an order (as you said above "Implementations are free to pick any order"), and provides policy constructs to act on the order (implementation-specific detail), then the operator can use those features to his/her advantage regardless of what this document says.  IOW, "MUST be considered an unordered list" doesn't reflect a reasonable expectation and can't really be enforced.




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

The text in -08 still says:

   administrative tags.  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).




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

Again, you're claiming an opaque space subject to local interpretation, but then constraining how to use them..and not meeting the "simplification, ease of management and control" claim.

>From section 2 (updated text): "The choice of what scope at which to flood the group tags is a matter of local policy."  And form the new 3.2.1: "The meaning of a per-node administrative tag is defined by the network local policy and is controlled via the configuration."  Apparently not. :-(

BTW, I noticed that in -08 you also added:

   ... If a node
   administrative tag is received in different scopes, the conflicting
   tag SHOULD not be used and this situation SHOULD be logged as an
   error including the tag with conflicting scopes and the
   originator(s).


[I know this was put in to answer the SecDir review related to what should be done if the same value was received with different flooding scopes.]

Which is the "conflicting tag"?  Does it mean that for all scopes that specific value is not to be used?  If so, what about policies in which the operator is looking for two (or maybe more) tags to be present to take an action?  If all the tags for all scopes are declared conflicting then you may be breaking more than one policy -- and depending on the expected action the disruption may be significant.

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

Suggestions shouldn't be normative.

The real problem is not whether the tags are configured to change when the topology does, the real problem is for the tags to change a lot and become unstable.  The only reason the tags will become unstable due to topology changes is if the topology is unstable itself.  However, there may be other reasons for tag instability.  For example, what it someone decides they want a tag to reflect available bandwidth (or any other constantly changing parameter)?

My point here is that it is ok for you to put in the suggestion about stability.  It would be even better if you talked about rate limiting the origination of the TLVs with updated/changed tags (which is the stability you seem to want to enforce); you can even make that normative. However, you're trying (again) to limit potential applications that may not result in the stability problem that you're trying to prevent..and at the same time leaving the door open to other potential stability issues.

In short, if stability is your concern, then address it directly!


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

This goes back to our conversation about scopes above.