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.nanog51-Schaumann.pdf).
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. :slight_smile:

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!
(also, a thing that's needed a use for 10 years)

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]

:: 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 :slight_smile: 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 :slight_smile: 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

:-/ 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 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 :slight_smile: 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 :slight_smile:

-igor