draft-ietf-idr-bgp-ct-33.txt   draft-ietf-idr-bgp-ct-33-jgs-edits.txt 
skipping to change at page 1, line 30 skipping to change at page 1, line 30
routes use as an ordered set to resolve reachability (Resolution routes use as an ordered set to resolve reachability (Resolution
Schemes) towards service endpoints. These constructs can be used, Schemes) towards service endpoints. These constructs can be used,
for example, to realize the "IETF Network Slice" defined in TEAS for example, to realize the "IETF Network Slice" defined in TEAS
Network Slices framework. Network Slices framework.
Additionally, this document specifies protocol procedures for BGP Additionally, this document specifies protocol procedures for BGP
that enable dissemination of service mapping information in a network that enable dissemination of service mapping information in a network
that may span multiple cooperating administrative domains. These that may span multiple cooperating administrative domains. These
domains may be administered either by the same provider or by closely domains may be administered either by the same provider or by closely
coordinating providers. A new BGP address family that leverages RFC coordinating providers. A new BGP address family that leverages RFC
4364 procedures and follows RFC 8277 NLRI encoding is defined to 4364 ("BGP/MPLS IP Virtual Private Networks (VPNs)"
advertise underlay routes with its identified class. This new procedures and follows RFC 8277 ("Using BGP to Bind MPLS Labels to Address Prefixes")
NLRI encoding is defined to enable each advertised underlay route to be
identified by its class. This new
address family is called "BGP Classful Transport", a.k.a., BGP CT. address family is called "BGP Classful Transport", a.k.a., BGP CT.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
appear in all capitals, as shown here. appear in all capitals, as shown here.
skipping to change at page 5, line 23 skipping to change at page 5, line 23
Provisioning end-to-end "intent-aware" paths using BGP. For Provisioning end-to-end "intent-aware" paths using BGP. For
example, low latency path, best effort path. example, low latency path, best effort path.
Expressing a desired intent. For example, use low latency path Expressing a desired intent. For example, use low latency path
with fallback to the best effort path. with fallback to the best effort path.
Forwarding service traffic "only" using end-to-end "intent-aware" Forwarding service traffic "only" using end-to-end "intent-aware"
paths honoring that desired intent. paths honoring that desired intent.
The constructs and procedures defined in this document apply The constructs and procedures defined in this document apply
homogeneously to intra-AS as well as inter-AS (a.k.a. multi-AS) to intra-AS as well as inter-AS (a.k.a. multi-AS)
Option A, Option B and Option C (Section 10, [RFC4364]) style Option A, Option B and Option C (Section 10, [RFC4364]) style
deployments in provider networks. deployments in provider networks.
+--
jgs: I suggested deleting "homogeneously" since I couldn't figure
out what work it was doing. You could leave it as I've put it, or
perhaps you wanted something like "equally". But I think it's OK
as shown.
+--
Provider networks that are deployed using such styles provision Provider networks that are deployed using such styles provision
intra-domain transport tunnels between a pair of endpoints, typically intra-domain transport tunnels between a pair of endpoints, typically
+--
jgs: I think it would be useful to state someplace early on what
"transport" means in the context of this document, since it will
also be reviewed by people who think "transport" means UDP, TCP,
and QUIC. This goes double for "transport layer" which is more
commonly understood to mean OSI reference model layer 4. That one
at least, I think should go in the Terminology section, I'll add
a stub.
+--
a service node or a border node, that service traffic use to traverse a service node or a border node, that service traffic use to traverse
that domain. These tunnels are signaled using various tunneling that domain. These tunnels are signaled using various tunneling
protocols depending on the forwarding architecture used in the protocols depending on the forwarding architecture used in the
domain, which can be Multiprotocol Label Switching (MPLS), Internet domain, which can be Multiprotocol Label Switching (MPLS), Internet
Protocol version 4 (IPv4), or Internet Protocol version 6 (IPv6). Protocol version 4 (IPv4), or Internet Protocol version 6 (IPv6).
The mechanisms defined in this document allow different tunneling The mechanisms defined in this document allow different tunneling
technologies to become Transport Class aware. These can be applied technologies to become Transport Class aware. These can be applied
homogeneously to intra-domain tunneling technologies used in existing homogeneously to intra-domain tunneling technologies used in existing
brownfield networks as well as new greenfield networks. For clarity, brownfield networks as well as new greenfield networks. For clarity,
skipping to change at page 5, line 51 skipping to change at page 5, line 66
described. Other tunneling technologies have been described in described. Other tunneling technologies have been described in
detail in other documents and only an overview has been included in detail in other documents and only an overview has been included in
this document. For example, the details for Segment Routing (SRv6) this document. For example, the details for Segment Routing (SRv6)
are provided in [BGP-CT-SRv6], and an overview is provided in are provided in [BGP-CT-SRv6], and an overview is provided in
Section 7.13. Section 7.13.
Customers need to be able to signal desired Intent to the network, Customers need to be able to signal desired Intent to the network,
and the network needs to have constructs able to enact the customer's and the network needs to have constructs able to enact the customer's
intent. The network constructs defined in this document are used to intent. The network constructs defined in this document are used to
classify and group these intra-domain tunnels based on various classify and group these intra-domain tunnels based on various
characteristics, like TE characeteristics (e.g., low latency), into characteristics, like TE characteristics (e.g., low latency), into
identifiable classes that can pass "intent-aware" traffic. These identifiable classes that can pass "intent-aware" traffic. These
constructs enable services to express their desired intent on using constructs enable services to express their intent to use
one or more identifiable classes, and mechanisms to selectively map one or more identifiable classes, and mechanisms to selectively map
traffic onto "intent-aware" tunnels for these classes. traffic onto "intent-aware" tunnels for these classes.
This document introduces a new BGP address family called "BGP This document introduces a new BGP address family called "BGP
Classful Transport", that extends/stitches intent-aware intra-domain Classful Transport", that extends/stitches intent-aware intra-domain
tunnels belonging to the same class across domain boundaries, to tunnels belonging to the same class across domain boundaries, to
establish end-to-end intent-aware paths between service endpoints. establish end-to-end intent-aware paths between service endpoints.
[Intent-Routing-Color] describes various use cases and applications [Intent-Routing-Color] describes various use cases and applications
of the procedures described in this document. of the procedures described in this document.
[Appendix C] provides an outline of the design philosophy behind this
specification. In particular, readers who are already familiar with
one or more BGP VPN technologies may want to review this appendix
before reading the main body of the specification.
+--
jgs: Up to you whether to include the above (or something like it) but
it sure would have helped my review to have done it in that order... and
I already had the outline from before, I just needed a refresher. I can
only imagine it would be even more helpful to a reviewer getting their
first exposure.
+--
2. Terminology 2. Terminology
+--
jgs: In general I tend to dislike the heavy use of acronyms/initialisms
where terms could be spelled out instead; it tends to create an
unnecessary barrier to entry for those who aren't part of the "in group"
while not (as far as I can tell) helping those who are part of the "in
group". However to change that in this document would be a large effort
for probably modest gains, so instead I've just suggested adding a few
missing terms to the glossary.
However, please feel free to take on the challenge of reducing use of
abbreviations instead, if you wish.
+--
ABR: Area Border Router ABR: Area Border Router
+--
jgs: I was surprised to encounter ABR in the BGP context. I was only
aware of it being a term of art in the IGPs. Since BGP doesn't have
"areas" as a defined construct, if you are going to use this term I
think it would be helpful to say some more words about what precisely
you intend by it. Or of course, cite a definition if there's already
one in another relevant document.
+--
AFI: Address Family Identifier AFI: Address Family Identifier
AS: Autonomous System AS: Autonomous System
ASBR: Autonomous System Border Router ASBR: Autonomous System Border Router
ASN: Autonomous System Number ASN: Autonomous System Number
BGP VPN: VPNs built using RD, RT; architecture described in RFC4364 BGP VPN: VPNs built using RD, RT; architecture described in RFC4364
skipping to change at page 6, line 50 skipping to change at page 6, line 82
DSCP: Differentiated Services Code Point DSCP: Differentiated Services Code Point
EP: Endpoint of a tunnel, e.g. a loopback address in the network EP: Endpoint of a tunnel, e.g. a loopback address in the network
EPE: Egress Peer Engineering EPE: Egress Peer Engineering
eSN: Egress Service Node eSN: Egress Service Node
FEC: Forwarding Equivalence Class FEC: Forwarding Equivalence Class
FRR: XXX fill me in XXX
iSN: Ingress Service Node iSN: Ingress Service Node
LPM: Longest Prefix Match L-ISIS: XXX fill me in, see also comment on B.2.2 XXX
LSP: Label Switched Path LSP: Label Switched Path
MNH: BGP MultiNexthop attribute MNH: BGP MultiNexthop attribute
MPLS: Multi Protocol Label Switching MPLS: Multi Protocol Label Switching
NLRI: Network Layer Reachability Information NLRI: Network Layer Reachability Information
PE: Provider Edge PE: Provider Edge
PHP: Penultimate Hop Pop PHP: Penultimate Hop Pop
PIC: XXX fill me in XXX
PNH: Protocol Next Hop address carried in a BGP Update message PNH: Protocol Next Hop address carried in a BGP Update message
RD: Route Distinguisher RD: Route Distinguisher
+--
jgs: You use "RD:EP" several time. I think it might be helpful to supply
a definition, even if it's "intuitively obvious" to reviewers who are
already expert in L3VPN technology.
+--
RSVP-TE: Resource Reservation Protocol - Traffic Engineering RSVP-TE: Resource Reservation Protocol - Traffic Engineering
RT: Route Target extended community RT: Route Target extended community
RTC: Route Target Constrain RTC: Route Target Constrain
+--
jgs: I see you're not citing RFCs for any of these. When I was reviewing
it seemed to me a cite for RTC wouldn't go amiss, but if you want to keep
it consistent that's OK.
+--
SAFI: Subsequent Address Family Identifier SAFI: Subsequent Address Family Identifier
SID: Segment Identifier SID: Segment Identifier
SLA: Service Level Agreement SLA: Service Level Agreement
SN: Service Node SN: Service Node
SR: Segment Routing SR: Segment Routing
skipping to change at page 7, line 48 skipping to change at page 7, line 61
SRTE: Segment Routing Traffic Engineering SRTE: Segment Routing Traffic Engineering
TC: Transport Class TC: Transport Class
TC ID: Transport Class Identifier TC ID: Transport Class Identifier
TC-BE: Best Effort Transport Class TC-BE: Best Effort Transport Class
TE: Traffic Engineering TE: Traffic Engineering
TEA: Tunnel Encapsulation Attribute, attribute type code 23.
TRDB: Transport Route Database TRDB: Transport Route Database
UHP: Ultimate Hop Pop UHP: Ultimate Hop Pop
VRF: Virtual Routing and Forwarding table VRF: Virtual Routing and Forwarding table
2.1. Definitions and Notations 2.1. Definitions and Notations
BGP Community Carrying Attribute (CCA) : A BGP attribute that carries BGP Community Carrying Attribute (CCA) : A BGP attribute that carries
community. Examples of BGP CCA are: Communities (attr code 8), community. Examples of BGP CCA are: COMMUNITIES (attribute code 8),
Extended Communities (attr code 16), IPv6 Address Specific Extended EXTENDED COMMUNITIES (attribute code 16), IPv6 Address Specific Extended
Community (attr code 25), Large community (attr code 32). Community (attribute code 25), LARGE_COMMUNITY (attribute code 32).
color:0:100 : This notation denotes a Color extended community as color:0:100 : This notation denotes a Color extended community as
defined in RFC 9012 with the Flags field set to 0 and the color field defined in RFC 9012 with the Flags field set to 0 and the color field
set to 100. set to 100.
End to End Tunnel: A tunnel spanning several adjacent tunnel domains End to End Tunnel: A tunnel spanning several adjacent tunnel domains
created by "stitching" them together using MPLS labels or an created by "stitching" them together using MPLS labels or an
equivalent identifier based on the forwarding architecture. equivalent identifier based on the forwarding architecture.
Import processing: Receive side processing of an overlay route, Import processing: Receive side processing of an overlay route,
including things like import policy application, resolution scheme including things like import policy application, resolution scheme
selection and next hop resolution. selection and next hop resolution.
Intent: A set of operational goals (that a network should meet) and Intent: As defined in Section 2 of [RFC9315], "A set of operational
outcomes (that a network is supposed to deliver) defined in a goals (that a network should meet) and outcomes (that a network is
declarative manner without specifying how to achieve or implement supposed to deliver) defined in a declarative manner without
them, as defined in Section 2 of [RFC9315]. specifying how to achieve or implement them."
Mapping Community: Any BGP CCA (e.g., Community, Extended Community) Mapping Community: Any BGP CCA (e.g., Community, Extended Community)
on an overlay route that maps to a Resolution Scheme. For example, on an overlay route that maps to a Resolution Scheme. For example,
color:0:100, transport-target:0:100. color:0:100, transport-target:0:100.
Resolution Scheme: A construct comprising of an ordered set of TRDBs Resolution Scheme: A construct comprising of an ordered set of TRDBs
to resolve next hop reachability, for realizing a desired intent. to resolve next hop reachability, for realizing a desired intent.
Service Family: A BGP address family used for advertising routes for Service Family: A BGP address family used for advertising routes for
destinations in "data traffic". For example, AFI/SAFIs 1/1 or 1/128. destinations in "data traffic". For example, AFI/SAFIs 1/1 or 1/128.
Transport, Transport Layer: XXX fill me in XXX
Transport Family: A BGP address family used for advertising tunnels, Transport Family: A BGP address family used for advertising tunnels,
which are in turn used by service routes for resolution. For which are in turn used by service routes for resolution. For
example, AFI/SAFIs 1/4 or 1/76. example, AFI/SAFIs 1/4 or 1/76.
Transport Tunnel : A tunnel over which a service may place traffic. Transport Tunnel : A tunnel over which a service may place traffic.
Such a tunnel can be provisioned or signaled using a variety of Such a tunnel can be provisioned or signaled using a variety of
means. For example, Generic Routing Encapsulation (GRE), UDP, LDP, means. For example, Generic Routing Encapsulation (GRE), UDP, LDP,
RSVP-TE, IGP FLEX-ALGO or SRTE. RSVP-TE, IGP FLEX-ALGO or SRTE.
Tunnel Route: A Route to Tunnel Destination/Endpoint that is Tunnel Route: A Route to Tunnel Destination/Endpoint that is
installed at the headend (ingress) of the tunnel. installed at the headend (ingress) of the tunnel.
Tunnel Domain: A domain of the network containing Service Nodes (SNs) Tunnel Domain: A domain of the network containing Service Nodes (SNs)
and Border Nodes (BNs) under a single administrative control that has and Border Nodes (BNs) under a single administrative control that has
tunnels between them. tunnels between them.
Brownfield network: An existing network that is already in service, Brownfield network: An existing network that is already in service,
deploying a chosen set of technologies and hardware. Enhancements deploying a chosen set of technologies and hardware. Enhancements
and upgrades to such network deployments protect return on and upgrades to such network deployments protect return on
investment, and should consider continuity of service. investment, and should consider continuity of service.
+--
jgs: maybe you've chosen to put this out of alphabetical order because
of proximity to the def'n of greenfield network, but noting in case it
was an accident.
+--
Greenfield network: A new network deployment which can make choice of Greenfield network: A new network deployment which can make choice of
new technology or hardware as needed, with fewer constraints than new technology or hardware as needed, with fewer constraints than
brownfield network. brownfield network.
Transport Class: A construct to group transport tunnels offering Transport Class: A construct to group transport tunnels offering
similar SLA. similar SLA.
+--
jgs: "Similar" is a likely trigger for reviewers to ask you to please be
specific about the kinds of similarity. Possibly you just need to
provide a forward reference to Section 4.1.
See also my next comment.
+--
Transport Class RT: A Route Target Extended Community used to Transport Class RT: A Route Target Extended Community used to
identify a specific Transport Class. identify a specific Transport Class.
transport-target:0:100 : This notation denotes a Transport Class RT transport-target:0:100 : This notation denotes a Transport Class RT
extended community as defined in this document with the "Transport extended community as defined in this document with the "Transport
Class ID" field set to 100. Class ID" field set to 100.
Transport Route Database: At the SN and BN, a Transport Class has an Transport Route Database: At the SN and BN, a Transport Class has an
associated Transport Route Database that collects its Tunnel Routes. associated Transport Route Database that collects its Tunnel Routes.
skipping to change at page 10, line 42 skipping to change at page 10, line 42
^^^^^^^ ^^^^ ^^^^^^ ^^^^^^^ ^^^^ ^^^^^^
Resolution Schemes Transport Route DB Transport Class Resolution Schemes Transport Route DB Transport Class
Figure 1: BGP CT Overview with Example Topology Figure 1: BGP CT Overview with Example Topology
To achieve end-to-end "Intent Driven Service Mapping", this document To achieve end-to-end "Intent Driven Service Mapping", this document
defines the following constructs and BGP extensions: defines the following constructs and BGP extensions:
The "Transport Class" (Section 4) construct to group underlay The "Transport Class" (Section 4) construct to group underlay
tunnels with sufficiently similar TE characteristics. tunnels with sufficiently similar TE characteristics.
+--
jgs: Again, don't leave this to the reader to infer (or guess). Either
remove the "similar" stuff, or qualify it. The "remove" option would
look like,
The "Transport Class" (Section 4) construct to group underlay
tunnels.
Which I think is actually sufficient, but ¯\_(ツ)_/¯
Alternatively, maybe a forward reference to Section 4.1 would do the
trick.
+--
The "Resolution Scheme" (Section 5) construct for overlay routes The "Resolution Scheme" (Section 5) construct for overlay routes
with Mapping Community to resolve next hop reachability from with Mapping Community to resolve next hop reachability from
either one or an ordered set of Transport Classes. either one or an ordered set of Transport Classes.
The "BGP Classful Transport" (Section 6) address family to extend The "BGP Classful Transport" (Section 6) address family to extend
these constructs to adjacent domains. these constructs to adjacent domains.
Figure 1 depicts the intra-AS and inter-AS application of these Figure 1 depicts the intra-AS and inter-AS application of these
constructs. It uses an example topology of Inter-AS option C network constructs. It uses an example topology of Inter-AS option C network
skipping to change at page 11, line 31 skipping to change at page 11, line 31
underlay tunnel to adjacent domains. A new BGP transport layer underlay tunnel to adjacent domains. A new BGP transport layer
address family called "BGP Classful Transport", also known as BGP CT address family called "BGP Classful Transport", also known as BGP CT
(AFI/SAFIs 1/76, 2/76) is defined for this purpose. BGP CT makes it (AFI/SAFIs 1/76, 2/76) is defined for this purpose. BGP CT makes it
possible to advertise multiple tunnels to the same destination possible to advertise multiple tunnels to the same destination
address, thus avoiding the need for multiple loopbacks on the Egress address, thus avoiding the need for multiple loopbacks on the Egress
Service Node (eSN). Service Node (eSN).
The BGP CT address family carries transport prefixes across tunnel The BGP CT address family carries transport prefixes across tunnel
domain boundaries, which is parallel to BGP LU (AFI/SAFIs 1/4 or domain boundaries, which is parallel to BGP LU (AFI/SAFIs 1/4 or
2/4). It disseminates "Transport Class" information for the 2/4). It disseminates "Transport Class" information for the
+--
jgs: above, I don't get what you mean by the first sentence, in
particularly "which is parallel" part. Would it be correct to break this
into two sentences? Like:
The BGP CT address family carries transport prefixes across tunnel
domain boundaries. Its design and operation are analogous to BGP LU
(AFI/SAFIs 1/4 or 2/4).
+--
transport prefixes across the participating domains while avoiding transport prefixes across the participating domains while avoiding
the need of per-transport class loopback. This is not possible with the need of per-transport class loopback. This is not possible with
BGP LU without using per-color loopback. This makes the end-to-end BGP LU without using per-color loopback. This makes the end-to-end
network a "Transport Class" aware tunneled network. network a "Transport Class" aware tunneled network.
In Figure 1, BGP CT routes are originated at BN11 in AS1 with next In Figure 1, BGP CT routes are originated at BN11 in AS1 with next
hop "self" towards BN21 in AS2 to extend available RSVP-TE tunnels hop "self" towards BN21 in AS2 to extend available RSVP-TE tunnels
for Transport Class 100 and 200 in AS1. BN21 propagates these routes for Transport Class 100 and 200 in AS1. BN21 propagates these routes
with next hop "self" onto PE21, which resolves the BGP CT routes over with next hop "self" to PE21, which resolves the BGP CT routes over
SRTE tunnels belonging to same transport class. SRTE tunnels belonging to same transport class.
Overlay routes carry sufficient indication of the desired Transport Overlay routes carry an indication of the desired Transport
Classes using a BGP community which assumes the role of as a "Mapping Classes using a BGP community which assumes the role of a "Mapping
Community". A Resolution Scheme is identified by its "Mapping Community". A Resolution Scheme is identified by its "Mapping
Community", where its configuration can either be auto-generated Community", where its configuration can either be auto-generated
based on TC ID or done manually. based on TC ID or done manually.
The following text illustrates CT architecture having the property of The following text illustrates CT architecture having the property of
providing tiered fallback options at a per-route granularity. In providing tiered fallback options at a per-route granularity. In
Figure 1, the Resolution Schemes are shown and the following next hop Figure 1, the Resolution Schemes are shown and the following next hop
resolutions are done by SN11 and PE21 for the service routes of resolutions are done by SN11 and PE21 for the service routes of
prefixes IP1, IP2, IP3: prefixes IP1, IP2, IP3:
skipping to change at page 12, line 35 skipping to change at page 12, line 35
architecture. However, these procedures would work in a similar architecture. However, these procedures would work in a similar
manner for non-MPLS forwarding architectures as well. Section 7.13 manner for non-MPLS forwarding architectures as well. Section 7.13
describes the application of BGP CT over SRv6 data plane. describes the application of BGP CT over SRv6 data plane.
4. Transport Class 4. Transport Class
Transport Class is a construct that groups transport tunnels offering Transport Class is a construct that groups transport tunnels offering
similar SLA within the administrative domain of a provider network or similar SLA within the administrative domain of a provider network or
closely coordinated provider networks. closely coordinated provider networks.
A Transport Class is uniquely identified on a box by a 32-bit A Transport Class is uniquely identified by a 32-bit
"Transport Class ID", that is assigned by the operator. The operator "Transport Class ID", that is assigned by the operator. The operator
consistently provisions a Transport Class on participating nodes (SNs consistently provisions a Transport Class on participating nodes (SNs
and BNs) in a domain with its unique Transport Class ID. and BNs) in a domain with its unique Transport Class ID.
+--
jgs: First, "on a box" is too colloquial, "on a router" would be better.
But more importantly, I think you can delete "on a box" and not replace
it with anything. Isn't it true that it has to be identical throughout
the AS? In fact, the second sentence says that. So I've proposed the
deletion.
+--
A Transport Class is also configured with RD and import/export RT A Transport Class is also configured with RD and import/export RT
attributes. Creation of a Transport Class instantiates its attributes. Creation of a Transport Class instantiates its
corresponding TRDB and Resolution Schemes on that node. corresponding TRDB and Resolution Schemes on that node.
All nodes within a domain agree on a common Transport Class ID All nodes within a domain agree on a common Transport Class ID
namespace. However, two co-operating domains may not always agree on namespace. However, two co-operating domains may not always agree on
the same namespace. Procedures to manage differences in Transport the same namespace. Procedures to manage differences in Transport
Class ID namespaces between co-operating domains are specified in Class ID namespaces between co-operating domains are specified in
Section 11.2.2. Section 11.2.2.
skipping to change at page 13, line 23 skipping to change at page 13, line 23
Tunnels (RSVP-TE, IGP FLEX-ALGO, SR-TE) that support latency Tunnels (RSVP-TE, IGP FLEX-ALGO, SR-TE) that support latency
sensitive routing. sensitive routing.
RSVP-TE Tunnels that only go over admin-group with Green links. RSVP-TE Tunnels that only go over admin-group with Green links.
Tunnels (RSVP-TE, SR-TE) that offer Fast Reroute. Tunnels (RSVP-TE, SR-TE) that offer Fast Reroute.
Tunnels (RSVP-TE, SR-TE) that share resources in the network based Tunnels (RSVP-TE, SR-TE) that share resources in the network based
on Shared Risk Link Groups defined by TE policy. on Shared Risk Link Groups defined by TE policy.
+--
jgs: I don't understand the one above.
+--
Tunnels (RSVP-TE, SR-TE, BGP CT) that avoid certain nodes in the Tunnels (RSVP-TE, SR-TE, BGP CT) that avoid certain nodes in the
network based on RSVP-TE ERO, SR-TE policy or BGP policy. network based on RSVP-TE ERO, SR-TE policy or BGP policy.
An operator may configure a SN/BN to classify a tunnel into an An operator may configure a SN/BN to classify a tunnel into an
appropriate Transport Class. How exactly these tunnels are made appropriate Transport Class. How exactly these tunnels are made
Transport Class aware is implementation specific and outside the Transport Class aware is implementation specific and outside the
scope of this document. scope of this document.
When a tunnel is made Transport Class aware, it causes the Tunnel When a tunnel is made Transport Class aware, it causes the Tunnel
skipping to change at page 13, line 50 skipping to change at page 13, line 53
A SN/BN receiving the transport routes via BGP with sufficient A SN/BN receiving the transport routes via BGP with sufficient
signaling information to identify a Transport Class can associate signaling information to identify a Transport Class can associate
those tunnel routes to the corresponding Transport Class. For those tunnel routes to the corresponding Transport Class. For
example, in BGP CT family routes, the Transport Class RT indicates example, in BGP CT family routes, the Transport Class RT indicates
the Transport Class. For BGP LU family routes, import processing the Transport Class. For BGP LU family routes, import processing
based on Communities or Inter-AS source-peer may be used to place the based on Communities or Inter-AS source-peer may be used to place the
route in the desired Transport Class. route in the desired Transport Class.
When the tunnel route is received via [SRTE] with "Color:Endpoint" as When the tunnel route is received via [SRTE] with "Color:Endpoint" as
the NLRI that encodes the Transport Class as an integer 'Color', the the NLRI that encodes the Transport Class as an integer 'Color'
in its Policy Color field,
the
'Color' is mapped to a Transport Class during the import processing. 'Color' is mapped to a Transport Class during the import processing.
The SRTE tunnel route for this 'Endpoint' is installed in the The SRTE tunnel route for this 'Endpoint' is installed in the
corresponding TRDB. The SRTE tunnel will be extended by a BGP CT corresponding TRDB. The SRTE tunnel will be extended by a BGP CT
advertisement with NLRI 'RD:Endpoint', Transport Class RT and a new advertisement with NLRI 'RD:Endpoint', Transport Class RT and a new
label. The MPLS swap route thus installed for the new label will pop label. The MPLS swap route thus installed for the new label will pop
the label and forward the decapsulated traffic into the path the label and forward the decapsulated traffic into the path
determined by the SRTE route for further encapsulation. determined by the SRTE route for further encapsulation.
+--
jgs: You've made [SRTE] an informative reference. Based on the above
paragraph, I think it has to be a normative reference. The above
paragraph specifies procedure, and it can't be understood without
reference to the SRTE document.
+--
[PCEP-SRPOLICY] extends Path Computation Element Communication [PCEP-SRPOLICY] extends Path Computation Element Communication
Protocol (PCEP) to signal attributes of an SR Policy which include Protocol (PCEP) to signal attributes of an SR Policy which include
Color. This Color is mapped to a Transport Class thus associating Color. This Color is mapped to a Transport Class thus associating
the SR Policy with the desired Transport Class. the SR Policy with the desired Transport Class.
Similarly, [PCEP-RSVP-COLOR] extends PCEP to carry the Color Similarly, [PCEP-RSVP-COLOR] extends PCEP to carry the Color
attribute for its use with RSVP-TE LSPs . This Color is mapped to a attribute for its use with RSVP-TE LSPs . This Color is mapped to a
Transport Class thus associating the RSVP-TE LSP with the desired Transport Class thus associating the RSVP-TE LSP with the desired
Transport Class. Transport Class.
skipping to change at page 14, line 30 skipping to change at page 14, line 36
4.2. Transport Route Database 4.2. Transport Route Database
A Transport Route Database (TRDB) is a logical collection of A Transport Route Database (TRDB) is a logical collection of
transport routes pertaining to the same Transport Class. In any transport routes pertaining to the same Transport Class. In any
node, every Transport Class has an associated TRDB. Resolution node, every Transport Class has an associated TRDB. Resolution
Schemes resolve next hop reachability for EP using the transport Schemes resolve next hop reachability for EP using the transport
routes within the scope of the TRDBs. routes within the scope of the TRDBs.
Tunnel endpoint addresses (EP) in a TRDB belong to the "Provider Tunnel endpoint addresses (EP) in a TRDB belong to the "Provider
Namespace" representing the core transport region. Namespace" representing the core transport region.
+--
jgs: you talk about "provider namespace" a few times but without ever
defining it. I presume it's the bottom turtle ;-) in the virtualization
stack, i.e. it represents real, non-virtualized addresses. (Well at
least notionally, from the provider's point of view.) I wonder if you
can say this more explicitly, i.e. it's the base of the virtualization
hierarchy. Equally, "the core transport region" doesn't have any well-
defined meaning.
+--
An implementation may realize the TRDB as a "Routing Table" referred An implementation may realize the TRDB as a "Routing Table" referred
in Section 9.1.2.1 of RFC4271 (https://www.rfc-editor.org/rfc/ in Section 9.1.2.1 of RFC4271 (https://www.rfc-editor.org/rfc/
rfc4271#section-9.1.2.1) which is used only for resolving next hop rfc4271#section-9.1.2.1) which is used only for resolving next hop
reachability in control plane. An implementation may choose a reachability in control plane. An implementation may choose a
different datastructure to realize this logical construct while still different datastructure to realize this logical construct while still
adhering to the procedures defined in this document. The tunnel adhering to the procedures defined in this document. The tunnel
routes in a TRDB require no footprint in the forwarding plane unless routes in a TRDB require no footprint in the forwarding plane unless
they are used to resolve a next hop. they are used to resolve a next hop.
+--
jgs: would it be correct to change "require no footprint" to "need not
be installed"?
+--
SNs or BNs originate routes for the "Classful Transport" address SNs or BNs originate routes for the "Classful Transport" address
family from the TRDB. These routes have "RD:Endpoint" in the NLRI, family from the TRDB. These routes have "RD:Endpoint" in the NLRI,
carry a Transport Class RT, and an MPLS label or equivalent carry a Transport Class RT, and an MPLS label or equivalent
identifier in different forwarding architecture. "Classful identifier in different forwarding architecture. "Classful
Transport" family routes received with Transport Class RT are Transport" family routes received with Transport Class RT are
installed into their respective TRDB. installed into their respective TRDB.
4.3. "Transport Class" Route Target Extended Community 4.3. "Transport Class" Route Target Extended Community
skipping to change at page 15, line 45 skipping to change at page 15, line 45
This field contains the "Transport Class" identifier, This field contains the "Transport Class" identifier,
which is an unsigned 32-bit integer. which is an unsigned 32-bit integer.
This document reserves the Transport class ID value 0 to This document reserves the Transport class ID value 0 to
represent "Best Effort Transport Class ID". represent "Best Effort Transport Class ID".
Figure 2: "Transport Class" Route Target Extended Community Figure 2: "Transport Class" Route Target Extended Community
The VPN route import/export mechanisms specified in BGP/MPLS IP VPNs The VPN route import/export mechanisms specified in BGP/MPLS IP VPNs
[RFC4364] and the Constrained Route Distribution mechanisms specified [RFC4364] and the Constrained Route Distribution mechanisms specified
in Route Target Constrain [RFC4684] are applied using Route Target in Route Target Constrain [RFC4684] are applied using the Route Target
extendend community. These mechanisms are applied to BGP CT routes extended community. These mechanisms are applied to BGP CT routes
(AFI/SAFI: 1/76 or 2/76) using "Transport Class Route Target Extended (AFI/SAFI: 1/76 or 2/76) using "Transport Class Route Target Extended
community". community".
A BGP speaker that implements Route Target Constrain [RFC4684] MUST A BGP speaker that implements Route Target Constrain [RFC4684] MUST
also apply the RTC procedures to the Transport Class Route Target also apply the RTC procedures to the Transport Class Route Target
Extended communities carried on BGP CT routes (AFI/SAFI: 1/76 or Extended communities carried on BGP CT routes (AFI/SAFI: 1/76 or
2/76). An RTC route is generated for each Route Target imported by 2/76). An RTC route is generated for each Route Target imported by
locally provisioned Transport Classes. locally provisioned Transport Classes.
+--
jgs: if you really want to impose normative constraints on RTC
implementations, then I think you should add the Updates: header
for RFC 4684. You will also need to add something like the following
to your Abstract: "This document updates RFC 4684 by requiring that
its procedures be applied in the new context described herein."
But this seems awfully aspirational. We all know you can't go and
force old RTC implementations into compliance. Do you really mean
something like "implements RTC as well as this specification"? If you
made that change you could skip the Updates: business.
+--
Further, when processing RT membership NLRIs received from external Further, when processing RT membership NLRIs received from external
BGP peers, it is necessary to consider multiple EBGP paths for a BGP peers, it is necessary to consider multiple EBGP paths for a
given RTC prefix for building the outbound route filter, and not just given RTC prefix for building the outbound route filter, and not just
the best path. An implementation MAY provide configuration to the best path. An implementation MAY provide configuration to
control how many EBGP RTC paths are considered. control how many EBGP RTC paths are considered.
+--
jgs: again, the paragraph above skates pretty close to updating RFC
4684, but you could avoid that if you scope it to apply only to the
NLRI defined in the present spec.
+--
The Transport Class Route Target Extended community is carried on BGP The Transport Class Route Target Extended community is carried on BGP
CT family routes and is used to associate them with appropriate TRDBs CT family routes and is used to associate them with appropriate TRDBs
at receiving BGP speakers. The Transport Target is carried unaltered at receiving BGP speakers. The Transport Target is carried unaltered
on the BGP CT route across BGP CT negotiated sessions except for on the BGP CT route across BGP CT negotiated sessions except for
scenarios described in Section 11.2.2. Implementations should scenarios described in Section 11.2.2. Implementations should
provide policy mechanisms to perform match, strip, or rewrite provide policy mechanisms to perform match, strip, or rewrite
operations on a Transport Target just like any other BGP community. operations on a Transport Target just like any other BGP community.
Defining a new type code for the Transport Class Route Target Defining a new type code for the Transport Class Route Target
skipping to change at page 16, line 42 skipping to change at page 16, line 59
not used. If received, it is considered equivalent in functionality not used. If received, it is considered equivalent in functionality
to the Transitive Transport Class Route Target Extended Community, to the Transitive Transport Class Route Target Extended Community,
except for the difference in Transitive bit flag. except for the difference in Transitive bit flag.
5. Resolution Scheme 5. Resolution Scheme
A Resolution Scheme is a construct that consists of a specific TRDB A Resolution Scheme is a construct that consists of a specific TRDB
or an ordered set of TRDBs. An overlay route is associated with a or an ordered set of TRDBs. An overlay route is associated with a
resolution scheme during import processing, based on Mapping resolution scheme during import processing, based on Mapping
Community on the route. Community on the route.
+--
jgs: The final clause above needs some kind of edit. Maybe "... based
on the Mapping Community in the route."
+--
Resolution Schemes enable a BGP speaker to resolve next hop Resolution Schemes enable a BGP speaker to resolve next hop
reachability for overlay routes over the appropriate underlay tunnels reachability for overlay routes over the appropriate underlay tunnels
within the scope of the TRDBs. Longest Prefix Match (LPM) of the within the scope of the TRDBs. Longest Prefix Match of the
next hop is performed within the identified TRDB. next hop is performed within the identified TRDB.
An implementation may provide an option for the overlay route to An implementation may provide an option for the overlay route to
resolve over less preferred Transport Classes, should the resolution resolve over less preferred Transport Classes, should the resolution
over a primary Transport Class fail. over a primary Transport Class fail.
To accomplish this, the "Resolution Scheme" is configured with the To accomplish this, the "Resolution Scheme" is configured with the
primary Transport Class, and an ordered list of fallback Transport primary Transport Class, and an ordered list of fallback Transport
Classes. Two Resolution Schemes are considered equivalent in Intent Classes. Two Resolution Schemes are considered equivalent in Intent
if they consist of the same ordered set of TRDBs. if they consist of the same ordered set of TRDBs.
skipping to change at page 17, line 26 skipping to change at page 17, line 26
A "Mapping Community" is used to signal the desired Intent on an A "Mapping Community" is used to signal the desired Intent on an
overlay route. At an ingress node receiving the route, it maps the overlay route. At an ingress node receiving the route, it maps the
overlay route to a "Resolution Scheme" used to resolve the route's overlay route to a "Resolution Scheme" used to resolve the route's
next hop. next hop.
A Mapping Community is a "role" and not a new type of community; any A Mapping Community is a "role" and not a new type of community; any
BGP Community Carrying Attribute (e.g. Community or Extended BGP Community Carrying Attribute (e.g. Community or Extended
Community) may play this role, besides the other roles it may already Community) may play this role, besides the other roles it may already
be playing. For example, the Transport Class Route Target Extended be playing. For example, the Transport Class Route Target Extended
Community plays both roles of being a Route Target as well as a Community plays a dual role, being a Route Target as well as a
Mapping Community. Mapping Community.
Operator provisioning ensures that the ingress and egress SNs agree Operator provisioning ensures that the ingress and egress SNs agree
on the BGP CCA and community namespace to use for the Mapping on the BGP CCA and community namespace to use for the Mapping
Community. Community.
A Mapping Community maps to exactly one Resolution Scheme at A Mapping Community maps to exactly one Resolution Scheme at
receiving BGP speaker. An implementation SHOULD allow associating receiving BGP speaker. An implementation SHOULD allow associating
multiple Mapping Communities to a Resolution Scheme. This helps with multiple Mapping Communities to a Resolution Scheme. This helps with
renumbering and migration scenarios. renumbering and migration scenarios.
An example of mapping community is "color:0:100", described in An example of mapping community is "color:0:100", described in
[RFC9012], or the "transport-target:0:100" described in Section 4.3 [RFC9012], or the "transport-target:0:100" described in Section 4.3
in this document. in this document.
The order of communities on an overlay route does not affect the The order of communities on an overlay route does not affect the
determining of Mapping community in effect. determining of Mapping community in effect.
+--
jgs: I'm confused. The sentence above appears to completely conflict
with the sentence below.
+--
The first community on the overlay route that matches a Mapping The first community on the overlay route that matches a Mapping
Community of a locally configured Resolution Scheme is considered the Community of a locally configured Resolution Scheme is considered the
effective Mapping Community for the route. The Resolution Scheme effective Mapping Community for the route. The Resolution Scheme
thus found is used when resolving the route's PNH. If a route thus found is used when resolving the route's PNH. If a route
contains more than one Mapping Community, it indicates that the route contains more than one Mapping Community, it indicates that the route
considers these distinct Mapping Communities as equivalent in Intent. considers these distinct Mapping Communities as equivalent in Intent.
If more than one distinct Mapping Communities on an overlay route map If more than one distinct Mapping Communities on an overlay route map
to distinct Resolution Schemes with dissimilar Intents at a receiving to distinct Resolution Schemes with dissimilar Intents at a receiving
node, it is considered a configuration error. Operators should avoid node, it is considered a configuration error.
such configuration errors when attaching mapping communities on
overlay routes.
It should be noted that the Mapping Community role does not require It should be noted that the Mapping Community role does not require
applying Route Target Constrain procedures specified in RFC 4684. applying Route Target Constrain procedures specified in RFC 4684.
6. BGP Classful Transport Family 6. BGP Classful Transport Family
The BGP Classful Transport (BGP CT) family will use the existing The BGP Classful Transport (BGP CT) family uses the existing
Address Family Identifier (AFI) of IPv4 or IPv6 and a new SAFI 76 Address Family Identifier (AFI) of IPv4 or IPv6 and a new SAFI 76
"Classful Transport" that will applies to both IPv4 and IPv6 AFIs. "Classful Transport" that applies to both IPv4 and IPv6 AFIs.
The AFI/SAFI 1/76 MUST be negotiated as per the Multiprotocol The AFI/SAFI 1/76 MUST be negotiated as per the Multiprotocol
Extensions capability described in Section 8 of [RFC4760] to be able Extensions capability described in Section 8 of [RFC4760] to be able
to send and receive BGP CT routes for IPv4 endpoint prefixes. to send and receive BGP CT routes for IPv4 endpoint prefixes.
The AFI/SAFI 2/76 MUST be negotiated as per the Multiprotocol The AFI/SAFI 2/76 MUST be negotiated as per the Multiprotocol
Extensions capability described in Section 8 of [RFC4760] to be able Extensions capability described in Section 8 of [RFC4760] to be able
to send and receive BGP CT routes for IPv6 endpoint prefixes. to send and receive BGP CT routes for IPv6 endpoint prefixes.
6.1. NLRI Encoding 6.1. NLRI Encoding
skipping to change at page 18, line 47 skipping to change at page 18, line 45
The procedures described for AFI/SAFIs 1/4 or 1/128 in Section 2 of The procedures described for AFI/SAFIs 1/4 or 1/128 in Section 2 of
[RFC8277] apply for AFI/SAFI 1/76 also. The procedures described for [RFC8277] apply for AFI/SAFI 1/76 also. The procedures described for
AFI/SAFIs 2/4 or 2/128 in Section 2 of [RFC8277] apply for AFI/SAFI AFI/SAFIs 2/4 or 2/128 in Section 2 of [RFC8277] apply for AFI/SAFI
2/76 also. 2/76 also.
BGP CT routes MAY carry multiple labels in the NLRI, by negotiating BGP CT routes MAY carry multiple labels in the NLRI, by negotiating
the Multiple Labels Capability as described in Section 2.1 of the Multiple Labels Capability as described in Section 2.1 of
[RFC8277] [RFC8277]
Attributes on a Classful Transport route include the Transport Class Mandatory attributes of a Classful Transport route include the Transport Class
Route Target extended community, which is used to associate the route Route Target extended community, which is used to associate the route
with the correct TRDBs on SNs and BNs in the network and either an with the correct TRDBs on SNs and BNs in the network, and either an
IPv4 or an IPv6 next hop. IPv4 or an IPv6 next hop.
+--
jgs: I added "mandatory". That's right, isn't it? These have to be
included?
Also, the word "attributes" is a little unfortunate since the NH isn't
a path attribute, and since we're talking about BGP the reader might
automatically think "attribute" means PA. Our field has a bad habit of
overloading all the synonyms we might use, e.g. "trait", "characteristic",
etc. Still, please consider whether something can be done to make this
less ambiguous.
+--
6.2. Next Hop Encoding 6.2. Next Hop Encoding
When the length of the Next hop Address field is 4, the next hop When the length of the Next hop Address field is 4, the next hop
address is of type IPv4 address. address is of type IPv4 address.
When the length of Next hop Address field is 16 (or 32), the next hop When the length of Next hop Address field is 16 (or 32), the next hop
address is of type IPv6 address (potentially followed by the link- address is of type IPv6 address (potentially followed by the link-
local IPv6 address of the next hop). This follows Section 3 in local IPv6 address of the next hop). This follows Section 3 in
[RFC2545] [RFC2545]
skipping to change at page 20, line 37 skipping to change at page 20, line 37
In this document, SAFI 76 (BGP CT) is used instead of reusing SAFI In this document, SAFI 76 (BGP CT) is used instead of reusing SAFI
128 (L3VPN) for AFIs 1 or 2 to carry these transport routes because 128 (L3VPN) for AFIs 1 or 2 to carry these transport routes because
it is operationally advantageous to segregate transport and service it is operationally advantageous to segregate transport and service
prefixes into separate address families. For example, such an prefixes into separate address families. For example, such an
approach allows operators to safely enable "per-prefix" label approach allows operators to safely enable "per-prefix" label
allocation scheme for Classful Transport prefixes, typically with a allocation scheme for Classful Transport prefixes, typically with a
space complexity of O(1K) to O(100K), without affecting SAFI 128 space complexity of O(1K) to O(100K), without affecting SAFI 128
service prefixes with a space complexity of O(1M). The "per prefix" service prefixes with a space complexity of O(1M). The "per prefix"
label allocation scheme localizes routing churn during topology label allocation scheme localizes routing churn during topology
changes. changes.
+--
jgs: two things to flag about the above:
1. "typically" --> "typically (at time of writing)"
2. I know we tend to colloquially abuse O() to mean "more or less" but
https://en.wikipedia.org/wiki/Big_O_notation will remind you that
O(1k) == O(100k) == O(1m) ... they're all constant. If you want
to be colloquial that's fine but then try to avoid the use of formal
language, e.g. perhaps something like,
"... typically with a number of routes in the hundreds of thousands or
less, without affecting SAFI 128 service prefixes which may represent
millions of routes, at time of writing."
+--
Service routes continue to be carried in their existing AFI/SAFIs Service routes continue to be carried in their existing AFI/SAFIs
without any change. For example, L3VPN (AFI/SAFI: 1/128 and 2/128), without any change. For example, L3VPN (AFI/SAFI: 1/128 and 2/128),
EVPN (AFI/SAFI: 25/70 ), VPLS (AFI/SAFI: 25/65), Internet (AFI/SAFI: EVPN (AFI/SAFI: 25/70 ), VPLS (AFI/SAFI: 25/65), Internet (AFI/SAFI:
1/1 or 2/1). These service routes can resolve over BGP CT (AFI/SAFI: 1/1 or 2/1). These service routes can resolve over BGP CT (AFI/SAFI:
1/76 or 2/76) transport routes. 1/76 or 2/76) transport routes.
A new SAFI 76 for AFI 1 and AFI 2 also facilitates having a different A new SAFI 76 for AFI 1 and AFI 2 also facilitates having a different
readvertisement path of the transport family routes in a network than distribution path of the transport family routes in a network than
the service route readvertisement path. Service routes (Inet-VPN the service route distribution path. Service routes (Inet-VPN
SAFI 128) are exchanged over an EBGP multihop session between ASes SAFI 128) are exchanged over an EBGP multihop session between ASes
with next hop unchanged; whereas Classful Transport routes (SAFI 76) with next hop unchanged; whereas Classful Transport routes (SAFI 76)
are readvertised over EBGP single hop sessions with "next hop self" are advertised over EBGP single-hop sessions with "next hop self"
rewrite over inter-AS links. rewrite over inter-AS links.
The BGP CT SAFI 76 for AFI 1 and 2 is similar in vein to BGP LU SAFI The BGP CT SAFI 76 for AFI 1 and 2 is conceptually similar to BGP LU SAFI
4, in that it carries transport prefixes. The only difference is 4, in that it carries transport prefixes. The only difference is
that it also carries in a Route Target an indication of which that it also carries in a Route Target an indication of which
Transport Class the transport prefix belongs to, and uses the RD to Transport Class the transport prefix belongs to, and uses the RD to
disambiguate multiple instances of the same transport prefix in a BGP disambiguate multiple instances of the same transport prefix in a BGP
Update. Update.
7. Protocol Procedures 7. Protocol Procedures
This section summarizes the procedures followed by various nodes This section summarizes the procedures followed by various nodes
speaking Classful Transport family. speaking Classful Transport family.
skipping to change at page 23, line 24 skipping to change at page 23, line 24
7.4. Readvertising Classful Transport Route by Border Nodes 7.4. Readvertising Classful Transport Route by Border Nodes
This section describes the MPLS label handling when readvertising This section describes the MPLS label handling when readvertising
a BGP CT route with Next Hop set to Self. When readvertising a a BGP CT route with Next Hop set to Self. When readvertising a
BGP CT route with Next Hop set to Self, a BN allocates an MPLS BGP CT route with Next Hop set to Self, a BN allocates an MPLS
label to advertise upstream in Classful Transport NLRI. The BN label to advertise upstream in Classful Transport NLRI. The BN
also installs an MPLS route for that label that swaps the incoming also installs an MPLS route for that label that swaps the incoming
label with the label received from the downstream BGP speaker (or label with the label received from the downstream BGP speaker (or
pops the incoming label if the label received from the downstream pops the incoming label if the label received from the downstream
BGP speaker was Implicit-NULL). It then pushes received traffic BGP speaker was Implicit-NULL). The MPLS route then pushes received traffic
to the transport tunnel or direct interface that the Classful to the transport tunnel or direct interface that the Classful
Transport route's PNH resolved over. Transport route's PNH resolved over.
+--
jgs: I suggested a change to clarify what is meant by "it". If I got the
referent of "it" wrong, let's discuss.
+--
The label SHOULD be allocated with "per-prefix" label allocation The label SHOULD be allocated with "per-prefix" label allocation
semantics. The IP prefix in the TRDB context (Transport-Class, semantics. The IP prefix in the TRDB context (Transport-Class,
IP-prefix) is used as the key to do per-prefix label allocation. IP-prefix) is used as the key to do per-prefix label allocation.
This helps in avoiding BGP CT route churn throughout the CT This helps in avoiding BGP CT route churn throughout the CT
network when an instability (e.g., link failure) is experienced in network when an instability (e.g., link failure) is experienced in
a domain. The failure is not propagated further than the BN a domain. The failure is not propagated further than the BN
closest to the failure. If a different label allocation mode is closest to the failure. If a different label allocation mode is
used, the impact on end to end convergence should be considered. used, the impact on end to end convergence should be considered.
skipping to change at page 26, line 24 skipping to change at page 26, line 24
Mapping Community, and absent local policy, the best effort Mapping Community, and absent local policy, the best effort
resolution scheme is used for resolving the BGP next hop on the resolution scheme is used for resolving the BGP next hop on the
route. This behavior is backward compatible to behavior of an route. This behavior is backward compatible to behavior of an
implementation that does not follow procedures described in this implementation that does not follow procedures described in this
document. document.
Implementations MAY provide configuration to selectively install Implementations MAY provide configuration to selectively install
BGP CT routes to the Forwarding Information Base (FIB), to provide BGP CT routes to the Forwarding Information Base (FIB), to provide
reachability for control plane peering towards endpoints in other reachability for control plane peering towards endpoints in other
domains. domains.
+--
jgs: I found the preceding paragraph a little startling. In general,
are BGP CT routes not installed in a forwarding information base? Are
you drawing a distinction between *a* FIB (which might be a VRF) and
*the* FIB, i.e. the "normal" IP forwarding table?
In any case a few more words around this might have helped me.
+--
7.10. Interaction with BGP Attributes Specifying Next Hop Address and 7.10. Interaction with BGP Attributes Specifying Next Hop Address and
Color Color
The Tunnel Encapsulation Attribute, described in [RFC9012] can be The Tunnel Encapsulation Attribute, described in [RFC9012] can be
used to request a specific type of tunnel encapsulation. This used to request a specific type of tunnel encapsulation. This
attribute may apply to BGP service routes or transport routes, attribute may apply to BGP service routes or transport routes,
including BGP Classful Transport family routes. including BGP Classful Transport family routes.
It should be noted that in such cases "Transport Class ID/Color" can It should be noted that in such cases "Transport Class ID/Color" can
exist in multiple places on the same route, and a precedence order exist in multiple places on the same route, and a precedence order
needs to be established to determine which Transport Class the needs to be established to determine which Transport Class the
route's next hop should resolve over. This document suggests the route's next hop should resolve over. This document suggests the
+--
jgs: Is it just a suggestion though? It seems not to be (see "expected"
in the final paragraph).
Perhaps "specifies", and if what you're trying to capture is that
the order could be changed by configuration, say something to that
effect.
+--
following order of precedence, more specific scoping of Color following order of precedence, more specific scoping of Color
preferred to less specific scoping: preferred to less specific scoping:
Color SubTLV, in Tunnel Encapsulation Attribute. Color SubTLV, in Tunnel Encapsulation Attribute.
Transport Target Extended community, on BGP CT route. Transport Target Extended community, on BGP CT route.
Color Extended community, on BGP service route. Color Extended community, on BGP service route.
Color specified in the Color subTLV in a TEA is a more specific Color specified in the Color subTLV in a TEA is a more specific
skipping to change at page 27, line 23 skipping to change at page 27, line 23
Such Flowspec BGP routes with Redirect to IP next hop MAY be attached Such Flowspec BGP routes with Redirect to IP next hop MAY be attached
with a Mapping Community (e.g. Color:0:100), which allows with a Mapping Community (e.g. Color:0:100), which allows
redirecting the flow traffic over a tunnel to the IP next hop redirecting the flow traffic over a tunnel to the IP next hop
satisfying the desired SLA (e.g. Transport Class color 100). satisfying the desired SLA (e.g. Transport Class color 100).
Flowspec BGP family acts as just another service that can make use of Flowspec BGP family acts as just another service that can make use of
BGP CT architecture to achieve Flow based forwarding with SLAs. BGP CT architecture to achieve Flow based forwarding with SLAs.
7.12. Applicability to IPv6 7.12. Applicability to IPv6
+--
jgs: I found it a little surprising/lacking in symmetry to have this
section without a corresponding "Applicability to IPv4" section. I
expect you might get a similar remark from the INT ADs.
You might consider adding a prefatory paragraph stating why it makes
sense to do it this way. (Or not. I don't insist.)
+--
This section describes applicability of BGP CT to IPv6 at various This section describes applicability of BGP CT to IPv6 at various
layers. BGP CT procedures apply equally to an IPv6 enabled Intra-AS layers. BGP CT procedures apply equally to an IPv6 enabled Intra-AS
or Inter-AS Option A, B, C network. or Inter-AS Option A, B, C network.
A BGP CT enabled network supports IPv6 service families (for example, A BGP CT enabled network supports IPv6 service families (for example,
AFI/SAFI 2/1 or 2/128) and IPv6 transport signaling protocols like AFI/SAFI 2/1 or 2/128) and IPv6 transport signaling protocols like
SRTEv6, LDPv6, RSVP-TEv6. SRTEv6, LDPv6, RSVP-TEv6.
Procedures in this document also apply to a network with Pure IPv6 Procedures in this document also apply to a network with Pure IPv6
skipping to change at page 28, line 8 skipping to change at page 28, line 8
IPv6 address tunnel endpoints in the NLRI. IPv6 Service family IPv6 address tunnel endpoints in the NLRI. IPv6 Service family
routes (for example, AFI/SAFI: 2/1, 2/128) are also advertised with routes (for example, AFI/SAFI: 2/1, 2/128) are also advertised with
those IPv4 Mapped IPv6 addresses as next hop. those IPv4 Mapped IPv6 addresses as next hop.
The PE-CE attachment circuits may use IPv4 addresses only, IPv6 The PE-CE attachment circuits may use IPv4 addresses only, IPv6
addresses only, or both IPv4 and IPv6 addresses. addresses only, or both IPv4 and IPv6 addresses.
7.13. SRv6 Support 7.13. SRv6 Support
This section describes how BGP CT family (AFI/SAFI 2/76) may be used This section describes how BGP CT family (AFI/SAFI 2/76) may be used
+--
jgs: "this section describes". No, it doesn't, or if so it only does so
by reference. I think you can fix this by deleting "This section describes
how"; after that change, the section stands.
+--
to set up inter-domain tunnels of a certain Transport Class, when to set up inter-domain tunnels of a certain Transport Class, when
using Segment Routing over IPv6 (SRv6) data plane on the inter-AS using Segment Routing over IPv6 (SRv6) data plane on the inter-AS
links or as an intra-AS tunneling mechanism. links or as an intra-AS tunneling mechanism.
Details of SRv6 Endpoint behaviors used by BGP CT and the procedures Details of SRv6 Endpoint behaviors used by BGP CT and the procedures
are specified in a separate document [BGP-CT-SRv6], along with are specified in a separate document [BGP-CT-SRv6], along with
illustration. As noted in this document, BGP CT route update for illustration. As noted in this document, BGP CT route update for
+--
jgs: does "this document" refer to BGP-CT-SRv6? If so, change it to
"that document" or even "BGP-CT-SRv6".
+--
SRv6 includes a BGP attribute containing SRv6 SID information (e.g. SRv6 includes a BGP attribute containing SRv6 SID information (e.g.
Prefix SID [RFC9252]) with Transposition scheme disabled. Prefix SID [RFC9252]) with Transposition scheme disabled.
7.14. Error Handling Considerations 7.14. Error Handling Considerations
If a BGP speaker receives both Transitive (Section 13.2.1.1.1) and If a BGP speaker receives both Transitive (Section 13.2.1.1.1) and
Non-Transitive (Section 13.2.1.1.2) versions of Transport Class Non-Transitive (Section 13.2.1.1.2) versions of Transport Class
extended community on a route, only the Transitive one is used. extended community on a route, only the Transitive one is used.
If a BGP speaker considers a received "Transport Class" extended If a BGP speaker considers a received "Transport Class" extended
skipping to change at page 28, line 41 skipping to change at page 28, line 50
8. Illustration of BGP CT Procedures 8. Illustration of BGP CT Procedures
This section illustrates BGP CT procedures in an Inter AS Option C This section illustrates BGP CT procedures in an Inter AS Option C
MPLS network. MPLS network.
All Illustrations in this document make use of [RFC6890] IP address All Illustrations in this document make use of [RFC6890] IP address
ranges. The range 192.0.2.0/24 is used to represent transport ranges. The range 192.0.2.0/24 is used to represent transport
endpoints like loopback addresses. The range 203.0.113.0/24 is used endpoints like loopback addresses. The range 203.0.113.0/24 is used
to represent service route prefixes advertised in AFI/SAFIs: 1/1 or to represent service route prefixes advertised in AFI/SAFIs: 1/1 or
1/128. 1/128.
+--
jgs: You will probably get (non-blocking) complaints from one of the INT
ADs about use of IPv4 instead of IPv6 for examples. You could consider
adding a sentence or two acknowledging that the examples could also have
been done using IPv6 ranges (although they weren't).
+--
8.1. Reference Topology 8.1. Reference Topology
[RR26] [RR27] [RR16] [RR26] [RR27] [RR16]
| | | | | |
| | | | | |
|+-[ABR23]--+|+--[ASBR21]---[ASBR13]-+|+--[PE11]--+ |+-[ABR23]--+|+--[ASBR21]---[ASBR13]-+|+--[PE11]--+
|| ||| ` / ||| | || ||| ` / ||| |
[CE41]--[PE25]--[P28] [P29] `/ [P15] [CE31] [CE41]--[PE25]--[P28] [P29] `/ [P15] [CE31]
| | | /` | | | | | | /` | | |
skipping to change at page 32, line 7 skipping to change at page 32, line 7
The RD value originated by an egress node is not modified by any BGP The RD value originated by an egress node is not modified by any BGP
speakers when the route is readvertised to the ingress node. Thus, speakers when the route is readvertised to the ingress node. Thus,
the RD can be used to identify the originator (unique RD provisioned) the RD can be used to identify the originator (unique RD provisioned)
or set of originators (RD reused on multiple nodes). or set of originators (RD reused on multiple nodes).
Similarly, these transport classes are also configured on ASBRs, ABRs Similarly, these transport classes are also configured on ASBRs, ABRs
and PEs with same Transport Route Target and unique RDs. and PEs with same Transport Route Target and unique RDs.
ASBR13 and ASBR14 negotiate BGP CT family with transport ASBRs ASBR13 and ASBR14 negotiate BGP CT family with transport ASBRs
ASBR21, ASBR22 in neighboring AS. They negotiate BGP CT family with ASBR21, ASBR22 in neighboring AS. They negotiate BGP CT family with
+--
jgs: The referent of "they" above is unclear. Do you mean ASBR21, ASBR22?
Probably better to spell it out instead of using the pronoun.
+--
RR27 in region 2, which reflects BGP CT routes to ABR23, ABR24. RR27 in region 2, which reflects BGP CT routes to ABR23, ABR24.
ABR23, ABR24 negotiate BGP CT family with Ingress node PE25 in region ABR23, ABR24 negotiate BGP CT family with Ingress node PE25 in region
1. BGP LU family is also negotiated on these sessions alongside BGP 1. BGP LU family is also negotiated on these sessions alongside BGP
CT family. BGP LU carries "best effort" transport class routes, BGP CT family. BGP LU carries "best effort" transport class routes, BGP
CT carries Gold, Bronze transport class routes. CT carries Gold, Bronze transport class routes.
PE11 is provisioned to originate BGP CT route with Gold SLA to PE11 is provisioned to originate BGP CT route with Gold SLA to
endpoint PE11. This route is sent with NLRI RD prefix endpoint PE11. This route is sent with NLRI RD prefix
+--
jgs: I find the first sentence of this paragraph ambiguous/unclear.
Do you mean "PE11 is provisioned to originate a BGP CT route for an
address of PE11, with Gold SLA"?
+--
192.0.2.11:100:192.0.2.11, Label B-L0, next hop 192.0.2.11 and a 192.0.2.11:100:192.0.2.11, Label B-L0, next hop 192.0.2.11 and a
route target extended community transport-target:0:100. Label B-L0 route target extended community transport-target:0:100. Label B-L0
can either be Implicit Null (Label 3) or an Ultimate Hop Pop (UHP) can either be Implicit Null (Label 3) or an Ultimate Hop Pop (UHP)
label. label.
This route is received by ASBR13 and it resolves over the tunnel This route is received by ASBR13 and it resolves over the tunnel
ASBR13_to_PE11_gold. The route is then readvertised by ASBR13 in BGP ASBR13_to_PE11_gold. The route is then readvertised by ASBR13 in BGP
CT family to ASBRs ASBR21, ASBR22 according to export policy. This CT family to ASBRs ASBR21, ASBR22 according to export policy. This
route is sent with same NLRI RD prefix 192.0.2.11:100:192.0.2.11, route is sent with same NLRI RD prefix 192.0.2.11:100:192.0.2.11,
Label B-L1, next hop self, and transport-target:0:100. MPLS swap Label B-L1, next hop self, and transport-target:0:100. MPLS swap
skipping to change at page 32, line 39 skipping to change at page 32, line 48
192.0.2.11:100:192.0.2.11 from PE11 and it resolves over the tunnel 192.0.2.11:100:192.0.2.11 from PE11 and it resolves over the tunnel
ASBR14_to_PE11_gold. The route is then readvertised by ASBR14 in BGP ASBR14_to_PE11_gold. The route is then readvertised by ASBR14 in BGP
CT family to ASBRs ASBR21, ASBR22 according to export policy. This CT family to ASBRs ASBR21, ASBR22 according to export policy. This
route is sent with the same NLRI RD prefix 192.0.2.11:100:192.0.2.11, route is sent with the same NLRI RD prefix 192.0.2.11:100:192.0.2.11,
Label B-L2, next hop self, and transport-target:0:100. MPLS swap Label B-L2, next hop self, and transport-target:0:100. MPLS swap
route is installed at ASBR14 for B-L1 with a next hop pointing to route is installed at ASBR14 for B-L1 with a next hop pointing to
ASBR14_to_PE11_gold tunnel. ASBR14_to_PE11_gold tunnel.
In the Bronze plane, BGP CT route with Bronze SLA to endpoint PE11 is In the Bronze plane, BGP CT route with Bronze SLA to endpoint PE11 is
originated by PE11 with a NLRI containing RD prefix originated by PE11 with a NLRI containing RD prefix
192.0.2.11:200:192.0.2.11, and appropriate label. The RD allows both 192.0.2.11:200:192.0.2.11, and appropriate label. The use of distinct
RDs for Gold and Bronze allows both
Gold and Bronze advertisements to traverse path selection pinchpoints Gold and Bronze advertisements to traverse path selection pinchpoints
without any path hiding at RRs or ASBRs. And route target extended without any path hiding at RRs or ASBRs. And route target extended
community transport-target:0:200 lets the route resolve over Bronze community transport-target:0:200 lets the route resolve over Bronze
tunnels in the network, similar to the process being described for tunnels in the network, similar to the process being described for
Gold SLA path. Gold SLA path.
Moving back to the Gold plane, ASBR21 receives the Gold SLA BGP CT Moving back to the Gold plane, ASBR21 receives the Gold SLA BGP CT
routes for NLRI RD prefix 192.0.2.11:100:192.0.2.11 over the single routes for NLRI RD prefix 192.0.2.11:100:192.0.2.11 over the single
hop EBGP sessions from ASBR13, ASBR14, and can compute ECMP/FRR hop EBGP sessions from ASBR13, ASBR14, and can compute ECMP/FRR
towards them. ASBR21 readvertises BGP CT route for towards them. ASBR21 readvertises BGP CT route for
192.0.2.11:100:192.0.2.11 with next hop self (loopback address 192.0.2.11:100:192.0.2.11 with next hop self (loopback address
192.0.2.21) to RR27, advertising a new label B-L3. An MPLS swap 192.0.2.21) to RR27, advertising a new label B-L3. An MPLS swap
route is installed for label B-L3 at ASBR21 to swap to received label route is installed for label B-L3 at ASBR21 to swap to received label
B-L1, B-L2 and forward to ASBR13, ASBR14 respectively. RR27 B-L1, B-L2 and forward to ASBR13, ASBR14 respectively. RR27
+--
jgs: It might be worth pointing out something like "(this is an ECMP
route)".
+--
readvertises this BGP CT route to ABR23, ABR24 with label and next readvertises this BGP CT route to ABR23, ABR24 with label and next
hop unchanged. hop unchanged.
Similarly, ASBR22 receives BGP CT route 192.0.2.11:100:192.0.2.11 Similarly, ASBR22 receives BGP CT route 192.0.2.11:100:192.0.2.11
over the single hop EBGP sessions from ASBR13, ASBR14, and over the single hop EBGP sessions from ASBR13, ASBR14, and
readvertises with next hop self (loopback address 192.0.2.22) to readvertises with next hop self (loopback address 192.0.2.22) to
RR27, advertising a new label B-L4. An MPLS swap route is installed RR27, advertising a new label B-L4. An MPLS swap route is installed
for label B-L4 at ASBR22 to swap to received label B-L1, B-L2 and for label B-L4 at ASBR22 to swap to received label B-L1, B-L2 and
forward to ASBR13, ASBR14 respectively. RR27 readvertises this BGP forward to ASBR13, ASBR14 respectively. RR27 readvertises this BGP
CT route also to ABR23, ABR24 with label and next hop unchanged. CT route also to ABR23, ABR24 with label and next hop unchanged.
skipping to change at page 35, line 23 skipping to change at page 35, line 23
alternate path exists. alternate path exists.
Assuming ASBR22_to_ASBR13 link goes down, such that traffic with Gold Assuming ASBR22_to_ASBR13 link goes down, such that traffic with Gold
SLA going to PE11 needs repair. ASBR22 has an alternate BGP CT route SLA going to PE11 needs repair. ASBR22 has an alternate BGP CT route
for 192.0.2.11:100:192.0.2.11 from ASBR14. This has been for 192.0.2.11:100:192.0.2.11 from ASBR14. This has been
preprogrammed in forwarding by ASBR22 as FRR backup next hop for preprogrammed in forwarding by ASBR22 as FRR backup next hop for
label B-L4. This allows the Gold SLA traffic to be locally repaired label B-L4. This allows the Gold SLA traffic to be locally repaired
at ASBR22 without the failure event propagated in the BGP CT network. at ASBR22 without the failure event propagated in the BGP CT network.
In this case, ingress node PE25 will not know there was a failure, In this case, ingress node PE25 will not know there was a failure,
and traffic restoration will be independent of prefix scale (PIC). and traffic restoration will be independent of prefix scale (PIC).
+--
jgs: I suggested glossing PIC although since you only use it 2x, you could
also just move the inline expansion you do later, to this location.
+--
8.4.3. Absorbing Failure of Primary Path: Fallback to Best Effort 8.4.3. Absorbing Failure of Primary Path: Fallback to Best Effort
Tunnels Tunnels
This section describes how the data plane reacts when a Gold path This section describes how the data plane reacts when a Gold path
experiences a failure, but no alternate path exists. experiences a failure, but no alternate path exists.
Assume tunnel ABR23_to_ASBR22_gold goes down, such that now no end- Assume tunnel ABR23_to_ASBR22_gold goes down, such that now no end-
to-end Gold path exists in the network. This makes the BGP CT route to-end Gold path exists in the network. This makes the BGP CT route
for RD prefix 192.0.2.11:100:192.0.2.11 is unusable at ABR23. This for RD prefix 192.0.2.11:100:192.0.2.11 is unusable at ABR23. This
skipping to change at page 36, line 42 skipping to change at page 36, line 42
Note that such use of the IP address specific route target Note that such use of the IP address specific route target
<eSN>:<TC> is optional in a BGP CT network. It is required only <eSN>:<TC> is optional in a BGP CT network. It is required only
if there is a requirement to prune the propagation of the if there is a requirement to prune the propagation of the
transport route for an egress node eSN to only the set of ingress transport route for an egress node eSN to only the set of ingress
nodes that need it. When only RT of transport-target:0:<TC> is nodes that need it. When only RT of transport-target:0:<TC> is
used, the pruning happens in granularity of Transport Class ID used, the pruning happens in granularity of Transport Class ID
(Color), and not BGP next hop; BGP CT routes will not be (Color), and not BGP next hop; BGP CT routes will not be
advertised into domains with PEs that don't import its transport advertised into domains with PEs that don't import its transport
class. class.
+--
jgs: Two things about the final clause above:
1. Isn't this true only if RTC is in use?
2. In any case it's wrong as written, should be "a BGP CT route will only
be advertised into a domain with at least one PE that imports its transport
class" -- right?
+--
The transport-target:0:<TC> is the new type of route target The transport-target:0:<TC> is the new type of route target
(Transport Class RT) defined in this document. It is carried in (Transport Class RT) defined in this document. It is carried in
BGP extended community attribute (BGP attribute code 16). BGP extended community attribute (BGP attribute code 16).
The RT carrying <eSN>:<TC> MAY be an IP-address specific regular The RT carrying <eSN>:<TC> MAY be an IP-address specific regular
RT (BGP attribute code 16), or IPv6-address specific RT (BGP RT (BGP attribute code 16), or IPv6-address specific RT (BGP
attribute code 25). It should be noted that the Local attribute code 25). It should be noted that the Local
Administrator field of these RTs can only carry two octets of Administrator field of these RTs can only carry two octets of
information, and thus the <TC> field in this approach is limited information, and thus the <TC> field in this approach is limited
to a 2 octets value. Future protocol extensions work is needed to to a 2 octets value. Future protocol extensions work is needed to
define a BGP CCA that can accomodate an IPv4/IPv6 address along define a BGP CCA that can accomodate an IPv4/IPv6 address along
with a 4 octet Local Administrator field. with a 4 octet Local Administrator field.
An ingress SN MAY import BGP CT routes with Route Target carrying An ingress SN MAY import BGP CT routes with Route Target carrying
<eSN>:<TC>. The ingress SN may learn the eSN values either by <eSN>:<TC>. The ingress SN may learn the eSN values either by
configuration, or it may discover them from the BGP next hop field configuration, or it may discover them from the BGP next hop field
in the BGP VPN service routes received from eSN. A BGP ingress SN in the BGP VPN service routes received from eSN. A BGP ingress SN
receiving a BGP service route with next hop of eSN generates a receiving a BGP service route with next hop of eSN and origin
autonomous system "Origin ASN" generates a
RTC/Extended-RTC route for Route Target prefix <Origin RTC/Extended-RTC route for Route Target prefix <Origin
+--
jgs: what is Extended-RTC?!?
+--
ASN>:<eSN>/[80|176] in order to learn BGP CT transport routes to ASN>:<eSN>/[80|176] in order to learn BGP CT transport routes to
reach eSN. This allows constrained distribution of the transport reach eSN. This allows constrained distribution of the transport
routes to the PNHs actually required by iSN. routes to the PNHs actually required by iSN.
When the path of route propagation of BGP CT routes is the same as When the path of route propagation of BGP CT routes is the same as
the RTC routes, a BN would learn the RTC routes advertised by the RTC routes, a BN would learn the RTC routes advertised by
+--
jgs: when RTC is in use, the path of propagation WILL be the same, right?
So is the first clause just a weird way of saying that? I think it is
not the most direct way to say it, if so. Perhaps something like, "When
RTC is in use as described here, BGP CT routes will be constrained to
follow the same path of propagation as the RTC routes. Therefore, a BN
would..."
Or am I mistaken?
+--
ingress SNs and propagate further. This will allow constraining ingress SNs and propagate further. This will allow constraining
distribution of BGP CT routes for a PNH to only the necessary BNs distribution of BGP CT routes for a PNH to only the necessary BNs
in the network, closer to the egress SN. in the network, closer to the egress SN.
This mechanism provides "On Demand Next hop" of BGP CT routes, This mechanism provides "On Demand Next hop" of BGP CT routes,
which help with the scaling of MPLS forwarding state at SN and BN. which help with the scaling of MPLS forwarding state at SN and BN.
However, the amount of state carried in RTC family may become However, the amount of state carried in RTC family may become
proportional to the number of PNHs in the network. To strike a proportional to the number of PNHs in the network. To strike a
balance, the RTC route advertisements for <Origin balance, the RTC route advertisements for <Origin
skipping to change at page 37, line 49 skipping to change at page 38, line ?
Such a BN in the core of the network imports BGP CT routes with Such a BN in the core of the network imports BGP CT routes with
Transport-Target:0:<TC> and generates an RTC route for <Origin Transport-Target:0:<TC> and generates an RTC route for <Origin
ASN>:0:<TC>/96, while not propagating the more specific RTC ASN>:0:<TC>/96, while not propagating the more specific RTC
requests for specific PNHs. This lets the BN learn transport requests for specific PNHs. This lets the BN learn transport
routes to all eSN nodes but confine their propagation to ingress routes to all eSN nodes but confine their propagation to ingress
SNs. SNs.
9.3. Limiting The Visibility Scope of PE Loopback as PNHs 9.3. Limiting The Visibility Scope of PE Loopback as PNHs
It may be even more desirable to limit the number of PNHs that are It may be even more desirable to limit the number of PNHs that are
globally visible in the network. This is possible using mechanism globally visible in the network. This is possible using the mechanism
described in Appendix D. described in Appendix D, such that advertisement of PE loopback
addresses as next-hop in
Such that advertisement of PE loopback addresses as next-hop in
BGP service routes is confined to the region they belong to. An BGP service routes is confined to the region they belong to. An
anycast IP-address called "Context Protocol Nexthop Address" anycast IP-address called "Context Protocol Nexthop Address"
(CPNH) abstracts the SNs in a region from other regions in the (CPNH) abstracts the SNs in a region from other regions in the
network. network.
+--
jgs: If the edit above is wrong, please help me understand what you do
intend.
+--
This provides much greater advantage in terms of scaling, This provides much greater advantage in terms of scaling,
convergence and security. Changes to implement this feature are convergence and security. Changes to implement this feature are
required only on the local region's BNs and RRs, so legacy PE required only on the local region's BNs and RRs, so legacy PE
devices can also benefit from this approach. devices can also benefit from this approach.
10. Operations and Manageability Considerations 10. Operations and Manageability Considerations
10.1. MPLS OAM 10.1. MPLS OAM
skipping to change at page 46, line 27 skipping to change at page 46, line 27
it maps to color 101 TRDB. it maps to color 101 TRDB.
Similarly, service routes advertised by PE31 that need to resolve Similarly, service routes advertised by PE31 that need to resolve
over Gold2 transport tunnels carry a mapping community color:0:102. over Gold2 transport tunnels carry a mapping community color:0:102.
In AS3 and AS1, where Gold2 is not available, it is mapped to color In AS3 and AS1, where Gold2 is not available, it is mapped to color
100 TRDB using a customized resolution scheme. In AS2, Gold2 is 100 TRDB using a customized resolution scheme. In AS2, Gold2 is
available and it maps to color 102 TRDB. available and it maps to color 102 TRDB.
To facilitate this mapping, every SN/BN in all AS provisioning To facilitate this mapping, every SN/BN in all AS provisioning
required transport classes, viz. 100, 101 and 102. SN and BN in AS1 required transport classes, viz. 100, 101 and 102. SN and BN in AS1
+--
jgs: I don't understand the sentence above.
+--
and AS3 are provisioned with customized resolution schemes that and AS3 are provisioned with customized resolution schemes that
resolve routes with transport-target:0:101 or transport-target:0:102 resolve routes with transport-target:0:101 or transport-target:0:102
strictly over color 100 TRDB. strictly over color 100 TRDB.
PE31 is provisioned to originate BGP CT route with color 101 for PE31 is provisioned to originate BGP CT route with color 101 for
endpoint PE31. This route is sent with NLRI RD prefix RD1:PE31 and endpoint PE31. This route is sent with NLRI RD prefix RD1:PE31 and
route target extended community transport-target:0:101. route target extended community transport-target:0:101.
Similarly, PE31 is provisioned to originate BGP CT route with color Similarly, PE31 is provisioned to originate BGP CT route with color
102 for endpoint PE31. This route is sent with NLRI RD prefix 102 for endpoint PE31. This route is sent with NLRI RD prefix
skipping to change at page 54, line 7 skipping to change at page 54, line 7
Furthermore, the NSC can use the Mapping Community on the service Furthermore, the NSC can use the Mapping Community on the service
route to map traffic to the desired IETF Network Slice. route to map traffic to the desired IETF Network Slice.
13. IANA Considerations 13. IANA Considerations
This document makes the following requests of IANA. This document makes the following requests of IANA.
13.1. New BGP SAFI 13.1. New BGP SAFI
IANA is requested to assign a new BGP SAFI code for "Classful IANA has assigned a BGP SAFI code for "Classful
Transport". Value 76. Transport". Value 76. IANA is requested to update
the reference to this document.
Registry Group: Subsequent Address Family Identifiers (SAFI) Parameters Registry Group: Subsequent Address Family Identifiers (SAFI) Parameters
Registry Name: SAFI Values Registry Name: SAFI Values
Value Description Value Description
-------------+-------------------------- -------------+--------------------------
76 Classful Transport SAFI 76 Classful Transport SAFI
This will be used to create new AFI,SAFI pairs for IPv4, IPv6 This will be used to create new AFI,SAFI pairs for IPv4, IPv6
Classful Transport families. viz: Classful Transport families. viz:
* "IPv4, Classful Transport". AFI/SAFI = "1/76" for carrying IPv4 * "IPv4, Classful Transport". AFI/SAFI = "1/76" for carrying IPv4
Classful Transport prefixes. Classful Transport prefixes.
* "IPv6, Classful Transport". AFI/SAFI = "2/76" for carrying IPv6 * "IPv6, Classful Transport". AFI/SAFI = "2/76" for carrying IPv6
Classful Transport prefixes. Classful Transport prefixes.
13.2. New Format for BGP Extended Community 13.2. New Format for BGP Extended Community
IANA is requested to assign a new Format type (Type high = 0xa) of IANA has assigned a Format type (Type high = 0xa) of
Extended Community EXT-COMM [RFC4360] for Transport Class from the Extended Community EXT-COMM [RFC4360] for Transport Class from the
following registries: following registries:
the "BGP Transitive Extended Community Types" registry, and the "BGP Transitive Extended Community Types" registry, and
the "BGP Non-Transitive Extended Community Types" registry. the "BGP Non-Transitive Extended Community Types" registry.
Please assign the same low-order six bits for both allocations. Please the same low-order six bits have been assigned for both allocations.
IANA is requested to update the references to this document.
This document uses this new Format with subtype 0x2 (route target), This document uses this new Format with subtype 0x2 (route target),
as a transitive extended community. The Route Target thus formed is as a transitive extended community. The Route Target thus formed is
called "Transport Class" route target extended community. called "Transport Class" route target extended community.
The Non-Transitive Transport Class Extended community with subtype The Non-Transitive Transport Class Extended community with subtype
0x2 (route target) is called the "Non-Transitive Transport Class 0x2 (route target) is called the "Non-Transitive Transport Class
route target extended community". route target extended community".
Taking reference of [RFC7153] , following requests are made: Taking reference of [RFC7153] , the following assignments have been made:
13.2.1. Existing Registries to be Modified 13.2.1. Existing Registries
13.2.1.1. Registries for the "Type" Field 13.2.1.1. Registries for the "Type" Field
13.2.1.1.1. Transitive Types 13.2.1.1.1. Transitive Types
This registry contains values of the high-order octet (the "Type" This registry contains values of the high-order octet (the "Type"
field) of a Transitive Extended Community. field) of a Transitive Extended Community.
Registry Group: Border Gateway Protocol (BGP) Extended Communities Registry Group: Border Gateway Protocol (BGP) Extended Communities
Registry Name: BGP Transitive Extended Community Types Registry Name: BGP Transitive Extended Community Types
skipping to change at page 56, line 49 skipping to change at page 56, line 49
-----------------+---------------------------- -----------------+----------------------------
0x00-0xBF First Come First Served 0x00-0xBF First Come First Served
0xC0-0xFF IETF Review 0xC0-0xFF IETF Review
Sub-Type Value Name Sub-Type Value Name
-----------------+-------------- -----------------+--------------
0x02 Route Target 0x02 Route Target
13.3. MPLS OAM Code Points 13.3. MPLS OAM Code Points
The following two code points are sought for Target FEC Stack sub- The following two code points have been assigned for Target FEC Stack sub-
TLVs: TLVs:
* IPv4 BGP Classful Transport * IPv4 BGP Classful Transport
* IPv6 BGP Classful Transport * IPv6 BGP Classful Transport
Registry Group: Multiprotocol Label Switching (MPLS) Registry Group: Multiprotocol Label Switching (MPLS)
Label Switched Paths (LSPs) Ping Parameters Label Switched Paths (LSPs) Ping Parameters
Registry Name: Sub-TLVs for TLV Types 1, 16, and 21 Registry Name: Sub-TLVs for TLV Types 1, 16, and 21
Sub-Type Name Sub-Type Name
-----------------+------------------------------ -----------------+------------------------------
31744 IPv4 BGP Classful Transport 31744 IPv4 BGP Classful Transport
31745 IPv6 BGP Classful Transport 31745 IPv6 BGP Classful Transport
IANA is requested to update
the references to this document.
13.4. Transport Class ID 13.4. Transport Class ID
+--
jgs: I don't understand why we need this "registry". AFAICT once
published it will be a read-only artifact: 0 is already assigned,
and all the rest of the code points are off limits.
To look at a recent example, consider the MASQUE Context ID,
https://www.rfc-editor.org/rfc/rfc9298.html#name-context-identifiers
This has similar properties (0 has a special meaning, the rest of the
2^62 values are dynamically allocated). It seems to me you're better
off following that pattern and not proposing a read-only registry,
which seems like a poor use of IANA resources.
If there's a rationale for making this a "registry" please let me
know it.
+--
This document reserves the Transport class ID value 0 to represent This document reserves the Transport class ID value 0 to represent
"Best Effort Transport Class ID". This is used in the 'Transport "Best Effort Transport Class ID". This is used in the 'Transport
Class ID' field of Transport Route Target extended community that Class ID' field of Transport Route Target extended community that
represents best effort transport class. Please create a new registry represents best effort transport class. Please create a new registry
for this. for this.
Registry Group: BGP Classful Transport (BGP CT) Registry Group: BGP Classful Transport (BGP CT)
Registry Name: Transport Class ID Registry Name: Transport Class ID
skipping to change at page 59, line 24 skipping to change at page 59, line 24
In order to mitigate the risk of the diversion of traffic from its In order to mitigate the risk of the diversion of traffic from its
intended destination, BGPsec solutions ([RFC8205] and Origin intended destination, BGPsec solutions ([RFC8205] and Origin
Validation [RFC8210][RFC6811]) may be extended in future to work for Validation [RFC8210][RFC6811]) may be extended in future to work for
non-Internet SAFIs (SAFIs other than 1). non-Internet SAFIs (SAFIs other than 1).
The restriction of the applicability of the BGP CT SAFI 76 to its The restriction of the applicability of the BGP CT SAFI 76 to its
intended well-defined scope limits the likelihood of traffic intended well-defined scope limits the likelihood of traffic
diversions. Furthermore, as long as the filtering and appropriate diversions. Furthermore, as long as the filtering and appropriate
configuration mechanisms discussed previously are applied diligently, configuration mechanisms discussed previously are applied diligently,
risk of the diversion of the traffic is eliminated. risk of the diversion of the traffic is eliminated.
+--
jgs: It's awfully daring to say a "risk ... is eliminated", especially when
the "elimination" is through the hard crunchy exterior, completely trusted
interior security model. I would suggest deleting the "furthermore" sentence
which is likely to draw fire and doesn't seem needed.
+--
15. References 15. References
15.1. Normative References 15.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
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 62, line 38 skipping to change at page 62, line 38
[INTAREA-TUNNELS] [INTAREA-TUNNELS]
Touch, Ed. and Townsley, Ed., "IP Tunnels in the Internet Touch, Ed. and Townsley, Ed., "IP Tunnels in the Internet
Architecture", 26 March 2023, Architecture", 26 March 2023,
<https://datatracker.ietf.org/doc/draft-ietf-intarea- <https://datatracker.ietf.org/doc/draft-ietf-intarea-
tunnels/13/>. tunnels/13/>.
[Intent-Routing-Color] [Intent-Routing-Color]
Hegde, Ed., "Intent-aware Routing using Color", 23 October Hegde, Ed., "Intent-aware Routing using Color", 23 October
2023, <https://datatracker.ietf.org/doc/html/draft-hr- 2023, <https://datatracker.ietf.org/doc/html/draft-hr-
spring-intentaware-routing-using-color-03#section-6.3.2>. spring-intentaware-routing-using-color-03#section-6.3.2>.
+---
jgs: why the link to a specific section? that's unusual in a reference.
I guess if you really to want to reference that particular section,
you should cite it as "Intent-aware Routing using Color", Section 6.3.2.
But better just to link to the top level.
I do see you refer to that specific section a couple places in the body text,
but elsewhere you refer to the overall doc without section. So better to
just cite the doc.
+---
[MNH] Vairavakkalai, Ed., "BGP MultiNexthop Attribute", 17 March [MNH] Vairavakkalai, Ed., "BGP MultiNexthop Attribute", 17 March
2024, <https://datatracker.ietf.org/doc/html/draft-ietf- 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
idr-multinexthop-attribute-00>. idr-multinexthop-attribute-00>.
[MPLS-NS] Vairavakkalai, Ed., "BGP signalled MPLS namespaces", 20 [MPLS-NS] Vairavakkalai, Ed., "BGP signalled MPLS namespaces", 20
October 2023, <https://datatracker.ietf.org/doc/html/ October 2023, <https://datatracker.ietf.org/doc/html/
draft-kaliraj-bess-bgp-sig-private-mpls-labels-07>. draft-kaliraj-bess-bgp-sig-private-mpls-labels-07>.
[PCEP-RSVP-COLOR] [PCEP-RSVP-COLOR]
skipping to change at page 63, line 45 skipping to change at page 63, line 45
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., [RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", RFC 9350, and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
DOI 10.17487/RFC9350, February 2023, DOI 10.17487/RFC9350, February 2023,
<https://www.rfc-editor.org/info/rfc9350>. <https://www.rfc-editor.org/info/rfc9350>.
[SRTE] Talaulikar, Ed. and S. Previdi, "Advertising Segment [SRTE] Talaulikar, Ed. and S. Previdi, "Advertising Segment
Routing Policies in BGP", 23 October 2023, Routing Policies in BGP", 23 October 2023,
<https://tools.ietf.org/html/draft-ietf-idr-segment- <https://tools.ietf.org/html/draft-ietf-idr-segment-
routing-te-policy-26>. routing-te-policy-26>.
+--
jgs: this is the wrong reference, you want draft-ietf-idr-sr-policy-safi-10
Also, please make this normative.
+--
[TEAS-NS] Farrel, Ed. and Drake, Ed., "A Framework for IETF Network [TEAS-NS] Farrel, Ed. and Drake, Ed., "A Framework for IETF Network
Slices", 14 September 2023, Slices", 14 September 2023,
<https://www.ietf.org/archive/id/draft-ietf-teas-ietf- <https://www.ietf.org/archive/id/draft-ietf-teas-ietf-
network-slices-25.html#section-4>. network-slices-25.html#section-4>.
Appendix A. Extensibility considerations Appendix A. Extensibility considerations
A.1. Signaling Intent over PE-CE Attachment Circuit A.1. Signaling Intent over PE-CE Attachment Circuit
+--
jgs: Why do we need this appendix when we already have Section 11.5,
"Use of DSCP"? If it's just a vehicle for referencing MNH, couldn't you
do that from S. 11.5 and dispense with this appendix?
+--
It may be desirable to allow a CE device to indicate in the data It may be desirable to allow a CE device to indicate in the data
packet it sends what treatment it desires (the Intent) when the packet it sends what treatment it desires (the Intent) when the
packet is forwarded within the provider network. packet is forwarded within the provider network.
Section A.10 in BGP MultiNexthop Attribute [MNH] describes some Section A.10 in BGP MultiNexthop Attribute [MNH] describes some
mechanisms that enable such signaling. mechanisms that enable such signaling.
A.2. BGP CT Egress TE A.2. BGP CT Egress TE
skipping to change at page 66, line 18 skipping to change at page 66, line 18
on the BGP session with RR11. Service helper RR11 reflects service on the BGP session with RR11. Service helper RR11 reflects service
routes between the two PEs with next hop unchanged. There are no routes between the two PEs with next hop unchanged. There are no
tunnels for transport-class 100 or 200 from RR11 to the PEs. tunnels for transport-class 100 or 200 from RR11 to the PEs.
Forwarding happens using service routes at service nodes PE11, PE12. Forwarding happens using service routes at service nodes PE11, PE12.
Routes received from CEs are not present in any other nodes' FIB in Routes received from CEs are not present in any other nodes' FIB in
the provider network. the provider network.
CE31 advertises a route for example prefix 203.0.113.31 with next hop CE31 advertises a route for example prefix 203.0.113.31 with next hop
self to PE12. CE31 can attach a Mapping Community Color:0:100 on self to PE12. CE31 can attach a Mapping Community Color:0:100 on
this route, to indicate its request for Gold SLA. Or, PE11 can this route, to indicate its request for Gold SLA. Or, PE12 can
attach the same using locally configured policies. attach the same using locally configured policies.
+--
jgs: I changed PE11 to PE12 above. Right?
+--
Consider, CE31 is getting VPN service from PE12. The RD:203.0.113.31 Consider, CE31 is getting VPN service from PE12. The RD:203.0.113.31
route is readvertised in AFI/SAFI 1/128 by PE12 with next hop self route is readvertised in AFI/SAFI 1/128 by PE12 with next hop self
(192.0.2.12) and label V-L1, to RR11 with the Mapping Community (192.0.2.12) and label V-L1, to RR11 with the Mapping Community
Color:0:100 attached. This AFI/SAFI 1/128 route reaches PE11 via Color:0:100 attached. This AFI/SAFI 1/128 route reaches PE11 via
RR11 with the next hop unchanged as PE12 and label V-L1. Now PE11 RR11 with the next hop unchanged as PE12 and label V-L1. Now PE11
can resolve the PNH 192.0.2.12 using PE11_to_PE12_gold RSVP TE LSP. can resolve the PNH 192.0.2.12 using PE11_to_PE12_gold RSVP TE LSP.
The IP FIB at PE11 VRF will have a route for 203.0.113.31 with a next The IP FIB at PE11 VRF will have a route for 203.0.113.31 with a next
hop when resolved using Resolution Scheme belonging to the mapping hop when resolved using Resolution Scheme belonging to the mapping
skipping to change at page 67, line 19 skipping to change at page 67, line 19
Traffic direction being described is CE31 to CE41. CE41 may request Traffic direction being described is CE31 to CE41. CE41 may request
a specific SLA (e.g. Gold for this traffic), when traversing these a specific SLA (e.g. Gold for this traffic), when traversing these
provider core networks. provider core networks.
B.2.2. Transport Layer B.2.2. Transport Layer
AS1 uses RSVP-TE intra-domain tunnels between PE11 and ASBR11. And AS1 uses RSVP-TE intra-domain tunnels between PE11 and ASBR11. And
LDP tunnels for best effort traffic. AS2 uses SRTE intra-domain LDP tunnels for best effort traffic. AS2 uses SRTE intra-domain
tunnels between ASBR21 and PE21, and L-ISIS for best effort tunnels. tunnels between ASBR21 and PE21, and L-ISIS for best effort tunnels.
+--
jgs: since I have no idea what L-ISIS is, I suggested in my earlier comments
that you gloss it. Possibly it also needs a reference?
+--
The networks have two Transport classes: Gold with Transport Class ID The networks have two Transport classes: Gold with Transport Class ID
100, Bronze with Transport Class ID 200. These transport classes are 100, Bronze with Transport Class ID 200. These transport classes are
provisioned at the PEs and ASBRs. This creates the Resolution provisioned at the PEs and ASBRs. This creates the Resolution
Schemes for these transport classes at these PEs and ASBRs. Schemes for these transport classes at these PEs and ASBRs.
Following tunnels exist for Gold transport class. Following tunnels exist for Gold transport class.
PE11_to_ASBR11_gold - RSVP-TE tunnel PE11_to_ASBR11_gold - RSVP-TE tunnel
skipping to change at page 68, line 26 skipping to change at page 68, line 26
(203.0.113.21) and label V-L1 to RR21 with the Mapping Community (203.0.113.21) and label V-L1 to RR21 with the Mapping Community
Color:0:100 attached. This AFI/SAFI 1/128 route reaches ASBR21 via Color:0:100 attached. This AFI/SAFI 1/128 route reaches ASBR21 via
RR21 with the next hop unchanged as PE21 and label V-L1. Now ASBR21 RR21 with the next hop unchanged as PE21 and label V-L1. Now ASBR21
can resolve the PNH 203.0.113.21 using ASBR21_to_PE21_gold SRTE LSP. can resolve the PNH 203.0.113.21 using ASBR21_to_PE21_gold SRTE LSP.
The IP FIB at ASBR21 VRF will have a route for 203.0.113.41 with a The IP FIB at ASBR21 VRF will have a route for 203.0.113.41 with a
next hop resolved using Resolution Scheme associated with mapping next hop resolved using Resolution Scheme associated with mapping
community Color:0:100, pointing to ASBR21_to_PE21_gold tunnel. community Color:0:100, pointing to ASBR21_to_PE21_gold tunnel.
This route is readvertised by ASBR21 on BGP session inside VRF with This route is readvertised by ASBR21 on BGP session inside VRF with
next hop self. EBGP session peering on interface address. ASBR21 next hop self.
+--
jgs: I don't know what you mean by "BGP session inside VRF".
+--
EBGP session peering on interface address.
+--
jgs: That's a sentence fragment; I don't know what you mean by it so
I can't propose a rewrite.
+--
ASBR21
acts like a CE to ASBR11, and the previously mentioned process acts like a CE to ASBR11, and the previously mentioned process
repeats in AS1, until the route reaches PE11 and resolves over repeats in AS1, until the route reaches PE11 and resolves over
PE11_to_ASBR11_gold RSVP TE tunnel. PE11_to_ASBR11_gold RSVP TE tunnel.
Traffic traverses as IP packet on the following legs: CE31-PE11, Traffic traverses as unlabeled IP packets on the following legs: CE31-PE11,
ASBR11-ASBR21, PE21-CE41. And uses MPLS forwarding inside AS1, AS2 ASBR11-ASBR21, PE21-CE41. And uses MPLS forwarding inside AS1, AS2
core. core.
BGP CT AFI/SAFI 1/76 is not used in this Inter-AS Option B BGP CT AFI/SAFI 1/76 is not used in this Inter-AS Option B
deployment. But the Transport class and Resolution Scheme constructs deployment. But the Transport class and Resolution Scheme constructs
are used to preserve end-to-end SLA. are used to preserve end-to-end SLA.
B.3. Inter-AS option B usecase B.3. Inter-AS option B usecase
B.3.1. Topology B.3.1. Topology
skipping to change at page 70, line 18 skipping to change at page 70, line 18
on the BGP session with RR13. Service helper RR13 reflects service on the BGP session with RR13. Service helper RR13 reflects service
routes between the PE11 and ASBR12 with next hop unchanged. routes between the PE11 and ASBR12 with next hop unchanged.
Similarly, in AS2 PE22, ASBR21 negotiate service family (AFI/SAFI Similarly, in AS2 PE22, ASBR21 negotiate service family (AFI/SAFI
1/128) on the BGP session with RR23, which reflects service routes 1/128) on the BGP session with RR23, which reflects service routes
between the PE22 and ASBR21 with next hop unchanged. between the PE22 and ASBR21 with next hop unchanged.
ASBR21 and ASBR12 negotiate AFI/SAFI 1/128 between them, and ASBR21 and ASBR12 negotiate AFI/SAFI 1/128 between them, and
readvertise L3VPN routes with next hop self, allocating new labels. readvertise L3VPN routes with next hop self, allocating new labels.
EBGP session peering on interface address. EBGP session peering on interface address.
+--
jgs: That's a sentence fragment; I don't know what you mean by it so
I can't propose a rewrite.
+--
CE41 advertises a route for example prefix 203.0.113.41 with next hop CE41 advertises a route for example prefix 203.0.113.41 with next hop
self to PE22 VRF. CE41 can attach a Mapping Community Color:0:100 on self to PE22 VRF. CE41 can attach a Mapping Community Color:0:100 on
this route, to indicate its request for Gold SLA. Or, PE22 can this route, to indicate its request for Gold SLA. Or, PE22 can
attach the same using locally configured policies. attach the same using locally configured policies.
Consider, CE41 is getting VPN service from PE22. The RD:203.0.113.41 Consider, CE41 is getting VPN service from PE22. The RD:203.0.113.41
route is readvertised in AFI/SAFI 1/128 by PE22 with next hop self route is readvertised in AFI/SAFI 1/128 by PE22 with next hop self
(192.0.2.22) and label V-L1 to RR23 with the Mapping Community (192.0.2.22) and label V-L1 to RR23 with the Mapping Community
Color:0:100 attached. This AFI/SAFI 1/128 route reaches ASBR21 via Color:0:100 attached. This AFI/SAFI 1/128 route reaches ASBR21 via
skipping to change at page 72, line 11 skipping to change at page 72, line 11
considerations, as it complements and works well with existing considerations, as it complements and works well with existing
protocol machineries. This problem does not need reinventing the protocol machineries. This problem does not need reinventing the
wheel with brand new NLRI and procedures. wheel with brand new NLRI and procedures.
This is a more pragmatic approach. Rather than abandoning time This is a more pragmatic approach. Rather than abandoning time
tested design pattern like RFC 4364 and RFC 8277, just to invent tested design pattern like RFC 4364 and RFC 8277, just to invent
something completely new that is not backward compatible with something completely new that is not backward compatible with
existing deployments. Overloading RFC 8277 NLRI MPLS Label field existing deployments. Overloading RFC 8277 NLRI MPLS Label field
with information related to non MPLS data plane leads to backward with information related to non MPLS data plane leads to backward
compatibility issues. compatibility issues.
+--
jgs: I generally think this appendix is very useful in providing a
conceptual framework for the reader to understand your design. However,
the final paragraph appears to be a leftover from the working group
debate, and seems out of place in the present document. I suggest
deleting it.
+--
C.1. Update packing considerations C.1. Update packing considerations
BGP CT carries transport class as an attribute. This means routes BGP CT carries transport class as an attribute. This means routes
that don't share the same transport class cannot be packed into same that don't share the same transport class cannot be packed into same
Update message. Update packing in BGP CT will be similar to RFC 8277 Update message. Update packing in BGP CT will be similar to RFC 8277
family routes carrying attributes like communities or extended family routes carrying attributes like communities or extended
communities. Service families like AFI/SAFI 1/128 have considerably communities. Service families like AFI/SAFI 1/128 have considerably
more scale than transport families like AFI/SAFI 1/4 or AFI/SAFI more scale than transport families like AFI/SAFI 1/4 or AFI/SAFI
1/76, which carry only loopbacks. Update packing mechanisms that 1/76, which carry only loopbacks. Update packing mechanisms that
skipping to change at page 72, line 33 skipping to change at page 72, line 40
Section 6.3.2.1 of [Intent-Routing-Color] suggests scaling numbers Section 6.3.2.1 of [Intent-Routing-Color] suggests scaling numbers
for transport network where BGP CT can be deployed. Experiments were for transport network where BGP CT can be deployed. Experiments were
conducted with this scale to find the convergence time with BGP CT conducted with this scale to find the convergence time with BGP CT
for those scaling numbers. Scenarios involving BGP CT carrying IPv4 for those scaling numbers. Scenarios involving BGP CT carrying IPv4
and IPv6 endpoints with MPLS label were tested. Tests with BGP CT and IPv6 endpoints with MPLS label were tested. Tests with BGP CT
IPv6 endpoints and SRv6 SID are planned. IPv6 endpoints and SRv6 SID are planned.
Tests were conducted with 1.9 million BGP CT route scale (387K Tests were conducted with 1.9 million BGP CT route scale (387K
endpoints in 5 transport classes). Initial convergence time for all endpoints in 5 transport classes). Initial convergence time for all
cases was less than 2 minutes, This experiment proves that carrying cases was less than 2 minutes. This experiment proves that carrying
+--
jgs: So... 2 minutes is good I guess? Say so, e.g. "which compares
favorably with __some baseline information__".
The basic issue here is that this is an archival document. While it
may be obvious today that 2 minutes is good, the state of the art will
be different later. So the more context you can provide the better.
+--
transport class information as an attribute keeps BGP convergence transport class information as an attribute keeps BGP convergence
within acceptable range. Details of the experiment and test results within acceptable range. Details of the experiment and test results
are available in BGP CT Update packing Test Results are available in BGP CT Update packing Test Results
[BGP-CT-UPDATE-PACKING-TEST]. [BGP-CT-UPDATE-PACKING-TEST].
Furthermore, even in today's BGP LU deployments each egress node Furthermore, even in today's BGP LU deployments each egress node
originates BGP LU route for it's loopback, with some attributes like originates BGP LU route for it's loopback, with some attributes like
community identifying the originating node or region, and AIGP community identifying the originating node or region, and AIGP
attribute. These attributes may be unique per egress node, thus do attribute. These attributes may be unique per egress node, thus do
not help with update packing in transport layer family routes. not help with update packing in transport layer family routes.
 End of changes. 89 change blocks. 
51 lines changed or deleted 407 lines changed or added

This html diff was produced by rfcdiff 1.49. The latest version is available from https://github.com/ietf-tools/rfcdiff