The Use of Entropy Labels in MPLS Forwarding
draft-ietf-mpls-entropy-label-06
Yes
(Adrian Farrel)
No Objection
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Pete Resnick)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Wesley Eddy)
Note: This ballot was opened for revision 06 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
()
Unknown
Stewart Bryant Former IESG member
Yes
Yes
(2012-09-12)
Unknown
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.
Barry Leiba Former IESG member
No Objection
No Objection
()
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
()
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2012-09-10)
Unknown
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.
Wesley Eddy Former IESG member
No Objection
No Objection
()
Unknown