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

From: Uma Chunduri <[email-masked]>
Date: Thu, 21 Aug 2014 03:04:20 +0000

We know  multiple  places  in 5302 and 5305 it's clearly said "Down" bit MUST NOT be set in L2. 
But I see the corner case in Section 4.1  where "Down" bit was allowed in the same level.

Now if that is the premise of this work - let's focus bit more on the problem see as described in Appendix A;

" o  R2 has two possible paths to reach 10/8, Level 2 route with metric
      2002, up/down bit is 0 (from R0) and Level 2 route with metric
      101, up/down bit is 1 (from R3).  R2 selects R1 as nexthop to 10/8
      because it prefers the route which does NOT have up/down bit set."

Why? 
Please clarify, which document said exactly prefer a route "which does NOT have up/down bit set". 

I could not see it neither in 5302 nor in 5305. To me this is R2 implementation issue (NOT a protocol issue) in dealing with 135s.

--
Uma C.
PS: Thanks both Hannes and Chris to check back if my question (asked partially at Toronto) has been addressed.

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Tuesday, August 19, 2014 4:48 AM
To: [email-masked] list
Cc: Hannes Gredler; Christian Hopps
Subject: [Isis-wg] Proposed isis-wg documents.

Hi Folks,

During the last meeting in Toronto there was good support for making the below drafts WG documents. Unless objections are posted to the list by Friday we will move forward with doing this.

Proposed WG Documents:

	draft-ginsberg-isis-sbfd-discriminator-00
	draft-ginsberg-isis-route-preference-00
	draft-litkowski-isis-yang-isis-cfg-01

Thanks,
Chris & Hannes.
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 21 Aug 2014 03:40:26 +0000

Uma -

The answers to all your questions are already in the draft.

Please reread Section 2 more carefully. It has direct quotes from RFC 5302 and 5305 which state:

" ignore the up/down bit in   L2 LSPs"

And 

" If a prefix is advertised from one area to another at the same
   level, then the up/down bit SHALL be set to 1."

This clearly introduces the possibility that DOWN bit can be set in L2 LSPs AND that it should NOT be used ("ignore" == "don't use"). We also have the existence proof from Stephane's interoperability testing that DOWN bit  is set in L2 LSPs (at least by some implementations) and that interpretation of the DOWN bit in L2 LSPs is not consistent among all implementations. This indicates that clarification is needed - which is the primary purpose of this draft.

The fact that you - a person with significant experience with the protocol - is uncertain also reinforces the need for this draft. (I mean that as a compliment.)

   Les

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Uma
> Chunduri
> Sent: Wednesday, August 20, 2014 8:04 PM
> To: Christian Hopps; [email-masked] list
> Cc: Hannes Gredler
> Subject: Re: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-
> route-preference-00
> 
> I could not see it neither in 5302 nor in 5305. To me this is R2
> implementation issue (NOT a protocol issue) in dealing with 135s.
> 
> 
> --
> Uma C.
> PS: Thanks both Hannes and Chris to check back if my question (asked
> partially at Toronto) has been addressed.
> 
> During the last meeting in Toronto there was good support for making the
> below drafts WG documents. Unless objections are posted to the list by
> Friday we will move forward with doing this.
> 
> Proposed WG Documents:
>

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 21 Aug 2014 06:24:55 +0000

Les,

Thank you for the response and the complement!

Section 2 of you document re-iterating the corner case where a down bit can be set in L2 LSP.
Ok, some implementation as seen by Stephane did indeed set the "Down" bit in L2 LSP (legit).

But I didn't get answer to my question for TLV 135 as described in Appendix A (Problem) - 
	
	Please clarify, which document said exactly to prefer a route "which does 
	NOT have up/down bit set".

>We also have the existence proof from Stephane's interoperability testing that DOWN bit  is set in L2 LSPs (at least by some implementations) and that interpretation of the DOWN bit in L2 LSPs is not consistent among all implementations. 

I see no specification (5302/5305) said to prefer/not-prefer the route with "down" bit set in L2 LSP. As I said, to me this is implementation issue on R2 not protocol issue for TLV 135.

This has to be clarified before discussing any solution (or position as clarification as you alluded to).

