The Use of Entropy Labels in MPLS Forwarding
draft-ietf-mpls-entropy-label-06

[Ballot comment]
I am voting Yes on this useful and mainly well written document, however
I do have some comments that I would request that the authors and
responsible AD consider.


In section 4.1

"If an ingress X chooses"

I think that is an ingress LSR (although you define it later
this is the first time we meet "X")

====

"This is to avoid jitter, latency and re-ordering issues for the flow."

Re-order for sure, but I don't see how jitter and latency come into
play.

=======

  "1.  at the ingress LSR, MPLS encapsulation hasn't yet occurred, so
      deep inspection is not necessary;"

Some people would consider a network layer device looking
at the transport headers to do ECMP as a DPI.

=======

  "On the other hand, an ingress LSR (e.g., a PE router) has detailed
  knowledge of an packet's contents, typically through a priori
  configuration of the encapsulation(s) that are expected at a given
  PE-CE interface, (e.g., IPv4, IPv6, VPLS, etc.).  They also have more
  flexible forwarding hardware."

The last sentence is disputable because it is highly implementation
dependent. There are ASIC and even Network Processor based
PEs that will not be able to push as the extra labels. I would delete
the last sentence.

=======


3.  Entropy Labels and Their Structure


  Entropy labels are generated by an ingress LSR, based entirely on
  load balancing information.  However, they MUST NOT have values in
  the reserved label space (0-15) [IANA MPLS Label Values].

Did I miss this reference to [IANA MPLS Label Values]?

=======

  "for multicast LSPs will be specified in a companion document."

Companion or future? I don't think it is yet a WG draft

=======

Section 8.1, 8.2 and 8.3 are quite hard to follow. They are only
informational, so it would probably be better if they were in
an appendix, so that any errors will not impact the protocol
definition.

It would also really help the reader if some text were
provided in each case explaining what is happening. Once
the first example has been explained in detail, many of the others
just need text describing the delta.

[Ballot comment]

Security considerations: if the EL value is calculated only
based on packet headers then a relatively efficient wiretapping
interface could be added depending on the function used to
generate the EL value. If a network didn't want that to be
possible or too easy then it could add some other input to the
generation of the EL values that'd make it harder to build a
table of EL values to tap given knowledge of the keys from the
packet.  For example the ingress LSR could generate a random
input to the EL generation process every so often. I've no idea
if that's practical nor worth inclusion but thought I'd mention
it anyway just in case.

IANA has reviewed draft-ietf-mpls-entropy-label-05 and has the following comments:

IANA understands that, upon approval of this document, there are  four actions which IANA must complete.

First in the Multiprotocol Label Switching Architecture (MPLS) Label Values
registry located at:

http://www.iana.org/assignments/mpls-label-values/mpls-label-values.xml

a new label value will be registered as follows:

Value: { TBD ]
Description:  Entropy Label Indicator (ELI)
Reference: [ RFC-to-be ]

Second, in the LDP TLV Type Name Space subregistry of the Label Distribution
Parameters registry located at:

http://www.iana.org/assignments/ldp-namespaces/ldp-namespaces.xml

a new TLV Type will be registered as follows:

Range: [ TBD ]
Description:  Entropy Label Capability TLV
Reference: [ RFC-to-be ]
Notes/Registration Date: [ TBD ]

Third, in the BGP Path Attributes subregistry of the Border Gateway Protocol
Parameters registry located at:

http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xml

a new path attribute will be added as follows:

Value: [ TBD ]
Code: BGP Entropy Label Capability Attribute
Reference: [ RFC-to-be ]

Fourth, in the Attribute Flags subregistry of the Resource Reservation
Protocol-Traffic Engineering (RSVP-TE) Parameters registry located at:

http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.xml

a new Attribute Flag is to be registerred as follows:

Bit | Name                    | Attribute  | Attribute  | RRO |
No  |                          | Flags Path | Flags Resv |    |  Reference
----+--------------------------+------------+------------+-----|--------------
TBD  Entropy Label Capability      Yes          Yes      No  [ RFC-to-be ]

IANA understands that these four actions are the only ones that need to be
completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The Use of Entropy Labels in MPLS Forwarding) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'The Use of Entropy Labels in MPLS Forwarding'
  as Proposed Standard

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 2012-09-03. 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


  Load balancing is a powerful tool for engineering traffic across a
  network.  This memo suggests ways of improving load balancing across
  MPLS networks using the concept of "entropy labels".  It defines the
  concept, describes why entropy labels are useful, enumerates
  properties of entropy labels that allow maximal benefit, and shows
  how they can be signaled and used for various applications.  This
  document updates RFCs 3031, 3107, 3209 and 5036.

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

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


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1797/
  http://datatracker.ietf.org/ipr/1605/
  http://datatracker.ietf.org/ipr/1789/

