Re: [OSPF] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: A-D issues

[Shraddha Hegde <[e-mail]>]

Thanks David for the follow-up.
Pls find details below.

[...Snip to open comments...]

David> Please add that statement, specifically that a receiver may have 
David> to ignore tags that do not match any local policies.  

<Shraddha>Updated as below.

"If a receiving node does not
understand the tag value or does not have a local policy corresponding to the tag,
it ignores the specific tag and floods the RI LSA without any change as defined in <xref target="RFC4970"/>."


David> For the first requirement, I was expecting the "MUST" to apply 
David> only to "independent identifier," i.e.:

    Each tag MUST be treated as an independent identifier that MAY be
    used in policy to perform a policy action.

<Shraddha> OK. Updating the draft as suggested.

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

David> The last sentence appears to still have a problem:  How does a 
David> receiving node determine when it has a complete set of tags?  Suggested rephrase:

	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.

David> I think that captures the underlying point that processing MUST 
David> always be based on current tag information.
 <Shraddha> Updated as per suggestion

<t> Multiple node administrative tag TLVs MAY appear in an RI LSA or 
   multiple node administrative tag TLVs MAY be contained in different
   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.
</t>
-------------------------------------------------------------------------------------------------------------------------------------

David> I don't understand how a receiving node can be certain that a tag 
David> has been removed based on this sentence in Section 2:

   Multiple TLVs MAY be added in same RI-LSA or in a different instance
   of the RI LSA as defined in [I-D.acee-ospf-rfc4970bis].

David> How does a receiving node determine that it has seen all the 
David> relevant RI LSAs and hence that absence of a previously seen tag 
David> renders that tag no longer applicable?  The "seen all the 
David> relevant RI LSAs" portion of this answer probably belongs in Section 2.

<Shraddha> A node cannot determine that it has all the complete and current information at any point of time.
This is true for any link state IGP protocol which floods the data for distribution. 
The flooding mechanism is reliable and ensures the changes are propagated
Domain wide. The receivers have to process any database change and apply it to the entire link state database every-time it receives any change from any node.
This is so fundamental to the link state protocols, I don't see the necessity of repeating that concept in this document.


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

> [D] No management support
> 
> From OPS-Dir Q&A: At a minimum, reporting of tag values ought to be 
> defined via an OSPF MIB extension or analogous functionality.
> 
> <shraddha> I think this should be taken separately as part of OSPF MIB 
> RFC update, which will combine multiple features which require new definitions.
> 
> Acee, How do we go about this?

David> At the very least, the draft that updates that MIB should be referenced.

<Shraddha>Currently there is no active draft working on OSPF MIB to update the node admin tag related configs.
 Yang data models are extensively being referred and recommended for management.
Have included a reference to the document and requested authors of yang draft to consider adding the node-admin-tag
Related interfaces to the data model.

7.  Manageability Considerations

   Node administrative tags are configured and managed using routing
   policy enhancements.  YANG data definition language is the latest
   model to describe and define configuration for network devices.  OSPF
   YANG data model is described in [I-D.ietf-ospf-yang] and routing
   policy configuration model is described in
   [I-D.ietf-rtgwg-policy-model].  These two documents will be enhanced
   to include the node administrative tag related configurations.

-----Original Message-----
From: Black, David [mailto:[e-mail]] 
Sent: Wednesday, October 07, 2015 7:58 PM
To: Shraddha Hegde <[e-mail]>; Rob Shakir <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; General Area Review Team ([e-mail]) <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; Black, David <[e-mail]>
Subject: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: A-D issues

David> Inline.  I'll deal with the A-D issues here and the editorial 
David> items/nits in a separate message.

> David,
> 
> Thanks a lot for your detailed review and comments.
> 
 
[... snip ...]

> --- Minor issues: ----
> 
> -- 3.2 Elements of procedure:
> 
> [A] I see what look like some underspecified requirements:
> 
>    Each tag SHOULD be treated as an independent identifier that MAY be
>    used in policy to perform a policy action.
> 
>    The administrative tag list within the
>    TLV SHOULD be considered an unordered list.
> 
> Why are those two not "MUST" requirements?  What happens if either is 
> not done?
> 
> <Shraddha> It's perfectly valid for the receiver of the node admin tag 
> to ignore a certain tag or set of tags if there are no local policies.
> I think MUST will be too restrictive statement.

David> Please add that statement, specifically that a receiver may have 
David> to ignore tags that do not match any local policies.  That still 
David> doesn't explain why "MUST" is inappropriate in either case.

David> For the first requirement, I was expecting the "MUST" to apply 
David> only to "independent identifier," i.e.:

    Each tag MUST be treated as an independent identifier that MAY be
    used in policy to perform a policy action.


