Uma – Hopefully we are making progress this time. Replies inline. Look for [Les2:]
From: Uma Chunduri <umac.i...@gmail.com> Sent: Wednesday, May 29, 2019 6:56 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Cc: lsr@ietf.org Subject: Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01 Les, Replies in-line [Uma1]: On Tue, May 28, 2019 at 6:01 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote: Uma - 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. [Uma1]: Yes. Who said it's otherwise? [Les2:] Well you have repeatedly asked about T3 in the context of PA – and I have repeatedly said “not relevant”. But as you indicate you get that, let’s agree to move on. You are simply not answering what I was asking. I have been taking about restarting router when it receives PA with hold time set as specified in 2.2.3 (re-read my original question). OK, let me ask this differently: You added the first 2 events to the 5306 table in section 3.2 as shown below. But I didn't see "RX PA" event. Perhaps you need to specify what you would do based on the newly added text in 2.2.3. Also specify: What is the impact on restarting router when the hold time value received in PA and RA are the same/different values? Unlike receiving RA would cause T3 to be set to prepare for the worst; describe the actions of a restarting router has to when receiving PA. You ought to be doing something with hold time you received with PA, what is it? [Les2:] OK – now I understand your question. RA is associated with post-restart activities. The restarting router has rebooted and is attempting to reestablish adjacency/LSPDB synchronization in a modest amount of time – which is constrained by the Remaining Holdtime sent by the helper router along w RA. That is then used by the restarting router to bound T3 because we want to complete LSPDB synchronization before the helper router times out the adjacency. PA is associated with pre-restart activities. Once received, the restarting router knows that the helper router is aware of the planned restart and the restarting router knows it is safe to actually do the restart. The value of the Remaining Holdtime that came along w the RA is only to be able to confirm/report how long the helper router will allow the restarting router to come back to life. This value can’t be used by the Restarting Router (e.g., IS-IS obviously cannot alter how long it takes for the router to reload) – but it might be useful as a debug mechanism in cases where some flapping occurs associated with the restart. I think there are a few things that could be clarified in the text: 1)State what I have written above 2)Add Receive PA into the state machine diagram (as you suggested) 3)We failed to mention that when sending the PR the restarting router should set the Remaining Holdtime to a value large enough to allow for the router reload to occur. This will serve as the value the helper router should use to maintain the adjacency in the absence of hellos while the restarting router is reloading I will spin a new version with those changes. 3.2. Restarting Router Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait | | RA | CSNP | =================================================================== Restart | Send PR | | | planned | | | | ------------+--------------------+-----------+-----------+------------ Planned | Send PR clr | | | restart | | | | canceled | | | | ------------+--------------------+-----------+-----------+------------ Router | Send IIH/RR | | | restarts | ADJ Init | | | | Start T1,T2,T3 | | | ------------+--------------------+-----------+-----------+------------ RX RR | Send RA | | | ------------+--------------------+-----------+-----------+------------ RX RA | Adjust T3 | | Cancel T1 | | Goto ADJ Seen RA | | Adjust T3 | ----------- +--------------------+-----------+-----------+------------ No offense intended – but your question is bizarre – I really don’t understand what logic leads you to ask it. ☺ [Uma1]: You said an obvious statement above that "Tx timers do not apply to neighbors of the restarting routers.." while I am asking about restarting router who received PA with holding timer value set. No offence intended, but it's the bizarre response I never expected from you! :) [Les2:] Apologies, but I really was struggling to understand where you were coming from. Thanx for persevering. I think we have fairly traded “bizarre”. Let’s be at peace now. ☺ 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. [Uma1]: Precisely. This is what I am looking for and I am not sure why describing this won't help to have a consistent behavior on neighboring node implementing this feature.. You gave a very good example where it is described (no sub-optimal). [Les2:] I would really rather not be prescriptive here. I don’t think it helps – and now that Acee has indicated most implementations ignore the prescriptive text present in RFC3623, I am encouraged that we have taken the right approach in leaving this up to the implementation. I think we will have to agree to disagree on this. Les 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. [Uma1]: There is no rocket science here; any implementation should avoid bringing down the ADJ for unrelated topology changes in a remote place which has no bearing or involvement of the restating router. For the record, IMO this need to be clarified (but that's up to you if you choose not to specify and keep this for only smart implementations!). Cheers! -- Uma C.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
