Hi all, I don't understand why you need to mention en empty ERO to mark en the end of synchronisation. Comparing with what other protocols do to mark the end of sync, I have a felling that we duplicate the marker. At least, a simple flag i.e. 1 bit is largely sufficient to say that this is the last LSP. So, a PCRpt message with PLSP-ID equal to the reserved value 0 is largely sufficient. No need to add extra information, and if there are present, just ignore them.
If multiple marker are needed, I would suggest to used the NO_PATH object define in RFC5440 instead of an empty ERO that has a variable interpretation. The NO_PATH object has been define exactly for this meaning: there is no path. Regards Olivier Le 08/08/2016 11:06, stephane.litkow...@orange.com a écrit : > > Hi Ina, > > > > Thanks for the feedback and proposal > > I would like to propose those modifications : > > “The end of synchronization marker is a PCRpt message 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, SHOULD include the LSP- IDENTIFIERS > TLV with the special value of all zeroes. All the flags of the LSP Object > MUST be set to 0. The PCRpt message MUST include an empty ERO as its intended > path and SHOULD NOT include the optional RRO object for its actual path or > any other object. If the PCC has no state to synchronize, it SHOULD only send > the end of synchronization marker.” > > > > > > > > It would be good to add a sentence in case of bad encoding of the EOS marker. > This may be covered but it looks confusing to mix generic PCRpt with EOS : > > “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. > > “ > > > > Some error examples : > > 1) PCRpt S=0 D=0 PLSP-ID 0 LSP-Object (LSP-ID 0.0.0.0) ERO empty RRO > present > > Need an error like : LSP State Synchronization Error, non authorized object > in EOS > > > > 2) PCRpt S=0 D=0 PLSP-ID 0 LSP-Object (LSP-ID 0.0.0.0) ERO empty BW=0 > > Need an error like : LSP State Synchronization Error, non authorized object > in EOS > > > > 3) PCRpt S=1 D=0 PLSP-ID 0 LSP-Object (LSP-ID 0.0.0.0) ERO empty > > Need an error like : LSP State Synchronization Error, bad flags in EOS > > > > 4) PCRpt S=0 D=1 PLSP-ID 0 LSP-Object (LSP-ID 0.0.0.0) ERO empty > > Need an error like : LSP State Synchronization Error, bad flags in EOS > > > > 5) PCRpt S=0 D=0 PLSP-ID 0 LSP-Object (LSP-ID 0.0.0.0) ERO non empty > > Need an error like : LSP State Synchronization Error, bad ERO in EOS > > > > 6) PCRpt S=0 D=0 PLSP-ID 0 LSP-Object (LSP-ID 0.0.1.1) ERO empty > > Need an error like : LSP State Synchronization Error, bad LSP ID in EOS > > > > 7) PCRpt S=0 D=0 PLSP-ID 0 LSP-Object (LSP-ID 0.0.0.0) > > Handled by Missing ERO in PCRpt which will apply to EOS as well > > > > A generic error would also work but less precise : LSP State Synchronization > Error, bad EOS encoding. > > > > > > Best Regards, > > > > Stephane > > > > > > *From:*Ina Minei [mailto:inami...@google.com] > *Sent:* Thursday, July 28, 2016 20:15 > *To:* LITKOWSKI Stephane OBS/OINIS > *Cc:* Robert Varga; pce@ietf.org > *Subject:* Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of > Synchronization marker > > > > 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, <stephane.litkow...@orange.com > <mailto:stephane.litkow...@orange.com>> 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:n...@hq.sk <mailto:n...@hq.sk>] > Sent: Monday, June 27, 2016 14:02 > To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org <mailto:pce@ietf.org> > Subject: Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of > Synchronization marker > > On 06/21/2016 05:18 PM, stephane.litkow...@orange.com > <mailto:stephane.litkow...@orange.com> 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. > > _______________________________________________ > Pce mailing list > Pce@ietf.org <mailto:Pce@ietf.org> > https://www.ietf.org/mailman/listinfo/pce > > > > _________________________________________________________________________________________________________________________ > > 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
