Re: rtgwg Digest, Vol 37, Issue 8

["Abhay D.S" <[e-mail]>]

Not via solution still must consider LFA

a) From the algorithm point of view not via
is more efficient because when one has
calculated the primary next hops, the rest
of the not via addresses can be directly inhereted once.
And re-attached for every failed node once.

b) not via and LFA go together and only U Turn
is not considered.




----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>
Sent: Sunday, October 14, 2007 12:00 AM
Subject: rtgwg Digest, Vol 37, Issue 8


> Send rtgwg mailing list submissions to
> [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www1.ietf.org/mailman/listinfo/rtgwg
> or, via email, send a message with subject or body 'help' to
> [e-mail]
>
> You can reach the person managing the list at
> [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of rtgwg digest..."
>
>
> Today's Topics:
>
>    1. agenda topics for IETF-70 (John G. Scudder)
>    2. Re: Comments on draft-ietf-rtgwg-ipfrr-spec-base-09
>       (R?diger A Martin)
>    3. Cascaded U Turns for IP Unicast FRR (Abhay D.S)
>    4. Re: "Basic Specification for IP Fast-Reroute: Loop-free
>       Alternates" ([e-mail])
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 12 Oct 2007 15:41:28 -0400
> From: "John G. Scudder" <[e-mail]>
> Subject: agenda topics for IETF-70
> To: [e-mail]
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> Folks,
>
> If you would like an agenda slot for our IETF-70 meeting, please let
> me know.  Please also let me know how much time you think you'll need.
>
> --John
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 12 Oct 2007 23:33:08 +0200
> From: R?diger A Martin <[e-mail]>
> Subject: Re: Comments on draft-ietf-rtgwg-ipfrr-spec-base-09
> To: [e-mail]
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi all,
>
> we recently finished a comparison of LFAs and Not-Vias.
> http://www-info3.informatik.uni-wuerzburg.de/TR/tr432.pdf
>
> It provides alternative wording for LFA description, strategies for
> LFA selection for different resilience requirements, and quantitative
> results of their impact on protection coverage.  It also
> compares the path prolongation and decapsulation load for various
> combinations of LFAs and Not-Vias. We plan to extend the analysis to
> broadcast scenarios and SRLGs.
>
> This analysis might be useful when reworking the current draft. Comments
> are welcome.
>
> Regards,
>
>    Rüdiger
>
> --
> _______________________________________________________
>
>              Dipl.-Inform. Rüdiger Martin
>  Department of Distributed Systems (Informatik III)
> Insitute of Computer Science, University of Würzburg
>         Am Hubland, 97074 Würzburg, Germany
>          [e-mail]
>               Tel: [phone]
>               Fax: [phone]
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 13 Oct 2007 13:22:38 +0800
> From: "Abhay D.S" <[e-mail]>
> Subject: Cascaded U Turns for IP Unicast FRR
> To: [e-mail]
> Message-ID: <045501c80d59$125722d0$[e-mail]>
> Content-Type: text/plain; charset="gb2312"
>
> hi alia and alex,
>
> If a neighbor cannot provide a loop free alternate,
> then a consideration for U turn alternate is made for
> the same neighbor.
>
> Now this U Turn Alternate cannot find a neighbor which can provide
> a LFA, then we can consider this neighbors -> Neighbor upstream.
>
> If this upstream neighbor can support LFA, then how to consider
> the forwarding from
>
> Source -> U-Turn Neighbor -> U-Turns Nbrs Nbr -> U-Turns Nbrs Nbrs Nbrs{
DISTANCE not via Source (This Nbr, Destination) < SPFDist(This Nbr, Src) +
SPFDist(Src,Dest) is TRUE at upstream
> neighbor).
>
> Source can determine this and sends packet to U turn Neighbor say X,  U
turn neighbor X  knows that it cannot send the packet to its neighbor Y,
since Y
> cannot provide a Loop Free Alternate but Z , Y's Upstream neighbor can.
>
> In my understanding X can be configured to consider more than one hop
neighbors can provide LFA, in this case Y's Neighbors Z
>
> At Y the primary next hop to reach destination is Z.
>
> I think X must signal to Src about its availablity as a U Turn for a
Neighbor explicitly for a particular prefix.
>
> How do you think ?.
>
> Thanks and Regards,
> Abhay
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
http://www1.ietf.org/pipermail/rtgwg/attachments/20071013/78ea50da/attachmen
t.html
>
> ------------------------------
>
> Message: 4
> Date: Sat, 13 Oct 2007 06:19:48 EDT
> From: [e-mail]
> Subject: Re: "Basic Specification for IP Fast-Reroute: Loop-free
> Alternates"
> To: [e-mail]
> Cc: [e-mail]
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> 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
> [e-mail]:
>
> [e-mail]_ (mailto:[e-mail])  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.
>
>
> 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:
> [e-mail]_ (mailto:[e-mail])
> Date:
> Mon,  8 Oct 2007 10:09:46 EDT
> To:
> [e-mail]_ (mailto:[e-mail])
> To:
> [e-mail]_ (mailto:[e-mail])
> CC:
> [e-mail]_ (mailto:[e-mail])
> (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
>
>
>
>
>
>
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
http://www1.ietf.org/pipermail/rtgwg/attachments/20071013/ebd20798/attachmen
t.html
>
> ------------------------------
>
> _______________________________________________
> rtgwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rtgwg
>
>
> End of rtgwg Digest, Vol 37, Issue 8
> ************************************




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