Subject: [Pce] Comments on draft-minei-pce-stateful-sync-optimizations-01

From: Jonathan Hardwick <[email-masked]>
Date: Fri, 14 Feb 2014 18:35:04 +0000

Hi there

I have reviewed this draft - here are my comments.

Best regards
Jon

Section 3.2
Figure 2, I think the "sync done" PCRpt should have SYNC=0, not SYNC=1.

Section 5.2
   If a PCC has to force full LSP DB
   synchronization due to reasons including but not limited: (1) local
   policy configured at the PCC; (2) no sufficient LSP state caches for
   incremental update, the PCC can set the D flag to 0.

Perhaps I have misunderstood, but I think case (2) above doesn't work.  The PCC does not know that it has "no sufficient LSP state caches" until it receives the OPEN from the PCE and sees what DBv the PCE has sent.  By then, the PCC has already sent its OPEN so it is too late to set D=0.  To cover case (2) the draft needs a mechanism for the PCC to change its mind and tell the PCE that it is going to send a full snapshot, not a replay of the missing database updates.  The simplest thing is probably for the PCC to bring the session down and then bring it back up again with D=0.

Section 4 talks about the PCE having to mark its LSP database as stale, and then remove any stale LSPs at the end of the synchronization process.  I assume that this does not apply in section 5.  To avoid confusion, I think section 5 should state that the PCE does not mark its LSP database as stale if both it and the PCC have set D=1.

In figure 7, I may have misunderstood section 4, but I don't think this is how the T bit is specified.  I don't think T=1 forces the PCC to wait for a PCUpd before sending the initial snapshot as you have shown.  I don't think this substantially changes anything about section 5, so I suggest removing the discussion of the T bit from section 5.

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Sat, 22 Feb 2014 07:32:36 +0000

Hi, Jon,

   Thank you very much for the constructive comments.  Please see my reply inline, marked with [Xian]:
From: Pce [mailto:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: 2014年2月15日 2:35
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] Comments on draft-minei-pce-stateful-sync-optimizations-01

Hi there

I have reviewed this draft – here are my comments.

Best regards
Jon

Section 3.2
Figure 2, I think the “sync done” PCRpt should have SYNC=0, not SYNC=1.
[Xian]: Indeed. Thank you for spotting this typo.

Section 5.2

Perhaps I have misunderstood, but I think case (2) above doesn’t work.  The PCC does not know that it has “no sufficient LSP state caches” until it receives the OPEN from the PCE and sees what DBv the PCE has sent.  By then, the PCC has already sent its OPEN so it is too late to set D=0.  To cover case (2) the draft needs a mechanism for the PCC to change its mind and tell the PCE that it is going to send a full snapshot, not a replay of the missing database updates.  The simplest thing is probably for the PCC to bring the session down and then bring it back up again with D=0.

[Xian]:  It actually depends, IMHO. If it is due to the 1st reason listed above, then, it can decide before sending OPEN and set D=0. The cases as a result of the 2nd reason might be more complicated. Your analysis would be one of the cases, in which a PCC can detect the insufficient LSP state caches ONLY after it gets the DB version information from the other party. But if a PCC has no LSP state caches or incomplete (missing quite some LSP state or those of the DB version in between), I think it is possible that it can decide without even checking the DBv from the other party. Does this clarify?

To include the case you described, how about we update the text  as below?

OLD:

[DD] NEW:
   If a PCC may have to force full LSP DB
   synchronization due to reasons including but not limited: (1) local
   policy configured at the PCC; (2) no sufficient LSP state caches for
   incremental update, the PCC can set the D flag to 0. Note a PCC may have to bring
 down the current session and  force a full LSPDB synchronization with D flag set to
0 in the  subsequent open message.

Section 4 talks about the PCE having to mark its LSP database as stale, and then remove any stale LSPs at the end of the synchronization process.  I assume that this does not apply in section 5.  To avoid confusion, I think section 5 should state that the PCE does not mark its LSP database as stale if both it and the PCC have set D=1.
[Xian]: Sure.  I think we have already explained in Section 5. The last sentence of the paragraph below Figure 7 says: “Note that the PCE should not mark the existing LSPs as stale for incremental state synchronisation”.

