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

[Stewart Bryant <[e-mail]>]

Well, yes and no.

Presumably routers know what they are load balancing on and can report 
that to the control & management plane, a path can be chosen that 
explicitly takes a path based on the desired behaviour.

Also presumably if there is a need, the ECMP behaviour could be modified 
to only use the EL.

My big concern is that there are a number of instrumentation (and maybe 
path construction) cases where we really would like to see EL only ECMP.

- Stewart


On 02/05/2018 16:03, John E Drake 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 <[e-mail]> *On Behalf Of *Eric Gray
> *Sent:* Wednesday, May 2, 2018 10:28 AM
> *To:* Stewart Bryant <[e-mail]>; Andrew G. Malis 
> <[e-mail]>; Loa Andersson <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]
> *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:[e-mail]] *On Behalf Of *Stewart Bryant
> *Sent:* Wednesday, May 02, 2018 9:52 AM
> *To:* Andrew G. Malis <[e-mail] <mailto:[e-mail]>>; 
> Loa Andersson <[e-mail] <mailto:[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; 
> [e-mail] 
> <mailto:[e-mail]>
> *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 <[e-mail]
>     <mailto:[e-mail]>> 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 (
>         [e-mail] <mailto:[e-mail]> ).
>
>         /Loa
>         for the mpls wf co-chairs
>
>         PS
>
>         I'm copying the spring working group on this mail.
>         -- 
>
>
>         Loa Andersson         email: [e-mail] <mailto:[e-mail]>
>         Senior MPLS Expert
>         Bronze Dragon Consulting        phone: [phone]
>
>         _______________________________________________
>         mpls mailing list
>         [e-mail] <mailto:[e-mail]>
>         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
>
>     [e-mail] <mailto:[e-mail]>
>
>     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=>
>