Subject: Re: Highly Available OSPF Router.

From: [email-masked]
Date: Mon, 16 Feb 2004 01:38:59 -0600

Vishwas,

I did take a look at the links that you provided. I am sorry but
I couldn't figure out what specifically on those site you are 
referring me too.

Regards
Mukesh

> -----Original Message-----
> From: Mailing List [mailto:[email-masked]]On Behalf Of ext
> Vishwas Manral
> Sent: Sunday, February 15, 2004 11:29 PM
> To: [email-masked]
> Subject: Re: Highly Available OSPF Router.
> 
> 
> Hi Mukesh,
> 
> This thing is not OSPF specific at all, and can be done 
> applications. As Dave said its pretty standard stuff done by 
> a lot of vendors, why dont you have a look at the link I provided?
> 
> Thanks,
> Vishwas
> 
> -----Original Message-----
> From: Mailing List [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Monday, February 16, 2004 12:56 PM
> To: [email-masked]
> Subject: Re: Highly Available OSPF Router.
> 
> 
> Thanks for the quick responses :)
> 
> Ok let me take the word "standardized" back !
> 
> I meant to ask "will it be useful to write an informational
> document on how to do this implementation trick for OSPF" ?
> I am sure every implementor will have to think about the same
> issues like:
> 
> - what are the tasks that are just performed by the Master and
>   not by the backups.
> - How to synchronize the initial state between the master and 
>   the member.
> - How to keep the state in sync.
> - What actions to perform at the time of the swithover (master
>   dying and backup taking over).
> etc. etc.
> 
> Why not write a document and make it easier for everyone ??
> 
> Regards
> Mukesh
> 
> > -----Original Message-----
> > From: Mailing List [mailto:[email-masked]]On 
> Behalf Of ext
> > Dave Katz
> > Sent: Sunday, February 15, 2004 11:19 PM
> > To: [email-masked]
> > Subject: Re: Highly Available OSPF Router.
> > 
> > 
> > I suspect a number of folks are working on things like this.
> > 
> > However, the way you describe it says that it in fact is not 
> > subject to
> > standardization, since it does what it does without the neighbors
> > realizing (nothing outside the "black box.")  Therefore it 
> is only an
> > implementation trick, not something to be standardized.
> > 
> > --Dave
> > 
> > On Sunday, Feb 15, 2004, at 23:03 US/Pacific, [email-masked]
> > wrote:
> > 
> > > Has anyone implemented an OSPF HA where two or more OSPF routers
> > > appear as one OSPF router to the OSPF neighbors. One of 
> the routers
> > > (the Master) talks to the external world (OSPF neighbors) and the
> > > others (the Backups) keep all the dynamic OSPF state (neighbors,
> > > database etc) in sync with the Master. When the Master 
> dies, one of
> > > the backup router takes over immediately without the neighbors
> > > realizing any change in the network ?
> > >
> > > If anyone has implemented any such thing, I would like to 
> hear about
> > > how they do it. I would also like to know if the WG would 
> > be interested
> > > in standardizing such a mechanism ? At least I think that 
> it will be
> > > a useful thing !!
> > >
> > > Regards
> > > Mukesh
> > >
> > 
>

---

From: Hari <[email-masked]>
Date: Mon, 16 Feb 2004 00:28:34 -0800

Hi Mukesh,
  Though I'm not sure of the generality of the solutions I agree with
Mukesh in having an "informational document for High available OSPF".
  It helps any one trying to build HA-OSPF to have atleast some design
directions

BTW I think Vishwas is referring to commercially available HA-OSPF
implementations. If that is the case the following links might be
useful.
http://mcg.motorola.com/netplane/releases/01282002-1.htm
http://www.dataconnection.com/iprouting/ospf.htm

Thanks,
Hari

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Sunday, February 15, 2004 11:39 PM
To: [email-masked]
Subject: Re: Highly Available OSPF Router.

Vishwas,

Regards
Mukesh

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 16 Feb 2004 16:42:29 +0100

>  It helps any one trying to build HA-OSPF to have atleast some design
i) IETF is not the forum for such a document really. It governs
'behavior between
    boxes'. That's for a good reason.
ii) Implementation details change from architecture to architecture
drastically and
    your document, even best written and well-ment, has a very high
chance to cause
    more confusion than help, since the interpretation of what you wrote
may cause
    implentors to take completely wrong decisions for their
architecture.  E.g., if a
    box has extremely slow between blades-communication, your document may
    cause complete havoc to a system. Another example, if a box
distributes hello
    state machines on different blades than topology maintainance, your
document
    is hard to interpret. That assuming you write 'put OSPF on two
different blades and
    sync them up using some kind of internal protocol'.
iii) Nobody can prevent you from publishing an informational and way worse
    things made it into an 'informational' ;-))

    -- tony