The MPLS WG Archive

["Feng, Mark" <m_feng@trillium.com>]

Rtear shouldn't be sent as response to a Ptear. It will most likely be
dropped by the neighbour since the state would've be removed by the Ptear.

- Mark

> -----Original Message-----
> From: Hong Liao [mailto:hliao@telcordia.com]
> Sent: Tuesday, November 13, 2001 2:15 PM
> To: mpls@UU.NET
> Subject: Re: resvtear msg
> 
> 
> 
> Hi,
> 
> Sorry to bring this topic again.
> 
> I would like to make a conclusion, if I am wrong, please point me out.
> 
> [My question]
> For example, the ingress sent out the path msg to egress, the 
> egress should
> not send out the resvtear msg, since pathrear will delete all 
> the path and
> resv state block.  But it is possible that egress send out 
> the path msg
> before the the ingress sent out the pathtear msg.
> 
> or it is also fine for the egress sent out the resvtear msg even the
> ingress send out the pathtear msg already.
> 
> [answer]
> 
> It should not have resvtear msg sent back if the pathtear  
> msg has been
> sent out to delete all the path, resv state block.
> 
> For my understanding, no resvtear msg should be sent out for 
> the response
> for the pathtear msg.
> 
> I observed that there is one vendor which implements this 
> way---egress sent
> out the resvtear to response the pathtear msg.
> 
> Can anyone confirm this one for me?
> 
> Julia
> 
> 
> 
> 
>                                                               
>                                             
>                     David Charlap                             
>                                             
>                     <David.Charlap@ma        To:     
> mpls@UU.NET                                          
>                     rconi.com>               cc:     (bcc: 
> Hong Liao/Telcordia)                           
>                                              Subject:     Re: 
> resvtear msg                                
>                     10/11/01 05:24 PM                         
>                                             
>                                                               
>                                             
>                                                               
>                                             
> 
> 
> 
> 
> 
> 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
> 
> 
>