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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Uma –

V2 of the draft has been published addressing your comments.

Note that “RX PR” was already in the state table in Section 3.1 – though I did do a minor update to the entry.

Regarding your question:  “is there any condition reload has to be initiated immediately after sending the PR by restarting router?”

I think you know that all we are defining here are extensions to the IS-IS protocol to signal an impending reload. Definition of when the router actually does the reload is obviously out of scope – IS-IS is not the controlling entity of a router.

The use of the term “additionally” has been retained in the Abstract. It follows the original wording in RFC 5306. As each paragraph describes an “additional” capability the multiple use of the term is appropriate.

   Les


From: Uma Chunduri <[e-mail]>
Sent: Thursday, May 30, 2019 4:28 PM
To: Les Ginsberg (ginsberg) <[e-mail]>
Cc: [e-mail]
Subject: Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

Les,

Few more comments for  your updated version.
in-line [Uma2]:



On Wed, May 29, 2019 at 10:09 PM Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>> wrote:
Uma –

Hopefully we are making progress this time.
[Uma2]: Indeed! Thx!

Replies inline. Look for [Les2:]

From: Uma Chunduri <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, May 29, 2019 6:56 PM
To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>
...
I think there are a few things that could be clarified in the text:

1)State what I have written above
[Uma2]: Yes, that would help.
2)Add Receive PA into the state machine diagram (as you suggested)
[Uma2]: For completeness you might want to add "RX PR" too in section 3.1 table (yup, same as currently documented receiving RR - being restarting router). Also what happens in sec 3.1 for running router (aka neighbor of the restarting router) when only RX PR Clr but RX RR set.

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
[Uma2]: "large enough to allow for the router reload"  - is there any condition reload has to be initiated immediately after sending the PR by restarting router?

I will spin a new version with those changes.
[Uma2]:
"           This document additionally describes a mechansim for a router to
     signal its neighbors that it is preparing to initiate a restart while
     maintaining forwarding plane state.  This allows the neighbors to
     maintain their adjacencies until the router has restarted, but also
     allows the neighbors to bring the adjacencies down in the event of
     other topology changes."

 Nit: Newly added text - "additionally" has been repeated in the original text after this paragraph.

--
Uma C.