Internet Engineering Task Force S. Alvarez
Internet-Draft K. Raza
Intended status: Standards Track S. Boutros
Expires: January 12, 2014 Cisco Systems, Inc.
July 11, 2013

Signaling Color Label Switched Paths Using LDP
draft-alvarez-mpls-ldp-color-lsp-00

Abstract

This document describes extensions to the Label Distribution Protocol (LDP) to signal a switching preference in the presence of multiple paths. A label switched router (LSR) can associate locally a color with one or more downstream paths or links, and signal a label path per color to upstream LSRs. Based on local policy, LSRs can select between these color LSPs to implement a forwarding preference on a downstream LSR. An egress LSR may influence the signaling decision of other LSRs by signaling interest in specific colors.

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 January 12, 2014.

Copyright Notice

Copyright (c) 2013 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

The extensions in this document allow LSRs to implement a forwarding preference between different paths available to downstream LSRs. While multiple paths between two LSR may have the same cost from an routing perspective, individual paths may have intrinsic characteristics that an LSR may prefer. As an example, some paths may have a significant difference in terms of latency, reliability, protection, bandwidth or path diversity among other characteristics. An LSR may want to allow upstream LSRs to determine what traffic is forwarded down specific paths.

A sample deployment scenario for color LSPs involves an LDP network using targeted LDP over RSVP-TE LSPs. A given head-end provider (P) device can establish multiple TE LSPs to another tail-end P device. One TE LSP can be engineered for low latency while the other TE LSPs can be engineered for high bandwidth. The head-end P device can associate locally the low-latency TE LSP with one color and the other TE LSPs with a second color. This device can signal two paths (one per color) to upstream LDP peers. With these two paths, a provider edge (PE) device can implement local policies to implement a forwarding preference for low latency or high bandwidth at the downstream P device.

1.1. 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].

2. Applicability of Colors to FEC Elements

A color LSP can be defined for the following types of LDP FEC elements:

and for the following address families:

3. Establishing Color LSPs

Three LSR roles can be involved in establishing a color LSP:

Color LSR:

A transit node with multiple paths towards a destination. It advertises color paths to other upstream LSRs according to a local forwarding association between colors and downstream paths. Advertisement may occur as response to an egress LSR interest in specific color paths.
Ingress LSR:

Selects between color paths associated with a given FEC to influence the forwarding by downstream color LSRs.
Egress LSR:

May signal interest in particular colors towards upstream LSRs in order to influence the signaling behavior of color LSRs.

Figure 1 illustrates an example of a network implemententing a forwarding preference policy for a prefix FEC. In this example, LSRa is an ingress LSR, LSRb is a color LSR and LSRc is an egress LSR. There are three paths (P1, P2 and P3) between LSRb and LSRc. Path P1 and P2 have unique characteristics with respect to p3. LSRb associates P1 and P2 with a color value C1, and P3 with a different color value C2. This color-to-path association is a local decision on LSRb, and colors are globally significant within the LDP domain.

               P1
             ------
            /      \
           /   P2   \
LSRa --- LSRb ---- LSRc
           \        /
            \      /
             ------
               P3
            
            

Example of a color LSP scenario

Figure 1

LSRb signals two color LSPs towards LSRa in response to LSRc interest in color LSPs. LSRc advertises a label for a prefix for which it is an egress LSR. The advertisement includes a label mapping for the prefix and a list of colors (C1 and C2) in which LSRc is interested. LSRb matches the colors in the local color-path association with the color list that LSRc advertised. After finding a match for both C1 and C2, LSRb signals labels for two paths towards LSRa with colors C1 and C2. In addition, it programs an MPLS forwarding entry that associates color C1 with P1 and P2 as next hops, and color label C2 with P3 as next hop for the prefix advertised by LSRc. Ultimately, LSRa receives two label mappings for the prefix, one associated with C1 and the second one associated with C2.

LSRa can make a local decision to forward traffic towards LSRc using the LSP with color C1 (via paths P1 and P2) or the LSP with color C2 (via P3). While both color paths overlap between LSRa and LSRb, the latter differentiates the forwarding of color labels towards LSRc per its local policy.

