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

["Adrian Farrel" <adrian@olddog.co.uk>]

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" <asatyana@cisco.com>
To: <ccamp@ops.ietf.org>; "Adrian Farrel" <adrian@olddog.co.uk>; "Kireeti
Kompella" <kireeti@juniper.net>
Cc: "Lou Berger" <lberger@movaz.com>; "Dimitri Papadimitriou"
<dimitri.papadimitriou@alcatel.be>; "Reshad Rahman" <rrahman@cisco.com>;
"Anca Zamfir" <ancaz@cisco.com>; "Junaid Israr" <jisrar@cisco.com>; "Arun
Satyanarayana (asatyana)" <asatyana@cisco.com>
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.