Circuit Style Segment Routing Policies
draft-schmutzer-pce-cs-sr-policy-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Christian Schmutzer , Clarence Filsfils , Zafar Ali , Francois Clad | ||
| Last updated | 2021-09-30 | ||
| Replaced by | draft-schmutzer-spring-cs-sr-policy | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-schmutzer-pce-cs-sr-policy-00
Network Working Group C. Schmutzer, Ed.
Internet-Draft C. Filsfils
Intended status: Informational Z. Ali, Ed.
Expires: 3 April 2022 F. Clad
Cisco Systems, Inc.
30 September 2021
Circuit Style Segment Routing Policies
draft-schmutzer-pce-cs-sr-policy-00
Abstract
This document describes how Segment Routing (SR) policies can be used
to satisfy the requirements for strict bandwidth guarantees, end-to-
end recovery and persistent paths within a segment routing network.
SR policies satisfying these requirements are called "circuit-style"
SR policies (CS-SR policies).
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 https://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 3 April 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Schmutzer, et al. Expires 3 April 2022 [Page 1]
Internet-Draft cs-srte September 2021
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements of CS-SR Policies . . . . . . . . . . . . . . . 3
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4
5. PCE Topology . . . . . . . . . . . . . . . . . . . . . . . . 4
6. CS-SR Policy Characteristics . . . . . . . . . . . . . . . . 5
7. CS-SR Policy Creation . . . . . . . . . . . . . . . . . . . . 5
8. Operations, Administration, and Maintenance (OAM) . . . . . . 6
8.1. Liveness . . . . . . . . . . . . . . . . . . . . . . . . 6
8.2. Performance Measurement . . . . . . . . . . . . . . . . . 7
9. Recovery Schemes . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Unprotected . . . . . . . . . . . . . . . . . . . . . . . 7
9.2. 1:1 Protection . . . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
14.1. Normative References . . . . . . . . . . . . . . . . . . 9
14.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
There are several applications that require strict bandwidth
guarantees, end-to-end recovery and persistent paths through the
network. Such a "transport centric" behavior is referred to as
"circuit-style" in this document.
This document describes how SR policies
[I-D.ietf-spring-segment-routing-policy] and adjacency-SIDs defined
in the SR architecture [RFC8402] together with a stateful Path
Computation Element (PCE) [RFC8231] can be used to statisfy those
requirements. It includes how end-to-end recovery and path integrity
monitoring can be implemented.
Schmutzer, et al. Expires 3 April 2022 [Page 2]
Internet-Draft cs-srte September 2021
SR policies that satisy those requirements are called "circuit-style"
SR policies (CS-SR policies).
2. Terminology
* CS-SR : Circuit-Style Segment Routing
* ID : Identifier
* LSP : Label Switched Path
* LSPA : LSP attributes
* OAM : Operations, Administration and Maintenance
* OF : Objective Function
* PCE : Path Computation Element
* PCEP : Path Computation Element Communication Protocol
* PT : Protection Type
* SID : Segment Identifier
* SLA : Service Level Agreement
* SR : Segment Routing
* STAMP : Simple Two-Way Active Measurement Protocol
* TI-LFA : Topology Independent Loop Free Alternate
* TLV : Type Length Value
3. Requirements of CS-SR Policies
The requirements of circuit-style SR policies (CS-SR policies) are as
follows:
* Persistent end2end traffic engineered paths that provide
predictable and identical latency in both directions
* Strict bandwidth commitment per path to ensure no impact on the
Service Level Agreement (SLA) due to changing network load from
other services
Schmutzer, et al. Expires 3 April 2022 [Page 3]
Internet-Draft cs-srte September 2021
* End2end protection (<50msec protection switching) and restoration
mechanisms
* Monitoring and maintenance of path integrity
* Data plane remains up while control plane is down
4. Architecture Overview
CS-SR policies are following the segment routing architecture
[RFC8402] and SR policy architecture
[I-D.ietf-spring-segment-routing-policy].
By nature of CS-SR policies, paths wil be computed and maintained by
a stateful PCE defined in [RFC8231]. When using a MPLS data plane
[RFC8660], PCEP extensions defined in [RFC8664] will be used. When
using a SRv6 data plane [RFC8754], PCEP extensions defined in
[I-D.ietf-pce-segment-routing-ipv6] will be used.
A simplified architecture is shown in Figure 1.
+--------------+
+-------------->| PCE |<--------------+
| +--------------+ |
| |
| |
v <<<<<<<<<<<<<< CS-SR Policy >>>>>>>>>>>>> v
+-------+ +-------+
| |=========================================>| |
| A | SR-policy from A to Z | Z |
| |<=========================================| |
+-------+ SR-policy from Z to A +-------+
Figure 1: Circuit-style SR Policy Architecture
5. PCE Topology
In order to satisfy the requirements of CS-SR policies, each link in
the topology MUST have: * An adjacency-SID which is: * Manually
allocated or persistent : to ensure that its value does not change
after a node reload * Non-protected : to avoid any local TI-LFA
protection to happen upon interface/link failures * The bandwidth
available for CS-SR policies
Schmutzer, et al. Expires 3 April 2022 [Page 4]
Internet-Draft cs-srte September 2021
Existing IGP extensions defined in [RFC8667] and [RFC8665] can be
used to distribute the topology information including those
persistent and unprotected Adj-SIDs when using a MPLS dataplane
[RFC8660]. When using a SRv6 dataplane [RFC8754] the IGP extensions
defined in [I-D.ietf-lsr-isis-srv6-extensions] and
[I-D.ietf-lsr-ospfv3-srv6-extensions] apply.
6. CS-SR Policy Characteristics
A CS-SR policy had the following characteristics:
* Requested bandwidth : bandwidth to be reserved for the CS-SR
policy
* Bidirectional co-routed : a CS-SR policy between A and Z is an
association of an SR-Policy from A to Z and an SR-Policy from Z to
A following the same path(s)
* Not automatically recomputed or reoptimized : the SID list of a
candidate path must not change automatically (for example upon
topology change)
* Multiple candiate paths in case of protection/restoration:
- Following the SR policy architecture, the highest preference
valid path is carrying traffic
- Depending on the protection/restoration scheme (Section 9) ,
lower priority candidate paths
o may be pre-computed
o may be pre-programmed
o may have to be disjoint
* Liveness and performance measurement is activated on each
candidate path (Section 8)
7. CS-SR Policy Creation
A CS-SR policy between A and Z is configured both on A (with Z as
endpoint) and Z (with A as endpoint) as shown in Figure 1.
Schmutzer, et al. Expires 3 April 2022 [Page 5]
Internet-Draft cs-srte September 2021
Both nodes A and Z act as PCC and delegate path computation to the
PCE using the extensions defined in [RFC8664]. Considering a CS-SR
policy that has no protection/restoration requirement, the PCRpt
message sent from the headends to the PCE contains the following
parameters:
* BANDWIDTH object (Section 7.7 of [RFC5440]) : to indicate the
requested bandwidth
* LSPA object (section 7.11 of [RFC5440]) : to indicate the local
protection requirements
- L flag set to 0 : no local protection
- E flag set to 1 : protection enforcement (section 5 of
[I-D.ietf-pce-local-protection-enforcement])
* ASSOCIATION object ([RFC8697]) :
- Type : Double-sided Bidirectional with Reverse LSP Association
([I-D.ietf-pce-sr-bidir-path])
- Bidirectional Association Group TLV ([RFC9059]) :
o R flag is always set to 0 (forward path)
o C flag is always set to 1 (co-routed)
If the SR-policies are configured with more than one candiate path, a
PCEP request is sent per candidate path. Each PCEP request does
include the "SR Policy Association" object (type 6) as defined in
[I-D.ietf-pce-segment-routing-policy-cp] to make the PCE aware of the
candidate path belonging to the same policy.
8. Operations, Administration, and Maintenance (OAM)
8.1. Liveness
The proper operation of each segment list is validated by both
headends using STAMP in loopback measurement mode as described in
section 4.2.3 of [I-D.ietf-spring-stamp-srpm].
As the STAMP test packets are including both the segment list of the
forward and reverse path, standard segment routing dataplane
operations will make those packets get switched along the forward
path to the tailend and along the reverse path back to the headend.
Schmutzer, et al. Expires 3 April 2022 [Page 6]
Internet-Draft cs-srte September 2021
The headend forms the bidirectional SR Policy association using the
procedure described in [I-D.ietf-pce-sr-bidir-path] and receives the
information about the reverse segment list from the PCE as described
in section 4.5 of [I-D.ietf-pce-multipath]
8.2. Performance Measurement
The same STAMP session used for liveliness monitoring can be used to
measure delay. As loopback mode is used only round-trip delay is
measured and one-way has to be derived by dividing the round-trip
delay by two.
The same STAMP session can also be used to estimate round-trip loss
as described in section 5 of [I-D.ietf-spring-stamp-srpm].
9. Recovery Schemes
Various protection and restoration schemes can be implemented. The
terms "protection" and "restoration" are used with same subtle
distinctions outlined in section 1 of [RFC4872], [RFC4427] and
[RFC3386] respectively.
* Protection : another candidate path is computed and fully
established in the data plane and ready to carry traffic
* Restoration : a candidate path may be computed and may be
partially established but is not ready to carry traffic
When protection and/or restoration is required the SR polices are
configured with two or more candidate paths. The PCRpt messages
include the "Path Protection Association" object (type 1) defined in
[RFC8745].
9.1. Unprotected
In the most basic scenario no protection nor restoration is required.
The SR-policy only has one candidate path configured.
In case of a failure the CS-SR policy will go down and traffic will
not be recovered.
9.2. 1:1 Protection
For fast recovery against failures a second candidate with a lower
preference is configured. Its path is pre-computed and pre-
programmed so that upon detection of a failure traffic can be
immediately directed to this alternate path by the headend.
Schmutzer, et al. Expires 3 April 2022 [Page 7]
Internet-Draft cs-srte September 2021
For the highest preference candidate path the parameters of the "Path
Protection Association TLV" defined in [RFC8745] are set as follows:
* Protection Type (PT) is set to 0x04 to indicate "1:N Protection
with Extra-Traffic" as defined in section 14.1 of [RFC4872]
* P bit is set to 0 to indicate this is the "working" path
* S bit is set to 0 but will be ignored
For the lower preference candidate path the parameters are as
follows:
* Protection Type (PT) is set to 0x04 to indicate "1:N Protection
with Extra-Traffic"
* P is set to 1 to indicate this is the "protect" path
* S bit set to 0 to indicate "primary"
Appropriate routing of the protect path diverse from the working path
can be requested from the PCE by using the "Disjointness Association"
object (type 2) defined in [RFC8800] in the PCRpt messages. The
disjoint requirements are communicated in the "DISJOINTNESS-
CONFIGURATION TLV"
* L bit set to 1 for link diversity
* N bit set to 1 for node diversity
* S bit set to 1 for SRLG diversity
* T bit set to enforce strict diversity
The P bit may be set for first candidate path to allow for finding
the best working path that does satisfy all constraints without
considering diversity to the protect path.
The "Objective Function (OF) TLV" as defined in section 5.3 of
[RFC8800] may also be added to minimize the common shared resources.
As described in Section 8.1, both headends will generate and receive
their own loopback mode test packets, hence even a unidirectional
failure will always be detected by both headends and therefore no
protection switch coordination is required.
Schmutzer, et al. Expires 3 April 2022 [Page 8]
Internet-Draft cs-srte September 2021
10. Security Considerations
TO BE ADDED
11. IANA Considerations
This document has no IANA actions.
12. Acknowledgements
The author's want to thank Samuel Sidor, Mike Koldychev, Rakesh
Gandhi for providing their review comments.
13. Contributors
Contributors' Addresses
Brent Foster
Cisco Systems, Inc.
Email: brfoster@cisco.com
Bertrand Duvivier
Cisco System, Inc.
Email: bduvivie@cisco.com
Stephane Litkowski
Cisco Systems, Inc.
Email: slitkows@cisco.com
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
14.2. Informative References
[I-D.ietf-lsr-isis-srv6-extensions]
Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
Z. Hu, "IS-IS Extensions to Support Segment Routing over
IPv6 Dataplane", Work in Progress, Internet-Draft, draft-
ietf-lsr-isis-srv6-extensions-17, 18 June 2021,
<https://www.ietf.org/archive/id/draft-ietf-lsr-isis-srv6-
extensions-17.txt>.
Schmutzer, et al. Expires 3 April 2022 [Page 9]
Internet-Draft cs-srte September 2021
[I-D.ietf-lsr-ospfv3-srv6-extensions]
Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak,
"OSPFv3 Extensions for SRv6", Work in Progress, Internet-
Draft, draft-ietf-lsr-ospfv3-srv6-extensions-02, 15
February 2021, <https://www.ietf.org/archive/id/draft-
ietf-lsr-ospfv3-srv6-extensions-02.txt>.
[I-D.ietf-pce-local-protection-enforcement]
Stone, A., Aissaoui, M., Sidor, S., and S. Sivabalan,
"Local Protection Enforcement in PCEP", Work in Progress,
Internet-Draft, draft-ietf-pce-local-protection-
enforcement-03, 5 August 2021,
<https://www.ietf.org/archive/id/draft-ietf-pce-local-
protection-enforcement-03.txt>.
[I-D.ietf-pce-multipath]
Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P.,
Bidgoli, H., Yadav, B., and S. Peng, "PCEP Extensions for
Signaling Multipath Information", Work in Progress,
Internet-Draft, draft-ietf-pce-multipath-01, 27 July 2021,
<https://www.ietf.org/archive/id/draft-ietf-pce-multipath-
01.txt>.
[I-D.ietf-pce-segment-routing-ipv6]
Li, C., Negi, M., Sivabalan, S., Koldychev, M.,
Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment
Routing leveraging the IPv6 data plane", Work in Progress,
Internet-Draft, draft-ietf-pce-segment-routing-ipv6-09, 27
May 2021, <https://www.ietf.org/internet-drafts/draft-
ietf-pce-segment-routing-ipv6-09.txt>.
[I-D.ietf-pce-segment-routing-policy-cp]
Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H.
Bidgoli, "PCEP extension to support Segment Routing Policy
Candidate Paths", Work in Progress, Internet-Draft, draft-
ietf-pce-segment-routing-policy-cp-05, 23 May 2021,
<https://www.ietf.org/archive/id/draft-ietf-pce-segment-
routing-policy-cp-05.txt>.
[I-D.ietf-pce-sr-bidir-path]
Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong,
"Path Computation Element Communication Protocol (PCEP)
Extensions for Associated Bidirectional Segment Routing
(SR) Paths", Work in Progress, Internet-Draft, draft-ietf-
pce-sr-bidir-path-08, 9 September 2021,
<https://www.ietf.org/archive/id/draft-ietf-pce-sr-bidir-
path-08.txt>.
Schmutzer, et al. Expires 3 April 2022 [Page 10]
Internet-Draft cs-srte September 2021
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", Work in
Progress, Internet-Draft, draft-ietf-spring-segment-
routing-policy-13, 28 May 2021,
<https://www.ietf.org/archive/id/draft-ietf-spring-
segment-routing-policy-13.txt>.
[I-D.ietf-spring-stamp-srpm]
Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens,
B., and R. Foote, "Performance Measurement Using Simple
TWAMP (STAMP) for Segment Routing Networks", Work in
Progress, Internet-Draft, draft-ietf-spring-stamp-srpm-02,
13 September 2021, <https://www.ietf.org/archive/id/draft-
ietf-spring-stamp-srpm-02.txt>.
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925,
DOI 10.17487/RFC1925, April 1996,
<https://www.rfc-editor.org/info/rfc1925>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3386] Lai, W., Ed. and D. McDysan, Ed., "Network Hierarchy and
Multilayer Survivability", RFC 3386, DOI 10.17487/RFC3386,
November 2002, <https://www.rfc-editor.org/info/rfc3386>.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427,
DOI 10.17487/RFC4427, March 2006,
<https://www.rfc-editor.org/info/rfc4427>.
[RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
<https://www.rfc-editor.org/info/rfc4872>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
Schmutzer, et al. Expires 3 April 2022 [Page 11]
Internet-Draft cs-srte September 2021
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>.
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", RFC 8665,
DOI 10.17487/RFC8665, December 2019,
<https://www.rfc-editor.org/info/rfc8665>.
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
Extensions for Segment Routing", RFC 8667,
DOI 10.17487/RFC8667, December 2019,
<https://www.rfc-editor.org/info/rfc8667>.
[RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "Path Computation Element
Communication Protocol (PCEP) Extensions for Establishing
Relationships between Sets of Label Switched Paths
(LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
<https://www.rfc-editor.org/info/rfc8697>.
[RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I.,
and M. Negi, "Path Computation Element Communication
Protocol (PCEP) Extensions for Associating Working and
Protection Label Switched Paths (LSPs) with Stateful PCE",
RFC 8745, DOI 10.17487/RFC8745, March 2020,
<https://www.rfc-editor.org/info/rfc8745>.
Schmutzer, et al. Expires 3 April 2022 [Page 12]
Internet-Draft cs-srte September 2021
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8800] Litkowski, S., Sivabalan, S., Barth, C., and M. Negi,
"Path Computation Element Communication Protocol (PCEP)
Extension for Label Switched Path (LSP) Diversity
Constraint Signaling", RFC 8800, DOI 10.17487/RFC8800,
July 2020, <https://www.rfc-editor.org/info/rfc8800>.
[RFC9059] Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation
Element Communication Protocol (PCEP) Extensions for
Associated Bidirectional Label Switched Paths (LSPs)",
RFC 9059, DOI 10.17487/RFC9059, June 2021,
<https://www.rfc-editor.org/info/rfc9059>.
Authors' Addresses
Christian Schmutzer (editor)
Cisco Systems, Inc.
Email: cschmutz@cisco.com
Clarence Filsfils
Cisco Systems, Inc.
Email: cfilsfil@cisco.com
Zafar Ali (editor)
Cisco Systems, Inc.
Email: zali@cisco.com
Francois Clad
Cisco Systems, Inc.
Email: fclad@cisco.com
Schmutzer, et al. Expires 3 April 2022 [Page 13]