[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-ospf
Subject:    Re: NSSA question
From:       Roch Guerin <guerin () EE ! UPENN ! EDU>
Date:       2004-10-29 19:18:17
Message-ID: 41829779.6030600 () ee ! upenn ! edu
[Download RAW message or body]

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

> Hi Roch,
>
> ----- Original Message -----
> From: "Roch Guerin" <guerin@EE.UPENN.EDU>
> To: <OSPF@PEACH.EASE.LSOFT.COM>
> Sent: Friday, October 29, 2004 2:38 PM
> Subject: Re: NSSA question
>
>
>> 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.
>
>
> 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.
>
>
[prev in list] [next in list] [prev in thread] [next in thread]