Hello Acee,
Agree that some widely deployed implementations have the default of
ignoring lsa change and re-starts occur quickly which
is infact partial and transparent to most traffic watchers.
IMHO the original implementation idea of Moy et al was to implement the
policy on helper, the very reason the re-start reason was
included in the grace tlv.
The re-start reason given by the re-starter implements the policy on the
helper.
1) Software Reset.
2) Unknown reason(probably hardware re-start) in this case I dont want
to help re-starter.
3) Other reasons.
LLS Hello maybe used, but then you have to enable LLS processing and
other configuration dependencies.
Grace LSA is anyway opaque.
With Regards,
Abhay
Acee Lindem wrote:
Hi Abhay,
On Feb 27, 2007, at 10:25 PM, Abhay D.S wrote:
hello acee,
The scenario where in helper router is configured not to support even
if they belong to the same administrative domain
is when we are using critical real-time traffic which is on-demand.
1) Except in controlled conditions, almost all graceful re-starts are
partial re-starts.
This is not the case with the widely deployed implementations. Most
implementations default to ignoring LSA changes and the restarts occur
very quickly.
2) If router was using more than just IP forwarding, towards
re-starter and also had level 2 or mpls forwarding on backup peer
it can refuse helping re-starter.
Here refusal has two meanings:
1) Refusal to use the black holing and route looping behavior of
re-starter (which is ofcourse temporary)
2) Allow the other peers of the re-starter to avoid the non-helper
router via the re-starter such that traffic can still flow around the
re-starter
to the non-helper.
Graceful restart is not designed to work with some FULL neighbors but
not others. So, if you have cases where it won't work, you simply
don't use it.
Explicit notification is quicker to accomplish refusal meaning 1 and 2.
There is an explicit mechanism today - it is just dependent on the
database exchange having started so, dependent on other factors, using
an empty hello LLS could be quicker.
In simpler words, if I am helper, I would say, I have lots of bursty
on-demand traffic, there are lots of users dialing in becoming my
peers for sometime
and then hanging up. I have backup paths towards same destinations
(probably switched paths). I want less delay variation on my
traffic.I dont want
to be busy helping re-starter give back routing information and
updating my caches, when I have already had working backup caches.
Also as a policy
after your first re-start I will not use re-starter for quite
sometime as my next hop till I become stable with my topologies.
If implementations have such policies then not requiring state >=
EXCHANGE to notify the restarting router would be faster. Do you know
of OSPF graceful restart implementations that offer this option?
Thanks,
Acee
With Regards,
Abhay
Acee Lindem wrote:
I don't think we've reached resolution on this draft. Here is my take:
- Explicit helper refusal to participate in graceful restart
There are situations where an explicit notification would be faster
than the RFC 3623 case of the helper originating an inconsistent
LSA. The updated draft lists alternatives for this that are
acceptable (IMHO, modifying LSA flooding to support one shot
signaling was not :^). I'm not really sure the scenario where the
helper is configured not to help makes that much sense (other than
in a test lab). An OSPF routing domain is under a single
administrative domain and why would someone configure OSPF routers
to attempt to restart gracefully while configuring their neighbor
not to help.
- Classification of LSA changes as to whether or not they terminate
graceful restart.
Right now we have two levels 1) LSA changes that would be flooded
to the restarting router will terminate graceful restart and, 2) LSA
changes do not terminate graceful restart. Irrespective of the RFC
3623 default, most implementations default to the latter. This
drafts proposes a third flavor that attempts to classify changes and
terminate graceful restart in the presence of changes to previously
advertised links and prefixes but not new information. I think this
is broken since new information can cause a routing loop as well.
Furthermore, I don't see a real requirement for an alternate flavor.
And, if there was to be a third flavor, it should be the the
variation Vishwas Manral suggested even though it is quite CPU
intensive (determine whether the new LSA information changes a route
to the restarting router and terminate graceful restart only when it
does).
Thanks,
Acee
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
<abhayds.vcf>
begin:vcard
fn:Abhay Rao
n:Rao;Abhay
email;internet:[EMAIL PROTECTED]
version:2.1
end:vcard
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
