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

Jari Arkko <> Thu, 19 November 2015 10:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0D8B51B31FD; Thu, 19 Nov 2015 02:58:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1Al67V0GYcyz; Thu, 19 Nov 2015 02:58:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DA8D31B31F9; Thu, 19 Nov 2015 02:58:03 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33F4A2CC5C; Thu, 19 Nov 2015 12:58:03 +0200 (EET) (envelope-from
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zCX7ksh9c2ky; Thu, 19 Nov 2015 12:58:02 +0200 (EET)
Received: from [] ( [IPv6:2a00:1d50:2::130]) by (Postfix) with ESMTP id E13E32CC52; Thu, 19 Nov 2015 12:58:01 +0200 (EET) (envelope-from
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_7650552D-068F-454C-ADD8-B4656F36D32C"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5.1
From: Jari Arkko <>
In-Reply-To: <>
Date: Thu, 19 Nov 2015 12:58:02 +0200
Message-Id: <>
References: <> <>
To: "Les Ginsberg (ginsberg)" <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc: "" <>, General Area Review Team <>, "" <>, "" <>
Subject: Re: [Gen-art] Gen-art LC review: draft-ietf-isis-route-preference-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Nov 2015 10:58:06 -0000

Thanks for the review, Robert.

Robert’s question was good, and your answer Les was spot. What I’m wondering is whether it would be useful to add something to the document about your answer, Les? Or at the very least, a reference to Appendix A from Section 2. And if you add something about transition mechanisms, it could simply be “… transition mechanisms (such as configuration setting) …”.


On 27 Oct 2015, at 21:41, Les Ginsberg (ginsberg) <> wrote:

> Robert -
> Thanx for the review.
> Responses inline.
>> -----Original Message-----
>> From: Robert Sparks []
>> Sent: Tuesday, October 27, 2015 12:14 PM
>> To: General Area Review Team;;
>> 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
>> <>.
>> 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
> _______________________________________________
> Gen-art mailing list