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

Jari -

Thanx for the comments.
Inline.

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.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.all@ietf.org; ietf@ietf.org; isis-wg@ietf.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@cisco.com>
> wrote:
> 
> > Robert -
> >
> > Thanx for the review.
> > Responses inline.
> >
> >> -----Original Message-----
> >> From: Robert Sparks [mailto:rjsparks@nostrum.com]
> >> Sent: Tuesday, October 27, 2015 12:14 PM
> >> To: General Area Review Team;
> >> draft-ietf-isis-route-preference.all@ietf.org;
> >> ietf@ietf.org; isis-wg@ietf.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@ietf.org
> > https://www.ietf.org/mailman/listinfo/gen-art