Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

["Acee Lindem (acee)" <[e-mail]>]

Hi Les, 

I agree with the responses.

On 7/11/17, 3:46 PM, "Les Ginsberg (ginsberg)" <[e-mail]> wrote:

>Acee -
>
>Thanx for your support abd your comments.
>Responses inline.
>
>> -----Original Message-----
>> From: spring [mailto:[e-mail]] On Behalf Of Acee Lindem
>> (acee)
>> Sent: Tuesday, July 11, 2017 12:02 PM
>> To: [e-mail]; Martin Vigoureux
>> Cc: [e-mail]
>> 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 [e-mail]"
>> <[e-mail] on behalf of [e-mail]>
>> 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:[e-mail]] On Behalf Of Martin
>> >Vigoureux
>> > > Sent: Monday, July 10, 2017 2:58 PM
>> > > To: [e-mail]
>> > > 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
>> > > > [e-mail]
>> > > > https://www.ietf.org/mailman/listinfo/spring
>> > > >
>> > >
>> > > _______________________________________________
>> > > spring mailing list
>> > > [e-mail]
>> > > 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
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/spring
>> 
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring