On 12/22/2014 11:44 AM, Dhruv Dhody wrote:
Hi Robert,
Hello Dhruv,
See inline
See inline...
-----Original Message-----
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Robert Varga
Sent: 18 December 2014 20:15
To: julien.meu...@orange.com; pce@ietf.org
Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-
02 and draft-ietf-pce-stateful-sync-optimizations-01
Hello,
donning the implementer (as opposed to co-author) hat, I have
comments pertaining to draft-ietf-pce-pce-initiated-lsp, specifically
to Section 6. In general it seems to contradict the general outline
of the extension as stated in section 3.2 paragraph 4.
The first paragraph clearly forbids the use of PCRpt D=0 for PCE-
initiated LSPs. It is not clear whether this restriction applies to
all PCRpts, or only the PCRpt solicited by the PCInitiate message.
Section 3.2 paragraph 4 seems to indicate this applies to solicited
PCRpts only, which is what makes sense. A clarification is definitely
needed.
But http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10#section-5.5.1
says..
Note that for an LSP to remain delegated to a PCE, the PCC MUST set
the Delegate flag to 1 on each LSP Status Report sent to the PCE.
So the D flag must be set on all PCRpts (including the solicited (first) PCRpt
and any other PCRpt message).
Right, but that would also mean that a PCE-initiated LSP cannot be
reported to backup PCEs, as that would mean the LSP is delegated to
multiple PCEs at the same time...
I am not sure what text in section 3.2 paragraph 4 is an issue?
The specific text is this:
Once instantiated, the delegation procedures for PCE-initiated LSPs
are the same as for PCC initiated LSPs as described in
[I-D.ietf-pce-stateful-pce
<https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-02#ref-I-D.ietf-pce-stateful-pce>].
This applies to the case of a PCE
failure as well.
Which is precisely what I understand you are implying in your response
below.
The third paragraph seems to be replacing the normal delegation
mechanics with a PCInitiate-driven exchange. It does not specify
whether it is legal for a PCE to send PCUpd(D=1) after a session flap
or not. It feels like it is not legal and PCInitiate is intended to
fully replace it, but that would contradict section 3.2 paragraph 4.
This needs to be clarified.
I think some clarification is needed. The text says..
In case of PCEP session failure, control over PCE-initiated LSPs
reverts to the PCC at the expiration of the redelegation timeout. To
obtain control of a PCE-initiated LSP, a PCE (either the original or
one of its backups) sends a PCInitiate message, including just the
SRP and LSP objects, and carrying the PLSP-ID of the LSP it wants to
take control of.
During state synchronization itself (full or incremental) the D flag could be
set while reporting the status of PCE-Initiated LSP (with C flag set) if
re-delegation is not done to another PCE. I feel the same behavior make sense
for PCC-Initiated LSP as well incase one wants to delegate to the same PCE
again after session down. It should not be mandatory to send PCInitiage message
in all cases.
Regards,
Dhruv
Bye,
Robert
My preference would be to remove pretty much all of this paragraph,
bringing the mechanics to what section 3.2 outlines. Unfortunately
there are already some implementations deployed, so we need to factor
in the compatiblity with the installed base. Can we perhaps allocate
another bit in the Stateful PCE Capability TLV and mark the current
one as reserved/deprecated?
Thanks,
Robert
On 12/01/2014 06:18 PM, 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
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
