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 <[email protected]> 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 <[email protected]> *On Behalf Of *Eric Gray > *Sent:* Wednesday, May 2, 2018 10:28 AM > *To:* Stewart Bryant <[email protected]>; Andrew G. Malis < > [email protected]>; Loa Andersson <[email protected]> > > > *Cc:* [email protected]; [email protected]; [email protected]; > [email protected] > > *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:[email protected] <[email protected]>] *On > Behalf Of *Stewart Bryant > *Sent:* Wednesday, May 02, 2018 9:52 AM > *To:* Andrew G. Malis <[email protected]>; Loa Andersson <[email protected]> > *Cc:* [email protected]; [email protected]; [email protected]; > [email protected] > *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 <[email protected]> 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 ( [email protected] ). > > /Loa > for the mpls wf co-chairs > > PS > > I'm copying the spring working group on this mail. > -- > > > Loa Andersson email: [email protected] > Senior MPLS Expert > Bronze Dragon Consulting phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > [email protected] > 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 > > [email protected] > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
