Subject: RE: epoch field in Refresh Reduction RFC (2961)

From: "Feng, Mark" <[email-masked]>
Date: Wed, 12 Sep 2001 11:14:14 -0700

Please see comments below.

> -----Original Message-----
> From: Ping Pan [mailto:[email-masked]]
> Sent: Sunday, September 09, 2001 8:49 PM
> To: Bob Braden
> Cc: [email-masked]; [email-masked]
> Subject: Re: epoch field in Refresh Reduction RFC (2961)
> 
> 
> Bob Braden wrote:
> 
> >  *> From [email-masked]  Thu Sep  6 23:50:55 2001
> >  *> X-Originating-IP: [63.27.22.48]
> >  *> From: "manoj juneja" <[email-masked]>
> >  *> To: [email-masked]
> >  *> Subject: epoch field in Refresh Reduction RFC (2961)
> >  *> Date: Thu, 06 Sep 2001 23:49:06 -0700
> >  *> Mime-Version: 1.0
> >  *> X-OriginalArrivalTime: 07 Sep 2001 06:49:07.0117 (UTC) 
> FILETIME=[30B24DD0:01C13769]
> >  *> 
> >  *> Hi All,
> >  *>            I have a doubt regarding the epoch value as 
> described in RR RFC. 
> >  *> If a node receives different epoch value than 
> previously received from the 
> >  *> neighbor, should the node delete the context of all the 
> message Ids that 
> >  *> were linked with old epoch value learned previously ? 
> If not, then how can a 
> >  *> node maintain the context of two different epochs at 
> the same time from the 
> >  *> same node ?
> >  *> If the context of all the old message Ids that were 
> linked with old epcoh 
> >  *> has to be deleted then should the path and reservation 
> states be deleted or 
> >  *> need to kept without the message ids ?
> >  *> 
> >  *> Regards,
> >  *> manoj.
> >  *> 
> >  *> 
> _________________________________________________________________
> >  *> Get your FREE download of MSN Explorer at 
> http://explorer.msn.com/intl.asp
> >  *> 
> >
> >If the received epoch value changes, then presumably the 
> sender of that
> >value has been restarted and lost state.  So the sensible thing to do
> >would seem to be to delete all state associated with the old 
> epoch value.
> >
> 
> Yep.
> 

[Mark] I am not sure deleting the states themselves is a good choice. With
the following scenario:
     R1 - R2 - R3
Let's assume R2 resets, R3 receives a new Epoch value. For simplicity, let's
just assume the associated states are Path states. If R3 deletes those
states, it would make sense that PTear should be sent towards the
downstream; otherwise, R3 is simply taking care of itself, and not helping
all the nodes downstream. By doing so, the effect is not localized to one
node, but affects all the states on the nodes along the path from that point
on.

The problem with this is that, RSVP has "soft state". R1, the upstream node,
might not know anything has happen to R2. R1 would still continue to send
refresh Path messages to R2. Eventually, R2 comes back up, and will create
those lost states again with the help of the received refresh messages.
Depends on the time of the "cleanup" timer and the time taken for R2 to come
back up, it would take R1 some considerable time to detect the trouble at R2
by the Resv state timeout. Then the RTear will have to travel all the way
back to the sender, which might or might not triggers a PTear message.

I agree this would be implementation dependent. Because of the "soft state",
even if the states are removed, they will be restored again. My concern is
that, a lot of processing and bandwidth could be wasted for the restoration.

> >
> >Whether you delete the old path and resv state or just let 
> it time out
> >would seem to be an implementor's choice.
> >
> Actually, if there is an epoch value change, the receiving 
> nodes should 
> nack the messages to force the sending node retransmits the full 
> messages. This is somewhat important in case of summary 
> refresh messages.
> 

[Mark] I assume the question is about the behavior of the receiver when it
detects a Epoch change when processing a full message. Nack object,
according to the RFC, should be used when processing the SRefresh messages.
It seems to be a protocol error to send Nack's when processing other
messages, regardless of the reason. Please correct me if I am wrong.

> - Ping Pan
> >Bob Braden

---

From: Ping Pan <[email-masked]>
Date: Wed, 12 Sep 2001 15:04:38 -0700

> node, but affects all the states on the nodes along the path from that point

I believe what Bob was saying that, in this case, the *receiving* node
should delete all the states that have an old epoch value. Not sure why
anybody wants to delete the actual reservation states.

> messages, regardless of the reason. Please correct me if I am wrong.

you're right.