LSRb may implement different policies for the signaling of color LSPs. In the scenario above, LSRb can be provisioned to advertise color labels for C1 and and C2 without requiring explicit indication from LSRc of interest in those two colors. Such configuration may be desirable for interoperability with legacy egress LSRs that cannot signal a color interest. It may also be desirable in deployment scenarios where color LSPs should be signaled for all egress LSRs and there is no need to provide control for individual egress LSRs.

4. LDP Color LSP Capability

This new capability parameter allows an LSR to advertise its ability to signal a color LSP for a given FEC type (Section 2). The capability follows the format and procedures defined in [RFC5561] and may be signaled in LDP Initialization or Capability messages.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Color LSP Capability(IANA)|            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|  Reserved   |                                               |
+-+-+-+-+-+-+-+-+                                               |
~                   Color LSP Capability Data                   ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           
           

"Color LSP Capability" TLV

Figure 2

U/F-bits:

MUST be set to 1 and 0 respectively so that a receiver silently ignores this TLV if unknown, continues processing the rest of the message and does not forward the TLV if unknown.
Length:

The length (in octets) of the TLV following this length field. The value of this field is variable and is dependent on capability-specific data.
S-bit:

Set to 1 or 0 to advertise or withdraw the capability respectively as specified in [RFC5561].
Reserved:

Must be set to zero on transmission and ignored on receipt
Color LSP Capability Data:

This is capability-specific data that is defined for Color LSPs. It consists of a Typed Wildcard FEC Element [RFC5918] identifying the FEC for which this capability is being signaled. In the context of this document, the Typed Wildcard FEC element MUST correspond to one of the FEC types applicable to Color LSP as defined in Section 2. If a receiver receives this TLV with a Typed Wildcard FEC of type other than those defined in Section 2, it SHOULD silently discard the TLV and continue processing rest of the message.

In order to announce or withdraw this capability for more than one type of FEC elements, an LDP speaker MUST announce/withdraw them separately using the same "Color LSP Capability" TLV. A receiver MUST keep record of the color LSP capabilities of its peer on per-FEC basis.

For example, consider an LSR that supports color LSPs for both IPv4 Prefixes and IPv6 Prefixes. The LSR will announce these capabilities in different Capability TLVs (either as part of the same LDP Initialization/Capability message or separate message) by setting the TLV S-bit to 1 and capability data to Typed Wildcard IPv4 Prefix FEC and Typed Wildcard IPv6 Prefix FEC (as defined in [RFC5918]). The receiver will keep track of the LSR capability and note it to be Color LSP capable for IPv4-Prefix and IPv6-Prefix FEC types. Later, if the LSR withdraws its capability for one of these FEC elements, it will send a Capability TLV (in a Capability message) with S-bit set to 0 and FEC's Typed Wildcard as the capability data. On receipt of this message, the peer will update accordingly to remove the corresponding FEC from LSR's color LSP capability list.

5. Color Lists

5.1. Color List TLV

The Color List TLV is a new optional parameter in the LDP Label Mapping and Label Request messages[RFC5036]. The list includes one or more color identifiers that LSRs may use to signal interest in a forwarding preference.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|     Color List (IANA)    |            Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Color Ids                             |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             
             

"Color List" TLV

Figure 3

U/F-bits:

MUST be set to 1 and 1 respectively so that a receiver silently ignores this TLV if unknown, continues processing the rest of the message and forwards the TLV.
Length:

The length (in octets) of the TLV following this length field. The value of this field is variable and is dependent on number of Color Ids that follow in the TLV.
Color Ids:

List of color identifiers associated with the FEC encoded in the message.

A Color Id is a two octet field defined as follows:

 0                   1          
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Color Id            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             

"Color identifier" field

Figure 4

Color Id:

(non-zero) unsigned color identifier. Color Id 0xFFFF refers to the "wildcard color" (i.e. all colors).

5.2. Procedures

An egress LSR MAY include the Color List TLV in a Label Mapping Message if using Downstream Unsolicited mode. An LSR may include the TLV in Label Request Messages if using Downstream on Demand mode. An LSR MUST NOT include this TLV in any other LDP message except the Label Mapping and Label Request messages. LSRs SHOULD silently discard this TLV if received in other messages and continue processing the rest of the message. A Color List TLV MUST only be used in downstream signaled paths.

