Internet DRAFT - draft-ray-idr-route-constrain-scope

draft-ray-idr-route-constrain-scope



Inter-Domain Routing                                              S. Ray
Internet-Draft                                            A. Sreekantiah
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: August 18, 2014                               February 14, 2014


      Signaling AFI-SAFI scope for Constrained Route Distribution
                 draft-ray-idr-route-constrain-scope-00

Abstract

   The Route Constrain address family can be used by a BGP speaker to
   signal a neighbor its interest in receiving only the routes with a
   matching route target (RT) extended community.  This signaling is
   afi-safi agnostic; the sender of a route constrain NLRI with an RT
   expresses its interest in receiving routes with that RT for all afi-
   safi.  The ability to further scope a given RT to a list of afi-safi
   would simplify network operations; then optimal route filtering would
   no longer require that the set of RTs used for different afi-safi be
   disjoint.

   This document proposes a simple extended community based backward
   compatible method to associate the list of afi-safi of interest to a
   route constrain NLRI and discusses the operational procedure.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 August 18, 2014.




Ray & Sreekantiah        Expires August 18, 2014                [Page 1]

Internet-Draft Signaling AFI-SAFI scope with RT Constrain  February 2014


Copyright Notice

   Copyright (c) 2014 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Sub-optimality of route constrain in shared RT
           deployments . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.1.  Unused route advertisement and retention  . . . . . .   3
       1.1.2.  Need for route-refresh on some configuration changes    4
     1.2.  Solutions . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.1.  Use of disjoint set of RTs  . . . . . . . . . . . . .   5
       1.2.2.  New route constrain NLRI  . . . . . . . . . . . . . .   5
       1.2.3.  Using BGP Path Attribute  . . . . . . . . . . . . . .   5
   2.  AFI-SAFI Extended Community . . . . . . . . . . . . . . . . .   6
   3.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   5.  Manageability Considerations  . . . . . . . . . . . . . . . .  10
     5.1.  Configuration Management  . . . . . . . . . . . . . . . .  10
     5.2.  Operational Considerations  . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   A VPN route (such as VPNv4/VPNv6 unicast [RFC4364], Multicast VPN
   [RFC6513], Layer 2 VPN [RFC6624], Flow-spec [RFC5575], etc.) is
   retained by a BGP speaker only if the route is of interest to itself
   - e.g., if the route belongs to a local VPN, or if it needs to be
   sent to one of its neighbors.  The VPN membership of a route is
   determined by the set of route target (RT) extended communities
   attached to the route.  Therefore the speaker's neighbors need to



Ray & Sreekantiah        Expires August 18, 2014                [Page 2]

Internet-Draft Signaling AFI-SAFI scope with RT Constrain  February 2014


   send only those routes to the speaker that carry one or more RTs that
   are of interest to the speaker.

   [RFC4684] defines a new address family called Route Target Constrain
   (RTC) using which a BGP speaker can signal its neighbors the set of
   RTs it is interested in.  For instance, if one of speaker A's locally
   configured VPNs is a member of RT:1:1 (i.e., if a local VRF imports
   RT:1:1), then speaker A advertises an RTC NLRI with RT:1:1 to speaker
   B. In turn speaker B sends to speaker A only the VPN routes with
   RT:1:1.  [I-D.ietf-idr-bgp-ipv6-rt-constrain] extends the NLRI
   definition to accommodate longer IPv6 Specific Route Target extended
   communities [RFC5701].

   The scope of an RTC NLRI RT:X:Y spans all address family routes with
   RT:X:Y. This design choice makes RTC a standard route filtering
   mechanism for all BGP based VPN solutions.  On the flip side, RTC can
   deliver optimal filtering only when the set of RTs used by an address
   family afi=x/safi=y is disjoint from the set of RTs used by any other
   address family afi=z/safi=w. The following section illustrates some
   of the problems when shared RTs are used.

1.1.  Sub-optimality of route constrain in shared RT deployments

1.1.1.  Unused route advertisement and retention



