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

From: Loa Andersson <[email-masked]>
Date: Wed, 2 May 2018 09:44:38 +0200

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/

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-masked] ).

/Loa
for the mpls wf co-chairs

PS

I'm copying the spring working group on this mail.
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 2 May 2018 09:01:15 -0400

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-masked]> wrote:

> https://datatracker.ietf.org/doc/review-ietf-mpls-spring-ent
> ropy-label-08-rtgdir-lc-ceccarelli-2018-02-21/
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 2 May 2018 13:29:22 +0000

Loa and all,
+1.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: spring [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Wednesday, May 2, 2018 4:01 PM
To: Loa Andersson <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] [mpls] should draft-ietf-mpls-spring-entropy-label be published as a RFC on the standards track?

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-masked]<mailto:[email-masked]>> wrote:
Working Group,

Please send your comments to the MPLS wg mailing list ( [email-masked]<mailto:[email-masked]> ).

/Loa

PS

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 2 May 2018 14:51:30 +0100

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:
>     <https://datatracker.ietf.org/doc/review-ietf-mpls-spring-entropy-label-08-rtgdir-lc-ceccarelli-2018-02-21/>
>
>     Please send your comments to the MPLS wg mailing list (
>     [email-masked] <mailto:[email-masked]> ).
>
>     /Loa
>     <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mpls>
>
>
>
>
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Eric Gray <[email-masked]>
Date: Wed, 2 May 2018 14:27:43 +0000

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-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, May 02, 2018 9:52 AM
To: Andrew G. Malis <[email-masked]>; Loa Andersson <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
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

Cheers,
Andy

/Loa

PS

spring mailing list

[email-masked]<mailto:[email-masked]>

---

From: Eric Gray <[email-masked]>
Date: Wed, 2 May 2018 14:52:46 +0000

Stewart, et al,

                Loa just pointed out that I made a typo in the original mail below.  In the second paragraph, I meant to say:

                “Explicitly limiting ECMP behavior to …”

--
Eric

From: mpls [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Wednesday, May 02, 2018 10:28 AM
To: Stewart Bryant <[email-masked]>; Andrew G. Malis <[email-masked]>; Loa Andersson <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [spring] should draft-ietf-mpls-spring-entropy-label be published as a RFC on the standards track?

Stewart,

--
Eric

From: mpls [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, May 02, 2018 9:52 AM
To: Andrew G. Malis <[email-masked]<mailto:[email-masked]>>; Loa Andersson <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] [spring] should draft-ietf-mpls-spring-entropy-label be published as a RFC on the standards track?

Be careful.

- Stewart

Cheers,
Andy

/Loa

PS

spring mailing list

---

From: Loa Andersson <[email-masked]>
Date: Wed, 2 May 2018 16:58:46 +0200

Eric, Stewart, wg,

Wouldn't just a few words in the draft saying something along the lines

"This document should not be interpreted in such a way that the ECMP
  behavior is limited to rely on EL only."

Go a long way to clarify Stewart's concerns?

/Loa

On 2018-05-02 16:52, Eric Gray wrote:
> Stewart, et al,
> 
>                  Loa just pointed out that I made a typo in the original 
> mail below.  In the second paragraph, I meant to say:
> 
> *From:*mpls [mailto:[email-masked]] *On Behalf Of *Eric Gray
> *Sent:* Wednesday, May 02, 2018 10:28 AM
> *To:* Stewart Bryant <[email-masked]>; Andrew G. Malis 
> <[email-masked]>; Loa Andersson <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> *Subject:* Re: [mpls] [spring] 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-masked]] *On Behalf Of *Stewart Bryant
> *Sent:* Wednesday, May 02, 2018 9:52 AM
> *To:* Andrew G. Malis <[email-masked] <mailto:[email-masked]>>; 
> Loa Andersson <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>
> *Subject:* Re: [mpls] [spring] should 
> draft-ietf-mpls-spring-entropy-label be published as a RFC on the 
> standards track?
> 
> Be careful.
> 
>     [email-masked] <mailto:[email-masked]>
> 

--

---

From: John E Drake <[email-masked]>
Date: Wed, 2 May 2018 15:03:47 +0000

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-masked]> On Behalf Of Eric Gray
Sent: Wednesday, May 2, 2018 10:28 AM
To: Stewart Bryant <[email-masked]>; Andrew G. Malis <[email-masked]>; Loa Andersson <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] [mpls] should draft-ietf-mpls-spring-entropy-label be published as a RFC on the standards track?

Stewart,

--
Eric

Be careful.

- Stewart

Cheers,
Andy

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=>

/Loa

PS

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
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

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=>

---

