Hi,
Thanks for your response. A protocol specification must describe what to do when something unexpected happens. Consider, for example, that we will say how to process a message that is badly encoded or can't be parsed (usually by saying "drop the message, and possibly log the event"). Are you saying that if an implementation breaks the rule in this text then that fact is not visible outside of that implementation? That is, the implementation would break or confuse itself, but would not actually harm any other implementations in the network? Furthermore, are you saying that the only way this error could be detected outside the broken implementation is through misrouting or blackholing of traffic? If you are saying those two things, then I agree with you that nothing more needs to be said (although the use of 2119 language doesn't seem to be appropriate because you are describing the internal details of an implementation. If, however, the error is externally detectable (for example, because the label is advertised associated with more than one SR FEC) then you do need to describe how the receiver of such advertisements will behave. You have to do that even if the behaviour is "accept the advertisements at face value". Cheers, Adrian From: Ahmed Bashandy <abashandy.i...@gmail.com> Sent: 06 December 2018 10:45 To: adr...@olddog.co.uk; bruno.decra...@orange.com; 'SPRING WG List' <spring@ietf.org> Cc: draft-ietf-spring-segment-routing-m...@ietf.org; 'Martin Vigoureux' <martin.vigour...@nokia.com> Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-17 Thanks a lot for the review The paragraph that you quoted says bugs (A.K.A "faulty implementation") are out of the scope of the this document. So there is no part of this document that says how to protect against bugs otherwise the document is contradicting itself Thanks again for the thorough review Ahmed On 12/3/18 2:28 PM, Adrian Farrel wrote: Hi all, Thanks to the authors for the multiple revisions since -17. I reviewed the Diff. All of my review comments along the way seem to have been addressed and I support moving to publication (soon). One thing, in Section 2.5. An implementation MUST NOT allow the MCCs belonging to the same router to assign the same incoming label to more than one SR FEC. An implementation that allows such behaviour is considered a faulty implementation and is not covered in this document. That is a fine statement, but what this document *does* need to cover is how an implementation protects itself against such a faulty implementation. Possibly this is covered in Section 2.6, in which case a forward pointer would be good. Best, Adrian From: spring <mailto:spring-boun...@ietf.org> <spring-boun...@ietf.org> On Behalf Of bruno.decra...@orange.com <mailto:bruno.decra...@orange.com> Sent: 03 December 2018 18:21 To: SPRING WG List <mailto:spring@ietf.org> <spring@ietf.org> Cc: draft-ietf-spring-segment-routing-m...@ietf.org <mailto:draft-ietf-spring-segment-routing-m...@ietf.org> ; Martin Vigoureux (martin.vigour...@nokia.com <mailto:martin.vigour...@nokia.com> ) <mailto:martin.vigour...@nokia.com> <martin.vigour...@nokia.com> Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-17 Hi all, Many thanks for all reviews during this last call. Given some changes and the duration needed to address all comments, we'll do another (3rd) short one-week working group last call limited to the changes done since -13 or possibly to comments not yet addressed from the second last call. Obviously, you should not refrain from reviewing the whole document and raise any errors in the whole document. This email starts a (third) Working Group Last Call on draft-ietf-spring-segment-routing-mpls-17 [1] in order to give the working group an additional opportunity to review the changes/document. There is no need to restate your previous support: there has already been many review and support, and we'll send this document to the IESG. Thanks, Regards, --Bruno, Rob [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-17 From: bruno.decra...@orange.com <mailto:bruno.decra...@orange.com> [mailto:bruno.decra...@orange.com] Sent: Thursday, June 07, 2018 6:52 PM To: SPRING WG List Cc: draft-ietf-spring-segment-routing-m...@ietf.org <mailto:draft-ietf-spring-segment-routing-m...@ietf.org> Subject: RE: WG Last Call for draft-ietf-spring-segment-routing-mpls-13 Hi all, A quick update on the status of this WGLC: - All the authors have responded about IPR (thank you!). Still missing replies from some contributors (Wim, Edward, Igor, Saku). I've sent them a reminder this Monday. - Two people (Zafar, Adrian) have responded supporting publication. - No opposition. - Two persons have sent comments (Adrian, myself). Thanks Adrian. - Authors have not replied to any comment so far. - The WGLC period was scheduled to end tomorrow. I wish we had more support, reviews, and authors' involvement to reply to reviews. The WGLC is extended by a week. Please review the document and send your comments to the list, no later than *June 15* Thank you, --Bruno From: bruno.decra...@orange.com <mailto:bruno.decra...@orange.com> [mailto:bruno.decra...@orange.com] Sent: Thursday, May 24, 2018 7:14 PM To: SPRING WG List Cc: draft-ietf-spring-segment-routing-m...@ietf.org <mailto:draft-ietf-spring-segment-routing-m...@ietf.org> Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-13 Hello Working Group, This email starts a Working Group Last Call on draft-ietf-spring-segment-routing-mpls-13 [1] which is considered mature and ready for a final working group review. Please read this document if you haven't read the most recent version yet, and send your comments to the list, no later than *June 08*. As a reminder, this document had already passed a WGLC more than a year ago on version -06 [2], had been sent to the AD but then returned to the WG. Since then, the document has significantly changed, so please read it again. In particular, it now includes the resolution in case of incoming label collision. Hence it killed draft-ietf-spring-conflict-resolution. Both co-chairs co-author this document, hence: - Shraddha has agreed to be the document shepherd.. Thank you Shraddha. - Martin, our AD, has agreed to evaluate the WG consensus. Thank you, Bruno, Rob [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13 [2] https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y ____________________________________________________________________________ _____________________________________________ 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. ____________________________________________________________________________ _____________________________________________ 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. ____________________________________________________________________________ _____________________________________________ 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.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
