Hi Rajesh, What situation are you talking about? If it is when the R-bit is set, I don't see why there would be any problem with the Intra-area-prefix-LSA corresponding to the Network-LSA. Acee On Mar 1, 2010, at 1:05 AM, Rajesh Shetty wrote:
> > Dear All, > > Irrespective of whether V is root or not > V's Intra Area Prefix with reference type Router will get installed to the > RIB. But V's Intra Area Prefix with reference type Network will not get > installed, whether this behavior is as expected? > > Thanks > Rajesh > > > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email immediately and delete it! > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Michael Barnes > Sent: Saturday, February 27, 2010 5:54 AM > To: Acee Lindem > Cc: [email protected] > Subject: [OSPF] Further R-Bit clarification [Fwd: [Technical Errata > Reported] RFC5340 (2046)] > > 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 _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
