Hi Bruno, > Speaking as an individual contributor and co-author: > - I think that this is fine to make a difference between an inconsistency from > a (one) faulty sender, and an inconsistency from two correct senders but with > inconsistent configurations. Those are different cases which may be handled > differently. > - A protocol specification must describe what to do when something > unexpected happens.
Good, that's all I'm asking for. > With this in mind, Id propose the following change: > > OLD: > 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 behavior is considered a faulty > implementation and is not covered in this document. > NEW: > 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 behavior is considered as faulty. Procedures > defined in this document equally applies to this case, both for incoming label > collision (§2.5) and effect on outgoing label programming (§2.6) > > > Possibly the second sentence could be omitted. (I would lightly favor > this, but tried to minimize the changes) Thanks, yes, that captures the cases and addresses them by referring to sections that describe the correct behaviour. I also think that that sentence doesn't add anything (since any variation from a MUST or MUST NOT) defines a faulty implementation. But if retaining that text keeps people happy, then that is fine. > On a side note, the document does cover this case: > > 2. Within an MCC, apply tie-breaking rules to select one FEC only and > assign the label to it. The losing FECs are handled as if no > labels are attached to them. The losing FECs with a non-zero > algorithm are not installed in FIB. Yes. Hopefully we can make the change you propose and move on. Best, Adrian -- Fairy tales from North Wales brought to you for Christmas https://www.feedaread.com/profiles/8604/ Available from your favourite online bookseller. Or contact me to receive a signed copy by mail. From: Adrian Farrel [mailto:[email protected]] Sent: Thursday, December 06, 2018 12:35 PM To: 'Ahmed Bashandy'; DECRAENE Bruno TGI/OLN; 'SPRING WG List' Cc: mailto:[email protected]; 'Martin Vigoureux' Subject: RE: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-17 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 cant 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 doesnt 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 <mailto:[email protected]> Sent: 06 December 2018 10:45 To: mailto:[email protected]; mailto:[email protected]; 'SPRING WG List' <mailto:[email protected]> Cc: mailto:[email protected]; 'Martin Vigoureux' <mailto:[email protected]> 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:[email protected] On Behalf Of mailto:[email protected] Sent: 03 December 2018 18:21 To: SPRING WG List mailto:[email protected] Cc: mailto:[email protected]; Martin Vigoureux (mailto:[email protected]) mailto:[email protected] 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, well 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 well send this document to the IESG. Thanks, Regards, --Bruno, Rob [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-17 From: mailto:[email protected] [mailto:[email protected]] Sent: Thursday, June 07, 2018 6:52 PM To: SPRING WG List Cc: mailto:[email protected] 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). Ive 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: mailto:[email protected] [mailto:[email protected]] Sent: Thursday, May 24, 2018 7:14 PM To: SPRING WG List Cc: mailto:[email protected] 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 _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
