Subject: Re: Question regarding the P bit in type-7 LSA

From: Sunil Patro <[email-masked]>
Date: Fri, 10 Mar 2006 13:27:04 -0800

Hi Paul,

Please see inline.

> -----Original Message-----
> From: Mailing List [mailto:[email-masked]] On Behalf Of
Paul
> Wells
> Sent: Friday, March 10, 2006 12:21 PM
> To: [email-masked]
> Subject: Re: Question regarding the P bit in type-7 LSA
> 
> Hi Sunil,
> 
> Let me try to redraw your topology with the link between D and the
> backbone shown to make sure I understand your point:
> 
>    area 0   area 1   area 2
>              nssa     nssa
> A--------B--------C--------D
>           |       asbr      |
>           |                 |
>           +-----------------+
>                  area 0
> 
> In this case C generates type-7 lsas with the P bit set and floods
them
> to B and D in areas 1 and 2 respectively.  B and D will indeed
translate
> these into two separate type 5 lsas.  However, this is necessary given
> the topology, as these two lsas are not functionally identical
> (different transit areas).  If, say, D were to not do the translation
> for some reason, then the external routes would be unreachable if the
> B-C link went down.
> 

Type-7 to type-5 translation is done only if type-7 LSA has non-zero
forwarding addresses. So, what extra information does the type-5 LSA
generated by D give to area 0 routers? I would think area 0 routers will
get the same information from type-5 LSA whether it comes from B or D.
As I see, even if D did not do translation, external destinations will
be still reachable even if B-C link went down because area 0 routers
care about connectivity to ASBR (in this case C), which is in no way
dependent upon type-5 LSA generated by D.

Am I missing something here?

> In the case in which we're talking about resetting the P bit, the
> redundant type 5 lsas don't add any new information, since both would
> use the same area to reach the asbr.

	area 0      area 1   
			nssa
     A--------B--------C (NSSA translator)
     |       asbr      |
     | 		     |
     +-----------------+
	    Area 0

I am drawing the topology above (the case we are interested in for
resetting the P -bit) to visualize it better.

I see the obvious reason in the above case that database size will
become unnecessarily big because of C translating type-7 into a type-5,
which is the reason mentioned in NSSA RFC that multiple NSSA area border
translators are not recommended. Does the same reason apply to our case?

Thanks,
Sunil

