Subject: NSSA question

From: Roch Guerin <[email-masked]>
Date: Fri, 29 Oct 2004 13:43:23 -0400

Sorry to bug with a potentially irrelevant question, but I searched the
mailing list archive and could not find an answer to my question.

We have developed software that emulates network-wide routing decisions
in an OSPF network based on the LSAs received in each area, i.e., by
reproducing the routing table computations that would be performed at
each router, and that forces us to precisely account for all the
possible corner cases that one might encounter in various topologies.

In that context, I had a question regarding step (6)(e) of the routing
table calculation for Type 7 external routes, as it is described in
section 2.5 of RFC 3101.  Basically, I wanted to know if step (6)(e) was
carried out in parallel or as a follow-up to the other earlier steps of
(6), i.e., steps (6)(a) to (6)(d).  The latter steps are present in the
regular (non-NSSA) OSPF processing for external routes as specified in
RFC 2328, and step (6)(e) is a new one that is specific to NSSA and I
want to make sure I am interpreting it correctly.

Specifically, assume an NSSA that is connected to the backbone area
through two ABRs, ABR1 and ABR2, where ABR2 is also an ASBR.  Consider
now an external route reachable though ABR2 in its capacity as an ASBR,
and for which ABR2 specifies a non-zero forwarding address pointing to a
subnet inside the NSSA.  ABR2 would advertise a T7 with a non-zero
forwarding address and the P-bit clear in the NSSA (it already
advertises itself a T5 in the rest of the network) and a T5 with the
same non-zero forwarding address in the rest of the network.

ABR1 therefore has two functionally equivalent LSAs, a T7 and a T5, for
that route.  Assuming that RFC 1583 compatibility is disabled, when
reaching step (6)(c), ABR1 would prefer the intra-area (through the
NSSA) path to ABR2.  However, if I consider step (6)(e), unless I assume
that it is performed *after* step (6)(c), it says that ABR1 should
prefer the backbone path to ABR2 (the T7 from ABR2 does not have its
P-bit set, and so the T5 should be preferred).

My current understanding is that step (6)(e) is indeed performed *after*
step (6)(c) so that in the above example, ABR1 would select the path
through the NSSA to ABR2, but I wanted to confirm that this was indeed
correct.    Assuming it is the correct understanding, could someone give
an example of when step (6)(e) is actually used?

Thanks in advance.

Roch

---

From: Acee Lindem <[email-masked]>
Date: Fri, 29 Oct 2004 14:38:00 -0400

Hi Roch,

Long time no see - see inline.

----- Original Message -----
From: "Roch Guerin" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 29, 2004 1:43 PM
Subject: NSSA question

> possible corner cases that one might encounter in various topologies.

Please post a pointer to the list when you are ready to make this work
public (assuming it is being done under the auspices of the University
of Pennslyvania).

> want to make sure I am interpreting it correctly.

The precedence rules are meant to be performed in order.

> correct.

That is my interpretation as well.

>  Assuming it is the correct understanding, could someone give

Only when different ASBRs are advertising the same external prefix
and other route attributes are equal. Admittedly, it seems that it would
hard for (6)(e)(2) to ever come into play. You'd need to have two
ASBRs: one in an NSSA and one in a regular non-backbone area
advertising the same prefix and the one in the NSSA would need to
disable the setting of the P via policy (my implementation allows this
via the route map used for redistribution).

Am I missing anything? It's been a long week...

Good Luck,
Acee

---

From: Roch Guerin <[email-masked]>
Date: Fri, 29 Oct 2004 14:38:29 -0400

Another related question, but that this time results in a potentially
inconsistent behavior between RFC 3101 and RFC 2328 involves a similar
configuration as the one described below, namely, two ABRs, ABR1 and
ABR2, where ABR2 is also an ASBR, but now in addition to the backbone,
the two ABRs also share connectivity to two other non-backone areas, and
two make things easier, lets assume that both those other areas are NSSAs.

