Subject: Re: Ospf3 checksum

From: SUBSCRIBE OSPF vishnuvardhan B <[email-masked]>
Date: Sun, 4 Dec 2005 15:21:23 -0500

Hi All,
From rfc 2740 the ospf header checksum is calculated as follows:
The 16-bit one's complement of the one's complement
       sum of the entire contents of the packet, starting with the OSPF
       packet header, and prepending a "pseudo-header" of IPv6 header
       fields, as specified in [Ref14, section 8.1]. 
As far as i know the pseudo-header contains a destination,src,len,protocol 
no. So if i want to generate any ospf3 packet, i should generate the 
checksum based on the destination??? this means an additional work of 
computing the checksum for each ospf3 packet generated. And also it's pain 
to know about the destination and calculate the checksum for each ospf3 
packet generated. Please give me some pointers on if it is compulsory to 
generate the ospf3 packet checksum based on the destination.
Regards,
Vishnu

---

From: Acee Lindem <[email-masked]>
Date: Mon, 5 Dec 2005 09:16:09 -0500

>generate the ospf3 packet checksum based on the destination.
Hi Vishnu,

Inclusion of pusedo header in the checksum calculation is required.
However, I'm not sure
why you have a concern. OSPFv3 uses a link-scoped multicast destination
for cases where
a single packet would be applicable to multiple adjacencies.

Thanks,
Acee
P.S. Please remove "SUBSCRIBE" from your E-mail from-address. It results in
replies being rejected.

---

From: sujay <[email-masked]>
Date: Wed, 7 Dec 2005 12:29:16 +0530

Group,

In reference to;
Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC 3623,
November 2003. 

There are certain areas which could be worked upon;

1. The conservative behavior of the Restarting router;
- in its reaction on reception of any new lsa where it *always* exits
the graceful restart, this behavior may be optimized such that the
Restarting router exits GR iff the new lsa actually implies a change 
in the topology

2. A helper router on the presence of non-refresh lsa's in the
retransmit list 
to the restarting router *always* exits as a gr helper
- this reaction again can be ratified only if the lsa's actually specify
a topology change.

3. The restarting router detects non participating helpers only via the
back link checks 
In the router and network lsa's
- this behavior again may lead to network inconsistency for some time,
perhaps an explicit 
notification from the helper router to the restarting router could be
thought of.

With the above optimizations as well keeping it downwardly compatible, 
there are a few pointers to rectify (1) and (2) above using "Topology
change Lsa's" and
 (3) using " Exit-Grace LSA TLV"

Where in short "Topology change LSA's" is the group of LSA's which
*actually* signify a Topology change
And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA
which the router may use to indicate
Its non-particiation as a helper.

The above has been documented at;
www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-00
.txt

While the implementation issues is not much of a hassle and there is at
least one vendor likely to support it
request your views on the same.

Sujay etc.

---

From: Don Goodspeed <[email-masked]>
Date: Wed, 7 Dec 2005 12:06:12 -0800

Having helped review the original RFC during its draft
stage, this draft looks like a sound one but this would
probably best be addressed by contacting the original authors
of the RFC and  co-authoring a revised Graceful OSPF Restart draft
rather than having the original one and an "enhancement".

Broadcasting this to the list seems like you did not contact them.

Just my observations,
Don 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of sujay
Sent: Tuesday, December 06, 2005 10:59 PM
To: 'Mailing List'
Subject: Gracefu-Restart & RFC 3623

Group,

In reference to;

Sujay etc.

---

From: Acee Lindem <[email-masked]>
Date: Wed, 7 Dec 2005 15:46:48 -0500

>Broadcasting this to the list seems like you did not contact them.
Hi Don - actually Padma and I did get an advance copy of the document. 
However, it is
better for the WG as a whole to decide whether or not the proposed 
enhancements justify
standardization.

Thanks,
Acee

---

From: "Abhay D.S" <[email-masked]>
Date: Thu, 8 Dec 2005 11:42:03 +0800

Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal

With a foresight..and with concerns..as a reviewer
for "Update to graceful restart draft".

Making a case for revisiting standardization:

Standardization has to be 'revisited' and in the pipeline, since "OSPF
Capabilities" draft which mentions about graceful
Restart capable, helper capable option advertisements
are 'useful' in making Graceful restart more robust.

The original RFC still lacks the solution for unplanned
restarts. (Do you think this the USP for vendors ?):-|

OSPF Capabilities draft can address many issues faced
by service providers deploying graceful restart.

Im also considering the possibility of using a different
OSPF version number for some special scenarios.

Abhay

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Don
Goodspeed
Sent: Thursday, December 08, 2005 4:06 AM
To: [email-masked]
Subject: Re: Gracefu-Restart & RFC 3623

Having helped review the original RFC during its draft
stage, this draft looks like a sound one but this would probably best be
addressed by contacting the original authors of the RFC and
co-authoring a revised Graceful OSPF Restart draft rather than having
the original one and an "enhancement".

Just my observations,
Don 

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

Group,

In reference to;

Where in short "Topology change LSA's" is the group of LSA's which
*actually* signify a Topology change
And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA
which the router may use to indicate Its non-particiation as a helper.

While the implementation issues is not much of a hassle and there is at
least one vendor likely to support it request your views on the same.

Sujay etc.

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 7 Dec 2005 22:10:11 -0800

See PPE for comments

>restarts. (Do you think this the USP for vendors ?):-|
PPE:

