Subject: [OSPF] ospfv3: next hop calculation for adjacent router's prefixes on bradcast link.

From: "Goyal, Manoj" <[email-masked]>
Date: Thu, 26 Apr 2007 18:47:09 -0700

Hi,
I have a doubt in the determination of the next hop
for the adjacent router's prefixes on a Broadcast link.

                R2 (DR, pfx: n2)
                |L2
                |      L3
    R1-------------------R3 (pfx: n3)

The router R1 is the calculating router and R2 is the DR.
R2 has prefix n2 on the link and R3 has n3 and the link local
address are L2 and L3 respectively.

Here the DR R2 generates the Intra-Area-Prefix(IAP) Lsa
for the network with prefixes n2 and n3 in that.

While calculating the routing table, R1 goes through the
IAP lsa of R2 and calculates the next hop for both
n2 and n3 as L2 only.

This will cause wrong forwarding
from R1 to R2 for the packets destined to n3.
In the draft, there does not seem to be a mention of
this situation.

In this case, to calculate the right next hop, the R1
has to look at the Link-Lsa of R3 and see that
the prefix n3 appears in it, then install the route
n3 with next-hop as Link-Local address from this Link Lsa.

Is there something I am missing here?
Though the purpose 2 of the link-lsa indirectly explains it.

Thanks,
Manoj
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

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

---

From: Acee Lindem <[email-masked]>
Date: Fri, 27 Apr 2007 08:59:17 -0400

Hi Manoj,

I agree that is not unclear. I've modified section 3.8.2 in the RFC  
2740 update.

***************
*** 2698,2713 ****

      In IPv6, the calculation of the next hop's IPv6 address (which  
will
      be a link-local address) proceeds along the same lines as the IPv4
!    next hop calculation (see Section 16.1.1 of [OSPFV2]).  The only
!    difference is in calculating the next hop IPv6 address for a router
!    (call it Router X) which shares a link with the calculating router.
!    In this case the calculating router assigns the next hop IPv6  
address
!    to be the link-local interface address contained in Router X's  
Link-
!    LSA (see Appendix A.4.9) for the link.  This procedure is necessary
!    for some link types, for example NBMA, where the two routers  
need not
!    be neighbors and might not be exchanging OSPF Hello packets.  For
!    other link types, the next hop address may be determined via the  
IPv6
!    source address in the neighbor's Hello packet.

   3.8.3.  Calculating the inter-area routes

--- 2698,2724 ----

      In IPv6, the calculation of the next hop's IPv6 address (which  
will
      be a link-local address) proceeds along the same lines as the IPv4
!    next hop calculation (see Section 16.1.1 of [OSPFV2]).  However,
!    there are some differences.  When calculating the next hop IPv6
!    address for a router (call it Router X) which shares a link with  
the
!    calculating router, the calculating router assigns the next hop  
IPv6
!    address to be the link-local interface address contained in Router
!    X's Link- LSA (see Appendix A.4.9) for the link.  This procedure is
!    necessary for some link types, for example NBMA, where the two
!    routers need not be neighbors and might not be exchanging OSPF  
Hello
!    packets.  For other link types, the next hop address may be
!    determined via the IPv6 source address in the neighbor's Hello
!    packet.
!
!    Additionally, when calculating routes for the area's intra-area-
!    prefix-LSAs, the parent vertex can be either a router-LSA or  
network-
!    LSA.  This is in contrast to the second stage of the OSPFv2 intra-
!    area SPF (Section 16.1 in [OSPFV2]) where the parent vertex is  
always
!    a router-LSA.  In the case where the intra-area-prefix-LSA's
!    referenced LSA is a directly connected network-LSA, the prefixes  
are
!    also considered to be directly connected.  In this case, the  
next-hop
!    is solely the outgoing link and no IPv6 next hop address is  
selected.

   3.8.3.  Calculating the inter-area routes

Thanks,
Acee

---

From: "Jin Wang" <[email-masked]>
Date: Sun, 29 Apr 2007 10:29:52 +0800

rfc2328 states that when the cost of a virtual link changes, a new 
router-LSA should be originated for the backbone area.

The calculating result of 16.3(choosing another forwarding path different 
to virtual link path) will lead to new router-LSA generation in backbone 
area? This new chosen path can be regarded as virtual-link cost change?If 
no,I feel only some ABR(related to this transit area) or some other 
non-backbone areas attached to these ABRs can get the optimal path(via 
new-generated summary LSA).But for some internal routers in backbone area 
may not be able to forward traffic by best path because they get none of 
new router-lsa notification.

Pls correct me and thanks in advance.

---

From: Anton Smirnov <[email-masked]>
Date: Sun, 29 Apr 2007 11:15:26 +0200

Hi Jin,
    16.3 can update only backbone paths. Virtual link can be laid down 
only via non-backbone areas. So I don't see any scenario when updating 
path via transit area can change cost of virtual link.

Anton

Jin Wang wrote:
> The calculating result of 16.3(choosing another forwarding path 
> different to virtual link path) will lead to new router-LSA generation 
> in backbone area? This new chosen path can be regarded as virtual-link 
> cost change?If no,I feel only some ABR(related to this transit area) or 
> some other non-backbone areas attached to these ABRs can get the optimal 
> path(via new-generated summary LSA).But for some internal routers in 
> backbone area may not be able to forward traffic by best path because 
> they get none of new router-lsa notification.
>

---

From: "Jin Wang" <[email-masked]>
Date: Sun, 29 Apr 2007 18:29:33 +0800

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

Anton Smirnov <[email-masked]>
2007-04-29 17:15
 
        收件人：        Jin Wang <[email-masked]>
        抄送：  OSPF List <[email-masked]>
        主题：  Re: [OSPF] Doubt for virtual link cost ?

    Hi Jin,

Anton

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: Anton Smirnov <[email-masked]>
Date: Sun, 29 Apr 2007 14:23:34 +0200

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

---

From: Acee Lindem <[email-masked]>
Date: Sun, 29 Apr 2007 16:11:15 -0400

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

---

From: Acee Lindem <[email-masked]>
Date: Sun, 29 Apr 2007 16:11:15 -0400

Hi Anton, Jin,

---

From: Acee Lindem <[email-masked]>
Date: Sun, 29 Apr 2007 16:11:29 -0400

Hi Anton, Jin,

ietf.org; Sun, 29 Apr 2007 16:12:21 -0400
From: Acee Lindem <[email-masked]>
Subject: Re: [OSPF] Doubt for virtual link cost ?
Date: Sun, 29 Apr 2007 16:11:29 -0400
To: Anton Smirnov <[email-masked]>
Cc: OSPF List <[email-masked]>, Jin Wang <[email-masked]>

Hi Anton, Jin,

---

From: 章魁 <[email-masked]>
Date: Mon, 30 Apr 2007 14:48:15 +0800

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,

---

From: "Abhay D.S" <[email-masked]>
Date: Mon, 30 Apr 2007 15:55:25 +0800

It is a network design problem (NDP).

Assigning OSPFv2 weights can help to solve this problem

---

From: Acee Lindem <[email-masked]>
Date: Mon, 30 Apr 2007 08:28:14 -0400

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

---

From: Kui Zhang <[email-masked]>
Date: Mon, 30 Apr 2007 21:09:17 +0800

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,

Thanks,
Acee