--
Uma C.

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Wednesday, August 20, 2014 8:40 PM
To: Uma Chunduri; Christian Hopps; [email-masked] list
Cc: Hannes Gredler
Subject: RE: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-route-preference-00

Uma -

And 

   Les

> During the last meeting in Toronto there was good support for making 
> the below drafts WG documents. Unless objections are posted to the 
> list by Friday we will move forward with doing this.
> 
> Proposed WG Documents:
>

---

From: Christian Hopps <[email-masked]>
Date: Thu, 21 Aug 2014 02:55:09 -0400

> I could not see it neither in 5302 nor in 5305. To me this is R2 implementation issue (NOT a protocol issue) in dealing with 135s.

Unfortunately it says this for IPv6 in RFC 5308. It’s not hard to imagine an implementation using those preferences for both address families, particularly given that RFC5 5308 claims to be making the same changes as RFC 5305.

Thanks,
Chris.

---

From: <[email-masked]>
Date: Thu, 21 Aug 2014 12:54:14 +0000

Uma,

Chris is right. There is explicit route preference rules established for IPv6 TLVs (RFC5308), old IPv4 (RFC 5302) but unfortunately there's nothing in RFC5305 for extended IPv4 TLVs, so implementators can reuse behaviors from 5308 or 5302 or none of them. This, unfortunately, leads freedom for interoperability issues.
IMO, It makes sense to clarify the behavior.

Stephane

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Thursday, August 21, 2014 08:55
To: Uma Chunduri
Cc: Hannes Gredler; Christian Hopps; [email-masked] list
Subject: Re: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-route-preference-00

> I could not see it neither in 5302 nor in 5305. To me this is R2 implementation issue (NOT a protocol issue) in dealing with 135s.

Unfortunately it says this for IPv6 in RFC 5308. It's not hard to imagine an implementation using those preferences for both address families, particularly given that RFC5 5308 claims to be making the same changes as RFC 5305.

Thanks,
Chris.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 21 Aug 2014 21:36:09 +0000

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. 

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.

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 may find the current specs "perfectly clear" - but the fact that not all implementations are consistent argues that not everyone found it to be so - and the fact that RFC 5308 is in conflict argues strongly for a clarification/correction. The question I would ask you is whether you find anything in the draft with which you disagree? 

If your argument is that the draft is unnecessary, I understand your point though I do not agree. It will be up to WG consensus to then determine which POV prevails.

   Les

> From: Isis-wg [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, August 21, 2014 5:54 AM
> To: Christian Hopps; Uma Chunduri
> Cc: Hannes Gredler; [email-masked] list
> Chris is right. There is explicit route preference rules established for IPv6
> TLVs (RFC5308), old IPv4 (RFC 5302) but unfortunately there's nothing in
> RFC5305 for extended IPv4 TLVs, so implementators can reuse behaviors
> from 5308 or 5302 or none of them. This, unfortunately, leads freedom for
> interoperability issues.
> Unfortunately it says this for IPv6 in RFC 5308. It's not hard to imagine an
> implementation using those preferences for both address families,
> particularly given that RFC5 5308 claims to be making the same changes as
> RFC 5305.
> 
> Thanks,
> Chris.
> 
> >
> >
> > --
> > Uma C.
> ___________________________________________________________________
> ______________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: Uma Chunduri <[email-masked]>
Date: Sun, 24 Aug 2014 07:15:51 +0000

Dear Chris, Stephane,

Thanks for a straight forward response and the motivation. My comments in-line [Uma]:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
...
...
	> Chris is right. There is explicit route preference rules established for IPv6 TLVs (RFC5308), old IPv4 (RFC 5302) 

[Uma]: Yes, I know that.. then why we should mix things for an aberration seen in the field for TLV 135 (TFC 5305) through this draft?

              > but unfortunately there's nothing in RFC5305 for extended IPv4 TLVs, 
 
 [Uma]: Absolutely. There is nothing currently defined route preferences for RFC 5305 or most predominantly used IPV4 reachability TLVS 135 as defined in RFC 5305.
               This is the point I want to highlight in the context of this draft.  There is a reason for "not having" any route preferences defined by removing the I/E bit in short metrics (TLV 128 etc..).

             > so implementators can reuse behaviors from 5308  or 5302 or none of them. 

[Uma]: Sorry, I fully disagree here. 
             Why should anybody re-use unrelated items  here? (if they do they should fix their  code not the specification, as it's not needed here).
             Extended TE reachability TLV 135 per RFC 5305 and TLV 235 (MT version for V4) per RFC 5120 semantics  are related and similarly 
             TLV 236 per RFC 5308 and TLV  237 (MT version of V6) per RFC 5120  are related.
             There is no confusion or lack of clarity to intermix things  here.

             >This, unfortunately, leads freedom for interoperability issues. IMO, It makes sense to clarify the behavior.

[Uma]: I don't think so. 
              In the name of clarity you CAN NOT create non-existent route preferences for  TE/MT-TE V4 TLVs 135, 235s because it's not needed and there are no semantics even if you wish (will write in the other thread).

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Sun, 24 Aug 2014 11:37:15 +0000

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:[email-masked]] 
Sent: Thursday, August 21, 2014 2:36 PM
To: [email-masked]; Christian Hopps; Uma Chunduri
Cc: Hannes Gredler; [email-masked] list
Subject: RE: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-route-preference-00

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

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 26 Aug 2014 01:53:10 +0000

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

> From: Uma Chunduri [mailto:[email-masked]]

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

> To: Les Ginsberg (ginsberg); [email-masked]; Christian

> Hopps

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

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

>     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

> To: [email-masked]<mailto:[email-masked]>; Christian Hopps; Uma Chunduri

> Cc: Hannes Gredler; [email-masked]<mailto:[email-masked]> list

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

> 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?).

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

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

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