+-------------+---+                                    +---+-------------+
|IPv4 VRF     |   | RTC:1:1        +---+   RTC:1:1     |   |IPv4 VRF     |
|export RT:1:1|   |<---------------|   | <------------ |   |import RT:1:1|
+-------------| A +----------------+ B +---------------+ C |-------------+
|IPv6 VRF     |   |--------------->|   | ------------> |   |
|export RT:1:1|   | VPNv4 unicast  +---+ VPNv4 unicast |   |
+-------------+---+ VPNv6 unicast        VPNv6 unicast +---+


    Figure 1: Sub-optimality: Unused route advertisement and retention

   Suppose speaker A has local VPNv4 unicast and VPNv6 unicast routes,
   both with membership in RT:1:1.  Speaker B is a route-reflector with
   client speaker C. Speaker C only needs VPNv4 unicast routes with
   RT:1:1 for its VPN with membership in RT:1:1.  Speaker C sends an RTC
   NLRI RT:1:1 to speaker B and speaker B in turn sends an RTC NLRI
   RT:1:1 to speaker A. Spearker A sends its VPNv4 unicast and VPNv6
   unicast routes with RT:1:1 to speaker B. Speaker B retains routes
   from both address families and sends all of them to speaker C.
   Speaker C retains only the VPNv4 unicast routes and drops VPNv6
   unicast routes.



Ray & Sreekantiah        Expires August 18, 2014                [Page 3]

Internet-Draft Signaling AFI-SAFI scope with RT Constrain  February 2014


   In this deployment, advertisement of VPNv6 unicast routes are not
   needed, but they are still advertised.  Second, speaker B (the route-
   reflector) does not need to retain any VPNv6 unicast route since its
   only client, speaker C, does not need them.  But speaker B still
   retains the VPNv6 unicast routes.  Therefore, route constrain does
   not lead to optimal route filtering.

1.1.2.  Need for route-refresh on some configuration changes


             RTC:1:1
+-------------+---+                RTC:1:1             +---+-------------+
|IPv4 VRF     |   |                +---+               |   |IPv4 VRF     |
|export RT:1:1|   |                |   |               |   |import RT:1:1|
+-------------| A +----------------+ B +---------------+ C |-------------+
|IPv6 VRF     |   |                |   |               |   |IPv6 VRF     .
|export RT:1:1|   |                +---+               |   |import RT:1:1.
+-------------+---+              VPNv4 unicast         +---+.............+
                                 VPNv6 unicast        VPNv4 unicast


                  Figure 2: Sub-optimality: Route refresh

   In the deployment shown in Figure 1, in steady state speaker C
   retains the VPNv4 unicast routes for RT:1:1 and speaker B has an RTC
   NLRI path for RT:1:1 from speaker C. Now suppose the operator adds a
   new IPv6 VRF on speaker C that imports RT:1:1 depicted in Figure 2.
   Now speaker C needs to get the VPNv6 unicast routes from speaker B
   with RT:1:1.  At this point, if speaker C advertises the RTC NLRI
   RT:1:1 to speaker B again, speaker B would receive an identical path
   from speaker C. Standard BGP implementation practice is to ignore
   identical updates (i.e., not mark the local prefix for further
   processing), in which case speaker B will not send the VPN routes to
   speaker C again.  Thus, speaker C would need to send a route refresh
   message to speaker B and receive all VPNv6 routes (this set of routes
   is larger than necessary if RT:1:1 is not the first RT imported by an
   IPv6 VRF on speaker C).

   There are possible implementation tricks to get around this issue
   (e.g., readvertise the RTC NLRI RT:1:1 from speaker C after changing
   an attribute such as local-preference).  However, a standardized
   solution without possible side-effects is much more preferable.

1.2.  Solutions







Ray & Sreekantiah        Expires August 18, 2014                [Page 4]

Internet-Draft Signaling AFI-SAFI scope with RT Constrain  February 2014


1.2.1.  Use of disjoint set of RTs

   Not using shared RTs by ensuring that the set of RTs used by one
   address family is disjoint from the set of RTs used by any other
   address family avoids the problems.  However, this constraint poses a
   burden on the network operation, especially in large networks that
   are run by multiple loosely coupled departments, where configurations
   change frequently.  Therefore, a protocol level solution is more
   preferable.

1.2.2.  New route constrain NLRI

   [I-D.dong-idr-vpn-route-constrain] proposes a new NLRI format that
   includes the safi value (among other fields) and use different afi
   values during capability negotiations.  This is not a backward
   compatible solution.  Given many existing (large) deployments of
   [RFC4684] based multi-vendor networks, backward compatibility is
   necessary.  In addition, [I-D.ietf-idr-bgp-ipv6-rt-constrain] solves
   the IPv6 specific RT issue in a backward compatible manner that
   [I-D.dong-idr-vpn-route-constrain] addresses.

