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

From: [email-masked]
Date: Thu, 11 Oct 2007 14:11:58 EDT

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

(1)
Now that I have become familiar with the notvia node solution I must say:  
Yes that is an excellent solution.

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 ?
b) why should a direct neighbor of P be the appropriate intermediate  
destination ?
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 !
 
Heiner

Subject: Re: "Basic Specification for IP Fast-Reroute: Loop-free Alternates"
From: [email-masked]
To: [email-masked]
Cc: [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

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

---

From: mike shand <[email-masked]>
Date: Fri, 12 Oct 2007 09:14:08 +0100

[email-masked] wrote:

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

(1)

Now that I have become familiar with the notvia node solution
I must say: Yes that is an excellent solution.

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
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]

Date:

Mon, 8 Oct 2007 10:09:46 EDT

To:

[email-masked]

To:

[email-masked]

CC:

[email-masked]

(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