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

Uma Chunduri <> Wed, 27 August 2014 11:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BBBF71A064F for <>; Wed, 27 Aug 2014 04:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gEuZlgMQ7kEj for <>; Wed, 27 Aug 2014 04:33:20 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 88B5F1A064D for <>; Wed, 27 Aug 2014 04:33:20 -0700 (PDT)
X-AuditID: c6180641-f79916d00000623a-32-53fd6ad1c9a8
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 96.AF.25146.1DA6DF35; Wed, 27 Aug 2014 07:21:22 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Wed, 27 Aug 2014 07:33:18 -0400
From: Uma Chunduri <>
To: Christian Hopps <>
Thread-Topic: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-route-preference-00
Date: Wed, 27 Aug 2014 11:33:18 +0000
Message-ID: <>
References: <> <> <2233_1408625655_53F5EBF7_2233_1538_1_9E32478DFA9976438E7A22F69B08FF9207D942@OPEXCLILM34.corporate.adroot.infra.ftgroup> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F3640E9eusaamb105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyuXRPoO6lrL/BBnNb2Sz+3b/BbLHhz0Z2 i/57T9gsjh56z2rxde9DVgdWjym/N7J6LFnyk8njetNVdo+WZyfZPO687mEPYI3isklJzcks Sy3St0vgynj0z6xgw2fGinPNqQ2MJy4xdjFyckgImEgcn9zGAmGLSVy4t56ti5GLQ0jgKKPE xZvLGSGc5YwS67f2s4NUsQnoSXyc+hPMFhHQlFjaOAGsg1ngFKPEr1lLmEESwgKxEpc/3IEq ipOY9vEIM4SdJLHh9DewdSwCqhJ7uhYxgdi8Ar4S5w/+Z4LYdohF4uXVT2wgCU4BB4lzj66B DWIEuu/7qTVgDcwC4hK3nsxngrhbQGLJnvPMELaoxMvH/1ghbCWJOa+vMUPU50vcb2thhVgm KHFy5hOWCYyis5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkaO0OLUs N93IcBMjMC6PSbA57mBc8MnyEKMAB6MSD++CqD/BQqyJZcWVuYcYpTlYlMR5NavnBQsJpCeW pGanphakFsUXleakFh9iZOLglGpgNGT43/YmjfX9xv7I3VoT+39N2lrE3Sd7rEircbrQFxnH rbWrFzz53D/FYI8Ge8qPs280V/zjMeycp6syR2PK01XHNJUPb+bhtj7xsEDvZdkS3hymL6s2 X2NTMmia2MHTt6DWQC7VNuqQ4iKG9oJH7ucqX1iXrLsoJ/vzo+df52eW23neXoh+qsRSnJFo qMVcVJwIAE4B7zasAgAA
Cc: "Les Ginsberg \(ginsberg\)" <>, Hannes Gredler <>, " list" <>
Subject: Re: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-route-preference-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Aug 2014 11:33:23 -0000

Hi Chris,

>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
Thanks for clarifying. But as that is already done, perhaps it's better to live with that so that we need not introduce new inetrop. issues (as agreed below) for TLV 236/237.
We have customers using both and they may not be speaking here.
This is only my suggestion but if you strongly feel this has to be addressed any ways I have no objection as I said earlier.

Hi Les,

I think we are going in circles (!!) stating the some point multiple times expect we made progress on agreeing the V6 new issue (both of us).
I am not able to suggest anything new and add value.

Let me try -
Perhaps a sub-tlv for leaked and external prefix for TLV 135/235 WITOUT associating any ROUTE PREFERENCE to it.
I like the X bit in 236 (without any preference baggage), which is not there for 135/235.
This is useful for some implementation when RIB is not HOT in HA scenarios  (I can't spell more details here and now, but these are related to route type  changes during HA)
 and also remove the need for tagging explicitly through configuration.
Uma C.

From: Christian Hopps []
Sent: Tuesday, August 26, 2014 6:08 AM
To: Uma Chunduri
Cc: Christian Hopps; Les Ginsberg (ginsberg);; Hannes Gredler; list
Subject: Re: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-route-preference-00

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.


On Aug 26, 2014, at 4:03 AM, Uma Chunduri <<>> wrote:

Dear Les,


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) []
Sent: Monday, August 25, 2014 6:53 PM
To: Uma Chunduri;<>; Christian Hopps
Cc: Hannes Gredler;<> 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.