The IESG has approved the following document: - 'The Use of Entropy Labels in MPLS Forwarding' (draft-ietf-mpls-entropy-label-06.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-entropy-label/ 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 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 meetings 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 We know of one implementation, that yet has to be completed; and several vendors have indicated that they intend to implement this specification. Personnel Loa Andersson is the document shepherd. Adrian Farrel is/ the responsible AD. RFC Editor Note Section 1.2 OLD 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. PE routers need this information and these capabilities to: NEW On the other hand, an ingress LSR (e.g., a PE router) has detailed knowledge of a packet's contents, typically through a priori configuration of the encapsulations that are expected at a given PE-CE interface, (e.g., IPv4, IPv6, VPLS, etc.). They may also have more flexible forwarding hardware, depending on implementation details. PE routers need this information and these capabilities to: END --- Section 3 s/[IANA MPLS Label Values]/[RFC3032]/ --- Section 4.1 s/If an ingress X/If an ingress LSR X/ --- Section 5.4 s/companion document./future document./ --- Section 8 OLD This section describes the use of entropy labels in various scenarios. NEW This section describes the use of entropy labels in various scenarios. The material in this section is illustrative and offers guidance to implementations, but does not form a normative part of this specification. END --- Section 9 OLD Given that there is no end-user control over the values used for entropy labels, there is little risk of Entropy Label forgery which could cause uneven load-balancing in the network. NEW Given that there is no end-user control over the values used for entropy labels, there is little risk of Entropy Label forgery which could cause uneven load-balancing in the network. Note that 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. An implementation may protect against this by adding some other input to the generation of the EL values that would 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. In practice, many ECMP hashing algorithms contain a random factor in any case so as to avoid polarization issues. END IANA Note This is a "strong request" for specific allocations to facilitate early implementations. IANA should consider itself free to select other values if necessary, but if there is free choice, it would be appreciated if the values indicated below were allocated. In Section 10.1 the allocation of an MPLS Reserved Label is requested. Please allocate label 7 as the Entropy Label Indicator (ELI) In Section 10.2 the allocation of an LDP TLV Type is requested. Please allocate type 0x0206 for the Entropy Label Capability TLV
