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

[Shraddha Hegde <[e-mail]>]

David,

Pls see inline...

-----Original Message-----
From: Black, David [mailto:[e-mail]] 
Sent: Thursday, October 08, 2015 11:21 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: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: A-D issues

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

<Shraddha> The receiver detects tag removal or change based on its current set of RI LSAs that it has in the database.
                          How to determine whether there is removal of a tag is implementation specific.

                          1) One way  is to  store all the node tags originated by a node and when new LSA arrives re populate the
                                node tags and compare old and    new tags. That can give the details of whether a tag was
                               removed or changes/added
                         2) Another way is to compare the RI LSA and there is any change simply pass the new set of tags to the
                              processing/computation . In this case if tag moves from one RI LSA to the other re-processing happens. 

Generally, multiple LSA changes are combined in one event before triggering the processing. So if tag moves from one RI LSA to the other
If (1) is implemented no processing related to tags would be necessary.

But, all of this is vendor implementation specific  and we need not suggest one or the other way (May be there is a third way as well)in standards.
It should be good enough to say If there is any change in tags , redo the tag processing  and that's what the current text says I believe.

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 
> David> have 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?  
> David> 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 
> David> tag 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 
> David> tag 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 
> David> have to ignore tags that do not match any local policies.  That 
> David> still 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?  
> David> 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 
> David> tag 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 
> David> tag 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]
> ----------------------------------------------------