> 
> Thanks,
> Paul
> 
> Sunil Patro wrote:
> > So, it looks like it is more of an optimization to reset the P bit
in
> > type-7 LSA in the case of an originated type-5 LSA also by the ASBR.
> >
> > But Acee, if you look at my example topology below, it still allows
for
> > a case where we could still land up with multiple type-5 LSA for the
> > same network even with the ASBR going by the RFC rules of resetting
the
> > P bit in type-7 LSA.
> >
> > Also, don't you think the statement of resetting the P bit in the
RFC
> > should be "SHOULD" instead of "MUST"?
> >
> > Thanks,
> > Sunil
> >
> >
> >>-----Original Message-----
> >>From: Mailing List [mailto:[email-masked]] On Behalf Of
> >
> > Acee
> >
> >>Lindem
> >>Sent: Wednesday, March 08, 2006 6:04 PM
> >>To: [email-masked]
> >>Subject: Re: Question regarding the P bit in type-7 LSA
> >>
> >>Vishwas Manral wrote:
> >>
> >>
> >>>Hi Sunil,
> >>>
> >>>Having multiple LSA's for the same destination are not very useful,
> >>
> >>though
> >>
> >>>they do not create a problem.
> >>>
> >>>The topology you refer to looks very interesting but may not ever
be
> >
> > that
> >
> >>>way in the real world.
> >>>
> >>>
> >>
> >>Hi Sunil,
> >>I agree with Vishwas. Additionally, since the non-translator
ABR/ASBR
> >>is the original source of the route, it makes no sense for the
> >>translating ABR to re-advertise it
> >>and will only delay convergence should connectivity to the
destination
> >>be lost.
> >>
> >>Thanks,
> >>Acee
> >>
> >>
> >>>Thanks,
> >>>Vishwas
> >>>
> >>>On 3/8/06, Sunil Patro <[email-masked]> wrote:
> >>>
> >>>
> >>>
> >>>>Does generating multiple type-5 LSAs for the same destination
> >
> > create
> >
> >>>>problem in any way? The same could happen if multiple ASBRs
generate
> >>
> >>type-5
> >>
> >>>>LSA for the same network.
> >>>>
> >>>>
> >>>>
> >>>>Coming back to the context again, consider the following network.
> >>>>
> >>>>
> >>>>
> >>>>       Area 0                      Area 1 (nssa)
> >>>>area 2 (nssa)
> >>>>
> >>>>
> >>
>
>>>A------------------------------B----------------------------------C--
-
> >
> > --
> >
> >>---------------------------------D
> >>
> >>>>
> >>>>
> >>>>Area 2's border router D can be either directly connected back to
> >
> > Area 0
> >
> >>>>again or through a virtual link.
> >>>>
> >>>>In this case, if C generates two type-7 LSAs for a network as an
> >
> > ASBR,
> >
> >>the
> >>
> >>>>type-7 will be translated to type-5 through B and D at the same
> >
> > time.
> >
> >>>>So, two type-5 LSA for the same network will end up in area 0. How
> >
> > is
> >
> >>this
> >>
> >>>>case handled then?
> >>>>
> >>>>
> >>>>
> >>>>Thanks
> >>>>
> >>>>Sunil
> >>>>
> >>>>
> >>>> ------------------------------
> >>>>
> >>>>*From:* Mailing List [mailto:[email-masked]] *On Behalf
> >
> > Of
> >
> >>*Vishwas
> >>
> >>>>Manral
> >>>>*Sent:* Wednesday, March 08, 2006 12:50 PM
> >>>>*To:* [email-masked]
> >>>>*Subject:* Re: Question regarding the P bit in type-7 LSA
> >>>>
> >>>>
> >>>>
> >>>>Hi Sunil,
> >>>>
> >>>>Acee may not be able to reply till the evening, so let me give it
a
> >
> > try
> >
> >>in
> >>
> >>>>the mean while.
> >>>>
> >>>>"If this is the case, the P-bit must be reset in the  type-7 NSSA
so
> >
> > the
> >
> >>>>type-7 LSA isn't again translated into a type-5 LSA by another
NSSA
> >
> > area
> >
> >>>>border router."
> >>>>
> >>>>Isnt the reason embedded in the question you ask?
> >>>>
> >>>>I guess we do not want to originate multiple Type-5 LSA's for the
> >
> > same
> >
> >>>>destination and that is the reason for the P-bit setting.
> >>>>
> >>>>Thanks,
> >>>>Vishwas
> >>>>
> >>>>On 3/8/06, *Sunil Patro* <[email-masked]> wrote:
> >>>>
> >>>
> >>>>From section 3.4 of rfc 1587(The OSPF NSSA Option),
> >>>
> >>>> "If a router is attached to another AS and is also an NSSA area
> >
> > border
> >
> >>>>  router, it may originate a both a type-5 and a type-7 LSA for
the
> >>>>  same network.  The type-5 LSA will be flooded to the backbone
> >
> > (and
> >
> >>>>  all attached type-5 capable areas) and the type-7 will be
flooded
> >>>>  into the NSSA.  If this is the case, the P-bit must be reset in
> >
> > the
> >
> >>>>  type-7 NSSA so the type-7 LSA isn't again translated into a
> >
> > type-5
> >
> >>>>  LSA by another NSSA area border router."
> >>>>
> >>>>
> >>>>Can someone throw some light on why the P bit must be clear in the
> >
> > case
> >
> >>>>when an ASBR originates both a type 7 and type 5 LSA for the same
> >>>>network?
> >>>>
> >>>>Thanks in advance.
> >>>>Sunil
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>

---

From: Paul Wells <[email-masked]>
Date: Mon, 13 Mar 2006 15:36:22 -0600

Hi Sunil,

Responses inline.

> Am I missing something here?

It's true that the type-7s and the translated type-5s will have 
forwarding addresses, however they will most likely be different 
forwarding addresses.  This is probably getting into implementation 
details, but I would expect that the type-7 lsa that C originates into 
area 1 will have a forwarding address in that area, and similarly for 
area 2.  The end result is that the two translated type-5s are not 
functionally identical.  One advertises a path through area 1 while the 
other is through area 2, just as if the forwarding address was not 
present and the advertising router id of the translator was used.

Note that the alternate abr behavior of rfc 3509 comes into play here as 
well.  In fact, the topology we are talking about is presented as figure 
2 in that rfc.  For implementations that follow 3509, C won't be 
originating summaries between area 1 and 2, so a forwarding address in 
the other area won't route through C.

>      A--------B--------C (NSSA translator)

I'm not sure I understand that last question.  In the above case, B is 
both an asbr and abr (3509 does not apply).  So, the type-5 originated 
by B into area 0 is sufficient for backbone routers.  For routers in 
area 1, the type-7 is sufficient.  If C were to translate the type-7 to 
a type-5 (with a forwarding address) I don't think it would give routers 
in the backbone any additional information about how to reach the 
external routes imported by B.

