Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

[Uma Chunduri <[e-mail]>]

Les,

Replies in-line [Uma1]:


On Tue, May 28, 2019 at 6:01 PM Les Ginsberg (ginsberg) <[e-mail]>
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?

              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?


                        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. **J*
>

>

[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! :)



*We could have been more prescriptive – similar to
> https://tools.ietf.org/html/rfc3623#section-3.2
> <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).



*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.