Subject: [Isis-wg] Handling of asymmetric 2^24-1 link metrics.

From: Saku Ytti <[email-masked]>
Date: Wed, 11 May 2011 22:19:52 +0300

Consider this topology

  A----B----C
  |             |
  +-----------+

A, B, C are routers.

A -> B has metric of 2^24-1
A<->C is symmetrically 300
Rest are 100 (i.e. B->A is 100)

B is running JunOS.
A and C are running IOS (or anything else but JunOS really)

B want to send packet to A.

Now JunOS as per design (And they're not going to change it) seeing
A->B is 2^24-1 also excludes B->A from SPF.

So B sends packet towards C, C which is running IOS (correctly)
understands that C->-B->A is 200, which is better than C->A 300, and
sends packet back to B, causing loop.

I think this is broken, I think ISIS inherently is not symmetric, and
it does not matter what the return metric is at all, and I'm baffled
anyone implementing ISIS could come into such understanding. Is there
anything I can do, to convince Juniper that they need to fix their
implementation and only look forward metrics. Since their official
statement is that it is matter of interpretation and they are not
going to change it. My view is, that it is simply wrong and if you
understood standard like this, you misunderstood it.

The example might be corner case, I don't still feel there should be
need to justify it, but maybe A-C is low capacity and A-B is high
capacity and A has highly asymmetric need for capacity and there is
huge packet loss in A->B direction.

-- 
  ++ytti

---

From: "Chen, Jay (Jay)" <[email-masked]>
Date: Wed, 11 May 2011 22:42:51 -0500

Very interesting. I think what is happening here is due to the bidirectional check. From forwarding point of view, there is no bidirectional forwarding path between these two nbr. There is a forwarding path from B->A, but not A->B because of the max metric. The step 3. of SPF computation will not add A (B's neighbor) to the tent for the reason of bidirectional check, as a result B->A will also be excluded from SPF.
   
Jay 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Saku Ytti
Sent: Wednesday, May 11, 2011 12:20 PM
To: [email-masked]
Subject: [Isis-wg] Handling of asymmetric 2^24-1 link metrics.

Consider this topology

  A----B----C
  |             |
  +-----------+

A, B, C are routers.

B is running JunOS.

So B sends packet towards C, C which is running IOS (correctly) understands that C->-B->A is 200, which is better than C->A 300, and sends packet back to B, causing loop.

I think this is broken, I think ISIS inherently is not symmetric, and it does not matter what the return metric is at all, and I'm baffled anyone implementing ISIS could come into such understanding. Is there anything I can do, to convince Juniper that they need to fix their implementation and only look forward metrics. Since their official statement is that it is matter of interpretation and they are not going to change it. My view is, that it is simply wrong and if you understood standard like this, you misunderstood it.

The example might be corner case, I don't still feel there should be need to justify it, but maybe A-C is low capacity and A-B is high capacity and A has highly asymmetric need for capacity and there is huge packet loss in A->B direction.

--
  ++ytti
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Saku Ytti <[email-masked]>
Date: Thu, 12 May 2011 07:00:57 +0300

> Very interesting. I think what is happening here is due to the bidirectional check. From forwarding point of view, there is no bidirectional forwarding path between these two nbr. There is a forwar…

Indeed, it is due to bidirectional check. But then question is, should
this be done, or should it not be done. As obviously vendors should
have same opinion of this to avoid loops.

My understanding is that there is nothing in ISO10589 or RFC1195 which
raises special case on 2^24-1 and enforces bidirectional exclusion.

It adds complexity and it reduces expressiveness of the protocol.
Operator can always emulate the behavior by configuring 2^24-1 on both
sides of the link. Who is to say, that there can't be situation where
it is desirable to exclude link from SPF for only one direction.

-- 
  ++ytti

---

From: Saku Ytti <[email-masked]>
Date: Wed, 18 May 2011 09:35:50 +0300

Any comments from the list about interpretation of the standards?
After all this is practical problem in deployed networks which causes
loops in correctly configured devices. Either this is explicitly
mentioned in the standards and I've missed it, or then it has to be
written down more explicitly so we can converge vendors into single
behavior.

Thanks,

-- 
  ++ytti

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 18 May 2011 17:26:25 +0200

On Wed, May 11, 2011 at 10:19:52PM +0300, Saku Ytti wrote:
| I think this is broken, I think ISIS inherently is not symmetric, and
| it does not matter what the return metric is at all, and I'm baffled
| anyone implementing ISIS could come into such understanding.

looks like the implementor has made a deliberate choice to treat a
MAX_METRIC link the same way as a non-exististent link.

| Is there anything I can do, to convince Juniper that they need to fix their
| implementation and only look forward metrics. Since their official
| statement is that it is matter of interpretation and they are not
| going to change it. My view is, that it is simply wrong and if you
| understood standard like this, you misunderstood it.

rather than insisting what is right or wrong (considering that
we are in the greyzone of 3-fold revised, 20+ year old specs),
perhaps you can just ask tech-support for a knob to only consider
forward-metrics. That way vendors do not surprise its installed
base customers and also fix what seems to be an issue for you.

tx,

/hannes

---

From: Saku Ytti <[email-masked]>
Date: Wed, 18 May 2011 19:29:34 +0300

> base customers and also fix what seems to be an issue for you.

Thanks for your thoughts Hannes. If both are desirable operating modes
then just like LSP MTU, you'd just make sure that single ISIS network
shares this setting. I'm happy to submit ER and PERS to my vendors of
choice to allow interoperability.

But if there is no practical usage scenario for both methods of
operation, maybe graceful phaseout would be more desirable
(automatically adding old behavior in configs during upgrade, later
removing completely). As adding gratuitous functions to protocol seems
suboptimal, adding complexity which means more software defects down
the line.

I just want to be sure I'm asking for the right thing from the right parties.
-- 
  ++ytti