Subject: resvtear msg

From: "Hong Liao" <[email-masked]>
Date: Tue, 9 Oct 2001 15:39:04 -0400

Hi,

If Ingress router sends out the pathtear msg to tear down the path and resv
state, does the egress suppose to send out the resvtear msg out once it
receive this pathtear msg?  I read the spec, I think the egress should not
send out the resvtear msg.

Can someone help me to confirm this?

Thanks,

Julia

---

From: "Gopalan, Vinod" <[email-masked]>
Date: Tue, 9 Oct 2001 12:52:40 -0700

You're right. Egress should not send out a resvtear in response to a
pathtear.

But the ingress is required to send a pathtear in response to a resvtear to
complete a teardown.

- Vinod.

-----Original Message-----
From: Hong Liao [mailto:[email-masked]]
Sent: Tuesday, October 09, 2001 12:39 PM
To: [email-masked]
Subject: resvtear msg

Hi,

Thanks,

Julia

---

From: "Hong Liao" <[email-masked]>
Date: Thu, 11 Oct 2001 11:09:22 -0400

Adrian Farrel wrote:
>
> However, there is an obvious race where the egress has already sent
> out ResvTear and it crosses with the PathTear

I think Adrian means that there is ResvTear msg sent out(Egress wants to
delete resv state) before the PathTear arrives to the Egress.

Julia

                    David Charlap                                                                                
                    <David.Charlap@ma        To:     [email-masked]                                                 
                    rconi.com>               cc:     (bcc: Hong Liao/Telcordia)                                  
                                             Subject:     Re: resvtear msg                                       
                    10/11/01 10:47 AM                                                                            

Adrian Farrel wrote:
>
> However, there is an obvious race where the egress has already sent
> out ResvTear and it crosses with the PathTear

This isn't really a race condition.  The ResvTear will propagate up to
the point at which it crosses the PathTear.  Beyond there, there will be
no corresponding path state and the Resv will be dropped (silently, I
think - I don't think you generate a ResvErr in response to a ResvTear
that doesn't match established state.)

-- David

---

From: "Arvind, K" <[email-masked]>
Date: Fri, 12 Oct 2001 14:31:56 -0400

>David Charlap wrote
> ...
> ...
> It is perfectly legal (and not unusual in classical RSVP) for an egress
> node to delete a reservation and later re-establish it with different
> parameters.

In sender-initiated TE-RSVP, how common is it for an egress node to delete a
reservation and later re-establish it with different parameters? Why not
just clear both the path and resv state when a ResvTear is received (in
addition to propagating the ResvTear upstream) in a TE-RSVP implementation,
instead of continuing to hold onto the Path state in anticipation of a
PathTear?

Regards,
Arvind.

> From:	Eric Gray [SMTP:[email-masked]]
> Sent:	Thursday, October 11, 2001 7:15 PM
> To:	David Charlap
> Cc:	[email-masked]
> Hariom,
>     David is correct, though there is another way to look at it: sending a
> PathTear message at an intermediate node would be a waste of time
> since the sender will continue to send Path messages and intermediate
> nodes will then be required to forward them.  A subsequent Path message
> will simply re-establish the Path state deleted as a result of an earlier
> PathTear message.  It doesn't really matter whether the Path message
> is a result of a refresh by the intermediate node, or the result of
> 'passing
> on' a Path message from the sender.
> 
> David Charlap wrote:
> 
> > Hariom P wrote:
> > >
> > > Why can't every hop that processes resvtear do the following,
> > > 1. Del matching reserv state and forward resvtear if required to the
> > >    prevhop
> >
> > It should always send a ResvTear after deleting the corresponding
> > state.  If the state is not present on the previous-hop router, then
> > that router will ignore the message.  It is unreasonable to expect a
> > router to know with certainty what the adjacent routers' states are.
> >
> > If you send a ResvTear when the neighbor has no state, it's not a big
> > deal - the message will just be ignored.  If, however, you do not send a
> > ResvTear when you should have, the neighbor's Resv state will not go
> > away until it times out.  Depending on how the routers are configured,
> > this could be quite a long time.
> >
> > > 2. And send a pathtear to the nexthop
> >
> > This is wrong.  Path state should not be deleted when Resv state is
> > deleted.  It must remain established, and the node must continue
> > refreshing it.
> >
> > It is perfectly legal (and not unusual in classical RSVP) for an egress
> > node to delete a reservation and later re-establish it with different
> > parameters.
> >
> > Don't think of RSVP as a variation on LDP.  It is not.  A Path message
> > is not just a request for a label.  It establishes state in and of
> > itself.  It is not something that can be causally discarded simply
> > because some corresponding Resv state has been destroyed.
> >
> > -- David
> 
> --
> Eric Gray (mailto:[email-masked])
> http://www.mindspring.com/~ewgray
> 
> 
>