Re: [Gen-art] Gen-art LC review: draft-ietf-isis-route-preference-02

["Les Ginsberg (ginsberg)" <[e-mail]>]

Robert -

Thanx for the review.
Responses inline.

> -----Original Message-----
> From: Robert Sparks [mailto:[e-mail]]
> Sent: Tuesday, October 27, 2015 12:14 PM
> To: General Area Review Team; [e-mail];
> [e-mail]; [e-mail]
> 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