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 to
David> ignore tags that do not match any local policies. That still doesn't
David> explain why "MUST" is inappropriate in either case.
David> For the first requirement, I was expecting
David> the "MUST" to apply 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 receiving
David> 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 always
David> 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 has
David> 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 relevant
David> RI LSAs and hence that absence of a previously seen tag renders that
David> tag no longer applicable? The "seen all the relevant RI LSAs" portion
David> 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 protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
