draft-ietf-6man-flow-update-03.txt   draft-ietf-6man-flow-update-04.txt 
6MAN S. Amante 6MAN S. Amante
Internet-Draft Level 3 Internet-Draft Level 3
Intended status: Informational B. Carpenter Intended status: Informational B. Carpenter
Expires: August 28, 2011 Univ. of Auckland Expires: September 14, 2011 Univ. of Auckland
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
February 26, 2011 March 13, 2011
Rationale for update to the IPv6 flow label specification Rationale for update to the IPv6 flow label specification
draft-ietf-6man-flow-update-03 draft-ietf-6man-flow-update-04
Abstract Abstract
Various published proposals for use of the IPv6 flow label are Various published proposals for use of the IPv6 flow label are
incompatible with its original specification in RFC 3697. incompatible with its original specification in RFC 3697.
Furthermore, very little practical use is made of the flow label, Furthermore, very little practical use is made of the flow label,
partly due to some uncertainties about the correct interpretation of partly due to some uncertainties about the correct interpretation of
the specification. This document discusses and motivates changes to the specification. This document discusses and motivates changes to
the specification in order to clarify it, and to introduce some the specification in order to clarify it, and to introduce some
additional flexibility. additional flexibility.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on August 28, 2011. This Internet-Draft will expire on September 14, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 40 skipping to change at page 5, line 40
label value, without creating state, which would clarify and label value, without creating state, which would clarify and
limit its possible uses. In particular, its use for load limit its possible uses. In particular, its use for load
distribution and balancing would be encouraged. distribution and balancing would be encouraged.
2. Relax the rules to encourage locally defined and/or stateful use 2. Relax the rules to encourage locally defined and/or stateful use
of the flow label. This approach would make the flow label of the flow label. This approach would make the flow label
completely mutable and would exclude use cases depending on completely mutable and would exclude use cases depending on
strict end-to-end immutability. It would encourage applications strict end-to-end immutability. It would encourage applications
of a pseudo-random flow label, such as load distribution, on a of a pseudo-random flow label, such as load distribution, on a
local basis, but it would exclude end-to-end applications. local basis, but it would exclude end-to-end applications.
During 2010 there was considerable debate about these options During 2010 there was considerable debate about these options and
and variants of them, with a variety of proposals in previous variants of them, with a variety of proposals in previous versions of
versions of this document and in mailing list discussions. After this document and in mailing list discussions. After these
these discussions, there appears to be a view that simplicity should discussions, there appears to be a view that simplicity should
prevail, and that complicated proposals such as defining quality of prevail, and that complicated proposals such as defining quality of
service semantics in the flow label, or sub-dividing the flow label service semantics in the flow label, or sub-dividing the flow label
field into smaller sub-fields, will not prove efficient or field into smaller sub-fields, will not prove efficient or
deployable, especially in high speed routers. There is also a deployable, especially in high speed routers. There is also a
clearly expressed view that using the flow label for various forms of clearly expressed view that using the flow label for various forms of
stateless load distribution is the best simple application for it. stateless load distribution is the best simple application for it.
At the same time, it is necessary to recognize that the strict At the same time, it is necessary to recognize that the strict
immutability rule has drawbacks as noted above. immutability rule has drawbacks as noted above.
Even under the rules of RFC 3697, the flow label is intrinsically Even under the rules of RFC 3697, the flow label is intrinsically
skipping to change at page 7, line 13 skipping to change at page 7, line 13
node, not just the source node, to set the flow label value. node, not just the source node, to set the flow label value.
However, it is recommended that sources should set a pseudo-random However, it is recommended that sources should set a pseudo-random
flow label value in all flows, replacing the less precise flow label value in all flows, replacing the less precise
recommendation made in Section 3 of RFC 3697. Both stateful and recommendation made in Section 3 of RFC 3697. Both stateful and
stateless methods of assigning a pseudo-random value could be used. stateless methods of assigning a pseudo-random value could be used.
Section 3 of RFC 3697 also allows nodes to participate in an Section 3 of RFC 3697 also allows nodes to participate in an
unspecified method of flow state establishment. The changes do not unspecified method of flow state establishment. The changes do not
remove that option, but it is made clear that stateless models are remove that option, but it is made clear that stateless models are
also possible and are the recommended default. also possible and are the recommended default. The specific text
about requirements for stateful models has been reduced to a bare
minimum requirement that they do not interfere with the stateless
model.
The main novelty is that a forwarding node (typically a first-hop or The main novelty is that a forwarding node (typically a first-hop or
ingress router) may set the flow label value if the source has not ingress router) may set the flow label value if the source has not
done so, according to the same recommendations that apply to the done so, according to the same recommendations that apply to the
source. This might place a considerable processing load on ingress source. This might place a considerable processing load on ingress
routers, even if they adopted a stateless method of flow routers, even if they adopted a stateless method of flow
identification and label assignment. identification and label assignment.
The immutability of the flow label, once it has been set, is not The immutability of the flow label, once it has been set, is not
changed. However, some qualifications are placed on this property, changed. However, some qualifications are placed on this property,
skipping to change at page 9, line 7 skipping to change at page 9, line 9
Valuable comments and contributions were made by Fred Baker, Steve Valuable comments and contributions were made by Fred Baker, Steve
Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Haberman, Tony Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Haberman, Tony
Hain, Joel Halpern, Chris Morrow, Thomas Narten, Pekka Savola, Mark Hain, Joel Halpern, Chris Morrow, Thomas Narten, Pekka Savola, Mark
Smith, Pascal Thubert, Iljitsch van Beijnum, and other participants Smith, Pascal Thubert, Iljitsch van Beijnum, and other participants
in the 6man working group. in the 6man working group.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
8. Change log 8. Change log
draft-ietf-6man-flow-update-04: updated again to be in styep with RFC
3697bis, 2011-03-13
draft-ietf-6man-flow-update-03: updated to be in styep with RFC draft-ietf-6man-flow-update-03: updated to be in styep with RFC
3697bis, 2011-02-26 3697bis, 2011-02-26
draft-ietf-6man-flow-update-02: repurposed as rationale for update of draft-ietf-6man-flow-update-02: repurposed as rationale for update of
RFC 3697, 2011-01-31 RFC 3697, 2011-01-31
draft-ietf-6man-flow-update-01: clarified that this is not a formal draft-ietf-6man-flow-update-01: clarified that this is not a formal
update of RFC 3697, clarified text about domains exporting update of RFC 3697, clarified text about domains exporting
inappropriate labels, 2011-01-10 inappropriate labels, 2011-01-10
skipping to change at page 9, line 49 skipping to change at page 10, line 7
tunnels", draft-carpenter-flow-ecmp-03 (work in progress), tunnels", draft-carpenter-flow-ecmp-03 (work in progress),
October 2010. October 2010.
[I-D.gont-6man-flowlabel-security] [I-D.gont-6man-flowlabel-security]
Gont, F., "Security Assessment of the IPv6 Flow Label", Gont, F., "Security Assessment of the IPv6 Flow Label",
draft-gont-6man-flowlabel-security-01 (work in progress), draft-gont-6man-flowlabel-security-01 (work in progress),
November 2010. November 2010.
[I-D.hu-flow-label-cases] [I-D.hu-flow-label-cases]
Hu, Q. and B. Carpenter, "Survey of proposed use cases for Hu, Q. and B. Carpenter, "Survey of proposed use cases for
the IPv6 flow label", draft-hu-flow-label-cases-02 (work the IPv6 flow label", draft-hu-flow-label-cases-03 (work
in progress), September 2010. in progress), February 2011.
[I-D.ietf-6man-flow-3697bis] [I-D.ietf-6man-flow-3697bis]
Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", "IPv6 Flow Label Specification",
draft-ietf-6man-flow-3697bis-00 (work in progress), draft-ietf-6man-flow-3697bis-01 (work in progress),
January 2011. February 2011.
[I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching]
Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)",
draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03 draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03
(work in progress), March 2007. (work in progress), March 2007.
[McGann05] [McGann05]
McGann, O. and D. Malone, "Flow Label Filtering McGann, O. and D. Malone, "Flow Label Filtering
Feasibility", European Conference on Computer Network Feasibility", European Conference on Computer Network
Defence , 2005. Defence , 2005.
 End of changes. 9 change blocks. 
13 lines changed or deleted 19 lines changed or added

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