Subject: [Isis-wg] up/down bit confusion

From: apoorv kulshrestha <[email-masked]>
Date: Wed, 15 Feb 2006 18:20:35 +0530

Hi,

As per rfc 2966, section 2:

" A simple extension would be to allow a L1L2 router to advertise
routes learned via L2 routing in its L1 LSP. However, to prevent
routing-loops, L1L2 routers must never advertise L2->L1 inter-area
routes that they learn via L1 routing, back into L2. Therefore, there
must be a way to distinguish L2->L1 inter-area routes from L1
intra-area routes. Draft-ietf-isis-traffic-01.txt defines the "up/down
bit" for this purpose.
...
L1L2 routers must set this bit to one for prefixes that are derived
from L2 routing and are advertised into L1 LSPs. The bit must be set
to zero for all other IP prefixes in L1 or L2 LSPs."

Ok there can be formed, routing loops. As per my understanding, it
will create problem only if the original IS which advertised the
prefix (to which advertised prefix is directly connected) goes down
(or that interface to which prefix is connected goes down). Otherwise
it would be like

A --- B--- C              (all are L1L2 systems)
                 |
              prefix X
At C, L2 LSP contain route to prefix X (directly connected), metric 10.
At B, L2 LSP contain route to prefix X due routing loop, metric 20.
At A, in L2 SPF, both LSP will result in route to prefix X with metric
30 and B as next  hop (same next hop, so ECMP also will not arise).
So, in normal operation, there should not be any problem due to L2
->L1 route leakage. But if interface on C to which prefix X is
connected, goes down, a 'count to infinity' sort of problem will come
up.

Now, my confusions are:
1. This problem will be with L1->L2 leakage also, but in the proposed
solution to break routing loops, ie, up/down bit, it is not possible
to distinguish between L1->L2 leaked route (has up/down bit set to up,
ie, 0) and L2 routes (has up/down bit set to reserved, ie, 0). How to
break routing loop in that case?
2. Am I correct in my understanding? Or are there some more issues due
to routing loop in normal operation also?

Please help.

Regards and thanks,
Apoorv

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

---

From: Henk Smit <[email-masked]>
Date: Wed, 15 Feb 2006 16:17:55 +0100 (CET)

Some remarks inline.

> At B, L2 LSP contain route to prefix X due routing loop, metric 20.

  I'm not sure I understand that sentence.
 There will be no routing loop.
 B will see prefix X twice in its databases. Once in the L1 LSPDB and
 once in the L2 LSPDB. B will find 2 paths to X, one via L1 SPF and
 one via L2 SPF. However, DIFFERENT TYPES of routes have DIFFERENT
 PREFERENCES. In this case, the L1 route will always be preferred over
 teh L2 routes, regardless of the cost of the path.

> 30 and B as next  hop (same next hop, so ECMP also will not arise).

  ECMP will not arise because the L1 route to X as advertised by C will
 be preferred to the L2 routes that can be derived from advertisements
 in B's or C's L2 LSP.

> connected, goes down, a 'count to infinity' sort of problem will come

  I hope not.
 First there is the difference in preference in route types.
 Secondly, the up/down bit will shorten the maximum "path of advertisement"
 to L1->L2->L1. After that the prefix can not be advertised back up.

> break routing loop in that case?

  Pure L1 routes are to be preferred over L2->L1 routes.
 That should prevent counting to infinity.
 There can be short periods of time where a L1 route will go away, and
 then the L1 routes can still see the L2->L1 route advertised back into
 the area. However 1) this should usually not happen as the L1L2 routers
 of that area will not have that prefixes installed in their globabl RIB
 as L2 route, but as a L1 route. So they won't advertise the L1 route
 back into their L1 LSP anyway. And secondly, if they do, after their
 next SPF they will realize that the prefix went away, and regenerate their
 L1 LSP, without that prefix.

> to routing loop in normal operation also?

  No, I think you are missing a few things.
 It's not trivial.
 But the issues you bring up should not happen.

  Hope this helps,

         Henk.

