Thank you for that. Adrian -----Original Message----- From: Ahmed Bashandy <[email protected]> Sent: 09 December 2018 13:31 To: [email protected]; [email protected] Cc: [email protected]; 'Martin Vigoureux' <[email protected]>; 'SPRING WG List' <[email protected]> Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-17
There is no document in the world that can cover what to do in case of bugs, simply because a document is finite while bugs are infinite However to avoid unnecessary discussions, I posted version 18 with the text that Bruno suggested Ahmed On 12/6/18 12:09 PM, Adrian Farrel wrote: > 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, I’d 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 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 <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, 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: 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). 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: 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
