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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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.


> 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