Subject: Re: "Basic Specification for IP Fast-Reroute: Loop-free Alternates"

From: [email-masked]
Date: Tue, 2 Oct 2007 08:47:32 EDT

Let me quote from page 6:
"In Figure 2, S would be able to use N as an alternate, but N could not use  
S; therefore N would have no alternate and would discard the traffic,   thus 
avoiding the micro-loop."
 
As I said: According to the IPFRR rules N cannot use S.
 
I can assure you that there are even more complex case studies and  yet each 
network link can properly be taxed and tagged and ranked as to  provide total 
orientation. Including cases where crankback (using IP forwarding  techniques, 
not MPLS) is  necessary, eventually even back to the ingress or  even 
further, e.g. to detour around any general SRLG.
You may say this is overdoing. Maybe, if you have already multiple best  next 
hops. But we all know that in a contiguous network just one best hop is  
guaranteed. The first alternative may already require a longer  detour.
And also, it would be useful to know whether some adjacent link enters a  
dead-end area so that it is better to discard the packet right away.
 
Heiner

In einer eMail vom 02.10.2007 13:13:50 Westeuropäische Normalzeit schreibt  
[email-masked]:

[email-masked] (mailto:[email-masked])  wrote:  
In figure 2 everyone can see that not only S but also N has two choices  to 
get to D. However
according to the rules of the game N has only one  choice.

I'm sorry, but I haven't a clue what you are  talking about. Figure 2 is 
illustrating the problem of using link protecting  LFAs which can cause loops when 
a node failure occurs.

If we are  talking about LFAs, then BOTH N and S have two choices (the 
primary path, and  the LFA). That is the whole point of the illustration.

If we want to  AVOID the possibility of looping, then we can use downstream 
paths. In this  case it is true that S has N as a downstream path, but N 
doesn't have S as a  downstream path. That again is the whole point. If they both 
had downstream  paths there would still be a loop.

Of course there are other ways to  solve this problem, like using node 
protecting LFAs as described in the draft.  And in the case where there are NO LFAs, 
then other methods such as not-via  can be applied.

It just takes a change of the rules of the game, i.e. to come up  with better 
rules as  to enable two choices for N as well and also for  detours which are 
big enough to avoid a loop.  
It will take more effort but still of the same order of complexity  as  is 
needed for IPFRR according to this draft.

Heiner

____________________________________

_______________________________________________

rtgwg mailing list

[email-masked] (mailto:[email-masked]) 

_https://www1.ietf.org/mailman/listinfo/rtgwg_ 
(https://www1.ietf.org/mailman/listinfo/rtgwg) 

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

---

From: [email-masked]
Date: Mon, 8 Oct 2007 10:09:46 EDT

(1)
Now that I have become familiar with the notvia node solution I must say:  
Yes that is an excellent solution.
(2)
Nevertheless, it should be made clear: each node along the notvia-path must  
precisely select its notvia-nexthop link i.e. no respective ECMP hop ! 
Otherwise  a deja vu with the failing node may happen. Let me just repeat that there  
alternatives which allow "multipath" along the notvia route (which however 
take  more efforts to avoid any loop).
(3)
I think it is ( unnessecarily ) too much protection centric. Why not  just 
saying AVOID a particular node and/or link?
Protection seems to be used just like in soccer defense.Who protects  whom? 
For specifying this subject it is not sufficient to reduce the  diagram to just 
two paths( a protecting one and a protected one). There may be  more (not 
shown) paths which may protect resp. which may need to be protected.  Also, there 
may be other reasons than failures why to tour around a particular  node/link.
(4)
I also hope that this WG considers this draft just as a beginning. The  
better and the more of good results, the smaller the phantom angst of a loop.  Yes 
crankback is a loop, but it could be made perfectly i.e. with successful  
delivery (although I think I read something about back tracking that shouldn't  
bother)

Heiner

---

From: [email-masked]
Date: Sat, 13 Oct 2007 06:19:48 EDT

Admitted, I have misunderstood the spec. However it is a mutual  
misunderstanding.
While the IETF's  IGP routing technology is essentially based on the  
Dijkstra's SPT (which spans all network nodes) all my thinking is based on a SPT  
which spans all network links. While ECMP tree links are certainly an essential  
part of "my All Links Spanning Tree ALST" they are timidly  excused in some 
IETF draft by saying "it is still a SPT".
And yet I am sure that an ALST (as can be seen on my webpage) would be  the 
right base for decades of routing research to come.
 
Heiner
 
www.hummel-research.de

In einer eMail vom 12.10.2007 10:14:28 Westeuropäische Normalzeit schreibt  
[email-masked]:

In einer eMail vom 08.10.2007 16:09:46 Westeuropäische Normalzeit  schreibt 
HeinerHummel:

(1)

I am afraid, I have praised this solution too early.
a) why should S have any (failure) suspicion on P if S is not immediate  
neighbor of P ?

Why do you think it should? It  doesn't and can't (unless it is a member of 
an SRLG, in which case its failure  is implied by the failure of the immediate 
neighbor/link). It seems you have  misundestood the spec.

b) why should a direct neighbor of P be the appropriate intermediate  
destination ?

Because we are protecting against node  failure of P and that is where the 
traffic WOULD have gone.

The immediate neighbor of P should rather start  a detour  towards  some 
intermediate destination somewhere in the network such  that best as well as 
equally best hops towards it won't hit P  !

I think you are talking about something akin to the  original tunnels scheme 
(aka PQ space), which suffers from all sorts of corner  cases. I suggest you 
read 
_http://www.potaroo.net/ietf/all-ids/draft-bryant-ipfrr-tunnels-00.txt-70928.txt_ 
(http://www.potaroo.net/ietf/all-ids/draft-bryant-ipfrr-tunnels-00.txt-70928.txt)   to see the difficulties this approach suffered from. The point 
about not-via  is that it is very simple. We have considered the possibility of 
exiting   the tunnel once Q space has been reached, thus allowing the packet 
a  potentially more direct route, but this is generally regarded as overly  
complex.

Heiner

Subject:  
Re: "Basic Specification for IP Fast-Reroute: Loop-free  Alternates"   
From: 
[email-masked] (mailto:[email-masked])    
Date: 
Mon,  8 Oct 2007 10:09:46 EDT   
To: 
[email-masked] (mailto:[email-masked])      
To: 
[email-masked] (mailto:[email-masked])    
CC: 

Heiner