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 <[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]] *On Behalf Of *Stewart Bryant
*Sent:* Wednesday, May 02, 2018 9:52 AM
*To:* Andrew G. Malis <[email protected] <mailto:[email protected]>>;
Loa Andersson <[email protected] <mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]>; [email protected]
<mailto:[email protected]>; [email protected]
<mailto:[email protected]>;
[email protected]
<mailto:[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]
<mailto:[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] <mailto:[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] <mailto:[email protected]>
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
[email protected] <mailto:[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] <mailto:[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
