Subject: Short additional working group last call on draft-ietf-ccamp-rsvp-restart-ext-03.txt

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 12 Aug 2005 12:29:39 +0100

Hi,

As mentioned by Arun in his email (below),
draft-ietf-ccamp-rsvp-restart-ext-03.txt has been marked up after working
group last call.

At the same time, the authors made a minor functional change to the
protocol extensions to handle a potential scaling issue.

This email starts a short, additional working group last call on the I-D.
Since the draft has already been through last call, I expect you to focus
on the new material only.

The last call will end on Sunday 21st August at 12 noon GMT.

Thanks,
Adrian

----- Original Message ----- 
From: "Arun Satyanarayana" <[email-masked]>
To: <[email-masked]>; "Adrian Farrel" <[email-masked]>; "Kireeti
Kompella" <[email-masked]>
Cc: "Lou Berger" <[email-masked]>; "Dimitri Papadimitriou"
<[email-masked]>; "Reshad Rahman" <[email-masked]>;
"Anca Zamfir" <[email-masked]>; "Junaid Israr" <[email-masked]>; "Arun
Satyanarayana (asatyana)" <[email-masked]>
Sent: Sunday, July 24, 2005 4:33 AM
Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-03.txt

> Hi all,
>
> Version -03 is the updated version resulting from last-call comments.
>
> A scalability concern was raised, where, the restarting node does not
> support the mechanism in this I-D, but, one or more RSVP neighbors do.
> This would result in unnecessary generation (and possible
> retransmission) of RecoveryPath msgs by the neighbors, and, receive
> processing of the RecoveryPath msg until the restarting node has to
> decide to drop it. This may be a scalability issue when a large number
> of LSPs are active on the restarting node.
>
> The solution is to indicate the capability to transmit and receive
> RecoveryPath msgs with 2 new bits in the Capability object.
>
> Note: The above solution also addresses a similar concern raised
> earlier, where, the restarting node support the extensions but one or
> more of its neighbors do not. The restarting node would have to wait
> until the end of the Recovery Period to revert to restart processing per
> RFC3473. With an explicit advertisement of RecoveryPath capability, this
> requirement no longer exists.