draft-ietf-softwire-lb-02.txt   draft-ietf-softwire-lb-03.txt 
Network Working Group C. Filsfils Network Working Group C. Filsfils
Internet-Draft P. Mohapatra Internet-Draft P. Mohapatra
Intended status: Standards Track C. Pignataro Intended status: Standards Track C. Pignataro
Expires: October 4, 2009 Cisco Systems Expires: November 9, 2009 Cisco Systems
April 2, 2009 May 8, 2009
Load Balancing for Mesh Softwires Load Balancing for Mesh Softwires
draft-ietf-softwire-lb-02 draft-ietf-softwire-lb-03
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 4, 2009. This Internet-Draft will expire on November 9, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 29 skipping to change at page 3, line 29
example, for L2TPv3-over-IP [RFC3931] encapsulation, the load example, for L2TPv3-over-IP [RFC3931] encapsulation, the load
balancing field is the Session Identifier (Session ID). For GRE balancing field is the Session Identifier (Session ID). For GRE
[RFC2784] encapsulation, the key field [RFC2890], if present, [RFC2784] encapsulation, the key field [RFC2890], if present,
represents the load balancing field. This mechanism assumes that represents the load balancing field. This mechanism assumes that
core routers base their load balancing decisions on a flow definition core routers base their load balancing decisions on a flow definition
that includes the load balancing field. This is an obvious and that includes the load balancing field. This is an obvious and
generic functionality as, for example, for L2TPv3-over-IP tunnels, generic functionality as, for example, for L2TPv3-over-IP tunnels,
the Session ID is at the same well-known constant offset as the TCP/ the Session ID is at the same well-known constant offset as the TCP/
UDP ports in the encapsulating header. UDP ports in the encapsulating header.
The "Encapsulation SAFI" [I-D.ietf-softwire-encaps-safi] is extended The "Encapsulation SAFI" [RFC5512] is extended such that a contiguous
such that a contiguous block of the load balancing field is bound to block of the load balancing field is bound to the Softwire advertised
the Softwire advertised by a BGP next-hop. On a per-inner flow by a BGP next-hop. On a per-inner flow basis, the ingress PE selects
basis, the ingress PE selects one value of the load balancing field one value of the load balancing field from the block to preserve per-
from the block to preserve per-flow ordering, and at the same time to flow ordering, and at the same time to enhance the entropy across
enhance the entropy across flows. flows.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Load Balancing Block sub-TLV 2. Load Balancing Block sub-TLV
This document defines a new sub-TLV for use with the Tunnel This document defines a new sub-TLV for use with the Tunnel
Encapsulation Attribute defined in [I-D.ietf-softwire-encaps-safi]. Encapsulation Attribute defined in [RFC5512]. The new sub-TLV is
The new sub-TLV is referred to as the "Load Balancing Block sub-TLV" referred to as the "Load Balancing Block sub-TLV" and MAY be included
and MAY be included in any Encapsulation SAFI UPDATE message where in any Encapsulation SAFI UPDATE message where load balancing is
load balancing is desired. desired.
The sub-TLV type of the Load Balancing Block sub-TLV is 5. The sub- The sub-TLV type of the Load Balancing Block sub-TLV is 5. The sub-
TLV length is 2 octets. The value represents the length of the block TLV length is 2 octets. The value represents the length of the block
in bits and it MUST NOT exceed the size of the load balancing field. in bits and it MUST NOT exceed the size of the load balancing field.
This format is very similar to the variable-length subnet masking This format is very similar to the variable-length subnet masking
(VLSM) used in IP addresses to allow arbitrary length prefixes. The (VLSM) used in IP addresses to allow arbitrary length prefixes. The
block is determined by extracting the initial sequence of 'block block is determined by extracting the initial sequence of 'block
size' bits from the load balancing field. size' bits from the load balancing field.
If a load balancing field is not signaled (e.g., if the Encapsulation
sub-TLV is not included in an advertisement as in the case of GRE
without a Key), then the Load Balancing Block sub-TLV MUST NOT be
included.
The smaller the value field of the Load Balancing Block sub-TLV, the The smaller the value field of the Load Balancing Block sub-TLV, the
larger the space for per-flow identification, and hence the better larger the space for per-flow identification, and hence the better
entropy for potential load-balancing in the core; in addition, the entropy for potential load-balancing in the core; in addition, the
lower the polarization when mapping flows to ECMP paths. However, lower the polarization when mapping flows to ECMP paths. However,
reducing the load balancing block size consumes more L2TPv3 Session reducing the load balancing block size consumes more L2TPv3 Session
IDs or GRE keys, resulting in potentially less number of supported IDs or GRE keys, resulting in potentially less number of supported
services. A typical deployment would need to arbitrate between this services. A typical deployment would need to arbitrate between this
trade-off. trade-off.
As an example, Assume that there is a Softwire set up between R1 and As an example, Assume that there is a Softwire set up between R1 and
skipping to change at page 5, line 31 skipping to change at page 5, line 36
if the optional cookie is included in the Encapsulation sub-TLV by if the optional cookie is included in the Encapsulation sub-TLV by
the egress router during Softwire signaling, it applies to all the the egress router during Softwire signaling, it applies to all the
"Session ID" values derived at the ingress router after applying the "Session ID" values derived at the ingress router after applying the
load balancing block as described in this document. load balancing block as described in this document.
3. IANA Considerations 3. IANA Considerations
IANA is requested to assign the Type of 5 for the Load Balancing IANA is requested to assign the Type of 5 for the Load Balancing
Block sub-TLV, in the BGP Tunnel Encapsulation Attribute Sub-TLVs Block sub-TLV, in the BGP Tunnel Encapsulation Attribute Sub-TLVs
registry (number space created as part of the publication of registry (number space created as part of the publication of
[I-D.ietf-softwire-encaps-safi]): [RFC5512]):
Sub-TLV name Type Sub-TLV name Type
------------- ----- ------------- -----
Load Balancing Block 5 Load Balancing Block 5
4. Security Considerations 4. Security Considerations
There are no additional security risks introduced by this design. There are no additional security risks introduced by this design.
5. Acknowledgements 5. Acknowledgements
The authors would like to thank Stewart Bryant, Mark Townsley, Rajiv The authors would like to thank Stewart Bryant, Mark Townsley, Rajiv
Asati, and Kireeti Kompella for their review and comments. Asati, Kireeti Kompella, and Robert Raszuk for their review and
comments.
6. Normative References 6. Normative References
[I-D.ietf-softwire-encaps-safi]
Mohapatra, P. and E. Rosen, "BGP Encapsulation SAFI and
BGP Tunnel Encapsulation Attribute",
draft-ietf-softwire-encaps-safi-05 (work in progress),
February 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000. March 2000.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000. RFC 2890, September 2000.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP
Tunnel Encapsulation Attribute", RFC 5512, April 2009.
Authors' Addresses Authors' Addresses
Clarence Filsfils Clarence Filsfils
Cisco Systems Cisco Systems
Brussels, Brussels,
Belgium Belgium
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Pradosh Mohapatra Pradosh Mohapatra
 End of changes. 10 change blocks. 
22 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/