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 protected]]
Sent: 2014年2月26日 17:12
To: Zhangxian (Xian)
Cc: [email protected]; [email protected]
Subject: RE: Comments on draft-minei-pce-stateful-sync-optimizations-01
Hi Xian, please see [Jon] below...
From: Zhangxian (Xian) [mailto:[email protected]]
Sent: 22 February 2014 07:33
To: Jonathan Hardwick
Cc: [email protected]; [email protected]
Subject: RE: Comments on draft-minei-pce-stateful-sync-optimizations-01
Hi, Jon,
Thank you very much for the constructive comments. Please see my reply
inline, marked with [Xian]:
From: Pce [mailto:[email protected]] On Behalf Of Jonathan Hardwick
Sent: 2014年2月15日 2:35
To:
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
Subject: [Pce] Comments on draft-minei-pce-stateful-sync-optimizations-01
Hi there
I have reviewed this draft �C 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
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.
[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:
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.
[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.
[Jon] Looks good to me.
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”.
[Jon] Apologies, I missed that.
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?
[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?
[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
[...] 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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
