Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels
draft-ietf-mpls-spring-entropy-label-12

[Ballot comment]
Thank you for writing this - it provides useful functionality.

Please see Joe Clarke's OpsDir review here: https://datatracker.ietf.org/doc/review-ietf-mpls-spring-entropy-label-11-opsdir-lc-clarke-2018-06-25/  - it mirrors comments made by a number of ADs, and also contains a significnat number of nits (which would make the document better / more readable).

I had a question:
Section 4.  Entropy Readable Label Depth
" The Entropy Readable Label Depth (ERLD) is defined as the number of
  labels a router can both:
  a.  Read in an MPLS packet received on its incoming interface(s)
      (starting from the top of the stack).
  b.  Use in its load-balancing function."
...
"In a distributed switching architecture, each linecard may have a different capability in terms of ERLD."

In many cases, a device may have a different readable label depth in hardware / fastpath than it does by punting the packet to the CPU / control plane.
Perhaps the ERLD should be defined as 'Use in its load-balancing function in the dataplace / fast-path" (or something, this will need some wording).

I'd also like to say that I like Section 10 (Options considered) - sections like this make a document much more satisfying (otherwise one has niggling questions like "What didn't they do single ELs at the bottom of the stack?!") - thank you for including it.

I also have some nits:
Section 1.  Introduction
"The hashing technique is required to perfom a per-flow load-balancing and thus prevent packet disordering. "
1: Perform is a type
2: While 'disordering' explains it well, 'reordering' is a much more common term, and will (I think) cause less confusion.

"The MPLS architecture brings some challenges on the load-balancing as an LSR (Label Switch Router) should be able to look at header fields that are beyond the MPLS label stack."
"on the load-balancing" doesn't really parse. Perhaps: "... brings some load-balancing challenges, as..."?

Section 2.  Abbreviations and Terminology
SRGB is not defined on first use, nor it is in the Terminology section. Also, sorting this alphabetically would be appreciated.

The MPLS working group requests that

        "Entropy label for SPRING tunnels"
    (draft-ietf-mpls-spring-entropy-label)

is published as an RFC on the standards track (see note under question 1).

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  We request publication as an RFC on the standards track.

  Note:  When we first requested publication, this was for an Informational
              RFC.  This was based on a very early decision on the type of RFC we
              should request,
              However, the RTG Dir and AD review converged on that this
            should be an RFC on the standards track.
            The working group has been polled, and agree that standards track
            is correct.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes how entropy labels (EL) may be used with
  Segment Routing running over an MPLS data plane.
  Entropy labels (EL) is a technique used in MPLS to improve load-balancing.
  Segment Routing (SR) is a technique  that uses  a source routing paradigm. 
  A node (LSR) steers a packets through an ordered list of instructions, called
  segments. 

Working Group Summary

There has been no controversies over this document, the working
group understands that key technologies like entropy labels need
to be made working also when LSPs are set up using the segement
routing paradigm. The processing has been somewhat slow, and
there were a long time, mostly depending on that some of the
authors were changing affiliations, between a first wglc and that
the document was updated. The working group decided, because
of the time elapsed to run a second wglc. This second wglc did not
receive anything but supportive comments.

This document has 6 authors listed. The reason is that all six authors
have substantially contributed text and ideas to the document. The
number of authors has been discussed at leas twice as the document
as the document has progressed. First then we adopted the draft as a
working group document. The outcome of this discussion were that we
should revisit it before we did go to wglc.