1.2.3.  Using BGP Path Attribute

   The list of afi-safi that a speaker needs in the scope for a given RT
   can be carried in the path attribute of the RTC NLRI.  This approach
   does not require any change in the NLRI format as the new information
   is not carried in the NLRI making the approach backward compatible.
   In addition, RTC being a hop-by-hop technique by nature, best path
   selection done on, say, a route-reflector, does not lead to missing
   information.  In this document, we adopt this approach which leads to
   a light-weight, backward compatible solution.  In addition, if the
   policy language supported on the BGP speakers allow attaching
   arbitrary extended communities to a route, then the proposed solution
   can be deployed on edge routers (i.e., on leafs of the VPN
   distribution graph) even without any software upgrade.

   While one could define a new BGP path attribute to carry the list of
   afi-safi as the scope, use of communities suffices for the present
   purpose.  Specifically, we propose using a new type of opaque
   extended community called AFI-SAFI extended community to encode each
   afi-safi pair that is of interest to the speaker and use multiple
   extended communities to form the list.  Extended communities instead
   of standard communities are used since the latter are used widely by
   the providers for communicating internal information.







Ray & Sreekantiah        Expires August 18, 2014                [Page 5]

Internet-Draft Signaling AFI-SAFI scope with RT Constrain  February 2014


2.  AFI-SAFI Extended Community

   The AFI-SAFI Community is an Non-Transitive Opaque Extended Community
   ([RFC4360], [I-D.ietf-idr-extcomm-iana]) defined as follows:

   Type Field:

       The value of the high-order octet of the extended Type Field is
       0x43, which indicates that it is non-transitive.  The value of
       low-order octet of the extended type field for this community is
       TBD.

   Value Field:

       The first 3 octets of the Value field contains two sub-fields,
       described below.  The last 3 octets of the Value field are
       reserved.  The originator of an AFi-SAFI community must set the
       reserved octets to 0, and a receiver of an AFi-SAFI community
       must ignore the reserved octets.


   +--------------------------------------------------+
   | Address Family Identifier (2 octets)             |
   +--------------------------------------------------+
   | Subsequent Address Family Identifier (1 octet)   |
   +--------------------------------------------------+
   | Reserved (3 octets)                              |
   +--------------------------------------------------+


               Figure 3: AFI-SAFI Extended Community Format

   We denote an AFI-SAFI extended community with Address Family
   Identifier field x and Subsequent Address Family Identifier field y
   as AFI-SAFI-EC:(x/y).

   A route carrying AFI-SAFI-EC:(x/y) implies that the route is
   correlated to the address family with index x/y. The route itself may
   belong to a different address family.  The semantics of the
   correlation is context dependent.  This document defines the
   correlation sematics for route constrain routes carrying AFI-SAFI-EC.

3.  Operation

   Suppose BGP speakers A and B have negotiated route constrain
   capability.  Speaker A receives an RTC NLRI RT:X:Y from speaker B
   with set S of AFI-SAFI-EC attached.  We define the following
   semantics:



Ray & Sreekantiah        Expires August 18, 2014                [Page 6]

Internet-Draft Signaling AFI-SAFI scope with RT Constrain  February 2014


   o  If S is empty, then speaker A SHOULD send all otherwise eligible
      routes from all address families to speaker B.

   o  If S is nonempty, then speaker A SHOULD send an otherwise eligible
      AFI=x/SAFI=y route with RT:X:Y to speaker B ONLY if S contains
      AFI-SAFI-EC:(x/y).

   o  Suppose speaker A has RTC route RT:X:Y with path i with AFI-SAFI-
      EC set S_i, for i=1..n.

      *  If all S_i are nonempty, then speaker A attaches AFI-SAFI-EC
         set S to RTC NLRI RT:X:Y that it advertises to its neighbors,
         where S is the union of S_i, i=1..n.

      *  If there is an empty S_i, then speaker A does not attach any
         AFI-SAFI-EC to RTC NLRI RT:X:Y that it advertises to its
         neighbors.

   The essential idea is to treat an RTC NLRI path with no AFI-SAFI-EC
   attached as a path with AFI-SAFI-EC for all address families
   attached.  We illustrate the rules with a couple of examples shown in
   Figure 4 and Figure 5.





























Ray & Sreekantiah        Expires August 18, 2014                [Page 7]