AD Review

Hi,

I have conducted my usual review of this draft before it moves on for
IETF last call and IESG evaluation. The purpose of the review is to
check that the document is ready to be published as an RFC and to try
to dig out any nits that should be resolved before wider review.

I am very impressed with the readability of this document and thank the
authors for their work so far. There are a number of minor nits and
small technical questions. I considered leaving these to be handled
during IETF last call, but I think there are enough of them that we
should get them fixed in a new revision before progressing further.

Please feel free to debate any of the points with me.

Can you please make a new revision, and as soon as I see it I will start
the last call.

Thanks,
Adrian

===

Please fix the following idnits

  -- The draft header indicates that this document updates RFC5036, but the
    abstract doesn't seem to mention this, which it should.

  -- The draft header indicates that this document updates RFC3031, but the
    abstract doesn't seem to mention this, which it should.

  == Unused Reference: 'RFC4364' is defined on line 946, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC4761' is defined on line 957, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC4762' is defined on line 961, but no explicit
    reference was found in the text

---

Need to expand a number of acronyms on first use because they show up
before Section 1.1
LSR

You need to add the following acronyms to Section 1.1
LSP
PW

---

Section 1.2

s/MPLS is very/MPLS is a very/
s/most notably: IP, PWE3/most notably: IP, PWs/
(in fact, in most cases s/PWE3/PW/)

---

Section 3

  The CoS field of an entropy label can be set
  to any value deemed appropriate.

and

  The CoS field can be set to any value deemed appropriate;
  typically, this will be the value in the label above the ELI in the
  label stack.

The field (formerly the EXP bits) is now known as the TC field per
RFC 5462.

---

Section 3

  This is accomplished by REQUIRING that the label

That is not a 2119 word. Try...

  To accomplish this, it is REQUIRED that the label

---

Somewhere in the document you need to say what would happen if a
legacy node accidentally received an ELI. I think the answer is easy:
there is no label mapping for the received label, so the packet is
dropped per section 3.18 of RFC 3031. It would be helpful to say this
in Section 4.1.

---

Section 4.2

  1.  On an incoming packet, identify the application to which the
      packet belongs, and thereby pick the fields to input to the load
      balancing function; call the output LB.

I think "LB" is load balancing function. Suggest...

  1.  On an incoming packet, identify the application to which the
      packet belongs, and thereby pick the fields to input to the load
      balancing function (LB); call the output LB.

---

Section 4.2

  4.  If, for the chosen tunnel, Y has not indicated that it can
      process ELs, push  onto the packet.  If Y has indicated that
      it can process ELs for the tunnel, push  onto the
      packet.  X SHOULD put the same TTL and TC fields for the ELI as
      it does for TL.  The TTL for the EL MUST be zero.  The TC for the
      EL may be any value.

Why is this "SHOULD". Under what conditions MAY this be varied?

---

4.4.  Penultimate Hop LSR

  No change is needed at penultimate hop LSRs.

I'm not clear about this.

Consider a simple tunnel carrying IP.
Before using the entropy label, PHP was a pop-and-go function such that
the whole MPLS header (including BoS) was stripped and only a native IP
packet was forwarded onto the final hop of the LSP.

The implication in what you write is that for when the entropy label is
used, the forwarded packet will contain ELI and EL. Surely you want to
strip them as well? Otherwise a router that did not previously handle
MPLS headers will suddenly need to.

I know that signaling (as described) will enable the egress to say
whether it can handle EL, but I am not sure that helps.

So the rule would be that whenever you pop a label that is immediately
followed by ELI, you must also pop ELI and EL.

