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

From: Ina Minei <[email-masked]>
Date: Thu, 28 Jul 2016 11:10:03 -0700

Yes, ERO is always mandatory, section 6.1 clearly states that.

On Mon, Jun 27, 2016 at 4:46 AM, Robert Varga <[email-masked]> wrote:

> On 06/23/2016 03:54 PM, [email-masked] wrote:
> > 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.
>
> 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
>
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
>

---

From: Ina Minei <[email-masked]>
Date: Thu, 28 Jul 2016 11:15:17 -0700

Stephane,

Thank you for the detailed feedback. How about the following 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). In this case, the LSP Object SHOULD NOT include the
SYMBOLIC-PATH-NAME TLV and SHOULD include the LSP- IDENTIFIERS TLV with the
special value of all zeroes. The PCRpt message MUST include an empty ERO as
its intended path and SHOULD NOT include the optional RRO object for its
actual path. If the PCC has no state to synchronize, it SHOULD only send
the end of synchronization marker.

On Mon, Jun 27, 2016 at 5:20 AM, <[email-masked]> wrote:

> 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
>
> On 06/21/2016 05:18 PM, [email-masked] wrote:
> > 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) ?
>
> 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.
>
> > 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."
>
> Yes. This would trigger, for example, for PLSP-ID=0 and non-empty ERO.
>
> Bye,
> Robert
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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: Ina Minei <[email-masked]>
Date: Thu, 28 Jul 2016 11:23:06 -0700

Although section 6.1 shows ERO as mandatory, it doesn't actually state
that, how about the following text?

"The intended path, represented by the ERO object, is REQUIRED. If the ERO
ojbect is missing, the receiving PCE MUST send a PCErr message with
Error-type=6 (Mandatory Object missing) and Error-value to be assigned by
IANA (ERO object missing). When present, the ERO object SHOULD contain at
least one subobject, representing the destination of the LSP."

---

From: Olivier Dugeon <[email-masked]>
Date: Fri, 29 Jul 2016 09:36:55 +0200

Hello Ina,

The beginning of our proposal seems OK for me, but the "/MUST include an empty ERO/" part seems in contradiction with our proposal that specifically mention that an ERO could not be empty. As it concerns the end of the synchronisation, I think that it is not necessary to include such ERO. The LSP-Identifiers TLV with special values of all zeroes is sufficient. I would propose to replace the following text:

"/The PCRpt message MUST include an empty ERO as its intended path and SHOULD NOT include the optional RRO object for its actual path./"

by

"/The PCRpt message MUST NOT include any ERO and RRO objects for its actual path./"

Indeed, the end marker of synchronisation is composed by a specific LSP with a PLSP-ID equal to 0 and a LSP-IDENTIFIERS TLV with all zeroes. IMHO, this corresponds to a "/zero LSP/" or "/null LSP/", where there is no need to attach and ERO or RRO. So, it is not necessary to convey them in the PCRpt message. From an algorithm point of view, as the code must include a special test to detect this end marker, it is not a problem to check that the ERO and RRO are not present, and when they must be present, this is check by the another branch in the code.

Regards

Olivier

Le 28/07/2016 20:15, Ina Minei a écrit :
> 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). In this case, the LSP Object SHOULD NOT include the SYMBOLIC-PATH-NAME TLV and SHOULD include the LSP- IDENTIFIERS TLV with the special value of all zeroes. The PCRpt message MUST include an empty ERO as its intended path and SHOULD NOT include the optional RRO object for its actual path. If the PCC has no state to synchronize, it SHOULD only send the end of synchronization marker.
>
> On Mon, Jun 27, 2016 at 5:20 AM, <[email-masked] <mailto:[email-masked]>> wrote:
>
>     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
>     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 ?
>
>     From: Robert Varga [mailto:[email-masked] <mailto:[email-masked]>]
>     To: LITKOWSKI Stephane OBS/OINIS; [email-masked] <mailto:[email-masked]>
>     Subject: Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Synchronization marker
>
>     On 06/21/2016 05:18 PM, [email-masked] <mailto:[email-masked]> wrote:
>     > Hi,
>     >
>     > Doing some interop testing between two vendors we falled into misinterpretation of the current text of the End Of Sync marker content.
>     >
>     > - 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) ?
>
>     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.
>
>     > 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) :
>     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;
>     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.
>
>     [email-masked] <mailto:[email-masked]>