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

[<[e-mail]>]

Hi David,

Thanks for your careful review.

Regarding you major issue:

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


May be the draft is missing some text on some points, but I don't share this _major_ concern (regarding the operation use of tags):
- their use in routing protocols is not new and we have a large operational feedback on this. e.g. 8 years with IS-IS prefix tags (RFC 5130), and especially 20 years with BGP community (RFC 1997) which are heavily used by all network operators, including between Autonomous System/Administrative Domains (which is beyond OSPF usage)
- they are meant to ease network operation. We could probably do everything you can think of without node tags, e.g. by referencing each node individually using its loopback address or router ID. But this would be more error prone and difficult to maintain over time.  I would note that the abstract of RFC 1997 states that BGP community has been defined to "reduce the management complexity of maintaining the Internet". 


And +1 on Rob's comment

Regards,
Bruno

> From: Black, David [mailto:[e-mail]] > Sent: Tuesday, October 06, 2015 1:35 AM
> 
> 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
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> 


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.