Subject: Re:

From: Alia Atlas <[email-masked]>
Date: Tue, 08 May 2001 18:15:35 -0500

Sanjay,

I am considering the same problem.  With the below topology, assume the
primary LSP is R1-R2-R3-R4-R5-R6. 

                  R7 --------- R8 -------- R9 ------- R10
                   |               |            |            |
     R1-------- R2 --------- R3 ------- R4 ------- R5 -------- R6

The backup from R2 is signalled as R2-R7-R8-R9-R4.
The backup from R3 is signalled as R3-R8-R9-R10-R5.

In the PATH messages, clearly the DETOUR object and the ERO distinguish the
two detours.  However, in the RESV, from the draft, the only way to
distinguish the two is based on the contents of the RRO.

I would suggest that it would make sense to set the "IPv4 tunnel sender
address" in the SENDER_TEMPLATE to an address of the PLR (R2 in the example
above).  This is how draft-swallow-rsvp-bypass-label-01.txt suggests
distinguishing a backup from the primary.  It has the advantage that the
"IPv4 tunnel sender address" is copied from the SENDER_TEMPLATE in the PATH
message into the FILTER_SPEC in the RESV message.

Does this make sense to you? Have you heard any other suggestions for how
to distinguish the different detours?

Thanks,
Alia

At 05:02 PM 4/25/01 -0700, Sanjay Wadhwa wrote:
>Hi
>The re-route technique mentioned in this draft talks about using the
>same sender_template for each detour LSP and the primary LSP. It is
>also restricted to use FF style. How would overlapping detours be
>handled here ?
>
>
> R1 ---- R2 ---- R3 ------ R4 ----- R5 ----- R6
>         |       o         |         o
>         |       o         |         o
>         +------ R7 -o-o-o R8 oooooooo
>
>Lets say R2 and R3 are local repairers.          
>R2-R7-R8-R4 (dashed path) provides detour for node R3.
>R3-R7-R8-R5 (bubbled path) provides a detour for R4.
>Both detours have R7-R8 as a common link. In this case you would want
>R8 to send different labels corresponding to the two detours to R7,
>since R8 needs to switch packets coming on the two detours out
>different interfaces (R8-R4 and R8-R5). If the sender_template is
>identical for the two detours how would R8 send two different labels to
>R7 (labels go with the filter-spec in RESVs. And I don't see the detour
>object being passed back in the RESV to possibly identify the detour) ?
>
>-Sanjay
>
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Auctions - buy the things you want at great prices
>http://auctions.yahoo.com/

---

From: Sanjay Wadhwa <[email-masked]>
Date: Fri, 11 May 2001 08:08:16 -0700 (PDT)

Alia,
  I haven't heard back from the authors of the draft on this. 
Using the address of the PLR for the detour is what I had in mind as a
possible option too. One issue is being able to unambiguously find the
primary's state to merge with on the merge point when you get a setup
for the detour, and to keep the primary's state alive (and refreshed
downstream) if path state for one or more detours is present. I suppose
on the merge point you could identify the primary's state by looking
for path state that correponds to the session in the detour's setup and
also contains a re-route object.

-Sanjay

---

From: Alia Atlas <[email-masked]>
Date: Fri, 11 May 2001 11:44:12 -0500

Sanjay,

>also contains a re-route object.

If the "local protection requested" flag is set in the Session Attribute
object for the primary, that could also be used.  In
draft-gan-fast-reroute-00.txt, I do not see it specified whether or not
that flag should be set.  I would assume that it should be, since local
protection is what the fast-reroute object is requesting.

I do have a question about draft-swallow-rsvp-bypass-label-01.txt and
keeping the primary's state alive.  The draft suggests simply sending the
primary's PATH message, presumably with a modified ERO, through the bypass
tunnel only in the event of a failure. 

Clearly, the bypass tunnel will be signalled and kept alive, but the Merge
node can't determine which primary's are protected via backups through that
bypass tunnel.  When global labels are available, no Path messages are sent
for the backups to the merge point.

When a failure occurs, however, the downstream node may immediately send a
path tear.
In the below diagram, with a primary of R1-R2-R3-R4-R5 and a bypass tunnel
of R2-R6-R4, if the link R2-R3 fails, presumably R3 will send a Path tear
to R4.   If R4 hasn't received a the modified Path message through the
bypass tunnel, then R4 will tear down the primary state.

                                    ___R6___
                                  /               \
		R1-----R2-----R3------R4------R5 

Do you see a solution to this race condition, other than signalling the
PATH message through the bypass tunnel always?  Is the assumption that R3
will not send an immediate Path Tear on a LSP with local protection requested?

Alia

---

From: Sanjay Wadhwa <[email-masked]>
Date: Mon, 14 May 2001 17:07:21 -0700 (PDT)

see inline..

--- Alia Atlas <[email-masked]> wrote:
> PATH message through the bypass tunnel always?  

Signalling through the bypass tunnel always would defeat the
optimization mentioned with global labels.

> Is the assumption that R3 will not send an immediate Path Tear on a
>LSP with local protection requested?

In my opinion, yes. And in addition (to be safe) R4 in your example
could also ignore any path tear messages and could wait for refreshes
when local protection has been requested on an LSP. 

-Sanjay