Hi Stéphane, Le 02/09/2016 11:48, LITKOWSKI Stephane OBS/OINIS a écrit : > > Hi Olivier, > > > > If we state that ERO is mandatory, it must always be present, so we need to > have it in the marker also. Not having it in the marker is possible but this > may require to introduce a different sanity check logic for this particular > PCRpt (so adding code complexity and bugs ..). > Agree. So, if the goal is to have a simple code without complexity and bug, only one marker and a simple 'if PLSP-ID == 0' instruction is largely sufficient. Here, the standard impose to test 5 more conditions before deciding is it is really an End Of Sync. Why complicate things when they can be simple ;-). It just propose to simplify the process.
Regards Olivier > > Again we having running codes now, so yes , it had been possible to use a > flag in the last LSP advertisement to tell that this is the last one, but now > EOS has been introduced and implemented and it would be hard to change this > without breaking current implementations or complexify them. > > Honestly having this empty ERO is not an issue and does not introduce any > issue. > > > > Brgds, > > > > Stephane > > > > > > *From:*Olivier Dugeon [mailto:[email protected]] > *Sent:* Friday, September 02, 2016 11:16 > *To:* LITKOWSKI Stephane OBS/OINIS; Ina Minei > *Cc:* [email protected] > *Subject:* Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of > Synchronization marker > > > > 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, [email protected] > <mailto:[email protected]> 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:[email protected]] > *Sent:* Thursday, July 28, 2016 20:15 > *To:* LITKOWSKI Stephane OBS/OINIS > *Cc:* Robert Varga; [email protected] <mailto:[email protected]> > *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, <[email protected] > <mailto:[email protected]>> 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 protected] <mailto:[email protected]>] > Sent: Monday, June 27, 2016 14:02 > To: LITKOWSKI Stephane OBS/OINIS; [email protected] <mailto:[email protected]> > Subject: Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of > Synchronization marker > > On 06/21/2016 05:18 PM, [email protected] > <mailto:[email protected]> 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 > [email protected] <mailto:[email protected]> > 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 > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/pce > > >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