The discussion prior to wglc led to that we moved two people to
contributors. The discussion involved working group chairs, ADs
and authors. After a discussion on the mpls list and reviewing what
each of the authors contributed we were convinced that it would be
correct to list six authors on the front page. This is the shared
opinion between ADs, wg chairs and authors.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

  We currently have no hard information on existing implementations.  An
  implementation poll has been sent to the working group mailing list, this write-up
  will be updated as soon as the implementation poll yields information.

  A significant number or vendors and service providers has expressed interest in
  this specification.

  No special type of review is necessary, it has been working group last called both in
  MPLS and SPRING working groups.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Loa Anderson is the Document Shepherd
  Deborah Brungard is the responsible Area Director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The working group chair / document shepherd review is pretty straightforward
  - the document was reviewed when it was first posted, some small comments sent
      to the authors
  - the document was reviewed a second time as preparation for the MPLS-RT
      review and working group adoption poll
  - the document was read a third time when we discussed the use of 2119 language
      in an Informational document; the working agreed that the document should be
      be on the standards track

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No such concerns.



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No such reviews necessary.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No such concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes, all author have confirmed on the working group mailing list
  that they are unaware of any IPRs relating to this document..

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are no IPR disclosures against this document.

  However, there is a small caveat where one possible solution on how
  to introduce the EL into the label stack. A single EL at the bottom of
  stack described in section 10.1, this technology has a relevant IPR.
  For the purpose of this document, the single EL at the bottom of the
  label stack was rejected, the working group found that it was unnecessary
  to disclose this IPR (at least against this document).
 

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  This is one of the things that MPLS and SPRING working groups
  agree needs to be specified for SPRING specified segment routing
  to work over an MPLS data plane.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such threats.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The shepherd has not found any such nits, and the document passes
  the nits tool clean.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal review necessary.

(13) Have all references within this document been identified as
either normative or informative?

  Yes all references are correctly split into normative and informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  There are two normative references to work in progress:
  draft-ietf-spring-segment-routing
  draft-ietf-spring-segment-routing-mpls

  However, for both of these documents publication has been requested.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No downward references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  There will be no changes of the status or any other document on
  publication of draft-ietf-mpls-spring-entropy-label.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  There are no IANA considerations in this document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA  registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No automated checks required.

