Subject: Re: Review Call: draft-atlas-ip-local-protect-00.txt as WG item

From: [email-masked]
Date: Wed, 05 May 2004 21:46:19 +0200

hi alex,

Alex Zinin wrote:

> Folks-
> 
>  As discussed in Seoul, draft-atlas-ip-local-protect-00.txt is being considered
>  for becoming a WG item.
> 
>  At this point I would like to solicit opinions on the following points:
> 
>   1. Technical comments on the substance of the document

- some assumptions are made in the document that should probably be
   spelled out as working assumptions - as example
   "In essence, the assumption being made is that the time budget to
   recover traffic in the event of a failure is being consumed by router
   S's detection of the failure and switchover to its pre-computed
   alternate."
   "It is extremely desirable to have at most one forwarding table per
   interface." how this would translate in case of sub-interfaces ?
   "Normally, if traffic fails a reverse forwarding check (i.e. would
   be forwarded out to the same neighbor as received from), then that
   traffic is either discarded or forwarded into a loop. In IP/LDP Local
   Protection, however, traffic that fails a reverse forwarding check is
   forwarded to the appropriate R_i_j, if available, rather than being
   discarded."
   "In examining realistic networks, it was seen that loop-free
    alternates did not provide adequate coverage for the traffic between
    all the source-destination pairs." would it be possible to give a
    average characterization of such networks ?

- i don't understand the sentence "For neighbor N_4, the path to D is
    N_3 to S to N_1 to R_1 to D; because there is a node between N4 and S
    on the path, N_4 is a looping neighbor." from the picture 3 but i'm
   not sure you meant figure 3

- in the example of section 4.2 is also sending an ICMP re-direct
   during U-turn mode ? in this case how the condition on top of the
   figure 8 holds

- why this document is referred to as IP*/LDP* protection, if it is
   referring to the section 5 then it would be need some further details
   in particular what about the re-direction of the sessions themselves

>   2. More specifically, comments on the U-Turn part (e.g. useful/not useful,
>      comfortable/concerned with the approach, etc.)

- seems useful in some particular p2p cases (but really difficult to
   assess computational complexity impact) since from the wg discussions
   it delivers ~ +20% coverage
- concerned in terms of robustness in non-p2p environment
- would prefer keep (d) and (e) case (detailed in section 3.2.3) for a
   next step (are there exp.results available ?)
- no details about retrieving the initial state once the failure is
   recovered (reversion)

>   3. Should the WG use this document as the basis for work on the IP fast
>      reroute topic

it introduces a formalism that can be used for to initiate work on this
as well as gives a sensible classification, now its readability is
difficult and its structure (since imho oriented towards the use of
U-turn) not necessarily in-line with the direction of general topic i-d

thanks,
- dimitri.

>  Please send your comments by May 9th.
> 
>  The document is available at:
> 
>  http://www.ietf.org/internet-drafts/draft-atlas-ip-local-protect-00.txt
> 
>  The IPR statement is available at:
> 
>  http://www.ietf.org/ietf/IPR/avici-ipr-draft-atlas-ip-local-protect.txt
> 
>  Abstract from the document:
> 
>    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 router may indicate the capability to break U-turns on its links;
>    only such links can be used as U-turn alternate next-hops.  To signal
>    this capability, a router must be capable of detecting when it
>    receives traffic for a given destination from a primary neighbor for
>    that destination and the router must forward that traffic to the
>    selected alternate next-hop.
> 
>    To support U-Turn alternates and node-protection, a router must know
>    what links its neighbor can consider for alternates, how a neighbor
>    will select an alternate, and upon which interfaces a neighbor can
>    break U-turns.  This document defines a common selection criteria
>    which MUST be followed.  In addition, it is necessary to signal two
>    capabilities per link.  First is whether U-turns can be broken on the
>    link and second is whether the link can be used as an alternate, as
>    determined administratively.
> 

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

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

---

From: Alia Atlas <[email-masked]>
Date: Thu, 06 May 2004 13:52:36 -0400

Hi Dimitri,

>   spelled out as working assumptions - as example

Yes, this makes sense.

>   interface." how this would translate in case of sub-interfaces ?

I meant interface or sub-interface.

>    average characterization of such networks ?

I'm not sure I can give you an average characterization.  Anyplace where 
you have something like the following, a loop-free alternate won't exist 
for S.  In this case, D could be replaced by a cloud with D accessed elsewhere.

               <---              <----
        [ P ]-----------[ S ]----------[ N_1 ]---------[ R_1 ]
           |                                                    |
           |       --->                             <---      |
           |------------------------------[D]------------------|

>   not sure you meant figure 3

Replace N_1 with P.  I do mean Figure 3.

>   during U-turn mode ? in this case how the condition on top of the

