[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Short additional working group last call on draft-ietf-ccamp-rsvp-restart-ext-03.txt
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.
----- Original Message -----
From: "Arun Satyanarayana" <firstname.lastname@example.org>
To: <email@example.com>; "Adrian Farrel" <firstname.lastname@example.org>; "Kireeti
Cc: "Lou Berger" <email@example.com>; "Dimitri Papadimitriou"
<firstname.lastname@example.org>; "Reshad Rahman" <email@example.com>;
"Anca Zamfir" <firstname.lastname@example.org>; "Junaid Israr" <email@example.com>; "Arun
Satyanarayana (asatyana)" <firstname.lastname@example.org>
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.