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

From: Alia Atlas <[email-masked]>
Date: Wed, 11 Feb 2004 04:32:40 -0500

Hi,

I recently submitted draft-atlas-ip-local-protect-00.txt and would be very 
interested in any comments on it.

Thanks,
Alia

>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>         Title           : IP/LDP Local Protection
>         Author(s)       : A. Atlas
>         Filename        : draft-atlas-ip-local-protect-00.txt
>         Pages           : 30
>         Date            : 2004-2-9
>
>This document defines an architecture and selection process for
>providing local protection for IP unicast and/or LDP traffic in the
>event of a single link or node failure until the router has
>converged.  When computing the primary next-hop for a prefix, a
>router S also determines an alternate next-hop which can be used if
>the primary next-hop fails.  The alternate can be either a loop-free
>alternate, which goes to a neighbor whose shortest path to the prefix
>does not go back through the router S, or a U-turn alternate, which
>goes to a neighbor whose primary next-hop to the prefix is the router
>S, 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-00.txt

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

---

From: Alia Atlas <[email-masked]>
Date: Wed, 11 Feb 2004 04:32:40 -0500

Hi,

Thanks,
Alia

---

From: "Raj Mani" <[email-masked]>
Date: Thu, 12 Feb 2004 02:37:17 -0500

Atlas,

>interested in any comments on it.

      Good research. A few comments on this draft of local protection:

      It's rather confusing to talk about characterizing the neighbors,
      since each prefix can have it's own primary path, loop-free 
node-protecting
      alternate, loop-free link-protecting alternate, U-turn..., etc. If
      one has lots of prefixes, and neighbors, the combination can be
      rather large to keep track of.

      I didn't fully understand all the U-turn cases described, since
      they are quite involved. Not sure you have covered the cases where two
      nodes have multiple parallel links, even you receive from one link and
      forward to another link, they can still be looping; also in
      multi-node looping case due to asymmetrical routing,
      S-->B-->A-->S which can not be detected by the inbound/outbound
      interface lookups.

      The computation of this can be intensive (depends on the number
      of routes and number of neighbors), there are more chance nodes
      converge at different times. But this paper depends on every nodes
      are in stable condition, otherwise, some of the calculations may not
      be reliable.

      The paper mentioned LDP and node protection, I don't see how the
      LDP traffic can be protected using node protection with this. Can
      you give an example?

      This paper mentioned the capability need only be flooded to a node's
      neighbor, I don't recall there is a special mechanism defined to
      only flood to IGP neighbors but not further.

      If the paper claims the MPLS-TE FRR is complicated, This scheme
      is not less complicated;) They can all be accomplished by router or
      some server software, but at least MPLS-TE FRR is guaranteed to 
deliver
      the switch-over without depending on chance.

      The alternate nexthops is not completely new, probably should
      mention draft-kini-traf-restore-nsp-00.txt which I think was
      expired, but searched on web found this link:
      
http://yen.cse.kyutech.ac.jp/~ike/I-D/OLD/draft-kini-traf-restore-nsp-00.txt
      that draft had some similar idea as computing primary and alternate
      nexthops.

Regards.
- r

_________________________________________________________________
Check out the great features of the new MSN 9 Dial-up, with the MSN Dial-up 
Accelerator. http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/

---

From: "Raj Mani" <[email-masked]>
Date: Thu, 12 Feb 2004 02:37:17 -0500

Atlas,

      

Regards.
- r

---

From: "Raj Mani" <[email-masked]>
Date: Thu, 12 Feb 2004 02:37:12 -0500

Atlas,

      

Regards.
- r

_________________________________________________________________
Get some great ideas here for your sweetheart on Valentine's Day - and 
beyond. http://special.msn.com/network/celebrateromance.armx

---

From: "Raj Mani" <[email-masked]>
Date: Thu, 12 Feb 2004 02:37:00 -0500

Atlas,

      

Regards.
- r

_________________________________________________________________
Plan your next US getaway to one of the super destinations here. 
http://special.msn.com/local/hotdestinations.armx

---

From: "Raj Mani" <[email-masked]>
Date: Thu, 12 Feb 2004 02:37:12 -0500

Atlas,

      

Regards.
- r

---

From: "Raj Mani" <[email-masked]>
Date: Fri, 13 Feb 2004 01:44:00 -0500

Hi Atlas,

          thanks, see some comments inline.
>The characterization is more conceptual.  In general, one determines the 
>appropriate alternate and primary next-hop for each node in the topology.  
>A prefix can be ECMP between two or more nodes, in which case it falls into 
>the multiple primary neighbors case.

          Yes, it's true. This should be per prefix/per next-hop based. 
Which was
           also the reason I'm puzzled by the paper most of the places 
treating those
           concept as per node basis. For example, the OSPF and ISIS 
signaling
           for the U-turn capabilities, it just announces this link as 
capable of performing
           U-turn or not, but since those concept is really 
prefix/destination related, you
           can have some prefixes having alternate paths, but other prefixes 
you
           don't have. So I'm not sure how can OSPF/ISIS flood only the 
capability
           for the links.

