Re: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-route-preference-00

Christian Hopps <chopps@rawdofmt.org> Tue, 26 August 2014 13:08 UTC

Return-Path: <chopps@rawdofmt.org>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52FB1A6FDD for <isis-wg@ietfa.amsl.com>; Tue, 26 Aug 2014 06:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoW-TwC-y_1k for <isis-wg@ietfa.amsl.com>; Tue, 26 Aug 2014 06:08:24 -0700 (PDT)
Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65AE41A6FF6 for <isis-wg@ietf.org>; Tue, 26 Aug 2014 06:08:14 -0700 (PDT)
Received: by mail-pa0-f50.google.com with SMTP id et14so23378973pad.23 for <isis-wg@ietf.org>; Tue, 26 Aug 2014 06:08:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=LSe+t2mU1SrqGuh7EIxuSdQq2flgdV34nESCe3f2axQ=; b=CPMfqWtaQEhN8aZf4EGRzAZ97McLsowSAXFSf8+a1CWcvusDDKuL8LurqMYllk77Jk ixZMgjSFGxScJ3TBx318BjlShQYCwBxIOhwkc+nLdKMUHgUI925oZgbUo6HizuAnZSHw yNKT65/nyQVBZRyN2nCng9Kg0MIVo2InswEoYTRZpPT48VE+QR0zi5vCUy9m/IuCbDuE gMXx0vwUdpiqcVwGXOQd4LOpvFl5qAtpK2yLP7qnU5w5WblBDauuR4QtVq1Mcj9wSitm 1aZqsODjn30cOmb2WIJBb1BXCP0FN7vemAORlYpzlePWK0Tpe4YyH4yTk4N6jOaTQiAk KVxw==
X-Gm-Message-State: ALoCoQmKKpcSKy9EnVglcCCGiSq1GTXh/wEj491NY+ltsk6QxdRoXBJzxGMfW9zAhpPvYjzycaf2
X-Received: by 10.66.167.105 with SMTP id zn9mr37882149pab.103.1409058493816; Tue, 26 Aug 2014 06:08:13 -0700 (PDT)
Received: from [192.168.1.3] (c-71-227-97-41.hsd1.mi.comcast.net. [71.227.97.41]) by mx.google.com with ESMTPSA id fk11sm4618603pdb.91.2014.08.26.06.08.11 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Aug 2014 06:08:12 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_587BB512-0E06-452D-B9D7-E9B74F665FAF"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Christian Hopps <chopps@rawdofmt.org>
In-Reply-To: <1B502206DFA0C544B7A60469152008633F3624F1@eusaamb105.ericsson.se>
Date: Tue, 26 Aug 2014 09:08:09 -0400
Message-Id: <7479C65E-D4D8-4C22-9355-28B66BAF820A@rawdofmt.org>
References: <1B502206DFA0C544B7A60469152008633F35A17A@eusaamb105.ericsson.se> <FF710BB8-0275-401E-BA3F-3ACC6D40BDE6@rawdofmt.org> <2233_1408625655_53F5EBF7_2233_1538_1_9E32478DFA9976438E7A22F69B08FF9207D942@OPEXCLILM34.corporate.adroot.infra.ftgroup> <F3ADE4747C9E124B89F0ED2180CC814F23EF9517@xmb-aln-x02.cisco.com> <1B502206DFA0C544B7A60469152008633F35E8FC@eusaamb105.ericsson.se> <F3ADE4747C9E124B89F0ED2180CC814F23EFCF83@xmb-aln-x02.cisco.com> <1B502206DFA0C544B7A60469152008633F3624F1@eusaamb105.ericsson.se>
To: Uma Chunduri <uma.chunduri@ericsson.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/GGFk6vq3a_-hLjkagRC9GjaSmAg
Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Hannes Gredler <hannes@juniper.net>, Christian Hopps <chopps@rawdofmt.org>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-route-preference-00
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Aug 2014 13:08:29 -0000

As the author of RFC 5308, my intention was not to create a different preference from IPv4, that doesn’t make much sense. In fact my plan was to respin the draft as a bis to correct the difference. I feel it would be helpful to be able to refer to this draft in order to clarify why the change was being made.

Thanks,
Chris.

On Aug 26, 2014, at 4:03 AM, Uma Chunduri <uma.chunduri@ericsson.com> wrote:

> Dear Les,
>  
> FWIW -
>  
> 1.       For V4, IMO, the problem seen  because of incorrect implementation (fix the code in R2)  not because of lack of clarity in the specification. So I don’t see any need to clarify anything
> (actually, it’s not possible to clarify, more in-line). You still have to “just clearly answer” my original question on which document said to “prefer” the route with “down” bit set for TLV 135.
> 2.       For V6, it’s good we agreed your solution creates interoperability issues/routing loops. I didn’t understand your goal of matching V4 behavior to V6 behavior.
> To me both V4 and V6 specs are clear.
>  
> I am still fine, if the respected WG feel to progress any ways.
>  
> More in-line [Uma]:
> --
> Uma C.
>  
> From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] 
> Sent: Monday, August 25, 2014 6:53 PM
> To: Uma Chunduri; stephane.litkowski@orange.com; Christian Hopps
> Cc: Hannes Gredler; isis-wg@ietf.org list
> Subject: RE: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-route-preference-00
>  
> Uma -
>  
> …
>  
>                 >The interoperability issue described was revealed in interoperability testing done by Stephane. He connected two different existing
>                 > implementations in the way described and saw the loop. Given access to the same set of implementations anyone would see the same
>                 >behavior under the conditions described.
>  
> [Uma]: If it’s not then it’s also called “bug” and wearing developer hats we both fix these every day. No?
>              It’s unfortunate, you thought this need to be fixed through  specification. I would only say this implementation “bug” got more attention than it’s deserved or worth!
>  
>                 >2)You say " There are no route preferences currently defined in RFC 5305".
>                 >…
>                 >" 1.  L1 intra-area routes with internal metric; L1 external routes
>                 >with internal metric"
>                 >For TLVs 135/235 we use the following text (see Section 3.3):
>                 >"  1.  L1 intra-area routes; L1 external routes". This does NOT represent a change.
>                 >It simply omits text which is not applicable to TLVs 135/235.
>  
> [Uma]: Yes, this does NOT represent a change. Actually, it doesn’t mean ANY THING.
>              Let me ask this, With RFC 5305 i.e., for TLV 135,  how do you distinguish “L1 intra-area routes; L1 external routes”?
>              You simply can’t and hence I said it’s a redundant statement.
>  
>               > 3)It is TRUE that we are modifying the rules for IPV6 L2 Routes w DOWN bit set (TLVs 236,237) as defined in RFC 5308 -  
>               > but that is because there is an error in RFC 5308 and we need to correct it . It does not make sense to apply different rules for IPv4 and IPv6.
>  
> [Uma]: I don’t know if it make sense to have different rules for V4 and V6 (it’s too late to even think). But, I can say this, it doesn’t make sense to me, to create new problems for existing deployments for
>               the sake of matching V4 and V6.
>  
>              > In doing so you are right that it is possible that during the transition we may see a loop problem w IPv6 deployments in cases where we currently would not have seen it.
>  
> [Uma]:  At least we agreed on this!
>  
> --
> Uma C.