> stated) and R1 is not.

>                              ============ 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

>                              This document defines the following route preferences for

> IPv6 routes

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

> inter-

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

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 26 Aug 2014 08:03:07 +0000

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

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

---

From: Christian Hopps <[email-masked]>
Date: Tue, 26 Aug 2014 09:08:09 -0400

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 <[email-masked]> 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.
> …
> [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!
>  
>                 >…
> [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.
>  
> [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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 26 Aug 2014 15:26:25 +0000

Uma -

Inline...

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

Dear Les,

FWIW -

LES: It's actually the opposite. RFC 5302 said to IGNORE the DOWN bit in L2 LSPs. The incorrect behavior is with the implementation that did NOT IGNORE and instead chose to treat the prefix w DOWN bit set as LESS PREFERRED.

It is TRUE that the implementation which does NOT follow RFC 5302 has a bug. As the draft explicitly says and what we have emphasized repeatedly is that we are NOT CHANGING IPv4 SPECIFICATION - simply clarifying. The only correction is to the IPv6 specification. You can  argue that clarification is not needed, but given that some experienced implementors did not interpret the spec consistently I disagree.

LES: I think the V4 spec benefits from clarification. The V6 spec is clear - but inconsistent from V4 - which is unjustifiable and (as Chris has stated) unintentional.

More in-line [Uma]:
--
Uma C.

To: Uma Chunduri; [email-masked]<mailto:[email-masked]>; Christian Hopps

Uma -

...

LES: For completeness we followed the model set out in RFC 5302 in this regard i.e. we define route types which are conceptually different but indistinguishable when looking at the encodings. This is why there is text in the draft such as:

<snip>

L1 intra-area routes: These are advertised in L1 LSPs, in TLV 135 or

   TLV 235.  The up/down bit is set to zero.  These IP prefixes are

   directly connected to the advertising router.  These routes are

   indistinguishable from L1 external routes.

   L1 external routes: These are advertised in L1 LSPs, in TLV 135 or

   TLV 235.  The up/down bit is set to zero.  These IP prefixes are

   learned from other protocols and are usually not directly connected

   to the advertising router.  These routes are indistinguishable from

   L1 intra-area routes.

<end snip>

If you object to this then you probably dislike RFC 5302 as well. :)

   Les

--

Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 27 Aug 2014 11:33:18 +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 [mailto:[email-masked]]
Sent: Tuesday, August 26, 2014 6:08 AM
To: Uma Chunduri
Cc: Christian Hopps; Les Ginsberg (ginsberg); [email-masked]; Hannes Gredler; [email-masked] 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 <[email-masked]<mailto:[email-masked]>> wrote:

Dear Les,

FWIW -

More in-line [Uma]:
--
Uma C.

Uma -

...

--

Uma C.