idnits 2.17.00 (12 Aug 2021) /tmp/idnits31972/draft-eckert-teas-bier-te-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC8279], [I-D.ietf-bier-te-arch]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Mar 5, 2018) is 1531 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Provisioning' is mentioned on line 196, but not defined == Missing Reference: 'Monitoring' is mentioned on line 196, but not defined == Outdated reference: A later version (-03) exists of draft-eckert-bier-te-frr-02 == Outdated reference: A later version (-07) exists of draft-ietf-bier-bier-yang-03 == Outdated reference: draft-ietf-bier-isis-extensions has been published as RFC 8401 == Outdated reference: draft-ietf-bier-ospf-bier-extensions has been published as RFC 8444 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-00 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Eckert 3 Internet-Draft Huawei 4 Intended status: Informational Mar 5, 2018 5 Expires: September 6, 2018 7 Framework for Traffic Engineering with BIER-TE forwarding (Bit Index 8 Explicit Replication with Traffic Engineering) 9 draft-eckert-teas-bier-te-framework-00 11 Abstract 13 BIER-TE is an application-state free, (loose) source routed multicast 14 forwarding method where every hop and destination is identified via 15 bits in a bitstring of the data packets. It is described in 16 [I-D.ietf-bier-te-arch]. BIER-TE is a variant of [RFC8279] in 17 support of such explicit path engineering. 19 This document described the traffic engineering control framework for 20 use with the BIER-TE forwarding plane: How to enable the ability to 21 calculate paths and integrate this forwarding plane into an overall 22 TE solution. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 6, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 59 2. BIER-TE Topology management . . . . . . . . . . . . . . . . . 6 60 2.1. Operational model . . . . . . . . . . . . . . . . . . . . 6 61 2.2. BIER-TE topology model . . . . . . . . . . . . . . . . . 7 62 2.3. Consistency checking . . . . . . . . . . . . . . . . . . 10 63 2.4. Auto-configuration . . . . . . . . . . . . . . . . . . . 11 64 3. Flow Management . . . . . . . . . . . . . . . . . . . . . . . 12 65 3.1. Operational / Architectural Models . . . . . . . . . . . 12 66 3.1.1. Overprovisioning . . . . . . . . . . . . . . . . . . 13 67 3.1.2. PCEC . . . . . . . . . . . . . . . . . . . . . . . . 13 68 3.1.2.1. per-flow QoS - policer/shaper/EF . . . . . . . . 14 69 3.1.2.2. DiffServ QoS . . . . . . . . . . . . . . . . . . 15 70 3.2. BIER-TE flow model . . . . . . . . . . . . . . . . . . . 15 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 74 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 17 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction and Overview 80 This document proposes a framework and abstract data model for the 81 control plane of BIER-TE as defined in [I-D.ietf-bier-te-arch] (BIER- 82 TE-ARCH). That document primarily defines the forwarding plane and 83 provides some example scenarios how to use it. 85 BIER-TE is a forwarding plane derived from BIER ([RFC8279]) in which 86 the destinations of packets are bits in a bitstring. Every bit 87 indicates a destination (BFER - BIER Forwarding Exit Router) and an 88 IGP is used to flood those "bit addresses" so hops along the path 89 from sender (BFIR - BIER Forwarding Ingres Router) through 90 intermediate nodes (BFR) can calculate the shortest path for each 91 destination (bit) and simply copy the received packet to every 92 interface to one or more bits set in the packet. 94 In BIER-TE, shortest path calculation is replaced by bits of the 95 bitstring indicating intermediate hops and pre-populated forwarding 96 tables (BIFT - Bit Index Forwarding Tables) on every BFR indicating 97 those bits. In the simplest case, every interface on a BFR has a 98 unique bit assigned to it, and the BIFT of only that BFR will have in 99 its BIFT for this bit an adjacency entry indicating that interface. 100 This ultimately allows to indicate any sub-graph of the network 101 topology as a bitstring and hop-by-hop perform the necessary 102 forwarding/replication for a packet with such a bitstring. More 103 complex semantics of bits are used to help saving bits. A typical 104 bitstring size supportable is 256 bits, the original BIER 105 specification allows up to 1024 bits. BIER-TE may be specifically 106 interesting for typically smaller topologies such as often 107 encountered in DetNet scenarios, or else through intelligent 108 allocating and saving of bits for larger topologies, some of which is 109 exemplified in BIER-TE-ARCH. 111 One can compare BIER-TE in function to Segment Routing in so far that 112 it attempts to be as much as possible a per-packet "source-routed" 113 (for lack of better term) forwarding paradigm without per- 114 application/flow state in the network. Whereas SR primarily supports 115 simple sequential paths indicated as a sequence of SIDs, in BIER-TE, 116 the bitstring indicate a directed and acyclic graphs (DAG) - with 117 replications. BIER-TE can also be combined with SR and then bits in 118 the bitstring are only required for the nodes (BFR) where replication 119 is desired, and the paths between any two such replication nodes 120 could be SIDs or stack of SIDs that are selected by assigning bits to 121 them (routed adjacencies in the BIER-TE terminology). 123 In BIER-TE-ARCH, the control plane is not considered. In its place, 124 a theoretical BIER-TE Controller Host uses unspecified signaling to 125 control the setup of the BIER-TE forwarding-plane end to end (all 126 bits/adjacencies in all BFR BFITs) and during the lifecycle of 127 network device install through the determination of paths for 128 specific traffic and changes to the topology. This document expands 129 and refines this simplistic model and intends to serve as the 130 framework for follow-up protocol and data model specification work. 132 The core forwarding documents relevant to this document are as 133 follows: 135 o [RFC8279] (BIER-ARCH): as summarized above. 137 o [RFC8296] (BIER-ENCAP): The encapsulation for BIER packets using 138 MPLS or non-MPLS networks underneath. 140 o [I-D.ietf-bier-te-arch] (BIER-TE-ARCH): as summarized above. 142 o [I-D.thubert-bier-replication-elimination] (BIER-EF-OAM): Extends 143 the BIER-TE forwarding from BIER-TE-ARCH to support the 144 Elimination Function (EF) and an OAM function. The Elimination 145 Function is a term from DetNets resilience architecture: Multiple 146 copies of traffic flows are carried across disjoint path, merged 147 in a BFR running the EF and duplicates are eliminated on that BFR 148 based on recognizing duplicate sequence numbers. Engineered 149 multiple transmission paths are a key reason to leverage BIER-TE. 151 o [I-D.huang-bier-te-encapsulation] (BIER-TE-ENCAP): Proposed 152 encapsulation based on an extension of BIER-ENCAP. Identifies 153 whether the packet expects to use a BIER or BIER-TE BIFT. Also 154 adds a control-word in support of (optional) elimination function 155 (EF) and interprets the pre-existing BFIR-ID and entropy fields as 156 a flow-id. 158 o [I-D.eckert-bier-te-frr] (BIER-TE-FRR): This document describes 159 protections methods applicable to BIER-TE. 1:1 / end-to-end path 160 protection is referenced in this document in the context of DetNet 161 style PREF path protection. The options not discucced yet (TBD) 162 in this document are link protection tunnels (such as used in 163 RSVP-TE as well) and the novel BIER-TE specific protection method, 164 in which nodes modify the bitstring upon local discovery of a 165 failure. 167 The relevant routing underlay documents are as follows: 169 o [I-D.ietf-bier-isis-extensions] (BIER-ISIS), 170 [I-D.ietf-bier-ospf-bier-extensions] (BIER-OSPF): The BIER-ISIS 171 and BIER-OSPF documents describe extensions to those two IGPs in 172 support of BIER. Effictively, every BFR announces the BIFTs it is configured for, the MT-ID (IGP Multitopology- 174 ID) they are using, and the BFR-ID it has in each SD (none if it 175 does not need to operate as a BFER). For MPLS encapsulation, the 176 base label for every SD is announced as well as the SI-range (one 177 label per is used). 179 o There is currently no document describing IGP extensions for BIER- 180 TE, but the goal is to define those based, using the proposals 181 made in this framework, and as feasible re-using and/or amending 182 those existing BIER IGP extensions. 184 o [I-D.ietf-bier-bier-yang] (BIER-YANG): This document describes the 185 YANG data model to provision on every BFR BIER. It also provides 186 OAM functions. There is currently no model expanding this to 187 support BIER-TE. This framework document defines elements that 188 should be included in a BIER-TE YANG model. 190 o TBD: incomplete list ?. 192 |<--- BIER-TE domain-->| 194 [Bier-TE Controller Host] 195 == 196 {PCE controller}, [Provisioning], [Monitoring] 198 ^ ^ ^ 199 / | \ BIER-TE control protocol 200 | | | Yang(netconf/restconf), PCEP 201 v v v 202 BFIR-----BFR-----BFER 204 {per-flow QoS} ...... {EF,OAM} Optional per-flow BFIR/BFER 205 functions (for per-flow TE) 207 |------------------->| 208 BIER-TE forwarding 210 |<------------------>| IGP extensions for BIER-TE 212 |<------------------>| Existing IGP 213 Routing underlay {Existing IGP TE extensions} 215 |<------------------>| 216 Unicast forwarding underlay - IPv4/v6/SR 218 Figure 1: BIER-TE signaling architecture 220 The above picture is a modified version of Picture 2 from BIER-TE- 221 ARCH reduced by the elements not considered in this document, and 222 refined with those that are intended to be described by this 223 document. 225 In comparison with BIER-TE-ARCH, Picture 2, this picture and this 226 document do not include considerations for specific multicast flow 227 overlay elements. Instead, it adds description of optional BFIR/BFER 228 elements for per-flow QoS/EF (Elimination Function) and OAM, which 229 are optional parts of an overall BIER-TE traffic engineering 230 architecture. See BIER-EF-OAM for more background. 232 The routing underlay is refined in this document to consider a 233 unicast forwarding underlay of IPv4/IPv6 and/or unicast SR (Segment 234 Routing) for BIER-TE "forward_routed" adjacencies. It also assumes 235 an existing IGP, such as ISIS or OSPF as the routing underlay. This 236 may include (TBD) extensions already supporting TE aspects (like 237 those IGP extensions done for RSVP-TE). 239 This framework intends to support a wide range of options to 240 instantiate it: 242 In one extreme (PCEC only), there is no IGP in the network that BIER- 243 TE depends on, but all BIER-TE operations is managed in an SDN-style 244 fashion from centralized components called "BIER-TE Controller Host" 245 in BIER-TE-ARCH. This central packend can be further subdivided into 246 a Configuration/Provisioning component to install the BIER-TE 247 topology into the network and a PCEC (Pat Computation Engine 248 Controller) and (TBD) monitoring components. After BIER-TE is 249 operational, the PCEC calculates BIER-TE bitstrings for BFIR when 250 they need to send traffic flow to 252 In the other extreme (IGP only), there is no need for a PCEC or NMS. 253 The initial setup of the BIER-TE topology can be performed manually, 254 using configuration options to support automatic consistency checking 255 and partial auto-configuration to simplify this work. BIER-TE 256 extensions of the IGP are used for consistency checking and 257 autoconfiguration and finally to provide the whole BIER-TE topology 258 to BFIR that can then autonomously calculate BIER-TE bitstrings 259 without the help of a PCEC. 261 2. BIER-TE Topology management 263 2.1. Operational model 265 When a network is installed, BIER-TE is added as a service or later 266 when it is meant to change, BFR need to be (re)provisioned. This 267 involves a planning phase which physical adjacencies (links) should 268 be used in the BIER-TE topology, and which virtual adjacencies 269 (routed adjacencies) should be created and assigned bits. Ultimately 270 this means the definition of the BIER-TE topology. 272 When the physical topology if the network is smaller than the 273 possible bitstring size (e.g.: 256 bits), then this can be a simple, 274 fully automated process. Likewise, if multiple disjoined services 275 for BIER-TE each require active subsets of the network topology 276 smaller than the network topology, it likewise can be simple to 277 create a different SD (subdomain) BIER-TE topologies for each such 278 service. 280 When the required network topology for a BIER-TE service exceeds the 281 supportable bitstring size, bit-saving mechanisms can be employed as 282 described in BIER-ARCH. Some of them such as p2p link bits or lan- 283 bits are easily automatically calculated. Creation of virtual 284 adjacencies (routed adjacencies) may likely best be done with 285 operator defined policies applied to a system a system calculating 286 the bits for the BIER-TE topology. 288 Ultimately, if the set of required destinations plus transit hops 289 exceeds the size of available bitstrings after optimization, multiple 290 BIFT == bitstrings need to be allocated to support this case. These 291 multiple BIFT will likely need to be engineered to minimize duplicate 292 traffic load on the network and minimize bit use. One example shown 293 in BIER-TE-ARCH is to allocate different BIFT to different 294 areas of a network, therefore having to create one BIER-TE packet 295 copy per required destination region, but in result having only one 296 packet copy in each of those regions. 298 Provisioning / initial setup can be done manually in simpler networks 299 or through a provisioning system. A PCEP may equally perform this 300 function. If a PCEP is not used to perform this function, but a PCEP 301 is used later for Flow Management, then the PCEP does of course need 302 to also learn the BIER-TE topologies created by the provisioning 303 system. 305 Unless a PCEC is used for provisioning/initial setup, YANG is likely 306 the prefered model to install the BIER-TE topology information into 307 the BFR. If a PCEC is used, YANG or PCEC seem to be valid choices. 309 When the network topology expands, bit assignements for the new parts 310 of the topology need to be made. If expansion was not factored into 311 the initial bit assignment plans, this can lead to the need to 312 reassign bits for existing parts of the topology. Support for such 313 processes could be simplified through additional topology 314 information, for example to enable seamless switching of traffic 315 flows from bits in one SD over to bits in another SD. This is 316 currently not considered in this document. 318 2.2. BIER-TE topology model 319 BIFT information: 320 Instance: "configured", "operational", 321 "learned-configured", "learned-operational" (pce, igp) 322 BIFT-ID: 323 BIFT-Name: string (optional) 324 BFR-ID: 16 bit (BIER-TE ID of the in this BIFT 325 or undefined if not BFER in this BIFT) 326 Ingres-groups: (list of) string (1..16 bytes) 327 (that is a member of) 328 EF: (optional, parameters for EF Function on this BIFT) 329 OAM: (optional, parameter for OAM Function on this BIFT) 330 Bits: (#BSL - BitStringLength) 331 BitIndex: 1...BSL 332 BitType(/Tag): "unassigned", 333 (if unassigned, must have no adjacencies) 334 "unique", "p2p", "lan", "leaf", "node", "flood", 335 "group" 336 (more BitTypes defined in text below) 337 Names: (list of 0 or more) string (1..16 bytes) 338 (for BitTypes that require it) 339 List of 0 or more adjacencies: 340 (The following is the list of possible types of adjacencies, 341 as defined in BIER-TE-ARCH with parameters) 342 local_decap: 343 VRFcontext: string (TBD) 344 forward_connected: 345 destination-id: ip-addr (4/16 bytes, router-id/link-local) 346 link-id: ifIndex Value (connecting to destination) 347 boolean: DNR (Do Not Reset) 348 forward_routed: 349 destination-id: 20 bit (SID), 4 or 16 bytes (router-id) 350 TBD: path/encap information (e.g: SR SID stack) 351 ECMP: 352 list of 2 or more forward_connect and/or 353 forward_routed adjacencies 355 Figure 2: BIER-TE topology information 357 The above picture shows informally the data model for BIER-TE 358 topology information. is a domain-wide unique identifier of a 359 BFR, for example the router-id of the IGP (if an IGP is used). Every 360 has a "configured" instance of the BIFT information for every 361 BIFT configured on it. This configuration could be created from 362 legacy models, a YANG model, PCEP, or other means. 364 Every also has an "operational" instance of the BIFT 365 information. If the BFR has nor "learned-configured" / "learned- 366 operational" information, then the "operational" instance is just a 367 copy of the "configuration" instance, but would take additional local 368 information into account. For example, if resource limits do not 369 allow to activate configured BIFT. Or when bits in the BIFT point to 370 interfaces/adjacencies that are down, this could potentially also be 371 reflected in the operational instance. While the "configuration" 372 instance is read/write, the operational instance is read-only (from 373 NMS or PCEC). 375 To calculate paths/bitstrings through the topology without the help 376 of a PCEC, a BIFT would need to know the network wide BIER-TE 377 topology. This topology consists of the "operational" BIFT 378 informations of the BFR itself plus the "learned-operational" BIFT 379 information from all other BIER-TE nodes in the network plus the 380 underlay routing topology information, for example from an IGP. When 381 an IGP is used, the "learned-operational" information of another BFR 382 is simply learned because the BFRs are flooding this information as 383 IGP information. 385 In the absence of any IGP, or the desire not to use it to distribute 386 BIER-TE topology information, an NMS or PCEC could collect the 387 "operational" BIER-TE topology information from BFRs and distribute 388 it to BFIR to enable them to calculate BIER-TE bitstrings 389 autonomously. 391 The operational instance of the topology information can depend on 392 the presence of an IGP. If the adjacency of a bit in the BIFT is 393 configured to use a nexthop identifier that has to be learned from an 394 IGP, such as a Segment Routing SID or a router-ID, then the 395 operational instance (as well as distributed learned-operational 396 ones) would indicate that such an adjacency is non-operational if the 397 BFR could not resolve this nexthop information. Forward_connected 398 adjacencies do not require a routing underlay, but just link-local 399 connectivity. 401 Some information elements in the BIER-TE topology information is 402 metadata to support automatic consistency checking of learned 403 topology information which permit to prohibit use of adjacencies that 404 would not lead to working paths or worst case could create loops. 405 The same information can also be used to auto-configure some 406 adjacencies, specifically routed adjacencies, allowing to minimize 407 operator work in case BIFT topology information is not auto-created 408 from an NMS/PCEP but through manual mechanisms, but also to 409 automatically discover mis-wirings and avoid them to be used. 411 The semantic of BitType and Names are described in conjunction with 412 consistency checking and autoconfiguration in the following sections. 414 2.3. Consistency checking 416 The BitType and associated Name or Names for the bit are intended to 417 support automated consistency checking and different reactions. an 418 NMS can for example discover misconfiguration or miscablings and 419 alert the operator. BFIR can likewise discover misconfiguration when 420 the "configured" and "operational" instances of BFR are distributed 421 via the IGP and are therefore available as "learned-configured" and 422 "learned-operational" on the BFIR. The BFIR can then fr example stop 423 using those misconfigured bits in any bitstrings it calculates and 424 further escalate (e.g.: overlay signaling) unreachability of any BFER 425 (or inability to calculate paths supporting required TE features). 427 "Unique" bits doe not require a name, but the bit in question 428 must only have an adjacency on one BFR. If it shows up with 429 adjacencies on more than one BFR, this is an inconsistency. 431 "p2p" bits need to be the same bit on both BFR connected to each 432 other via a subnet, and must be pointing to each other via 433 "forward_connected" adjacencies. A "p2p" bit needs to have one Name 434 parameter unique in the domain - for example constructed from 435 concatenating the IfIndex of both sides. Note that the actual subnet 436 does not need to be p2p, a BFR can have multiple bits across a 437 multiaccess subnet, one for each neighbor. 439 Not listed in the above picture, but a "remote-p2p" could be a 440 BitType when a bidirectional adjacency between two remode BFR using 441 forward_routed adjacencies. 443 A "leaf" bit is the one shared bit in a bitstring assigned to 444 the "local_decap" adjacency on all leaf BFER. Leaf BFER do not need 445 a separate bit. See BIER-TE-ARCH. If more then one "lead" bits are 446 used in an across the domain that is an inconsistency - waste 447 of bits. 449 A "node" bit is associated with a Name that follows a standardized 450 form to identify a node - e.g.: its router-id. On a non-leaf BFER, 451 this bit can only have one local_decap adjacency on the node 452 indicated itself. On a leaf BFER, the "node" bit must be assigned to 453 adjacencies on one or BFR that connect to the indicated BFER. Other 454 configurations (or wirings) are a misconfiguration. 456 A "lan" bit indicates a bit for a LAN, as discussed in BIER-TE-ARCH. 457 It must have one domain wide unique name. It must only be used by 458 BFR connecting to the same subnet with a set of forward_connected 459 adjacencies pointing to the other BFR on that subnet. Disabling the 460 use of a "lan" bit either on a BFIR when sending packets, or even 461 more son on the actual BFR connecting to a subnet and recognizing 462 inconsistent BIER-TE topolocy configuraiton for it - is the most 463 important automatic function to avoid mis-routing of BIER-TE packets. 464 The looping will be also stopped because bits are reset when packets 465 traverse the paths, or ultimately by TTL, but neither mechanism can 466 provide as specifica OAM information about what went wrong than 467 recognizing inconsistencies via the IGP. 469 TBD: flood bit, DNR (like lan bit, but more complex. 471 Consistency checking may happen directly during configuration as well 472 as later during rewiring/remot changes of topology. 474 In general, the operational instance of the BIER-TE topology are 475 relevant to topology consistency checking (as hey are for path 476 calculations). For example, future extensions may actually introduce 477 some form of node/BFR redundancy where different BFR are configured 478 for the same bits, but only one at a time is actively using a bit, 479 and therefore announcing it in the operational instance of the BIER- 480 TE topology. 482 2.4. Auto-configuration 484 For subnets, the actual adjacency to the neighbor on a link may not 485 actually be configured explicitly, but only the interface. Discovery 486 of the neighbor via the IGP would result in a complete working 487 adjacency for a bit, and that adjacency would show then in the 488 operational instance - while the configured instance would only show 489 an incomplete adjacency and the bit that was configured for the 490 adjacency. The Name parameter can be used in configuration to lock 491 in the BFR that is expected to be on the other side of a subnet 492 interface. If that node is not the one actually connected, the 493 adjacency in the operational instance would not be completed. 495 When a "p2p" BitType is used, but the bit is configured 496 inconsistently on both sides of a p2p link, an autoconfiguration 497 mechanism may be specified to select which of the two bits should be 498 used (e.g.: bit number configured on the higher router-id peer). 499 This could help to auto-correct a configuration mistake, but it does 500 of course not recover the inconsistently configured bit directly, it 501 just ignores it. 503 When a "lan" or "flood" BitType is configured, likewise auto- 504 configuration can be done to overcome misconfigurations. TBD: more 505 details. 507 Most importantly, configuration of routed adjacencies can create most 508 need for network-wide consistent configuration. This can be 509 automated with the proposed "group" bittype. 511 (Source) (midpoint1) (midpoint2) (receivers) 513 GrpA1 GrpB1 GrpC1 GrpD1 515 GrpA2 GrpB2 GrpC2 GrpD2 516 ... ... 517 GrpA10 GrpB3 GrpC3 GrpD200 519 Figure 3: Group BitType use 521 The typical set of forward_routed adjacency is to allow steering of 522 BIER-TE packets through a sequence of one or more members of a hop- 523 group, load-balancing across them for TE reasons. In the above 524 picture, those paths would start from a BFIR in GrpA and go via one 525 (or more) nodes in GrpB, then GrpC and then BFER (GrpD). 527 To half-automate the setup of such loose hops, each member of GrpC 528 would for example be configured with one unique bit of BitType 529 "group" and the Name parameter would be set to "GrpB". Each 530 midpoint1 BFR would "GrpB" in the list of strings for the BIFT 531 Ingres-Group parameter. When such a BFR discovers (e.g.: via the 532 IGP) a BFR "learned-operational" bit of BitType group with a name 533 "GrpB" (and no adjacency!), then that midpoint1 BFR would create an 534 adjacency in its "operational" instance, pointing to the announcing 535 BFR with a "forward_routed" adjacency. 537 The saving through such group BitTypes is therefore that the bit had 538 only to be configured on one node (the receiver side of the 539 forward_routed adjacency), but would be configured on any number of 540 ingres BFR for the adjacency. In the above picture, the benefit 541 would be biggest if forward_routed adjacencies where used from Source 542 to midpoint1, because the number of Sources is potentially largest 543 (e.g: as shown in the picture 10 BFIR in Source group). 545 3. Flow Management 547 3.1. Operational / Architectural Models 549 Once a BIER-topology is active in a network, it can be used to pass 550 BIER-TE packets. Typically this also requires the provisioning of 551 some routing overlay because today, all applications defined for BIER 552 today are classical SP PE-PE application where some customer traffic 553 is mapped to SP traffic via PE-PE "overlay" signaling. 555 Applications in future environments such as industrial control or IoT 556 may result in different overlay signaling. Even native end-to-end 557 BIER-TE from application stacks is possible, but has so far not been 558 defined. 560 Overlay signaling is currently out of scope of this document. 562 3.1.1. Overprovisioning 564 In the "overprovisioning flow management" model, the network operator 565 is responsible to engineer the available network resources, BIER-TE 566 Topology and applications generating BIER-TE flows such that the 567 required resources can be guaranteed without contention - and 568 potentially without the help of either PCEP or IGP, but simply using 569 provisioning to configure BFIR and overlay signaling to determine 570 active destinations. 572 Overprovisioning is the most control/signaling lightweight approach 573 and currently the standard approach in most enterprises and service 574 provider for IP multicast traffic. 576 For example: An ISP with a ++40Gbps network and a comparable small 577 amount of high-value muticast traffic requiring in aggregate less 578 than 5 Gbps can easily carry all of that multicast traffic across any 579 available path. This is especially easy when the mayority of traffic 580 is best effort traffic (such as Internet traffic). In that case, the 581 multicast traffic would be carried in a traffic class that is 582 overprovisioned, for example with 6 Gbps guaranteed on every link. 583 Calculated BIER-TE bitstrings would for example be used to reduce 584 cost of multicast distribution (e.g.: steiner tree calculation), use 585 disjoint paths (in conjunction with EF), or simply load-balance 586 across all available non-ECMP paths. Overprovisioning flow 587 management is traditional in most SP networks (core/edge/access) for 588 IP multicast traffic and requires no additional signaling. 590 The overprovisioning flow management model is one that likely would 591 request for (only) a YANG model to provision the BIER-TE topology. 593 3.1.2. PCEC 595 In the PCEC based flow management model, a PCEP determines 596 (calculates) the (flow-id,,bitstring) for a traffic flows and 597 signals this to the BFIR sourcing the flow (its BFR-ID is part of the 598 flow-id). If the flow was not statically defined, then this step 599 would be preceeded with the BFIR requesting the resources for the, 600 indicating the requested resources as well as the set of 601 destinations. The destinations could be indicated as BFR-ID or 602 (likely easier for the BFIR) by their unique identifiers in unicast 603 routing (e.g.: router-ID). The bitstring returned by the PCEP would 604 include not only engineered paths to all these destinations, but 605 those paths could also be disjoint paths, carrying the traffic twice 606 towards each destination and merging them via the EF function. The 607 BFIR could be fully agnostic to these PCEP choices. 609 One of the core benefits of using BIER-TE forwarding is the ability 610 to change the bitstring on a per-packet basis to re-route traffic by 611 setting different transit bits, or to quickly add/delete 612 destinations. When the BFIR should be empowered to perform any of 613 these functions without the need for help by the PCEP, then the PCEP 614 needs to provide additiona information back to the BFIR. 616 If a BFIR has for example an OAM capability to determine without the 617 help of a controller that a path has failed (too much packet loss on 618 destination, signalled back to BFIR), and dual-transmission is not 619 desired (due to double resource usage), then the PCP and BFIR could 620 co-operate on a path-protection scheme in which the PCEP provides for 621 flows not one, but two bitstrings, one being the backup path which is 622 used by the BFIR when it discovers via OAM loss on the currently used 623 path. This approach can extremely reduce the need to rely on 624 controller help during failures. 626 When the destinations for a particular flow can potentially change 627 over time, this can often be faster and more efficiently signalled 628 directly via the overlay signaling to the BFIR instead of going 629 through the PCEP. To support this mode of operations, the BFIR could 630 request from the PCEP not simply the current set of destinations for 631 a flow, but instead the maximum superset of receivers and request 632 per-destination information. The PCEP would then return not just one 633 bitstring, but one bitstring per destination (BFER). The BFIR would 634 simply OR the bitstrings for all required destinations for each 635 packet to create the final bitstring for that packet. Note that this 636 description of of course on a per- (aka: per BIFT) basis. 637 Destinations using different BIFTs require always different BIER-TE 638 packets to be sent by the BFIR. 640 3.1.2.1. per-flow QoS - policer/shaper/EF 642 In the PCEP based resource management model, it is up to the PCEP to 643 determine how explicit resource reservations should be managed, e.g.: 644 whether or how it tracks resource consumption. The BIER-TE 645 forwarding plane itself does not support per-flow state with the 646 exception of EF, which would usually be a function enabled on BFER. 648 Likewise, per-flow policer and/or shaper state may be a useful 649 optional feature that the PCEP should be able to request to be 650 enabled on a BFIR to ensure that the traffic passed by the BFIR into 651 the BIER-TE domain does not overrun resources available. In the 652 simplest case, such a shaper/policer could simply reflect the 653 resources indicated by the BFIR in its request to the PCEP. 655 Per-flow policer/shaper or EF may need to be explicitly instantiated 656 by BFIR/BFER. Instantiation of the Policer/Shaper on the BFIR can 657 happen as a function of the PCEP signaling to the BFIR, but 658 instantiation of the EF would also require signaling of the PCEP to 659 the BFER(s) for flows. Note that EF could also be instantiated on 660 any midpoint BFR, so the PCEP would need to know the BIER-TE topology 661 including where EF is considered and manage it through appropriate 662 signaling. 664 Note that it is unclear yet, if EF implemenations could or should be 665 implemented with or wihthout the need for explicit instantiation, the 666 BIER-TE-EF-OAM document allows both options. Even in the absence of 667 explicit signaling, per-flow Policer/Shaper and EF are limited 668 resources and PCEP should keep track of how much of these resources 669 are allocated and available for future flows. Like other path 670 resources, exhaustion may require PCEP failure to allocate responses 671 or other mitigating options. 673 3.1.2.2. DiffServ QoS 675 The only resource management that could be expected to exist in the 676 BIER-TE domain hop-by-hop would be DiffServ QoS. As outlined in the 677 above overprovisioning resource management model, it can serve as an 678 easy method for lightweight resource management, and as soon as the 679 network intends to use more than one such DiffServ codepoint across 680 different BIER-TE flows, the PCEP should likely be able to understand 681 and manage the DiffServ assignments of BIER-TE flows and signal the 682 selected codepoint back to the BFIR. 684 3.2. BIER-TE flow model 685 BIER-TE traffic flow (change) request (from BFIR): 686 Flow-control-ID: 687 Ingres BFIR of flow: (IGP router-id ?!) 688 Destination-ID: set of BFER identifiers (IGP router-id ?!) 689 extended-reply-required (boolean) 690 Requirements: 691 TSPEC (bandwidth, burst size,...) 692 resilience: dual-transmission with EF 693 shared-group: name 695 BIER-TE traffic flow reply/command (to BFIR): 696 Flow-control-ID: 697 Ingres Policer/Shaper parameters (applies to each BIFT) 698 Set of 1 or more BIFT: 699 700 BFIR-ID, entropy (form together flow-ID) 701 Bitstring 702 QoS, TTL, 704 BIER-TE traffic flow extended reply/command (to BFIR): 705 Flow-control-ID: 706 Ingres Policer/Shaper parameters (applies to each BIFT) 707 Set of 1 or more BIFT: 708 709 BFIR-ID, entropy (form together flow-ID) 710 QoS, TTL 711 List of 1 or more destinations 712 Destination-ID, Bitstring 714 BIER-TE traffic flow command (to BFER): 715 Flow-control-ID: 716 Ingres BFIR of flow: BFIR-ID (in BIER-TE packet header) 717 Set of 1 or more BIFT: 718 719 BFIR-ID, entropy (form together flow-ID) 720 EF parameter (window size etc..) 722 Figure 4: Flow request/reply/commands 724 The above picture shows an initial abstract representation of the 725 data models for the different type of request/replies discussed in 726 the previous section between PCEC and BFIR (and in one case BFER). 728 The Flow-conrol-ID identifies the managed object itself: a flow to be 729 sent from one BFIR to a set of BFER with some TE requirements, which 730 ultimately may require BIER-TE packets for one or more BIFT. 732 BFIR and BFER need to be identified in the request in a form not 733 specific to the bits of BIFT, so the PCEP can select the appropriate 734 BIFT(s) to use. The above picture assumes the router-id of BFIR and 735 BFER are appropriate. 737 The request includes TE requirements, including (something like a) 738 TSPEC for bandwidth, burst-size or the like, whether or not dual- 739 transmsision via PREF is required, and if the resource used are to be 740 shared across multiple flows, then the name of a shared group. One 741 example of sharing would for example be a video-conference where the 742 speaker transmits video, every speaker requests/allocates a BIER-TE 743 flow from the PCEP, but the resources for those flows are of course 744 shared (only one flow active at a time). 746 The reply from the PCEP lists the BIFTS/packets that must be sent by 747 the BFIR to reach the desired destinations as well as any other BIER- 748 TE packet header fields relevant , BFIR-ID, entropy, QoS, 749 TTL. Beside the BIER-TE packet header, the parameters for the 750 policer and/or shaper to be used by the BFIR are signalled back. 752 The extended reply does not provide simply the bitstring to use for 753 each BIFT, but instead lists the bitstrings required for each 754 destination so that (as described above), the BFIR can simply add/ 755 delete destinations on a packet-by-packet basis OR'ing those 756 bitstrings. 758 Finally, a command to BFER is required to instruct the creation of EF 759 state in case this can not be done automatically. 761 4. Security Considerations 763 TBD. 765 5. IANA Considerations 767 This document requests no action by IANA. 769 6. Acknowledgements 771 TBD. 773 7. Change log [RFC Editor: Please remove] 775 00: Initial version. 777 8. References 779 [I-D.eckert-bier-te-frr] 780 Eckert, T., Cauchie, G., Braun, W., and M. Menth, 781 "Protection Methods for BIER-TE", draft-eckert-bier-te- 782 frr-02 (work in progress), June 2017. 784 [I-D.huang-bier-te-encapsulation] 785 Huang, R., Eckert, T., Wei, N., and P. Thubert, 786 "Encapsulation for BIER-TE", draft-huang-bier-te- 787 encapsulation-00 (work in progress), March 2018. 789 [I-D.ietf-bier-bier-yang] 790 Chen, R., hu, f., Zhang, Z., dai.xianxian@zte.com.cn, d., 791 and M. Sivakumar, "YANG Data Model for BIER Protocol", 792 draft-ietf-bier-bier-yang-03 (work in progress), February 793 2018. 795 [I-D.ietf-bier-isis-extensions] 796 Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, 797 "BIER support via ISIS", draft-ietf-bier-isis- 798 extensions-09 (work in progress), February 2018. 800 [I-D.ietf-bier-ospf-bier-extensions] 801 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 802 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 803 for BIER", draft-ietf-bier-ospf-bier-extensions-15 (work 804 in progress), February 2018. 806 [I-D.ietf-bier-te-arch] 807 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 808 Engineering for Bit Index Explicit Replication (BIER-TE)", 809 draft-ietf-bier-te-arch-00 (work in progress), January 810 2018. 812 [I-D.thubert-bier-replication-elimination] 813 Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER- 814 TE extensions for Packet Replication and Elimination 815 Function (PREF) and OAM", draft-thubert-bier-replication- 816 elimination-03 (work in progress), March 2018. 818 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 819 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 820 Explicit Replication (BIER)", RFC 8279, 821 DOI 10.17487/RFC8279, November 2017, 822 . 824 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 825 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 826 for Bit Index Explicit Replication (BIER) in MPLS and Non- 827 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 828 2018, . 830 Author's Address 832 Toerless Eckert 833 Futurewei Technologies Inc. 834 2330 Central Expy 835 Santa Clara 95050 836 USA 838 Email: tte+ietf@cs.fau.de