Hi,
I have the following comments on
draft-ietf-pce-stateful-sync-optimizations-01.
Section 3 :
The documents proposes different optimizations, spending a paragraph or
two to describe the different optimizations, then a list of extensions, and
finish with procedures would help.
Section 3.2
- A bit INCLUDE-DB-VERSION (IDB) is defined, section 7 defines the S bit.
Section 3.2.2
- OLD: "The type of the TLV is [TBD] and it has a a variable length, which
MUST be greater than 0 and padded to 4-octet alignment (, and
padding
is not included in the Length field).
"
NEW: "The type of the TLV is [TBD] and it has a a variable length, which
MUST be greater than 0. The Value is padded to 4-octet alignment.
The padding
is not included in the Length field"
The value field is padded, not the lenght
Section 4.
- Incremental is not allowed, because Paragraph 6 of section 3.2 indicates:
"Otherwise, the PCC MUST perform state synchronization to the stateful
PCE."
Section 3.2 should take into consideration all the bits defined, moving
the procedures after all the object definition would allow for an easier
understanding.
- proposes-> defines
Section 4.2.
- Figure 7: I believe this is the D flag, not the T flag
Section 5.
The use case is different from section 6, but they use the same bit to
advertize that capability, so if T bit is set, the PCC MUST/SHOULD/MAY wait
the trigger from the PCE??
Section 6.2.
- OLD: "The PCC MUST respond with a PCRpt message and SHOULD include the
SRP-ID-number of the PCUpd that triggered the resynchronization."
NEW: "The PCC MUST respond with a PCRpt message with the LSP state, SYNC
Flag set to 0 and MUST include the SRP-ID-number of the PCUpd that
triggered the resynchronization."
SHOULD -> MUST.
draft-ietf-pce-stateful-pce-10, section 5.6.2 indicates that the
PCRpt MUST include the SRP id in the subsequent PCErr or PCRpt. I see no
justification in the text to change the mechanism described in
draft-ietf-pce-stateful-pce-10.
The SYNC flag MUST be set to 0, otherwise it may be confused with a
full sync.
- I believe all those updates are scoped only to the session that
triggered the delta/PCE triggered sync, adding it explicitly would be good,
as its a change in the PCRpt mechanism of the PCC.
- What happens if the PCE sends multiple resync requests while the a full
resync is in progress?
Section 7:
- This should under section 3.3. PCEP Extensions, and refer to the section
defining the bit behavior,
- D bit requires the S bit to be set, correct? A corresponding error is
missing
- The behavior of T bit is not clear, see comment of section 5.
- T bit and D&S bit combination : it seems the T bit behavior does not
depend on the INCLUDE-DB-VERSION and Delta, so it can be set independently.
This should be specified.
Manageability section is missing.
Section 8.3.
Suggested values are off, 29 is the suggested value of the I bit of
draft-ietf-pce-pce-initiated-lsp-02.
I believed this should be:
TBD(suggested value 27) DELTA-LSP-SYNC-CAPABILITY This document
TBD(suggested value 28) TRIGGERED-SYNC This document
TBD(suggested value 30) INCLUDE-DB-VERSION This document
Section 9.
The document introduces new messages that may introduce load on the PCC, a
malicious PCE may flood the PCC with resync requests, this should be
mentioned.
On 1 December 2014 at 12:18, <julien.meu...@orange.com> wrote:
> Dear all,
>
> As planned, this message ignites a 3-week WG Last Call on both
> draft-ietf-pce-pce-initiated-lsp-02 and
> draft-ietf-pce-stateful-sync-optimizations-01.
> It will end on Monday December 22 at 11:59 PM, HST.
>
> Please send your comments to the PCE mailing list.
>
> Thanks,
>
> JP & Julien
>
>
> ____________________________________________________________
> _____________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
