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

[Uma Chunduri <[e-mail]>]

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 [mailto:[e-mail]]
Sent: Tuesday, August 26, 2014 6:08 AM
To: Uma Chunduri
Cc: Christian Hopps; Les Ginsberg (ginsberg); [e-mail]; Hannes Gredler; [e-mail] 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.

Thanks,
Chris.

On Aug 26, 2014, at 4:03 AM, Uma Chunduri <[e-mail]<mailto:[e-mail]>> 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:[e-mail]]
Sent: Monday, August 25, 2014 6:53 PM
To: Uma Chunduri; [e-mail]<mailto:[e-mail]>; Christian Hopps
Cc: Hannes Gredler; [e-mail]<mailto:[e-mail]> 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.