Subject: [Isis-wg] OSPF WG: Retstart: moving further was: [Re: draft-ietf-ospf-hitless-restart-00.txt, draft-ietf-idr-restart-00.txt]

From: Alex Zinin <[email-masked]>
Date: Tue, 27 Mar 2001 19:08:10 -0800

Danny:

Thanks for your thoughts, the message was a good break
in the middle of a battle... see my comments inline, please.

> IS-IS:

>   o "Restart signaling for ISIS" (draft-shand-ISIS-restart-00.txt),
>     which discusses restart and resync for IS-IS.

It must be noted that the discussion there was much more productive.

>     The IS-IS WG charter is quite dated as well...

> OSPF:

>   o "OSPF Restart Signaling" (draft-ietf-ospf-restart-01.txt),
>     which was the first of the OSPF proposals and triggered
>     [unfortunately] competing proposals to provide this
>     functionality.  This work falls into the "We'll accept
>     anything as a WG item" category".

Add draft-ietf-ospf-oob-resync-01.txt here.
This is a useful mechanism that is also used in our graceful
restart implementation to resync LSDB on restart.

>   o "Hitless OSPF Restart" (draft-ietf-ospf-hitless-restart-00.txt),
>     which is John's proposal and falls into the "we'll accept
>     anything as a WG item" category.  I guess this as well is
>     one of the benefits of having a charter with goals and
>     milestones as recent as Jun 98.

>   o I think an overhaul of the OSPF charter is necessary (have I
>     missed something in this area?).

As a message that I sent to the WG today tells, I also think the WG
charter should be updated.

> I'll not argue the merits of the two proposals (type 9's versus new
> bits in existing packets, resync, nsync, fairy dust, etc..), as I
> think they've pretty much been beat to death.  However, regardless of
> what some of the author(s) have said, I feel they could be merged into
> a single document and consensus reach in the WG based on the technical
> merits of each.

We are ready to work towards this.
This does require, however, that both sides are
willing to negotiate.

> Certainly, requirements documents would help to scope this discussion,
> as would up to date charters and milestones.  After all, I'd hope an
> associated requirements document would specify whether the additional
> functionality of Alex's proposal is interesting to the community.

> IMO, if we're planning to implement any of this, we might as well go
> ahead and provide a full set of capabilities (not that any one of them
> MUST be enabled in a network, mind you), as well as a common framework
> and architecture for NSF/headless routing.

I think it's doable and will have merit.
In fact, we have started working on something like this with
a number of folks... I think we can resume the effort and
come up with the requirement and framework documents.
Interested parties, please drop me a line.

Thanks again!

Alex.

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg