Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA

From: Vishwas Manral <[email-masked]>
Date: Thu, 15 Dec 2005 21:30:42 -0800

Hi,

> When a helper exits - all its neighbors are aware of its exit and
> are going to route around it.
> If it cannot help anymore then the premise of having cooperating 
> routers is broken anyway.
I agree totally with Padma.

Thanks,
Vishwas
-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Padma
Pillay-Esnault
Sent: Friday, December 16, 2005 10:54 AM
To: [email-masked]
Subject: Re: WG Consideration of
draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV
to Grace LSA

Ashok wrote:

>Hi Acee, 
>
>I agree that the use of an LSA to signal a one time event is different
>from the nature of LSA in OSPF. At the time the draft was written, we
>were unaware of the Manet proposals and the plan to bring back LLS to
>augment GR mechanism. Piggybacking the exit signal on the link local
>grace LSA, was our way of achieving LLS without actually employing the
>ideas in the expired LLS draft. Also, the requirement that this signal
>to be not stored in the database or flushed later, is a natural
>consequence of the Grace LSA format and usage, and does not require any
>special handling.
>  
>

I don't think that there was any agreement to bring LLS in GR but rather

if such signalling
was indeed needed - LLS might be a better choice. I am still not 
convinced about the need/utility
of signalling an exit for the helper.

GR is a best effort mechanism and this case will drop packets as well in

a non-restart situation.
Albeit, we might want to reduce the time of blackholing but I don't 
think this is the way to go

When a helper exits - all its neighbors are aware of its exit and are 
going to route around it.
If it cannot help anymore then the premise of having cooperating routers

is broken anyway.

Padma

>If LLS is going to be brought back from the dead, then perhaps the LLS
>method needs discussion on its merit for signaling helper exit. I do
>have some reservations on using LLS in hello packets to achieve such
>signaling. The purpose of Hello packets is different and on broadcast
>networks, it just becomes messy.
>
>I am completely against using 1-way in hello packets to signal exit of
>Helper mode. The meaning of 1-way is defined by the Ospf protocol. It
is
>incorrect to add any implied meaning to it. If the Helper is already in
>state 2-way or above with the Nbr, then forcefully going to 1-way is
>completely wrong. The handling of exit signal is upto the restarting
>router.
>It may or may not tear down the adjacency (in what ever state it may
be)
>with the helper router. The purpose is merely to flush grace lsas. This
>was the intention of the exit-grace tlv. Sending 1-way in hello has
>other undesired consequences due to its primary meaning as defined by
>2328.
>
>Regards,
>Ashok
>    
>
>
>
>-----Original Message-----
>From: Mailing List [mailto:[email-masked]] On Behalf Of Acee
>Lindem
>Sent: Friday, December 16, 2005 6:30 AM
>To: [email-masked]
>Subject: WG Consideration of
>draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV
>to Grace LSA
>
><speaking as WG member>
>
>I'm totally against this extension for the following reasons.
>
>   1. It introduces a totally new flooding scope for LSAs. In this 
>context, they are
>       scoped only to the restarting neighbor.
>   2. It changes the semantics of the LSA from a persistent 
>advertisement to a
>       one-shot signal. The draft proposed that the LSA is not stored
in
>
>the link
>       state database and need not be purged (it simply ceases to exist
>once
>       it is ack'ed).
>
>IMHO, this changes the semantics of the grace LSA (and LSAs in general)
>too drastically. To make an analogy, it is like using your level to
>pound
>in a nail. It can be made to work but you may find out that you've
>broken
>your level.
>
>
>If we do agree there is a requirement for a potential helper router to 
>signal
>that graceful restart isn't inappropriate or the helper just isn't 
>feeling all that
>generous, then we should use one of the following mechanisms:
>
>   1. Link Local Signaling (LLS)
>   2. One-Way Hello
>
>I reject the supposition that this must wait until the next hello 
>interval. A unicast
>hello is much better suited to one-shot signaling than a LSA.  If you 
>want to
>make it reliable, you simply continue to signal until the restarting
>router
>terminates GR.
>
>Thanks,
>Acee
>
>  
>

---

From: Ashok <[email-masked]>
Date: Fri, 16 Dec 2005 13:54:11 +0800

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of
Vishwas Manral
Sent: Friday, December 16, 2005 1:31 PM
To: [email-masked]
Subject: Re: WG Consideration of
draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV
to Grace LSA

Hi,

This depends on an assumption on the kind of topology. It is not the
case always that there are other helpers in direct contact with the
helper who has exited helper mode. In real scenarios, connectivity
between routers may be maintained through other RPAs as well, with OSPF
learnt route being the favored one. (I know, the implementation details
bugbear :)) 
So, GR mechanism must ensure the quickest possible reaction to bad news.
While GR is best effort, Ospf with GR must not lead to longer
convergence times than Ospf without GR.
Regards,
Ashok

Thanks,
Vishwas
-----Original Message-----

if such signalling

a non-restart situation.

is broken anyway.

Padma

is
be)
in

---

From: sujay <[email-masked]>
Date: Fri, 16 Dec 2005 11:57:23 +0530

Hi Vishwas,

> going to route around it. If it cannot help anymore then the premise 
> of having cooperating routers is broken anyway.

- here all neighbors will be of aware of the helpers exit only after the
Nbr dead
Interval fires, 

Other nodes on the network until this point will use the Restarting
router
in its path.

It also implies if the Helper has decided to exit before the Nbr
interval timer
fires, all it does is recalculate its route tables and sends
reoriginates lsa's
Using these lsa's again , other helpers may choose to exit Helper mode ,
subject 
to interpretation of 'changed lsa's'.

Better still let them decide using the definition of 'topology change
lsa's' .

Couple with the above , send an explicit signalling from the helper
to Restarting router, it removes the grace lsa from all other helpers
the simplest
approach in triggering a router exit helper mode.

Best Regards,
Sujay

-----Original Message-----
Sent: Friday, December 16, 2005 11:01 AM

Hi,

> going to route around it. If it cannot help anymore then the premise 
> of having cooperating routers is broken anyway.

Thanks,
Vishwas
-----Original Message-----

if such signalling

a non-restart situation.

is broken anyway.

Padma

is
be)
in

---

From: "Abhay D.S" <[email-masked]>
Date: Fri, 16 Dec 2005 12:16:28 +0530

hi Group,
Amongst the various ideas (with due respect) of WG minds.

I dont see John Moy much in the discussions( do you know
what we have done to  OSPF now ? ) :-).

RFC 3623 is enough for graceful re-start mechanisms.

Using Exit Grace TLV modification is useful for RFC 3623.

Acee, using LLS is same as using Grace TLV with OSPF capabilities

draft.

Thanks,
Abhay

-----Original Message-----

Hi,

Thanks,
Vishwas
-----Original Message-----

if such signalling

a non-restart situation.

is broken anyway.

Padma

is
be)
in

---

From: "Abhay D.S" <[email-masked]>
Date: Fri, 16 Dec 2005 12:19:41 +0530

Addendum....

By the way, I dont see using non-helpers into networks
in future, unless the administrator is totally crazy and
want to make fun of Graceful restart.

Thanks,
Abhay

-----Original Message-----
From: Mailing List [mailto:[email-masked]]On Behalf Of sujay
Sent: Friday, December 16, 2005 11:57 AM
To: [email-masked]
Subject: Re: WG Consideration of

Hi Vishwas,

Best Regards,
Sujay

-----Original Message-----

Hi,

Thanks,
Vishwas
-----Original Message-----

if such signalling

a non-restart situation.

is broken anyway.

Padma

is
be)
in

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 16 Dec 2005 08:44:39 -0800

>- here all neighbors will be of aware of the helpers exit only after the
and how is that different in normal case OSPF ?

>Other nodes on the network until this point will use the Restarting
same in a normal ospf situation

>to interpretation of 'changed lsa's'.
other helpers maintain the restarting nbr up - it doesn't mean they are 
not running spf and
will reroute according to changes.

>approach in triggering a router exit helper mode.
Don't agree - how about the case you have a lone helper who doesn't 
interfere with routing path xcept for himself
or for a limited set of routers
you will bring down GR for everyone else. Doesn't look optimizing to me.

Padma

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 16 Dec 2005 09:13:47 -0800

