Subject: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt

From: Acee Lindem <[email-masked]>
Date: Tue, 13 Dec 2005 20:59:40 -0500

<Speaking as WG Co-chair>

This draft proposes (at least) three separate improvements to RFC 3623 
graceful restart.

     1. Classification of topology change LSAs as a less conservative 
criteria for a
         helper router exiting graceful restart.
     2. Use of a explicit exit TLV for a helper router terminating 
graceful restart. The
         use of a hello without the restarting router's router-ID is 
also suggested.
     3. Preservation of the backup DR across graceful restarts to avoid 
new adjacencies.

Let's discuss each of these in the context of potential for improvement, 
requirements, and
previous proposals (if any) to meet the requirement.

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Tue, 13 Dec 2005 21:20:31 -0500

<Speaking as WG member>

The draft proposes  sub-classification of  LSA changes for determining 
whether or
not a helper should terminate graceful restart. RFC 3623 currently has 2 
modes:
        
           1. Strict LSA Checking - Any changed LSA which would be 
flooded to the restarting
                router will terminate graceful restart.
           2. Changed LSAs will not terminate graceful restart (the 
default for most vendors).

The draft further classifies LSA changes as constituting a topology 
change (in an effort to
reduce the cases where graceful restart must be terminated). For 
example, a new LSA or
new link added to a router LSA would not cause GR termination. I have 
the following
concerns:

        1. Are people asking for this? Most vendors default to #2.
        2. New LSAs can cause the same problems as topology changes to 
existing ones.
            Consider the installation of new more specific routes - the 
characterization of new LSAs
            or "good" news being innocuous and "bad" news terminating 
grace restart seems
            arbitrary.  The draft suggests monitoring all route changes 
involving next hops
            of the restarting router to avoid this problem.
        3. Although my memory is weak, it seems to me that Vishwas' 
previous proposal
            was more robust. If there is a requirement for some level of 
LSA checking but less
            conservative than any LSA flooded to the restarting router 
than we should consider
            that one as well.

Thanks,
Acee

---

From: Ashok <[email-masked]>
Date: Wed, 14 Dec 2005 11:07:17 +0800

Hi group,

The main objective of the topology change LSA definition is to achieve a
balance between unbroken forwarding and restricting the scope of false
GR exits.

The GR mechanism overrides the basic OSPF protocol behavior. All the
checks that have been put in place by OSPF are invalidated by the GR
protocol. GR thus necessitates some 'faith' on part of the routers in a
topology to adhere to the principle of reacting quickly to bad news. 
By disabling strict-lsa-checking, this 'faith' is lost. 
In several scenarios, disabling strict LSA checking will result in the
overall convergence time of OSPF routers being worse with graceful
restart mechanism than without it. This generally involves unstable
topologies and multiple failures. Perhaps, the service providers have
not had such scenarios occurring and as a result, have not asked for
such changes. 

However, the protocol must address this possibility. My concern with the
existing mechanism is that taking policy decisions like disabling strict
lsa checking is incorrect, since we cannot decide the significance of a
topology change apriori. It could lead to extended downtimes, which
would not have been the case if GR mechanism was not in place. 

While this is true, what is equally true is that in large networks, many
changes keep occurring. Links and routers toggle, policies changed and
new routes learnt. This problem is amplified when there are different
service providers operating in the same space. Clearly, many of these
changes may be irrelevant to the neighborhood of a gracefully restarting
router and must not play a part in forcing GR exit. By enabling
strict-lsa-checking, this objective is undermined.

Therefore I feel that there is a need to make the protocol less
conservative and more intelligent, while retaining the
strict-lsa-checking. 

The exact method of achieving this is perhaps still debatable. We have
suggested a method with a bias towards maintaining unbroken forwarding.

Vishwas, it would be nice if you could refresh the group's memory with
your suggestion. I am new to the group and have missed out on the
context and content of that discussion.

Regards,
Ashok

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Acee
Lindem
Sent: Wednesday, December 14, 2005 10:21 AM
To: [email-masked]
Subject: draft-holla-ospf-update-graceful-restart-00.txt - Topology
Change LSAs and Helper Mode Exit

<Speaking as WG member>

modes:

LSA checking but less

Thanks,
Acee

---

From: sujay <[email-masked]>
Date: Wed, 14 Dec 2005 11:14:49 +0530

Adding to Ashoks comment below:

About the issue of the vendors and service providers are unaware of
'strict lsa checking' 
And 'changed lsa's' and they do not resort to the 'strict lsa checking'
concept.