I think the basic goal remains keeping the lsdb as small as possible 
(but no smaller :-), especially since type-5/7 lsas can be quite 
numerous.  Or did I misunderstand your question?

Thanks,
Paul

---

From: Acee Lindem <[email-masked]>
Date: Mon, 13 Mar 2006 15:47:52 -0500

Hi Sunil,

>Am I missing something here?
RFC 3101, and it predecessor RFC 1587, both go to great pain to assure 
only one ABR
translates in order to avoid redundant advertisements. Why wouldn't an 
ABR not want to
take this relatively simple action (clearing the P bit) to avoid a 
duplicate advertisement?

Additionally, you could delay convergence in the situation where the 
external route
becomes unreachably due to the latency of the translating ABR running an 
SPF and
withdrawing the translated type 5 LSA.

Hope this helps,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Tue, 14 Mar 2006 01:06:36 -0500

Hi Paul,

I agree - one point to add inline.

Paul Wells wrote:

> functionally identical.  One advertises a path through area 1 while 
> the other is through area 2, just as if the forwarding address was not 
> Note that the alternate abr behavior of rfc 3509 comes into play here 
> as well.  In fact, the topology we are talking about is presented as 
> figure 2 in that rfc.  For implementations that follow 3509, C won't 
> be originating summaries between area 1 and 2, so a forwarding address 
> in the other area won't route through C.

For normal ABR behavior (RFC 2328), ASBR C will consider itself an ABR since
it is connected to multiple areas and should clear the P bit in the type 
7 LSAs
originated into NSSAs 1 and 2. Hence, neither ABR B nor ABR D will translate
them.

Thanks,
Acee

>>     area 0      area 1               nssa
> area 1, the type-7 is sufficient.  If C were to translate the type-7 
> to a type-5 (with a forwarding address) I don't think it would give 
> routers in the backbone any additional information about how to reach 
> the external routes imported by B.
>

---

From: Acee Lindem <[email-masked]>
Date: Tue, 14 Mar 2006 02:24:11 -0500

Acee Lindem wrote:

>> details, but I would expect that the type-7 lsa that C originates 
>> into area 1 will have a forwarding address in that area, and 
>> similarly for area 2.  The end result is that the two translated 
>> type-5s are not functionally identical.  One advertises a path 
>> through area 1 while the other is through area 2, just as if the 
>> forwarding address was not present and the advertising router id of 
>> the translator was used.
>>
>> be originating summaries between area 1 and 2, so a forwarding 
>> address in the other area won't route through C.
>
>
> it is connected to multiple areas and should clear the P bit in the 
> type 7 LSAs

I checked RFC 3101 and the criteria for mandatory clearing of the P bit is
dependent on whether or not a type 5 is originated as well (see excerpt 
below)
So, I was incorrect in saying that ASBR C would clear the P bit  :^)

   When an NSSA border router originates both a Type-5 LSA and a Type-7
   LSA for the same network, then the P-bit must be clear in the Type-7
   LSA so that it isn't translated into a Type-5 LSA by another NSSA
   border router.  If the border router only originates a Type-7 LSA, it
   may set the P-bit so that the network may be aggregated/propagated
   during Type-7 translation.  If an NSSA's border router originates a
   Type-5 LSA with a forwarding address from the NSSA, it should also
   originate a Type-7 LSA into the NSSA. 

I agree that originating type 7 LSAs into both areas is the correct
behavior and that the respective forwarding addresses will be different. 
Keep in mind that one or neither of the NSSAs will have an intra-area
route to the external route's next-hop address. When the next-hop 
address doesn't correspond to an NSSA intra-area route, the
forwarding address will be selected as specified in section 2.3 of
RFC 3101 (see excerpt below). 

   When a router is forced to pick a forwarding address for a Type-7
   LSA, preference should be given first to the router's internal
   addresses (provided internal addressing is supported).  If internal
   addresses are not available, preference should be given to the
   router's active OSPF stub network addresses.  These choices avoid the
   possible extra hop that may happen when a transit network's address
   is used.  When the interface whose IP address is the LSA's forwarding
   address transitions to a Down state (see [OSPF] Section 9.3), the
   router must select a new forwarding address for the LSA and then re-
   originate it.  If one is not available the LSA should be flushed.

Thanks,
Acee

>> I'm not sure I understand that last question.  In the above case, B 
>> is both an asbr and abr (3509 does not apply).  So, the type-5 
>> originated by B into area 0 is sufficient for backbone routers.  For 
>> routers in area 1, the type-7 is sufficient.  If C were to translate 
>> the type-7 to a type-5 (with a forwarding address) I don't think it 
>> would give routers in the backbone any additional information about 
>> how to reach the external routes imported by B.
>>