Uma -
From: Uma Chunduri <[email protected]>
Sent: Tuesday, May 28, 2019 5:09 PM
To: Les Ginsberg (ginsberg) <[email protected]>
Cc: [email protected]
Subject: Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01
Les,
[Les:] The timers (T1, T2, T3) are NOT relevant to PR/PA.
PR is sent BEFORE a router does a restart to alert the neighbors that the
signaling router’s control plane is going away for a time.
RR/RA are associated with what happens AFTER the router has restarted and now
wants to reacquire adjacencies/LSDB.
Thx. Yes, I got that.
I do not know what text in the draft suggests to you that there is any relation
between PR/PA and RR/RA.
Newly added Section 2.2.3 a says this:
The "remaining time" transmitted according to (b)
below MUST reflect the actual time after which the adjacency will
now expire.
The above is same for section 2.2.1 a, which talks about RR and RA.
This is the reason, I asked, what is the implication of same timer value here
for PR/PA.
For example, what are the implications of this new timer times out before the
value specified in RA (as PR is obviously initiated before) ? Also see my
original question.
[Les:] Tx timers do NOT apply to the neighbors of the restarting router – and
they are the only routers whose control plane is alive while the restarting
router is reloading.
No offense intended – but your question is bizarre – I really don’t understand
what logic leads you to ask it. ☺
[Les:] What constitutes a topology change significant enough to trigger
bringing down the adjacency is an implementation decision.
Definition of the conditions is NOT an interoperability issue and therefore
does not fall within the scope of the draft.
I would have agreed with the above statement if this is the guidance for the
restarting router. Here the topology change is detected by the neighboring
router (see your text below) and you do want a consistent behavior from
neighboring node from any vendor. No?
[Les:] The neighbor is free at any time to declare adjacency to the restarting
as down. Obviously, if it does so, this will affect forwarding in the network.
Whether the neighbor is making the “optimal choice” based on the topology
change is an implementation decision and it is up to the customers to judge
whether they are happy w the implementation choice or not. It does not affect
interoperability.
We could have been more prescriptive – similar to
https://tools.ietf.org/html/rfc3623#section-3.2 – but I think that is
sub-optimal. It is possible for a topology change to occur which does not
affect forwarding via the restarting node – in which case it isn’t helpful to
bring the adjacency down.
Rather than try to detail all possible cases, we have left it as an
implementation decision as to how “smart” an implementation wants to be. Given
that the neighbor will send an updated LSP of its own reflecting the down
adjacency in such a case, the rest of the network will know that there is no
longer a path via the restarting router.
It simply isn’t necessary to mandate a behavior.
Les
Section 2.2.3
" While a control plane restart is in progress it is expected that the
restarting router will be unable to respond to topology changes. It
is therefore useful to signal a planned restart (if the forwarding
plane on the restarting router is maintained) so that the neighbors
of the restarting router can determine whether it is safe to maintain
the adjacency if other topology changes occur prior to the completion
of the restart. "
--
Uma C.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
