Subject: Re: [OSPF] Doubt for virtual link cost ?

From: "sujay gupta" <[email-masked]>
Date: Tue, 15 May 2007 16:41:43 +0530

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-masked]> 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-masked]]
> 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-masked]]
> > 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-masked]
> >>> Web Site:www.accton.com.cn
> >>>
> >>
> >>
> >> _______________________________________________
> >> OSPF mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/ospf
> >
> >
> > _______________________________________________
> > OSPF mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ospf
> >
> >
>
>
>
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ospf
>
_______________________________________________
OSPF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf

---

From: "sujay gupta" <[email-masked]>
Date: Tue, 15 May 2007 16:47:19 +0530

(Resending as the previous mail was incomplete.)

> 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

   The Transit area summary lsa check is placed after Intra and Inter area
route calculation
    so all routes will be touched if required.

Am I missing something?

> > From: Acee Lindem [mailto:[email-masked] ]
> > >>> Web Site: www.accton.com.cn
> > >>>
> > >>
> > >>

---

From: Roch Guerin <[email-masked]>
Date: Tue, 15 May 2007 07:47:21 -0400

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
> Noting that the only difference prior to transit area summary lsa
> checking and
> On 4/30/07, *Kui Zhang* <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Acee,
>
>     Yes, a simple way to prevent this from happening is to configure a
>     full mesh
>     From: Acee Lindem [mailto:[email-masked] <mailto:[email-masked]>]
>     other paths.However, this is not a problem since there is no
>     > From: Acee Lindem [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     >>> E-mail:[email-masked] <mailto:[email-masked]>
>     >>> Web Site: www.accton.com.cn <http://www.accton.com.cn>
>     >>>
>     >>
>     >>
>     >> [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Pierre Francois <[email-masked]>
Date: Tue, 15 May 2007 13:57:32 +0200

There is a (very short) paper formulating the conditions that
favour the occurence of such sub-optimal paths. It is entitled
"Forwarding deflection in multi-area OSPF",
and is accessible from http://portal.acm.org/citation.cfm?id=1095967

Pierre.

Roch Guerin 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.
>
> 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,
>> as IP is hop by hop forwarding any border router adjoining the
>> transit area will pick
>>     Yes, a simple way to prevent this from happening is to configure
>>     a full mesh

---

From: "sujay gupta" <[email-masked]>
Date: Wed, 16 May 2007 11:35:04 +0530

Hi Roch,
Agree with your explanation, "optimal" definitely in this context does not
mean that
the packet should be forwarded by the VL, in fact that is the reason why we
perform
the transit area summary lsa checks to rectify the reachability thru a
better path.

Again going with your example, as the next forwarding decision or the path
is taken by the
intermediate routers and not by the internal router R0, there should not
arise a case when a
packet forwarded by an internal router in the backbone reaching a ABR
adjacent to a transit
area will not be forwarded using the best path, which I believe was the
point of discussion in
this thread.( I am yet to read the link suggested by Pierre )

Regards,
Sujay

On 5/15/07, Roch Guerin <[email-masked]> wrote:
> 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
> 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,
> ------------------------------
>
> [email-masked]://www1.ietf.org/mailman/listinfo/ospf
>
>
>
>

---

From: Roch Guerin <[email-masked]>
Date: Wed, 16 May 2007 07:08:29 -0400

Sujay,

It is very easy to construct examples where a packet does not travel on
the "best," i.e., shortest path. The scenario I outlined in my previous
email is one such case that applies whether the local area is a transit
area or not.

Specifically, R0 picks ABR1 as its exit point for prefix /p/, because
ABR1 advertises a T3-summary LSA for /p/ with a cost of /x/, so that
when added to the cost of /y/ from R0 to ABR1, /x/+/y/ is the smallest
total cost. Now, on their way to ABR1, packets from R0 and destined for
/p/ happen to traverse a router that is also an ABR, ABR2. ABR2 had
advertised a cost of /z/>/x/ to /p/, so that /u/+/z/>/y/+/z/, where
/u/</y/ is the cost of the shortest path from R0 to ABR2, so that ABR2
is not the "best" exit point to reach /p/. However, ABR2 will intercept
all packets destined for /p/ and forward them on its own "shortest" path
to /p/.

You can construct other similar "fun" examples with external routes when
1583 compatibility is not turned on because of the impact of area in
selecting an ASBR, and more traditionally summarization can also be
responsible for lots of quirky scenarios where non shortest paths are used.

The good news is that while "quirky" all these deviations are entirely
predictable as they simply follow the letter of the specs (that is, if
your implementation is conformant ;-))

Roch
> Hi Roch,
> Agree with your explanation, "optimal" definitely in this context does
> not mean that
> the packet should be forwarded by the VL, in fact that is the reason
> why we perform
> Again going with your example, as the next forwarding decision or the
> path is taken by the
> intermediate routers and not by the internal router R0, there should
> not arise a case when a
> area will not be forwarded using the best path, which I believe was
> the point of discussion in
> On 5/15/07, *Roch Guerin* <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     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,
>>         Yes, a simple way to prevent this from happening is to
>>         configure a full mesh

---

From: Roch Guerin <[email-masked]>
Date: Wed, 16 May 2007 07:10:48 -0400

P.S.: To specifically address the scenario you point to below, namely,
packet forwarding in the backbone, you can use exactly the same example
as I described in my previous email but now replacing exit point with
entry point.

---

From: Acee Lindem <[email-masked]>
Date: Wed, 16 May 2007 08:15:23 -0400

Hi Sujay,

On May 16, 2007, at 2:05 AM, sujay gupta wrote:

> Hi Roch,
> Agree with your explanation, "optimal" definitely in this context  
> does not mean that
> the packet should be forwarded by the VL, in fact that is the  
> reason why we perform
> the transit area summary lsa checks to rectify the reachability  
> thru a better path.
>
> Again going with your example, as the next forwarding decision or  
> the path is taken by the
> intermediate routers and not by the internal router R0, there  
> should not arise a case when a
> packet forwarded by an internal router in the backbone reaching a  
> ABR adjacent to a transit

Here is a simple case. Consider a transit area with 3 ABRs: ABR-1,  
ABR-2, and ABR-3. ABR-1 and ABR-3 are connected via a virtual link  
but ABR-2 is not. A backbone area internal router BBIR-1 is adjacent  
to ABR-2. There may be shorter paths for BBIR-1 through ABR-2 via the  
transit area but it will not take these paths since they are not  
advertised. If BBIR-1 happens to select a path that includes ABR-2,  
ABR=2 may use the shorter path through the transit area even though  
that was not the path BBIR-1 computed.

Hope this helps,
Acee
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 :^)