It is not also sending an ICMP re-direct.  I'm a bit confused by this 
question.  Can you clarify?

>   in particular what about the re-direction of the sessions themselves

The sessions do not need to be redirected; that is one of the benefits.
If there is no existing LDP session with the selected alternate neighbor, 
then that LDP FEC cannot use the alternate.  Generally, a router will have 
an LDP session with its neighbors in that area.

>- concerned in terms of robustness in non-p2p environment

For non-p2p, you have to know that all the neighbors on that interface are 
in the same area, and thus working on the same topology.  It is of more 
limited use there.

>   next step (are there exp.results available ?)

What type of exp. results are you looking for?

>- no details about retrieving the initial state once the failure is

This falls into the assumptions, I guess.  Once a new SPF has been run, its 
results are installed into the FIB and are used.

>U-turn) not necessarily in-line with the direction of general topic i-d

The U-turn alternates clearly require some standardized signaling and 
agreement on selection, which is why the document was written with that 
orientation.

Thanks,
Alia

---

From: [email-masked]
Date: Fri, 07 May 2004 00:57:16 +0200

Hi alia,

[snip]
>>   spelled out as working assumptions - as example

would it possible to group them (suggestion at the beginning) they were 
put in different sections (may even help to have those listed per method

> I meant interface or sub-interface.

ok -

> for S.  In this case, D could be replaced by a cloud with D accessed 

i asked this because you mentioned "realistic networks", as asking you 
what realistic mean wouldn't have helped, was trying to see how for 
these realistic network characterizes in order to assess computational 
complexity (it won't be easy anyway)

> Replace N_1 with P.  I do mean Figure 3.

ok

> question.  Can you clarify?

taking figure 8, the condition mentions "Because all link costs are 
positive, no neighbor on the broadcast interface will ever send traffic 
to S along that interface in order to reach P. Therefore, S can assume 
that any traffic received on the broadcast interface which goes to a 
destination via a primary next-hop neighbor that is also on the 
broadcast interface is in fact sent by that primary next-hop neighbor 
and should be redirected to break the U-Turn." where should it be 
redirect (is it N_4 ? i think so because the figure uses the @@@ arrow)
but we would have then N_1/N_2/N_3 (-> P) -> S -> N_4 isn't P sending
a redirect (and how the condition holds ?) if the link to P fails i 
don't understand how this would work (how would N_1/N_2/N_3 detect link 
to P has failed), would you clarify ? but it seems looking at the next 
sentence that it seems that the interpretation i have is that S attracts 
the traffic "Thus, if router S has a primary next-hop neighbor for a 
given prefix on the broadcast interface, S should redirect all traffic 
received destined to that prefix on the broadcast interface to S's 
alternate next-hop." (N_4 is pointed by the @@@ arrow that's indicating 
the alternate next-hop towards D"

> If there is no existing LDP session with the selected alternate 
> neighbor, then that LDP FEC cannot use the alternate.  Generally, a 
> router will have an LDP session with its neighbors in that area.

i would have started the discussion on "FEC protection", and then try to 
see if there is an impact on LDP from the link/node failures that could 
affect it, i think we say the same in fact, you've concentrated the doc
on FEC (distributed from LDP) - LDP is simply another section in the 
protocol interactions described in section 6 - but you would agree with 
me that first sentence of the abstract is rather confusing then from 
that perspective "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." btw is the working assumption that the network is running in 
a uniform mode ? both ?

>>   it delivers ~ +20% coverage

by the way i was re-looking at the slides discussed in atlanta and is 
seems that thre any loop free reached at least 89% (and it was mention 
that in terms of % of protected links it should be higher)

> For non-p2p, you have to know that all the neighbors on that interface 
> are in the same area, and thus working on the same topology.  It is of 
> more limited use there.

up so far for non p2p environments i have been more looking at the 
problems it could generate (because without diminishing the merit of the 
effort i think - and the above statement confirms this - that we're 
probably running outside of its relevant utilization scope) you may 
still argue that you can emulate a point to point environment (see 
p2p-over-lan) but once above point will be clarified i think it will be 
easier to assess

> What type of exp. results are you looking for?

computational overhead (we know all the system constraints) wrt to 
loop-free alternates (for the same topology & in terms of the #nodes, 
#links, #dest.prefixes) we can even take the topologies for which the 
succesful events would be greater than simply with loop free alternates

> This falls into the assumptions, I guess.  Once a new SPF has been run, 
> its results are installed into the FIB and are used.

my question is related to overhead to retrieve the initial state it is 
in the introduction "until a new SPF is run and its results are 
installed." there are no further details upon conditions (assuming that 
breaking a U turn occur) you would require to have something equivalent 
in terms of succesful events (which results are installed)

> agreement on selection, which is why the document was written with that 

it would need to be revisited from that perspective (even it would need 
to make abstraction of the use of U-turns or any "optimized" method 
beyond loop free alternates in a first phase (?) - would you agree ?

thanks,
- dimitri.

---

From: Alia Atlas <[email-masked]>
Date: Fri, 07 May 2004 11:39:21 -0400

Hi Dimitri,

>put in different sections (may even help to have those listed per method

Yes, this makes sense as long as sufficient context has been introduced for 
the assumptions and methods to be understood.

>what realistic mean wouldn't have helped, was trying to see how for these 
>realistic network characterizes in order to assess computational 

Well, in this case realistic networks meant a combination of actual core 
networks.
The complexity depends on how many neighbors a router has to consider for 
an alternate.

>positive, no neighbor on the broadcast interface will ever send traffic to 
>S along that interface in order to reach P. Therefore, S can assume that 
>any traffic received on the broadcast interface which goes to a 
>destination via a primary next-hop neighbor that is also on the broadcast 
>interface is in fact sent by that primary next-hop neighbor and should be 
>redirected to break the U-Turn." where should it be redirect (is it N_4 ? 
>i think so because the figure uses the @@@ arrow)
>a redirect (and how the condition holds ?) if the link to P fails i don't 
>understand how this would work (how would N_1/N_2/N_3 detect link to P has 
>failed), would you clarify ? but it seems looking at the next sentence 
>that it seems that the interpretation i have is that S attracts the 
>traffic "Thus, if router S has a primary next-hop neighbor for a given 
>prefix on the broadcast interface, S should redirect all traffic received 
>destined to that prefix on the broadcast interface to S's alternate 
>next-hop." (N_4 is pointed by the @@@ arrow that's indicating the 
>alternate next-hop towards D"

Ok.  In ref to Figure 8, first, N_1, N_2 and N_3 would have P has their 
primary neighbor.  So would S.

If the link from P to D failed, then P would send traffic destined for D to 
S.  S, on receiving traffic from its primary neighbor, would detect and 
break the U-turn and therefore send the traffic to N_4.

This picture is trying to address the question of whether N_1, N_2 or N_3 
might send traffic destined to D towards S with the belief that it should 
then go to P.

P could send redirects for traffic it receives; that's on a longer 
time-scale, and doesn't make much sense to me if N_1, N_2 and N_3 are all 
in the same routing area running the same IGP.

>>then that LDP FEC cannot use the alternate.  Generally, a router will 
>>have an LDP session with its neighbors in that area.
>
>protocol interactions described in section 6 - but you would agree with me 
>that first sentence of the abstract is rather confusing then from that 
>perspective "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." 
>btw is the working assumption that the network is running in a uniform 
>mode ? both ?

It is true that the LDP protection comes from following the IGP and using 
the alternates that the IGP has computed for a FEC.  This works as long as 
LDP is running in liberal label retention mode and downstream unsolicited, 
so that LDP has the necessary labels.   I wanted to put that benefit up 
front in the abstract...

What do you mean by running in a uniform mode?  Are you asking if I'm 
assuming that the network topology was stable (and the routers converged to 
use it) before the single failure?  Or are you asking if I'm assuming LDP 
is running everywhere if running anywhere?  Or something else?

>that in terms of % of protected links it should be higher)

The coverage benefits are very much network topology dependent.  I'm 
probably looking at a different set of networks than Cengiz & Alex were.

>probably running outside of its relevant utilization scope) you may still 
>argue that you can emulate a point to point environment (see p2p-over-lan) 
>but once above point will be clarified i think it will be easier to assess

If emulating a p2p environment, then it works without additional restrictions.

>succesful events would be greater than simply with loop free alternates

That very much depends on the details of the algorithm used for the 
computation.

>my question is related to overhead to retrieve the initial state it is in 
>the introduction "until a new SPF is run and its results are installed." 
>there are no further details upon conditions (assuming that breaking a U 
>turn occur) you would require to have something equivalent in terms of 
>succesful events (which results are installed)

Sorry, but could you clarify your question even further?

>it would need to be revisited from that perspective (even it would need to 
>make abstraction of the use of U-turns or any "optimized" method beyond 
>loop free alternates in a first phase (?) - would you agree ?

Certainly it will need to given a perspective suitable to the sub-set of 
information contained in it.  If that doesn't include U-Turns (because that 
is in a separate draft for Experimental, for instance), then that would 
certainly change the perspective.

Thanks,
Alia

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 10 May 2004 11:48:00 +0100

Whilst I agree that the topic of link and node protection
in an IP network should be a work item for the IETF, it
is premature to accept draft-atlas-ip-local-protect-00.txt
as WG item.

I believe that there may exist a number of alternate
solutions to this problem. I think that we should
fully describe the problem and properly explore
the alternative solutions before accepting this draft
as a WG item.

- Stewart