What ? I beg to differ. 

What about section 5 - Unplanned Outages ?

>Restarting router exits GR iff the new lsa actually implies a change 
PPE :

AFAIK Major vendors already implement "non-strict lsa checking" for the 
restarting router and I have
already discussed this on this alias (I seem to recall) way back.
I did not agree then for strict-lsa checking and I still don't as it is 
restrictive.

Several reasons
In a fairly large topology, it going to be impractical.
Is it worth it to exit GR because a acquired a new previously unknown 
neighbor ?

 From day 1, my implementation did not support strict lsa checks.
The graceful restart implementation report mentions 
non-strict-lsa-checking as well.

This is an implementation decision and does not require helpers to agree 
on the behavior.

>- this reaction again can be ratified only if the lsa's actually specify

PPE :
Please see section B2.

The RFC already has the non-strict-lsa-checking option - which I believe 
goes hand in hand - removing strict lsa checking everywhere ( both the 
GR and helper). At least this was the intention of this author.

>notification from the helper router to the restarting router could be

PPE.

Please see 2.1 last sentence.

What are you trying to achieve here ?
- if there is no helper (router doesn't understand grace or refuses to 
act as helper)
there is no way you are going to achieve graceful restart anyway.
- that the rebooting GR router continues to do so is not a problem  and 
you are going to drop
packets - just as expected.

Are you proposing to stop graceful restart if you cannot achieve it ? 
What would be the benefit ?
as you will then attempt a non-graceful one and drop packets anyway.

> (3) using " Exit-Grace LSA TLV"
I don't agree that these optimizations are extensions to the original draft.

- (1) non-strict lsa checking is already mentioned - maybe not as 
clearly as one would wish
- (2) -is already mentioned  see section B.2
- (3) - see my above comment

my 2 cts

Padma

---

From: "Abhay D.S" <[email-masked]>
Date: Thu, 8 Dec 2005 14:38:59 +0800

Addendum...

Also look at the RFC's 7th section

7. Possible Future Work

   Devise a less conservative algorithm for graceful restart helper
   termination that provides a comparable level of black hole and
   routing loop avoidance.

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Padma
Pillay-Esnault
Sent: Thursday, December 08, 2005 2:10 PM
To: [email-masked]
Subject: Re: Gracefu-Restart & RFC 3623

See PPE for comments

Abhay D.S wrote:

>Capabilities" draft which mentions about graceful Restart capable, 
>helper capable option advertisements are 'useful' in making Graceful 
>restart more robust.
>
>The original RFC still lacks the solution for unplanned restarts. (Do 
>you think this the USP for vendors ?):-|
>
>  
>
PPE:

What ? I beg to differ. 

>stage, this draft looks like a sound one but this would probably best 
>be addressed by contacting the original authors of the RFC and 

>Restarting router exits GR iff the new lsa actually implies a change in

>the topology
PPE :

AFAIK Major vendors already implement "non-strict lsa checking" for the 
restarting router and I have
already discussed this on this alias (I seem to recall) way back. I did
not agree then for strict-lsa checking and I still don't as it is 
restrictive.

Several reasons

 From day 1, my implementation did not support strict lsa checks. The
graceful restart implementation report mentions 
non-strict-lsa-checking as well.

on the behavior.

>retransmit list to the restarting router *always* exits as a gr helper

PPE :
Please see section B2.

>back link checks In the router and network lsa's

PPE.

> (3) using " Exit-Grace LSA TLV"
I don't agree that these optimizations are extensions to the original
draft.

my 2 cts

Padma

---

From: "Abhay D.S" <[email-masked]>
Date: Thu, 8 Dec 2005 14:37:36 +0800

Hi Padma !,
IMHO.
Section 5 has an avoidance approach not preventive.

Why ?.
Unassuming..
Case X ) Hello packets will be sent eventually to discover some
neighbors ,but what if hello packets are received by
some routers before they receive the grace LSA.(Only for
unplanned case) because of transient network conditions.

Case Y) Due to load of neighbors, restart router feels it needs
more time to complete Graceful restart.

In case of unplanned restart(crash on router processer)
Voice over IP call is still running. Do we want to exit
Helper mode and get routes down ?. (Case X).Voice call
is down.

Do you feel OSPF capabilities specification can help provide
a solution to ISP ?. Im keeping in mind the options some graph
experts had suggested about configuration of exiting helper mode.
But that did not cover case X..

Another, Grace period should be able to be changed
dynamically, depending on restarting routers load, and period should
be derived from a standardized function.(Case y)

If I was a ISP operator, I would not refuse all of these .... :-).

Abhay

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

See PPE for comments

PPE:

What ? I beg to differ. 

PPE :

Several reasons

on the behavior.

PPE :
Please see section B2.

PPE.

my 2 cts

Padma

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 7 Dec 2005 23:02:39 -0800

>Section 5 has an avoidance approach not preventive.
Humm ...
You said there is "no" support - and now you say it is avoidance.

I missing something. Not sure I understand what is avoidance and what is 
preventive ?

Can you prevent/avoid  a crash ? :-)

>unplanned case) because of transient network conditions.
Why would only the grace lsas ( BTW we do send several of them wait 
before sending hellos -
discussed on this alias in 2001 I believe) get dropped and not the 
subsequent hello packets ?

Makes me think of a french proverb

"With a lot of ifs you can put Paris in a bottle ...."

