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

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

Atlas,

>I recently submitted draft-atlas-ip-local-protect-00.txt and would be very 
>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

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

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

---

From: Alia Atlas <[email-masked]>
Date: Thu, 12 Feb 2004 04:06:48 -0500

Hi Raj,

At 02:37 AM 2/12/2004, Raj Mani wrote:

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

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.

>      S-->B-->A-->S which can not be detected by the inbound/outbound

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.

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.

>      are in stable condition, otherwise, some of the calculations may not

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.

>      LDP traffic can be protected using node protection with this. Can

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.

>      only flood to IGP neighbors but not further.

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.

>      some server software, but at least MPLS-TE FRR is guaranteed to deliver

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.

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

>      that draft had some similar idea as computing primary and alternate

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.

Thanks,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 12 Feb 2004 04:06:48 -0500

Hi Raj,

Thanks,
Alia