Robert -
Thanx for the review.
Responses inline.
-----Original Message-----
From: Robert Sparks [mailto:rjsparks(_at_)nostrum(_dot_)com]
Sent: Tuesday, October 27, 2015 12:14 PM
To: General Area Review Team;
draft-ietf-isis-route-preference(_dot_)all(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org; isis-wg(_at_)ietf(_dot_)org
Subject: Gen-art LC review: draft-ietf-isis-route-preference-02
I am the assigned Gen-ART reviewer for this draft. The General Area Review
Team (Gen-ART) reviews all IETF documents being processed by the IESG for
the IETF Chair. Please treat these comments just like any other last call
comments.
For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-isis-route-preference
Reviewer: Robert Sparks
Review Date: 27Oct2015
IETF LC End Date: 30Oct2015
IESG Telechat date: Not yet scheduled
Summary: Ready for publication as Proposed Standard
This document reads easily despite most of it being detailed lists. I have no
objection to it moving forward, but I would like to check one thing:
The sparsity of detail at the end of section 2, where you call out potential
interoperability issues and suggest that "implementers may wish to support
transition mechanisms" is concerning. It might be worth being explicit here
about the interoperability issues, and what a transition mechanism might
look like, particularly if there's a chance of having to deal with a peer that
won't implement what's described in this draft?
[Les:] Appendix A provides a real-life example of how the interoperability
issue manifests itself. As far as how a transition mechanism might be
implemented this gets into non-normative aspects. I have always had a strong
bias for avoiding non-normative statements in specifications. Transition here
really means having some configuration knob to specify whether old/new behavior
should be used. Specifying a CLI is not something I would want to put into a
standard. For folks who have an IS-IS implementation it isn’t difficult to
figure out how to do this.
Did the group consider defining a couple of new code points and deprecating
these two, to avoid that transition issue?
[Les:] This would not help - it would only make things more difficult. You
would then have to deal with the transition between the old TLV and the new TLV
- which has a much broader impact because it affects all IPv6 prefix
reachability advertisements in all deployments - whereas the existing problem
only occurs in certain deployments (multiple instances of IS-IS on the same
router with redistribution between the instances at Level-2).
Les