Subject: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Synchronization marker

From: <[email-masked]>
Date: Tue, 21 Jun 2016 15:18:14 +0000

Hi,

Doing some interop testing between two vendors we falled into misinterpretation of the current text of the End Of Sync marker content.

Here is the current text :

"The end of synchronization marker is a PCRpt message with the SYNC
   Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved
   value 0 (see Section 7.3).  The LSP Object does not include the
   SYMBOLIC-PATH-NAME TLV in this case, it will include an empty ERO as
   its intended path and will not include the optional RRO object in the
   path.  If the PCC has no state to synchronize, it will only send the
   end of synchronization marker."

The current text, IMO, has the following issues :
- it uses non normative wording : "does not include", "will include" , "will not include". How do we need to interpret it ? MUST, SHOULD, MAY ?
- it does not precise if it can include or not some other objects : can it include an LSP-Identifier object (with all fields to 0) ? 

It would be good to enhance the text to better describe the content of EOS.

We suppose that in case there is an issue with the encoding of the EOS marker, the following behavior will be applied, could you confirm ? (typically bad encoding of EOS marker) :
" The PCE does not send positive acknowledgements for properly received
   synchronization messages.  It MUST respond with a PCErr message with
   error-type 20 (LSP State Synchronization Error) and error-value 1
   (indicating an error in processing the PCRpt) (see Section 8.5) if it
   encounters a problem with the LSP State Report it received from the
   PCC and it MUST terminate the session."

Thanks,

Stephane Litkowski 
Network Architect 
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 28 49 83 
mobile: +33 6 37 86 97 52 
[email-masked] 

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Thu, 23 Jun 2016 13:54:55 +0000

Hi again,

We also found an issue when a PCC removes a LSP. It would be good to precise the objects that are mandatory, optional in this case also. 
Some PCE implementations are waiting for an ERO in the PCRpt that removes an LSP, while some PCC does not send an ERO. 
Would be good to clarify the procedure of LSP removal.

Best Regards,

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, June 21, 2016 17:18
To: [email-masked]
Subject: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Synchronization marker

Hi,

Thanks,

Stephane Litkowski
Network Architect

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-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: Robert Varga <[email-masked]>
Date: Mon, 27 Jun 2016 13:46:10 +0200

> Would be good to clarify the procedure of LSP removal.

Hello,

I think section 6.1 on PCRpt message format covers this: ERO is
mandatory in all cases. I could not find any text which would imply this
should not be the case for R=1.

Bye,
Robert

---

From: Robert Varga <[email-masked]>
Date: Mon, 27 Jun 2016 14:01:46 +0200

> - it does not precise if it can include or not some other objects : can it include an LSP-Identifier object (with all fields to 0) ?

The intent here is to use a minimal PCRpt message, hence we explicitly
exclude SYMBOLIC-PATH-NAME TLV and RRO. ERO is kept empty for the same case.

I think we have not precluded other TLVs from appearing in EOS to allow
future extensions.

I do not think LSP-IDENTIFIERS TLV should be carried here, as it serves
no purpose and is not required -- section 7.3.1's MUST condition does
not trigger, as PLSP-ID=0 is a reserved value and does not identify an LSP.

>    PCC and it MUST terminate the session."

Yes. This would trigger, for example, for PLSP-ID=0 and non-empty ERO.

Bye,
Robert

---

From: <[email-masked]>
Date: Mon, 27 Jun 2016 12:14:43 +0000

Hi,

Do you take this assumption from  :
"   Where:
      <path>::= <intended_path><attribute-list>[<actual_path>]

   Where:
      <intended_path> is represented by the ERO object defined in
      section 7.9 of [RFC5440]." ?

What should be the content of the ERO ? empty ? current ERO ?

Section 6.2. is more clear on the presence of ERO in PCUpd :
" There are three mandatory objects that MUST be included within each
   LSP Update Request in the PCUpd message ... If the ERO object
   is missing, the receiving PCC MUST send a PCErr message with Error-
   type=6 (Mandatory Object missing) and Error-value=9 (ERO object
   missing)."

If you consider that ERO is mandatory for PCRpt, would be good to have similar text, stating the "mandatory" stuff, the content expected (or telling that we do not care) and the behavior is case it is missing.

Thoughts ?

Best regards,

Stephane

-----Original Message-----
From: Robert Varga [mailto:[email-masked]] 
Sent: Monday, June 27, 2016 13:46
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Synchronization marker

Hello,

I think section 6.1 on PCRpt message format covers this: ERO is mandatory in all cases. I could not find any text which would imply this should not be the case for R=1.

Bye,
Robert

---

From: <[email-masked]>
Date: Mon, 27 Jun 2016 12:20:52 +0000

Hi,

Thanks for the feedback.

> The intent here is to use a minimal PCRpt message, hence we explicitly exclude SYMBOLIC-PATH-NAME TLV and RRO. ERO is kept empty for the same case.
> I think we have not precluded other TLVs from appearing in EOS to allow future extensions.
> I do not think LSP-IDENTIFIERS TLV should be carried here, as it serves no purpose and is not required -- section 7.3.1's MUST condition does not trigger, as 
> PLSP-ID=0 is a reserved value and does not identify an LSP.

Even if you think that LSP-ID should not be carried, it's not explicitly mentioned in the draft, so it's authorized.
Why not restricting EOS to the minimal case, and let potential future extensions to modify it ? To you forsee anycase that could require modification of EOS content ?

At least the text should use normative words.

Best Regards,

Stephane

-----Original Message-----
From: Robert Varga [mailto:[email-masked]] 
Sent: Monday, June 27, 2016 14:02
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Synchronization marker

> - it does not precise if it can include or not some other objects : can it include an LSP-Identifier object (with all fields to 0) ?

The intent here is to use a minimal PCRpt message, hence we explicitly exclude SYMBOLIC-PATH-NAME TLV and RRO. ERO is kept empty for the same case.

I think we have not precluded other TLVs from appearing in EOS to allow future extensions.

I do not think LSP-IDENTIFIERS TLV should be carried here, as it serves no purpose and is not required -- section 7.3.1's MUST condition does not trigger, as PLSP-ID=0 is a reserved value and does not identify an LSP.

Bye,
Robert