Last Call Review of draft-ietf-ospf-node-admin-tag-05
review-ietf-ospf-node-admin-tag-05-opsdir-lc-black-2015-10-09-00

This is a combined Gen-ART and OPS-Dir review.  Boilerplate for both follows ...

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at:

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These comments
were written primarily for the benefit of the operational area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

Document: draft-ietf-ospf-node-admin-tag-06
Reviewer: David Black
Review Date: October 5, 2015
IETF LC End Date: October 8, 2015
IESG Telechat date: October 15, 2015

Summary:  This draft is on the right track, but has open issues
 		described in the review.

This is a generally well-written draft about adding administrative tags for
operational use to OSPF.  The draft is clear, and the material on how the
tags could be used is helpful, although raises a number of concerns about
the consequences of the intended usage of these tags.

---- Major issues: ----

[1] Operational considerations:  There appears to be more than enough
enabled by this draft to wreak serious operational havoc, but the draft
seems to sidestep all operational topics, primarily by treating all
usage of tags as vendor- or implementation- specific and trusting the
vendors and operators not to foul things up.  I'm not sure that's wise.

See end of OPS-Dir review below for more on this concern.

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

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

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

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

--- Nits/editorial comments: ----

-- 1.  Introduction

The Abstract says that the tags are for "route and path selection"; the
Introduction should also say that.  Suggestion - at the end of this sentence
in the first paragraph:

   It is useful to assign a per-node administrative tag to a router in
   the OSPF domain and use it as an attribute associated with the node.

add the text "for route and path selection".  This will help with the
second sentence in the second paragraph:

   Path selection is a functional set
   which applies both to TE and non-TE applications and hence new TLV
   for carrying per-node administrative tags is included in Router
   Information LSA [RFC4970] .

If "path selection" and "functional set" are specific terms with
specialized meaning in OSPF context, that sentence is fine as-is,
otherwise it would read better if it began with:

   Route and path selection functionality applies to both ...

-- 3.1.  TLV format

   Type : TBA, Suggested value 10

Please add an RFC Editor Note asking the RFC Editor to replace this with
the actual IANA-assigned value.

-- 3.2.  Elements of procedure

While it's obvious that tag usage should be confined to the administrative
domain that understands the tag, it's worth stating.  At the end of this
sentence:

   Interpretation of tag values is specific to the administrative domain
   of a particular network operator.

I'd suggest adding:

   , and hence tag values SHOULD NOT be propagated outside the
   administrative domain to which they apply.

-- 4.4.  Mobile back-haul network service deployment

Please expand "eNodeB" acronym on first use.

-- 4.5.  Explicit routing policy

In Figure 3:
- The link from the leftmost pair of A nodes to the pair of T nodes
   do not have link weights.
- The link from the left R node to the left T node does not have a
   link weight
- The following example of an explicitly routed policy:

      - Traffic from A nodes to I nodes must not go through R and T
      	nodes

    prevents the leftmost pair of A nodes from sending traffic to the
    I nodes.  Was this "black hole" intended as part of the example?

Also: "explicitly routed policies" -> "explicit routing policies"

- 5. Security considerations

I'd add discussion that advertisement of tag values for one administrative
domain into another risks misinterpretation of the tag values (if the two
domains have assigned different meanings to the same values), which may
have undesirable and unanticipated side effects.

In addition, injection of tag values from the outside (e.g., forge OSPF
traffic that appears to be from a node in the domain and carries
administrative tag values) is at least a possible denial-of-service attack
vector, and could also be used for more nefarious purposes (e.g., reroute
otherwise unobservable [to the attacker] VPN traffic via a route where
the attacker can observe it).

idnits 2.13.02 did not find any nits.

---- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ----

A.1.2.  Has installation and initial setup been discussed?
A.1.5.  Has the impact on network operation been discussed?
A.1.6.  Have suggestions for verifying correct operation been discussed?

	No - given the impact that these tags could have on route and path
		computation, likely implementations will be powerful "guns"
		with which network operators can readily shoot themselves
		in far more than just their "feet."  These
		considerations would have to be documented based on the
		specific uses made of these tags by specific implementations
		and deployments.  All of that appears to be outside the scope
		of this draft.

A.1.7.  Has management interoperability been discussed?

	No - at a minimum, reporting of tag values ought to be defined
		via an OSPF MIB extension or analogous functionality.
		This is minor issue [D].

A.1.8.  Are there fault or threshold conditions that should be reported?

	Yes, but they're implementation-specific - see response to
		A.1.[2,5,6] above.

A.2.  Management Considerations
   Do you anticipate any manageability issues with the specification?

	Yes, manageability has been largely ignored.

A.3.  Documentation

   Is an operational considerations and/or manageability section part of
   the document?

	No.

   Does the proposed protocol have a significant operational impact on
   the Internet?

	Yes, the anticipated uses will.

   Is there proof of implementation and/or operational experience?

	Nothing was stated in the draft or shepherd write-up.

As an OPS-Dir member, I'm concerned by the above RFC 5706 answers,
and in particular treating all operational issues as vendor- and/or
operator-specific.  One possible alternative would be to scope the
draft down to interoperably specify what's needed for LFA, as
indicated by this answer from the Shepherd write-up:

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with it?

      There is consensus from the WG and others outside the WG that
      this document can progress. It complements work done on LFA 
      manageability in the RTG Working Group.

Another alternative could be Experimental RFC status for the full
tag mechanism (e.g., to figure out what it'll be used for in practice,
how and why) rather than Proposed Standard.

This is major issue [1].

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------