BGP Classful Transport
PlanesJuniper Networks, Inc.1133 Innovation Way,SunnyvaleCA94089USkaliraj@juniper.netJuniper Networks, Inc.1133 Innovation Way,SunnyvaleCA94089USnatv@juniper.netJuniper Networks, Inc.Electra, Exora Business Park~Marathahalli - Sarjapur Outer
Ring Road,BangaloreKA560103Indiabalajir@juniper.netVerizon Communications Inc.13101 Columbia PikeSilver SpringMD20904USAgyan.s.mishra@verizon.comCox Communications Inc.AtlantaGAUSAmazen.khaddam@cox.comCapitalonline.BeijingChinaxiaohu.xu@capitalonline.netGoogle.1160 N Mathilda Ave, Bldg 5,Sunnyvale,CA94089USAszarecki@google.comExtreme Networks55 Commerce Valley Drive West, Suite 300,Thornhill, Toronto,OntarioL3T 7V9Canadadgowda@extremenetworks.comATT200 S Laurel Ave,Middletown,NJ07748USAcy098d@att.comThis document specifies a mechanism, referred to as "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
co-operating administrative domains. These domains may be administetered
by the same provider or closely co-ordinating provider networks.It makes it possible to advertise multiple tunnels to the same
destination address, thus avoiding need of multiple loopbacks on the
egress node.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.It carries transport prefixes across tunnel domain boundaries (e.g.
in Inter-AS Option-C networks), 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.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.To facilitate service mapping, the tunnels in a network can be
grouped by the purpose they serve into a "Transport Class". The tunnels
could be created using any signaling protocol, such as LDP, RSVP, BGP LU
or SPRING. The tunnels could also use native IP or IPv6, as long as they
can carry MPLS payload. Tunnels may exist between different pair of end
points. Multiple tunnels may exist between the same pair of end
points.Thus, a Transport Class consists of tunnels created by various
protocols that satisfy the properties of the class. For example, a
"Gold" transport class may consist of tunnels that traverse the shortest
path with fast re-route protection, a "Silver" transport class may hold
tunnels that traverse shortest paths without protection, a "To NbrAS
Foo" transport class may hold tunnels that exit to neighboring AS Foo,
and so on.The extensions specified in this document can be used to create a BGP
transport tunnel that potentially spans domains, while preserving its
Transport Class. Examples of domain are Autonomous System (AS), or IGP
area. Within each domain, there is a second level underlay tunnel used
by BGP to cross the domain. The second level underlay tunnels could be
hetrogeneous: Each domain may use a different type of tunnel (e.g. MPLS,
IP, GRE), or use a differnet signaling protocol. A domain boundary is
demarcated by a rewrite of BGP nexthop to 'self' while re-advertising
tunnel routes in BGP. Examples of domain boundary are inter-AS links and
inter-region ABRs. The path uses MPLS label-switching when crossing
domain boundary and uses the native intra-AS tunnel of the desired
transport class when traversing within a domain.Overlay routes carry sufficient indication of the Transport Classes
they should be encapsulated over, in form of BGP community called the
"Mapping community". Based on the mapping community, "route resolution"
procedure on the ingress node selects from the corresponding Transport
Class an appropriate tunnel whose destination matches (LPM) the nexthop
of the overlay route. If the overlay route is carried in BGP, the
protocol nexthop (or, PNH) is generally carried as an attribute of the
route.The PNH of the overlay route is also referred to as "service
endpoint" (SEP). The service endpoint may exist in the same domain as
the service ingress node or lie in a different domain, adjacent or
non-adjacent. In the former case, reachability to the SEP is provided by
an intra-domain tunneling protocol, and in the latter case, reachability
to the SEP is via BGP transport families.In this architecture, the intra-domain transport protocols (e.g.
RSVP, SRTE) are also "Transport Class aware", and they publish ingress
routes in Transport RIB associated with the Transport Class, at the
tunnel ingress node. These routes are then redistributed into BGP CT to
be advertised to adjacent domains. It is outside the scope of this
document how exactly the transport protocols are made transport class
aware, though configuration on the tunnel ingress node is a simple
mechanism to achieve it.This document describes mechanisms to: Model a "Transport Class" as "Transport RIB" on a router,
consisting of tunnel ingress routes of a certain class.Enable service routes to resolve over an intended Transport Class
by virtue of carrying the appropriate "Mapping community". Which
results in using the corresponding Transport RIB for finding nexthop
reachability.Advertise tunnel ingress routes in a Transport RIB via BGP
without any path hiding, using BGP VPN technology and Add-path. Such
that overlay routes in the receiving domains can also resolve over
tunnels of associated Transport Class.Provide a way for co-operating domains to reconcile any
differences in extended community namespaces, and interoperate
between different transport signaling protocols in each domain.In this document we focus mainly on MPLS as the intra-domain
transport tunnel forwarding, but the mechanisms described here would
work in similar manner for non-MPLS (e.g. IP, GRE, UDP) transport tunnel
forwarding technologies too.This document assumes MPLS forwarding when crossing domain
boundaries, as that is the defacto standard in deployed networks today.
But mechanisms specified in this document can also support different
forwarding technologies (e.g. SRv6). Section in this document describes adaptation of BGP
CT over SRv6 data plane.The document Seamless Segment
Routing describes various use cases and applications of
procedures described in this document.LSP: Label Switched Path.TE : Traffic Engineering.SN : Service Node.BN : Border Node.TN : Transport Node, P-router.BGP-VPN : VPNs built using RFC4364 mechanisms.RT : Route-Target extended community.RD : Route-Distinguisher.PNH : Protocol-Nexthop address carried in a BGP Update message.SEP : Service End point, the PNH of a Service route.LPM : Longest Prefix Match.Service Family : BGP address family used for advertising routes for
"data traffic", as opposed to tunnels.Transport Family : BGP address family used for advertising tunnels,
which are in turn used by service routes for resolution.Transport Tunnel : A tunnel over which a service may place traffic.
These tunnels can be GRE, UDP, LDP, RSVP, or SR-TE.Tunnel Domain : A domain of the network containing SN and BN, under a
single administrative control that has a tunnel between SN and BN. An
end-to-end tunnel spanning several adjacent tunnel domains can be
created by "stitching" them together using labels.Transport Class : A group of transport tunnels offering the same type
of service.Transport Class RT : A Route-Target extended community used to
identify a specific Transport Class.Transport RIB : At the SN and BN, a Transport Class has an associted
Transport RIB that holds its tunnel routes.Transport Plane : An end to end plane comprising of transport tunnels
belonging to same transport class. Tunnels of same transport class are
stitched together by BGP route readvertisements with nexthop-self, to
span across domain boundaries using Label-Swap forwarding mechanism
similar to Inter-AS option-b.Mapping Community : BGP Community/Extended-community on a service
route, that maps it to resolve over a Transport Class.A Transport Class is defined as a set of transport tunnels that share
certain characteristics useful for underlay selection.On the wire, a transport class is represented as the Transport Class
RT, which is a new Route-Target extended community.A Transport Class is configured at SN and BN, along with attributes
like RD and Route-Target. Creation of a Transport Class instantiates the
associated Transport RIB and a Transport routing instance to contain
them all.The operator may configure a SN/BN to classify a tunnel into an
appropriate Transport Class, which causes the tunnel's ingress routes to
be installed in the corresponding Transport RIB. At a BN, these tunnel
routes may then be advertised into BGP CT.Alternatively, a router receiving the transport routes in BGP with
appropriate signaling information can associate those ingress routes to
the appropriate Transport Class. E.g. for Classful Transport family
(SAFI 76) routes, the Transport Class RT indicates the Transport Class.
For BGP LU family(SAFI 4) routes, import processing based on Communities
or inter-AS source-peer may be used to place the route in the desired
Transport Class.When the ingress route is received via SRTE, which encodes the Transport Class as an
integer 'Color' in the NLRI as "Color:Endpoint", the 'Color' is mapped
to a Transport Class during import processing. SRTE ingress route for
'Endpoint' is installed in that transport class. The SRTE route when
advertised out to BGP speakers will then be advertised in Classful
Transport family with Transport Class RT and a new label. The MPLS swap
route thus installed for the new label will pop the label and deliver
decapsulated traffic into the path determined by SRTE route.RFC8664 extends PCEP to carry SRTE
Color. This color association thus learnt is also mapped to a Transport
Class thus associating the PCEP signaled SRTE LSP with the desired
Transport Class.Similarly, PCEP-RSVP-COLOR
extends PCEP to carry RSVP Color. This color association thus learnt is
also mapped to a Transport Class thus associating the PCEP signaled RSVP
LSP with the desired Transport Class.This document defines a new type of Route Target, called "Transport
Class" Route Target Extended Community."Transport Class" Route Target extended community is a transitive
extended community EXT-COMM of
extended-type, with a new Format (Type high = 0xa) and SubType as 0x2
(Route Target).This new Route Target Format has the following encoding:The "Transport class" Route Target Extended community follows the
mechanisms for VPN route import, export as specified in BGP-VPN, and follows the Route Target Contrain
mechanisms as specified in VPN-RTCA BGP speaker that implements RT Constraint VPN-RTC MUST apply the RT Constraint procedures
to the "Transport class" Route Target Extended community as-well.The Transport Class Route Target Extended community is carried on
Classful Transport family routes, and allows associating them with
appropriate Transport RIBs at receiving BGP speakers.Use of the Transport Class Route Target Extended community with a new
Type code avoids conflicts with any VPN Route Target assignments already
in use for service families.A Transport RIB is a routing-only RIB that is not installed in
forwarding path. However, the routes in this RIB are used to resolve
reachability of overlay routes' PNH. Transport RIB is created when the
Transport Class it represents is configured.Overlay routes that want to use a specific Transport Class confine
the scope of nexthop resolution to the set of routes contained in the
corresponding Transport RIB. This Transport RIB is the "Routing Table"
referred in Section
9.1.2.1 RFC4271Routes in a Transport RIB are exported out in 'Classful Transport'
address family.A BGP VPN routing instance that is a container for the Transport RIB.
It imports, and exports routes in this RIB with Transport Class RT.
Tunnel destination addresses in this routing instance's context come
from the "provider namespace". This is different from user VRFs for
e.g., which contain prefixes in "customer namespace"The Transport Routing instance uses the RD and RT configured for the
Transport Class.An implementation may provide an option for the service route to
resolve over less preferred Transport Classes, should the resolution
over preferred, or "primary" Transport Class fail.To accomplish this, the set of service routes may be associated with
a user-configured "resolution scheme", which consists of the primary
Transport Class, and optionally, an ordered list of fallback Transport
Classes.A community called as "Mapping Community" is configured for a
"resolution scheme". A Mapping community maps to exactly one resolution
scheme. A resolution scheme comprises of one primary transport class and
optionally one or more fallback transport classes.A BGP route is associated with a resolution scheme during import
processing. The first community on the route that matches a mapping
community of a locally configured resolution scheme is considered the
effective mapping community for the route. The resolution scheme thus
found is used when resolving the route's PNH. If a route contains more
than one mapping community, it indicates that the route considers these
multiple mapping communities as equivalent. So the first community that
maps to a resolution scheme is chosen.A transport route received in BGP Classful Transport family SHOULD
use a resolution scheme that contains the primary Transport Class
without any fallback to best effort tunnels. The primary Transport Class
is identified by the Transport Class RT carried on the route. Thus
Transport Class RT serves as the Mapping Community for Classful
Transport routes.A service route received in a BGP service family MAY map to a
resolution scheme that contains the primary Transport Class identified
by the mapping community on the route, and a fallback to best effort
tunnels transport class. The primary Transport Class is identified by
the Mapping community carried on the route. For e.g. the Extended Color
community may serve as the Mapping Community for service routes.
Color:0:<n> MAY map to a resolution scheme that has primary
transport class <n>, and a fallback to best-effort transport
class.The Classful Transport (CT) family will use the existing AFI of IPv4
or IPv6, and a new SAFI 76 "Classful Transport" that will apply to both
IPv4 and IPv6 AFIs. These AFI, SAFI pair of values MUST be negotiated in
Multiprotocol Extensions capability described in to be able to send and receive BGP CT routes.The "Classful Transport" SAFI NLRI itself is encoded as specified in
https://tools.ietf.org/html/rfc8277#section-2.When AFI is IPv4 the "Prefix" portion of Classful Transport family
NLRI consists of an 8-byte RD followed by an IPv4 prefix. When AFI is
IPv6 the "Prefix" consists of an 8-byte RD followed by an IPv6
prefix.Attributes on a Classful Transport route include the Transport Class
Route-Target extended community, which is used to leak the route into
the right Transport RIBs on SNs and BNs in the network.SAFI 76 routes can be sent with either IPv4 or IPv6 nexthop. The type
of nexthop is inferred from the length of nexthop.When the length of Next Hop Address field is 24 (or 48) the nexthop
address is of type VPN-IPv6 with 8-octet RD set to zero (potentially
followed by the link-local VPN-IPv6 address of the next hop with an
8-octet RD set to zero).When the length of Next Hop Address field is 12 the nexthop address
is of type VPN-IPv4 with 8-octet RD set to zero.SAFI 128 (Inet-VPN) is a RF8277 encoded family that carries service
prefixes in the NLRI, where the prefixes come from the customer
namespaces, and are contexualized into separate user virtual service
RIBs called VRFs, using RFC4364 procedures.SAFI 4 (BGP LU) is a RFC8277 encoded family that carries transport
prefixes in the NLRI, where the prefixes come from the provider
namespace.SAFI 76 (Classful Transport) is a RFC8277 encoded family that carries
transport prefixes in the NLRI, where the prefixes come from the
provider namespace, but are contexualized into separate Transport RIBs,
using RFC4364 procedures.It is worth noting that SAFI 128 has been used to carry transport
prefixes in "L3VPN Inter-AS Carrier's carrier" scenario, where BGP
LU/LDP prefixes in CsC VRF are advertised in SAFI 128 towards the
remote-end baby carrier.In this document a new AFI/SAFI is used instead of reusing SAFI 128
to carry these transport routes, because it is operationally
advantageous to segregate transport and service prefixes into separate
address families, RIBs. E.g. It allows to safely enable "per-prefix"
label allocation scheme for Classful Transport prefixes without
affecting SAFI 128 service prefixes which may have huge scale. "per
prefix" label allocation scheme keeps the routing churn local during
topology changes.A new family also facilitates having a different readvertisement path
of the transport family routes in a network than the service route
readvertisement path. viz. Service routes (Inet-VPN) are exchanged over
an EBGP multihop session between Autonomous systems with nexthop
unchanged; whereas Classful Transport routes are readvertised over EBGP
single hop sessions with "nexthop-self" rewrite over inter-AS links.The Classful Transport family is similar in vein to BGP LU, in that
it carries transport prefixes. The only difference is, it also carries
in Route Target an indication of which Transport Class the transport
prefix belongs to, and uses RD to disambiguate multiple instances of the
same transport prefix in a BGP Update.This section summarizes the procedures followed by various nodes
speaking Classful Transport familyPreparing the network for deploying Classful Transport planesOperator decides on the Transport Classes that exist in the
network, and allocates a Route-Target to identify each Transport
Class.Operator configures Transport Classes on the SNs and BNs in the
network with unique Route-Distinguishers and Route-Targets.Implementations may provide automatic generation and assignment
of RD, RT values for a transport routing instance; they MAY also
provide a way to manually override the automatic mechanism, in order
to deal with any conflicts that may arise with existing RD, RT
values in the different network domains participating in a
deployment.Origination of Classful Transport route:At the ingress node of the tunnel's home domain, the tunneling
protocols install routes in the Transport RIB associated with the
Transport Class the tunnel belongs to.The ingress node then advertises this tunnel destination into BGP
as a Classful Transport family route with NLRI RD:TunnelEndpoint,
attaching a 'Transport Class' Route Target that identifies the
Transport Class. This BGP CT route is advertised to EBGP peers and
IBGP peers which are RR-clients. This route MUST NOT be advertised
to the IBGP peers who are not RR-clients.Alternatively, the egress node of the tunnel i.e. the tunnel
endpoint can originate the same BGP Classful Transport route, with
NLRI RD:TunnelEndpoint and PNH TunnelEndpoint, which will resolve
over the tunnel route at the ingress node. When the tunnel is up,
the Classful Transport BGP route will become usable and get
re-advertised.Unique RD SHOULD be used by the originator of a Classful
Transport route to disambiguate the multiple BGP advertisements for
a transport end point.Ingress node receiving Classful Transport routeOn receiving a BGP Classful Transport route with a PNH that is
not directly connected, e.g. an IBGP-route, a mapping community on
the route (the Transport Class RT) indicates which Transport Class
this route maps to. The routes in the associated Transport RIB are
used to resolve the received PNH. If there does not exist a route in
the Transport RIB matching the PNH, the Classful Transport route is
considered unusable, and MUST NOT be re-advertised further.Border node readvertising Classful Transport route with nexthop
self:The BN allocates an MPLS label to advertise upstream in Classful
Transport NLRI. The BN also installs an MPLS swap-route for that
label that swaps the incoming label with a label received from the
downstream BGP speaker, or pops the incoming label. And then pushes
received traffic to the transport tunnel or direct interface that
the Classful Transport route's PNH resolved over.The label SHOULD be allocated with "per-prefix" label allocation
semantics. RD is stripped from the BGP CT NLRI prefix when a BGP CT
route is leaked to a Transport RIB. The IP prefix in the transport
RIB context (IP-prefix, Transport-Class) is used as the key to do
per-prefix label allocation. This helps in avoiding BGP CT route
churn through out the CT network when a failure happens in a domain.
The failure is not propagated further than the BN closest to the
failure.The value of advertised MPLS label is locally significant, and is
dynamic by default. The BN may provide option to allocate a value
from a statically carved out range. This can be achieved using
locally configured export policy, or via mechanisms described in
BGP Prefix-SID.Border node receiving Classful Transport route on EBGP :If the route is received with PNH that is known to be directly
connected, e.g. EBGP single-hop peering address, the directly
connected interface is checked for MPLS forwarding capability. No
other nexthop resolution process is performed, as the inter-AS link
can be used for any Transport Class.If the inter-AS links should honor Transport Class, then the BN
SHOULD follow procedures of an Ingress node described above, and
perform nexthop resolution process. The interface routes SHOULD be
installed in the Transport RIB belonging to the associated Transport
Class.Avoiding path-hiding through Route ReflectorsWhen multiple BNs exist that advertise a RDn:PEn prefix to RRs,
the RRs may hide all but one of the BNs, unless ADDPATH is used for the Classful Transport
family. This is similar to L3VPN option-B scenarios. Hence ADDPATH
SHOULD be used for Classful Transport family, to avoid path-hiding
through RRs.Avoiding loop between Route Reflectors in forwarding pathPair of redundant ABRs acting as RR with nexthop-self may chose
each other as best path instead of the upstream ASBR, causing a
traffic forwarding loop.Implementations SHOULD provide a way to alter the tie-breaking
rule specified in BGP RR to tie-break
on CLUSTER_LIST step before ROUTER-ID step, when performing path
selection for BGP CT routes. RFC4456 considers pure RR which is not
in forwarding path. When RR is in forwarding path and reflects
routes with nexthop-self, which is the case for ABR BNs in a BGP
transport network, this rule may cause loops. This document suggests
the following modification to the BGP Decision Process Tie Breaking
rules (Sect. 9.1.2.2, ) when doing path
selection for BGP CT family routes:The following rule SHOULD be inserted between Steps e) and f): a
BGP Speaker SHOULD prefer a route with the shorter CLUSTER_LIST
length. The CLUSTER_LIST length is zero if a route does not carry
the CLUSTER_LIST attribute.Some deployment considerations can also help in avoiding this
problem: IGP metric should be assigned such that "ABR to redundant
ABR" cost is inferior than "ABR to upstream ASBR" cost.Tunnels belonging to special Transport classes SHOULD NOT be
provisioned between ABR to ABRs. This will ensure that the route
received from an ABR with nexthop-self will not be usable at a
redundant ABR.This avoids possibility of such loops altogether,
irrespective of whether the path selection modification mentioned
above is implemented.Ingress node receiving service route with mapping communityService routes received with mapping community resolve using
Transport RIBs determined by the resolution scheme. If the
resolution process does not find an usable Classful Transport route
or tunnel route in any of the Transport RIBs, the service route MUST
be considered unusable for forwarding purpose.Coordinating between domains using different community
namespaces.Cooperating option-C domains may sometimes not agree on RT, RD,
Mapping-community or Transport Route Target values because of
differences in community namespaces; e.g. during network mergers or
renumbering for expansion. Such deployments may deploy mechanisms to
map and rewrite the Route-target values on domain boundaries, using
per ASBR import policies. This is no different than any other BGP
VPN family. Mechanisms employed in inter-AS VPN deployments may be
used with the Classful Transport family also.The resolution schemes SHOULD allow association with multiple
mapping communities. This helps with renumbering, network mergers,
or transitions.Though RD can also be rewritten on domain boundaries, deploying
unique RDs is strongly RECOMMENDED, because it helps in trouble
shooting by uniquely identifying originator of a route, and avoids
path-hiding.This document defines a new format of Route-Target
extended-community to carry Transport Class, this avoids collision
with regular Route Target namespace used by service routes.RFC8212 suggests BGP speakers require
explicit configuration of both BGP Import and Export Policies for any
EBGP sessions, in order to receive or send routes on EBGP
sessions.It is recommended to follow this for BGP CT routes. It will
prohibit unintended advertisement of transport routes through out the
BGP CT transport domain which may span multiple AS. This will conserve
usage of MPLS label and nexthop resources in the network. An ASBR of a
domain can be provisioned to allow routes with only the Transport
targets that are required by SNs in the domain.This section describes how the number of Protocol Nexthops
advertised to a SN or BN can be constrained using BGP Classsful
Transport and VPN RTCAn egress SN MAY advertise BGP CT route for RD:eSN with two
Route Targets: transport-target:0:<TC> and a RT carrying
<eSN>:<TC>. Where TC is the Transport Class
identifier, and eSN is the IP-address used by SN as BGP nexthop in
it's service route advertisements.transport-target:0:<TC> is the new type of route target
(Transport Class RT) defined in this document. It is carried in
BGP extended community attribute (BGP attribute code 16).The RT carrying <eSN>:<TC> MAY be an IP-address
specific regular RT (BGP attribute code 16), IPv6-address specific
RT (BGP attribute code 25), or a Wide-communities based RT (BGP
attribute code 34) as described in RTC-ExtAn ingress SN MAY import BGP CT routes with Route Target
carrying: <eSN>:<TC>. The ingress SN MAY learn the eSN
values either by configuration, or it MAY discover them from the
BGP nexthop field in the BGP VPN service routes received from eSN.
A BGP ingress SN receiving a BGP service route with nexthop of eSN
SHOULD generate a RTC/Extended-RTC route for Route Target prefix
<Origin ASN>:<eSN>/[80|176] in order to learn BGP CT
transport routes to reach eSN. This allows constrained
distribution of the transport routes to the PNHs actually required
by iSN.When path of route propogation of BGP CT routes is same as the
RTC routes, a BN would learn the RTC routes advertised by ingress
SNs and propagate further. This will allow constraining
distribution of BGP CT routes for a PNH to only the necessary BNs
in the network, closer to the egress SN.This mechanism provides "On Demand Nexthop" of BGP CT routes,
which help with scaling of MPLS forwarding state at SN and BN.But the amount of state carried in RTC family may become
proportional to number of PNHs in the network. To strike a
balance, the RTC route advertisements for <Origin
ASN>:<eSN>/[80|176] MAY be confined to the BNs in home
region of ingress-SN, or the BNs of a super core.Such a BN in the core of the network SHOULD import BGP CT
routes with Transport Class Route Target: 0:<TC>, and
generate a RTC route for <Origin ASN>:0:<TC>/96, while
not propagating the more specific RTC requests for specific PNHs.
This will let the BN learn transport routes to all eSN nodes. But
confine their propagation to ingress-SNs.It may be even more desirable to limit the number of PNHs that are
globaly visible in the network. This is possible using mechanism
described in MPLS NamespacesSuch that advertisement of PE loopback addresses as next-hop in BGP
service routes is confined to the region they belong to. An anycast
IP-address called "Context Protocol Nexthop Address" abstracts the PEs
in a region from other regions in the network, swapping the PE scoped
service label with a CPNH scoped private namespace label.This provides much greater advantage in terms of scaling and
convergence. Changes to implement this feature are required only on
the region's BNs and RR.Standard MPLS OAM procedures specified in
also apply to BGP Classful Transport.The 'Target FEC Stack' sub-TLV for IPv4 Classful Transport has a
Sub-Type of [TBD], and a length of 13. The Value field consists of the
RD advertised with the Classful Transport prefix, the IPv4 prefix (with
trailing 0 bits to make 32 bits in all), and a prefix length, encoded as
follows:The 'Target FEC Stack' sub-TLV for IPv6 Classful Transport has a
Sub-Type of [TBD], and a length of 25. The Value field consists of the
RD advertised with the Classful Transport prefix, the IPv6 prefix (with
trailing 0 bits to make 128 bits in all), and a prefix length, encoded
as follows:In Network Slicing, the Transport Slice Controller (TSC) sets up the
Topology (e.g. RSVP, SR-TE tunnels with desired characteristics) and
resources (e.g. polices/shapers) in a transport network to create a
Transport slice. The Transport class construct described in this
document represents the "Topology Slice" portion of this equation.The TSC can use the Transport Class Identifier (Color value) to
provision a transport tunnel in a specific Topology Slice.Further, Network slice controller can use the Mapping community on
the service route to map traffic to the desired Transport slice.This section describes how BGP CT may be used to set up inter domain
tunnels of a certain Transport Class, when using Segment Routing over
IPv6 (SRv6) data plane on the inter AS links or as intra-AS tunneling
mechanism.RFC8986, specify the SRv6 Endpoint
behaviors (End USD, End.BM, End.B6.Encaps and End.Replace,
End.ReplaceB6, respectively). These are leveraged for BGP CT with SRv6
data plane.The BGP Classful Transport route update for SRv6 MUST include the BGP
Prefix-SID attribute along with SRv6 SID information as specified in
. It may also include SRv6 SID structure
for Transposition as specified in . It
should be noted that prefixes carried in BGP CT family are transport
layer end-points, e.g. PE loopback addresses. Thus the SRv6 SID carried
in a BGP CT route is also a transport layer identifier.This document extends the usage of "SRv6 label route tunnel" TLV to
AFI=1/2 SAFI 76. "SRv6 label route tunnel" is the TLV of the BGP
Prefix-SID Attribute as specified in .This example shows a provider network that comprises of two
Autonomous systems, AS1, AS2. They are serving customers AS3, AS4
respectively. Traffic direction being described is CE41 to CE31. CE31
may request a specific SLA, e.g. Gold for this traffic, when
traversing these provider networks.AS2 is further divided into two regions. So there are three tunnel
domains in provider space. AS1 uses ISIS Flex-Algo intra-domain
tunnels, whereas AS2 uses RSVP intra-domain tunnels.The network has two Transport classes: Gold with transport class id
100, Bronze with transport class id 200. These transport classes are
provisioned at the PEs and the Border nodes (ABRs, ASBRs) in the
network.Following tunnels exist for Gold transport class.PE25_to_ABR23_gold - RSVP tunnelPE25_to_ABR24_gold - RSVP tunnelABR23_to_ASBR22_gold - RSVP tunnelASBR13_to_PE11_gold - ISIS FlexAlgo tunnelASBR14_to_PE11_gold - ISIS FlexAlgo tunnelFollowing tunnels exist for Bronze transport class.PE25_to_ABR23_bronze - RSVP tunnelABR23_to_ASBR21_bronze - RSVP tunnelABR23_to_ASBR22_bronze - RSVP tunnelABR24_to_ASBR21_bronze - RSVP tunnelASBR13_to_PE12_bronze - ISIS FlexAlgo tunnelASBR14_to_PE11_bronze - ISIS FlexAlgo tunnelThese tunnels are either provisioned or auto-discovered to belong
to transport class 100 or 200.Service nodes PE11, PE12 negotiate service families (SAFI 1, 128)
on the BGP session with RR16. Service helpers RR16, RR26 have multihop
EBGP session to exchange service routes between the two AS. Similarly
PE25 negotiates service families with RR26.Forwarding happens using service routes at service nodes PE25,
PE11, PE12 only. Routes received from CEs are not present in any other
nodes' FIB in the network.CE31 advertises a route for example prefix 31.31.31.31 with nexthop
self to PE11, PE12. CE31 can attach a mapping community Color:0:100 on
this route, to indicate its request for Gold SLA. Or, PE11 can attach
the same using locally configured policies. Let us assume CE31 is
getting VPN service from PE25.The 31.31.31.31 route is readvertised in SAFI 128 by PE11 with
nexthop self (1.1.1.1) and label V-L1, to RR16 with the mapping
community Color:0:100 attached. This SAFI 128 route reaches PE25 via
RR16, RR26 with the nexthop unchanged, as PE11 and label V-L1. Now
PE25 can resolve the PNH 1.1.1.1 using transport routes received in
BGP CT or BGP LU.The IP FIB at PE25 will have a route for 31.31.31.31 with a nexthop
thus found, that points to a Gold tunnel in ingress domain.ASBR13 negotiates BGP CT family with transport ASBRs ASBR21,
ASBR22. They negotiate BGP CT family with RR27 in region 2. ABR23,
ABR24 negotiate BGP CT family with RR27 in region 2 and RR26 in region
1. PE25 receives BGP CT routes from RR26. BGP LU family is also
negotiated on these sessions alongside BGP CT family. BGP LU carries
"best effort" transport class routes, BGP CT carries gold, bronze
transport class routes.ASBR13 is provisioned with transport class 100, RD value 1.1.1.3:10
and a transport route target 0:100. And a Transport class 200 with RD
value 1.1.1.3:20, and transport route target 0:200.Similarly, these transport classes are also configured on ASBRs,
ABRs and PEs, with same transport route target, but unique RDs.Ingress route for ASBR13_to_PE11_gold is advertised by ASBR13 in
BGP CT family to ASBRs ASBR21, ASBR22. This route is sent with a NLRI
containing RD prefix 1.1.1.3:10:1.1.1.1, Label B-L1 and a route target
extended community transport-target:0:100. MPLS swap route is
installed at ASBR13 for B-L1 with a nexthop pointing to
ASBR13_to_PE11_gold tunnel.Ingress route for ASBR13_to_PE11_bronze is advertised by ASBR13 in
BGP CT family to ASBRs ASBR21, ASBR22. This route is sent with a NLRI
containing RD prefix 1.1.1.3:20:1.1.1.1, Label B-L2 and a route target
extended community transport-target:0:200. MPLS swap route is
installed at ASBR13 for label B-L2 with a nexthop pointing to
ASBR13_to_PE11_bronze tunnelASBR21 receives BGP CT route 1.1.1.3:10:1.1.1.1 over the single hop
EBGP sesion, and readvertises with nexthop self (loopback adderss
2.2.2.1) to RR27, advertising a new label B-L3. MPLS swap route is
installed for label B-L3 at ASBR21 to swap to received label B-L1 and
forwards to ASBR13. RR27 readvertises this BGP CT route to ABR23,
ABR24.ASBR22 receives BGP CT route 1.1.1.3:10:1.1.1.1 over the single hop
EBGP sesion, and readvertises with nexthop self (loopback adderss
2.2.2.2) to RR27, advertising a new label B-L4. MPLS swap route is
installed for label B-L4 at ASBR22 to swap to received label B-L2 and
forwards to ASBR13. RR27 readvertises this BGP CT route to ABR23,
ABR24.Addpath is enabled for BGP CT family on the sessions between RR27
and ASBRs, ABRs. Such that routes for 1.1.1.3:10:1.1.1.1 with the
nexthops ASBR21 and ASBR22 are reflected to ABR23, ABR24 without any
path hiding. Thus giving ABR23 visibiity of both available nexthops
for Gold SLA.ABR23 receives the route with nexthop 2.2.2.1, label B-L3 from
RR27. The route target "transport-target:0:100" on this route acts as
mapping community, and instructs ABR23 to strictly resolve the nexthop
using transport class 100 routes only. ABR23 is unable to find a route
for 2.2.2.1 with transport class 100. Thus it considers this route
unusable and does not propagate it further. This prunes ASBR21 from
Gold SLA tunneled path.ABR23 also receives the route with nexthop 2.2.2.2, label B-L4 from
RR27. The route target "transport-target:0:100" on this route acts as
mapping community, and instructs ABR23 to strictly resolve the nexthop
using transport class 100 routes only. ABR23 successfully resolves the
nexthop to point to ABR23_to_ASBR22_gold tunnel. ABR23 readvertises
this route with nexthop self (loopback address 2.2.2.3) and a new
label B-L5 to RR26. Swap route for B-L5 is installed by ABR23 to swap
to label B-L4, and forward into ABR23_to_ASBR22_gold tunnel.RR26 reflects the route from ABR23 to PE25. PE25 receives the BGP
CT route for prefix 1.1.1.3:10:1.1.1.1 with label B-L5, nexthop
2.2.2.3 and transport-target:0:100 from RR26. And it similarly
resolves the nexthop 2.2.2.3 over transport class 100, pushing labels
associated with PE25_to_ABR23_gold tunnel.In this manner, the Gold transport LSP "ASBR13_to_PE11_gold" in
egress-domain is extended by BGP CT until the ingress-node PE25 in
ingress domain, to create an end-to-end Gold SLA path. MPLS swap
routes are installed at ASBR13, ASBR22 and ABR23, when propagating the
PE11 BGP CT Gold transport class route 1.1.1.3:10:1.1.1.1 with nexthop
self towards PE25.The BGP CT LSP thus formed, originates in PE25, and terminates in
ASBR13, traversing over the Gold underlay LSPs in each domain. ASBR13
uses UHP to stitch the BGP CT LSP into the "ASBR13_to_PE11_gold" LSP
to traverse the last domain, thus satisfying Gold SLA end-to-end.When PE25 receives service route with nexthop 1.1.1.1 and mapping
community Color:0:100, it resolves over this BGP CT route
1.1.1.3:10:1.1.1.1. Thus pushing label B-L5, and pushing as top label
the labels associated with PE25_to_ABR23_gold tunnel.This section describes how the data plane looks like in steady
state.CE41 transmits an IP packet with destination as 31.31.31.31. On
receiving this packet PE25 performs a lookup in the IP FIB
associated with the CE41 interface. This lookup yeids the service
route that pushes the VPN service label V-L1, BGP CT label B-L5, and
labels for PE25_to_ABR23_gold tunnel. Thus PE25 encapsulates the IP
packet in MPLS packet with label V-L1(innermost), B-L5, and top
label as PE25_to_ABR23_gold tunnel. This MPLS packet is thus
transmitted to ABR23 using Gold SLA.ABR23 decapsulates the packet received on PE25_to_ABR23_gold
tunnel as required, and finds the MPLS packet with label B-L5. It
performs lookup for label B-L5 in the global MPLS FIB. This yields
the route that swaps label B-L5 with label B-L4, and pushes top
label provided by ABR23_to_ASBR22_gold tunnel. Thus ABR23 transmits
the MPLS packet with label B-L4 to ASBR22, on a tunnel that
satisfies Gold SLA.ASBR22 similarly performs a lookup for label B-L4 in global MPLS
FIB, finds the route that swaps label B-L4 with label B-L2, and
forwards to ASBR13 over the directly connected MPLS enabled
interface. This interface is a common resource not dedicated to any
specific transport class, in this example.ASBR13 receives the MPLS packet with label B-L2, and performs a
lookup in MPLS FIB, finds the route that pops label B-L2, and pushes
labels associated with ASBR13_to_PE11_gold tunnel. This transmits
the MPLS packet with VPN label V-L1 to PE11, using a tunnel that
preserves Gold SLA in AS 1.PE11 receives the MPLS packet with V-L1, and performs VPN
forwarding. Thus transmitting the original IP payload from CE41 to
CE31. The payload has traversed path satisfying Gold SLA
end-to-end.This section describes how the data plane reacts when gold path
experiences a failure.Let us assume tunnel ABR23_to_ASBR22_gold goes down, such that
now end-to-end Gold path does not exist in the network. This makes
the BGP CT route for RD prefix 1.1.1.1:10:1.1.1.1 unusable at ABR23.
This makes ABR23 send a BGP withdrawal for 1.1.1.1:10:1.1.1.1 to
RR26, which then withdraws the prefix from PE25.Withdrawal for 1.1.1.1:10:1.1.1.1 allows PE25 to react to the
loss of gold path to 1.1.1.1. Let us assume PE25 is provisioned to
use best-effort transport class as the backup path. This withdrawal
of BGP CT route allows PE25 to adjust the nexthop of the VPN
Service-route to push the labels provided by the BGP LU route. That
repairs the traffic to go via best effort path. PE25 can also be
provisioned to use Bronze transport class as the backup path. The
repair will happen in similar manner in that case as-well.Traffic repair to absorb the failure happens at ingress node
PE25, in a service prefix scale independent manner. This is called
PIC (Prefix scale Independent Convergence). The repair time will be
proportional to time taken for withdrawing the BGP CT route.This document makes following requests of IANA.New BGP SAFI code for "Classful Transport". Value 76.This will be used to create new AFI,SAFI pairs for IPv4, IPv6
Classful Transport families. viz:"Inet, Classful Transport". AFI/SAFI = "1/76" for carrying IPv4
Classful Transport prefixes."Inet6, Classful Transport". AFI/SAFI = "2/76" for carrying
IPv6 Classful Transport prefixes.Please assign a new Format (Type high = 0xa) of extended community
EXT-COMM called "Transport Class" from
the following registries:the "BGP Transitive Extended Community Types" registry, andthe "BGP Non-Transitive Extended Community Types" registry.Please assign the same low-order six bits for both allocations.This document uses this new Format with subtype 0x2 (route target),
as a transitive extended community.The Route Target thus formed is called "Transport Class" route
target extended community.Taking reference of RFC7153 ,
following requests are made:This registry contains values of the high-order octet (the
"Type" field) of a Transitive Extended Community.This registry contains values of the high-order octet (the
"Type" field) of a Non-transitive Extended Community.The following two code points are sought for Target FEC Stack
sub-TLVs:IPv4 BGP Classful TransportIPv6 BGP Classful TransportMechanisms described in this document carry Transport routes in a new
BGP address family. That minimizes possibility of these routes leaking
outside the expected domain or mixing with service routes.When redistributing between SAFI 4 and SAFI 76 Classful Transport
routes, there is a possibility of SAFI 4 routes mixing with SAFI 1
service routes. To avoid such scenarios, it is RECOMMENDED that
implementations support keeping SAFI 4 routes in a separate transport
RIB, distinct from service RIB that contain SAFI 1 service routes.The authors thank Jeff Haas, John Scudder, Navaneetha Krishnan, Ravi
M R, Chandrasekar Ramachandran, Shradha Hegde, Richard Roberts,
Krzysztof Szarkowicz, John E Drake, Srihari Sangli, Vijay Kestur,
Santosh Kolenchery, Robert Raszuk, Ahmed Darwish for the valuable
discussions and review comments.The decision to not reuse SAFI 128 and create a new address-family to
carry these transport-routes was based on suggestion made by Richard
Roberts and Krzysztof Szarkowicz.Advertising Segment Routing Policies in BGPRoute Target Constrain ExtensionSeamless Segment RoutingBGP signalled
MPLS-namespacesPath Computation Element
Protocol(PCEP) Extension for RSVP ColorSRv6 inter-domain mapping
SIDsSRv6 BGP based Overlay
ServicesSRv6 and MPLS interworking