Re: [mpls] [spring] should draft-ietf-mpls-spring-entropy-label be published as a RFC on the standards track?

I agree with adding such a statement here if this document should be
standards track. It's not clear to me that such an implication is intended
by the draft.

r.

On Wed, May 2, 2018 at 8:04 AM John E Drake <jdrake@juniper.net> wrote:

> Stewart,
>
>
>
> Realistically, I think your proposal is an example of closing the barn
> door after the horse has bolted.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Eric Gray
> *Sent:* Wednesday, May 2, 2018 10:28 AM
> *To:* Stewart Bryant <stewart.bryant@gmail.com>; Andrew G. Malis <
> agmalis@gmail.com>; Loa Andersson <loa@pi.nu>
>
>
> *Cc:* mpls@ietf.org; spring@ietf.org; mpls-ads@ietf.org;
> draft-ietf-mpls-spring-entropy-label@ietf.org
>
> *Subject:* Re: [spring] [mpls] should
> draft-ietf-mpls-spring-entropy-label be published as a RFC on the standards
> track?
>
>
>
> Stewart,
>
>
>
>                 At least one view of the purpose of an Entropy label is
> that it _*adds*_ entropy to the process of path selection.
>
>
>
>                 Explicitly limiting EL behavior to rely exclusively on use
> of the entropy label would also explicitly _*limit*_ the total entropy to
> whatever the implementation that provided the entropy label was implemented
> to treat as _*sufficient*_ among all paths in the ECMP gestalt, possibly
> including branches that implementation might not know about.
>
>
>
>                 I doubt very much that many of the problems you refer to
> would have arisen if folks generally felt that the entropy label – by
> itself – provides sufficient entropy.
>
>
>
>                 It might make sense to impose this restriction –
> optionally – when a deployment occurs in which any particular pathological
> behavior might be expected to occur.
>
>
>
>                 In that case, it might be very important to ensure that
> the limited approaches available for maximizing efficient load distribution
> via explicit and exclusive use of the entropy label are acceptable to a
> reasonably diverse set of implementers, as support for at least one of
> those approaches would then become a mandatory part of every standard
> implementation.
>
>
>
>                 Even so, I don’t believe it is a good idea to restrict
> implementations from using other approaches in every case.
>
>
>
>                 The simplest example possible (where doing so is a big
> problem) is one where the entropy labels provided have N possible values
> and there are M possible paths, where M>N. In any scenario where this
> occurs, M-N paths simply will not be used.
>
>
>
> --
>
> Eric
>
>
>
> *From:* mpls [mailto:mpls-bounces@ietf.org <mpls-bounces@ietf.org>] *On
> Behalf Of *Stewart Bryant
> *Sent:* Wednesday, May 02, 2018 9:52 AM
> *To:* Andrew G. Malis <agmalis@gmail.com>; Loa Andersson <loa@pi.nu>
> *Cc:* mpls@ietf.org; spring@ietf.org; mpls-ads@ietf.org;
> draft-ietf-mpls-spring-entropy-label@ietf.org
> *Subject:* Re: [mpls] [spring] should
> draft-ietf-mpls-spring-entropy-label be published as a RFC on the standards
> track?
>
>
>
> Be careful.
>
> There is text in the draft that talks about ECMP behaviour in different
> parts of the path, which implies an expectation that the EL is the sole
> source of entropy. If we make this ST then we will be implicitly
> standardizing that behaviour. Now as it happens, I thing we need to update
> the EL behaviour to make it the sole source of entropy, because that solves
> a number of problems, particularly in network instrumentation, but we need
> to do that explicitly and not as an artefact of this draft.
>
> So the way I see it, either this draft is published as informational, or
> it is published as ST without any text that implies that the EL is the sole
> source of entropy, or we harden the EL behaviour (which I think we need to
> do) and this draft is published with a normative reference to an RFC that
> specifies the stricter EL behaviour.
>
> - Stewart
>
>
>
> On 02/05/2018 14:01, Andrew G. Malis wrote:
>
> Loa,
>
>
>
> There’s plenty of RFC 2119 language in the draft, so I support making this
> standards track.
>
>
>
> Cheers,
>
> Andy
>
>
>
>
>
> On Wed, May 2, 2018 at 3:44 AM, Loa Andersson <loa@pi.nu> wrote:
>
> Working Group,
>
> February 1st the MPLS working Group requested that draft-ietf-mpls-
> spring-entropy-label should be published as an Informational RFC.
>
> During the RTG Directorate and AD reviews the question whether the
> document should instead be published as a RFC on the Standards Track
> has been raised.
>
> The decision to make the document Informational was taken "a long time
> ago", based on discussions between the authors and involving the
> document shepherd, on the wg mailing list. At that point it we were
> convinced that the document should be progressed as an Informational
> document.
>
> It turns out that there has been such changes to the document that we
> now would like to request input from the working group if we should make
> the document a Standards Track RFC.
>
> Daniele's RTG Directorate review can be found at at:
>
> https://datatracker.ietf.org/doc/review-ietf-mpls-spring-entropy-label-08-rtgdir-lc-ceccarelli-2018-02-21/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_review-2Dietf-2Dmpls-2Dspring-2Dentropy-2Dlabel-2D08-2Drtgdir-2Dlc-2Dceccarelli-2D2018-2D02-2D21_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=7_r3cJDG9p57NRbEtEFwAyBK-8a5dmfxyolD2L0t-NY&s=8uWamWCicXKfKdzVgZT8gX3j8YO9Yo2Eb3mZxOCMNnI&e=>
>
> All the issues, with the exception whether it should be Informational
> or Standards track, has been resolved as part AD review.
>
> If the document is progressed as a Standard Tracks document then we
> also need to answer the question whether this is an update RFC 6790.
>
> This mail starts a one week poll (ending May 9) to see if we have
> support to make the document a Standards Track document. If you support
> placing it on the Standards Track also consider if it is an update to
> RFC 6790.
>
> Please send your comments to the MPLS wg mailing list ( mpls@ietf.org ).
>
> /Loa
> for the mpls wf co-chairs
>
> PS
>
> I'm copying the spring working group on this mail.
> --
>
>
> Loa Andersson                        email: loa@pi.nu
> Senior MPLS Expert
> Bronze Dragon Consulting             phone: +46 739 81 21 64
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=7_r3cJDG9p57NRbEtEFwAyBK-8a5dmfxyolD2L0t-NY&s=7zu_z-7g4wBIOav02jUg5eWNVpu_UbyFhy3Ea7r7wKA&e=>
>
>
>
>
>
> _______________________________________________
>
> spring mailing list
>
> spring@ietf.org
>
> https://www.ietf.org/mailman/listinfo/spring <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=7_r3cJDG9p57NRbEtEFwAyBK-8a5dmfxyolD2L0t-NY&s=Bre3I6DpvXPKYT12vpNTyKEsnhA6jqbAP4Pc59KLc3c&e=>
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>