Internet-Draft Signaling AFI-SAFI scope with RT Constrain  February 2014


                                           RTC:1:1
                                           EC: 2/128    +---+
                                         <------------- |   |
                                       +----------------+ C |
                                       | -------------> |   |
                                       |   VPNv6        +---+
                                       |
                                       |   RTC:1:1
              RTC:1:1                  v   EC: 1/128
   +-------+  (No AFI-SAFI extcomm)  +---+ EC: 2/128    +---+
   | VPNv4 | <---------------------- |   |<------------ |   |
   | VPNv6 +-------------------------+ B +--------------+ D |
   | MVPN  | ----------------------> |   |------------->|   |
   +-------+ VPNv4, VPNv6, MVPN      +---+ VPNv4, VPNv6 +---+
   Router A                            ^
                                       |
                                       |   RTC:1:1
                                       |(No AFI-SAFI EC)+---+
                                       | <------------- |   |
                                       +----------------+ E |
                                         -------------> |   |
                                     VPNv4, VPNv6, MVPN +---+


              Figure 4: Operational rule in asymmetric cases

   In Figure 4, speaker B receives RTC NLRI RT:1:1 from neighbors C, D
   and E. Neighbor C attaches AFI-SAFI-EC:(2/128) and neighbor D
   attaches AFI-SAFI-EC:(1/128) and AFI-SAFI-EC:(2/128).  Neighbor E
   does not attach any AFI-SAFI-EC to its route.

   From the received set of AFI-SAFI-EC, speaker B knows that among all
   the routes with RT:1:1, speaker C needs only VPNv6 unicast routes and
   speaker D needs only VPNv4 unicast and VPNv6 unicast routes.
   However, speaker B does not know which address family routes node E
   needs.  Therefore, speaker B must request routes with RT:1:1 for all
   address families (whose capabilities have been negotiated) from its
   neighbors.  So speaker B advertises RTC NLRI RT:1:1 to speaker A with
   no AFI-SAFI-EC.

   Speaker A has VPNv4 unicast, VPNv6 uncast and MVPN routes with RT:1:1
   that are eligible for sending to speaker B. Speaker A sends all those
   routes to speaker B.

   Speaker B now has VPNv4 unicast, VPNv6 uncast and MVPN routes with
   RT:1:1 that are eligible for sending to neighbors C, D and E. Among
   those routes, speaker B sends only the VPNv6 unicast routes to
   neighbor C, VPNv4 unicast and VPNv6 unicast routes to neighbor D and



Ray & Sreekantiah        Expires August 18, 2014                [Page 8]

Internet-Draft Signaling AFI-SAFI scope with RT Constrain  February 2014


   VPNv4 unicast, VPNv6 unicast and MVPN (i.e., all) routes to neighbor
   E.

   If speaker E actually only needs VPNv4 unicast routes, it would drop
   the VPNv6 unicast and MVPN routes it receives from speaker B for RT
   1:1.  This sub-optimal behavior improves when speaker E also uses
   AFI-SAFI-EC to signal the scope for RT:1:1 and the "island" of
   contiguous AFI-SAFI-EC users expands.


                                           RTC:1:1
                                           EC: 2/128    +---+
                                         <------------- |   |
                                       +----------------+ C |
                                       | -------------> |   |
                                       |   VPNv6        +---+
                                       |
                                       |   RTC:1:1
              RTC:1:1                  v   EC: 1/128
   +-------+  EC: 1/128, EC: 2/128   +---+ EC: 2/128    +---+
   | VPNv4 | <---------------------- |   |<------------ |   |
   | VPNv6 +-------------------------+ B +--------------+ D |
   | MVPN  | ----------------------> |   |------------->|   |
   +-------+ VPNv4, VPNv6            +---+ VPNv4, VPNv6 +---+
   Router A                            ^
                                       |
                                       |   RTC:1:1
                                       |   EC: 1/128    +---+
                                       | <------------- |   |
                                       +----------------+ E |
                                         -------------> |   |
                                          VPNv4         +---+


               Figure 5: Operational rule in symmetric cases

   In Figure 5, speaker B receives RTC NLRI RT:1:1 from neighbors C, D
   and E. Neighbor C attaches AFI-SAFI-EC:(2/128), neighbor D attaches
   AFI-SAFI-EC:(1/128) and AFI-SAFI-EC:(2/128), and neighbor E attaches
   AFI-SAFI-EC:(1/128).

   From the received set of AFI-SAFI-EC, speaker B knows that among all
   routes with RT:1:1, speaker C needs only VPNv6 unicast routes,
   speaker D needs only VPNv4 unicast and VPNv6 unicast routes, and
   speaker E needs only VPNv4 unicast routes.  Speaker B advertises RTC
   NLRI RT:1:1 to speaker A with AFI-SAFI-EC:(1/128) and AFI-SAFI-EC:(2/
   128), which is the union of all AFI-SAFI-EC from all paths of the RTC
   NLRI.



