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

["Alvaro Retana (aretana)" <[e-mail]>]

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.

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



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


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.




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