I found it online, for free :-D
http://alumni.info.ucl.ac.be/suh//papers/conext-abstract-stefano.pdf I'm surprised to see an interest in that "problem". Is the issue of a real importance for the ISPs ? Pierre. On Wed, 16 May 2007, Pierre Francois wrote: > > > P.S. Don't take the link to paper unless you are an ACM member since > > the paper requires a login and subscription. I let my ACM membership > > lapse a long time ago since I found I didn't even have time to look at > > the pictures, let alone read the articles :^) > Halala, those who want the paper can send me an e-mail ;-) > > Pierre. > > > > > > > > > > > >> > >> Regards, > >> Sujay > >> > >> On 5/15/07, *Roch Guerin* <[EMAIL PROTECTED] > >> <mailto:[EMAIL PROTECTED]>> wrote: > >> > >> I guess this is a question of defining what "optimal" means. If > >> optimal means that packets should be forwarded along the VL, then > >> clearly there are cases where that may not happen, although as > >> Acee pointed out, this wont create (permanent0 routing loops > >> since no matter what packets are always forwarded in a manner > >> that consistently decreases their cost to the destination. > >> However, note that the cost decrease rule is not equivalent to > >> always selecting the shortest path. In particular, there are > >> many cases where actual packet forwarding follows a different > >> path from that the initial router computed. In some cases those > >> paths will be shorter than the original one (the VL case under > >> discussion is one such example), but not always. This is because > >> of the many situations where different routers have access to > >> different information, and the fact that there are non-cost based > >> precedence rules when selecting paths. > >> > >> For example, an internal router R0 could pick an ABR, say ABR1, > >> as its exit point from its area for a remote prefix /p/ because > >> the sum of its cost to ABR1 and the cost of the T3 for /p/ > >> advertised by ABR1 is the smallest among all possible choices. > >> However, if there is another ABR, say ABR2, on the (shortest) > >> path from R0 to ABR1, then ABR2 will hijack all the packets to > >> /p/ and will proceed to forward them onto its own shortest path > >> to /p/, even though this wont be the shortest path originally > >> selected by R0. And there are many other examples one can > >> construct, where actual packet forwarding is not along true > >> end-to-end shortest paths and where different routers have > >> differing views on what paths packets actually follow. None of > >> these behaviors create the risk of routing loops. > >> > >> Roch > >>> Hi, > >>> I fail to see as to how a non-optimal path will be picked up, > >>> for all > >>> ABR's adjoining the transit area will do a transit area summary lsa > >>> checking and route table modification if required. > >>> Noting that the only difference prior to transit area summary > >>> lsa checking and > >>> after will be the nexthop modified by the ABR to reach the same > >>> destination, and > >>> as IP is hop by hop forwarding any border router adjoining the > >>> transit area will pick > >>> up the optimum path( be it thru the VL or not). > >>> Am I miss something? > >>> Regds, > >>> Sujay > >>> > >>> > >>> On 4/30/07, *Kui Zhang* <[EMAIL PROTECTED] > >>> <mailto:[EMAIL PROTECTED]>> wrote: > >>> > >>> Hi Acee, > >>> > >>> Yes, a simple way to prevent this from happening is to > >>> configure a full mesh > >>> of virtual links between all ABRs in the transit area. > >>> And this makes IP FRR works well too. > >>> > >>> Thanks, > >>> Kui > >>> -----Original Message----- > >>> From: Acee Lindem [mailto:[EMAIL PROTECTED] > >>> <mailto:[EMAIL PROTECTED]>] > >>> Sent: Monday, April 30, 2007 8:28 PM > >>> To: ç« é > >>> Cc: 'Anton Smirnov'; 'OSPF List'; 'Jin Wang' > >>> Subject: Re: [OSPF] Doubt for virtual link cost ? > >>> > >>> Hi Kui, > >>> Yes - there could be an ABR for the transit area that takes a > >>> "shortcut" across the transit area for a non-virtual link > >>> path. Other > >>> routers in the backbone will not know about this path and > >>> may take > >>> other paths. However, this is not a problem since there is no > >>> possibility of a routing loop. Additionally, the situation > >>> can easily > >>> be remedied by configuring a virtual link between the > >>> transit area > >>> routers across the "shortcut" path. > >>> > >>> Thanks, > >>> Acee > >>> > >>> On Apr 30, 2007, at 2:48 AM, ç« é wrote: > >>> > >>> > Hi Acee, > >>> > I guess Jin is asking that a non-optimal path might be > >>> chosen when > >>> > other > >>> > routers in backbone area can't check the transit area's > >>> summary lsa to > >>> > update the intra-area route. This should be a drawback of > >>> virtual > >>> > link, I > >>> > think. > >>> > > >>> > Kui > >>> > -----Original Message----- > >>> > From: Acee Lindem [mailto:[EMAIL PROTECTED] > >>> <mailto:[EMAIL PROTECTED]>] > >>> > Sent: Monday, April 30, 2007 4:11 AM > >>> > To: Anton Smirnov > >>> > Cc: OSPF List; Jin Wang > >>> > Subject: Re: [OSPF] Doubt for virtual link cost ? > >>> > > >>> > Hi Anton, Jin, > >>> > I guess I don't really understand the point of controversy > >>> here. I > >>> > agree with Anton. Note that if there is not an active > >>> virtual link > >>> > then the non-backbone area is not a transit area. > >>> > Thanks, > >>> > Acee > >>> > On Apr 29, 2007, at 8:23 AM, Anton Smirnov wrote: > >>> > > >>> >> Jin, > >>> >> right. In network design where such scenario is > >>> possible you > >>> >> always > >>> >> can create VL between this ABR and ABR providing best path via > >>> >> transit > >>> >> area. This will make the best path 'visible' to other > >>> routers in > >>> >> backbone. > >>> >> > >>> >> Anton > >>> >> > >>> >> > >>> >> Jin Wang wrote: > >>> >>> > >>> >>> Thanks for anton's response. > >>> >>> But if so,only the traffic going through this ABR(determined > >>> >>> before 16.3 > >>> >>> calculating result) is forwarded by the new optimal > >>> path.For those > >>> >>> other > >>> >>> traffic not forwarded via this ABR(determined by 16.1 & > >>> 16.2) in the > >>> >>> backbone will not consider the new path(via ABR) even path is > >>> >>> shorter.right? > >>> >>> > >>> >>> > >>> >>> Best regards, > >>> >>> > >>> >>> Wangjin > >>> >>> Accton Technology China Company Ltd. > >>> >>> Shanghai R&D Center > >>> >>> TEL:+86-021-64859922*6227 > >>> >>> E-mail:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > >>> >>> Web Site: www.accton.com.cn <http://www.accton.com.cn> > >>> >>> > >>> >> > >>> >> > >>> >> _______________________________________________ > >>> >> OSPF mailing list > >>> >> [email protected] <mailto:[email protected]> > >>> >> https://www1.ietf.org/mailman/listinfo/ospf > >>> > > >>> > > >>> > _______________________________________________ > >>> > OSPF mailing list > >>> > [email protected] <mailto:[email protected]> > >>> > https://www1.ietf.org/mailman/listinfo/ospf > >>> > > >>> > > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> OSPF mailing list > >>> [email protected] <mailto:[email protected]> > >>> https://www1.ietf.org/mailman/listinfo/ospf > >>> > >>> > >>> > >>> ------------------------------------------------------------------------ > >>> _______________________________________________ > >>> OSPF mailing list > >>> [email protected] <mailto:[email protected]> > >>> https://www1.ietf.org/mailman/listinfo/ospf > >>> > >> > >> > >> > >> _______________________________________________ > >> OSPF mailing list > >> [email protected] <mailto:[email protected]> > >> https://www1.ietf.org/mailman/listinfo/ospf > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > OSPF mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/ospf > > > > > _______________________________________________ > OSPF mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ospf