These are local link scope - how can you expect the hellos to jump ahead 
of the grace lsa if you
implemented it not to be so  - unless you have a buggy implementation.

>more time to complete Graceful restart.
The router does not feel - you configure it  :-)

>Helper mode and get routes down ?. (Case X).Voice call
I am missing your point .....

Unlikely case X ( hellos ahead of grace) and the helper exit  - why  ?

>be derived from a standardized function.(Case y)
Actually GR can configured to be a very long period and a good 
implementation will get end as soon as it
is ready. This is the approach in my implementation, let's call it 
intuitively dynamic and you
don't even have to add extra config.

>If I was a ISP operator, I would not refuse all of these .... :-).
I think you already have these :-)

Padma

>>- this reaction again can be ratified only if the lsa's actually
>>    
>>
>specify
>  
>
>>a topology change.
>> 
>>
>>    
>>
>
>PPE :
>Please see section B2.
>

---

From: sujay <[email-masked]>
Date: Thu, 8 Dec 2005 13:12:14 +0530

The RFC being the base, has room for improvements,
no wonder WG's and mailing lists !

Please See comments Inline 
SUJ>

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Padma
Pillay-Esnault
Sent: Thursday, December 08, 2005 11:40 AM
To: [email-masked]
Subject: Re: Gracefu-Restart & RFC 3623

See PPE for comments

PPE:

What ? I beg to differ. 

SUJ> here I guess the issue is, section 5 still has room for work,
'future work' on 3623.

PPE :

Several reasons

on the behavior.

SUJ> IMHO the strict lsa checking option has been provided for in the
helper in 3623, not the restarting router
See section 3.2, B.2,
Considering even it for the restarting router (and the helper), the
concept of a 'changed lsa' is too wide.
It has been tightly defined with the category as "Topology change LSA's"
in the draft. There are quite a few cases
Where for a 'changed lsa' is not truly a qualifier for Changing the GR
environment !

specify

PPE :
Please see section B2.

SUJ> Please see above comments.

PPE.

SUJ> the point is of knowing the non-participation of *any* helper asap,
and getting out of GR
Needless to say it serves the common goal of detecting blackholes and
routing loops asap

my 2 cts

Padma

SUJ> To summarize:
1. The draft in short defines certain elements more clearly and exact.
2. It makes the definitions more terse, specifications exact.
3. It is backwardly compatible with the "large vendors" as reported in
the 'graceful restart implementation report'
4. It is an addition over and above the 3623 and nothing out of the blue
!

---

From: "Abhay D.S" <[email-masked]>
Date: Thu, 8 Dec 2005 15:41:39 +0800

Hi padma !.
Your proverbs are enjoyable ! :-).
However, please read inline and think
im your customer !(ends at the moment
we start thinking about revisiting standardization).

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Padma
Pillay-Esnault
Sent: Thursday, December 08, 2005 3:03 PM
To: [email-masked]
Subject: Re: Gracefu-Restart & RFC 3623

>Section 5 has an avoidance approach not preventive.

Yes there is "no" support. 

Humm ...

preventive ?

Abhay)) Yes RFC does not have a mechanism to prevent neighbors from
getting down due to receiving hello. Do you remember the robustness
variable ?(This is what is avoidance).(Hope you understand and not
mislead
yourself into thinking what RFC says is perfect,everybody loves
their babies).

Unplanned restart: Why do you think grace LSA cannot be dropped and
hello packets be received in
case of unplanned restart,we have still not discovered our neighbors.

In planned case I agree that grace LSA's will be received by all
neighbors before
sending hello.

>neighbors ,but what if hello packets are received by some routers 
>before they receive the grace LSA.(Only for unplanned case) because of 
>transient network conditions.
>  
>

of the grace lsa if you

Abhay)) You must have heard about packet being dropped(it is justified
in draft,sending several times), and about priority handling of hello
packets.
(suggested by folks at AT&T).

>Case Y) Due to load of neighbors, restart router feels it needs more 
>time to complete Graceful restart.
>
>  
>

Abhay)) I need an router with extra intelligence. As you know that GR
deployment is critical in PE's. Feeling is better than configuring it
and then saying sorry "we will come up with something soon, I beg you".
Configuration is for stable toplogies.

Abhay)) It is possible in unplanned case, think more....see reason given
Above.

>a solution to ISP ?. Im keeping in mind the options some graph experts 
>had suggested about configuration of exiting helper mode. But that did 
>not cover case X..
>
>Another, Grace period should be able to be changed dynamically, 
>depending on restarting routers load, and period should be derived from

>a standardized function.(Case y)
>
>
>  
>

Abhay)) Do you think all vendors run the same type of mechanisms ?.
But just above you said it can be configured ??.

Padma

Abhay)) Im still not satisfied, I cannot buy your RFC. :-). Please
improve
section 5 and I will think about it.

>From: Mailing List [mailto:[email-masked]] On Behalf Of 
>Padma Pillay-Esnault
in
>graceful restart implementation report mentions non-strict-lsa-checking

>as well.

>>perhaps an explicit notification from the helper router to the 
>>restarting router could be thought of.
>> 
>>
>>    
>>
>
>PPE.
>

>>www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-
0
>>0

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 8 Dec 2005 00:03:14 -0800

See PPE for comments

>SUJ> here I guess the issue is, section 5 still has room for work,
PPE  - I have yet to see those :-)