Ray & Sreekantiah        Expires August 18, 2014                [Page 9]

Internet-Draft Signaling AFI-SAFI scope with RT Constrain  February 2014


   Speaker A therefore sends only VPNv4 unicast and VPNv6 unicast routes
   speaker B.

   Among those routes with RT:1:1 that speaker B has, speaker B sends
   only the VPNv6 unicast routes to neighbor C, VPNv4 unicast and VPNv6
   unicast routes to neighbor D and only VPNv4 unicast routes to
   neighbor E. Therefore, when all speakers use AFI-SAFI-EC, optimal
   route filtering is restored even in shared RT deployments.

4.  IANA Considerations

   This document requests assignment of a codepoint from the Non-
   Transitive Opaque Extended Community Sub-Types registry for AFI-SAFI
   extended community.

5.  Manageability Considerations

   This section is structured as recommended in [RFC5706].

5.1.  Configuration Management

   TBD.

5.2.  Operational Considerations

   TBD.

6.  Security Considerations

   Procedures and protocol extensions defined in this document do not
   affect the BGP security model.  See the 'Security Considerations'
   section of [RFC4271] for a discussion of BGP security.  Also refer to
   [RFC4272] and [I-D.ietf-karp-routing-tcp-analysis] for analysis of
   security issues for BGP.

7.  Acknowledgements

   TBD.

8.  References

8.1.  Normative References

   [I-D.ietf-idr-extcomm-iana]
              Rosen, E. and Y. Rekhter, "IANA Registries for BGP
              Extended Communities", draft-ietf-idr-extcomm-iana-02
              (work in progress), December 2013.




Ray & Sreekantiah        Expires August 18, 2014               [Page 10]

Internet-Draft Signaling AFI-SAFI scope with RT Constrain  February 2014


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
              4272, January 2006.

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, February 2006.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

8.2.  Informative References

   [I-D.dong-idr-vpn-route-constrain]
              Li, Z., Dong, J., Ni, H., Chen, M., and G. Liu,
              "Constrained Route Distribution for BGP based Virtual
              Private Networks(VPNs)", draft-dong-idr-vpn-route-
              constrain-02 (work in progress), September 2010.

   [I-D.ietf-idr-bgp-ipv6-rt-constrain]
              Patel, K., Raszuk, R., Djernaes, M., Dong, J., and M.
              Chen, "IPv6 Extensions for Route Target Distribution",
              draft-ietf-idr-bgp-ipv6-rt-constrain-04 (work in
              progress), August 2013.

   [I-D.ietf-karp-routing-tcp-analysis]
              Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
              BGP, LDP, PCEP and MSDP Issues According to KARP Design
              Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in
              progress), April 2013.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

   [RFC4684]  Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
              R., Patel, K., and J. Guichard, "Constrained Route
              Distribution for Border Gateway Protocol/MultiProtocol
              Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
              Private Networks (VPNs)", RFC 4684, November 2006.

   [RFC5575]  Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
              and D. McPherson, "Dissemination of Flow Specification
              Rules", RFC 5575, August 2009.



Ray & Sreekantiah        Expires August 18, 2014               [Page 11]

Internet-Draft Signaling AFI-SAFI scope with RT Constrain  February 2014


   [RFC5701]  Rekhter, Y., "IPv6 Address Specific BGP Extended Community
              Attribute", RFC 5701, November 2009.

   [RFC5706]  Harrington, D., "Guidelines for Considering Operations and
              Management of New Protocols and Protocol Extensions", RFC
              5706, November 2009.

   [RFC6513]  Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
              VPNs", RFC 6513, February 2012.

   [RFC6624]  Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
              Virtual Private Networks Using BGP for Auto-Discovery and
              Signaling", RFC 6624, May 2012.

Authors' Addresses

   Saikat Ray
   Cisco Systems, Inc.
   170, West Tasman Drive
   San Jose, CA  95134
   US

   Email: sairay@cisco.com


   Arjun Sreekantiah
   Cisco Systems, Inc.
   170, West Tasman Drive
   San Jose, CA  95134
   US

   Email: asreekan@cisco.com



















Ray & Sreekantiah        Expires August 18, 2014               [Page 12]