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

[<[e-mail]>]

Alvaro, Shraddha,

Please see inline [Bruno]

> From: Alvaro Retana (aretana) [mailto:[e-mail]]
> Sent: Friday, October 16, 2015 1:50 PM
> 
> 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.

[Bruno] Good. [REF1]

> >
> >The piece of text I have a problem with is this:
> >
> >   The administrative tag list within the TLV MUST be considered an
> >unordered list.

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

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

[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
> considered an unordered list" doesn't reflect a reasonable expectation and
> can't really be enforced.

[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 

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


_________________________________________________________________________________________________________________________

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.