(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?

  The MPLS working group request that:

            The Use of Entropy Labels in MPLS Forwarding
                    draft-ietf-mpls-entropy-label-04

  is published as an RFC on the standards track.




(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

  Load balancing, or multi-pathing, is an attempt to balance traffic
  across a network by allowing the traffic to use multiple paths. Load
  balancing has several benefits: it eases capacity planning; it can
  help absorb traffic surges by spreading them across multiple paths;
  it allows better resilience by offering alternate paths in the event
  of a link or node failure.

  As providers scale their networks, they use several techniques to
  achieve greater bandwidth between nodes. Two widely used techniques
  are: Link Aggregation Group (LAG) and Equal-Cost Multi-Path (ECMP).

  For MPLS networks, most of the same tecniques apply.
  However, finding useful keys in a packet for the purpose of load
  balancing can be more of a challenge.  In many cases, MPLS
  encapsulation may require fairly deep inspection of packets to find
  these keys at transit LSRs.

  One way to eliminate the need for this deep inspection is to have the
  ingress LSR of an MPLS Label Switched Path extract the appropriate
  keys from a given packet, input them to its load balancing function,
  and place the result in an additional label, termed the 'entropy
  label', as part of the MPLS label stack it pushes onto that packet.

  This docuement assumes that a method are used by the ingress nodes,
  e.g. use certain fields,  termed 'keys', within a packet's header
  as input to a load balancing function (typically a hash function) that
  selects the path for all packets in a given flow. 

  For MPLS networks this document specifies how an entropy and entropy
  label indicator is introduced into the label stack. In MPLS networks
  the packet's MPLS entire label stack can then be used by transit LSRs
  to perform load balancing, as the entropy label introduces the right
  level of "entropy" into the label stack.

Working Group Summary



Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

  This document has a strong support in the working group
  and has been well reviewed. We have had good discussions both
  on the mailing list and at the meeting in Paris.

  The working last call high-lighted an issues, that was decided
  to not have an effect on this draft, but the working group chairs
  has initiated a separate discussion that were started at the
  Vancouver meeting.
  This is has to do with how an LSRs should behave if it can't
  inspect the entire label stack and how the use of entropy labels
  will cooperate with MPLS OAM..

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 know of one implementation, that yet has to be completed;
  and sevral vendors has indicated that they intend to implement
  this specification.


Personnel



  Who is the Document Shepherd? Who is the Responsible Area
  Director?
 
  Loa Andersson is the document shepherd.

  Adrian Farrel is/will be the responsible AD.



(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 document shepherd have reviewed the document several times,
  e.g. when it was polled to become a wg document and at the wg last
  call, and one time in between.
  The document is ready for publication.


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

  No.



(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.


(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.

  There are IPRs filed against this document.
  Before the working group last call started the working group chairs
  sent a mail to the working group and the authors, asking any members
  of the working group whom were aware of IPRs to speak up and requiring
  the authors either to indicate if they were aware of IPRs or say that
  they were not.

  The IPR claims has not been explicitly discussed on the wg mailing
  list, but the working group has been made aware of the IPR claims.

  All the authors said they were not aware of IPRs, the working group
  chairs has taken these statement as "We are not aware of any other
  IPR claims, then those that has already been filed."



(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 three IPR claims filed for this document, two from IPR
  holders and one from a third party.



(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?

  The working group is behind this document. It has been well discussed
  and reviewed. 



(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


  The idnits-tool flags three "problems"

  1. a number of "unused references" or "looks like references",
      between lines 704 and 825. The background is that when the behavior
      of the entropy label in different scenarios is described the
      the authors use "[" and "]", which causes the nits tool to
      believe this is references.

  2. The document header says that this document updates RFC 3031
      and RFC 5036, but this is not mentioned in the abstract.

  3. there are there "Unused references" RFC4364, RFC4761 and RFC4762.
      They are defined in the reference section, but not used in the text.

  The authors will be required to fix this if a new version is
  need or it will be captured in a RFC Editors note.

  No other nits found.


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

  There are no such formal review criteria.

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

  Yes.

(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?

  No, all references, both normative and informative are to existing
  RFCs.

(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.

  RFC 3031 and and RFC 5036 will be updated, they are listed in the
  title page header, but there is no discussion on this in the abstract.
  This is discussed in the Introduction.


(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).


  The document requests four new IANA allocations:

  - One Reserved Label for Entropy Label Indicator form the "Multiprotocol Label
    Switching Architecture  (MPLS) Label Values" Registry.

  - One "LDP Entropy Label Capability TLV" from the IETF Consensus range
    in the LDP TLV Type Name Space Registry as the "Entropy Label Capability TLV".

  - One "BGP Entropy Label Capability Attribute" from Path Attribute Type
    Code from the "BGP Path Attributes" registry as the "BGP Entropy
    Label Capability Attribute".

  - One "RSVP-TE Entropy Label Capability flag" from the "Attribute Flags"
    from "RSVP TE Parameters" registry.

  All these allocation are well discussed in the working group.



(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 formal language.