An LSR MAY include a Color List TLV List TLV whether the neighbor has previously advertised the LDP Color LSP Capability (Section 4) or not. The TLV MUST be forwarded to other neighbors as defined by the U/F flags. This behavior allows LSRs that do not support the Color LSP extensions to not preclude the signaling of Color LSPs if they are downstream from a Color LSR.

On receipt of a Color List TLV, a Color LSR with multiple downstream paths SHOULD match the list of color identifiers with its local association between forwarding paths and colors. At least one path MUST be defined as the "default" path. This path SHOULD be used as a second best match in the absence of an exact color match. If the Color LSR does not have an association between colors and paths or is a legacy LSR not supporting the Color LSP extensions, all paths SHOULD be treated as default paths.

6. Color Address Families

To setup LSPs corresponding to FECs under a given color scope, the applicable LDP FEC elements (Section 2) must be extended to include the color information. The Color Id becomes an attribute of such LDP FEC elements, and all FEC-Label binding operations are performed under the context of the given color.

To be able to associate a color with a FEC, we define new "color" address families as follows:

  • Color IP (version 4)
  • Color IPv6

These address families just extend the format of their base address family by including color information. The format of data associated with these new address families is described later in sections Section 6.1 and Section 6.2. The proposed new address families can be used in any LDP message and procedures defined for Color LSPs. If a receiver does not support these address families received in a message, it SHOULD send "Unknown Address Family" notification back to the sender and discard the message.

6.1. Color IP Address Family

The format of data associated with Color IP (version 4) address family is:

 0                   1                   2                   3	
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
|                            Prefix                             |	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
|           Color Id           |           Reserved             |	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
             
             

"Color IP (version 4)" Address Family Format

Figure 5

Prefix:

IPv4 prefix for "Color IP (version 4)" address family
Color Id:

Color identifiers associated with IP (version 4) address

The address length for Color IP address family is 8 octets.

6.2. Color IPv6 Address Family

The format of data associated with Color IPv6 address family is:

 0                   1                   2                   3	
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
|                                                               |
|                            Prefix                             |	
|                                                               |        
|                                                               |        
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
|           Color Id           |           Reserved             |	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
             
             

"Color IPv6" Address Family Format

Figure 6

Prefix:

IPv6 prefix for "Color IPv6" address family
Color Id:

Color identifiers associated with IPv6 address

The address length for Color IP address family is 20 octets.

7. Color FECs

The following subsection defines the format of the LDP Color FEC elements (Section 2) as well as their Typed wildcard [RFC5918] counterparts.

7.1. Color Prefix FEC Element

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Prefix (2)   |    AF (Color IP/Color IPv6)   |     PreLen    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                             Prefix                            ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Color Id            |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             

"Color Prefix" FEC element

Figure 7

The definition of these fields follows Section 6 and [RFC5036]. The Prefix field can be either an IP (version 4) or an IPv6 address.

7.2. Color Multipoint FEC Elements

EDITOR NOTE: To be included in a later version.

7.3. Procedures

EDITOR NOTE: To be included in a later version.

8. Other FEC-based Features

8.1. Typed Wildcard Forward Equivalence Class

[RFC5918] extends base LDP and defines Typed Wildcard FEC Element framework. Typed Wildcard FEC element can be used in any LDP message to specify a wildcard operation for the given type of FEC. The Color LSP extensions proposed in this document do not require any extension in the procedures for Typed Wildcard FEC Element support in [RFC5918].

 0                   1                   2                   3	
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
|Typed Wcard (5)|  FEC Type (2) |   Len = 6     | AF=Color IP ..|	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
|. or Color IPv6|           Color Id            |	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             

The encoding for a Color Prefix Typed Wildcard FEC element is as follows:

"Color Prefix Typed Wildcard" FEC element

Figure 8

The definition of these fields follows [RFC5918] and Section 5.1.