---

From: apoorv kulshrestha <[email-masked]>
Date: Thu, 16 Feb 2006 14:07:37 +0530

Hi,
I missed to specify one thing in the routing loop scenario I discussed:
A --- B--- C              (all are L1L2 systems)
                |
             prefix X
"At C, L2 LSP contain route to prefix X (directly connected), metric 10.
At B, L2 LSP contain route to prefix X due routing loop, metric 20.
At A, in L2 SPF, both LSP will result in route to prefix X with metric
30 and B as next  hop (same next hop, so ECMP also will not arise).
So, in normal operation, there should not be any problem due to L2
->L1 route leakage. But if interface on C to which prefix X is
connected, goes down, a 'count to infinity' sort of problem will come
up."

Here all A, B and C are in differnet areas.

At B, L2 LSP containing route to prefix X is recieved and it will
participate in L2 SPF.
Due to L2->L1 route leakage, L1 LSP will list routes resulted from L2
SPF which will include route to prefix X. This L1 LSP will take part
in L1 SPF, and thus L1 SPF will also result in route to prefix X.
Now, while building L2 LSP B will take L1->L2 routes also, ie routes
learned via L1 SPF which contain route to prefix X. Thus L2 LSP of B
will also contain prefix to X.

Preference order is involved in building routing table only. While
building LSP of one level, it will simply take routes which it learned
from other level SPF. And both level SPF will give a route to prefix
X, so it will be in both LSPs - L1 and L2.

So now B and C both are advertising route to prefix X in their LSP. So
a routing loop is formed. However it should create problem only when
interface of C connected to prefix X goes down.

To break this loop, RFC 2966, suggests use of up/down bit to
distinguish L2->L1 route, so that we can discard them while building
L2 LSP.
But the problem is what about reverse situation, L1->L2->L1 loop?

Regards,
Apoorv

---

From: Henk Smit <[email-masked]>
Date: Thu, 16 Feb 2006 11:28:12 +0100 (CET)

> Here all A, B and C are in differnet areas.

  So this is the biggest change with the scenario you described in
 your previous email ?

> in L1 SPF, and thus L1 SPF will also result in route to prefix X.

  At B ?
 I don't think so. When you do an SPF computation, you start by doing
 two things. 1) Either put all your neighbors on the PATHS list first.
 This will ensure you will not compute routes from your own LSP.
 Or 2) you put your own LSP on the PATHS list first. But then you
 must skip the IP prefixes in that LSP. There is no point installing
 routes in the routing table that you learned from your own advertisements.

> will also contain prefix to X.

  First of all you, in the above scenario should never see that prefix
 X as a L1 route on B or A. Secondly, a general rule of thumb, which
 holds true for most routing protocols is: you should never advertise
 a route you are not using yourself !
  Third of all, the prefix that B put in its L1 LSP will have the
 up/down bit set ! It must. So therefor even if B would compute L1 SPF
 and would see a L1 route to X, it is not allowed to include that
 prefix back into its L2 LSP.

> from other level SPF.

  No, there is nothing "simply". There's all sorts of conditions.
 Which I will not re-list here.

> And both level SPF will give a route to prefix

  No. B will not put prefix X in its L2 LSP. Never.

> So now B and C both are advertising route to prefix X in their LSP.

  B (and A) will never advertise X in their L2 LSP.

> So

  No. Your implementation needs to use a few simple old rules.
 Don't listen to your own route advertisements. (In the case of a
 Linkstate routing protocol: don't pick up routes from your own LSPs).
 And: don't advertise a route you don't use yourself.

  The up/down bit was introduced for network topologies where
 you have a backbone, and 2 L1 areas, where each area is connected
 by 2 L1L2 routers. That is where consistent routing loops could
 occur. That is where the up/down bit solves a problem.

> But the problem is what about reverse situation, L1->L2->L1 loop?

  If you use the above 2 general rules, you will see that the addition
 of the up/down bit takes away those problems.

     Henk.