Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels

From: Curtis Villamizar <[email-masked]>
Date: Tue, 03 Apr 2001 15:14:05 -0400

In message <[email-masked]>, George Swallow writes:
> This message commences a workgroup last call on "RSVP Label Allocation
> for Backup Tunnels" <draft-swallow-rsvp-bypass-label-01.txt>.  This
> draft is informational.  The last call closes April 11, 12 PM GMT.
> 
> ...George

+   Cisco Systems may have intellectual property rights claimed in regard
+   to some or all of the specification contained in this document.

George,

Can you be more specific.  Do you or don't you have intellectual
property rights claims on this.

This is open ended.  If you aren't sure, then I suggest that the WG
hold the document until you can find out if you do.  If you do, I
suggest that you be more specific in stating what they are and under
what terms usage is granted to others.

Curtis

---

From: "Loa Andersson" <[email-masked]>
Date: Mon, 09 Apr 2001 17:58:13 +0200

All,

while moving from one employer to another I've been out of contact
with the IETF mailings lists, but here are my two cents on the RSVP
backup tunnel.

1. To the discussion of ms requirements.
All networks do not have SDH, or might even transport SDH in the MPLS
network, either way an MPLS based ms reroute capability is beneficial,
especially since it is cheaper than the SDH technology.

2. LSPs may be "concatenated" of segements using different LL
technologies,
this draft gives us the possibility to detect and reroute independent
of the lower layers.

3. The draft fails to mention that the described technology is even more
efficient and  straightforward if the rerouted traffic is plain IP. No
needs for identifying merging tunnels, just take the packet from R2 to
R4 through the tunnel, pop and forward on L3.

4. this is a wg last call for a non-wg draft (correct?). Implications?
Could I propose it is made a wg document? If appropriate I so move.

5. Neil might be right in saying that the failure modeling needs to be
done, but it could be kept out  of scope for the document. There are
probably many more scenarios that needs to be taken care of than the ones
that Neil mentions, e.g. what do R4 do with a label inside the
tunnel that is not recognized ? In which cases is it allowed to pop
and forward on L3 address?

6. further discussion on different types of failures ("link", "interface"
or "node") and the actions to be taken according to failure type would
also be useful, but could be done in independent drafts.

7, In the figure at page 4 R7 is the penultimate node (my reading), should

the double lines be from R2 to R6 instead of from R7 to R4?

8. In the cases there "additional" labels are needed have any thought been

given how much this affects  the salability?

9. A thought: would it be possible to establish the backup tunnel
(R2-R6-R7-R4), when that is done establish a LDP adjacency through the
tunnel and use vanilla LDP DoD to request lables for the FECs representing

the tunnels to be backuped? They would benaturally merged in R4, back to
the original tunnel.

10. the draft fails to mention complications that comes with resource
reservations associated with the backuped tunnels. We  need to distinguish

a situation where e.g. the same BW is merged back onto the original tunnel

from the situation where two tunnels are merged each requiring the full
BW that has been assigned to it.

11. in the introduction it is mentioned that this describes how to use
RSVP (RFC 2205) to set up back tunnels, this is true but I would like and
additional reference to the  RSVP-TE: Extensions to RSVP for LSP Tunnels,
since this is really what is needed/desscribed. BTW what is the state of
that document?

I can't see anything in what I mentioned above above or what has been
in the responses to  the last call, that would make necessary to stop
progressing this document.

/Loa

George Swallow wrote:

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

Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           [email-masked]
WWW             www.utfors.se