From: Rob Shakir <[email-masked]>
Date: Wed, 02 May 2018 15:15:31 +0000

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-masked]> wrote:

> *From:* spring <[email-masked]> *On Behalf Of *Eric Gray
> *Sent:* Wednesday, May 2, 2018 10:28 AM
> *To:* Stewart Bryant <[email-masked]>; Andrew G. Malis <
> [email-masked]>; Loa Andersson <[email-masked]>
>
>
> *Subject:* Re: [spring] [mpls] should
> draft-ietf-mpls-spring-entropy-label be published as a RFC on the standards
> track?
>
>
>
> Stewart,
>
>
>
> 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
> optionally – when a deployment occurs in which any particular pathological
> behavior might be expected to occur.
>
>
>
> 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.
>
>
>
> 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-masked] <[email-masked]>] *On
> Behalf Of *Stewart Bryant
> *To:* Andrew G. Malis <[email-masked]>; Loa Andersson <[email-masked]>
> draft-ietf-mpls-spring-entropy-label be published as a RFC on the standards
> track?
>
>
>
> Be careful.
>
> 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.
>
> 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
>
>
>
> <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=>
>
> <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=>
>
>
>
>
>
> 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=>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 2 May 2018 16:50:46 +0100

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:
> *From:*spring <[email-masked]> *On Behalf Of *Eric Gray
> 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 
> 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
>
> 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 
> 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
>
>         Loa Andersson         email: [email-masked] <mailto:[email-masked]>
>         Senior MPLS Expert
>     <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=>
>

---

From: Eric Gray <[email-masked]>
Date: Wed, 2 May 2018 18:23:45 +0000

Andy,

                Don’t you feel that this is just a bit of a flip observation?

                Personally I agree that RFC 2119 “language” and even a reference to RFC 2119 itself seems inappropriate in an “FYI” RFC.

                But I have been over-ridden on that before.

                I have to say, however that making something a standards track document _because_ it has RFC 2119 “language” in it is a tad extreme.

                Know another RFC that has a lot of RFC 2119 “language” in it that is not a standards track RFC?  RFC 2119…

                😊

--
Eric

From: mpls [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Wednesday, May 02, 2018 9:01 AM
To: Loa Andersson <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] should draft-ietf-mpls-spring-entropy-label be published as a RFC on the standards track?

Loa,

Cheers,
Andy

/Loa

PS

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 2 May 2018 14:59:44 -0400

Eric,

That’s a fair point, and a matter of interpretation of the draft. It would
be more obvious that standards track was necessary if the draft defined new
message formats or TLVs on the wire, or if any requests were being made of
IANA. Neither is the case in this draft.

However, there is quite a bit of RFC 2119 language. That means that
interoperability requirements are being made of implementers of a
draft/RFC. An implementation MUST do the “MUST”s, and so on, if they want
to play nicely with other implementations.

Informational status is great for documents like architectures, problem
statements, or to document how a particular vendor or operator did
something interesting. However, right in the abstract, this draft says
“This document examines and describes how ELs are to be applied to Segment
Routing MPLS.” That, in combination with the RFC 2119 language, sounds very
standards tracky, rather than informational, to me.

Cheers,
Andy

On Wed, May 2, 2018 at 2:23 PM, Eric Gray <[email-masked]> wrote:

>                 Personally I agree that RFC 2119 “language” and even a
> reference to RFC 2119 itself seems inappropriate in an “FYI” RFC.
>
>
>
>                 I have to say, however that making something a standards
> track document _*because*_ it has RFC 2119 “language” in it is a tad
> extreme.
>
>
>
>                 Know another RFC that has a lot of RFC 2119 “language” in
> it that is not a standards track RFC?  RFC 2119…
>
>
>
>                 😊
>
>
>
> --
>
> Eric
>
>
>
> *From:* mpls [mailto:[email-masked]] *On Behalf Of *Andrew G. Malis
> *Sent:* Wednesday, May 02, 2018 9:01 AM
> *To:* Loa Andersson <[email-masked]>
> *Subject:* Re: [mpls] should draft-ietf-mpls-spring-entropy-label be
> published as a RFC on the standards track?
>
>
>
> Loa,
>
>
>
> https://datatracker.ietf.org/doc/review-ietf-mpls-spring-
> entropy-label-08-rtgdir-lc-ceccarelli-2018-02-21/
>

---

From: Loa Andersson <[email-masked]>
Date: Sun, 13 May 2018 12:03:55 +0200

Working Group,

This poll has been closed.

We have no objections to publishing draft-ietf-mpls-spring-entropy-label
as a RFC on the standards track. We also seem to have some support for
adding information that an entropy label is not necessarily the only
method handling ECMP.

I will forward this to Deborah (AD responsible for this document).

/Loa

--