Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type

From: Lili Wang <[email-masked]>
Date: Fri, 3 Jun 2011 10:58:44 -0400

Hi Richard,

   Sorry for the late reply!

Yes, this is a problem with the current spec.  We incorrectly convinced ourselves that such a check is not required.

Here's the proposed change.

We make sure the non-DR router have a synchronized database with the DR before advertising the Type 1 link to other non-DR router.
We declare the DR as a fully synchronized adjacency after having all the DR's LSA request satisfied (i.e., Our LSA update for the LSA requests are acknowledged by the DR.) in addition to having a full adjacency with the DR. 

The rule then will look like the following:  

o  If a router is not the DR and has a fully synchronized adjacency to the DR, it MUST add a Type 1 link corresponding to each neighbor that is in
state 2-Way or higher.

Tanks,

Lili
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Ogier
Sent: Tuesday, May 17, 2011 12:05 PM
To: [email-masked]
Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type

Section 3.6 of draft-nsheth-ospf-hybrid-bcast-and-p2mp-01
has the following rule:

o  If a router is not the DR and has a full adjacency to the DR, it
   MUST add a Type 1 link corresponding to each neighbor that is in
   state 2-Way or higher.

Suppose i and j are non-DR routers.  It seems to me that i should
also require that the DR's router-LSA include a link to j before
i adds a Type 1 link corresponding to j, in order to ensure that
i and j are fully synchronized before either uses the other as
a next hop.  Is there a reason why this condition was omitted?

To explain further, the SPT calculation (Section 16.1 of RFC 2328)
requires that router j advertise a link back to router i before i
can use j as a next hop (and vice versa). Thus, routers i and j can use
each other as a next hop if they both advertise a link to each other.

Therefore, the above rule from draft-nsheth only ensures that
routers i and j are fully adjacent with the DR before either can
use the other as a next hop.  As a result, the DR might not be fully
adjacent with router i or j, and thus i and j may not be fully
synchronized.  Note that full adjacency with a neighbor does not
imply that the link state databases are synchronized (see footnote 23
in RFC 2328).  It only means that the router is at least as
up-to-date as the neighbor, since it only means that all Link
State Requests have been satisfied.

Please correct me if I am mistaken.

Richard
_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: Richard Ogier <[email-masked]>
Date: Mon, 06 Jun 2011 20:49:46 -0700

Hi Lili,

Your proposed change assumes that the non-DR router knows when the
DR has finished sending LS request packets.  I am not sure this can
be assumed, since a router doesn't indicate when it is finished
sending LS request packets (and might not send any).
I think the only indication is when the DR declares the adjacency
to be Full when the LoadingDone event occurs (and adds the neighbor
to its LSA).

Even if the non-DR router determines via Database Description
packets that the DR has out-of-date LSAs, the DR could receive
those LSAs from another router.

It seems easier to just require that the DR's LSA include a link to
the router itself (router i in my example), or to the other non-DR
router j (which is what I used in my draft), before router i includes
a link to j in its router-LSA.  I prefer the latter because then
router i advertises a link to j only if router i is Full with the DR
and the DR is Full with router j.  Thus, by transitivity router i is
equivalent to being Full with router j (i.e., router i is as
up-to-date as router j).

Richard

---

From: Lili Wang <[email-masked]>
Date: Mon, 13 Jun 2011 09:10:17 -0400

Hi Richard,
 
   We agree with you.
Originally we thought about this approach but we later went for other approach. Now we think that this approach is more robust to make sure 
that router i and router j have synchronized database.  
We prefer the latter option, too.

Thanks,

Lili