Re: [Pce] Review of draft-ietf-pce-stateful-pce-18

[<[e-mail]>]

Hi Julien, Jon,

Thank you for your feedback.
Please see below my answer/feedback (indicated with [LM2])

Regards,

Lionel
 
> Hi Julien
> 
> You are right, but it is *really easy* for the reader to confuse "stateful
> capability" with "update capability" and "active stateful capability".  Case in
> point: I just confused them in my reply to Lionel.
> 
> We should fix each of the three points below to make this clearer.

[LM2] I agree :)

> Jon, Lionel,
> 
> I believe Lionel got confused by the wording introduced in RFC 8051:
> - no report, no update means stateless PCE;
> - report, no update means passive stateful PCE;
> - report and update means active (stateful) PCE.

[LM2] understood!
> 
> > =====
> >
> > [LM] active/passive mode are not  advertized in PCEP. s/if active
> > stateful PCE capability was not advertised/if stateful PCE capability
> > was not advertised
> >
> > Jon> ACK
> >
> > =====
> [JM] NACK! ;-)
> Actually, the passive mode is advertised using the Stateful-capability-object TLV
> with the U bit unset, the active mode by setting the U bit.
> 
[LM2] "il faut être sorti de Saint-Cyr pour comprendre" as we say in french :)
Could be good to add something like "(as indicated by the U-bit clear in Stateful-capability-object)"

> > =====
> >
> > Note that even if the update capability has not been advertised, a PCE
> > can still accept LSP Status Reports from a PCC and build and maintain
> > an up to date view of the state of the PCC's LSPs.
> >
> > [LM] I don't undersand. Is it not in contradiction with
> >
> > "If the PCEP Speaker on the PCE supports the extensions of this draft
> > but did not advertise this capability, then upon receipt of a PCRpt
> > message from the PCC, it MUST generate a PCErr with error- type
> > 19 (Invalid Operation), error-value 5 (Attempted LSP State Report if
> > active stateful PCE capability was not advertised) (see Section
> > 8.5) and it SHOULD terminate the PCEP session."
> >
> > Or does it mean that there is another way than PCRpt message for the
> > PCC to send LSP status reports to the PCE?
> >
> > Jon> ACK.  I think that the statement in the draft is bogus and I
> > propose to delete this sentence from it.
> >
> > =====
> [JM] I do not think that the text is bogus:
> - case 1: no advertised capability on update but advertised on report (i.e. passive
> stateful) => no error message;
> - case 2: no advertised capability on update nor report (i.e. stateless) => error.

[LM2] After multiple readings and thanks to your explanation, I think I have understood. Am I correct saying that the PCE will accept LSP Status Reports from a PCC ONLY if the stateful PCE capability has been advertised (i.e. Stateful Capability TLV with the 'LSP Update' Flag cleared)? If it is the case, is it really required to keep this text, as in the previous paragraph we find the conditions to accept/reject reports from the PCC?
> 
> > =====
> >
> > [LM] Would it be useful to discover (using another TLV) whether the
> > PCE is an active/passive stateful PCE, as in IGP-based capabilities
> > discovery mechanism?
> >
> > Jon> This can be inferred immediately from the U flag in the
> > STATEFUL-PCE-CAPABILITY TLV.  Passive mode is synonymous with not
> > sending / handling PCUpd messages.
> >
> > =====
> [JM] The mechanism is there, but section 7.1.1 may deserve an explicit use of
> the "passive/active" terms, to make sure the capability terminology is aligned
> with the vocabulary in the IGP section.

[LM2] I can only be agree with you :)


_________________________________________________________________________________________________________________________

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.