[Ballot comment]
Minor high level comment:
The use of normative and non normative MAY is a bit confusing in this doc. I think the usage is in most cases correct, however, if you could re-phase some of the sentences where your use a lower case "may" to just avoid the word "may", I think it would even make the text easier readable in quite some cases. Any maybe also double-check on the use of MAY (e.g. there are some "an implementation may" and "an implementation MAY" where I'm not certain about the use of upper case MAY).

One mostly editorial request:
sec 1:
"... and, if the upper layer is TCP or UDP, the source port and destination port can be added as well in the hash."
SCTP has port number as well. Maybe better say:
"... and, if provided by the upper layer, the source port and destination port can be added as well in the hash."

[Ballot comment]
I have a similar opinion as others regarding the status of this document: informational vs proposed standard.  While I don't disagree with the intention of the WG to put this work on the standards track, I think that, as a standard, the document still needs some work:  even when using rfc2119 language, the specification is not as precise as I would hope.  A couple of examples from §7:

(a) "This section describes some considerations that could be taken into account when placing ELI/ELs.  This list of criteria is not considered as exhaustive and an implementation MAY take into account additional criteria or tie-breakers that are not documented here."  Even if specific language is used later on, the preface says that the considerations don't have to be taken into account ("could be"), and that there is other criteria (not in this document) that could be used.  How are multiple implementations to consistently interoperate?

(b) "An implementation SHOULD try to maximize the load-balancing where multiple ECMP paths are available and minimize the number of EL/ELIs that need to be inserted."  How does an implementation try?  How would an implementation maximize load balancing?  I don't remember seeing anything like that in rfc6790.


On the process side, the IETF LC should be redone simply because it was done assuming an informational status (regardless of the downref).

[I am not balloting DISCUSS because I'm sure the responsible AD will do the right thing.]

[Ballot comment]
* Section 2

      ELI - Entropy Label Identifier

Isn't ELI supposed to be the Entropy Label *Indicator* that indicates that the next label is an entropy label?

* Section 7.1.1.

In this example the label stack is stated as



but the text that follows assumes that there is an entropy label for P6 to follow. Is the example stack missing ELI2 and EL2? I think the text should be made consistent with the label stack either way.

[Ballot comment]
Substantive Comments:

- Adam beat me to the comment about the normative downref to RFC 7855. I agree with his point.

§1, 2nd paragraph: "The MPLS architecture brings some challenges on the load-balancing as
  an LSR (Label Switch Router) should be able to look at header fields
  that are beyond the MPLS label stack."

I'm confused by that statement.  Should this say " ... should _not_ be able ... " or "needs to be able"?

§14: Please elaborate. This adds a new data element and mechanism; please expLain why that doesn't affect the security considerations. (I'm willing to believe that it doesn't, but the section should contain an actual argument for that point.)

Editorial Comments:

- General: The term "Entropy Label" is used in a singular sense on several occasions. That usage needs an article, e.g. "The Entropy Label ..."

[Ballot comment]
Small process nit:

RFC 7855, which is informational, is listed as a normative reference in this
document, which is PS. I don't see RFC 7855 on the downref registry (
https://datatracker.ietf.org/doc/downref/ ), and this document didn't mention
the downref in its IETF LC announcement (
https://mailarchive.ietf.org/arch/msg/ietf-announce/ROPiwT5P_oM5PYBRoVeY7L_vsFQ
)

RFC 8067 §2 lets the IESG process the document anyway, and I think we should,
but I want to flag this for explicit consideration. This also interacts with
Benjamin's observation that perhaps this document should go back to being
informational.

---------------------------------------------------------------------------

§7.2.3:

>  All
>  routers have an ERLD of 10, expect P1 and P2 which have an ERLD of 4.

Nit: "except"

[Ballot comment]
I'm balloting No Objection, but would still like to see some discussion on the first point.

I see the WG decided to change from targetting Informational to Proposed
Standard as triggered by the RtgDir review.  It's still unclear to me that
this is the best choice, though.  Perhaps a better test than "does this use
RFC 2119 language to normatively specify behavior?" is "can we concretely
test if two independent implementations interoperate?", as would be needed
to move to full Internet Standard.  It's unclear that there is any
cooperative interoperability needed here, as opposed to unilateral choices
made by one peer in the context of a broader framework.  (Perhaps a new
thing here is ther presence of multiple ELs in the stack; I don't know.)
This makes me wonder if the contents would be better recast as a BCP (being
the best practice for assigning multiple entropy labels for SPRING
tunnels).

I guess this ship has sailed and probably I should keep quiet about it (and
yet I'm still talking), but if I understand correctly the entropy label is
not exactly providing fresh entropy (in the form of random input) for
load-balancing, but rather making existing entropy more easily accessible.
My worldview is not represented in RFC 6790 at all, though, so the desire
to maintain consistency over time would contraindicate any big changes to
this document.  Perhaps in Section 1 "provide entropy" could be "make
entropy accessible", or similar, but I suspect I'm in the rough here and
the right answer is actually to do nothing.

There's a lot of "how to advertise this value is outside the scope of this
document", but the only guidance or pointer to external work seems to be in
Section 7.2.1; maybe there could be more internal references to that
section when the "out of scope" remarks appear.  Something like a
parenthetical, "(see Section 7.2.1 for potential approaches)", perhaps.

Some section-by-section comments follow (mostly nits).

Section 1

  [...] Using the
  entropy label in the hash keys reduces the need of a deep packet
  inspection in the LSR while keeping a good level of entropy in the
  load balancing.

s/need of a/need for/

Section 2

Does LSR expand to "Label Switch Router" (as is done in this text) or
"Label Switching Router" (what's in the RFC Editor's word list)?

Section 3

Expand SRGB on first use.

Section 4

It's a little jarring to talk of "position 1 (top)" which is (IIUC) the
bottommost label in the Figure 2 depiction.  (I'm sure readers will know
the intent, of course.)

Section 5

  When an external controller is used to program a label stack on a
  particular node, this node MAY advertise its MSD value or a subset of
  its MSD value to the controller.  How this advertisement is done is
  outside the scope of this document.  As the controller does not have
  the knowledge of the entire label stack to be pushed by the node, the
  node may advertise an MSD value which is lower than its actual limit.

A node's MSD is a scalar value, not a set, so "a subset of its MSD value"
makes no sense; presumably it is advertising a value smaller than its
actual MSD value in this case, as is explicitly mentioned in the last
quoted sentence.  Given the apparent duplication, maybe this text could be
trimmed down, something like:

  An external controller can be used to program a label stack on a
  particular node, which requires the node to indicate to the controller
  what MSD value to be used for that node.  How this advertisement is done is
  outside the scope of this document.  As the controller does not have
  the knowledge of the entire label stack to be pushed by the node, the
  node may advertise an MSD value which is lower than its actual limit.


  In the figure 3, an IP packet comes in the MPLS network at PE1.  All

nit: "comes in to" or maybe just "enters"

Not being a routing person, I always have to look up whether a higher
metric means to give that link more or less traffic, but presumably this is
only a problem for me...

Section 6

  Each LSP associated with a binding SID has its own entropy
  label capability.

I'm not sure I understand what this sentence means.  Is it that I can
assign ELs differently for different LSPs, or that the ERLD at each point
step on the path is a function of the LSP, or something else?

Section 7.1.1

IMPORTANT: I'm confused here; we talk about PE1 having a MSD that lets it
introduce two ELI/EL pairs, but the proposed stack only includes one such
pair, despite the text talking about the need to insert a new ELI/EL next
to P6 for its load balancing.

Section 7.2.2.1

Please expand SPT.

Section 7.2.4

  [...] As example, a service provider

nit: As an example

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-mpls-spring-entropy-label-11, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-06-19):

From: The IESG
To: IETF-Announce
CC: mpls@ietf.org, loa@pi.nu, mpls-chairs@ietf.org, db3546@att.com, draft-ietf-mpls-spring-entropy-label@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Entropy label for SPRING tunnels) to Informational RFC


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'Entropy label for SPRING
tunnels'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-06-19. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Segment Routing (SR) leverages the source routing paradigm.  A node
  steers a packet through an ordered list of instructions, called
  segments.  Segment Routing can be applied to the Multi Protocol Label
  Switching (MPLS) data plane.  Entropy label (EL) is a technique used
  in MPLS to improve load-balancing.  This document examines and
  describes how ELs are to be applied to Segment Routing MPLS.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-entropy-label/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-entropy-label/ballot/


No IPR declarations have been submitted directly on this I-D.

The MPLS working group requests that

        "Entropy label for SPRING tunnels"
    (draft-ietf-mpls-spring-entropy-label)

is published as an RFC on the standards track (see note under question 1).

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  We request publication as an RFC on the standards track.

  Note:  When we first requested publication, this was for an Informational
              RFC.  This was based on a very early decision on the type of RFC we
              should request,
              However, the RTG Dir and AD review converged on that this
            should be an RFC on the standards track.
            The working group has been polled, and agree that standards track
            is correct.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes how entropy labels (EL) may be used with
  Segment Routing running over an MPLS data plane.
  Entropy labels (EL) is a technique used in MPLS to improve load-balancing.
  Segment Routing (SR) is a technique  that uses  a source routing paradigm. 
  A node (LSR) steers a packets through an ordered list of instructions, called
  segments. 

Working Group Summary

There has been no controversies over this document, the working
group understands that key technologies like entropy labels need
to be made working also when LSPs are set up using the segement
routing paradigm. The processing has been somewhat slow, and
there were a long time, mostly depending on that some of the
authors were changing affiliations, between a first wglc and that
the document was updated. The working group decided, because
of the time elapsed to run a second wglc. This second wglc did not
receive anything but supportive comments.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

  We currently have no hard information on existing implementations.  An
  implementation poll has been sent to the working group mailing list, this write-up
  will be updated as soon as the implementation poll yields information.

  A significant number or vendors and service providers has expressed interest in
  this specification.

  No special type of review is necessary, it has been working group last called both in
  MPLS and SPRING working groups.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Loa Anderson is the Document Shepherd
  Deborah Brungard is the responsible Area Director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The working group chair / document shepherd review is pretty straightforward
  - the document was reviewed when it was first posted, some small comments sent
      to the authors
  - the document was reviewed a second time as preparation for the MPLS-RT
      review and working group adoption poll
  - the document was read a third time when we discussed the use of 2119 language
      in an Informational document; the working agreed that the document should be
      be on the standards track

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No such concerns.



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No such reviews necessary.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No such concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes, all author have confirmed on the working group mailing list
  that they are unaware of any IPRs relating to this document..

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are no IPR disclosures against this document.

  However, there is a small caveat where one possible solution on how
  to introduce the EL into the label stack. A single EL at the bottom of
  stack described in section 10.1, this technology has a relevant IPR.
  For the purpose of this document, the single EL at the bottom of the
  label stack was rejected, the working group found that it was unnecessary
  to disclose this IPR (at least against this document).
 

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  This is one of the things that MPLS and SPRING working groups
  agree needs to be specified for SPRING specified segment routing
  to work over an MPLS data plane.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such threats.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The shepherd has not found any such nits, and the document passes
  the nits tool clean.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal review necessary.

(13) Have all references within this document been identified as
either normative or informative?

  Yes all references are correctly split into normative and informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  There are two normative references to work in progress:
  draft-ietf-spring-segment-routing
  draft-ietf-spring-segment-routing-mpls

  However, for both of these documents publication has been requested.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No downward references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  There will be no changes of the status or any other document on
  publication of draft-ietf-mpls-spring-entropy-label.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  There are no IANA considerations in this document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA  registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No automated checks required.

The MPLS working group requests that

        "Entropy label for SPRING tunnels"
    (draft-ietf-mpls-spring-entropy-label)

is published as an Informational RFC.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  We request publication as an Informational RFC, it is correctly indicated
  in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes how entropy labels (EL) may be used with
  Segment Routing running over an MPLS data plane.
  Entropy labels (EL) is a technique used in MPLS to improve load-balancing.
  Segment Routing (SR) is a technique  that uses  a source routing paradigm. 
  A node (LSR) steers a packets through an ordered list of instructions, called
  segments. 

Working Group Summary

There has been no controversies over this document, the working
group understands that key technologies like entropy labels need
to be made working also when LSPs are set up using the segement
routing paradigm. The processing has been somewhat slow, and
there were a long time, mostly depending on that some of the
authors were changing affiliations, between a first wglc and that
the document was updated. The working group decided, because
of the time elapsed to run a second wglc. This second wglc did not
receive anything but supportive comments.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

  We currently have no hard information on existing implementations.  An
  implementation poll has been sent to the working group mailing list, this write-up
  will be updated as soon as the implementation poll yields information.

  A significant number or vendors and service providers has expressed interest in
  this specification.

  No special type of review is necessary, it has been working group last called both in
  MPLS and SPRING working groups.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Loa Anderson is the Document Shepherd
  Deborah Brungard is the responsible Area Director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The working group chair / document shepherd review is pretty straightforward
  - the document was reviewed when it was first posted, some small comments sent
      to the authors
  - the document was reviewed a second time as preparation for the MPLS-RT
      review and working group adoption poll
  - the document was read a third time when we discussed the use of 2119 language
      an Informational document; the working agreed that the document should be
      Informational, but also that the use of "SHOULD" especially in section 4 in the
      context of RLD is correct. "SHOULD is the only 2119 word that is is used .

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No such concerns.



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No such reviews necessary.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No such concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes, all author have confirmed on the working group mailing list
  that they are unaware of any IPRs relating to this document..

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are no IPR disclosures against this document.

  However, there is a small caveat where one possible solution on how
  to introduce the EL into the label stack. A single EL at the bottom of
  stack described in section 10.1, this technology has a relevant IPR.
  For the purpose of this document, the single EL at the bottom of the
  label stack was rejected, the working group found that it was unnecessary
  to disclose this IPR (at least against this document).
 

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  This is one of the things that MPLS and SPRING working groups
  agree needs to be specified for SPRING specified segment routing
  to work over an MPLS data plane.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such threats.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The shepherd has not found any such nits, and the document passes
  the nits tool clean.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal review necessary.

(13) Have all references within this document been identified as
either normative or informative?

  Yes all references are correctly split into normative and informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  There are two normative references to work in progress:
  draft-ietf-spring-segment-routing
  draft-ietf-spring-segment-routing-mpls

  However, for both of these documents publication has been requested.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  We are requesting publication of an Informational RFC, the shepherd
  does not think that downward references are possible. In any case there
  are no downward references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  There will be no changes of the status or any other document on
  publication of draft-ietf-mpls-spring-entropy-label.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  There are no IANA considerations in this document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA  registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No automated checks required.

The MPLS working group requests that

        "Entropy label for SPRING tunnels"
    (draft-ietf-mpls-spring-entropy-label)

is published as an Informational RFC.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  We request publication as an Informational RFC, it is correctly indicated
  in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes how entropy labels (EL) may be used with
  Segment Routing running over an MPLS data plane.
  Entropy labels (EL) is a technique used in MPLS to improve load-balancing.
  Segment Routing (SR) is a technique  that uses  a source routing paradigm. 
  A node (LSR) steers a packets through an ordered list of instructions, called
  segments. 

Working Group Summary

There has been no controversies over this document, the working
group understands that key technologies like entropy labels need
to be made working also when LSPs are set up using the segement
routing paradigm. The processing has been somewhat slow, and
there were a long time, mostly depending on that some of the
authors were changing affiliations, between a first wglc and that
the document was updated. The working group decided, because
of the time elapsed to run a second wglc. This second wglc did not
receive anything but supportive comments.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

  We currently have no hard information on existing implementations.  An
  implementation poll has been sent to the working group mailing list, this write-up
  will be updated as soon as the implementation poll yields information.

  A significant number or vendors and service providers has expressed interest in
  this specification.

  No special type of review is necessary, it has been working group last called both in
  MPLS and SPRING working groups.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Loa Anderson is the Document Shepherd
  Deborah Brungard is the responsible Area Director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The working group chair / document shepherd review is pretty straightforward
  - the document was reviewed when it was first posted, some small comments sent
      to the authors
  - the document was reviewed a second time as preparation for the MPLS-RT
      review and working group adoption poll
  - the document was read a third time when we discussed the use of 2119 language
      an Informational document; the working agreed that the document should be
      Informational, but also that the use of "SHOULD" especially in section 4 in the
      context of RLD is correct. "SHOULD is the only 2119 word that is is used .
  - However while writing the shepherd write-up it is discovered that the
      "Requirement Language"-template is old and should be updated, the authors
      is instructed to do this as a part of updates at RTG-DIR review, AD review or
      IETF LC.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No such concerns.



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No such reviews necessary.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No such concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes, all author have confirmed on the working group mailing list
  that they are unaware of any IPRs relating to this document..

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There are no IPR disclosures against this document.

  However, there is a small caveat where one possible solution on how
  to introduce the EL into the label stack. A single EL at the bottom of
  stack described in section 10.1, this technology has a relevant IPR.
  For the purpose of this document, the single EL at the bottom of the
  label stack was rejected, the working group found that it was unnecessary
  to disclose this IPR (at least against this document).
 

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  This is one of the things that MPLS and SPRING working groups
  agree needs to be specified for SPRING specified segment routing
  to work over an MPLS data plane.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such threats.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The shepherd has not found any such nits, and the document passes
  the nits tool clean.

  Maybe we should count the use of the old requirement language template
  (see question 11 of this write-up)  as a "nit".

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal review necessary.

(13) Have all references within this document been identified as
either normative or informative?

  Yes all references are correctly split into normative and informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  There are two normative references to work in progress:
  draft-ietf-spring-segment-routing
  draft-ietf-spring-segment-routing-mpls

  However, for both of these documents publication has been requested.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  We are requesting publication of an Informational RFC, the shepherd
  does not think that downward references are possible. In any case there
  are no downward references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  There will be no changes of the status or any other document on
  publication of draft-ietf-mpls-spring-entropy-label.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  There are no IANA considerations in this document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA  registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No automated checks required.

Request for posting confirmation emailed to previous authors: Siva Sivabalan , Rob Shakir , Kireeti Kompella , Sriganesh Kini , " jefftant@gmail.com" , Stephane Litkowski

Request for posting confirmation emailed to previous authors: Siva Sivabalan , Rob Shakir , Kireeti Kompella , mpls-chairs@ietf.org, Sriganesh Kini , " jefftant@gmail.com" , Stephane Litkowski

Request for posting confirmation emailed to previous authors: Siva Sivabalan , Rob Shakir , Kireeti Kompella , mpls-chairs@ietf.org, Sriganesh Kini , " jefftant@gmail.com" , Stephane Litkowski

Notification list changed to draft-ietf-mpls-spring-entropy-label.ad@ietf.org, mpls@ietf.org, draft-ietf-mpls-spring-entropy-label.shepherd@ietf.org, mpls-chairs@ietf.org, draft-ietf-mpls-spring-entropy-label@ietf.org, "Loa Andersson" <loa@pi.nu> from draft-ietf-mpls-spring-entropy-label.ad@ietf.org, mpls@ietf.org, draft-ietf-mpls-spring-entropy-label.shepherd@ietf.org, mpls-chairs@ietf.org, draft-ietf-mpls-spring-entropy-label@ietf.org