Santhosh

Santosh P K wrote:
        > 2    Seciont 2 point 2
>         The restarting router runs its OSPF routing calculations, as
>          specified in Section 16 of [1].  This is necessary to return
>          any OSPF virtual links to operation.  However, the restarting
>          router does *not* install OSPF routes into the system's
>          forwarding table(s) and relies on the forwarding entries that
>          it installed prior to the restart.
> 
> At wht point of time I need to run SPF when the router comes up?
> Because after adjacency is formaed the restarting router exits
> graceful restart and anyways at this point it calculates SPF and
> update forwarding table.

        SPF will be scheduled or invoked as specified in the RFC 2328.
So, there is   no need to schedule SPF at any other point of time
[specially in graceful-restart mode]. The only thing that needs to be
handled is that, no route should be installed when the router is running
in the graceful-restart mode.

Regards
Sundar

-----Original Message-----
From: Erblichs [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 08, 2007 1:07 AM
To: Santosh P K
Cc: [email protected]
Subject: Re: [OSPF] graceful restart doubt

Santosh,

        Just an an answer to 1.

        Thus, I read "an LSA" as a Grace LSA as an
        example..

        Within "Router X recieves an LSA"...  

        Grace LSAs are Opaque LSAs and Opaque capability
         is first required for GR. Secondly, then the
         understanding of what a Grace-LSA is, and then
         third the willingness to respond to a recieved
         Grace-LSA.

        Mitchell Erblich
        -----------------

Santosh P K wrote:
> 
> Hi all,
>      I have couple of doubt in graceful restart for ospf.
> 
> 1.      Router X receives an LSA that is inconsistent with
its pre-
>          restart router-LSA.  For example, X receives a
router-LSA
>          originated by router Y that does not contain a
link to X, even
>          though X's pre-start router-LSA did contain a
link to Y.  This
>          indicates that either a) Y does not support
graceful restart,
>          b) Y never received the grace-LSA or c) Y has
terminated its
>          helper mode for some reason (Section 3.2).
> 
> Why is it really required to validate the router LSA?
> In all the above three cases mentioned the restarting
router can come
> to know about inconsistency in hello packet itself, as the
hello
> received by that restarting router from its previously
adjacent
> neighbor would contain a one-way.
> 
> 2    Seciont 2 point 2
>         The restarting router runs its OSPF routing
calculations, as
>          specified in Section 16 of [1].  This is
necessary to return
>          any OSPF virtual links to operation.  However,
the restarting
>          router does *not* install OSPF routes into the
system's
>          forwarding table(s) and relies on the forwarding
entries that
>          it installed prior to the restart.
> 
> At wht point of time I need to run SPF when the router
comes up?
> Because after adjacency is formaed the restarting router
exits
> graceful restart and anyways at this point it calculates
SPF and
> update forwarding table.
> 
> Thanks and regards
> Santosh P K
> 
> _______________________________________________
> OSPF mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ospf


Santosh P K wrote:
> 
> Hi all,
>      I have couple of doubt in graceful restart for ospf.
> 
> 1.      Router X receives an LSA that is inconsistent with its pre-
>          restart router-LSA.  For example, X receives a router-LSA
>          originated by router Y that does not contain a link to X,
even
>          though X's pre-start router-LSA did contain a link to Y.
This
>          indicates that either a) Y does not support graceful restart,
>          b) Y never received the grace-LSA or c) Y has terminated its
>          helper mode for some reason (Section 3.2).
> 
> Why is it really required to validate the router LSA?
> In all the above three cases mentioned the restarting router can come
> to know about inconsistency in hello packet itself, as the hello
> received by that restarting router from its previously adjacent
> neighbor would contain a one-way.
> 
> 2    Seciont 2 point 2
>         The restarting router runs its OSPF routing calculations, as
>          specified in Section 16 of [1].  This is necessary to return
>          any OSPF virtual links to operation.  However, the restarting
>          router does *not* install OSPF routes into the system's
>          forwarding table(s) and relies on the forwarding entries that
>          it installed prior to the restart.
> 
> At wht point of time I need to run SPF when the router comes up?
> Because after adjacency is formaed the restarting router exits
> graceful restart and anyways at this point it calculates SPF and
> update forwarding table.
> 
> Thanks and regards
> Santosh P K
> 
> _______________________________________________
> OSPF mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ospf

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

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. 
Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the 
opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is 
strictly prohibited. If you have
received this email in error please delete it and notify the sender 
immediately. Before opening any mail and 
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

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

Reply via email to