>Where for a 'changed lsa' is not truly a qualifier for Changing the GR
PPE -

As I said before, if you have a helper who does not perform
strict lsa checking and floods it to a router with strict lsa checking - 
this won't work.
So to me mention of this couples it for both restarting and helper routers.

What you are describing already is done in most implementation using 
common sense.
It is actually documenting what implementations have already done 
individually. This is where I think
these are not extensions but exposing implementation details about 
common sense.

>SUJ> Please see above comments.

PPE  - see above  - it does not make sense to have a mix and match of 
restart and helper routers
regarding strictlsachecking. The wording might not be great but it 
really implicitly
mean for both.

>Needless to say it serves the common goal of detecting blackholes and

PPE
I don't think that you responded to my question ....

You are going to drop packets anyway and
I hardly see how you are going to figure out just by exchange of info of 
helper capability
whether you are going to have less blackhole/loop with or without GR.

see below

Padma

---

From: sujay <[email-masked]>
Date: Thu, 8 Dec 2005 14:00:26 +0530

See SUJ>>

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Padma
Pillay-Esnault
Sent: Thursday, December 08, 2005 1:33 PM
To: [email-masked]
Subject: Re: Gracefu-Restart & RFC 3623

See PPE for comments

SUJ>> this is not covered in this draft, as can be read from its
objectives.

in

>concept of a 'changed lsa' is too wide. It has been tightly defined 
>with the category as "Topology change LSA's" in the draft. There are 
>quite a few cases Where for a 'changed lsa' is not truly a qualifier 
>for Changing the GR environment !
>
>  
>
PPE -

As I said before, if you have a helper who does not perform strict lsa
checking and floods it to a router with strict lsa checking - 
this won't work.
So to me mention of this couples it for both restarting and helper
routers.

SUJ>> section B.2 says "RestartHelperStrictLSAChecking" .

SUJ>> To quote a Spanish proverb "Common sense is the least common of
the senses"

Sections of Exiting, Entering GR as a Restarting Router or a Helper (in
3623), is not 
necessary  all implementors should be able to guess it , rather can !

Spec's to my understanding should be as clear as possible. Refer 2328
for what clarity is.

The purpose is not to overrule 3623, but document,and enhance it, a
known fact by the world 
of men as we know.

>SUJ> the point is of knowing the non-participation of *any* helper 
>SUJ> asap,
>and getting out of GR

PPE

helper capability

see below

SUJ>> 

The restarting router if informed of a non participating helper, can
undergo a 
Hard restart directly immediately all other routers ( which may be ready
as helpers) too
Exit the helper process.
It hastens the process of detecting that there is something gone wrong
in the middle of
Grace period to the initial stages.

Padma

>2. It makes the definitions more terse, specifications exact. 3. It is 
>backwardly compatible with the "large vendors" as reported in the 
>'graceful restart implementation report' 4. It is an addition over and 
>above the 3623 and nothing out of the blue !
>
>
>
>  
>
0

---

From: Ashok <[email-masked]>
Date: Thu, 8 Dec 2005 16:35:38 +0800

Hi Padma,

Regarding the idea behind topology change lsa:
In my opinion, disabling strict LSA checking is not the ideal way of
going about graceful restart, since this leads to topology
inconsistencies and routing holes. 
What the draft suggests is 'while working in the existing framework with
strict lsa checking enabled', we restrict the scope of the topology
changes that can and MUST force a gracefully restarting router to
terminate the GR. This is better than doing away with the strict lsa
checking all together. Therefore this mechanism offers maximum
flexibility while adhering to the principle of unbroken forwarding. 

Regarding the idea behind exit-grace tlv:
There may be scenarios, where there are configuration anomalies on
routing peers. 
During such scenarios, if a router on receiving grace lsa, refuses to
act as helper, it can immediately inform the restarting router. This
helps the restarting router to flush the grace lsas from the domain and
ensure the best protection against any further changes. 
What is perhaps seen as common sense is what the restarting router does
AFTER flushing the grace lsas. That as you rightly point out is
implementation specific. Our concern should only be that the restarting
router flushes the grace lsas asap, in order to provide the correct
picture of the routing topology.
There are a few other suggestions in the draft like excluding implied
acks from the purview of changed lsas (when a rtr enters helper mode).

Perhaps, the draft warrants a discussion in greater detail.

Regards,
Ashok

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Padma
Pillay-Esnault
Sent: Thursday, December 08, 2005 4:03 PM
To: [email-masked]
Subject: Re: Gracefu-Restart & RFC 3623

See PPE for comments

Padma

in

PPE -

this won't work.

>SUJ> the point is of knowing the non-participation of *any* helper
asap,

PPE

helper capability

see below

Padma

0

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 8 Dec 2005 01:18:17 -0800

>Your proverbs are enjoyable ! :-).
Glad you like them

The original in french "Avec des si on metterait Paris en bouteille."

responses below

PPE -

 Robustness variable - yeah - send as many grace lsa you think before 
you send
your hellos - when I think that we have feature out now that demands to 
send packets
asap and no drops - but just grace lsa would get dropped !! I don't buy 
your argument.

If your robustness variable is good enough that is prevention.

>case of unplanned restart,we have still not discovered our neighbors.
PPE - what makes you think that only these lsa will get dropped ?

I think that you are being biased here - lo! all my grace lsa - for 5 s 
got dropped but lo and behold
all my hellos got thru - well something is wrong and we never said that 
this should work on faulty
equipment did we ?

