Subject: Re: Restart signaling, DR/BDR, and RouterDeadInterval

From: "Manral, Vishwas" <[email-masked]>
Date: Fri, 10 May 2002 13:42:46 -0400

Mitchell,

I guess the "restart signaling" draft is now located at
http://www.ietf.org/internet-drafts/draft-nguyen-ospf-restart-00.txt

Though Alex, or some other draft author would give the exact details, I
think this draft does not bother about keeping DR state, so if a DR router
goes down, and comes up it may no longer be the DR after the DR election.
Things I guess work as per the base RFC2328.

Acee,

Thanks for the information. (However I don't remember asking a question
related to this. ;-))

Thanks,
Vishwas

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]]
Sent: Friday, May 10, 2002 9:07 PM
To: [email-masked]
Subject: Re: Restart signaling, DR/BDR, and RouterDeadInterval

Michelle, Manral,

There are two hitless restart drafts. Although I was not at
the specific meeting, the one below is the one that was accepted
by the OSPF work group.

http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-02.txt

IMHO, it does address your questions although there is
currently no provision for a restart that doesn't proceed within
the router dead interval. We are considering this for our
implementation.

Erblichs wrote:
> OSPF Restart Signaling.. Feb01 to Sept01
>
> Hi Group,
>
>         I didn't see if this became a standard, so
>         this clarification / question could be moot..
>
>         Just thinking of the proper way to code
>         this..
>
>         I assume that if a hello is recieved from
>         a restart router within the RouterDeadInterval
>         timeframe, then there is significantly less
>         work... There was no intervening teardown..
>
>         However, what is not mentioned, and I want to
>         clarify this..
>
>         Assume both routers support Restart..
>         If the restarting router was the DR or the BDR,
>         there is no assumption that if the restart was
>         done WITHIN the RouterDeadInterval timeframe,
>         the adjacency is still up, that a restarting
>         router would stay the BDR or DR...
>
>         Assume both routers support restart..
>         Else, NOT WITHIN the RouterDeadInterval timeframe.
>         We have to assume that there was a intervening
>         election. Would we do another election?
>
>         There is no mention of election effects / side-effects
>         with respect to the restarting router, when all or
>         some routers support restart? The non-restart supported
>         routers would force a re-election.
>
>         Thanks,
>                 Mitchell Erblich
>

--
Acee

---

From: Suvani Kaura <[email-masked]>
Date: Fri, 10 May 2002 11:24:42 -0700

Hi All,

From reading RFC2328 (sections 8.1, 7.1 & 9.5), I interpreted that
hello packets sent in point to multipoint mode should be sent
directly to each of the neighbors as unicasts.  However, I recently
saw a commercial router send hellos to the AllSpfRouters multicast
address.  Which is the correct way?

Thanks in advance,
Suvani

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Mother's Day is May 12th!
http://shopping.yahoo.com

---

From: Alex Zinin <[email-masked]>
Date: Fri, 10 May 2002 16:36:55 -0700

Suvani,

  What you're seeing is broadcast emulation where
  the lack of broadcast capability of the cloud is
  hidden from the routing layer by replication of
  IP-multicast packets performed by the device driver.

  Following the tradition of referring people to books,
  please see section 9.2.9.4 of "Cisco IP Routing: Packet
  Forwarding & Intra-domain Routing Protocols" :)

--
Alex

---

From: Acee Lindem <[email-masked]>
Date: Mon, 13 May 2002 09:46:19 -0400

Suvani,

RFC 2328 (which is a standards track RFC) is correct. However,
if you're implementing OSPF you'll need to adhere to Jon Postal's
advice and "be liberal in what you accept from others". Most
implementations support point-to-multipoint packets sent both to your
unicast address and the OSPF multicast addresses.

>   IP-multicast packets performed by the device driver.

Alex,

Conceptually, it doesn't seem that this is correct since
OSPF doesn't view the network topologically as a broadcast
network (i.e., fully meshed). Oh well, it is a moot point.

--
Acee

---

From: Suvani Kaura <[email-masked]>
Date: Mon, 13 May 2002 07:48:03 -0700

Thanks, Acee & Alex.

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

---

From: Alex Zinin <[email-masked]>
Date: Mon, 13 May 2002 10:51:33 -0700

Acee,

> network (i.e., fully meshed). Oh well, it is a moot point.

In fact, there are two modes: pure broadcast emulation,
and p2mp with broadcast emulation. In the former case OSPF
has no idea it's NBMA, the driver performs packet
replication, but the admin needs to make sure there's
any-any connectivity between nodes. In the latter case
everything is like in p2mp except for the dst address
and that you don't have to configure OSPF neighbors
manually.

Alex

---

From: Ash he <[email-masked]>
Date: Mon, 13 May 2002 12:04:28 -0700

I agree with Alex. Routers do support broadcast
emulation (pseudo-broadcast as cisco terms it) on P2P
interfaces in much the same way. Its the view that the
interface offers to OSPF i.e. P2mP or broadcast. In
the
broadcast mode OSPF would behave as though it were
using an ethernet. Full/selective meshing would be
a configuration issue.