The Color Prefix Typed Wildcard FEC allows an LSR to perform wildcard FEC operations under the scope of a specific color. For example, upon local configuration of color LSP feature for a color C, an LSR may send a wildcard label request with Color Id C to learn all its labels from the peer under the scope of that color. If an LSR wishes to perform a wildcard operation that applies to all colors, it can use the "wildcard color" Color Id.

8.2. Signaling Convergence (End-of-LIB)

[RFC5919] specifies extensions and procedures that allows an LDP speaker to signal its convergence for a given FEC type towards a peer using the corresponding Typed Wildcard FEC element. Color LSP extensions for FECs do not require any change in these procedures and they apply as-is to these extended FEC elements. For instance, an LDP speaker MAY signal its LIB convergence per color (or for all colors) using a Color Prefix Typed Wildcard FEC element.

8.3. LSP Ping Extensions

8.3.1. Color Prefix FEC

[RFC4379] defines procedures to detect MPLS LSP data-plane failures via LSP ping. The section 3.2 of [RFC4379] defines Sub-Types and formats for Sub-TLVs corresponding to FECs. For "Prefix" FEC, it defines "LDP IPv4 prefix" and "LDP IPv6 prefix" sub-types and TLVs. To support LSP ping for Color LDP LSPs, this document proposes following extensions to [RFC4379]:

  • New FEC types: Color LDP IPv4 FEC, and Color LDP IPv6 FEC
  • New sub-types: for sub-TLVs to specify these FECs in the "Target FEC Stack" TLV of [RFC4379]

Sub-Type       Length              Value Field	
--------       ------          --------------------	
  TBA1            5            Color LDP IPv4 prefix	
  TBA2           17            Color LDP IPv6 prefix
               
               

The format of these new FEC types is defined as an extension to the format of LDP IPv4 prefix and LDP IPv6 prefix sub-TLV by adding color information.

 0                   1                   2                   3	
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
|Type=Color LDP IPv4 FEC (TBA1) |          Length = 8           |	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
|                          IPv4 prefix                          |	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
| Prefix Length |      MBZ      |           Color Id            |	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             
               

The encoding for a Color LDP IP (version 4) and IPv6 FEC sub-TLVs is as follows:

"Color LDP IP (version 4)" FEC sub-TLV for LSP ping

Figure 9

 0                   1                   2                   3	
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
|Type=Color LDP IPv6 FEC (TBA2) |          Length = 20          |	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
|                                                               |	
|                          IPv6 prefix                          |	
|                                                               |	
|                                                               |	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
| Prefix Length |      MBZ      |          Color Id             |	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	
               
               

"Color LDP IPv6" FEC sub-TLV for LSP ping

Figure 10

8.3.2. Color Multipoint FEC

EDITOR NOTE: To be included in a later version.

9. IANA Considerations

This document defines the following new LDP extensions:

Sub-Type           Value Field	
--------       ------          --------------------	
  TBA1            5            Color LDP IPv4 prefix	
  TBA2           17            Color LDP IPv6 prefix
               
               

  • "Color LSP Capability" (codepoint to be allocated from LDP registry "TLV Type Name Space")
  • Color List TLV (codepoint to be allocated from LDP registry "TLV Type Name Space")
  • Color Address Families (from registry "Address Familiy Numbers")
    • Color IP (version 4)
    • Color IPv6

  • New Sub-TLV Types under TLV type 1 (Target FEC Stack) from "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, and "TLVs and sub-TLVs" sub-registry.

IANA is requested to assign the LDP capability code point and the type values of these TLVs.

10. Security Considerations

The MPLS security framework [RFC5920] and the security considerations in the LDP specification [RFC5036] apply to this document.

11. References

11.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC5036] Andersson, L., Minei, I. and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R. and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5918] Asati, R., Minei, I. and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, August 2010.
[RFC5919] Asati, R., Mohapatra, P., Chen, E. and B. Thomas, "Signaling LDP Label Advertisement Completion", RFC 5919, August 2010.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K. and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011.

11.2. Informative References

[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.

Authors' Addresses

Santiago Alvarez Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: saalvare@cisco.com
Kamran Raza Cisco Systems, Inc. 2000 Innovation Drive Kanata, ON K2K-3E8 Canada EMail: skraza@cisco.com
Sami Boutros Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: sboutros@cisco.com