The MPLS WG Archive

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

It is wrong to send the RTear; and the neighbour will most likely ignore it,
because there shouldn't be any states matching the RTear after the PTear has
been processed.

- Mark

> -----Original Message-----
> From: Hong Liao [mailto:hliao@telcordia.com]
> Sent: Tuesday, November 13, 2001 3:04 PM
> To: Feng, Mark
> Cc: mpls@UU.NET
> Subject: RE: resvtear msg
> 
> 
> 
> >>It will most likely be dropped by the neighbour since the 
> state would've
> be removed by the Ptear.
> 
> If it is considered wrong if the ResvTear msg sent out after 
> the Pathtear
> msg, or it is fine, neighbour just ingore it.
> 
> Thanks,
> Julia
> 
> 
> 
> 
>                                                               
>                                         
>                     "Feng, Mark"                              
>                                         
>                     <m_feng@trill        To:     "'Hong 
> Liao'" <hliao@telcordia.com>, mpls@UU.NET     
>                     ium.com>             cc:     (bcc: Hong 
> Liao/Telcordia)                           
>                                          Subject:     RE: 
> resvtear msg                                
>                     11/13/01                                  
>                                         
>                     05:45 PM                                  
>                                         
>                                                               
>                                         
>                                                               
>                                         
> 
> 
> 
> 
> 
> 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
> >
> >
> >
> 
> 
>