L3DSR server side bits open sourced
Hello, Some of you may remember my talk at Nanog51 about L3DSR (http://nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.nanog5...). I had promised that we'd try to get the server side bits released soon. While it took longer than anticipated, I'm glad to be able to announce that as of about ten minutes ago, they have finally escaped^Wbeen released into the wild: https://github.com/yahoo/l3dsr It's possible that we will try to put together a more formal announcement of this, but since I had promised the release at Nanog, I figured it'd be fair to let you guys know first. :-) Vanity plug: https://twitter.com/#!/jschauma/status/45181937089908736 Happy L3DSR'ing! -Jan
a real use for the diffserv bits! why not flowlabel in 6? it's been looking for a use for a decade. randy
v6 has subnet anycast... done and done!
never published Network Working Group R. Bush Internet-Draft IIJ Intended status: Standards Track August 2010 Expires: February 2, 2011 IPv6 Subnet Anycast Deprecated draft-ymbk-no-subnet-anycast-00 Abstract IPv6 subnet anycast is not used operationally, complicates implementations, and complicates protocol specifications. The form of anycast actually used in the Internet is routing-based, and is essentilly the same as that of IPv4 anycast. Therefore, this document deprecates IPv6 subnet anycast. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 2, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Bush Expires February 2, 2011 [Page 1] Internet-Draft IPv6 Subnet Anycast Deprecated August 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Normative References . . . . . . . . . . . . . . . . . . . 3 4.2. Informative References . . . . . . . . . . . . . . . . . . 3 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 Bush Expires February 2, 2011 [Page 2] Internet-Draft IPv6 Subnet Anycast Deprecated August 2010 1. Introduction The form of anycast which is used in the operational internet is described in [RFC4786]. This is used widely in IPv4 and IPv6. To quote, "To distribute a service using anycast, the service is first associated with a stable set of IP addresses, and reachability to those addresses is advertised in a routing system from multiple, independent service nodes." IPv6 subnet anycast, as defined in [RFC2526], complicates host and router stacks. It also makes address assignment unnecessarily complex, see [I-D.kohno-ipv6-prefixlen-p2p]. IPv6 subnet anycast is not actually used or deployed. In this case, it is sure that implementations are not even debugged. Therefore, this document deprecates IPv6 subnet anycast and removes conformance requirements from host and router implementations. 2. Security Considerations There are no known security implications for this document. 3. IANA Considerations This document has no IANA Considerations. 4. References 4.1. Normative References [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999. 4.2. Informative References [I-D.kohno-ipv6-prefixlen-p2p] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., and L. Colitti, "Using 127-bit IPv6 Prefixes on Inter-Router Links", draft-kohno-ipv6-prefixlen-p2p-02 (work in progress), July 2010. [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Bush Expires February 2, 2011 [Page 3] Internet-Draft IPv6 Subnet Anycast Deprecated August 2010 Services", BCP 126, RFC 4786, December 2006. Author's Address Randy Bush Internet Initiative Japan, Inc. 5147 Crystal Springs Bainbridge Island, Washington 98110 US Phone: +1 206 780 0431 x1 Email: randy@psg.com Bush Expires February 2, 2011 [Page 4]
On Wed, 9 Mar 2011, Randy Bush wrote: :: a real use for the diffserv bits! why not flowlabel in 6? it's been :: looking for a use for a decade. Honestly, we figured flowlabel might actually find a use before all the values of diffserv will :) In all seriousness, we are starting to set the spec for v6 l3dsr now, so, if you care, and believe that flowlabel would be a better field to "hijack" (or have a suggestion for another, better way then same DSCP methodology that we used for ipv4), we welcome input.. Thanks, -igor (yahoo)
:: a real use for the diffserv bits! why not flowlabel in 6? it's been :: looking for a use for a decade.
Honestly, we figured flowlabel might actually find a use before all the values of diffserv will :) In all seriousness, we are starting to set the spec for v6 l3dsr now, so, if you care, and believe that flowlabel would be a better field to "hijack" (or have a suggestion for another, better way then same DSCP methodology that we used for ipv4), we welcome input..
well, compared to an extension header, it wins hands down. randy
On Mar 9, 2011, at 00:35 MST, Igor Gashinsky wrote:
On Wed, 9 Mar 2011, Randy Bush wrote:
:: a real use for the diffserv bits! why not flowlabel in 6? it's been :: looking for a use for a decade.
Honestly, we figured flowlabel might actually find a use before all the values of diffserv will :) In all seriousness, we are starting to set the spec for v6 l3dsr now, so, if you care, and believe that flowlabel would be a better field to "hijack" (or have a suggestion for another, better way then same DSCP methodology that we used for ipv4), we welcome input..
:-/ Please don't abuse the flow-label this way, otherwise your proposal could get added to the "graveyard of IPv6 flow-label proposals" draft: http://tools.ietf.org/html/draft-hu-flow-label-cases-03#section-3 There has been *a lot* of discussion in the 6man WG recently to (finally) define the flow-label to be: a) be stateless; and, b) potentially be useful as an input-key, when used in conjunction with {src_ip, dst_ip}, for fine-grained load-balancing over LAG & ECMP paths, (instead of the traditional IPv6 header 5-tuple). One example where this might be useful is within Layer-2 switches, at IXP's or other parts of the network, where you'd really like them to only have to look at the 3-tuple: {src_ip, dst_ip + flow-label} as input-keys for LAG load-balancing, since they are at a fixed location in the IPv6 header. The other, longer-term win of this approach is that hosts can be free to define, or re-define, new IPv6 Extension Headers and you won't have to worry about Core routers/switches needing to dig into those Ext. headers (or, past them) to find useful input-keys for load-balancing over LAG & ECMP paths. Take a look at the following drafts and comment on the 6man WG mailing list if you have questions or concerns: IPv6 Flow Label Specification -- proposed revisions to the most current (& confusing) flow-label RFC: http://tools.ietf.org/html/draft-ietf-6man-flow-3697bis-01 Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels http://tools.ietf.org/html/draft-ietf-6man-flow-ecmp-01 Rationale for update to the IPv6 flow label specification http://tools.ietf.org/html/draft-ietf-6man-flow-update-03 -shane
On Wed, 9 Mar 2011, Shane Amante wrote: :: :: On Mar 9, 2011, at 00:35 MST, Igor Gashinsky wrote: :: > On Wed, 9 Mar 2011, Randy Bush wrote: :: > :: > :: a real use for the diffserv bits! why not flowlabel in 6? it's been :: > :: looking for a use for a decade. :: > :: > Honestly, we figured flowlabel might actually find a use before all the :: > values of diffserv will :) In all seriousness, we are starting to set the :: > spec for v6 l3dsr now, so, if you care, and believe that flowlabel would :: > be a better field to "hijack" (or have a suggestion for another, better :: > way then same DSCP methodology that we used for ipv4), we welcome input.. :: :: :-/ Please don't abuse the flow-label this way, otherwise your proposal could get added to the "graveyard of IPv6 flow-label proposals" draft: :: http://tools.ietf.org/html/draft-hu-flow-label-cases-03#section-3 :: :: There has been *a lot* of discussion in the 6man WG recently to (finally) define the flow-label to be: a) be stateless; and, b) potentially be useful as an input-key, when used in conjunction with {src_ip, dst_ip}, for fine-grained load-balancing over LAG & ECMP paths, (instead of the traditional IPv6 header 5-tuple). One example where this might be useful is within Layer-2 switches, at IXP's or other parts of the network, where you'd really like them to only have to look at the 3-tuple: {src_ip, dst_ip + flow-label} as input-keys for LAG load-balancing, since they are at a fixed location in the IPv6 header. The other, longer-term win of this approach is that hosts can be free to define, or re-define, new IPv6 Extension Headers and you won't have to worry about Core routers/switches needing to dig into those Ext. headers (or, past them) to find useful input-keys for load-balancing over LAG & ECMP paths. :: Yeap, this is why I said flow-label might actually find a good use soon enough :) -igor
participants (5)
-
Christopher Morrow -
Igor Gashinsky -
Jan Schaumann -
Randy Bush -
Shane Amante