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

From: Shraddha Hegde <[email-masked]>
Date: Thu, 8 Oct 2015 12:03:04 +0000

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:[email-masked]] 
Sent: Wednesday, October 07, 2015 7:58 PM
To: Shraddha Hegde <[email-masked]>; Rob Shakir <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; General Area Review Team ([email-masked]) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Black, David <[email-masked]>
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
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Black, David" <[email-masked]>
Date: Thu, 8 Oct 2015 17:50:47 +0000

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

> From: Shraddha Hegde [mailto:[email-masked]]
> Sent: Thursday, October 08, 2015 8:03 AM
> To: Black, David; Rob Shakir; [email-masked]; [email-masked]; ops-
> [email-masked]; General Area Review Team ([email-masked]);
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06:
> A-D issues
> 
> ------------------------------------------------------------------------------
> -------------------------------------------------------
> 
> 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.
> 
> 
> ------------------------------------------------------------------------------
> ---------------------------------------------------------
> 
> To: Shraddha Hegde <[email-masked]>; Rob Shakir <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]; General Area Review
> Team ([email-masked]) <[email-masked]>; [email-masked]
> > the rationale for not specifying an interoperable tag value removal
> mechanism ought to be added to this document.
> >

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 9 Oct 2015 03:48:58 +0000

David,

Pls see inline...

-----Original Message-----
From: Black, David [mailto:[email-masked]] 
Sent: Thursday, October 08, 2015 11:21 PM
To: Shraddha Hegde <[email-masked]>; Rob Shakir <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; General Area Review Team ([email-masked]) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Black, David <[email-masked]>
Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: A-D issues

Shradda,

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

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

> To: Black, David; Rob Shakir; [email-masked]; [email-masked]; 
> ops- [email-masked]; General Area Review Team ([email-masked]); 
> [email-masked]
> David> Please add that statement, specifically that a receiver may 
> David> have to ignore tags that do not match any local policies.
> 
> 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"/>."
> 
> 
> <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> receiving node determine when it has a complete set of tags?  
> David> Suggested
> rephrase:
> 
> 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:
> 
> David> relevant RI LSAs and hence that absence of a previously seen 
> David> tag renders that tag no longer applicable?  The "seen all the 
> current information at any point of time.
> 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.
> 
> 
> > <shraddha> I think this should be taken separately as part of OSPF 
> > MIB RFC update, which will combine multiple features which require 
> > new
> definitions.
> >
> <Shraddha>Currently there is no active draft working on OSPF MIB to 
> update the node admin tag related configs.
> 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.
> 
> [email-masked]; [email-masked]; [email-masked]; General 
> Area Review Team ([email-masked]) <[email-masked]>; 
> [email-masked]
> Subject: Gen-ART and OPS-Dir review of 
> draft-ietf-ospf-node-admin-tag-06: A-D issues
> 
> > 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.
> 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.
> 
> > (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.
> >
> >
> >    with a node for the purpose of any computation or processing at 
> > the
> receiver SHOULD
> >    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
> David> receiving node determine when it has a complete set of tags?  
> David> Suggested
> rephrase:
> 
> > When there is a change or removal of an adminstrative affiliation of 
> > a node, the node MUST
> >
> > On the receiver, When there is a change in the node administrative 
> > tag TLV or removal/
> 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:
> 
> David> relevant RI LSAs and hence that absence of a previously seen 
> David> tag renders that tag no longer applicable?  The "seen all the 
> > <shraddha> I think this should be taken separately as part of OSPF 
> > MIB RFC update, which will combine multiple features which require 
> > new
> definitions.
> >
> David L. Black, Distinguished Engineer EMC Corporation, 176 South St., 
> Hopkinton, MA  01748