Re: [OSPF] Comments / questions on RFC3623 and Update GR part 1 : BMA env

Hi Mitchell,
I have some comments inline;

On 11/14/06, Erblichs <erblichs@earthlink.net> wrote:
>
> Group,
>
>         First, I have a few questions to the base and the update.
>         These comments / questions pertain ONLY to BMA envs
>         but are also relevelent to other envs.
>
>         FYI) IMO, helpers are defined by two major requirements
>            a) the ability to recieve a grace-LSA before a hello
>               "new hello" and not restart the adj
>            b) the ability of a helper "Y" to (re)send a router-LSA, etc
> upon
>               router "X" exiting graceful restart that are in its
>               retransmit-list.
>
>
>         If this "helper" split functionality is supported, then only
>         a limited number of routers within a area need to be in
>         Full-helper mode.
>
>         Within BMA envs a DR-other above helper "b" functionality
>         is not really necessary for retransmit. We use the DR/BDR
>         for retransmit support.
>
>
>         IFFFFFFF, a GR router is the DR, who is in it grace-period,
>         and a DR-other stops sending hellos, if their are no
>         alternate paths thru another router for any forwarding
>         data. Then what benefit is it to prematurely end helper
>         mode? Basicly, most algs can determine ahead of time whether
>         the exiting router has contributed a primary link/path. If
>         it isn't then it has no consequence. Yes, data pkts that have
>         a intermediate dest will be forwarded 1 or two extra hops,
>         before they are dropped.
>
>         (Update: 2.0 Action on route calculation)
>         If a topology change occurs and the GR restarting router
>         is identified as the next hop. By definition it is in non-stop
>         forwarding mode and should be able to forward packets. If this
>         is identified as a topology change and the ONLY route is thru
>         this GR router, shouldn't packets be forwarded thru it anyway?
>         Not doing so blackholes those routes, IMO.

Suj>> Here topology change also includes routes which are no more valid,if
the lsa seeks a route to be removed and that route involves the GR router
the helper exits, thus black-holing and circumventing the GR router as
router
under plain restart.Note here that previously(rfc3623) the helper was
exiting
for all reasons, which has been curbed now so as you have pointed out if the

lsa effects the route which is ONLY through the restarting router will the
system
exit, which makes sense.

        Thus,
>         1) Helpers should be able to be able to support a, without b
>            If this is the case, router "X", if it is a DR should allow
>            all the DR-others to support a, while only the BDR need be
>            a "Full-Helper".

Suj>> I like your analysis in breaking up the helper job into partial and
full.
IMO  "Helper" is a behaviour of a router w.r.t to the GR operation, where as
the idea whether the helper is "Full-helper" else a "Partial" depends upon
the result
of election. In brief a "Helper" is  always expected to perform
"Full-helper" features as per your describe , if it does less; guess it is
plain lucky ! ,( also note Helper support maybe a feature switched on / off
by admin, not a partial/full helper).

        2) If router "X" is a DR-other only one of a "DR or BDR"
>            need to be a Full-helper. All LSAs can be placed on the
>            retransmit list of the for router "X" by the DR or BDR.
>
>         3) Topology change. A LSA aging out of the LSDB, will not
>            necessarily remove a element in the forwarding table?
>            If this can be detected, should it still force the exit
>            of a helper wrt graceful restart?

Suj>> as per the base ospf operation a max aged lsa on the lsa, should
trigger
it to flood the lsa (-->" which in turn should instigate the originator of
the lsa to resend a fresh copy, if fails ends in removal of the
corresponding route everywhere! "),
thus if the case happens as you have described a GR with "strict lsa
checking
enabled" i.e catch all topology changes should force the helper to exit as
it has to
flood this lsa to the GR router, here the update draft would tell you
prohibit your
exit only if the lsa somehows affects a route through the GR router, else
let peace
prevail, no need to exit.

        4) If router "X" is a DR and has entered graceful restart
>            with no BDR present, should the DR-other routers allow the
>            LSAs to become not refreshed and aged out because the
>            grace period has not expired.
>            How can "one" or more "HELPERS" force a new DR election?

Suj>> IMO the DR-other allows normal aging to continue, if the lsa age's out
before grace period expiry, the helpers would exit GR(see above) , again
applying the same logic.

A new election would disturb all previous adjacencies, do we need it?

        5) Even with a 30 min max for the grace period, some routers
>            may only retransmit once every 45 mins or so. How can we
>            guarantee that those retransmited-LSAs are not aged-out if
>            router "X" is the DR and is down for a longer time?
>
>             Shouldn't recieving the first grace-LSAs from a restarting
>             router initiate a re-send of the LSAs?

Suj>>  With the LSRefreshtime is 30 min , the MaxAge double(60min), the max
grace period is same as LSRefreshtime 30 min, I dont see how we reach a
stage where
the problem will come, you might want to consider some border cases i guess
there the previous arguments(see above) hold good.

        Mitchell Erblich

Best Regards,
Sujay

_______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www1.ietf.org/mailman/listinfo/ospf
>