> matter what packets are always forwarded in a manner that  
> 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,
>> On 4/30/07, Kui Zhang <[email-masked] > wrote:
>> Hi Acee,
>>

---

From: Pierre Francois <[email-masked]>
Date: Wed, 16 May 2007 14:20:09 +0200

> 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.
>>     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
>>     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,
>>>     Noting that the only difference prior to transit area summary
>>>     lsa checking and

---

From: "Jin Wang" <[email-masked]>
Date: Thu, 17 May 2007 15:18:18 +0800

RFC3101 2.5 Calculating type-7 as external routes (3) states:

Else if the destination is a Type-7 default route (destination
          ID = DefaultDestination) and one of the following is true,
          then do nothing with this LSA and consider the next in the
          list:

            o  The calculating router is a border router and the LSA has
               its P-bit clear.  Appendix E describes a technique
               whereby an NSSA border router installs a Type-7 default
               LSA without propagating it.

            o  The calculating router is a border router and is
               suppressing the import of summary routes as Type-3
               summary-LSAs.
            [NSSA]

Suppose user perform following steps in scenario(there is one ABR and ASBR 
in NSSA area):
1)ASBR generate type-7 default route LSA to redistribute default route 
from static route source.
2)In ABR,Create type 7 default route LSA via command like 
"default-route-originate" for this NSSA area.

After step 2),the ABR calculation also should not consider type-7 default 
route LSA redistribted by ASBRs?
Am I missing something?please correct me.

Best regards,

Wangjin

---

From: Pierre Francois <[email-masked]>
Date: Thu, 17 May 2007 14:14:02 +0200 (CEST)

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.