Subject: Fwd: I-D ACTION:draft-atlas-ip-local-protect-uturn-01.txt

From: Alia Atlas <[email-masked]>
Date: Tue, 26 Oct 2004 21:49:42 -0400

I've revised the U-turn alternates draft.  The major changes are as follows:

a) Introduced the option for explicitly marking U-turn traffic.
This may simplify some hardware implementations, allows handling of more 
broadcast link cases, allows correct handling of traffic exiting a TE 
tunnel via PHP (if needed), and provides a method where only traffic that 
is explicitly requested to be sent to the alternate will be.

b) Added example algorithm for computing u-turn alternates.  Worst-case is 
N additional SPFs, where N is the number of neighbors that could be U-turn 
alternates.  This should also clarify reason for the alternate selection 
procedure.   There is a brief discussion on considering SRLGs.

Thanks,
Alia

>To: [email-masked]
>From: [email-masked]
>Date: Tue, 26 Oct 2004 16:33:39 -0400
>Subject: I-D ACTION:draft-atlas-ip-local-protect-uturn-01.txt
>X-BeenThere: [email-masked]
>X-Mailman-Version: 2.1.5
>Reply-To: [email-masked]
>List-Id: i-d-announce.ietf.org
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
>         <mailto:[email-masked]?subject=unsubscribe>
>List-Post: <mailto:[email-masked]>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
>         <mailto:[email-masked]?subject=subscribe>
>Sender: [email-masked]
>X-Avici-MailScanner: Found to be clean, Found to be clean
>X-Avici-MailScanner-SpamCheck: not spam, SpamAssassin (score=-100.08,
>         required 5, AV_BSPAMST2 2.00, AWL 1.64, BAYES_00 -4.90,
>         MIME_BOUND_NEXTPART 0.90, NO_REAL_NAME 1.19, SARE_HEAD_XBEEN -0.91,
>         USER_IN_WHITELIST -100.00)
>X-MailScanner-From: [email-masked]
>X-Avici-MailScanner-Information: Please contact the ISP for more information
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : U-turn Alternates for IP/LDP Local Protection
>         Author(s)       : A. Atlas
>         Filename        : draft-atlas-ip-local-protect-uturn-01.txt
>         Pages           : 27
>         Date            : 2004-10-26
>
>This document defines and describes the use of u-turn alternates to
>    provide local protection for IP unicast and/or LDP traffic in the
>    event of a single link or node failure.  When a topology change
>    occurs, a router S pre-computes for each prefix an alternate next-hop
>    that can be used if the primary next-hop fails.  An acceptable
>    alternate can be either a loop-free alternate or a U-turn alternate.
>    A U-turn alternate uses a neighbor, whose primary next-hop to the
>    prefix is router S itself and which has itself a loop-free
>    node-protecting alternate, which thus does not go through router S to
>    reach the destination prefix.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-atlas-ip-local-protect-uturn-01.txt
>
>To remove yourself from the I-D Announcement list, send a message to
>[email-masked] with the word unsubscribe in the body of the 
>message.
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>to change your subscription settings.
>
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-atlas-ip-local-protect-uturn-01.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-atlas-ip-local-protect-uturn-01.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID: <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-atlas-ip-local-protect-uturn-01.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-atlas-ip-local-protect-uturn-01.txt>
>_______________________________________________
>I-D-Announce mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Rtgwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg

---

From: Thomas Eriksson <[email-masked]>
Date: Thu, 28 Oct 2004 14:19:48 +0200

Alia, we have talked briefly at the IETF a couple of times. I am interested 
in the IP fast reroute concept and hope that we can use it in our network 
some time in the future. I have a concern however. It is regarding the 
complexity of designing and keeping the topology so that uturn or even 
better, loop-free approach gives 100% coverage. Is my feeling correct that 
you need to keep a  very dense topology to reach the 100% goal?

Thomas

---

From: Christoph Reichert <[email-masked]>
Date: Thu, 28 Oct 2004 17:54:51 +0200

Hello,

I just recently started lurking on this list.

Sorry for referring just to a paper, but you might be interested in:

C. Reichert, T. Magedanz, "Topologies for Resilient IP Networks", Sept., 2004
http://www.fokus.fraunhofer.de/research/cc/ngni/employees/christoph.reichert/pubs/topologies.pdf

It's mainly pure graph theory, but we describe topologies in
which every link and node can be protected by what we called "O2
routing" (out-degree 2), which is basically the same as IPFRR. Our
conclusion is that this approach restricts topology design, but this
restrictions do not hurt very much. The required density is modest,
I would say.

However, depending on the algorithm used, 100% coverage depends not
only on the topology, but also on the link weights. We developed
several algorithm, and from this experience, I am quite sure that
the loop-free approach requires a special metric to achieve 100%
coverage.

chris

-- 
Dipl.-Inform. Christoph Reichert
Fraunhofer FOKUS             email:  [email-masked]
Kaiserin-Augusta-Allee 31    tel:    ++49-30-3463-7171
D-10589 Berlin
============================================
CoNEXT 2005 (Toulouse, France) in coopeartion with ACM Sigcomm.
Submit your manuscript until May 1st!
www.co-next.net <http://www.co-next.net/>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 28 Oct 2004 18:33:27 -0400

Thomas,

My impression from the networks that I have analyzed is that most are very 
close to 100% (average 98%) for coverage with u-turn and loop-free 
alternates.  For a few, I have explored the changes necessary to bring the 
coverage to 100%; it has been a relatively minor modification.  For 
instance, the modification may be a link that was already planned, a slight 
modification to a metric, or the like.

Clearly, this is topology dependent, but I think that a topology need not 
be substantially more dense than they are today.

The purpose of u-turn alternates is to bring the coverage and network 
engineering into that area.

I am more than happy to analyze any topologies and report back the 
results.  These don't even have to be real topologies :-)

Alia

At 08:19 AM 10/28/2004, Thomas Eriksson wrote:
>Alia, we have talked briefly at the IETF a couple of times. I am 
>interested in the IP fast reroute concept and hope that we can use it in 
>our network some time in the future. I have a concern however. It is 
>regarding the complexity of designing and keeping the topology so that 
>uturn or even better, loop-free approach gives 100% coverage. Is my 
>feeling correct that you need to keep a  very dense topology to reach the 
>100% goal?
>
>Thomas

---

From: Pekka Savola <[email-masked]>
Date: Fri, 29 Oct 2004 09:00:07 +0300 (EEST)

On Thu, 28 Oct 2004, Alia Atlas wrote:
> coverage to 100%; it has been a relatively minor modification.  For instance, 
> the modification may be a link that was already planned, a slight 
> Clearly, this is topology dependent, but I think that a topology need not be 
> substantially more dense than they are today.
>
> I am more than happy to analyze any topologies and report back the results. 
> These don't even have to be real topologies :-)

Have such topologies been formally described?  Or, with (sufficient 
number of) examples of topologies which are not supported, and the 
changes required to make them so?

It would be useful for the operators to be able to figure out how 
their topology would act like?

If we don't get 100% coverage, this exercise needs to be done sooner 
or later, and (IMHO) written in an RFC.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings