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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Uma -



It is a bit difficult to respond to your remarks because there is such a large gap between what your comments say and what the draft is trying to do. I have tried to look at the draft in the light of your comments and see if the language we used has contributed to this disconnect - but it is hard  for me to see how you have drawn a number of the conclusions you have. So the underlying message in my responses is "you have misinterpreted things". I don't know if my responses will help get us to common ground, but I will give it a try.



I am going to reply in the order I think makes sense - not the same order that you have listed below.



1)You say " the non-existent loop issue" indicating you believe that the interoperability issue originally described in http://datatracker.ietf.org/doc/draft-litkowski-isis-ip-route-preference-issue/ and now described in the Appendix to http://datatracker.ietf.org/doc/draft-ginsberg-isis-route-preference/ is an invention on our parts. THIS IS FALSE!!



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.



We will never be able to have a useful discussion of the remainder of the draft unless you acknowledge this reality.



2)You say " There are no route preferences currently defined in RFC 5305".



In a literal sense this is true, but of course we do have route preference rules for TLVs 135/235. If we did not there would be a specification gap.



If one looks at the route preference rules defined in RFC 5302, eliminates the attributes/types which are not supported by TLV 135/235 (internal vs external metric, internal vs external reachability), then one has the set of route preference rules. However, no existing document ever wrote this down - things have worked because we (the IS-IS community) relied on the cleverness of implementors to extrapolate the rules for TLVs 135/235 from the rules for TLVs 128/130. In the absence of the interoperability issue revealed by Stephane's testing we might have simply continued with that ad hoc status. However since the interoperability issue exists, we decided to make the rules for TLVs 135/235 explicit as part of the draft. In doing so we have been careful to not deviate from the rules defined in RFC 5302. But we did eliminate the categories that are not supported by TLVs 135/235. For example, in RFC 5302 Section 3.2 the text says:



" 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.



So I really don't know what your objection is.



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. 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. But given that the use of DOWN bit in L2 LSPs is rare - and deployment of IPv6 is still much less than IPv4 - it is better to make the correction sooner rather than later.



It is always possible, of course, for protocol vendors to provide a knob to enable/disable the new IPv6 behavior as a transition aid. I would be willing to add text to the draft that discusses that point.



   Les





> -----Original Message-----

> From: Uma Chunduri [mailto:[e-mail]]

> Sent: Sunday, August 24, 2014 4:37 AM

> To: Les Ginsberg (ginsberg); [e-mail]; Christian

> Hopps

> Cc: Hannes Gredler; [e-mail] list

> Subject: RE: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-

> route-preference-00

>

> Dear Les,

>

>

> My detailed response in-line [Uma]:

>

> Quick Summary:

> ----------------------

>

> 1. There are no route preferences currently defined in RFC 5305. In fact Tony

