Hi Les, I agree with the responses.
On 7/11/17, 3:46 PM, "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> wrote: >Acee - > >Thanx for your support abd your comments. >Responses inline. > >> -----Original Message----- >> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Acee Lindem >> (acee) >> Sent: Tuesday, July 11, 2017 12:02 PM >> To: bruno.decra...@orange.com; Martin Vigoureux >> Cc: spring@ietf.org >> Subject: Re: [spring] WG Last Call for >>draft-ietf-spring-conflict-resolution >> >> I fully support this document and, now that we have reached consensus, >> believe we should publish it before anyone changes their minds… >> >> I have reviewed the -05 version and have the following comments: >> >> 1. Section 3.1 - Make it clear that a larger preference is more >>preferred. >> While this is stated in section 3.3, it must be inferred in section 3.1 >>to >> understand the text. > >[Les:] Agreed. > >> 2. Expand acronyms on first use, e.g., SID and SRMS. > >[Les:] ACK > >> 3. In section 3.8, do we want to suggest that the conflicting >>configuration >> not be “accepted” rather than not “advertised”? >> >[Les:] I don't think so. > >While it is possible that such a check could be run as each configuration >line is entered, stating that this is the way it should be done >constrains an implementation unnecessarily. That is certainly a >reasonable way of implementing it, but not the only way. For example, a >node could allow SRMS configuration to be entered locally without >validating it until the user indicates "configuration complete". Then >the conflict resolution algorithm could be run "as if the configured >values were advertised" to detect conflicts before advertisement is >enabled. > >I don’t think we care which way an implementation chooses to go - the >useful bit is that the check is performed BEFORE the config is advertised >and starts to be used. That is reasonable. Thanks, Acee > > >> I also have a number of editorial suggestions which I will sent to the >>authors >> offline. > >[Les:] Thanx for those as well. > > Les > >> >> Thanks, >> Acee >> >> On 7/11/17, 6:41 AM, "spring on behalf of bruno.decra...@orange.com" >> <spring-boun...@ietf.org on behalf of bruno.decra...@orange.com> >> wrote: >> >> >Martin, >> > >> >As an individual contributor, I have read all versions of this document >> >and support progressing -05 to the IESG. >> > >> >Unless we believe error never happen, a standardized conflict >> >resolution procedure is needed to safely deploy MPLS Segment Routing in >> >a multi-vendor network. Some implementations are waiting for this >> >document to be advanced to RFC in order to implement the stable >> behavior. >> > >> >IMO, -05 is ready: >> >- "SR Global Block Inconsistency" is ready for months (>1 year) >> >- "SR-MPLS Segment Identifier Conflicts" required more time to progress >> >and explored multiple options, but after much work from the authors, >> >-05 seems ready to me. For forwarding nodes, it defines a per FEC >> >preference rule limiting the conflict resolution to only the FEC >> >(prefix/SID) which indeed face conflicting advertisements. For non- >> forwarding nodes (e.g. >> >network controllers, PCE...), it allows more freedom in the SID to be >> >used (or discarded), including a simplified procedure disregarding all >> >conflicting entries. >> > >> >Thanks, >> >Regards, >> >--Bruno >> > > -----Original Message----- >> > > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Martin >> >Vigoureux >> > > Sent: Monday, July 10, 2017 2:58 PM >> > > To: spring@ietf.org >> > > Subject: Re: [spring] WG Last Call for >> >draft-ietf-spring-conflict-resolution >> > > >> > > WG, >> > > >> > > We are half-way through the WG Last Call and I am very surprised to >> >only >> > > see a single answer to it. >> > > >> > > I am not sure I'll move this forward with only silence as support. >> > > >> > > -m >> > > >> > > Le 29/06/2017 à 15:28, Martin Vigoureux a écrit : >> > > > Hello Working Group, >> > > > >> > > > This email starts a Working Group Last Call on >> > > > draft-ietf-spring-conflict-resolution-04 [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 >> > > > *21st of July*. >> > > > Note that this is *not only* a call for comments on the document; >> > > > it >> >is >> > > > also a call for support (or not) to publish this document as a >> >Proposed >> > > > Standard RFC. >> > > > >> > > > ¤ *Coincidentally*, we are also polling for knowledge of any IPR >> > > > that applies to draft-ietf-spring-conflict-resolution, to ensure >> > > > that IPR >> >has >> > > > been disclosed in compliance with IETF IPR rules (see RFCs 3979, >> >4879, >> > > > 3669 and 5378 for more details). >> > > > >> > > > If you are listed as an Author or Contributor of >> > > > draft-ietf-spring-conflict-resolution-04 please respond to this >> > > > email and indicate whether or not you are aware of any relevant >>IPR. >> > > > >> > > > Note that, as of today, no IPR has been disclosed against this >> >document >> > > > or its earlier versions. >> > > > >> > > > Thank you, >> > > > Martin >> > > > >> > > > [1] >> >https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolution/ >> > > > >> > > > _______________________________________________ >> > > > spring mailing list >> > > > spring@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/spring >> > > > >> > > >> > > _______________________________________________ >> > > spring mailing list >> > > spring@ietf.org >> > > https://www.ietf.org/mailman/listinfo/spring >> > >> >_________________________________________________________ >> ______________ >> >___ _______________________________________________ >> > >> >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 >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