Because ABR2 is an ASBR that advertises itself its T5's in the rest of
the network, it sends T7's in both NSSAs with the P-bit clear.  But now
because the P-bit is clear, it seems that ABR2 is NOT required to set
the forwarding address to a non-zero value (see p.9 of RFC 3101, i.e.,

"If the P-bit is set, the forwarding address must be non-zero; otherwise it may be 0.0.0.0."

If that happens, then step (6)(e) is never invoked.  This would result
in the two paths between ABR1 and ABR2 being kept, obviously assuming
that they are equal cost.  This is inconsistent with the pruning based
on area ID that is specified in RFC 2328.

Should I therefore assume that RFC 3101 mandates that ABR2 always set
the forwarding address to a non-zero value if it is advertising a route
using both T7 and T5 LSAs?  I could not find language in RFC 3101 that
stated this requirement explicitly.

Thanks in advance,

Roch

> Sorry to bug with a potentially irrelevant question, but I searched
> the mailing list archive and could not find an answer to my question.
>
> We have developed software that emulates network-wide routing
> decisions in an OSPF network based on the LSAs received in each area,
> i.e., by reproducing the routing table computations that would be
> performed at each router, and that forces us to precisely account for
> all the possible corner cases that one might encounter in various
> topologies.
> section 2.5 of RFC 3101.  Basically, I wanted to know if step (6)(e)
> was carried out in parallel or as a follow-up to the other earlier
> steps of (6), i.e., steps (6)(a) to (6)(d).  The latter steps are
> present in the regular (non-NSSA) OSPF processing for external routes
> as specified in RFC 2328, and step (6)(e) is a new one that is
> specific to NSSA and I want to make sure I am interpreting it correctly.
>
> now an external route reachable though ABR2 in its capacity as an
> ASBR, and for which ABR2 specifies a non-zero forwarding address
> pointing to a subnet inside the NSSA.  ABR2 would advertise a T7 with
> a non-zero forwarding address and the P-bit clear in the NSSA (it
> already advertises itself a T5 in the rest of the network) and a T5
> with the same non-zero forwarding address in the rest of the network.
> ABR1 therefore has two functionally equivalent LSAs, a T7 and a T5,
> for that route.  Assuming that RFC 1583 compatibility is disabled,
> when reaching step (6)(c), ABR1 would prefer the intra-area (through
> the NSSA) path to ABR2.  However, if I consider step (6)(e), unless I
> assume that it is performed *after* step (6)(c), it says that ABR1
> should prefer the backbone path to ABR2 (the T7 from ABR2 does not
> have its P-bit set, and so the T5 should be preferred).
>
> My current understanding is that step (6)(e) is indeed performed
> *after* step (6)(c) so that in the above example, ABR1 would select
> the path through the NSSA to ABR2, but I wanted to confirm that this
> was indeed correct.    Assuming it is the correct understanding, could
> someone give an example of when step (6)(e) is actually used?
>
> Thanks in advance.
>
> Roch

---

From: Acee Lindem <[email-masked]>
Date: Fri, 29 Oct 2004 15:08:22 -0400

Hi Roch,

----- Original Message -----
From: "Roch Guerin" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 29, 2004 2:38 PM
Subject: Re: NSSA question

> stated this requirement explicitly.

I think the assumption from RFC 3101 doesn't take this case into account.

          Since a Type-7 LSA only has area-wide flooding scope, when its
          forwarding address is set to 0.0.0.0, its ASBR's routing table
          entry must be chosen from the originating NSSA.  Here no
          pruning is necessary since this entry always contains non-
          backbone intra-area paths.

I must admit that in one implemenation that I worked on I added a knob to
allow ECMP routes for AS externals to be calculated through multiple areas.

---

From: Roch Guerin <[email-masked]>
Date: Fri, 29 Oct 2004 15:18:17 -0400

Acee,

Thanks.  This is a bit of a corner case and it may not happen that often
but it indeed seemed that RFC 3101 had left this case open to
interpretation and therefore to different implementations.  We'll be
testing a couple of different implementations to see how they behave for
this particular configuration and I'll report what we find, but I'd be
interested in any data on how other implementations handle it.
Thanks,

Roch