The Use of Entropy Labels in MPLS Forwarding
RFC 6790

Note: This ballot was opened for revision 06 and is now closed.

(Stewart Bryant) Yes

Comment (2012-09-12)
No email
send info
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


   "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

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.

(Adrian Farrel) Yes

(Ron Bonica) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Stephen Farrell) No Objection

Comment (2012-09-10)
No email
send info
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.

(Brian Haberman) No Objection

(Russ Housley) No Objection

(Barry Leiba) No Objection

(Pete Resnick) No Objection

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection