summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7954.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7954.txt')
-rw-r--r--doc/rfc/rfc7954.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc7954.txt b/doc/rfc/rfc7954.txt
new file mode 100644
index 0000000..4f69972
--- /dev/null
+++ b/doc/rfc/rfc7954.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) L. Iannone
+Request for Comments: 7954 Telecom ParisTech
+Category: Experimental D. Lewis
+ISSN: 2070-1721 Cisco Systems, Inc.
+ D. Meyer
+ Brocade
+ V. Fuller
+ September 2016
+
+
+ Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block
+
+Abstract
+
+ This document directs IANA to allocate a /32 IPv6 prefix for use with
+ the Locator/ID Separation Protocol (LISP). The prefix will be used
+ for local intra-domain routing and global endpoint identification, by
+ sites deploying LISP as Endpoint Identifier (EID) addressing space.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This document is a product of the Internet Engineering
+ Task Force (IETF). It represents the consensus of the IETF
+ community. It has received public review and has been approved for
+ publication by the Internet Engineering Steering Group (IESG). Not
+ all documents approved by the IESG are a candidate for any level of
+ Internet Standard; see Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7954.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iannone, et al. Experimental [Page 1]
+
+RFC 7954 LISP EID Block September 2016
+
+
+Copyright Notice
+
+ Copyright (c) 2016 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
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Rationale and Intent . . . . . . . . . . . . . . . . . . . . 3
+ 4. Expected Use . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 5. Block Dimension . . . . . . . . . . . . . . . . . . . . . . . 5
+ 6. 3+3 Allocation Plan . . . . . . . . . . . . . . . . . . . . . 6
+ 7. Allocation Lifetime . . . . . . . . . . . . . . . . . . . . . 7
+ 8. Routing Considerations . . . . . . . . . . . . . . . . . . . 7
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
+ 11.2. Informative References . . . . . . . . . . . . . . . . . 10
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iannone, et al. Experimental [Page 2]
+
+RFC 7954 LISP EID Block September 2016
+
+
+1. Introduction
+
+ This document directs the IANA to allocate a /32 IPv6 prefix for use
+ with the Locator/ID Separation Protocol (LISP [RFC6830]), LISP Map-
+ Server ([RFC6833]), LISP Alternative Topology (LISP+ALT [RFC6836])
+ (or other) mapping systems, and LISP Interworking ([RFC6832]).
+
+ This block will be used as global Endpoint Identifier (EID) space.
+
+2. Definition of Terms
+
+ The present document does not introduce any new terms with respect to
+ the set of LISP Specifications ([RFC6830], [RFC6831], [RFC6832],
+ [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC6837]), but it
+ assumes that the reader is familiar with the LISP terminology.
+ [LISP-INTRO] provides an introduction to the LISP technology,
+ including its terminology.
+
+3. Rationale and Intent
+
+ Discussion within the LISP working group led to the identification of
+ several scenarios in which the existence of a LISP-specific address
+ block brings technical benefits. The most relevant scenarios are
+ described below:
+
+ Early LISP destination detection: With the current specifications,
+ there is no direct way to detect whether or not a certain
+ destination is in a LISP domain without performing a LISP
+ mapping lookup. For instance, if an Ingress Tunnel Router
+ (ITR) is sending packets to all types of destinations (i.e.,
+ non-LISP destinations, LISP destinations not in the IPv6 EID
+ block, and LISP destinations in the IPv6 EID block), the only
+ way to understand whether or not to encapsulate the traffic is
+ to perform a cache lookup and, in case of a LISP cache miss,
+ send a Map-Request to the mapping system. In the meanwhile
+ (while waiting for the Map-Reply), packets may be dropped to
+ avoid excessive buffering.
+
+ Avoid penalizing non-LISP traffic: In certain circumstances, it
+ might be desirable to configure a router using LISP features to
+ natively forward all packets that do not have a destination
+ address in the block and, hence, no lookup whatsoever is
+ performed and packets destined to non-LISP sites are not
+ penalized in any manner.
+
+
+
+
+
+
+
+Iannone, et al. Experimental [Page 3]
+
+RFC 7954 LISP EID Block September 2016
+
+
+ Traffic Engineering: In some deployment scenarios, it might be
+ desirable to apply different traffic-engineering policies for
+ LISP and non-LISP traffic. A LISP-specific EID block would
+ allow improved traffic-engineering capabilities with respect to
+ LISP vs. non-LISP traffic. In particular, LISP traffic might
+ be identified without having to use Deep Packet Inspection
+ (DPI) techniques in order to parse the encapsulated packet.
+ Instead, performing a simple inspection of the outer header is
+ sufficient.
+
+ Transition Mechanism: The existence of a LISP-specific EID block may
+ prove useful in transition scenarios. A non-LISP domain would
+ ask for an allocation in the LISP EID block and use it to
+ deploy LISP in its network. Such allocation would not be
+ announced in the BGP routing infrastructure (cf. Section 4).
+ This approach will allow non-LISP domains to avoid fragmenting
+ their already allocated non-LISP addressing space, which may
+ lead to BGP routing table inflation since it may (rightfully)
+ be announced in the BGP routing infrastructure.
+
+ Limit the impact on the BGP routing infrastructure: As described in
+ the previous scenario, LISP adopters will avoid fragmenting
+ their addressing space, since fragmentation would negatively
+ impact the BGP routing infrastructure. Adopters will use
+ addressing space from the EID block, which might be announced
+ in large aggregates and in a tightly controlled manner only by
+ Proxy Tunnel Routers (PxTRs).
+
+ It is worth mentioning that new use cases may arise in the future,
+ due to new and unforeseen scenarios.
+
+ Furthermore, the use of a dedicated address block allows for tighter
+ control over the traffic in the initial experimental phase
+ (especially filtering), while facilitating its large-scale
+ deployment.
+
+ [RFC3692] considers assigning experimental and testing numbers
+ useful; having a reserved IPv6 prefix enables this practice. The
+ present document follows the guidelines provided in [RFC3692], with
+ one exception. [RFC3692] suggests the use of values similar to those
+ called "Private Use" in [RFC5226], which by definition are not
+ unique. One purpose of the present request to IANA is to guarantee
+ uniqueness to the EID block. The lack thereof would result in a lack
+ of real utility of a reserved IPv6 prefix.
+
+
+
+
+
+
+
+Iannone, et al. Experimental [Page 4]
+
+RFC 7954 LISP EID Block September 2016
+
+
+4. Expected Use
+
+ Sites planning to deploy LISP may request a prefix in the IPv6 EID
+ block. Such prefixes will be used for routing and endpoint
+ identification inside the site requesting it. Mappings related to
+ such a prefix, or part of it, will be made available through the
+ mapping system in use and registered to one or more Map-Server(s).
+
+ The EID block must be used for LISP experimentation and must not be
+ advertised in the form of more specific route advertisements in the
+ non-LISP inter-domain routing environment. Interworking between the
+ EID block sub-prefixes and the non-LISP Internet is done according to
+ the techniques described in [RFC6832] and [RFC7215].
+
+ As the LISP adoption progresses, the EID block may potentially have a
+ reduced impact on the BGP routing infrastructure, compared to the
+ case of having the same number of adopters using global unicast space
+ allocated by Regional Internet Registries (RIRs) ([MobiArch2007]).
+ From a short-term perspective, the EID block offers potentially large
+ aggregation capabilities since it is announced by Proxy Tunnel
+ Routers (PxTRs), possibly concentrating several contiguous prefixes.
+ This trend should continue with even lower impact from a long-term
+ perspective, because more aggressive aggregation can be used,
+ potentially leading to using fewer PxTRs announcing the whole EID
+ block ([FIABook2010]).
+
+ The EID block will be used only at the configuration level, so it is
+ recommended not to hard-code the IPv6 EID block in the router
+ hardware in any way. This prevents locking out sites that may want
+ to switch to LISP while keeping their own IPv6 prefix, which is not
+ in the IPv6 EID block. Furthermore, in the case of a future
+ permanent allocation, the allocated prefix may differ from the
+ experimental temporary prefix allocated during the experimentation
+ phase.
+
+ With the exception of the Proxy Ingress Tunnel Router (PITR) case
+ (described in Section 8), prefixes out of the EID block must not be
+ announced in the BGP routing infrastructure.
+
+5. Block Dimension
+
+ The working group reached consensus on an initial allocation of a /32
+ prefix. The reason of such consensus is manifold:
+
+ o The working group agreed that the /32 prefix is sufficiently large
+ to cover initial allocation and requests for prefixes in the EID
+ space in the next few years for very large-scale experimentation
+ and deployment.
+
+
+
+Iannone, et al. Experimental [Page 5]
+
+RFC 7954 LISP EID Block September 2016
+
+
+ o As a comparison, it is worth mentioning that the current LISP Beta
+ Network ([BETA]) is using a /32 prefix, with more than 250 sites
+ using a /48 sub-prefix. Hence, a /32 prefix appears sufficiently
+ large to allow the current deployment to scale up and be open for
+ interoperation with independent deployments using the EIDs in the
+ new /32 prefix.
+
+ o A /32 prefix is sufficiently large to allow deployment of
+ independent (commercial) LISP-enabled networks by third parties,
+ but may as well boost LISP experimentation and deployment.
+
+ o The use of a /32 prefix is in line with previous similar prefix
+ allocation for tunneling protocols ([RFC3056]).
+
+6. 3+3 Allocation Plan
+
+ Per this document, IANA has initially assigned a /32 prefix out of
+ the IPv6 addressing space for use as EID in LISP.
+
+ IANA allocated the requested address space in September 2016 for a
+ duration of 3 (three) years (through September 2019), with an option
+ to extend this period by 3 (three) more years (until September 2022).
+ By the end of the first period, the IETF will provide a decision on
+ whether to transform the prefix into a permanent assignment or to put
+ it back in the free pool (see Section 7 for more information).
+
+ In the first case, i.e., if the IETF decides to transform the block
+ into a permanent allocation, the EID block allocation period will be
+ extended for three years (until September 2022) to give the IETF time
+ to define the final size of the EID block and create a transition
+ plan. The transition of the EID block into a permanent allocation
+ might pose policy issues (as recognized in [RFC2860], Section 4.3);
+ therefore, discussion with the IANA, the RIR communities, and the
+ IETF community will be necessary to determine the appropriate policy
+ for permanent EID-block allocation and management. Note as well that
+ the final permanent allocation may differ from the initial
+ experimental assignment; hence, it is recommended not to hard-code
+ the experimental EID block on LISP-capable devices in any way.
+
+ In the latter case, i.e., if the IETF decides to terminate the
+ experimental-use EID block, all temporary prefix allocations in this
+ address range must expire and be released by September 2019, so that
+ the entire /32 is returned to the free pool.
+
+ The allocation and management of the EID block for the initial 3-year
+ period (and the optional 3 more years) is detailed in [RFC7955].
+
+
+
+
+
+Iannone, et al. Experimental [Page 6]
+
+RFC 7954 LISP EID Block September 2016
+
+
+7. Allocation Lifetime
+
+ If no explicit action is carried out by the end of the experiment (by
+ September 2019), it is automatically considered that there was not
+ sufficient interest in having a permanent allocation; therefore, the
+ address block will be returned to the free pool.
+
+ Otherwise, if the LISP working group recognizes that there is value
+ in having a permanent allocation, then explicit action is needed.
+
+ In order to trigger the process for a permanent allocation, a
+ document is required. Such a document has to articulate the
+ rationale for why a permanent allocation would be beneficial. More
+ specifically, the document has to detail the experience gained during
+ experimentation and all of the technical benefits provided by the use
+ of a LISP-specific prefix. Such technical benefits are expected to
+ lay in the scenarios described in Section 3. However, new and
+ unforeseen benefits may appear during experimentation. The
+ description should be sufficiently articulate that the needed size of
+ the permanent allocation can be estimated. However, note that, as
+ explained in Section 6, it is up to IANA to decide which address
+ block will be used as a permanent allocation and that such a block
+ may be different from the temporary experimental allocation.
+
+8. Routing Considerations
+
+ In order to provide connectivity between the Legacy Internet and LISP
+ sites, PITRs announcing large aggregates (ideally one single, large
+ aggregate) of the IPv6 EID block could be deployed. By doing so,
+ PITRs will attract traffic destined for LISP sites in order to
+ encapsulate and forward it toward the specific destination LISP site.
+ Routers in the Legacy Internet must treat announcements of prefixes
+ from the IPv6 EID block as normal announcements, applying best
+ current practices for traffic engineering and security.
+
+ Even in a LISP site, not all routers need to run LISP elements. In
+ particular, routers that are not at the border of the local domain,
+ used only for intra-domain routing, do not need to provide any
+ specific LISP functionality but must be able to route traffic using
+ addresses in the IPv6 EID block.
+
+ For the above-mentioned reasons, routers that do not run any LISP
+ element must not include any special handling code or hardware for
+ addresses in the IPv6 EID block. In particular, it is recommended
+ that the default router configuration not handle such addresses in
+ any special way. Doing differently could prevent communication
+ between the Legacy Internet and LISP sites or even break local intra-
+ domain connectivity.
+
+
+
+Iannone, et al. Experimental [Page 7]
+
+RFC 7954 LISP EID Block September 2016
+
+
+9. Security Considerations
+
+ This document does not introduce new security threats in the LISP
+ architecture nor in the legacy Internet architecture.
+
+10. IANA Considerations
+
+ IANA has assigned a /32 IPv6 prefix for use as the global EID space
+ for LISP using a hierarchical allocation as outlined in [RFC5226] and
+ summarized in Table 1. The assigned block is from the 2001:5 global
+ unicast space.
+
+ IANA is not requested to issue an AS0 Route Origin Attestation (ROA
+ [RFC6491]), because the global EID space is be used for routing
+ purposes.
+
+ +----------------------+--------------------+
+ | Attribute | Value |
+ +----------------------+--------------------+
+ | Address Block | 2001:5::/32 |
+ | Name | EID Space for LISP |
+ | RFC | RFC 7954 |
+ | Allocation Date | September 2016 |
+ | Termination Date | September 2019 [1] |
+ | Source | True [2] |
+ | Destination | True |
+ | Forwardable | True |
+ | Global | True |
+ | Reserved-by-protocol | True [3] |
+ +----------------------+--------------------+
+
+ [1] According to the 3+3 Plan outlined in this document, the
+ termination date can be postponed to September 2022.
+ [2] Can be used as a multicast source as well.
+ [3] To be used as EID space by routers enabled by LISP [RFC6830].
+
+ Table 1: Global EID Space
+
+ The reserved address space is requested for an initial 3-year period
+ starting in September 2016 (until September 2019), with an option to
+ extend it by three years (until September 2022) upon the decision of
+ the IETF (see Sections 6 and 7). Following the policies outlined in
+ [RFC5226], upon IETF Review, the decision should be made on whether
+ to have a permanent EID block assignment by September 2019. If no
+ explicit action is taken or, if the IETF Review outcome is that it is
+ not worth having a reserved prefix as a global EID space, the whole
+ /32 will be taken out from the "IANA IPv6 Special-Purpose Address
+ Registry" and put back in the free pool managed by IANA.
+
+
+
+Iannone, et al. Experimental [Page 8]
+
+RFC 7954 LISP EID Block September 2016
+
+
+ Allocation and management of the global EID space is detailed in
+ [RFC7955]. Nevertheless, all prefix allocations out of this space
+ must be temporary and no allocation must go beyond September 2019
+ unless the IETF Review decides for a permanent global EID space
+ assignment.
+
+11. References
+
+11.1. Normative References
+
+ [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
+ Understanding Concerning the Technical Work of the
+ Internet Assigned Numbers Authority", RFC 2860,
+ DOI 10.17487/RFC2860, June 2000,
+ <http://www.rfc-editor.org/info/rfc2860>.
+
+ [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
+ Considered Useful", BCP 82, RFC 3692,
+ DOI 10.17487/RFC3692, January 2004,
+ <http://www.rfc-editor.org/info/rfc3692>.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ DOI 10.17487/RFC5226, May 2008,
+ <http://www.rfc-editor.org/info/rfc5226>.
+
+ [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
+ Locator/ID Separation Protocol (LISP)", RFC 6830,
+ DOI 10.17487/RFC6830, January 2013,
+ <http://www.rfc-editor.org/info/rfc6830>.
+
+ [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
+ Locator/ID Separation Protocol (LISP) for Multicast
+ Environments", RFC 6831, DOI 10.17487/RFC6831, January
+ 2013, <http://www.rfc-editor.org/info/rfc6831>.
+
+ [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
+ "Interworking between Locator/ID Separation Protocol
+ (LISP) and Non-LISP Sites", RFC 6832,
+ DOI 10.17487/RFC6832, January 2013,
+ <http://www.rfc-editor.org/info/rfc6832>.
+
+ [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
+ Protocol (LISP) Map-Server Interface", RFC 6833,
+ DOI 10.17487/RFC6833, January 2013,
+ <http://www.rfc-editor.org/info/rfc6833>.
+
+
+
+
+
+Iannone, et al. Experimental [Page 9]
+
+RFC 7954 LISP EID Block September 2016
+
+
+ [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
+ Separation Protocol (LISP) Map-Versioning", RFC 6834,
+ DOI 10.17487/RFC6834, January 2013,
+ <http://www.rfc-editor.org/info/rfc6834>.
+
+ [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
+ Protocol Internet Groper (LIG)", RFC 6835,
+ DOI 10.17487/RFC6835, January 2013,
+ <http://www.rfc-editor.org/info/rfc6835>.
+
+ [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
+ "Locator/ID Separation Protocol Alternative Logical
+ Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
+ January 2013, <http://www.rfc-editor.org/info/rfc6836>.
+
+ [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
+ Routing Locator (RLOC) Database", RFC 6837,
+ DOI 10.17487/RFC6837, January 2013,
+ <http://www.rfc-editor.org/info/rfc6837>.
+
+ [RFC7955] Iannone, L., Jorgensen, R., Conrad, D., and G. Huston,
+ "Locator/ID Separation Protocol (LISP) Endpoint Identifier
+ (EID) Block Management Guidelines", RFC 7955,
+ DOI 10.17487/RFC7955, September 2016,
+ <http://www.rfc-editor.org/info/rfc7955>.
+
+11.2. Informative References
+
+ [BETA] LISP Beta Network, "Locator/ID Separation Protocol",
+ <http://www.lisp4.net>.
+
+ [FIABook2010]
+ Iannone, L. and T. Leva, "Modeling the economics of Loc/ID
+ Separation for the Future Internet", Towards the Future
+ Internet, Pages 11-20, ISBN: 9781607505389, IOS Press,
+ DOI 10.3233/978-1-60750-539-6-11, May 2010.
+
+ [LISP-INTRO]
+ Cabellos-Aparicio, A. and D. Saucez, "An Architectural
+ Introduction to the Locator/ID Separation Protocol
+ (LISP)", Work in Progress, draft-ietf-lisp-introduction-
+ 13, April 2015.
+
+
+
+
+
+
+
+
+
+Iannone, et al. Experimental [Page 10]
+
+RFC 7954 LISP EID Block September 2016
+
+
+ [MobiArch2007]
+ Quoitin, B., Iannone, L., de Launois, C., and O.
+ Bonaventure, "Evaluating the Benefits of the Locator/
+ Identifier Separation", The 2nd ACM-SIGCOMM International
+ Workshop on Mobility in the Evolving Internet
+ Architecture (MobiArch'07), DOI 10.1145/1366919.1366926,
+ August 2007.
+
+ [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
+ via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February
+ 2001, <http://www.rfc-editor.org/info/rfc3056>.
+
+ [RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public
+ Key Infrastructure (RPKI) Objects Issued by IANA",
+ RFC 6491, DOI 10.17487/RFC6491, February 2012,
+ <http://www.rfc-editor.org/info/rfc6491>.
+
+ [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
+ Pascual, J., and D. Lewis, "Locator/Identifier Separation
+ Protocol (LISP) Network Element Deployment
+ Considerations", RFC 7215, DOI 10.17487/RFC7215, April
+ 2014, <http://www.rfc-editor.org/info/rfc7215>.
+
+Acknowledgments
+
+ Special thanks to Roque Gagliano for his suggestions and pointers.
+ Thanks to Alvaro Retana, Deborah Brungard, Ron Bonica, Damien Saucez,
+ David Conrad, Scott Bradner, John Curran, Paul Wilson, Geoff Huston,
+ Wes George, Arturo Servin, Sander Steffann, Brian Carpenter, Roger
+ Jorgensen, Terry Manderson, Brian Haberman, Adrian Farrel, Job
+ Snijders, Marla Azinger, Chris Morrow, and Peter Schoenmaker for
+ their insightful comments. Thanks as well to all participants for
+ the fruitful discussions on the IETF mailing list.
+
+ The work of Luigi Iannone has been partially supported by the
+ ANR-13-INFR-0009 LISP-Lab Project <www.lisp-lab.org> and the EIT KIC
+ ICT-Labs SOFNETS Project.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iannone, et al. Experimental [Page 11]
+
+RFC 7954 LISP EID Block September 2016
+
+
+Authors' Addresses
+
+ Luigi Iannone
+ Telecom ParisTech
+
+ Email: ggx@gigix.net
+
+
+ Darrel Lewis
+ Cisco Systems, Inc.
+
+ Email: darlewis@cisco.com
+
+
+ David Meyer
+ Brocade
+
+ Email: dmm@1-4-5.net
+
+
+ Vince Fuller
+
+ Email: vaf@vaf.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Iannone, et al. Experimental [Page 12]
+