%% You should probably cite draft-ietf-idr-bgp-ct-33 instead of this revision. @techreport{ietf-idr-bgp-ct-01, number = {draft-ietf-idr-bgp-ct-01}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ct/01/}, author = {Kaliraj Vairavakkalai and Natrajan Venkataraman}, title = {{BGP Classful Transport Planes}}, pagetotal = 65, year = , month = , day = , abstract = {This document specifies a mechanism, referred to as "Intent Driven Service Mapping" to express association of overlay routes with underlay routes satisfying a certain SLA using BGP. The document describes a framework for classifying underlay routes into transport classes and mapping service routes to specific transport class. The "Transport class" construct maps to a desired SLA and can be used to realize the "Topology Slice" in 5G Network slicing architecture. This document specifies BGP protocol procedures that enable dissemination of such service mapping information that may span multiple cooperating administrative domains. These domains may be administetered by the same provider or by closely co-ordinating provider networks. A new BGP transport layer address family (SAFI 76) is defined for this purpose that uses RFC-4364 technology and follows RFC-8277 NLRI encoding. This new address family is called "BGP Classful Transport", aka BGP CT. BGP CT makes it possible to advertise multiple tunnels to the same destination address, thus avoiding need of multiple loopbacks on the egress node. It carries transport prefixes across tunnel domain boundaries (e.g. in Inter-AS Option-C networks), which is parallel to BGP LU (SAFI 4) . It disseminates "Transport class" information for the transport prefixes across the participating domains, which is not possible with BGP LU. This makes the end-to-end network a "Transport Class" aware tunneled network. Just like BGP LU (SAFI 4), BGP CT family (SAFI 76) is used in inter- AS option-C networks. The Service Mapping procedures described in this document apply in the same manner to Intra-AS service end points as well as Inter-AS option-A, option-B, option-C variations. Examples of these variations are given in Appendix A.}, }