Then it would be advisable to go away with the concept of 'strict lsa
checking' , ' changed lsa's' 
In 3623.

On the other hand if we propose to keep it, still keeping in mind most(
and not all) vendors could use it ,
the strict lsa checking and changed lsa's definitions need a clear and
exact definition.

One part of the draft explains this, calling them as "topology change
lsa"

Talking about the "Exit TLV" it needs merit, as leaving apart the
simplicity it provides in 
Catching outages, there are cases where without it ( i.e using only the
implicit checks) routing
Inconsistencies go unnoticed ( See section 8)

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Ashok
Sent: Wednesday, December 14, 2005 8:37 AM
To: [email-masked]
Subject: Re: draft-holla-ospf-update-graceful-restart-00.txt - Topology

Hi group,

Regards,
Ashok

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

<Speaking as WG member>

modes:

LSA checking but less

Thanks,
Acee

---

From: "Abhay D.S" <[email-masked]>
Date: Wed, 14 Dec 2005 12:43:35 +0530

hi,
Apart from the drafted ideas.
It is time to list out facts which really matter.
A balance between "need it" or good to have.
We need a Requirements for Graceful restart in general.
Regards,
Abhay

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Ashok
Sent: Wednesday, December 14, 2005 8:37 AM
To: [email-masked]
Subject: Re: draft-holla-ospf-update-graceful-restart-00.txt - Topology

Hi group,

Regards,
Ashok

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

<Speaking as WG member>

modes:

LSA checking but less

Thanks,
Acee

---

From: Russ White <[email-masked]>
Date: Thu, 15 Dec 2005 16:09:18 -0500

None of this would be needed, of course, if LLS were used, would it? Why 
not modify the current standard to allow optional LLS and OOB, and then 
we could merge the drafts all into one big mess.... (?)

:-)

Russ

>            conservative than any LSA flooded to the restarting router 

- -- 
[email-masked] CCIE <>< Grace Alone

---

From: Acee Lindem <[email-masked]>
Date: Thu, 15 Dec 2005 16:43:51 -0500

Hi Russ,

Russ White wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>None of this would be needed, of course, if LLS were used, would it? 
>
IMHO, LLS would definitely be a better alternative than adding the exit 
GR TLV to the
grace LSA. As I proposed in Vancouver, we're bringing LLS to the WG 
extensions
for OSPF MANET anyway. However, I want to discuss that in a mail thread 
devoted
solely this is piece of the Holla draft.

>Why 
With respect to GR, I really don't see much functional difference in 
whether one does an OOB
sync or allows neighbor state to transition while advertising the 
neighbor as FULL during graceful restart.

Thanks,
Acee

>-----BEGIN PGP SIGNATURE-----
>Version: PGP Desktop 9.0.3 (Build 2932)
>
>iQA/AwUBQ6HbhREdu7FIVPTkEQLcowCg/rB5fh3270DmJiYIqYFr2O5m/zUAnRn9
>7ZhOOP/AXNjPXjMlIWlTyuCc
>=QfZR
>-----END PGP SIGNATURE-----
>
>  
>

---

From: Acee Lindem <[email-masked]>
Date: Thu, 15 Dec 2005 17:30:13 -0500

<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: Acee Lindem <[email-masked]>
Date: Thu, 15 Dec 2005 17:48:38 -0500

<speaking as WG member>

I don't see that preserving BDR status across restarts buys
you anything. If there are N routers on the broadcast or
NBMA network and the restarting router is preserved,
you have to form (N - 1) adjacencies. If you don't, the new
BDR has to form (N - 2) adjacencies (since it is already
adjacent with the DR) plus the restarting router must form
2 adjacencies. Of course, the adjacency between the new BDR
and restarting router is counted twice so in both cases you
form (N - 1) adjacencies on the broadcast or NBMA network.
Is there something wrong with my math?

Additionally, one could argue that the restarting router already
has enough work to do during the graceful restart and you'd
rather off-load some of the work to a new BDR (all other
things considered equal).

Thanks,
Acee

---

From: Ashok <[email-masked]>
Date: Fri, 16 Dec 2005 10:45:15 +0800

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.

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>

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.

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 11:14:36 +0800

Hi Acee,

What is saved is the running of the election algorithm, which may be
expensive depending on the topology size. Why run it, if it can be
avoided? 
I don't see any harm in keeping the BDR status of the restarting router
intact (excluding the possibility of the DR failing when the restarting
BDR has not yet come up).

Regards,
Ashok

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Acee
Lindem
Sent: Friday, December 16, 2005 6:49 AM
To: [email-masked]
Subject: WG Consideration of
draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR
status

