On Thu, 2015-01-08 at 17:55 +0800, Lu Feng wrote: > Hi Joakim, > > Yes of course I remember it. We have no agreement on it, and no other voice > appears on it. So I send the 6WIND approach as a candidate. :)
aha, competition :) > > My answers are inline: > > On 1/8/15, Joakim Tjernlund <[email protected]> wrote: > > Hi Feng > > > > I remember this one, I sent a patch long time ago which we even discussed > > :) > > See http://patchwork.quagga.net/patch/537/ > > > > Yours is a bit different though: > > 1) at least PtoP links needs the same as virtual links. > > Please refer to the function ospf_nbr_key(), only VL nbr has a special way of > building the key. That is, there's no need to treat the ptp nbr specially. Yes now I remember. There is another patch from me that corrects this, remember http://patchwork.quagga.net/patch/964/ ? Better to include ptop now so it will work later on. > > > W.r.t to your comment on my patch, do you really want to keep DR/BDR info > > when > > RouterID has changed? Can DR/BDR may change as a result of changing > > RouterID? > > According to RFC2328, the router ID is allowed to change without changing > the DR/BDR. That is, no mechanism is defined to trigger the DR-election if > some OSPF router on a broadcast network changes its router ID. > > If we rebuild the self_nbr, the DR/BDR will be lost, and hence it will cause > problems in generating network-LSA and routing calculation and maybe others. > Moreover, I don't know what will happen if it keeps DR/BDR empty in Hello > packets. > > Another reason is, on non-VL interfaces the nbr key is not the router ID. OK, just wanted to make sure. > > > > > 2) You have an extra oi->nbr_self = ospf_nbr_new (oi), is that needed? > > I think yes. The function ospf_nbr_add_self() does not allocate the memory > for nbr_self. We must allocate it explicitly. yes, so it seems. Jocke _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