>Yes, this is why the check is whether the traffic was received from the 
>same neighbor that the traffic would be sent out to and NOT whether the 
>traffic was received on the same link on which it would be forwarded.

          Since this is described as the "default" behavior; We are talking
           about forwarding plane or fast path. What will be the performance
           impact to detect which neighbor each packet is from? Even just
           to match inbound interface with outbound interface, I'm pretty
           sure that, most of the high-end routers can not even do that 
(without
           re-spining an Engine-12 for example); even for the routers are 
able to
           perform this, there can be a significant performance hit.

>
>If there were a routing loop of S->B->A->S, then B would not be a U-Turn 
>neighbor of S and S would not sure B for a U-Turn alternate.  If you look 
>at the definition of a U-Turn neighbor, a neighbor B is a U-Turn neighbor 
>of S if and only if S is the primary neighbor for all optimal paths from B 
>to the destination that go through S.
>
>
>Just like the primary SPF, the computation primarily depends on the number 
>of nodes in the network, though the number of neighbors which can provide 
>alternates is also important.
>
>The alternates are computed to protect against a single failure.   The 
>calculations for the alternate next-hops are as reliable as the primary 
>next-hops are; i.e. once the network has converged, there will be 
>alternates that can be used to protect against a single failure.

          Sometimes there can be link/route flappings, sometimes there are 
fiber
           cut which may bring down more than one IP link; a node failure
           may also trigger multiple link failure detection by multiple 
nodes.

>The issue with providing LDP with node protection is knowing the new 
>neighbor's label.  If the LSRs use downstream unsolicited and liberal label 
>retention, then an LSR will have the label bindings for each FEC from each 
>of its neighbors that support that FEC.
>
>As long as the label binding is known for the alternate neighbor, then the 
>appropriate out-segment can be created beforehand based on the selected 
>alternate next-hop.
>
>Does that make sense?  It does assume that there are LDP sessions to each 
>neighbor, but that is generally the case.

          yes, this makes sense.

>For OSPF, there is the ability to have a link-scope opaque TLV (type 9, I 
>believe).  The same mechanism isn't there for IS-IS.
>
>We actually decided not to use a link-scope TLV, because we wanted similar 
>capabilities for OSPF and IS-IS, and because we wanted to define a link 
>capabilities sub-TLV, where the other bits could be used to another 
>purpose.
>
>Take a look at draft-atlas-ospf-local-protect-cap-00.txt and 
>draft-martin-isis-local-protect-cap-00.txt.

          Yes, I just did. Thus I have the above mentioned question. I would
           think the capability is not just a node/link capability, but also 
related
           to the prefixes which may or may not use the same alternate paths
           or even have alternate path.

>The question is where the complexity burden is handled.  This scheme is 
>complicated to understand and non-trivial to implement, but the complexity 
>is primarily in the algorithm.  The management for it is more 
>straightforward; the difference between managing a connection-less network 
>and a connect-oriented network, on some level.

          Yes, and we all know managing a connectless network can face
          uncertainty while connection-oriented network gives certainty.
          In some sense, it's also an implementation issue, the MPLS-TE
          FRR if without considering the TE portion, can also be setup
          automatically without much configuration.

>
>This scheme doesn't depend on chance; it depends upon the topology being 
>appropriately engineered.

          When I mentioned "by chance", I meant in this paper, you may
           or may not find alternate path, or find U-turn alternate; you may
           face two network events close enough that you don't have
           enough time to compute all the alternate paths before a local
           link/node failure; while in MPLS-TE FRR, it's almost a certainty
           to get switched-over correctly.

>Absolutely; it's hard to reference an expired draft.  I know that the 
>concept of alternate next-hops has been discussed before, in reference to 
>loop-free alternates.  The conclusion seems to have been that it didn't 
>provide enough coverage.  That's what the U-Turn alternates are trying to 
>solve.

          this makes sense. thanks.

- r

_________________________________________________________________
Let the advanced features & services of MSN Internet Software maximize your 
online time. http://click.atdmt.com/AVE/go/onm00200363ave/direct/01/

---

From: "Raj Mani" <[email-masked]>
Date: Fri, 13 Feb 2004 01:44:00 -0500

Hi Atlas,

          yes, this makes sense.

- r

---

From: "Raj Mani" <[email-masked]>
Date: Fri, 13 Feb 2004 01:43:43 -0500

Hi Atlas,

          yes, this makes sense.

- r

_________________________________________________________________
Create your own personal Web page with the info you use most, at My MSN. 
http://click.atdmt.com/AVE/go/onm00200364ave/direct/01/

---

From: "Raj Mani" <[email-masked]>
Date: Fri, 13 Feb 2004 01:44:52 -0500

Hi Atlas,

          yes, this makes sense.

- r

_________________________________________________________________
Choose now from 4 levels of MSN Hotmail Extra Storage - no more account 
overload! http://click.atdmt.com/AVE/go/onm00200362ave/direct/01/

---

From: "Raj Mani" <[email-masked]>
Date: Fri, 13 Feb 2004 01:44:52 -0500

Hi Atlas,

          yes, this makes sense.

- r