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

From: "Alvaro Retana" <[email-masked]>
Date: Tue, 13 Oct 2015 07:21:27 -0700

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.

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 15 Oct 2015 04:47:31 +0000

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:[email-masked]] 
Sent: Tuesday, October 13, 2015 7:51 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)

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

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:

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.

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.

---

From: Anton Smirnov <[email-masked]>
Date: Thu, 15 Oct 2015 11:50:14 +0200

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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 15 Oct 2015 11:33:04 +0000

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

Shraddha:

Hi!

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

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:

   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.

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

> facilitate interoperable implementations by vendors."

3.2, right? 

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.

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.

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.

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

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.

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.

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.

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> Is it OK to reference drafts as Normative refrence?

Yes.

Thanks!

Alvaro.

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 16 Oct 2015 09:20:16 +0000

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:[email-masked]] 
Sent: Thursday, October 15, 2015 5:03 PM
To: Shraddha Hegde <[email-masked]>; The IESG <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)

Shraddha:

Hi!

>interpret the tags and how to use them to get interoperable 

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.

>>standardized and is left to the operator's discretion to allocate 
>>values and assign meanings to it, It's necessary to layout certain 
>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:

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

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

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

. . .

Yes.

Thanks!

Alvaro.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 16 Oct 2015 11:50:11 +0000

On 10/16/15, 5:20 AM, "Shraddha Hegde" <[email-masked]> wrote:

Shraddha:

Hi!

I'm just leaving in the still outstanding issues.

Thanks!

Alvaro.

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

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

>1. "Each tag MUST be treated as an independent identifier that MAY be
>used in policy to perform a policy action."
>
><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.

. . .  
>administrative tags MUST NOT tie advertised tags to changes in the
>network topology (both within and outside the OSPF domain) or
>reachability of routes."
>
><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
><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!

><Shraddha > All RI LSA instances includes all flooding scopes.

This goes back to our conversation about scopes above.

---

From: Rob Shakir <[email-masked]>
Date: Fri, 16 Oct 2015 07:03:13 -0600

Alvaro,

Picking up on one particular point:

> can't really be enforced.

I think the opposite is true. If we have no guarantee of order, then vendor C can sort tags numerically ascending, and vendor D can sort tags numerically descending. Based on this, one could have a policy that matches (1 BEFORE 2) which is triggered only when advertisements are received from a vendor C box, and not a vendor D one.

Given that operationally, we do not care whether it was a vendor C or D box [0], then this actually will mean that we have different logic applied based on the implementation choice. If we are to allow tags to be combined non-commutitvately, then we need to have logic that says that the ordering matters (and defined how it is done). If we do not, then we need strong guidance to implementors (of the specification AND operators) that they cannot rely on order.

A murky middle ground is that we end up with inconsistent treatment of tags across different implementations, which creates pain for network operators trying to use them, or introducing a new implementation into their network (all policies that previously worked based on order, suddenly don’t based on this new implementation having different logic).

r.

[0]: And if we did, we could just create a new tag that specifies the vendor, like we could have one that specifies the role.

---

From: <[email-masked]>
Date: Fri, 16 Oct 2015 13:32:44 +0000

Alvaro, Shraddha,

Please see inline [Bruno]

> Sent: Friday, October 16, 2015 1:50 PM
> 

[Bruno] Good. [REF1]

> >   The administrative tag list within the TLV MUST be considered an

[Bruno]
Personally, I see what Shraddha means, and I'm fine with the text.
But If you have a problem with this sentence, I'd say we could remove it as, for me, [REF1] say the same thing and would be enough.

> to his/her advantage regardless of what this document says. 

[Bruno] I don't think so because 2 different implementations are involved:
- the one (a) setting the tag (and advertising it in OSPF)
- the one (b) receiving it in OSPF and using the it in the policy

The point is that node "b" cannot assume that node "a" advertised the tags in OSPF in the same order that the operator has configured.

> IOW, "MUST be

[Bruno] Again IMO an option is to remove that sentence. Or may be :s/MUST be considered/is" which remove the "enforcibility" issue.
 The more important one is the next "Whilst policies may be implemented
   based on the presence of multiple tags [...], they MUST NOT be reliant upon the order of the tags [..]"
with possibly :s/order of the tags/order of the received tags"

-- Bruno 

> This goes back to our conversation about scopes above.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
Thank you.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 16 Oct 2015 14:22:53 +0000

On 10/16/15, 9:03 AM, "Rob Shakir" <[email-masked]> wrote:

Rob:

Hi!

>Picking up on one particular point:

Are you advocating for the draft to specify an ordering scheme, or at just
leaving it at "MUST be considered unordered"?  Your text below says one or
the other, just wondering about preference.

Thanks!

Alvaro.

>I think the opposite is true. If we have no guarantee of order, then
>vendor C can sort tags numerically ascending, and vendor D can sort tags
>numerically descending. Based on this, one could have a policy that
>matches (1 BEFORE 2) which is triggered only when advertisements are
>received from a vendor C box, and not a vendor D one.
>
>Given that operationally, we do not care whether it was a vendor C or D
>box [0], then this actually will mean that we have different logic
>applied based on the implementation choice. If we are to allow tags to be
>combined non-commutitvately, then we need to have logic that says that
>the ordering matters (and defined how it is done). If we do not, then we
>need strong guidance to implementors (of the specification AND operators)
>that they cannot rely on order.
>
>A murky middle ground is that we end up with inconsistent treatment of
>tags across different implementations, which creates pain for network
>operators trying to use them, or introducing a new implementation into
>their network (all policies that previously worked based on order,
>suddenly don¹t based on this new implementation having different logic).
>
>r.
>
>[0]: And if we did, we could just create a new tag that specifies the
>vendor, like we could have one that specifies the role.
>
>
>