>(suggested by folks at AT&T).
PPE - this is what I call implementation details- if you write get the 
grace out first - just do it !
or else you have a buggy implementation of the feature.  Suggestion -use 
the pak priority right :-)

PPE  -

I never saw my routers beg :-)  Gosh your routers are really different 
from mine !! :-)

Restart with PE could have a very large value - under 1 hr theoretically 
- and an implementation exit
GR as soon as it has completed. Simple and robust.
( Though I don't recommend 1 hr ! - I have done enough of profiling on 
this one to
find a suitable value!)

So what do you suggest evaluate DB size. number of routers, may be mtu, 
may be link robustness  and
get some number ? How do you evaluate for those famous packet drops ?  :-)
Renegotiate the time ? By how much - how are you going to "feel" when 
you are done ?
What are the criterias ?

Do really want to go there ?

I know how to do complex but aim for simplicity.

>>Voice over IP call is still running. Do 
>>

>>we want to exit
PPE - sorry I must be slow. I think  that a good implementation should 
avoid X from there nothing
makes sense anymore. It's like saying I have OSPF but I can't have 
multicast ... the basic premise is
broken - all kinds of speculations are open. Well don't break the 
premise and it will work.
Further more the restarting router control the premise and can make sure 
it is not broken.

Are you trying to say the GR router send a hello then a grace ? - but 
the hello should have torn
down the adj - the other router is not even a helper at that point as it 
will receive a hello
with no nbr - which will cause a adjacency recycle.

PPE -

Implementation detail  -  you don't need a spec for that.
I am sure you can figure it out.

PPE

See my comments above

Improve yes as long as it stays simple and robust and usable
but  brew coffee don't think so  :-)

Padma

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 8 Dec 2005 15:00:43 +0530

Abhay,

!> 
!> >Why ?.
!> >Unassuming..
!> >Case X ) Hello packets will be sent eventually to discover some 
!> >neighbors ,but what if hello packets are received by some routers 
!> >before they receive the grace LSA.(Only for unplanned case) 
!> because of 
!> >transient network conditions.
!> >  
!> >
!> Why would only the grace lsas ( BTW we do send several of them wait 
!> before sending hellos -
!> discussed on this alias in 2001 I believe) get dropped and not the 
!> subsequent hello packets ?
!> 
!> 
!> 
!> Makes me think of a french proverb
!> 
!> "With a lot of ifs you can put Paris in a bottle ...."
!> 
!> These are local link scope - how can you expect the hellos 
!> to jump ahead
!> 
!> of the grace lsa if you
!> implemented it not to be so  - unless you have a buggy 
!> implementation.
!> 
!> Abhay)) You must have heard about packet being dropped(it is 
!> justified
!> in draft,sending several times), and about priority handling of hello
!> packets.
!> (suggested by folks at AT&T).

What really stops an implementation from prioritizing its grace LSAs? :) A
proper implementation would IMO correctly handle the grace LSAs in case of
an unplanned outage also.

Manav

___________________________________________________________ 
Yahoo! Exclusive Xmas Game, help Santa with his celebrity party - http://santas-christmas-party.yahoo.net/

---

From: "Abhay D.S" <[email-masked]>
Date: Thu, 8 Dec 2005 17:49:38 +0800

Hi Padma !

IMHO
We all want to have a KISS implementation(Keep It Simple Stupid).

But it is useful only for demonstration not practical.

You have no proof to say Grace TLV can be received before receiving
Hello.

One case: 
In unplanned case, RFC implementation keeps sending grace TLV to all
neighbors, assuming that they have received the TLV.We never
Wait for an ACK from all neighbors, since we don't know who they were.

And then send hello to discover neighbors.

But one end is a remote router which failed to receive Grace LSA(what
ever reason,overloaded,dropped due to
packet type scheduling). If hello reached the router,What to do ?

How about prioritized handling of hello packets many high energy vendors
implement.

How to inter-operate with them ?

Yes in a four router setup, agreed, but not in large networks, you have
to consider packet scheduling and router backplane architectures.

Please, im talking only about helper router being in danger of receiving
out of turn
Hello.

On restart router, this can be controlled to send Grace LSA.

We know our packets well. We also have to consider network conditions.

Demonstrability is a requirement for OSPF GR, Usability is the highest
priority than
Demonstrability.

Abhay

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Padma
Pillay-Esnault
Sent: Thursday, December 08, 2005 5:18 PM
To: [email-masked]
Subject: Re: Gracefu-Restart & RFC 3623

Glad you like them

responses below

>mislead yourself into thinking what RFC says is perfect,everybody loves
>their babies).
>
>  
>
PPE -

>hello packets be received in case of unplanned restart,we have still 
>not discovered our neighbors.
>
>  
>

>neighbors before sending hello.
>
>
>  
>
>>Why ?.
>>Unassuming..

>packets. (suggested by folks at AT&T).
>
>  
>

PPE  -

So what do you suggest evaluate DB size. number of routers, may be mtu, 
may be link robustness  and
get some number ? How do you evaluate for those famous packet drops ?
:-) Renegotiate the time ? By how much - how are you going to "feel"
when 
you are done ?
What are the criterias ?

it is not broken.

will receive a hello

PPE -

PPE

See my comments above

Padma

Don

>>graceful restart implementation report mentions
non-strict-lsa-checking

