Re: [OSPF] OSPF GR query

[Acee Lindem <[e-mail]>]

Hi Sujay,

On Jan 2, 2007, at 12:42 AM, sujay gupta wrote

<pruned - I don't like snipets of my E-mails to be quoted out of  
context.>


>
> While going with the basic OSPF protocol working, when the helper
> exits.
> -before reaching Full State would be to regenerate LSA's, giving a  
> snapshot
> of the incomplete state with the Restarting router, causing an  
> "inconsistent"
> lsa generation which in turn would cause the restarting router exit  
> GR.
> -after reaching Full State would be to regenerate LSA's, but this  
> time a duped LSA
> reporting "inconsistent" states, which in turn would cause the  
> restarting router to
> exit GR.
> While I immediately see 'wee' bit of an ethical problem by this  
> approach(for it looks more like a hack ;), it is still a way of  
> explicit signaling,  works for me!  Some other ways could have been  
> "a one-way hello" or "lls signaling".


It's not as if this mechanism (originally conceived by John Moy)  
didn't receive
ample review while RFC 3623 was in draft state. If you look at the  
implementation
report (RFC 4167), you'll see that there are quite a few  
implementations so not
everybody was confused. Since the sending of an inconsistent LSA has  
been
standardized, the motivation for a new mechanism would need to be due to
a requirement as opposed to the fact that some people are confused.

Thanks,
Acee

>
> Acee, with my limited experience in the OSPF WG, I have had and  
> seen confusions.
> Please note RFC3623 Exit GR procedures (Section 3.2) does not  
> entail the helper GR to produce inconsistent LSA's, an addendum  
> should have a better future rather than raising the same queries  
> again.
>
> There have been some more issues raised on the GR and update by  
> Mitchell, which I shall shortly address in a separate e-mail.
>
> Best Regards & HNY'07,
> -Sujay
>
>
>
>
>
>
>
>
>
>
> On 12/5/06, Acee Lindem <[e-mail]> wrote:
> Hi Sujay,
> sujay gupta wrote:
> > Hi Acee,
> > A late mail on this thread.
> >
> > given the scenario if R3-R1 is a stub area
> > and the incoming LSA is a type-5, even with strict LSA
> > checking enabled will not exit Helper mode.
> I'm not sure what the network picture looks like but a helper
> router can always terminate graceful restart by flooding an
> inconsistent router or network LSA to the restarting  router.
>
> Thanks,
> Acee
>
> >
> > It can be a nice idea to give some explicit notification
> > by R2 to R1 about exiting helper mode.
> >
> > As rightly pointed by you the above conditions and more
> > has been causing some confusion for some time.
> > Our proposal ;
> > http://tools.ietf.org/wg/ospf/draft-holla-ospf-update-graceful- 
> restart-02.txt
> >
> > hopefully resolves this.
> > Could we add this as an addendum/reference to RFC3623?, purely an
> > add-on.
> > Best Regards.
> > Sujay
> >
> > On 10/5/06, Acee Lindem <[e-mail] > wrote:
> >>
> >> Khan Amir-G20247 wrote:
> >> > Hi Ace
> >> >
> >> > But reaching to a FULL state is not one of the conditions for
> >> Helper to
> >> > quit Helper mode, I guess a Helper who has reached
> >> > to FULL state with its restarting router will wait for Grace LSAs
> >> to be
> >> > flushed or GR timeout to happen for exiting Helper mode.
> >> >
> >> No - The presumption is when you reach FULL state you don't need to
> >> "quit"
> >> helping - you have "finished" helping. Over the years, there  
> have been a
> >> few situations that could have been better documented - however,  
> this
> >> never
> >> caused any confusion in the past.
> >>
> >> Thanks,
> >> Acee
> >>
> >> > Regards
> >> > Aamir
> >> >
> >> >
> >> > -----Original Message-----
> >> > From: Acee Lindem [mailto:[e-mail]]
> >> > Sent: Thursday, October 05, 2006 8:00 PM
> >> > To: Khan Amir-G20247
> >> > Cc: [e-mail]
> >> > Subject: Re: [OSPF] OSPF GR query
> >> >
> >> > Hello Amir,
> >> >
> >> > Khan Amir-G20247 wrote:
> >> >
> >> >>
> >> >>
> >> >> Hi
> >> >>
> >> >> I have query related to OSPF Graceful Restart.
> >> >>
> >> >> Consider this scenario:
> >> >>
> >> >>
> >> >>
> >> >> - Three Routers R1, R2 and R3 connected via Broadcast networks.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> - Where R1 is a DR on both the segments, where as R2 and R3  
> are in
> >> >> DR-other
> >> >> - Now R1 wants to perform GR, R2 and R3 agrees to be its  
> Helpers.
> >> >> - Now after restart R1 will try to form adjacency with both  
> R2 and
> >> R3.
> >> >>
> >> >
> >> >
> >> >> - Lets say R1 and R2 had become FULL, while R1 and R3 had  
> reached
> >> >> Exstart state.   Now at this time R2 receives an LSA (any  
> type 1-5
> >> and
> >> >> 7, from some other router existing in the same area, not  
> pictured
> >> >> here) which he needs to flood to R1.
> >> >> - This will force R2 to quit Helper Status, while R1 and R3  
> are still
> >> >> in process of forming adjacency.
> >> >>
> >> >>
> >> > Since he has reached FULL state, he is no longer a helper router.
> >> >
> >> >> Considering above scenario, my doubts are:
> >> >>
> >> >> - How will R1 come to know that its Helper R2 has quit?
> >> >>
> >> >>
> >> > Since he has reached FULL state, he is no longer a helper router.
> >> >
> >> >> - Will the adjacency between R1 and R2 needs to go down, as  
> R2 quits
> >> >> helper mode?
> >> >>
> >> >>
> >> > No
> >> >
> >> >> - Will this effect the adjacency formation of R1 and R3?
> >> >>
> >> >>
> >> > No. R3 MAY exit helper status and re-originate a new router  
> LSA if he
> >> > receives the new LSA before reaching FULL state with R1 AND he  
> is has
> >> > strict-LSA-checking configured.
> >> >
> >> > Hope this helps,
> >> > Acee
> >> >
> >> >>
> >> >>
> >> >> Regards
> >> >> Aamir
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >>  
> ----------------------------------------------------------------------
> >> >> --
> >> >>
> >> >> _______________________________________________
> >> >> OSPF mailing list
> >> >> [e-mail]
> >> >> https://www1.ietf.org/mailman/listinfo/ospf
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> _______________________________________________
> >> OSPF mailing list
> >> [e-mail]
> >> https://www1.ietf.org/mailman/listinfo/ospf
> >>
> >
>
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ospf

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