In figure 7, I may have misunderstood section 4, but I don’t think this is how the T bit is specified.  I don’t think T=1 forces the PCC to wait for a PCUpd before sending the initial snapshot as you have shown.  I don’t think this substantially changes anything about section 5, so I suggest removing the discussion of the T bit from section 5.
[Xian]：Section 4 describes how a PCE can force re-synchronization after the initial LSP-DB synchronization has been done. Section 5 talks about an alternative method for the initial LSP-DB sync. (i.e., incremental way).  The idea here is allow PCE to control the sequence of incremental sync., the authors do see the value. However, you can see from the explanation of Section 5, setting the T=1 is NOT a mandate operation to enable incremental sync., but a feature optical and not covered by Section 4. The figure is drawn as shown because we intends to capture both features. Does this clarify your doubt?

Regards,
Xian

---

From: Jonathan Hardwick <[email-masked]>
Date: Wed, 26 Feb 2014 09:12:05 +0000

Hi Xian, please see [Jon] below...

From: Zhangxian (Xian) [mailto:[email-masked]]
Sent: 22 February 2014 07:33
To: Jonathan Hardwick
Cc: [email-masked]; [email-masked]
Subject: RE: Comments on draft-minei-pce-stateful-sync-optimizations-01

Hi, Jon,

From: Pce [mailto:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: 2014年2月15日 2:35
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Pce] Comments on draft-minei-pce-stateful-sync-optimizations-01

Hi there

Best regards
Jon

Section 3.2

Section 5.2

OLD:

[DD] NEW:

[Jon] Looks good to me.

[Jon] Apologies, I missed that.

[Jon] I’m still unsure how triggered synchronizations are used by section 5.2.  Here is the text that is confusing me:

   A stateful PCE MAY choose to control the LSP-DB synchronization
   process.  To allow PCE to do so, PCEP speakers MUST set T bit to 1 to
   indicate this (as described in Section 4<http://tools.ietf.org/html/draft-minei-pce-stateful-sync-optimizations-01#section-4>).  If the LSP-DB Version is
   mis-matched, it can send a PCUpd message with PLSP-ID = 0 and SYNC =
   1 in order to trigger the LSP-DB synchronization process.

The final sentence says that the PCE “can send a PCUpd”.  It is not clear under what circumstances the PCC MUST wait for the PCE to trigger the initial synchronization.  Please could you clarify?  Do you mean that the PCE MUST trigger the initial synchronization any time the PCC and PCE have both set the T bit in their Open messages?  Does that also apply in section 4?  My understanding from section 4.1 is that this mechanism is intended to allow the PCE to sanity check the LSPDB and recover from internal errors after the initial session is established, not to trigger the initial synchronization:

   [...] it can be beneficial to be able to resynchronize this
   state even after the session has been established.  The PCE may use
   this approach to continuously sanity check its state against the
   network, or to recover from error conditions without having to tear
   down sessions.

Regards,
Xian

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 28 Feb 2014 02:18:09 +0000

Hi, Jon,

         Glad to see the first two points are now cleared.  Please see my explanation to the last point inline, marked with [Xian2]:

From: Jonathan Hardwick [mailto:[email-masked]]
Sent: 2014年2月26日 17:12
To: Zhangxian (Xian)
Cc: [email-masked]; [email-masked]
Subject: RE: Comments on draft-minei-pce-stateful-sync-optimizations-01

Hi, Jon,

Hi there

Best regards
Jon

Section 3.2

Section 5.2

OLD:

[DD] NEW:

[Jon] Looks good to me.

The final sentence says that the PCE “can send a PCUpd”.  It is not clear under what circumstances the PCC MUST wait for the PCE to trigger the initial synchronization.  Please could you clarify?
[Xian2]: The motivation behind allowing PCE to trigger initial LSP re-synchronization to avoid over flooding the PCE. If this capability is enabled, PCCs won’t start the synchronization process until the PCE sends a PCUpd.
Do you mean that the PCE MUST trigger the initial synchronization any time the PCC and PCE have both set the T bit in their Open messages?
[Xian2]: NO. Only when PCE wants to have the capability to trigger the timing of when a PCC should report the LSP state during initial re-synchronization. And it is purely optional.
Does that also apply in section 4?  My understanding from section 4.1 is that this mechanism is intended to allow the PCE to sanity check the LSPDB and recover from internal errors after the initial session is established, not to trigger the initial synchronization:
[Xian2]: No. Section 4 indeed only describes the function as you understand and written above. So, the purpose of these two Sections (section 4 and Section 5.2) is different (one is to use in sanity check after the initial synchronization has been finished, and the other is used during initial synchronization). But from protocol extension point of view, Section 5 does not ask any extensions, but re-use what already defined in Section 4.1. Hope this clarifies.

Regards,
Xian

Regards,
Xian