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.
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.
Explicit notification is quicker to accomplish refusal meaning 1 and 2.
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.
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
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