>learnt route being the favored one. (I know, the implementation details

I am missing your point. In any LS protocol - the dead timer interval is 
going to be a factor.
The other helpers in direct contact will reroute eventually after dead 
interval.

>convergence times than Ospf without GR.

You are forgetting that a premise for all this is that you have a 
forwarding plane that works.

I don't see how you are achieving the "must" with the proposal.

Padma

---

From: sujay <[email-masked]>
Date: Sun, 18 Dec 2005 16:37:21 +0530

See Inline SUJ>

-----Original Message-----
Sent: Friday, December 16, 2005 10:15 PM

sujay wrote:

>- here all neighbors will be of aware of the helpers exit only after 
>the Nbr dead Interval fires,
>  
>

>router in its path.

>interval timer fires, all it does is recalculate its route tables and 
>sends reoriginates lsa's

>Couple with the above , send an explicit signalling from the helper to 
>Restarting router, it removes the grace lsa from all other helpers the 
>simplest approach in triggering a router exit helper mode.
>
>  
>

Padma

SUJ> It is a better bet to make the all the helpers go down as well
because
some thoughts;

(a) If there are other app's on the restarting router and they are using
the 
Fwd rout entries( case , ospf soft restart on the control plane, app
could be 
Say bgp) , how do we prevent them from using the invalid routes, without
exiting
GR?

(b) 3623, is based on the same premise as well See section 3.2,1,(b) ,
*all* helpers would 
Exit GR as well !( Note the caveat there as well.. " Such an option
will, however,
            increase the risk of transient routing loops and black
            holes." )

(c) Yet there are cases in which the helper need not exit,as rightly
pointed out by
Padma, these cases is best decided using the definintion of Topology
change lsa's.
If the helper does decide that it is a bad news(for the restaring
router), the explicit signalling is used.

(d) One case which comes easily to mind and cannot be handled using the
implicit checks is
Mentioned in Section 8 Case B from the draft.

Put here for a quick reference;
"
 Since the protocol [OSPFGR] does not provide a method for a helper 
   router to notify the restarting router, its exit of helper mode after

   the adjacency formation is complete, there are possibilities of 
   routing holes existing for a bounded period of time, grace LSA being 
   flushed or grace period expiry. 
    
   Ex:      
          
                         Area 0 
   RT1-----------------X-----------------RT2---------RT3 
                       | 
               Area 1  | 
                       | 
                      RT4 

   In the above topology RT1, X, RT2 and RT3 are all in area 0; X and 
   RT4 are in Area 1 which is a stub area. 
     
   Scenario: 
   X having initiated GR has completed adjacency formation with helpers 
   RT1 and RT2 and still in the process of forming adjacency with RT4. 
   At this point, RT3 originates a new type-5 LSA. Due to the nature of 
   the protocol, RT2 and RT1 will exit helper mode on receipt of this 
   LSA from RT3 and X respectively. Since, X will not send this LSA to 
   RT4, RT4 will not exit helper mode. RT1 and RT2 have no mechanism to 
   inform X about their quitting of helper mode (since they are already 
   full with X). Therefore, X continues with GR WITHOUT adding a route 
   to the destination described by the new LSA, as X will not update the

   forwarding table during GR. This results in a routing hole being 
   created at X. This condition will persist until X exits GR. 
 "

 To summarise, 

Explicit signalling is a better option.

>Padma Pillay-Esnault

>>consequence of the Grace LSA format and usage, and does not require 
>>any special handling.
>> 
>>
>>    
>>
>
routers

>>incorrect to add any implied meaning to it. If the Helper is already 
>>in state 2-way or above with the Nbr, then forcefully going to 1-way 
>>is completely wrong. The handling of exit signal is upto the 
>>restarting router. It may or may not tear down the adjacency (in what 
>>ever state it may
>>    
>>
>be)
>  
>
>>with the helper router. The purpose is merely to flush grace lsas. 
>>This was the intention of the exit-grace tlv. Sending 1-way in hello 
>>has other undesired consequences due to its primary meaning as defined

>>by 2328.
>>Acee Lindem

>>once
>>      it is ack'ed).
>>
>>IMHO, this changes the semantics of the grace LSA (and LSAs in 
>>general) too drastically. To make an analogy, it is like using your 
>>level to pound in a nail. It can be made to work but you may find out 
>>that you've broken
>>your level.
>>
>>