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>
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