<speaking as WG member>

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Thu, 15 Dec 2005 22:29:54 -0500

Hi Ashok,

>expensive depending on the topology size. Why run it, if it can be
The BDR/DR election is a simple O(N) loop dependent on the number of 
routers on the link

>BDR has not yet come up).
No benefit either.

Thanks,
Acee

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 15 Dec 2005 21:24:29 -0800

>consequence of the Grace LSA format and usage, and does not require any

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

---

From: sujay <[email-masked]>
Date: Sun, 18 Dec 2005 17:10:35 +0530

See Inline 
SUJ>

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Acee
Lindem
Sent: Friday, December 16, 2005 9:00 AM
To: [email-masked]
Subject: Re: WG Consideration of
draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR
status

Hi Ashok,

SUJ>Acee, Agree with the math :) , adjacencies are about (N-1), +/- 1 in

Either case.
It cannot be avoided.

I would see the election algo as an O(N), but I were to see the system 
As a whole with (N-1) nodes, that makes the computation O(N*2) !
Else am I missing something?

No benefit either.

SUJ> Coming up with the BDR or the DR is not as straight process as the 
Algorithm,

I recall this paper on "OSPF Dynamics On a Broadcast LAN" talking about
The actual settling time on LAN's for DR/BDR election.
By M Goyal etc. on this list itself.
http://doi.ieeecomputersociety.org/10.1109/MASCOT.2005.35

Afraid I cannot put the pdf in the mailing list.Here's the
Abstract-"In this paper, we analyze the behavior of OSPF's
interface state machine in a broadcast LAN scenario. We derive
several interesting properties of this behavior that help us
estimate the number of DR elections performed and the time
required as each router on the LAN settles on the DR/BDR identity.
The analytical results are verified using testbed experiments."

To cut the long story short there is a benefit in avoiding it.
Same, Section 3.1.5 in the draft *suggests* to avoid it.

Best Regards,
Sujay

Thanks,
Acee

>I don't see that preserving BDR status across restarts buys you 
>anything. If there are N routers on the broadcast or NBMA network and 
>the restarting router is preserved, you have to form (N - 1) 
>adjacencies. If you don't, the new BDR has to form (N - 2) adjacencies 
>(since it is already adjacent with the DR) plus the restarting router 
>must form 2 adjacencies. Of course, the adjacency between the new BDR
>Additionally, one could argue that the restarting router already has 
>enough work to do during the graceful restart and you'd rather off-load

>some of the work to a new BDR (all other things considered equal).
>
>Thanks,
>Acee
>
>  
>

---

From: Acee Lindem <[email-masked]>
Date: Sun, 18 Dec 2005 07:38:31 -0500

Hi Sujay,

>Else am I missing something?
I've never seen anyone count that way :^). Anyway, if running through 
these the neighbor
loop twice is a big consideration in your implementation, then you can 
include the
BDR preservation. However, my experience is that it is minuscule in 
comparison to
the other protocol processes required.

>Same, Section 3.1.5 in the draft *suggests* to avoid it.
If your choice is forming new adjacencies or not forming new 
adjacencies, then it is
a no-brainer that you should avoid it. However, with graceful restart, 
this is not
the case.

Thanks,
Acee

---

From: sujay <[email-masked]>
Date: Mon, 19 Dec 2005 13:11:04 +0530

Hi Acee,
I concur with you.
Albeit there may not be much of an improvement.
The draft only suggests it may be avoided without any mishaps.. :)
Left to the implementor to consider merit/de-merits.
Best Regards,
Sujay

-----Original Message-----
Sent: Sunday, December 18, 2005 6:09 PM

Hi Sujay,

>SUJ>Acee, Agree with the math :) , adjacencies are about (N-1), +/- 1 
>SUJ>in
>
>Either case.
>It cannot be avoided.
>

>The actual settling time on LAN's for DR/BDR election. By M Goyal etc. 
>on this list itself. 
>Afraid I cannot put the pdf in the mailing list.Here's the Abstract-"In

>this paper, we analyze the behavior of OSPF's interface state machine 
>in a broadcast LAN scenario. We derive several interesting properties 
>of this behavior that help us estimate the number of DR elections 
>performed and the time required as each router on the LAN settles on 
>the DR/BDR identity. The analytical results are verified using testbed 
>experiments."
>
>To cut the long story short there is a benefit in avoiding it. Same, 
>Section 3.1.5 in the draft *suggests* to avoid it.
>  
>

Thanks,
Acee