Hi Michael,
I agree - hopefully nobody has implemented this yet :^). Here is an update to
the errata for review. I used the same terminology as is used in RFC 2328's
section 16.1, step 1.
*** rfc5340.txt 2010-01-31 15:28:35.000000000 -0500
--- rfc5340.txt.errata 2010-03-01 10:56:04.000000000 -0500
***************
*** 2510,2521 ****
for a transit network is a combination of the Interface ID and
OSPF Router ID of the network's Designated Router.
! o In Step 2, when a router Vertex V has just been added to the
! shortest-path tree, there may be multiple LSAs associated with the
! router. All router-LSAs with the Advertising Router set to V's
! OSPF Router ID MUST be processed as an aggregate, treating them as
! fragments of a single large router-LSA. The Options field and the
!
--- 2510,2520 ----
for a transit network is a combination of the Interface ID and
OSPF Router ID of the network's Designated Router.
! o In Step 2, when a router Vertex V other than the root (which is
! the router doing the calculation) has just been added to the
! shortest-path tree and the router-LSA R-bit is not set in the
! LSA options, Vertex V's links are ignored and the next vertex on
! the candidate list should be examined as described in Step 3.
***************
*** 2524,2538 ****
RFC 5340 OSPF for IPv6 July 2008
router type bits (bits Nt, V, E, and B) should always be taken
from the router-LSA with the smallest Link State ID.
o Step 2a is not needed in IPv6, as there are no longer stub network
links in router-LSAs.
! o In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is
! not set in the LSA options, the transit link W is ignored and V's
! next link is examined.
o In Step 2b, if W is a router, there may again be multiple LSAs
associated with the router. All router-LSAs with the Advertising
--- 2523,2542 ----
RFC 5340 OSPF for IPv6 July 2008
+ o Also In Step 2, when a router Vertex V has just been added to the
+ shortest-path tree, there may be multiple LSAs associated with the
+ router. All router-LSAs with the Advertising Router set to V's
+ OSPF Router ID MUST be processed as an aggregate, treating them as
+ fragments of a single large router-LSA. The Options field and the
router type bits (bits Nt, V, E, and B) should always be taken
from the router-LSA with the smallest Link State ID.
o Step 2a is not needed in IPv6, as there are no longer stub network
links in router-LSAs.
! o In Step 2b, if W is a router and the router-LSA V6-bit is not set
! in the LSA options, the transit link to W is ignored and V's next
! link is examined.
o In Step 2b, if W is a router, there may again be multiple LSAs
associated with the router. All router-LSAs with the Advertising
Thanks,
Acee
On Feb 26, 2010, at 7:24 PM, Michael Barnes wrote:
> Hi Acee,
>
> Another question regarding the R-bit. If V is the root of the SPF tree
> (e.g. it is the router doing the SPF) with the current rules it will not
> install any OSPF routes into its own RIB. I don't think this is really
> the behavior that is desired. If V is the root then don't we want to
> ignore the R-bit?
>
> Thanks,
> Michael
>
>
> -------- Original Message --------
> Subject: [OSPF] [Technical Errata Reported] RFC5340 (2046)
> Date: Wed, 17 Feb 2010 12:45:00 -0800 (PST)
> From: RFC Errata System <[email protected]>
> To: [email protected], [email protected], [email protected],
> [email protected], [email protected], [email protected],
> [email protected], [email protected]
> CC: [email protected], [email protected]
>
>
> The following errata report has been submitted for RFC5340,
> "OSPF for IPv6".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5340&eid=2046
>
> --------------------------------------
> Type: Technical
> Reported by: Acee Lindem <[email protected]>
>
> Section: 4.8.1
>
> Original Text
> -------------
> o In Step 2, when a router Vertex V has just been added to the
> shortest-path tree, there may be multiple LSAs associated with the
> router. All router-LSAs with the Advertising Router set to V's
> OSPF Router ID MUST be processed as an aggregate, treating them as
> fragments of a single large router-LSA. The Options field and the
>
>
>
>
> Coltun, et al. Standards Track [Page 45]
> ^L
> RFC 5340 OSPF for IPv6 July 2008
>
>
> router type bits (bits Nt, V, E, and B) should always be taken
> from the router-LSA with the smallest Link State ID.
>
> o Step 2a is not needed in IPv6, as there are no longer stub network
> links in router-LSAs.
>
> o In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is
> not set in the LSA options, the transit link W is ignored and V's
> next link is examined.
>
>
> Corrected Text
> --------------
> o In Step 2, when a router Vertex V has just been added to the
> shortest-path tree and the router-LSA R-bit is not set in the
> LSA options, Vertex V's links are ignored and the next vertex on
> the candidate list should be examined as described in Step 3.
>
>
>
> Coltun, et al. Standards Track [Page 45]
> ^L
> RFC 5340 OSPF for IPv6 July 2008
>
>
> o Also In Step 2, when a router Vertex V has just been added to the
> shortest-path tree, there may be multiple LSAs associated with the
> router. All router-LSAs with the Advertising Router set to V's
> OSPF Router ID MUST be processed as an aggregate, treating them as
> fragments of a single large router-LSA. The Options field and the
> router type bits (bits Nt, V, E, and B) should always be taken
> from the router-LSA with the smallest Link State ID.
>
> o Step 2a is not needed in IPv6, as there are no longer stub network
> links in router-LSAs.
>
> o In Step 2b, if W is a router and the router-LSA V6-bit is not set
> in the LSA options, the transit link to W is ignored and V's next
> link is examined.
>
>
>
> Notes
> -----
> This changes reflects the fact that the R-bit and the V6-bit should not
> be handled identically. The R-bit allows the router to participate in
> the IPv6 unicast topology but does not allow transit traffic. The V6-bit
> doesn't allow either. This problem was pointed out by Balaji Ganesh.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC5340 (draft-ietf-ospf-ospfv3-update-23)
> --------------------------------------
> Title : OSPF for IPv6
> Publication Date : July 2008
> Author(s) : R. Coltun, D. Ferguson, J. Moy, A. Lindem
> Category : PROPOSED STANDARD
> Source : Open Shortest Path First IGP
> Area : Routing
> Stream : IETF
> Verifying Party : IESG
> _______________________________________________
> OSPF mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ospf
>
> _______________________________________________
> OSPF mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