---

From: sujay <[email-masked]>
Date: Thu, 8 Dec 2005 15:25:35 +0530

Manav:
Prioritizing packets , reordering them etc. 
Is mentioned in the draft-ietf-ospf-scalability.

The thought is perhaps of the fine-print with the drafts and
RFC's (of what else to do other than sending grace lsa's??)
- use a Robustness variable ( already suggested)
- use packet prioritization ( not suggested ) - maybe skipped but
thought of.
- ???

Therefore its nothing to do with implementation details.

Talk about implementation I could refer some books.

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Manav
Bhatia
Sent: Thursday, December 08, 2005 3:01 PM
To: [email-masked]
Subject: Re: Gracefu-Restart & RFC 3623

Abhay,

!> 
!> >Why ?.
!> >Unassuming..
!> packets. !> (suggested by folks at AT&T).

What really stops an implementation from prioritizing its grace LSAs? :)
A proper implementation would IMO correctly handle the grace LSAs in
case of an unplanned outage also.

Manav

___________________________________________________________ 
Yahoo! Exclusive Xmas Game, help Santa with his celebrity party -
http://santas-christmas-party.yahoo.net/

---

From: "Abhay D.S" <[email-masked]>
Date: Thu, 8 Dec 2005 18:05:13 +0800

Manav,
If you followed me right...

It is helper receiving order, Grace LSA might
be dropped and hello received.

Do you think Grace LSA can be sent again after
a set of hellos were sent.

This way:

Send Grace LSA many times...

Send Hello to discover neighbors.

Send Grace LSA many times.....

My idea is if helper knows that the router is
graceful restart capable, it would wait a while
expecting to receive a Grace LSA, even after seeing
a one way hello.

Please see my scenario:

                                      Congestion
Restart Router ---------> Send Grace LSA----->Switch --------Nothing--->
Helper

                                        Congestion  
Restart Router---------> Send Grace LSA ------> Switch--Nothing-->
Helper

                                        Congestion  
Restart Router---------> Send Grace LSA ------>
Switch----Nothing--->Helper
 
Normal   
Restart Router Has no neighbors ---(assumes all helpers received)---Send
Hello ---->Switch------>Hello-->Helper(Down)

Abhay

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Manav
Bhatia
Sent: Thursday, December 08, 2005 5:31 PM
To: [email-masked]
Subject: Re: Gracefu-Restart & RFC 3623

Abhay,

!> 
!> >Why ?.
!> >Unassuming..

Manav

---

From: Don Goodspeed <[email-masked]>
Date: Thu, 8 Dec 2005 02:10:29 -0800

In all fairness to all implementations involved in this discussion,
we are talking about proposed *standards* not about how best everyone
should implement a given protocol.  Granted, there are numerous papers,
books, studies, etc. that can describe how best to implement a protocol
but unless I am mistaken, that is not the charter of the IETF.

I believe they leave the "wiggle room" up to the individual vendors
on how best to implement against the common set of base standards that
are defined on how protocols should and must be implemented.

There were a couple comments eariler tonight to this effect when
discussing the section on "what constitutes a non-refresh" which
most vendors have left up to each other to define.

I do agree that something like an exit-reason TLV that is sent out
on the wire *may* be a nice enhancement.

I see the discussion heading in the wrong direction, so I had to speak
up at this late (for me, not for others) hour.

Cheers and good night from the states,
Don

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of sujay
Sent: Thursday, December 08, 2005 1:56 AM
To: 'Mailing List'
Subject: RE: Gracefu-Restart & RFC 3623

Manav:

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

Abhay,

!> 
!> >Why ?.
!> >Unassuming..

Manav

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 8 Dec 2005 16:17:10 +0530

Sujay,
 
!> Manav:
!> Prioritizing packets , reordering them etc. 
!> Is mentioned in the draft-ietf-ospf-scalability.

RFC4222 to be precise.

!> 
!> The thought is perhaps of the fine-print with the drafts and
!> RFC's (of what else to do other than sending grace lsa's??)
!> - use a Robustness variable ( already suggested)
!> - use packet prioritization ( not suggested ) - maybe skipped but
!> thought of.
!> - ???
!> 

I am not sure if I understand your point with "fine-print with drafts, etc."
and all. I responded to the post that said:

"You must have heard about packet being dropped(it is justified in
draft,sending several times), and about priority handling of hello packets.
(suggested by folks at AT&T)."

Note the "priority handling" part. So, if prioritizing HELLOs is the only
problem, then you might as well prioritize your grace LSAs. Simple.

!> Therefore its nothing to do with implementation details.
!> 
!> Talk about implementation I could refer some books.

I would love to! :)

I would agree to Don that we are perhaps heading in the wrong direction!

Manav

