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

[Shraddha Hegde <[e-mail]>]

Alvaro,

I'll try to clarify based on my understanding of your comments.

If the same tag value is flooded with multiple scopes, then it will be declared conflicting (for all scopes).
<Shraddha>Yes.
.
  If there are policies that are dependent on those tags then they won't be applied
<Shraddha> The conflicting tag won't be considered. Lets say a node had advertised 10 tags. Lets say 10th tag is conflicting and is arriving
                       In different scopes. Only 9 tags will be sent to policy. 
                       If you saying just because one tag is conflicting the whole set of tags for that node is ignored, then that's not the case.

 -- including policies that rely on more than one tag being present (including the one declared conflicting, of course).  The point of that question was to point out that by invalidating a tag the policies that will be applied won't always depend just on the remaining tags..

<Shraddha> Again I don't understand your statement. Why can't the policy be applied on only 9 tags in above example. If the policy fails because of the absence of 10th flag then it's an issue with the advertising router being nod-ABR and having advertised different tags in different scopes.

Do you mean to say we should not restrict same tag being advertised in different scopes?
I am not sure If we can change that at this stage of the document since WG as well as others who reviewed the document so far are OK with that restriction being there.

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

Again, the point was that by not allowing the tags to be tied to changes in topology you are not necessarily doing much to limit instability.
True, the topology may become unstable and the tags advertised will mirror that -- the root cause being the topology instability.  But I think there can be valid applications that could follow topology changes that won't mirror instability (if the network itself is stable).  Also, you focused on one thing (topology instability), leaving other reasons for tag instability without mention -- this last part was why I suggested that you might want to focus on the problem you really want to resolve and maybe talk about rate limiting.

<Shraddha> Personally, I do not think we need to talk about rate limiting of node-admin tags since we already have rate limiting for the LSA origination.
Would like to hear others opinion on this.

Rgds
Shraddha

-----Original Message-----
From: Alvaro Retana (aretana) [mailto:[e-mail]] 
Sent: Monday, October 19, 2015 6:09 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/18/15, 11:53 PM, "Shraddha Hegde" <[e-mail]> wrote:

Shraddha:


Hi!

I'm either completely missing the point, not explaining myself correctly, or both.  We seem to be going around in circles.. :-(

I'm going to clear the DISCUSS.. I trust the responsible AD and hope that the WG had the appropriate discussions.  There are still some comments below.

Alvaro.

. . .
>
>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 the same tag value is flooded with multiple scopes, then it will be declared conflicting (for all scopes).  If there are policies that are dependent on those tags then they won't be applied -- including policies that rely on more than one tag being present (including the one declared conflicting, of course).  The point of that question was to point out that by invalidating a tag the policies that will be applied won't always depend just on the remaining tags..

Your answer is: the operator can change their policies..

We're now going in circles..


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

It should.  This is the text I quoted originally:

"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, the point was that by not allowing the tags to be tied to changes in topology you are not necessarily doing much to limit instability.
True, the topology may become unstable and the tags advertised will mirror that -- the root cause being the topology instability.  But I think there can be valid applications that could follow topology changes that won't mirror instability (if the network itself is stable).  Also, you focused on one thing (topology instability), leaving other reasons for tag instability without mention -- this last part was why I suggested that you might want to focus on the problem you really want to resolve and maybe talk about rate limiting.