Hi Mike, 

> On Feb 28, 2024, at 11:59, Mike Fox <mj...@us.ibm.com> wrote:
> 
> Section 21.4.2 of RFC 2328 has a couple of seemingly contradictory statements 
> I am trying to reconcile. 
>  
> It says that a network LSA is only originated by the DR if the DR is fully 
> adjacent to at least one other router, and it includes itself in the list of 
> fully adjacent routers. 
>  
> But it also says that if a router is no longer the DR, it flushes the network 
> LSA by setting it to MAXAGE and flooding it.  However, in this case the 
> router may not be fully adjacent to any other routers. 

Section 14.1 of RFC 2328 is clear. You don’t need to re-originate the LSA, you 
simply set the LS age to MAXAGE and reflood it. So, you wouldn’t modify the 
sequence number, LS checksum,  or contents including the list of adjacent 
neighbors. 

        An LSA can be flushed from the routing domain by setting its LS
        age to MaxAge, while leaving its LS sequence number alone, and
        then reflooding the LSA.  This procedure follows the same course
        as flushing an LSA whose LS age has naturally reached the value
        MaxAge (see Section 14).  In particular, the MaxAge LSA is
        removed from the router's link state database as soon as a) it
        is no longer contained on any neighbor Link state retransmission
        lists and b) none of the router's neighbors are in states
        Exchange or Loading.  We call the setting of an LSA's LS age to
        MaxAge "premature aging".

Hope this helps, 
Acee          




>  
> The question that arises is:  should the router still include itself in the 
> list of attached routers when it’s flushing a network LSA because it’s no 
> longer DR, and it isn’t fully adjacent to any other routers?  My product has 
> been sending an empty attached routers list in this case, and recently 
> Wireshark has started flagging that as an error, saying the network LSA is 
> four bytes below the minimum size.
>  
> Mike Fox
> z/OS Communications Server 
> <https://www.ibm.com/products/zos-communications-server>
> IBM Enterprise Networking Solutions
> Research Triangle Park, NC USA
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org <mailto:Lsr@ietf.org>
> https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to