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

["Black, David" <[e-mail]>]

Shradda,

We're very close to done here, thanks for the updated text.

I have one more concern on information completeness vs. tag removal
(I'll deal w/[1] and the new Operational Considerations text in a
separate message):

The last paragraph in Section 3.2 of the proposed-for-07 text says:

   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.

In addition, this comment was made in email:

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

My Concern: How does a receiver detect tag removal or change when it
has to assume that its tag information may always be incomplete?

Specifically, how does a receiver determine that a tag (or an old tag
prior to a change) is not in some portion of the information that has
not been received (and hence that a tag removal or change has occurred)?

Thanks,
--David

> -----Original Message-----
> From: Shraddha Hegde [mailto:[e-mail]]
> Sent: Thursday, October 08, 2015 8:03 AM
> To: Black, David; Rob Shakir; [e-mail]; [e-mail]; ops-
> [e-mail]; General Area Review Team ([e-mail]);
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06:
> A-D issues
> 
> 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]
> ----------------------------------------------------