David> The "SHOULD" in the second requirement appears to be asking for 
David> interoperability problems if it's ignored.  I think that ought to be:

    The administrative tag list within the
    TLV MUST be considered an unordered list.

> ----------------------------------------------------------------------
> --------
> --------------------------------------------
> 
> [B] Tag set completeness:
> 
>    Multiple node administrative tag TLVs MAY appear in an RI LSA or
>    multiple node administrative tag TLVs MAY be contained in different
>    instances of the RI LSA.  The node administrative tags associated
>    with a node for the purpose of any computation or processing SHOULD
>    be a superset of node administrative tags from all the TLVs in all
>    instances of the RI LSA originated by that node.
> 
> This paragraph is about processing at that node.  It's easy to 
> misread, as that implication
> 
> is buried in the word "originated" in the last line.
> Suggested change:
> 
> 	"for the purpose of any computation or processing SHOULD" ->
> 	"for the purpose of any computation or processing performed
> 		at that node SHOULD"
> 
> Also, it looks like it's acceptable for other nodes to perform such 
> computation or processing based on a partial tag set for this node 
> (e.g., when some other node has not received all the RI LSAs with all the tags).  That should be stated.
> 
> <Shraddha> This is talking about processing at the receiver. Will update as below.
> 
> 
>    Multiple node administrative tag TLVs MAY appear in an RI LSA or
>    multiple node administrative tag TLVs MAY be contained in different
>    instances of the RI LSA.  The node administrative tags associated
>    with a node for the purpose of any computation or processing at the receiver SHOULD
>    be a superset of node administrative tags from all the TLVs in all
>    instances of the RI LSA originated by that node. Receiver MAY perform the processing on
>    administrative node tags when only a partial set is receieved but the receiver
>    node MUST repeat the computation or processing when the complete set of node
>    administrative tags for that node is received.

David> That's much clearer.  Some minor editorial suggestions:

	- "associated with a node" -> "associated with a node that originates tags"
	- "processing at the receiver" -> "processing at a receiving node"
	- "instances of the RI LSA" -> "received RI LSA instances"

David> The last sentence appears to still have a problem:  How does a 
David> receiving node determine when it has a complete set of tags?  Suggested rephrase:

	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.

David> I think that captures the underlying point that processing MUST 
David> always be based on current tag information.

> ----------------------------------------------------------------------
> --------
> ---------------------------------------------------
> [C] Tag change/removal:
> 
>    When there is a change in the node administrative tag TLV or removal/
>    addition of a TLV in any instance of the RI-LSA, implementations MUST
>    take appropriate measures to update its state according to the
>    changed set of tags.  Exact actions depend on features working with
>    administrative tags and is outside of scope of this specification.
> 
> Inability to interoperably remove a tag value (e.g., distribute the 
> update that tag X no longer applies to node Q) seems like a 
> significant omission, but I'm not a routing expert, so I'll defer to 
> the WG's and ADs' judgment on the importance of this.  At a minimum, 
> the rationale for not specifying an interoperable tag value removal mechanism ought to be added to this document.
> 
> <Shraddha> Added the tag updations at the origination.
> 
> When there is a change or removal of an adminstrative affiliation of a 
> node, the node MUST
> 
> re-originate the RI LSA with the latest set of node administrative tags.
> On the receiver, When there is a change in the node administrative tag 
> TLV or removal/
>    addition of a TLV in any instance of the RI-LSA, implementations MUST
>    take appropriate measures to update its state according to the
>    changed set of tags.  Exact actions depend on features working with
>    administrative tags and is outside of scope of this specification.

David> I don't understand how a receiving node can be certain that a tag 
David> has been removed based on this sentence in Section 2:

   Multiple TLVs MAY be added in same RI-LSA or in a different instance
   of the RI LSA as defined in [I-D.acee-ospf-rfc4970bis].

David> How does a receiving node determine that it has seen all the 
David> relevant RI LSAs and hence that absence of a previously seen tag 
David> renders that tag no longer applicable?  The "seen all the 
David> relevant RI LSAs" portion of this answer probably belongs in Section 2.

> ----------------------------------------------------------------------
> --------
> -----------------------------------------------------------
> 
> [D] No management support
> 
> From OPS-Dir Q&A: At a minimum, reporting of tag values ought to be 
> defined via an OSPF MIB extension or analogous functionality.
> 
> <shraddha> I think this should be taken separately as part of OSPF MIB 
> RFC update, which will combine multiple features which require new definitions.
> 
> Acee, How do we go about this?

David> At the very least, the draft that updates that MIB should be referenced.

[... Nits/editorial comments snipped - will send separate email ...]

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------