> (both Tony's!)  took more effort to not to have any by even removing the

>     I/E bit (remember BGP MED issue?).   This is applicable to MT V4 TLV 235

> (RFC 5120).

>     "Down bit" semantic *only* used for not creating circular looping  for TLV

> 135/235 as defined (unlike V6 5308).

>

> 2. Even for TLV 236/TLV 237 (V6 variants) there is no internal/external metric

> and hence no route preferences from those. However, yes,

>     route preferences based on "Down bit " are defined in RFC 5308 (Section

> 5) and hence these are applicable to MT variant TLV 237.

>     The good news is it's clearly defined and  is applicable to 236 and 237.

>     If you want to correct this to make this "equivalent" to V4 (135/235),

> actually you create the non-existent loop issue for V6 you are PRECISELY

> trying to prevent.

>

>    Essentially this draft could create problems for BOTH  V4 (135/235 through

> clarification)  and V6 (236/237 through correction).

>

>    Did you also see the backward compatible problems  I am talking about

> both V4 and V6 once an implementation follows your

>    new draft with nodes behaving per 5305 and 5308 (and 5120)??

>

> --

> Uma C.

>

>

> -----Original Message-----

> From: Les Ginsberg (ginsberg) [mailto:[e-mail]]

> Sent: Thursday, August 21, 2014 2:36 PM

> To: [e-mail]<mailto:[e-mail]>; Christian Hopps; Uma Chunduri

> Cc: Hannes Gredler; [e-mail]<mailto:[e-mail]> list

> Subject: RE: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-

> route-preference-00

>

> Let me add to what Chris and Stephane have stated.

> The issue is NOT confined to new style TLVs - it could occur w old style TLVs

> as well since RFC 5302 defined the DOWN bit for those TLVs.

>

> [Uma]: I didn't see you alter preferences to the old style in this draft?? I see

> only for 135/235 in Section 3.3 and 236/237

> in Section 3.4 http://tools.ietf.org/html/draft-ginsberg-isis-route-<http://tools.ietf.org/html/draft-ginsberg-isis-route-preference-00#page-5>

> preference-00#page-5<http://tools.ietf.org/html/draft-ginsberg-isis-route-preference-00#page-5>

>

>

> It is important to note that even though RFC 5302 allowed for the possibility

> of the DOWN bit being set in L2 LSPs (see Section 3.3) it did NOT define any

> L2 route types with DOWN bit set to one (see Section 3.1). This was not

> strictly necessary because RFC 5302 also states (Section 3.3) that DOWN bit

> should be ignored when seen in L2 LSPs. IMO it is the subtleties of allowing

> DOWN bit to be set in L2 LSPs but specifying it should be ignored that has

> led to inconsistent implementations. This is compounded by the fact that -

> as Chris already pointed out - RFC 5308 did NOT ignore the DOWN bit in L2

> LSPs.

>

> [Uma]: You are trying to fix TLV 236 route preferences with DOWN bit

> because you see a problem with TLV 135 (V4?).

>              IMO,  It doesn't make sense and Spec is very clear for both V4 and V6.

>

>

> The primary point of this draft is to clarify what the correct behavior should

> be. In doing so we do not make ANY changes to RFC 5302/5305 - a strict

> interpretation of those RFCs is still correct under the rules defined in this

> draft. We do correct RFC 5308 so that it is consistent w RFC 5302/5305.

>

> [Uma]: You inadvertently created problems for both V4 and V6, which you

> were trying to solve to start with.

>              Let's see quickly how.. take the same example

>              http://tools.ietf.org/html/draft-ginsberg-isis-route-preference-<http://tools.ietf.org/html/draft-ginsberg-isis-route-preference-00#appendix-A>

> 00#appendix-A<http://tools.ietf.org/html/draft-ginsberg-isis-route-preference-00#appendix-A>

>

>             Assume instead of 135, all nodes are using V6 TLV 236/237.

>             R2 is now updated and  implementing your draft  (section 3.4 as

> stated) and R1 is not.

>             R1 is just implementing 5308.

>

>                              ============ http://tools.ietf.org/html/draft-ginsberg-isis-<http://tools.ietf.org/html/draft-ginsberg-isis-route-preference-00#page-6>

> route-preference-00#page-6<http://tools.ietf.org/html/draft-ginsberg-isis-route-preference-00#page-6>===

>                               3.4.  Order of Preference for all types of routes supported

> by TLVs 236

>                                              and 237

>

>                              This document defines the following route preferences for

> IPv6 routes

>                              advertised in TLVs 236 or 237.

>

>                               1.  L1 intra-area routes; L1 external routes

>

>                               2.  L2 intra-area routes; L2 external routes; L1->L2 inter-area

>                               routes; L1-L2 external routes;L2-L2 inter-area routes

>

>                              3.  L2->L1 inter-area routes; L2->L1 external routes;L1->L1

> inter-

>                               area routes

>                             ============

>

>                     R2 selects R1, because it prefers the route which doesn't have

> up/down bit set in "L2-L2 inter-area routes" (#2 above) as defined above.

>                     R1 selects R2 as next hop due to lowest metric and it doesn't have

> corrected behavior of your draft for " L2-L2 inter-area routes".

>                    Hence the loop.

>

> --

> Uma C.