Subject: Looking for comments on draft for RSVP Graceful Restart extensions (draft-rahman-ccamp-rsvp-restart-extensions-00.txt)

From: Reshad Rahman <[email-masked]>
Date: Wed, 04 Feb 2004 20:44:45 -0500

Hi,

This draft was presented at the MPLS WG during IETF 58 and there was 
some interest. However the recommendation was to move the draft to CCAMP. 

Tthe main comment/question was if we could reuse the RRO object instead 
of defining a new object to recover the contents of an ERO expansion 
done prior to control plane restart. Here are two potential issues with 
reusing RRO:
- The RRO would contain the full list of nodes whereas the ERO expansion 
may have been partial. In that situation the downstream node would 
detect a change in the incoming ERO and may reject the message (the 
expected behaviour on incoming ERO change seems to be unspecified).
- RRO uses Class-Number of form 0bbbbbbb, so if the downstream node 
doesn't support RRO, the whole message is rejected.

The draft also proposes a mechanism for a restarting node to detect 
whether its downstream neighbour is also restarting.

Comments welcome.

Regards,
Reshad.

-------- Original Message --------
Subject: 	I-D ACTION:draft-rahman-ccamp-rsvp-restart-extensions-00.txt
Date: 	Wed, 04 Feb 2004 15:41:46 -0500
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	IETF-Announce: ;

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: RSVP Graceful Restart Extensions
	Author(s)	: R. Rahman
	Filename	: draft-rahman-ccamp-rsvp-restart-extensions-00.txt
	Pages		: 9
	Date		: 2004-2-4
	
This document describes the extensions needed by certain 
             features for the purpose of RSVP Graceful Restart (defined 
             in[RFC3473]). One of these extensions refers to the ability of 
             a node to recover the ERO in the case it has performed an ERO 
             expansion before control plane restart. Also a small 
             modification is proposed in the basic procedure to support 
             simultaneous multiple node restarts in a network. 
             Specifically, a node should use a non-zero Recovery Time while 
             in the recovery phase. This allows a node to determine at 
             restart time if any of its neighbors has previously restarted 
             and it is currently in the recovery phase.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-rahman-ccamp-rsvp-restart-extensions-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: David Charlap <[email-masked]>
Date: Thu, 05 Feb 2004 10:53:19 -0500

> expected behaviour on incoming ERO change seems to be unspecified).

I hope it doesn't do this.

RSVP, by nature is a soft-state protocol.  Implementations should expect 
stuff to change all the time.  When an ERO changes, a node shouldn't 
reject the message.  It should use the new ERO to determine the new 
next-hop.

If the next hop doesn't change, then the node should leave the LSP in 
place and immediately generate a Path refres, so that downstream 
neighbors get the new ERO as soon as possible.

If the next hop changes, then it should be treated identically to what 
would happen in response to a route change with a loose ERO-hop or no ERO.

BTW, I noted that your draft allows an ingress node to recover more 
quickly.  This has been a hole in the GR procedure.  An ingress node 
that is computing an ERO can't re-compute that ERO until routing 
reconverges, and when it does so, there is no guarantee that it will 
compute the same ERO as before the failure.  It could store the ERO in 
non-volatile storage, but that can be problematic if there are thousands 
of LSPs originating.

Using the recovery-ERO object solves this.  The ingress node can then 
send out a Path (using the preserved forwarding state to know what the 
next-hop is) using an empty (or near-empty) recovery ERO.  The next-hop 
can then send back an immediate Resv containing an appropriate 
recovery-ERO, which the ingress node can use while waiting for routing 
to reconverge.  (Once routing reconverges and recovery completes, of 
course, it will want to compute its own ERO and possibly do a 
make-before-break to the new path if it ends up being better than the 
recovered path.)

> doesn't support RRO, the whole message is rejected.

If RRO isn't supported, then the ingress node will know about, since the 
LSP won't come up in the first place.

If this happens, then the upstream node will know that it can't use this 
method of ERO recovery.  Functionally, this is really no different from 
a node not supporting the recovery-ERO class.

Note that other RSVP extensions (like Fast Reroute) also require RRO 
support as a prerequisite.

-- David

---

From: Reshad Rahman <[email-masked]>
Date: Mon, 09 Feb 2004 12:16:12 -0500

Thanks for the response. Comments inline.

> I hope it doesn't do this.

I haven't seen anything wrt ERO change clearly specified in any of the RFCs. 

> a node not supporting the recovery-ERO class.

Yes. I was thinking of the case where the LSP hadn't initially been setup with
RRO. Adding RRO in the Path message may result in a PathError but the restarting
node can handle that. So it doesn't seem to be an issue.

> support as a prerequisite.

We're OK with using RRO to recover ERO, as long as there's agreement/consensus
on how to handle ERO change.

Regards,
Reshad.

---

From: David Charlap <[email-masked]>
Date: Mon, 09 Feb 2004 12:29:38 -0500

> I haven't seen anything wrt ERO change clearly specified in any of

Unfortunately, it isn't mentioned.  The consensus at the time of RFC 
3209's development was that make-before-break should be used for any 
rerouting.

Unfortunately, this ignores corner cases like when the route table 
changes, causing a loose-hop's next-hop to change.  How to process an 
ERO change seems (to me, anyway) to be related.

What I wrote (quoted below) is what I think makes the most sense.  It 
would be great if this could be codified so that everybody handles this 
the same way.  If some feel that my assumption is wrong, then this is 
something that should be discussed and codified afterwards.

>> RSVP, by nature is a soft-state protocol.  Implementations should
>> expect stuff to change all the time.  When an ERO changes, a node
>> shouldn't reject the message.  It should use the new ERO to
>> determine the new next-hop.
>> 
>> If the next hop doesn't change, then the node should leave the LSP
>> in place and immediately generate a Path refres, so that downstream
>> If the next hop changes, then it should be treated identically to
>> what would happen in response to a route change with a loose
>> ERO-hop or no ERO.

Note that I didn't describe what to do when a route-table change causes 
an LSP to reroute.  There are different approaches to this, but none are 
ideal.  All result in transient problems (LSP flapping, dropped packets, 
etc.)  This is why make-before-break is strongly preferred to changing 
an ERO in-line.

-- David