Hi,
I have the following comments on draft-ietf-pce-pce-initiated-lsp-02:
Some comments require non minor changes (security section). I think the
document should progress, but I am not sure its fully ready for LC.
Section 3.2. "Operation overview"
- "A PCE may return a delegation to the PCC in order to facilitate
re-delegation of its LSPs to an alternate PCE."
In this context (protocol operation), a MAY seems appropriate.
Section 4.1:
- In draft-ietf-pce-stateful-sync-optimizations-01, the U is referenced in
the list of flags. draft-ietf-pce-pce-initiated-lsp-02 could use the same
format.
Section 5
- The section is a mix of object definition and procedures, the procedures
could be more clearly marked (having separate object format and procedure
section, or changing the section titles)
Section 5.1.
- The error procedure refers to I-D.ietf-pce-stateful-pce for a message
defined in this document, I-D.ietf-pce-stateful-pce should not define error
procedure for unknown message.
I believe you are refering to the error values
OLD:
"If either the SRP or the LSP object is missing, the PCC MUST send a
PCErr as described in [I-D.ietf-pce-stateful-pce]."
NEW:
"If either the SRP or the LSP object is missing, the PCC MUST send a
PCErr with error-type 6 (Mandatory Object missing) and error-value=10 (SRP
Object missing), respectively error-value=8 (LSP Object missing). Those
errors are defined defined in [I-D.ietf-pce-stateful-pce]."
- Section 3.2 has a more strict definition of the message content, that
matches the RBNF, namely including the ERO and ENDPOINTS objects,
the text of section 3.2 sould be moved to this section (the overview
being more detailed than the definition), but its also repeated in section
5.3., maybe better to reference section 5.3 or have section 5.3 be a
"procedures" subsection
Section 5.2.
- "The type object is defined in [I-D.ietf-pce-stateful-pce]."
This sentence could be removed
Section 5.3
- OLD: "The LSP is set up using RSVP-TE, extensions for other setup methods
are outside the scope of this draft."
NEW: "The LSP is assumed to be set up using RSVP-TE, extensions for other
setup methods are outside the scope of this draft."
- OLD: "The END-POINTS Object is mandatory for an instantiation request of
an RSVP-signaled LSP."
NEW: "The END-POINTS Object is mandatory for an instantiation request."
Regardless of RSVP or other protocol, the END-POINTS is required on a lot
of PCEP messages, so if new signaling protocols does not require the
END-POINTS, its better to leave the new definition that will affect other
PCEP messages to that document.
- Error code 6 (Object missing) for a missing TLV seems confusing, its
more a malformed object content (as the TLV is part of the object), the TLV
missing error should be reparented to error-type=10 (Reception of an
invalid object)
- "If there is conflict with
the LSP name, the PCC MUST send a PCErr message with Error-type=23
(Bad Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use).
The only exception to this rule is for LSPs for which the State
timeout timer is running (see Section 6)."
I am unsure the exception is a good mechanism, this is detailed further in
the comment for section 6.
- "LSPs that were instantiated as a result of a PCInitiate message MUST
have the C flag set in the LSP object."
C flag is not yet defined, please add reference to the section or has
Object extensions then procedures
- "If the PCC determines that the LSP parameters proposed in the
PCInitiate message are unacceptable, it MUST trigger a PCErr with
error-type=TBD (PCE instantiation error) and error-value=1 (Unacceptable
instantiation parameters)."
This procedure is cleaner and offers more possibility for the PCE to know
which parameter was wrong, base draft should use the same
- "A PCC MUST relay to the PCE errors it encounters in the..."
This imply that the PCC SHOULD wait for the LSP to be signaled before
reporting the LSP State, I would suggest the following text:
"The PCC SHOULD respond to the PCInitiate message when the LSP has been
signaled. On succesful completion ... (Last paragraph).
On unsucessfull completion a PCC MUST relay ..."
- on PCInitiate , the Symbolic Path Name TLV is mandatory, the LSP
Identifiers TLVs may be present unless specified (I do not see any
drawback/limitation, behavior is the same as mplsTunnelIndex)
is this correct?
- Are the LSP Error Code TLV and RSVP Error Spec TLV accepted, rejected
or ignored?
- Section 5.3.1 indicated a new optional TLV (SPEAKER-IDENTITY-ID), maybe
a TLV presence rules section could be usefull, its now distributed over
different sections and levels.
Section 5.3.1.
- Is there any specific reason to have the flag defined as a subsection of
the instantiation procedure rather than a separate section as the R flag?
- Nits : draft-ietf-pce-stateful-pce-10 define Flag, the document defines
Flags, name should be aligned
- "If the TLV appears for an LSP for which the C flag is 0,
the TLV MUST be ignored the PCC MUST send a PCErr message with Error-
type 23 ("Bad parameter value") and error value 2 ("Speaker identity
included for an LSP that is not PCE-initiated")."
To ease procedure, why not allow it? this can be set to the PCC
SPEAKER-IDENTITY-ID for that matter, or simply ignored, it can be up to the
PCE. Why is the error necessary here?
Section 5.4:
- OLD: "If the PLSP-ID specified in the PCInitiate message was not created
by the PCE, the PCC MUST send a PCErr message indicating "LSP is not PCE
initiated" (Error code 19,
error value TBD)."
- NEW: "If the PLSP-ID specified in the PCInitiate message was not created
by a PCE, the PCC MUST send a PCErr message indicating "LSP is not PCE
initiated" (Error code 19,
error value TBD)."
(In case of multiple PCEs)
- TLV presence rules are missing:
- is symbolic path name, lsp identifiers, ..etc allowed or ignored?
- does it make sense to allow the SPEAKER-IDENTITY TLV for debugging
purpose in the subsequent PCRpt ?
Section 6:
- For the delegation bit, adding "to the PCE the LSP is delegated to"
would make the text more clear
- What does contains the PCErr message of type 19 (Invalid Operation) and
value TBD "Delegation for PCE-initiated LSP cannot be revoked"?
I believe it should at least contains the LSP object.
- 'A PCE MAY return a delegation to the PCC, to allow for LSP transfer
between PCEs. Doing so MUST trigger the State Timeout Interval timer
([I-D.ietf-pce-stateful-pce]).'
the state timeout interval is defined as "time period before flushing
LSP state associated
with that PCEP session" (in case of session closed)
In the context of a PCE returning the delegation, the State Timeout
interval should only apply to the LSP, not the the state associated to the
session. This should be stated
- "To obtain control of a PCE-initiated LSP, a PCE (either the original
or one of its backups) sends a PCInitiate message, ..."
It feels a bit of a patch, I believe the PCC can redelegate the LSP to
the "original" PCE or to the "preferred" PCE by itself (Policies and
SPEAKER-IDENTITY-ID would allow for that), rather than adding an exception
(who wins in case the timeout is long and several PCEs connect at the same
time, for say a network failure?)
Section 8.
- Missing the new bit definition of Section 4.1. Stateful PCE Capability
TLV (according to draft-ietf-pce-stateful-pce-10, section 8.6.)
I : bit 29
- Missing the new bit definition of Section 5.2. The R flag in the SRP
Object - The bit number should be defined (bit 31), should a new registry
be defined at this point?
Section 8.3
- As described before, error-type=23, error-value=2 is not needed
- Error-type=24, error-value=3 : OLD: "RSVP signaling error" , NEW:
"signaling error" The type of error is included in the TLV, Restricting the
error to RSVP is too stong.
Section 9.1:
"Rapid flaps triggered by the PCE can also be an attack vector. This will
be discussed in a future version of this document."
Its rather time to document them
The exception mechanism also introduce another attack (restart the session
and steal LSPs)
Was the END-POINTS under PCE control considered? This would allow a
malicious PCE to strain other AS/domains.
On 22 December 2014 at 05:59, BELOTTI, SERGIO (SERGIO) <
[email protected]> wrote:
> Hi Druhv,
>
> as I pointed out in mail,
>
> in section 3.2 , when you talked about R flad in SRP, the fleg is new and
> is introduced in the following chapter.
>
> For me text should be:
>
> (2) In sec 3.2,
>
> OLD:
>
> To indicate a delete operation, the PCE MUST use the R flag in the SRP
> object in a PCUpd message.
>
> NEW:
>
> To indicate a delete operation, a new R flag is introduced in the SRP
> object and to be used in a PCInitiate message.
>
>
>
> Thanks
>
>
>
> Sergio
>
>
>
>
>
>
>
> -----Original Message-----
> From: Pce [mailto:[email protected]] On Behalf Of Dhruv Dhody
> Sent: lunedì 22 dicembre 2014 11:44
> To: [email protected]; [email protected]
> Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and
> draft-ietf-pce-stateful-sync-optimizations-01
>
>
>
> Hi All,
>
>
>
> > As planned, this message ignites a 3-week WG Last Call on both
>
> > draft-ietf-pce-pce-initiated-lsp-02
>
>
>
> Support with following comments:
>
>
>
> (1) We should align the tone of the draft to
> http://tools.ietf.org/html/rfc7399#section-20 which differentiates
> between the recommendation for instantiation (this draft), and the actual
> (NMS like) instantiation of the LSPs (marked out of scope). This could
> either be done by a suitable text in Introduction and/or use of phrase
> 'recommend instantiation' in the document.
>
>
>
> (2) In sec 3.2,
>
> OLD:
>
> To indicate a delete operation, the PCE MUST use the R flag in the SRP
> object in a PCUpd message.
>
> NEW:
>
> To indicate a delete operation, the PCE MUST use the R flag in the SRP
> object in a PCInitiate message.
>
>
>
> I guess Ramon pointed this out already!
>
>
>
> (3) In sec 5.3.1, we are changing the meaning of the SPEAKER-IDENTITY-ID
> TLV, which was earlier used in OPEN to identify the exact PCEP-Speaker but
> now here it identifies the PCE that initiated the LSP. This looks like a
> hack, a better idea would be to define a new TLV type
> PCE-INITIATED-IDENTITY-ID with the same format.
>
>
>
> (4) Section 9.1, it says...
>
> Rapid flaps triggered by the PCE can also be an attack vector. This will
> be discussed in a future version of this document.
>
>
>
> The text for this needs to be added.
>
>
>
> (5) It would be nice to have a manageability consideration section.
>
>
>
> (6) Few lines on state synchronization should also be added - If the DB
> did not survive the PCC restart, PCE must send the PCE initiated message
> again. During state synchronization the PCE should get the status of PCE
> Initiated LSPs with C flag set in the LSP object. Incase of redelegation to
> a different PCE the same should be reported during state synchnronization
> with D=0. The original PCE should also be allowed to send PCInitiate to get
> back the delegation. (this is not allowed in the current text as PCInitiate
> with non-zero PLSP-ID is allowed only during State Timeout timer)
>
>
>
> Nits
>
> - Reference to 2119, as SHOULD, MUST are used in the document
>
> - Expand on first use LER, LSR etc
>
> - Reference to SRP, LSP, PLSP-ID as defined in [I-D.ietf-pce-stateful-pce]
>
> - section 3.2 s/PCinitiate/PCInitiate/
>
> - section 4 s/A PCC indicates its ability.../A PCEP speaker indicates its
> ability/ (because both PCC and PCE needs to do this)
>
> - section 4.1 Type=16 should be removed as its TBD in the base document as
> well
> http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10#section-7.1.1
>
> - section 4.1
>
> OLD:
>
> If set to 1 by a PCE, the I flag indicates that the PCE will attempt to
> instantiate LSPs.
>
> NEW:
>
> If set to 1 by a PCE, the I flag indicates that the PCE can attempt to
> instantiate LSPs.
>
>
>
>
>
> > and draft-ietf-pce-stateful-sync-
>
> > optimizations-01.
>
>
>
> Support (As a co-author)
>
>
>
> Regards,
>
> Dhruv
>
>
>
> > 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
>
> > [email protected]
>
> > https://www.ietf.org/mailman/listinfo/pce
>
>
>
> _______________________________________________
>
> Pce mailing list
>
> [email protected]
>
> https://www.ietf.org/mailman/listinfo/pce
>
> _______________________________________________
> Pce mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pce
>
>
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
