Subject: Originating Type 5 LSAs with non-zero forwarding addresses

From: "Pat Murphy - (650)329-4044" <[email-masked]>
Date: Mon, 20 Mar 2006 09:49:49 -0700

When originating a Type 5 LSA its forwarding address should never be 
chosen from a stub or Not-So-Stubby-Area (NSSA), unless it is a 
translation of a Type 7 LSA. To do so would potentially cause traffic 
destined toward the Type 5 LSA's prefix to be black holed whenever that 
stub area or NSSA has multiple ABRs. There are several references in RFC 
2328 to the selection of a non-zero forwarding address that read...

  ...when the forwarding address field is non-zero, it should point
  to a router belonging to another Autonomous System.

I recommend the following minor rewording (errata)

  ...when the forwarding address field is non-zero, it should point
  to a router belonging to another Autonomous System and MUST be chosen
  from an area capable of flooding Type 5 LSAs. If no such address
  exists the forwarding address should be 0.0.0.0.

Two such references can be found in Section 12.4.4.1 and Footnote [24]. 
I don't think there are any others. It might also be worth adding to 
Appendix A.4.5. The exception is documented in RFC 3101.

Pat

---

From: Hasso Tepper <[email-masked]>
Date: Tue, 21 Mar 2006 13:42:14 +0200

Pat Murphy - (650)329-4044 wrote:
> stub area or NSSA has multiple ABRs. There are several references in
> RFC 2328 to the selection of a non-zero forwarding address that read...
>

Is anyone working on update to RFC2328? I just had discussion regarding 
architectural constants in RFC2328 appendix B and how much they are 
honoured nowadays. I'd really like to see update to avoid such 
discussions in the future :).

regards,

-- 
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator

---

From: Acee Lindem <[email-masked]>
Date: Tue, 21 Mar 2006 14:42:21 -0500

Hi Pat,
Agree with the update. Over the years, I've seen this bug fixed in several
implementations.

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Tue, 21 Mar 2006 14:48:34 -0500

>discussions in the future :).
Hi Hasso,

RFC 2328 is quite stable. We will incorporate the errata as part of 
going from DS (Draft Standard)
to PS (Proposed Standard). While many implementations have allowed 
modification of the
architectural constants (especially related to flooding), I'm not sure 
we need to document this since
the defaults haven't changed.

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Tue, 21 Mar 2006 15:17:44 -0500

See one correction below.
Acee Lindem wrote:

>> Is anyone working on update to RFC2328? I just had discussion 
>> regarding architectural constants in RFC2328 appendix B and how much 
>> they are honoured nowadays. I'd really like to see update to avoid 
>> such discussions in the future :).
>>  
>>
> Hi Hasso,
>
> to PS (Proposed Standard). 

Meant PS (Proposed Standard) to DS (Draft Standard).

> While many implementations have allowed modification of the