Subject: Re: resvtear msg

From: "Hariom P" <[email-masked]>
Date: Thu, 11 Oct 2001 15:47:41 -0700

Please see inline

>From: David Charlap <[email-masked]>
>To: [email-masked]
>Subject: Re: resvtear msg
>Date: Thu, 11 Oct 2001 17:24:15 -0400
>
>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.

HMP : I am assuming only RSVP-TE for the current discussion. Excuse me
      because i am using terms that may seem to resemble LDP here, but
      idea is not to compare RSVP-TE with LDP..

      You are saying that resvTear != LabelWithdraw. It seems to me
      that resv msg = labelMap because it does give the label
      mapping. And hence any resvTear = LabelWithdraw, in response to
      which i am saying the node can generate pathTear = labelRel.

      If we take an example scenario, RSB on some hop times out for
      whatever reason resulting in generation of resvTear upstream.
      According to what you are saying, LSP should remain intact and
      continue to forward traffic but with no Qos etc which does not
      look right. You are also making an assumption that any subsequent
      RESV msg that might re-establish RSB will retain the same label..

      Which also means that only time an LSP is cleaned is because of
      psb timout or on receiving pathTear msg. Is this how RSVP-TE LSP
      signalling designed to work..

      BTW i did look at RFC2209 wrt to vanilla RSVP. There is no
      mention of generating Pathtear in response to processing of
      ResvTear msg.

>-- David

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---

From: David Charlap <[email-masked]>
Date: Thu, 11 Oct 2001 19:21:00 -0400

Hariom P wrote:
> 
> You are saying that resvTear != LabelWithdraw. It seems to me that
> resv msg = labelMap because it does give the label mapping. And
> hence any resvTear = LabelWithdraw, in response to which i am
> saying the node can generate pathTear = labelRel.

This is simply not true.  When an LDP box receives a Label Request, the
message is just that - a request for a label.  It does not establish any
state, other than the request itself.  When a label is withdrawn in LDP,
the label-release accomplishes nothing more than an acknowledgement of
the withdraw.

On the other hand, when an RSVP box receives a Path message, state is
established on the router, even if a Resv message is never received. 
This state exists before the Resv arrives, and it remains after the Resv
arrives.

> RESV msg that might re-establish RSB will retain the same label..

No, that is not what I am saying.

When the ResvTear arrives, the LSP goes down.  You can't forward labeled
traffic without a label.

But the Path state is still there.  This state is not sufficient to
continue forwarding data, but it must remain in case another Resv should
arrive for it - which will re-establish the LSP (perhaps with a
different label).

> signalling designed to work.

The "LSP" is established on a router only when there is both Path and
Resv state.  A ResvTear deletes the Resv state.  A PathTear deletes
both.

> BTW i did look at RFC2209 wrt to vanilla RSVP. There is no mention
> of generating Pathtear in response to processing of ResvTear msg.

Right.  Because it isn't done.

-- David