draft-ietf-softwire-lb-00.txt   draft-ietf-softwire-lb-01.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: June 19, 2009 Cisco Systems Expires: August 31, 2009 Cisco Systems
December 16, 2008 February 27, 2009
Load Balancing for Mesh Softwires Load Balancing for Mesh Softwires
draft-ietf-softwire-lb-00 draft-ietf-softwire-lb-01
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 June 19, 2009. This Internet-Draft will expire on August 31, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2008 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 Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
Payloads carried over a Softwire mesh service as defined by BGP Payloads carried over a Softwire mesh service as defined by BGP
Encapsulation Subsequent Address Family Identifier (SAFI) information Encapsulation Subsequent Address Family Identifier (SAFI) information
exchange often carry a number of identifiable, distinct flows. It exchange often carry a number of identifiable, distinct flows. It
can in some circumstances be desirable to distribute these flows over can in some circumstances be desirable to distribute these flows over
the equal cost multiple paths (ECMPs) that exist in the packet the equal cost multiple paths (ECMPs) that exist in the packet
switched network. Currently, the payload of a packet entering the switched network. Currently, the payload of a packet entering the
Softwire can only be interpreted by the ingress and egress routers. Softwire can only be interpreted by the ingress and egress routers.
skipping to change at page 4, line 49 skipping to change at page 4, line 49
o L2TPv3 over IP - Session ID. Special care needs to be taken to o L2TPv3 over IP - Session ID. Special care needs to be taken to
always create a non-zero Session ID. When an egress router always create a non-zero Session ID. When an egress router
includes a load balancing sub-TLV, it MUST encode the Session ID includes a load balancing sub-TLV, it MUST encode the Session ID
field of the Encapsulation sub-TLV in a way that ensures that the field of the Encapsulation sub-TLV in a way that ensures that the
most significant bits of the Session ID after extracting the block most significant bits of the Session ID after extracting the block
are non-zero. are non-zero.
o GRE - GRE key o GRE - GRE key
Future tunnel types that desire to use the load balancing sub-TLV This document does not define a load balancing field for the IP in IP
MUST define a load balancing field that is part of the encapsulating Tunnel Type (tunnel types 7). Future tunnel types that desire to use
header. the load balancing sub-TLV MUST define a load balancing field that is
part of the encapsulating header.
2.2. Encapsulation Considerations 2.2. Encapsulation Considerations
Fields included in the encapsulation header besides the load Fields included in the encapsulation header besides the load
balancing field are not affected by the load balancing block sub-TLV. balancing field are not affected by the load balancing block sub-TLV.
All other encapsulation fields are shared between variations of the All other encapsulation fields are shared between variations of the
load balancing field. For example, for L2TPv3-over-IP tunnel type, load balancing field. For example, for L2TPv3-over-IP tunnel type,
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 tunnel sub-TLV types of the Tunnel Block sub-TLV, in the BGP Tunnel Encapsulation Attribute Sub-TLVs
Encapsulation attribute registry (number space created as part of the registry (number space created as part of the publication of
publication of [I-D.ietf-softwire-encaps-safi]): [I-D.ietf-softwire-encaps-safi]):
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, and The authors would like to thank Stewart Bryant, Mark Townsley, and
Rajiv Asati for their review and comments. Rajiv Asati for their review and comments.
6. Normative References 6. Normative References
[I-D.ietf-softwire-encaps-safi] [I-D.ietf-softwire-encaps-safi]
Mohapatra, P. and E. Rosen, "BGP Encapsulation SAFI and Mohapatra, P. and E. Rosen, "BGP Encapsulation SAFI and
BGP Tunnel Encapsulation Attribute", BGP Tunnel Encapsulation Attribute",
draft-ietf-softwire-encaps-safi-03 (work in progress), draft-ietf-softwire-encaps-safi-05 (work in progress),
June 2008. 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.
 End of changes. 8 change blocks. 
19 lines changed or deleted 19 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/