---

From: Rob Shakir <[email-masked]>
Date: Fri, 16 Oct 2015 08:26:35 -0600

Hi Alvaro,

> the other, just wondering about preference.

I prefer leaving "MUST be considered unordered” in the document, I currently cannot envisage any use cases that would need to consider ordering (in general, I think this can be dealt with by creating a new tag).

Kind regards,
r.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 16 Oct 2015 14:31:59 +0000

Hi Rob, Alvaro, 

This is a great discussion! It is unfortunate that it did not occur
earlier on the OSPF WG list. I’d like to determine how we can solicit more
discussion earlier in the process. See one inline below…

On 10/16/15, 10:26 AM, "Rob Shakir" <[email-masked]> wrote:

>I prefer leaving "MUST be considered unordered” in the document, I
>currently cannot envisage any use cases that would need to consider
>ordering (in general, I think this can be dealt with by creating a new
>tag).

In thinking about this and case of nondeterministic behavior with varying
implementation ordering, I think we should keep it as unordered and
discourage the creation of policies that are sensitive to ordering.

Thanks,
Acee

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 16 Oct 2015 14:39:10 +0000

On 10/16/15, 10:31 AM, "Acee Lindem (acee)" <[email-masked]> wrote:

Hi!

>earlier on the OSPF WG list.

Couldn't agree more! :-)

. . .
>>I prefer leaving "MUST be considered unordered² in the document, I

Ok..that's fine with me.

Thanks!

Alvaro.

---

From: Anil Kumar S N <[email-masked]>
Date: Fri, 16 Oct 2015 20:53:13 +0530

Hi!

Even if tags are ordered we are not going to achieve much; when lsa is received on refresh interval, all received tags must be verified against tags available in lsdb. Worst case the last tag in the ordered list is missing. So Ordering is not going to help m
uch.

I do feel tags can be unordered.

With regards 
Anil S N

Sent from my Cyanogen phone

On Oct 16, 2015 8:09 PM, "Alvaro Retana (aretana)" <[email-masked]> wrote:
> _______________________________________________ 
> OSPF mailing list 
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ospf

---

From: <[email-masked]>
Date: Fri, 16 Oct 2015 15:26:22 +0000

Acee,

> From: Acee Lindem (acee) [mailto:[email-masked]] > Sent: Friday, October 16, 2015 4:32 PM
> 
> Hi Rob, Alvaro,
> 

Looks good to me.
This is also in sync with IS-IS prefix admin tag (RFC 5130), which BTW has a section about "Ordering of tags" http://tools.ietf.org/html/rfc5130#section-4

OSPF node tag says:

IS-IS prefix tags says:
The semantics of the tag order are implementation-dependent.  That
   is, there is no implied meaning to the ordering of the tags that
   indicates a certain operation or set of operations need be performed
   based on the order of the tags.

i.e. both are quite identical. An option would be to make then identical.

Thanks,
--Bruno 

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 16 Oct 2015 15:40:04 +0000

IESG removed - only the OSPF faithful retained…

On 10/16/15, 11:23 AM, "Anil Kumar S N" <[email-masked]> wrote:

>Hi!
>
>Even if tags are ordered we are not going to achieve much; when lsa is
>received on refresh interval, all received tags must be verified against
>tags available in lsdb. Worst case the last tag in the ordered list is
>missing. So Ordering is not going to help m
>uch.

I don’t see this is a problem since the refresh interval is 1/2 the MaxAge
interval. 

>I do feel tags can be unordered.

We agree here. 

Thanks,
Acee

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 19 Oct 2015 03:53:41 +0000

Alvaro,

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

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

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

   ... If a node

[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. :-(

   ... If a node

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

<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:[email-masked]] 
Sent: Friday, October 16, 2015 5:20 PM
To: Shraddha Hegde <[email-masked]>; The IESG <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)

Shraddha:

Hi!

Thanks!

Alvaro.

. . .
>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.
>applications) to have some type of predictability/persistence, not 
>having an order is ok.  The text in 3.2 that reads:
>
>free to pick any order since the receiver's actions are based on tag 
>set and not on the order.
>document would say "MUST be considered unordered"..limiting future 
>policy implementations.
>

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

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.

>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.
>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.
>
>
>router in RI LSAs of different scopes."
>
>Why not?
>
><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. :-(

   ... If a node

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

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.

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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 19 Oct 2015 12:39:17 +0000

On 10/18/15, 11:53 PM, "Shraddha Hegde" <[email-masked]> 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. :-(
>
>[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.]
>
>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. :-(
>
>[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.]
>
>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)?
>

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.

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 20 Oct 2015 03:56:45 +0000

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:[email-masked]] 
Sent: Monday, October 19, 2015 6:09 PM
To: Shraddha Hegde <[email-masked]>; The IESG <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)

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.

. . .
><Shraddha> Tags are associated with nodes which advertise them. There 
>is no need to associate tags with scopes for any policy action. If an 
><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..

>breaking more than one policy -- and depending on the expected action 
>the disruption may be significant
>
>---
>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.
>
>reasonably small and stable."
>

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

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 20 Oct 2015 04:04:07 +0000

Resending the mail as the previous mail content got removed.

Alvaro,

  Thanks for the discussion.
I am sorry that we are not able to reach conclusion quickly.

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

Rgds
Shraddha

-----Original Message-----
From: Shraddha Hegde [mailto:[email-masked]] 
Sent: Tuesday, October 20, 2015 9:27 AM
To: Alvaro Retana (aretana) <[email-masked]>; The IESG <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)

Alvaro,