Subject: Comments on Bypass Label draft

From: "Wadhwa, Sanjay" <[email-masked]>
Date: Tue, 10 Apr 2001 18:14:27 -0400

>Robert, George:

>Below are some comments on, and questions about, your bypass label draft.

>- Philip

>* Refreshing a backup tunnel riding a bypass tunnel
>  I don't understand how the refresh works in this case.
>  Section 2 states that the Path message for the backup tunnel is sent
inside the bypass
>  tunnel, while section 3 states that the SENDER_TEMPLATE object contains a
sender address
>  that differs from the address used for the primary LSP. So the merge
point LSR will create
>  a new Path State Block and try to send back a Resv message. But where
does it send this
>  Resv to?  If the network is as shown in figure on page 4, then it can
send the RESV message
>  on either the link to R3 or the link to R7. However, in either case, R3
or R7 will intercept
>  the Resv message, and because neither one is expecting a Resv message
with this sender
>  (because neither saw the corresponding Path message), problems ensue.

Philip
  My understanding is that the PHOP in the path message (for the backup
tunnel) sent on the bypass tunnel 
  would be one of PLR's (R2's) addresses. Since the interface on which the
path arrived on R4 is uni-directional,
  R4 will have to just unicast route the resv back to the PHOP. So rsvp on
R3 or R7 will not be seeing it. 
  Maybe the draft should be more explicit about signalling for backup
tunnels.

-Sanjay

---

From: "Philip Matthews" <[email-masked]>
Date: Tue, 17 Apr 2001 06:53:17 -0400

Sanjay:

Sorry about the slow response.
For some reason, both my original posting and your reply took nearly a week to
reach me from the list server.

"Wadhwa, Sanjay" wrote:
> >  Section 2 states that the Path message for the backup tunnel is sent inside the bypass
> >  tunnel, while section 3 states that the SENDER_TEMPLATE object contains a sender address
> >  that differs from the address used for the primary LSP. So the merge point LSR will create
> >  a new Path State Block and try to send back a Resv message. But where does it send this
> >  Resv to?  If the network is as shown in figure on page 4, then it can send the RESV message
> >  on either the link to R3 or the link to R7. However, in either case, R3 or R7 will intercept
> >  the Resv message, and because neither one is expecting a Resv message with this sender
>   My understanding is that the PHOP in the path message (for the backup tunnel) sent on
>   the bypass tunnel would be one of PLR's (R2's) addresses. Since the interface on which the
>   path arrived on R4 is uni-directional, R4 will have to just unicast route the resv back
>   to the PHOP. So rsvp on R3 or R7 will not be seeing it.
>   Maybe the draft should be more explicit about signalling for backup tunnels.
> 
> -Sanjay

Isn't this non-standard behavior? As I understand things, basic RSVP-TE (without
any hierarchy extensions), requires neighbors to be adjacent. Path and Resv messages
are addressed to the head end and tail end of the tunnel respectively, and are
processed hop-by-hop as they proceed through the network.

George claimed at the WG meeting in Minneapolis that no protocol extensions were required to
implement this draft. The above seems to be in conflict with that claim.

George: Any comments?

- Philip

---

From: George Swallow <[email-masked]>
Date: Tue, 17 Apr 2001 15:35:00 -0400

> any hierarchy extensions), requires neighbors to be adjacent. 

RSVP-TE builds on RFC2205.  The assumption there was that a network
may have a mix of RSVP capable and non-RSVP capable nodes.  If a Path
message is sent to a non-RSVP node, it simply passes through to the
next node.  If that node (or some subsequent node) is RSVP capable,
then it does normal processing.  When a Resv message comes, it will be
forwarded back according to the PHOP.  

> Path and Resv messages
> are addressed to the head end and tail end of the tunnel respectively, 

Path messages are addressed to the tail of the tunnel.  Resv messages
are address to the PHOP of the corresponding Path message.

> and are processed hop-by-hop as they proceed through the network.

They may or may not be processed hop-by-hop.

> George claimed at the WG meeting in Minneapolis that no protocol
> extensions were required to implement this draft. The above seems to
> be in conflict with that claim.
>
> George: Any comments?

I stand by my claim.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: "Philip Matthews" <[email-masked]>
Date: Wed, 18 Apr 2001 08:11:02 -0400

George:

Thanks for your reply.
I think I understand the refresh mechanism in your draft now.

I had mistakenly thought that a node implementing RSVP-TE
needed to check that the PHOP and NHOP were directly adjacent
(in order to ensure the LSP was not set up through a non-RSVP-TE
node). However, from your reply, and a re-read of RFC2205,
I now understand that the correct test is for the node receiving
the Path message to check that the TTL field in the IP header
against the Send_TTL in the common header. No check is necessary
on received Resv messages.

When refreshing over a bypass tunnel, the TTL will not be
decremented inside the tunnel, so the Path message will still
pass the TTL check at the merge node.

As for the Resv message, it will be sent back over whatever
path still exists between the merge node and the PLR. Its
destination address is the PLR node, so the intervening
nodes will forward it with any further processing.
(While IGP routing is reconverging, the Resv messages may be
lost, but assuming a generous refresh interval, the IGP should
reconverge before the Path and Resv state times out).

Thanks again.

- Philip