Jari -
Thanx for the comments.
Inline.
-----Original Message-----
From: Jari Arkko [mailto:jari(_dot_)arkko(_at_)piuha(_dot_)net]
Sent: Thursday, November 19, 2015 2:58 AM
To: Les Ginsberg (ginsberg)
Cc: Robert Sparks; 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: Re: [Gen-art] Gen-art LC review: draft-ietf-isis-route-preference-02
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) ...".
[Les:] The devil is really in the details in this draft - and I appreciate if
you are not heavily into the protocol details things can be easily
misinterpreted.
The draft makes one non-backwards compatible change to the protocol - which is
to eliminate the incorrect " Level 2 down prefix" route type defined in RFC
5308. This is the change that could require a transition mechanism.
Appendix A documents a real world interoperability issue - but it is NOT
directly related to RFC 5308. It results from inconsistent interpretation of
content in RFC 5302/RFC 5305. There is no transition mechanism proposed for
this as the incompatibility already exists in some deployments. What is needed
here is for the non-conforming implementations to correct their behavior.
We could mention Appendix A in Section 2 - but it would NOT be related to the
transition mechanism which is suggested in that section.
(Hope this makes sense)
Les
Jari
On 27 Oct 2015, at 21:41, Les Ginsberg (ginsberg)
<ginsberg(_at_)cisco(_dot_)com>
wrote:
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
_______________________________________________
Gen-art mailing list
Gen-art(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/gen-art