draft-ietf-lsr-ospf-transport-instance-01.txt   draft-ietf-lsr-ospf-transport-instance-02.txt 
LSR Workgroup A. Lindem LSR Workgroup A. Lindem
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track Y. Qu Intended status: Standards Track Y. Qu
Expires: May 22, 2022 Futurewei Expires: 22 November 2022 Futurewei
A. Roy A. Roy
Arrcus, Inc. Arrcus, Inc.
S. Mirtorabi S. Mirtorabi
Cisco Systems Cisco Systems
November 18, 2021 21 May 2022
OSPF Transport Instance Extensions OSPF Transport Instance Extensions
draft-ietf-lsr-ospf-transport-instance-01 draft-ietf-lsr-ospf-transport-instance-02
Abstract Abstract
OSPFv2 and OSPFv3 include a reliable flooding mechanism to OSPFv2 and OSPFv3 include a reliable flooding mechanism to
disseminate routing topology and Traffic Engineering (TE) information disseminate routing topology and Traffic Engineering (TE) information
within a routing domain. Given the effectiveness of these within a routing domain. Given the effectiveness of these
mechanisms, it is convenient to envision using the same mechanism for mechanisms, it is convenient to envision using the same mechanism for
dissemination of other types of information within the domain. dissemination of other types of information within the domain.
However, burdening OSPF with this additional information will impact However, burdening OSPF with this additional information will impact
intra-domain routing convergence and possibly jeopardize the intra-domain routing convergence and possibly jeopardize the
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 22, 2022. This Internet-Draft will expire on 22 November 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Possible Use Cases . . . . . . . . . . . . . . . . . . . . . 3 3. Possible Use Cases . . . . . . . . . . . . . . . . . . . . . 3
3.1. MEC Service Discovery . . . . . . . . . . . . . . . . . . 3 3.1. MEC Service Discovery . . . . . . . . . . . . . . . . . . 3
3.2. Application Data Dissemination . . . . . . . . . . . . . 4 3.2. Application Data Dissemination . . . . . . . . . . . . . 4
3.3. Intra-Area Topology for BGP-LS Distribution . . . . . . . 4 3.3. Intra-Area Topology for BGP-LS Distribution . . . . . . . 4
4. OSPF Transport Instance . . . . . . . . . . . . . . . . . . . 4 4. OSPF Transport Instance . . . . . . . . . . . . . . . . . . . 4
4.1. OSPFv2 Transport Instance Packet Differentiation . . . . 5 4.1. OSPFv2 Transport Instance Packet Differentiation . . . . 5
4.2. OSPFv3 Transport Instance Packet Differentiation . . . . 5 4.2. OSPFv3 Transport Instance Packet Differentiation . . . . 5
4.3. Instance Relationship to Normal OSPF Instances . . . . . 5 4.3. Instance Relationship to Normal OSPF Instances . . . . . 5
4.4. Network Prioritization . . . . . . . . . . . . . . . . . 5 4.4. Network Prioritization . . . . . . . . . . . . . . . . . 5
4.5. OSPF Transport Instance Omission of Routing Calculation . 6 4.5. OSPF Transport Instance Omission of Routing
Calculation . . . . . . . . . . . . . . . . . . . . . . . 6
4.6. Non-routing Instance Separation . . . . . . . . . . . . . 6 4.6. Non-routing Instance Separation . . . . . . . . . . . . . 6
4.7. Non-Routing Sparse Topologies . . . . . . . . . . . . . . 7 4.7. Non-Routing Sparse Topologies . . . . . . . . . . . . . . 7
4.7.1. Remote OSPF Neighbor . . . . . . . . . . . . . . . . 7 4.7.1. Remote OSPF Neighbor . . . . . . . . . . . . . . . . 8
4.8. Multiple Topologies . . . . . . . . . . . . . . . . . . . 8 4.8. Multiple Topologies . . . . . . . . . . . . . . . . . . . 8
5. OSPF Transport Instance Information (TII) Encoding . . . . . 8 5. OSPF Transport Instance Information (TII) Encoding . . . . . 8
5.1. OSPFv2 Transport Instance Information Encoding . . . . . 8 5.1. OSPFv2 Transport Instance Information Encoding . . . . . 8
5.2. OSPFv3 Transport Instance Information Encoding . . . . . 9 5.2. OSPFv3 Transport Instance Information Encoding . . . . . 9
5.3. Transport Instance Information (TII) TLV Encoding . . . . 10 5.3. Transport Instance Information (TII) TLV Encoding . . . . 10
5.3.1. Top-Level TII Application TLV . . . . . . . . . . . . 10 5.3.1. Top-Level TII Application TLV . . . . . . . . . . . . 11
6. Manageability Considerations . . . . . . . . . . . . . . . . 11 6. Manageability Considerations . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.1. OSPFv2 Opaque LSA Type Assignment . . . . . . . . . . . . 11 8.1. OSPFv2 Opaque LSA Type Assignment . . . . . . . . . . . . 12
8.2. OSPFv3 LSA Function Code Assignment . . . . . . . . . . . 12 8.2. OSPFv3 LSA Function Code Assignment . . . . . . . . . . . 12
8.3. OSPF Transport Instance Information Top-Level TLV 8.3. OSPF Transport Instance Information Top-Level TLV
Registry . . . . . . . . . . . . . . . . . . . . . . . . 12 Registry . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
skipping to change at page 3, line 47 skipping to change at page 3, line 45
Multi-Access Edge Computing (MEC) plays an important role in 5G Multi-Access Edge Computing (MEC) plays an important role in 5G
architecture. MEC optimizes the performance for ultra-low latency architecture. MEC optimizes the performance for ultra-low latency
and high bandwidth services by providing networking and computing at and high bandwidth services by providing networking and computing at
the edge of the network [ETSI-WP28-MEC]. To achieve this goal, it's the edge of the network [ETSI-WP28-MEC]. To achieve this goal, it's
important to expose the network capabilities and services of a MEC important to expose the network capabilities and services of a MEC
device to 5G User Equipment UE, i.e. UEs. device to 5G User Equipment UE, i.e. UEs.
The followings are an incomplete list of the kind of information that The followings are an incomplete list of the kind of information that
OSPF transport instance can help to disseminate: OSPF transport instance can help to disseminate:
o A network service is realized using one or more physical or * A network service is realized using one or more physical or
virtualized hosts in MEC, and the locations of these service virtualized hosts in MEC, and the locations of these service
points might change. The auto-discovery of these service points might change. The auto-discovery of these service
locations can be achieved using an OSPF transport instance. locations can be achieved using an OSPF transport instance.
o UEs might be mobile, and MEC should support service continuity and * UEs might be mobile, and MEC should support service continuity and
application mobility. This may require service state transferring application mobility. This may require service state transferring
and synchronization. OSPF transport instance can be used to and synchronization. OSPF transport instance can be used to
synchronize these states. synchronize these states.
o Network resources are limited, such as computing power, storage. * Network resources are limited, such as computing power, storage.
The availability of such resources is dynamic, and OSPF transport The availability of such resources is dynamic, and OSPF transport
instance can be used to populate such information, so applications instance can be used to populate such information, so applications
can pick the right location of such resources, hence improve user can pick the right location of such resources, hence improve user
experience and resource utilization. experience and resource utilization.
3.2. Application Data Dissemination 3.2. Application Data Dissemination
Typically a network consists of routers from different vendors with Typically a network consists of routers from different vendors with
different capabilities, and some applications may want to know different capabilities, and some applications may want to know
whether a router supports certain functionality or where to find a whether a router supports certain functionality or where to find a
skipping to change at page 6, line 35 skipping to change at page 6, line 39
| | AS-external-LSAs (type 0x4005) | | | AS-external-LSAs (type 0x4005) |
| | NSSA-LSAs (type 0x2007) | | | NSSA-LSAs (type 0x2007) |
| | intra-area-prefix-LSAs (type 0x2009) | | | intra-area-prefix-LSAs (type 0x2009) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPFv3 Extended LSA | E-inter-area-prefix-LSAs (type 0xA023) | | OSPFv3 Extended LSA | E-inter-area-prefix-LSAs (type 0xA023) |
| | E-as-external-LSAs (type 0xC025) | | | E-as-external-LSAs (type 0xC025) |
| | E-Type-7-NSSA (type 0xA027) | | | E-Type-7-NSSA (type 0xA027) |
| | E-intra-area-prefix-LSA (type 0xA029) | | | E-intra-area-prefix-LSA (type 0xA029) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSAs not included in OSPF transport instance Figure 1: LSAs not included in OSPF transport instance
If these LSAs are erroneously advertised, they will be flooded as per If these LSAs are erroneously advertised, they will be flooded as per
standard OSPF but MUST be ignored by OSPF routers supporting this standard OSPF but MUST be ignored by OSPF routers supporting this
specification. specification.
4.6. Non-routing Instance Separation 4.6. Non-routing Instance Separation
It has been suggested that an implementation could obtain the same It has been suggested that an implementation could obtain the same
level of separation between IP routing information and non-routing level of separation between IP routing information and non-routing
information in a single instance with slight modifications to the information in a single instance with slight modifications to the
OSPF protocol. The authors refute this contention for the following OSPF protocol. The authors refute this contention for the following
reasons: reasons:
o Adding internal and external mechanisms to prioritize routing * Adding internal and external mechanisms to prioritize routing
information over non-routing information are much more complex information over non-routing information are much more complex
than simply relegating the non-routing information to a separate than simply relegating the non-routing information to a separate
instance as proposed in this specification. instance as proposed in this specification.
o The instance boundary offers much better separation for allocation * The instance boundary offers much better separation for allocation
of finite resources such as buffers, memory, processor cores, of finite resources such as buffers, memory, processor cores,
sockets, and bandwidth. sockets, and bandwidth.
o The instance boundary decreases the level of fate sharing for * The instance boundary decreases the level of fate sharing for
failures. Each instance may be implemented as a separate process failures. Each instance may be implemented as a separate process
or task. or task.
o With non-routing information, many times not every router in the * With non-routing information, many times not every router in the
OSPF routing domain requires knowledge of every piece of non- OSPF routing domain requires knowledge of every piece of non-
routing information. In these cases, groups of routers which need routing information. In these cases, groups of routers which need
to share information can be segregated into sparse topologies to share information can be segregated into sparse topologies
greatly reducing the amount of non-routing information any single greatly reducing the amount of non-routing information any single
router needs to maintain. router needs to maintain.
4.7. Non-Routing Sparse Topologies 4.7. Non-Routing Sparse Topologies
With non-routing information, many times not every router in the OSPF With non-routing information, many times not every router in the OSPF
routing domain requires knowledge of every piece of non-routing routing domain requires knowledge of every piece of non-routing
skipping to change at page 7, line 40 skipping to change at page 7, line 43
information at all. information at all.
With normal OSPF, every router in an OSPF area must have every piece With normal OSPF, every router in an OSPF area must have every piece
of topological information and every intra-area IP or IPv6 prefix. of topological information and every intra-area IP or IPv6 prefix.
With non-routing information, only the routers needing to share a set With non-routing information, only the routers needing to share a set
of information need be part of the corresponding sparse topology. of information need be part of the corresponding sparse topology.
For directly attached routers, one only needs to configure the For directly attached routers, one only needs to configure the
desired topologies on the interfaces with routers requiring the non- desired topologies on the interfaces with routers requiring the non-
routing information. When the routers making up the sparse topology routing information. When the routers making up the sparse topology
are not part of a uniconnected graph, two alternatives exist. The are not part of a uniconnected graph, two alternatives exist. The
first alternative is configure tunnels to form a fully connected first alternative is configuring tunnels to form a fully connected
graph including only those routers in the sparse topology. The graph including only those routers in the sparse topology. The
second alternative is use remote neighbors as described in second alternative is use remote neighbors as described in
Section 4.7.1. Section 4.7.1.
4.7.1. Remote OSPF Neighbor 4.7.1. Remote OSPF Neighbor
With sparse topologies, OSPF routers sharing non-routing information With sparse topologies, OSPF routers sharing non-routing information
may not be directly connected. OSPF adjacencies with remote may not be directly connected. OSPF adjacencies with remote
neighbors are formed exactly as they are with regular OSPF neighbors. neighbors are formed exactly as they are with regular OSPF neighbors.
The main difference is that a remote OSPF neighbor's address is The main difference is that a remote OSPF neighbor's address is
configured and IP routing is used to deliver OSPF protocol packets to configured and IP routing is used to deliver OSPF protocol packets to
the remote neighbor. Other salient feature of the remote neighbor the remote neighbor. Other salient feature of the remote neighbor
include: include:
o All OSPF packets have the remote neighbor's configured IP address * All OSPF packets have the remote neighbor's configured IP address
as the IP destination address. as the IP destination address. This address has be to reachable
usig the unicast topology.
o The adjacency is represented in the router Router-LSA as a router * The adjacency is represented in the router Router-LSA as a router
(type-1) link with the link data set to the remote neighbor's (type-1) link with the link data set to the remote neighbor's
configured IP address. configured IP address.
o Similar to NBMA networks, a poll-interval is configured to * Similar to NBMA networks, a poll-interval is configured to
determine if the remote neighbor is reachable. This value is determine if the remote neighbor is reachable. This value is
normally much higher than the hello interval with 40 seconds normally much higher than the hello interval with 40 seconds
RECOMMENDED as the default. RECOMMENDED as the default.
4.8. Multiple Topologies 4.8. Multiple Topologies
For some applications, the information need to be flooded only to a For some applications, the information need to be flooded only to a
topology which is a subset of routers of the transport instance. topology which is a subset of routers of the transport instance.
This allows the application specific information only to be flooded This allows the application specific information only to be flooded
to routers that support the application. A transport instance may to routers that support the application. A transport instance may
skipping to change at page 9, line 24 skipping to change at page 9, line 24
| LS sequence number | | LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length | | LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- TLVs -+ +- TLVs -+
| ... | | ... |
g g
OSPFv2 Transport Instance Information Opaque LSA Figure 2: OSPFv2 Transport Instance Information Opaque LSA
The format of the TLVs within the body of an TII LSA is as defined in The format of the TLVs within the body of an TII LSA is as defined in
Section 5.3. Section 5.3.
5.2. OSPFv3 Transport Instance Information Encoding 5.2. OSPFv3 Transport Instance Information Encoding
Application specific information will be flooded in separate LSAs Application specific information will be flooded in separate LSAs
with a separate function code. Refer to section A.4.2.1 of with a separate function code. Refer to section A.4.2.1 of
[RFC5340]. for information on the LS Type encoding in OSPFv3, and [RFC5340]. for information on the LS Type encoding in OSPFv3, and
section 2 of [RFC8362] for OSPFv3 extended LSA types. An OSPFv3 section 2 of [RFC8362] for OSPFv3 extended LSA types. An OSPFv3
skipping to change at page 10, line 22 skipping to change at page 10, line 22
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number | | LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length | | LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- TLVs -+ +- TLVs -+
| ... | | ... |
OSPFv3 Transport Instance Information LSA Figure 3: OSPFv3 Transport Instance Information LSA
The format of the TLVs within the body of an TII LSA is as defined in The format of the TLVs within the body of an TII LSA is as defined in
Section 5.3. Section 5.3.
5.3. Transport Instance Information (TII) TLV Encoding 5.3. Transport Instance Information (TII) TLV Encoding
The format of the TLVs within the body of the LSAs containing non- The format of the TLVs within the body of the LSAs containing non-
routing information is the same as the format used by the Traffic routing information is the same as the format used by the Traffic
Engineering Extensions to OSPF [RFC3630]. The LSA payload consists Engineering Extensions to OSPF [RFC3630]. The LSA payload consists
of one or more nested Type/Length/Value (TLV) triplets. The format of one or more nested Type/Length/Value (TLV) triplets. The format
of each TLV is: of each TLV is:
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... | | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Format Figure 4: TLV Format
5.3.1. Top-Level TII Application TLV 5.3.1. Top-Level TII Application TLV
An Application top-level TLV will be used to encapsulate application An Application top-level TLV will be used to encapsulate application
data advertised within TII LSAs. This top-level TLV may be used to data advertised within TII LSAs. This top-level TLV may be used to
handle the local publication/subscription for application specific handle the local publication/subscription for application specific
data. The details of such a publication/subscription mechanism are data. The details of such a publication/subscription mechanism are
beyond the scope of this document. An Application ID is used in the beyond the scope of this document. An Application ID is used in the
top-level application TLV and shares the same code point with IS-IS top-level application TLV and shares the same code point with IS-IS
as defined in [RFC6823]. as defined in [RFC6823].
skipping to change at page 11, line 31 skipping to change at page 11, line 37
Application ID: Application ID:
An identifier assigned to this application via the IANA registry, An identifier assigned to this application via the IANA registry,
as defined in RFC 6823. Each unique application will have a as defined in RFC 6823. Each unique application will have a
unique ID. unique ID.
Additional Application-Specific Sub-TLVs: Additional Application-Specific Sub-TLVs:
Additional information defined by applications can be encoded as Additional information defined by applications can be encoded as
Sub-TLVs. Definition of such information is beyond the scope of Sub-TLVs. Definition of such information is beyond the scope of
this document. this document.
Top-Level TLV Figure 5: Top-Level TLV
The specific TLVs and sub-TLVs relating to a given application and The specific TLVs and sub-TLVs relating to a given application and
the corresponding IANA considerations MUST be specified in the the corresponding IANA considerations MUST be specified in the
document corresponding to that application. document corresponding to that application.
6. Manageability Considerations 6. Manageability Considerations
7. Security Considerations 7. Security Considerations
The security considerations for the Transport Instance will not be The security considerations for the Transport Instance will not be
skipping to change at page 12, line 34 skipping to change at page 12, line 39
| | | | | |
| 2-16383 | Unassigned (IETF Review) | | 2-16383 | Unassigned (IETF Review) |
| | | | | |
| 16383-32767 | Unassigned (FCFS) | | 16383-32767 | Unassigned (FCFS) |
| | | | | |
| 32768-32777 | Experimentation (No assignements) | | 32768-32777 | Experimentation (No assignements) |
| | | | | |
| 32778-65535 | Reserved (Not to be assigned) | | 32778-65535 | Reserved (Not to be assigned) |
+-----------+-------------------------------------+ +-----------+-------------------------------------+
TII Top-Level TLV Registry Assignments Figure 6: TII Top-Level TLV Registry Assignments
9. Acknowledgement 9. Acknowledgement
The authors would like to thank Les Ginsberg for review and comments. The authors would like to thank Les Ginsberg for review and comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 13, line 51 skipping to change at page 14, line 13
10.2. Informative References 10.2. Informative References
[ETSI-WP28-MEC] [ETSI-WP28-MEC]
Sami Kekki, etc., "MEC in 5G Networks", 2018, Sami Kekki, etc., "MEC in 5G Networks", 2018,
<https://www.etsi.org/images/files/ETSIWhitePapers/ <https://www.etsi.org/images/files/ETSIWhitePapers/
etsi_wp28_mec_in_5G_FINAL.pdf>. etsi_wp28_mec_in_5G_FINAL.pdf>.
[I-D.wang-lsr-igp-extensions-ifit] [I-D.wang-lsr-igp-extensions-ifit]
Wang, Y., Zhou, T., Qin, F., Chen, H., and R. Pang, "IGP Wang, Y., Zhou, T., Qin, F., Chen, H., and R. Pang, "IGP
Extensions for In-situ Flow Information Telemetry (IFIT) Extensions for In-situ Flow Information Telemetry (IFIT)
Capability Advertisement", draft-wang-lsr-igp-extensions- Capability Advertisement", Work in Progress, Internet-
ifit-01 (work in progress), July 2020. Draft, draft-wang-lsr-igp-extensions-ifit-01, 28 July
2020, <http://www.ietf.org/internet-drafts/draft-wang-lsr-
igp-extensions-ifit-01.txt>.
[RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the [RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the
Tunnel Setup Protocol (TSP)", RFC 5572, Tunnel Setup Protocol (TSP)", RFC 5572,
DOI 10.17487/RFC5572, February 2010, DOI 10.17487/RFC5572, February 2010,
<https://www.rfc-editor.org/info/rfc5572>. <https://www.rfc-editor.org/info/rfc5572>.
Authors' Addresses Authors' Addresses
Acee Lindem Acee Lindem
Cisco Systems Cisco Systems
301 Midenhall Way 301 Midenhall Way
CARY, NC 27513 CARY, NC 27513
UNITED STATES United States
Email: acee@cisco.com Email: acee@cisco.com
Yingzhen Qu Yingzhen Qu
Futurewei Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA United States of America
Email: yingzhen.qu@futurewei.com Email: yingzhen.qu@futurewei.com
Abhay Roy Abhay Roy
Arrcus, Inc. Arrcus, Inc.
Email: abhay@arrcus.com Email: abhay@arrcus.com
Sina Mirtorabi Sina Mirtorabi
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA United States of America
Email: smirtora@cisco.com Email: smirtora@cisco.com
 End of changes. 32 change blocks. 
46 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/