Subject: Re: Proposal to support dynamic capability negotiation of graceful restart

From: "Bruno Rijsman" <[email-masked]>
Date: Tue, 06 Aug 2002 14:43:08 -0400

Okay, no need to hold up the graceful restart draft for this if
it is that far along.

How about adding the text to the Dynamic Capability draft?

In general, what is the propor place for documenting "Dynamic
negotation of capabilty Foo"?  Is is the draft for Foo, the
dynamic capability negotiation draft, or some other place?

>From: Yakov Rekhter <[email-masked]>
>To: "Bruno Rijsman" <[email-masked]>
>CC: [email-masked]
>Subject: Re: Proposal to support dynamic capability negotiation of graceful 
>restart Date: Tue, 06 Aug 2002 11:23:55 -0700
>
>Bruno,
>
>If we are to insert the text you suggested below into the graceful
>restart draft, we would create dependency on the dynamic capacbility
>negotiation.  Please note that while graceful restart draft already
>passed the working group last call and is ready for the IESG last
>call, the dynamic capability negotiation didn't even pass the
>working group last call.
>
>Yakov.
>
> > All of the few people who responded to my question "should graceful
> > restart be dynamically negotiable" answered "yes" and they gave two
> > reasons:
> >
> > 1. It is convenient from an operational point of view to be able to
> >    enable graceful restart or to change the restart timer without
> >    needing to bounce the session.
> >
> > 2. What is the point of being able to dynamically advertise address
> >    families using multi-protocol dynamic capability negotiation if you
> >    cannot also dynamically advertise the ability to preserve forwarding
> >    state for those address families using graceful-restart dynamic
> >    capability negotiation?
> >
> > Thus, I'd like to propose that the following text be added to
> > draft-ietf-idr-restart:
> >
> > ---< Start of proposed text for draft-ietf-idr-restart >---------------
> >
> > X. Dynamic capability negotiation.
> >
> > The graceful-restart capability can be dynamically negotiated as
> > described in [dyn-cap].
> >
> > The < AFI, SAFI, Flags for Address Family > tuples in the graceful-
> > restart capability in CAPABILITY messages with action set to
> > "advertise" are not cummulative: the information in such an advertised
> > graceful-restart capability invalidates and replaces all of the
> > information in all graceful-restart capabilities in previously sent
> > OPEN and CAPABILITY messages.
> >
> > The graceful-restart capability in a CAPABILITY message with action set
> > to "withdraw" MUST NOT contain any < AFI, SAFI, Flags for Address
> > Family > tuples. If there are any < AFI, SAFI, Flags for Address
> > Family > tuples a NOTIFICATION message MUST be sent with error
> > code "CAPABILITY Message Error", error subcode "Malformed Capability
> > Value", and the offending graceful-restart capability in the data field
> > of the NOTIFICATION.
> >
> > A router which advertises the dynamic-capability-negotiation capability
> >
> > 1. MUST send an End-of-RIB marker when it completes sending the initial
> >    updates even if it has not received the graceful-restart capability
> >    from its peer at that point in time.
> >
> > 2. MUST be prepared to receive an End-of-RIB marker even if it has not
> >    advertised the graceful-restart capability to its peer at that
> >    point in time.
> >
> > This is to avoid confusion about the state of convergence if graceful
> > restart is dynamically renegotiated later on.
> >
> > Reference:
> >
> > [dyn-cap] draft-ietf-idr-dynamic-cap-02.txt
> >
> > ---< End of proposed text for draft-ietf-idr-restart >-----------------
> >
> >
>
> > _________________________________________________________________
> > Send and receive Hotmail on your mobile device: http://mobile.msn.com
> >

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 06 Aug 2002 11:52:36 -0700

Bruno,

> How about adding the text to the Dynamic Capability draft?

That would be much better.

> dynamic capability negotiation draft, or some other place?

It depends. For capabilities that are ahead (along the standards
track) of dynamic capability, documenting this should probably
go into either (a) dynamic capability negotiation draft, or (b)
a separate draft. For capabilities that would be behind the dynamic
capability documenting this should go into the capability draft.

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 12 Aug 2002 11:24:42 -0400

All strictly IMO:

> That would be much better.

I think it would be better to keep the dynamic capability draft
as simple as possible.  It should, however, discuss that for
each capability that can be dynamically altered that the
implications to the FSM and other issues must be documented.

> capability documenting this should go into the capability draft.

I'd suggest that, for "stable" features that are unlikely to get
an updated rfc any time soon that a ID be done to document the
relevant implications to that feature.  For features in need of
an update, it should go in the update.

-- 
Jeff Haas 
NextHop Technologies