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

From: Uma Chunduri <[email-masked]>
Date: Fri, 24 May 2019 10:48:41 -0700

As asked by chairs I was trying to write the shepherd report on this doc.

Have few quick questions on this work:

1.

Observation: The new text added in 2.2.3 (PR and PA bits) is almost similar
 to section 2.2.1 (RR and RA bits)

Now is there any relation of the timer here with T3 (which would have been
set by restarting router with the value received with RA bit set, assuming
it is lower than the initialized value  65535).

There is no description or guidance on how these values are related and how
the restarting router handle this.

2.

On the text below

"a.  If additional topology changes occur, the adjacency which is in
       planned restart state MAY be brought down even though the hold
       time has not yet expired.  Given that the neighbor which has
       signaled a planned restart is not expected to update its
       forwarding plane in response to signaling of the topology changes
       (since it is restarting) traffic which transits that node is at
       risk of being improperly forwarded. "

Is this any topology change ? Not related to the restarting router in
question?

Need clarification text here or point me if I miss something.

Have few more questions/comments overall and shall come back.

--
Uma C.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 24 May 2019 21:21:30 +0000

Uma –

Inline.

From: Lsr <[email-masked]> On Behalf Of Uma Chunduri
Sent: Friday, May 24, 2019 10:49 AM
To: [email-masked]
Subject: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

1.

Observation: The new text added in 2.2.3 (PR and PA bits) is almost similar  to section 2.2.1 (RR and RA bits)

Now is there any relation of the timer here with T3 (which would have been set by restarting router with the value received with RA bit set, assuming it is lower than the initialized value  65535).

There is no description or guidance on how these values are related and how the restarting router handle this.

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

I do not know what text in the draft suggests to you that there is any relation between PR/PA and RR/RA.

2.

On the text below

Is this any topology change ? Not related to the restarting router in question?

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

   Les

--
Uma C..

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 28 May 2019 17:08:45 -0700

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:] 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?

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 29 May 2019 01:01:30 +0000

Uma -

From: Uma Chunduri <[email-masked]>
Sent: Tuesday, May 28, 2019 5:09 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

Les,

Thx. Yes, I got that.

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

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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 29 May 2019 14:06:48 +0000

Hi Les, Uma,

Excuse the top-post but Outlook doesn’t do well with inline response for messages such as this one. AFAIK, no implementation defaulted to aborting graceful restart due to any topology change as recommended by RFC 3623.

Thanks,
Acee
From: Lsr <[email-masked]> on behalf of "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tuesday, May 28, 2019 at 9:02 PM
To: Uma Chunduri <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

Uma -

Les,

Thx. Yes, I got that.

   Les

Section 2.2.3

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 29 May 2019 18:56:03 -0700

Les,

Replies in-line [Uma1]:

On Tue, May 28, 2019 at 6:01 PM Les Ginsberg (ginsberg) <[email-masked]>
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. *

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

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 29 May 2019 19:12:19 -0700

Hi Acee,

On Wed, May 29, 2019 at 7:06 AM Acee Lindem (acee) <[email-masked]> wrote:

> Hi Les, Uma,
>
>
>
> Excuse the top-post but Outlook doesn’t do well with inline response for
> messages such as this one. AFAIK, no implementation defaulted to aborting
> graceful restart due to any topology change as recommended by RFC 3623.
>
>
> Np. For IS-IS/RFC 5306  (base) yes no implementation defaulted to aborting
GR due to topology changes. If one wants to capture topology changes
during restart yes they have to do beyond GR(NSR?).
However, in the bis document with planned restart indication this is being
introduced (i.e., exiting GR if "any" topology change is detected by the
neighbor of restating router).

Thank you!
--
Uma C.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 30 May 2019 05:09:44 +0000

Uma –

Hopefully we are making progress this time.
Replies inline. Look for [Les2:]

From: Uma Chunduri <[email-masked]>
Sent: Wednesday, May 29, 2019 6:56 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:
Uma -

[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

[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. ☺

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 30 May 2019 05:19:57 +0000

Uma –

I think I have addressed this in my previous reply on this thread, but just to be sure nothing is left unaddressed…

The bis document is introducing planned restart signaling – so the helper router now has the opportunity to react to topology changes while waiting for the restarting router to come back to life.
We have chosen to leave the decision of when to bring down the adjacency to implementations for a number of reasons:

1.       There is no interoperability issue if different helpers use different policies

2.       Specifying an optimal behavior that applies to all scenarios would be difficult and unnecessarily constraining

3.       With Acee’s feedback that at least some implementations of OSPF GR have chosen not to follow a prescriptive behavior I think we have validation of this choice

   Les

From: Uma Chunduri <[email-masked]>
Sent: Wednesday, May 29, 2019 7:12 PM
To: Acee Lindem (acee) <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Subject: Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

Hi Acee,

On Wed, May 29, 2019 at 7:06 AM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Les, Uma,

Np. For IS-IS/RFC 5306  (base) yes no implementation defaulted to aborting GR due to topology changes. If one wants to capture topology changes  during restart yes they have to do beyond GR(NSR?).
However, in the bis document with planned restart indication this is being introduced (i.e., exiting GR if "any" topology change is detected by the neighbor of restating router).

Thank you!
--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 30 May 2019 16:28:29 -0700

Les,

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

On Wed, May 29, 2019 at 10:09 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

Uma –

[Uma2]: Indeed! Thx!

Replies inline. Look for *[Les2:]  *

*From:* Uma Chunduri <[email-masked]>
> *Sent:* Wednesday, May 29, 2019 6:56 PM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
>
> ...
>
> *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.