!> 
!> 
!> 
!> -----Original Message-----
!> From: Mailing List [mailto:[email-masked]] On 
!> Behalf Of Manav
!> Bhatia
!> Sent: Thursday, December 08, 2005 3:01 PM
!> To: [email-masked]
!> Subject: Re: Gracefu-Restart & RFC 3623
!> 
!> 
!> Abhay,
!> 
!> !> 
!> !> >Why ?.
!> !> >Unassuming..
!> !> >Case X ) Hello packets will be sent eventually to discover some 
!> !> >neighbors ,but what if hello packets are received by 
!> some routers 
!> !> >before they receive the grace LSA.(Only for unplanned case) 
!> !> because of 
!> !> >transient network conditions.
!> !> >  
!> !> >
!> !> Why would only the grace lsas ( BTW we do send several of 
!> them wait 
!> !> before sending hellos -
!> !> discussed on this alias in 2001 I believe) get dropped 
!> and not the 
!> !> subsequent hello packets ?
!> !> 
!> !> 
!> !> 
!> !> Makes me think of a french proverb
!> !> 
!> !> "With a lot of ifs you can put Paris in a bottle ...."
!> !> 
!> !> These are local link scope - how can you expect the hellos 
!> !> to jump ahead
!> !> 
!> !> of the grace lsa if you
!> !> implemented it not to be so  - unless you have a buggy 
!> !> implementation.
!> !> 
!> !> Abhay)) You must have heard about packet being dropped(it is 
!> !> justified
!> !> in draft,sending several times), and about priority 
!> handling of hello
!> !> packets. !> (suggested by folks at AT&T).
!> 
!> What really stops an implementation from prioritizing its 
!> grace LSAs? :)
!> A proper implementation would IMO correctly handle the grace LSAs in
!> case of an unplanned outage also.
!> 
!> Manav
!> 
!> 
!> 
!> 		
!> ___________________________________________________________ 
!> Yahoo! Exclusive Xmas Game, help Santa with his celebrity party -
!> http://santas-christmas-party.yahoo.net/

___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 8 Dec 2005 09:08:22 -0800

Agree with you and Don - We are going in the wrong direction discussing
how implementation should be done.

I am trying hard to avoid discussion on premises that are not fulfilled 
by an implementation as this
is really up to the implementation to achieve it.

Trying to sift out what is really spec material here.

Padma

---

From: Acee Lindem <[email-masked]>
Date: Thu, 8 Dec 2005 14:40:36 -0500

<Speaking as a somewhat biased WG member :^>

I meant to read this whole E-mail thread before responding but I'll respond
to the discussion immediately. In practice, do any network operators see 
graceful restart
failing due failure to receive grace LSAs prior to a hello? Heretofore, 
I haven't heard this
complaint.

If this were to happen, it would imply a somewhat fragile network and 
I'm not so sure
we'd want restart gracefully anyway (assuming the restarting router has 
delayed sending
its first hello a sufficient amount of time and flooded the grace LSAs a 
couple times
as suggested by RFC 3623).

If we graceful restart does need to solve this problem and we need a more
reliable mechanism  (which is yet to be proved), then I don't think we 
should
build a request/response mechanism into the LSAs. Rather, we should migrate
to Link Local Signaling (LLS) which we are will be needed for the OSPF MANET
extensions anyway (one of the common design points of every flooding 
reduction
proposal is that it uses LLS).

http://www.ietf.org/internet-drafts/draft-nguyen-ospf-lls-05.txt

Thanks,
Acee

Abhay D.S wrote:

>>Abhay)) It is possible in unplanned case, think more....see reason
>>    
>>
>given
>  
>
>>Above.
>>
>>
>> 
>>
>>    
>>
>>>depending on restarting routers load, and period should be derived
>>>      
>>>
>from
>  
>
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>>Standardization has to be 'revisited' and in the pipeline, since
>>>>        
>>>>
>"OSPF
>  
>
>>>AFAIK Major vendors already implement "non-strict lsa checking" for
>>>      
>>>
>the
>  
>
>>>already discussed this on this alias (I seem to recall) way back. I
>>>      
>>>
>did
>  
>
>>>>retransmit list to the restarting router *always* exits as a gr
>>>>        
>>>>
>helper
>  
>
>>>>- this behavior again may lead to network inconsistency for some
>>>>        
>>>>
>time,
>  
>
>>>>     
>>>>
>>>>        
>>>>
>> 
>>
>>    
>>
>>>- that the rebooting GR router continues to do so is not a problem
>>>      
>>>
>and
>  
>
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>>you are going to drop
>>>>With the above optimizations as well keeping it downwardly
>>>>        
>>>>
>compatible,
>  
>
>>>>     
>>>>
>>>>        
>>>>
>> 
>>
>>    
>>
>>>>which the router may use to indicate Its non-particiation as a
>>>>        
>>>>
>helper.
>  
>
>>>>www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart
>>>>        
>>>>
>-
>  
>
>>>>     
>>>>
>>>>        
>>>>
>>0
>> 
>>
>>    
>>
>>>>0
>>>>.txt
>>>>

---

From: "Abhay D.S" <[email-masked]>
Date: Fri, 9 Dec 2005 10:10:59 +0800

Acee,Padma,Don, et al...

My idea is a standardization for Graceful restart,
not modification to RFC 3623.

It should generalize all the facts and quote some usable
mechanisms,LLS or request/reply. MANET has LLS, so reuse
it for GR again ?. 

Implementation and Standardization go hand in hand.(Implementation
need not be discussed) and I think it is *wrong* ...to say discussions
about draft shortcomings are discussion of implementations.

OSPF WG is one such body where discussions of all
sort happen,it gives important to WG. Otherwise WG is useless.

We also can do it our own way,but we also want to see what
the WG thinks.

We want a common set of agreed rules.

Thanks,
Abhay

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Acee
Lindem
Sent: Friday, December 09, 2005 3:41 AM
To: [email-masked]
Subject: Re: Gracefu-Restart & RFC 3623

