[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02
LSR Shaofu. Peng
Internet-Draft Ran. Chen
Intended status: Standards Track ZTE Corporation
Expires: June 10, 2021 Ketan. Talaulikar
Cisco Systems
December 7, 2020
Algorithm Related IGP-Adjacency SID Advertisement
draft-peng-lsr-algorithm-related-adjacency-sid-02
Abstract
Segment Routing architecture supports the use of multiple routing
algorithms, i.e, different constraint-based shortest-path
calculations can be supported. There are two standard algorithms:
SPF and Strict-SPF, defined in Segment Routing architecture. There
are also other user defined algorithms according to Flex-algo
applicaiton. However, an algorithm identifier is often included as
part of a Prefix-SID advertisement, that maybe not satisfy some
scenarios where multiple algorithm share the same link resource.
This document complement that the algorithm identifier can be also
included as part of a Adjacency-SID advertisement
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 June 10, 2021.
Copyright Notice
Copyright (c) 2020 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
Peng, et al. Expires June 10, 2021 [Page 1]
Internet-Draft algo-related adj-sid December 2020
(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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Adjacency Segment Identifier per Algorithm . . . . . . . . . 3
3.1. ISIS Adjacency Segment Identifier per Algorithm . . . . . 3
3.1.1. ISIS Adjacency Segment Identifier (Adj-SID) per
Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 4
3.1.2. ISIS Adjacency Segment Identifier (LAN-Adj-SID) per
Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 4
3.2. OSPF Adjacency Segment Identifier per Algorithm . . . . . 5
3.2.1. OSPF Adj-SID Sub-TLV . . . . . . . . . . . . . . . . 6
3.2.2. OSPF LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . 6
3.3. OSPFv3 Adjacency Segment Identifier per Algorithm . . . . 7
3.3.1. OSPFv3 Adj-SID Sub-TLV . . . . . . . . . . . . . . . 7
3.3.2. OSPFv3 LAN Adj-SID Sub-TLV . . . . . . . . . . . . . 8
4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Segment Routing architecture [RFC8402] supports the use of multiple
routing algorithms, i.e, different constraint-based shortest-path
calculations can be supported. There are two standard algorithms,
i.e, SPF and Strict-SPF, that defined in Segment Routing
architecture. For SPF, the packet is forwarded along the well known
ECMP-aware Shortest Path First (SPF) algorithm employed by the IGPs.
However, it is explicitly allowed for a midpoint to implement another
forwarding based on local policy. For Strict Shortest Path First
(Strict-SPF), it mandates that the packet be forwarded according to
the ECMP-aware SPF algorithm and instructs any router in the path to
ignore any possible local policy overriding the SPF decision.
There are also other user defined algorithms according to IGP Flex
Algorithm [I-D.ietf-lsr-flex-algo]. IGP Flex Algorithm proposes a
solution that allows IGPs themselves to compute constraint based
Peng, et al. Expires June 10, 2021 [Page 2]
Internet-Draft algo-related adj-sid December 2020
paths over the network, and it also specifies a way of using Segment
Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the
constraint-based paths. It specifies a set of extensions to ISIS,
OSPFv2 and OSPFv3 that enable a router to send TLVs that identify (a)
calculation-type, (b) specify a metric-type, and (c )describe a set
of constraints on the topology, that are to be used to compute the
best paths along the constrained topology. A given combination of
calculation-type, metric-type, and constraints is known as an FAD
(Flexible Algorithm Definition).
However, an algorithm identifier is often included as part of a
Prefix-SID advertisement, that maybe not satisfy some scenarios where
multiple algorithm share the same link resource. For example, an SR-
TE policy may be instantiated within specific Flex-algo plane, i.e.,
the SID list requires to include algorithm related SIDs. An
algorithm-unware Adjacency-SID included in the SID list can just
steer the packet towards the link, but can not apply different QoS
policy for different algorithm. Another example is that the TI-LFA
backup path computed in Flex-algo plane may also contain an
algorithm-unware Adjacency-SID, which maybe also used in other SR-TE
instance that carries other service.
This document complement that the algorithm identifier can be also
included as part of an Adjacency-SID advertisement for SR-MPLS.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Adjacency Segment Identifier per Algorithm
3.1. ISIS Adjacency Segment Identifier per Algorithm
[RFC8667] describes the IS-IS extensions that need to be introduced
for Segment Routing operating on an MPLS data plane. It defined
Adjacency Segment Identifier (Adj-SID) sub-TLV advertised with TLV-
22/222/23/223/141, and Adjacency Segment Identifier (LAN-Adj-SID)
Sub-TLV advetised with TLV-22/222/23/223. Accordingly, this document
defines two new optional Sub-TLVs, "ISIS Adjacency Segment Identifier
(Adj-SID) per Algorithm Sub-TLV" and "ISIS Adjacency Segment
Identifier (LAN-Adj-SID) per Algorithm Sub-TLV".
Peng, et al. Expires June 10, 2021 [Page 3]
Internet-Draft algo-related adj-sid December 2020
3.1.1. ISIS Adjacency Segment Identifier (Adj-SID) per Algorithm Sub-
TLV
ISIS Adjacency Segment Identifier (Adj-SID) per Algorithm Sub-TLV has
the following format:
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 | Length | Flags | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ISIS Adjacency Segment Identifier (Adj-SID) per Algorithm
Format
where:
Type: TBD1.
Length: 6 or 7 depending on size of the SID.
Flags: Refer to Adjacency Segment Identifier (Adj-SID) sub-TLV.
Weight: Refer to Adjacency Segment Identifier (Adj-SID) sub-TLV.
Algorithm: The Algorithm field contains the identifier of the
algorithm the router uses to apply algorithm specific QoS policy
configured on the adjacency.
SID/Label/Index: Refer to Adjacency Segment Identifier (Adj-SID) sub-
TLV.
For a P2P link, an SR-capable router MAY allocate different Adj-SID
for different algorithm, if this link will join different algorithm
related plane.
3.1.2. ISIS Adjacency Segment Identifier (LAN-Adj-SID) per Algorithm
Sub-TLV
ISIS Adjacency Segment Identifier (LAN-Adj-SID) per Algorithm Sub-TLV
has the following format:
Peng, et al. Expires June 10, 2021 [Page 4]
Internet-Draft algo-related adj-sid December 2020
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 | Length | Flags | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor System-ID (ID length octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ISIS Adjacency Segment Identifier (LAN-Adj-SID) per
Algorithm Format
where:
Type: TBD2.
Length: Variable.
Flags: Refer to Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV.
Weight: Refer to Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV.
Algorithm: The Algorithm field contains the identifier of the
algorithm the router uses to apply algorithm specific QoS policy
configured on the adjacency.
SID/Label/Index: Refer to Adjacency Segment Identifier (LAN-Adj-SID)
Sub-TLV.
For a broadcast link, an SR-capable router MAY allocate different
Adj-SID for different algorithm, if this link will join different
algorithm related plane.
3.2. OSPF Adjacency Segment Identifier per Algorithm
[RFC8665] describes the OSPF extensions that need to be introduced
for Segment Routing operating on an MPLS data plane. It defined Adj-
SID Sub-TLV and LAN Adj-SID Sub-TLV advertised with Extended Link TLV
defined in [RFC7684]. This document extends these two Sub-TLVs to
carry the specific algorithm.
Peng, et al. Expires June 10, 2021 [Page 5]
Internet-Draft algo-related adj-sid December 2020
3.2.1. OSPF Adj-SID Sub-TLV
The existing Adj-SID Sub-TLV has the following format:
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm | MT-ID | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) |
+---------------------------------------------------------------+
Figure 3: OSPF Adj-SID Format
where:
Algorithm: The new Algorithm field contains the identifier of the
algorithm the router uses to apply algorithm specific QoS policy
configured on the adjacency.
For a P2P link, an SR-capable router MAY allocate different Adj-SID
for different algorithm, if this link will join different algorithm
related plane.
3.2.2. OSPF LAN Adj-SID Sub-TLV
The existing LAN Adj-SID Sub-TLV has the following format:
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm | MT-ID | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) |
+---------------------------------------------------------------+
Figure 4: OSPF LAN Adj-SID Format
Peng, et al. Expires June 10, 2021 [Page 6]
Internet-Draft algo-related adj-sid December 2020
where:
Algorithm: The new Algorithm field contains the identifier of the
algorithm the router uses to apply algorithm specific QoS policy
configured on the adjacency.
For a broadcast link, an SR-capable router MAY allocate different
Adj-SID for different algorithm, if this link will join different
algorithm related plane.
3.3. OSPFv3 Adjacency Segment Identifier per Algorithm
[RFC8666] describes the OSPFv3 extensions that need to be introduced
for Segment Routing operating on an MPLS data plane. It defined Adj-
SID Sub-TLV and LAN Adj-SID Sub-TLV advertised with Router-Link TLV
as defined in [RFC8362]. This document extends these two Sub-TLVs to
carry the specific algorithm.
3.3.1. OSPFv3 Adj-SID Sub-TLV
The existing Adj-SID Sub-TLV has the following format:
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Weight | Algorithm | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) |
+---------------------------------------------------------------+
Figure 5: OSPFv3 Adj-SID Format
where:
Algorithm: The new Algorithm field contains the identifier of the
algorithm the router uses to apply algorithm specific QoS policy
configured on the adjacency.
For a P2P link, an SR-capable router MAY allocate different Adj-SID
for different algorithm, if this link will join different algorithm
related plane.
Peng, et al. Expires June 10, 2021 [Page 7]
Internet-Draft algo-related adj-sid December 2020
3.3.2. OSPFv3 LAN Adj-SID Sub-TLV
The existing LAN Adj-SID Sub-TLV has the following format:
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Weight | Algorithm | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) |
+---------------------------------------------------------------+
Figure 6: OSPFv3 LAN Adj-SID Format
where:
Algorithm: The new Algorithm field contains the identifier of the
algorithm the router uses to apply algorithm specific QoS policy
configured on the adjacency.
For a broadcast link, an SR-capable router MAY allocate different
Adj-SID for different algorithm, if this link will join different
algorithm related plane.
4. Operations
The method introduced in this document enables the traffic of
different flex-algo plane to be distinguished on the same link, so
that these traffic can be applied with different QoS policy per
algorithm.
The endpoint of a link shared by multiple flex-algo plane can reserve
different queue resources for different algorithms locally, and
perform priority based queue scheduling and traffic shaping. This
algorithm related reserved information can be advertised to other
nodes in the network through some mechanism, therefore it has an
impact on the constraint based path calculation of the flex-algo
plane. How to allocate algorithm related resouce and advertise it in
the network is out the scope of this document.
Depending on the implementation, operators can configure multiple
Adacency-SIDs each for different algorithm on the same link. One of
Peng, et al. Expires June 10, 2021 [Page 8]
Internet-Draft algo-related adj-sid December 2020
the difficulties is that during this configuration phase it is not
straightforward for a link to be included in an FA plane, as this can
only be determined after all nodes in the network have negotiated the
FAD. A simple way is that as long as an IGP instance enable an FA
for a level/area, all links joined to that level/area should allocate
Adjacency-SIDs for that algorithm statically. Another way is to
allocate and withdraw Adjacency-SID per algorithm dynamically
according to the result of FAD negotiation.
The following figure shows an example of Adjacency-SID per algorithm.
[S1]--------[D]--------[S2]
| | |
| | |
| | |
[A]---------[B]--------[C]
Figure 7: Flex-algo LFA Path with Adjacency-SID per Algorithm
Suppose that node S1, A, B, D and their inter-connected links belongs
to FA-id 128 plane, and S2, B, C, D and their inter-connected links
belongs to FA-id 129 plane. The IGP metric of link B-D is 100, and
all other links have IGP metric 1. In FA-id 128 plane, from S1 to
destination D, the primary path is S1-D, and the TI-LFA backup path
is segment list {node(B), adjacency(B-D)}. Similarly, In FA-id 129
plane, from S2 to destination D, the primary path is S2-D, and the
TI-LFA backup path is segment list {node(B), adjacency(B-D)}. The
above TI-LFA path of FA-id 128 plane can be translated to {node-
SID(B)@FA-id128, adjacency-SID(B-D)@FA-id128}, and TI-LFA path of FA-
id 129 plane will be translate to {node-SID(B)@FA-id129, adjacency-
SID(B-D)@FA-id129}. So that node B can distinguish the flow of FA-id
128 and FA-id 129 based on different adjacency-SID(B-D), and take
different treatment (e.g., QoS policy) of them when they are send to
the same outgoing link B-D.
5. IANA Considerations
TBD
6. Security Considerations
There are no new security issues introduced by the extensions in this
document. Refer to [RFC8665], [RFC8666], [RFC8667] for other
security considerations.
Peng, et al. Expires June 10, 2021 [Page 9]
Internet-Draft algo-related adj-sid December 2020
7. Acknowledgements
TBD
8. Normative References
[I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-13 (work in progress), October 2020.
[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>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/info/rfc4915>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <https://www.rfc-editor.org/info/rfc7684>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
F. Baker, "OSPFv3 Link State Advertisement (LSA)
Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
2018, <https://www.rfc-editor.org/info/rfc8362>.
Peng, et al. Expires June 10, 2021 [Page 10]
Internet-Draft algo-related adj-sid December 2020
[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>.
[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>.
[RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions
for Segment Routing", RFC 8666, DOI 10.17487/RFC8666,
December 2019, <https://www.rfc-editor.org/info/rfc8666>.
[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>.
[RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri,
M., and E. Aries, "Advertising Layer 2 Bundle Member Link
Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668,
December 2019, <https://www.rfc-editor.org/info/rfc8668>.
Authors' Addresses
Shaofu Peng
ZTE Corporation
China
Email: peng.shaofu@zte.com.cn
Ran Chen
ZTE Corporation
China
Email: chen.ran@zte.com.cn
Ketan Talaulikar
Cisco Systems
India
Email: ketant@cisco.com
Peng, et al. Expires June 10, 2021 [Page 11]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/