I meant to read this whole E-mail thread before responding but I'll
respond to the discussion immediately. In practice, do any network
operators see 
graceful restart
failing due failure to receive grace LSAs prior to a hello? Heretofore, 
I haven't heard this
complaint.

couple times

If we graceful restart does need to solve this problem and we need a
more reliable mechanism  (which is yet to be proved), then I don't think
we 
should
build a request/response mechanism into the LSAs. Rather, we should
migrate to Link Local Signaling (LLS) which we are will be needed for
the OSPF MANET extensions anyway (one of the common design points of
every flooding 
reduction
proposal is that it uses LLS).

Thanks,
Acee

Abhay D.S wrote:

>ever reason,overloaded,dropped due to packet type scheduling). If hello

>reached the router,What to do ?
>
>How about prioritized handling of hello packets many high energy 
>vendors implement.
>

>Please, im talking only about helper router being in danger of 
>receiving out of turn Hello.
>
>priority than Demonstrability.
>
>Abhay
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

>>before sending hellos - discussed on this alias in 2001 I believe) get

>>dropped and not the subsequent hello packets ?
>>
>>
>>
>>>In case of unplanned restart(crash on router processer) Voice over IP

>>>call is still running. Do
>>>
>>>      
>>>
>
>  
>
>>>we want to exit
>>>Do you feel OSPF capabilities specification can help provide a 
>>>solution to ISP ?. Im keeping in mind the options some graph experts
>>>      
>>>
>
>  
>
>>improve section 5 and I will think about it.
>>
>> 
>>
>>    
>>
>PPE
>
>See my comments above
>
>Improve yes as long as it stays simple and robust and usable but  brew 
>coffee don't think so  :-)
>
>
>Padma
>
>  
>
>>>Abhay
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>

>>>>restart more robust.
>>>>
>>>>The original RFC still lacks the solution for unplanned restarts. 
>>>>(Do you think this the USP for vendors ?):-|
>>>>
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>PPE:
>>>
>>>What ? I beg to differ.
>>>
>>>>Im also considering the possibility of using a different OSPF 
>>>>version number for some special scenarios.
>>>>
>>>>Abhay
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>Having helped review the original RFC during its draft stage, this 
>>>>draft looks like a sound one but this would probably best be 
>>>>- in its reaction on reception of any new lsa where it *always* 
>>>>exits the graceful restart, this behavior may be optimized such that

>>>>the Restarting router exits GR iff the new lsa actually implies a 
>>>>change
>>>>     
>>>>
>>>>        
>>>>
>>in
>> 
>>
>>    
>>
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>   
>>>
>>>      
>>>
>>>>the topology
>>>>
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>PPE :
>>>
>>>

>>>goes hand in hand - removing strict lsa checking everywhere ( both 
>>>the GR and helper). At least this was the intention of this author.
>>>
>>>
>>>
>>>   
>>>
>>>      
>>>
>>>- if there is no helper (router doesn't understand grace or refuses 
>>>to act as helper) there is no way you are going to achieve graceful 
>>>restart anyway.

>>>What would be the benefit ? as you will then attempt a non-graceful 
>>>one and drop packets anyway.
>>>
>>>
>>>
>>>   
>>>
>>>      
>>>

---

From: Acee Lindem <[email-masked]>
Date: Thu, 8 Dec 2005 21:36:26 -0500

Abhay,

>mechanisms,LLS or request/reply. MANET has LLS, so reuse
LLS was originally introduced for graceful restart. The argue for link 
local opaque
LSA was that they already existed. The argument for LLS was that the 
signaling
coincided with the hello/DD packets so there was no chance for a the 
initial grace
LSA flood(s) to be missed.

>about draft shortcomings are discussion of implementations.
I agree.

>We also can do it our own way,but we also want to see what
It would be great to hear as well from folks deploying OSPF network 
which utilize
graceful restart.

Thanks,
Acee

>>>mislead yourself into thinking what RFC says is perfect,everybody
>>>      
>>>
>loves
>  
>
>>>their babies).
>>>
>>>
>>>
>>>   
>>>
>>>      
>>>
>>PPE -
>>
>>or else you have a buggy implementation of the feature.  Suggestion
>>    
>>
>-use
>  
>
>>>and then saying sorry "we will come up with something soon, I beg
>>>      
>>>
>you".
>  
>
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>>Further more the restarting router control the premise and can make
>>    
>>
>sure
>  
>
>>it is not broken.
>>
>>down the adj - the other router is not even a helper at that point as
>>    
>>
>it
>  
>
>>will receive a hello

---

From: Ashok <[email-masked]>
Date: Fri, 9 Dec 2005 11:51:08 +0800

Folks,
During the discussion on the enhancement proposal to GR, perhaps a lot
of issues were raised and dissolved into incoherence.
I have intentionally created a new thread for the discussion that was
originally intended.
Perhaps this thread can be focused towards debating the ideas in: 
www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-00

The main ideas outlined are:

* The draft attempts to reduce the conservativeness of the existing GR
mechanism. 
* It proposes a new explicit feedback mechanism for the helpers to
communicate their non-participation in GR.

Other useful links:
RFC 3623: http://www.ietf.org/rfc/rfc3623.txt

Vishwas Manral's discussion on the mailing list:
http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0203&L=ospf&T=0&F=&S=&P
=1888

I suggest that all other issues and ideas for GR can be either continued
in the other thread or started as separate threads.

Regards,
Ashok