| < draft-ietf-bier-isis-extensions-06.txt | draft-ietf-bier-isis-extensions-07.txt > | |||
|---|---|---|---|---|
| Internet Engineering Task Force L. Ginsberg, Ed. | Internet Engineering Task Force L. Ginsberg, Ed. | |||
| Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
| Intended status: Standards Track A. Przygienda | Intended status: Standards Track A. Przygienda | |||
| Expires: April 25, 2018 Juniper Networks | Expires: August 13, 2018 Juniper Networks | |||
| S. Aldrin | S. Aldrin | |||
| J. Zhang | J. Zhang | |||
| Juniper Networks, Inc. | Juniper Networks, Inc. | |||
| October 22, 2017 | February 9, 2018 | |||
| BIER support via ISIS | BIER support via ISIS | |||
| draft-ietf-bier-isis-extensions-06 | draft-ietf-bier-isis-extensions-07 | |||
| Abstract | Abstract | |||
| Specification of an ISIS extension to support BIER domains and sub- | Specification of an ISIS extension to support BIER domains and sub- | |||
| domains. | domains. | |||
| 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", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| skipping to change at page 1, line 42 ¶ | skipping to change at page 1, line 42 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on April 25, 2018. | This Internet-Draft will expire on August 13, 2018. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 4.1. BIER Domains and Sub-Domains . . . . . . . . . . . . . . 4 | 4.1. BIER Domains and Sub-Domains . . . . . . . . . . . . . . 4 | |||
| 4.2. Advertising BIER Information . . . . . . . . . . . . . . 5 | 4.2. Advertising BIER Information . . . . . . . . . . . . . . 4 | |||
| 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 5.1. Multi Topology and Sub-Domain . . . . . . . . . . . . . . 5 | 5.1. Multi Topology and Sub-Domain . . . . . . . . . . . . . . 5 | |||
| 5.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 5 | 5.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 5.3. BIER Algorithm . . . . . . . . . . . . . . . . . . . . . 5 | 5.3. BIER Algorithm . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 5.4. Label advertisements for MPLS Encapsulation . . . . . . . 6 | 5.4. Label advertisements for MPLS Encapsulation . . . . . . . 6 | |||
| 5.5. BFR-id Advertisements . . . . . . . . . . . . . . . . . . 6 | 5.5. BFR-id Advertisements . . . . . . . . . . . . . . . . . . 6 | |||
| 5.6. Reporting Misconfiguration . . . . . . . . . . . . . . . 6 | 5.6. Reporting Misconfiguration . . . . . . . . . . . . . . . 6 | |||
| 5.7. Flooding Reduction . . . . . . . . . . . . . . . . . . . 6 | 5.7. Flooding Reduction . . . . . . . . . . . . . . . . . . . 6 | |||
| 6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 6 | 6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 6.1. BIER Info sub-TLV . . . . . . . . . . . . . . . . . . . . 6 | 6.1. BIER Info sub-TLV . . . . . . . . . . . . . . . . . . . . 6 | |||
| 6.2. BIER MPLS Encapsulation sub-sub-TLV . . . . . . . . . . . 7 | 6.2. BIER MPLS Encapsulation sub-sub-TLV . . . . . . . . . . . 7 | |||
| 6.3. Optional BIER sub-domain BSL conversion sub-sub-TLV . . . 8 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 | 9.2. Informative References . . . . . . . . . . . . . . . . . 9 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 10 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 1. Introduction | 1. Introduction | |||
| Bit Index Explicit Replication (BIER) | Bit Index Explicit Replication (BIER) [RFC8279] defines an | |||
| [I-D.draft-ietf-bier-architecture-08] defines an architecture where | architecture where all intended multicast receivers are encoded as | |||
| all intended multicast receivers are encoded as bitmask in the | bitmask in the Multicast packet header within different | |||
| Multicast packet header within different encapsulations such as | encapsulations such as [RFC8296]. A router that receives such a | |||
| [I-D.draft-ietf-bier-mpls-encapsulation-10]. A router that receives | packet will forward the packet based on the Bit Position in the | |||
| such a packet will forward the packet based on the Bit Position in | packet header towards the receiver(s), following a precomputed tree | |||
| the packet header towards the receiver(s), following a precomputed | for each of the bits in the packet. Each receiver is represented by | |||
| tree for each of the bits in the packet. Each receiver is | a unique bit in the bitmask. | |||
| represented by a unique bit in the bitmask. | ||||
| This document presents necessary extensions to the currently deployed | This document presents necessary extensions to the currently deployed | |||
| ISIS for IP [RFC1195] protocol to support distribution of information | ISIS for IP [RFC1195] protocol to support distribution of information | |||
| necessary for operation of BIER domains and sub-domains. This | necessary for operation of BIER domains and sub-domains. This | |||
| document defines a new TLV to be advertised by every router | document defines a new TLV to be advertised by every router | |||
| participating in BIER signaling. | participating in BIER signaling. | |||
| 2. Terminology | 2. Terminology | |||
| Some of the terminology specified in | Some of the terminology specified in [RFC8279] is replicated here and | |||
| [I-D.draft-ietf-bier-architecture-08] is replicated here and extended | extended by necessary definitions: | |||
| by necessary definitions: | ||||
| BIER: Bit Index Explicit Replication (The overall architecture of | BIER: Bit Index Explicit Replication (The overall architecture of | |||
| forwarding multicast using a Bit Position). | forwarding multicast using a Bit Position). | |||
| BIER-OL: BIER Overlay Signaling. (The method for the BFIR to learn | BIER-OL: BIER Overlay Signaling. (The method for the BFIR to learn | |||
| about BFER's). | about BFER's). | |||
| BFR: Bit Forwarding Router (A router that participates in Bit Index | BFR: Bit Forwarding Router (A router that participates in Bit Index | |||
| Multipoint Forwarding). A BFR is identified by a unique BFR- | Multipoint Forwarding). A BFR is identified by a unique BFR- | |||
| prefix in a BIER domain. | prefix in a BIER domain. | |||
| skipping to change at page 3, line 47 ¶ | skipping to change at page 3, line 46 ¶ | |||
| BIER sub-domain: A further distinction within a BIER domain | BIER sub-domain: A further distinction within a BIER domain | |||
| identified by its unique sub-domain identifier. A BIER sub-domain | identified by its unique sub-domain identifier. A BIER sub-domain | |||
| can support multiple BitString Lengths. | can support multiple BitString Lengths. | |||
| BFR-id: An optional, unique identifier for a BFR within a BIER sub- | BFR-id: An optional, unique identifier for a BFR within a BIER sub- | |||
| domain. | domain. | |||
| Invalid BFR-id: Unassigned BFR-id. The special value 0 is reserved | Invalid BFR-id: Unassigned BFR-id. The special value 0 is reserved | |||
| for this purpose. | for this purpose. | |||
| BAR BIER Algorithm. Algorithm used to calculate unicast nexthops | BAR BIER Algorithm. Algorithm used to calculate nexthops. | |||
| 3. IANA Considerations | 3. IANA Considerations | |||
| This document adds the following new sub-TLV to the registry of sub- | This document adds the following new sub-TLV to the registry of sub- | |||
| TLVs for TLVs 235, 237 [RFC5120] and TLVs 135,236 | TLVs for TLVs 235, 237 [RFC5120] and TLVs 135,236 | |||
| [RFC5305],[RFC5308]. | [RFC5305],[RFC5308]. | |||
| Value: 32 (suggested - to be assigned by IANA) | Value: 32 (suggested - to be assigned by IANA) | |||
| Name: BIER Info | Name: BIER Info | |||
| This document also introduces a new registry for sub-sub-TLVs for the | This document also introduces a new registry for sub-sub-TLVs for the | |||
| BIER Info sub-TLV added above. The registration policy is Expert | BIER Info sub-TLV added above. The registration policy is Expert | |||
| Review as defined in [RFC8126]. This registry is part of the "IS-IS | Review as defined in [RFC8126]. This registry is part of the "IS-IS | |||
| TLV Codepoints" registry. The name of the registry is "sub-sub-TLVs | TLV Codepoints" registry. The name of the registry is "sub-sub-TLVs | |||
| for BIER Info sub-TLV". The defined values are: | for BIER Info sub-TLV". The defined values are: | |||
| Type Name | Type Name | |||
| ---- ---- | ---- ---- | |||
| 1 BIER MPLS Encapsulation | 1 BIER MPLS Encapsulation | |||
| 3 BIER sub-domain BSL conversion | ||||
| 4. Concepts | 4. Concepts | |||
| 4.1. BIER Domains and Sub-Domains | 4.1. BIER Domains and Sub-Domains | |||
| An ISIS signalled BIER domain is aligned with the scope of | An ISIS signalled BIER domain is aligned with the scope of | |||
| distribution of BFR-prefixes that identify the BFRs within ISIS. | distribution of BFR-prefixes that identify the BFRs within ISIS. | |||
| ISIS acts in such a case as the supporting BIER underlay. | ISIS acts in such a case as the supporting BIER underlay. | |||
| Within such a domain, the extensions defined in this document | Within such a domain, the extensions defined in this document | |||
| advertise BIER information for one or more BIER sub-domains. Each | advertise BIER information for one or more BIER sub-domains. Each | |||
| sub-domain is uniquely identified by a subdomain-id. Each subdomain | sub-domain is uniquely identified by a subdomain-id. Each subdomain | |||
| is associated with a single ISIS topology [RFC5120], which may be any | is associated with a single ISIS topology [RFC5120], which may be any | |||
| of the topologies supported by ISIS. Local configuration controls | of the topologies supported by ISIS. Local configuration controls | |||
| which <MT,SD> pairs are supported by a router. The mapping of sub- | which <MT,SD> pairs are supported by a router. The mapping of sub- | |||
| domains to topologies MUST be consistent within a BIER flooding | domains to topologies MUST be consistent within the IS-IS flooding | |||
| domain. | domain used to advertise BIER information. | |||
| Each BIER sub-domain has as its unique attributes the encapsulation | Each BIER sub-domain has as its unique attributes the encapsulation | |||
| used and the type of tree it is using to forward BIER frames | used and the type of tree it is using to forward BIER frames | |||
| (currently always SPF). Additionally, per supported bitstring length | (currently always SPF). Additionally, per supported bitstring length | |||
| in the sub-domain, each router will advertise the necessary label | in the sub-domain, each router will advertise the necessary label | |||
| ranges to support it. | ranges to support it. | |||
| 4.2. Advertising BIER Information | 4.2. Advertising BIER Information | |||
| BIER information advertisements are associated with a new sub-TLV in | BIER information advertisements are associated with a new sub-TLV in | |||
| skipping to change at page 5, line 29 ¶ | skipping to change at page 5, line 19 ¶ | |||
| advertisement is leaked between levels. | advertisement is leaked between levels. | |||
| 5. Procedures | 5. Procedures | |||
| 5.1. Multi Topology and Sub-Domain | 5.1. Multi Topology and Sub-Domain | |||
| A given sub-domain is supported within one and only one topology. | A given sub-domain is supported within one and only one topology. | |||
| All routers in the flooding scope of the BIER sub-TLVs MUST advertise | All routers in the flooding scope of the BIER sub-TLVs MUST advertise | |||
| the same sub-domain within the same multi-topology. A router | the same sub-domain within the same multi-topology. A router | |||
| receiving an <MT,SD> advertisement which does not match the locally | receiving an <MT,SD> advertisement which does not match the locally | |||
| configured pair MUST report a misconfiguration of the received <MT, | configured pair MUST report a misconfiguration of the received | |||
| SD> pair. All received BIER advertisements associated with the | <MT,SD> pair. All received BIER advertisements associated with the | |||
| conflicting <MT, SD> pair MUST be ignored. | conflicting <MT,SD> pair MUST be ignored. | |||
| 5.2. Encapsulation | Example: | |||
| All routers in the flooding scope of the BIER TLVs MUST advertise the | The following combination of advertisements are valid: <0,0> <0,1> | |||
| same encapsulation for a given <MT,SD>. A router discovering | <2,2>. | |||
| encapsulation advertised that is different from its own MUST report a | ||||
| misconfiguration of a specific <MT,SD>. All received BIER | The following combination of advertisements are invalid: <0,0> <0,1> | |||
| advertisements associated with the conflicting <MT, SD> pair MUST be | <2,0>. Advertisements associated with <0,0> and <2,0> MUST be | |||
| ignored. | ignored. | |||
| 5.2. Encapsulation | ||||
| Multiple encapsulations MAY be advertised/supported for a given | ||||
| <MT,SD>. Clearly, however, there MUST be at least one encapsulation | ||||
| type in common in order for a BIER encapsulated packet to be | ||||
| successfully forwarded between two BFRs. | ||||
| 5.3. BIER Algorithm | 5.3. BIER Algorithm | |||
| All routers in the flooding scope of the BIER TLVs MUST advertise a | All routers in the flooding scope of the BIER TLVs MUST advertise a | |||
| supported algorithm for a given <MT,SD>. The specified algorithm is | supported algorithm for a given <MT,SD>. The specified algorithm is | |||
| used when calculating the optimal path. Currently only the default | used when calculating the optimal path. The supported algorithm MUST | |||
| algorithm "SPF" is defined - which has a reserved value of 0. The | be consistent for all routers supporting a given <MT,SD>. A router | |||
| supported algorithm MUST be consistent for all routers supporting a | receiving an <MT,SD> advertisement with a BAR which does not match | |||
| given <MT,SD>. A router receiving an <MT,SD> advertisement with a | the locally configured value MUST report a misconfiguration of the | |||
| BAR which does not match the locally configured value MUST report a | received <MT, SD> pair. All received BIER advertisements associated | |||
| misconfiguration of the received <MT, SD> pair. All received BIER | with the conflicting <MT, SD> pair MUST be ignored. | |||
| advertisements associated with the conflicting <MT, SD> pair MUST be | ||||
| ignored. | Currently only the default algorithm "SPF" is defined - which has a | |||
| reserved value of 0 and represents Shortest Path First (SPF) based on | ||||
| IGP link metric. This is the standard shortest path algorithm as | ||||
| computed by the IS-IS protocol. | ||||
| 5.4. Label advertisements for MPLS Encapsulation | 5.4. Label advertisements for MPLS Encapsulation | |||
| A router that desires to participate in <MT,SD> MUST advertise for | A router that desires to participate in <MT,SD> MUST advertise for | |||
| each bitstring length it supports in <MT,SD> a label range size that | each bitstring length it supports in <MT,SD> a Maximum Set ID that | |||
| guarantees to cover the maximum BFR-id injected into <MT,SD> (which | guarantees to cover the maximum BFR-id injected into <MT,SD> (which | |||
| implies a certain maximum set id per bitstring length as described in | implies a certain maximum set id per bitstring length as described in | |||
| [I-D.draft-ietf-bier-architecture-08]). Any router that violates | [RFC8279]). Any router that violates this condition MUST be excluded | |||
| this condition MUST be excluded from BIER BFTs for <MT,SD>. | from BIER BFTs for <MT,SD>. | |||
| 5.5. BFR-id Advertisements | 5.5. BFR-id Advertisements | |||
| Each BFER/BFIR MAY advertise with its TLV<MT,SD> the BFR-id that it | Each BFER/BFIR MAY advertise with its TLV<MT,SD> the BFR-id that it | |||
| has administratively chosen. A valid BFR-id MUST be unique within | has administratively chosen. A valid BFR-id MUST be unique within | |||
| the flooding scope of the BIER advertisments. All BFERs/BFIRs MUST | the flooding scope of the BIER advertisements. All BFERs/BFIRs MUST | |||
| detect advertisement of duplicate valid BFR-IDs for a given <MT, SD>. | detect advertisement of duplicate valid BFR-IDs for a given <MT, SD>. | |||
| When such duplication is detected all of the routers advertising | When such duplication is detected all of the routers advertising | |||
| duplicates MUST be treated as if they did not advertise a valid BFR- | duplicates MUST be treated as if they did not advertise a valid BFR- | |||
| id. This implies they cannot act as BFER or BFIR in that <MT,SD>. | id. This implies they cannot act as BFER or BFIR in that <MT,SD>. | |||
| 5.6. Reporting Misconfiguration | 5.6. Reporting Misconfiguration | |||
| Whenever an advertisement is received which violates any of the | Whenever an advertisement is received which violates any of the | |||
| constraints defined in this document the receiving router MUST report | constraints defined in this document the receiving router MUST report | |||
| the misconfiguration. Such reports SHOULD be dampened to avoid | the misconfiguration. Such reports SHOULD be dampened to avoid | |||
| skipping to change at page 7, line 28 ¶ | skipping to change at page 7, line 28 ¶ | |||
| Type: as indicated in IANA section. | Type: as indicated in IANA section. | |||
| Length: variable | Length: variable | |||
| BAR BIER Algorithm. 0 is the only supported value defined in this | BAR BIER Algorithm. 0 is the only supported value defined in this | |||
| document. Other values may be defined in the future. 8 bits | document. Other values may be defined in the future. 8 bits | |||
| subdomain-id: Unique value identifying the BIER sub-domain. 1 octet | subdomain-id: Unique value identifying the BIER sub-domain. 1 octet | |||
| BFR-id: A 2 octet field encoding the BFR-id, as documented in | BFR-id: A 2 octet field encoding the BFR-id, as documented in | |||
| [I-D.draft-ietf-bier-architecture-08]. If no BFR-id has been | [RFC8279]. If no BFR-id has been assigned this field is set to | |||
| assigned this field is set to the invalid BFR-id. | the invalid BFR-id. | |||
| 6.2. BIER MPLS Encapsulation sub-sub-TLV | 6.2. BIER MPLS Encapsulation sub-sub-TLV | |||
| This sub-sub-TLV carries the information for the BIER MPLS | This sub-sub-TLV carries the information for the BIER MPLS | |||
| encapsulation including the label range for a specific bitstring | encapsulation including the label range for a specific bitstring | |||
| length for a certain <MT,SD>. It is advertised within the BIER Info | length for a certain <MT,SD>. It is advertised within the BIER Info | |||
| sub-TLV (Section 6.1) . This sub-sub-TLV MAY appear multiple times | sub-TLV (Section 6.1) . This sub-sub-TLV MAY appear multiple times | |||
| within a single BIER info sub-TLV. | within a single BIER info sub-TLV. | |||
| On violation of any of the following conditions, the receiving router | On violation of any of the following conditions, the receiving router | |||
| MUST ignore the encapsulating BIER Info sub-TLV. | MUST ignore the encapsulating BIER Info sub-TLV. | |||
| o Label ranges in multiple sub-sub-TLV MUST NOT overlap. | o Label ranges in multiple sub-sub-TLV MUST NOT overlap. | |||
| o Bitstring lengths in multiple sub-sub-TLVs MUST NOT be identical. | o Bitstring lengths in multiple sub-sub-TLVs MUST NOT be identical. | |||
| o The sub-sub-TLV MUST include the required bitstring lengths | o The sub-sub-TLV MUST include the required bitstring lengths | |||
| encoded in precisely the same way as in | encoded in precisely the same way as in [RFC8296]. | |||
| [I-D.draft-ietf-bier-mpls-encapsulation-10]. | ||||
| o The label range size MUST be greater than 0. | ||||
| o All labels in the range MUST represent valid label values | o All labels in the range MUST represent valid label values | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type | Length | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Lbl Range Size|BS Len | Label | | | Max SI |BS Len | Label | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type: value of 1 indicating MPLS encapsulation. | Type: value of 1 indicating MPLS encapsulation. | |||
| Length: 4 | Length: 4 | |||
| Local BitString Length (BS Len): Encoded bitstring length as per [I- | Local BitString Length (BS Len): Encoded bitstring length as per | |||
| D.draft-ietf-bier-mpls-encapsulation-10]. 4 bits. | [RFC8296]. 4 bits. | |||
| Label Range Size: Number of labels in the range used on | Max SI Maximum Set Identifier (section 1 of [RFC8279]) used in the | |||
| encapsulation for this BIER sub-domain for this bitstring length, | encapsulation for this BIER sub-domain for this bitstring length, | |||
| 1 octet. The size of the label range is determined by the number | 1 octet. Each SI maps to a single label in the label range. The | |||
| of Set Identifiers (SI) (section 1 of [I-D.ietf-bier- | first label is for SI=0, the second label is for SI=1, etc. | |||
| architecture]) that are used in the network. Each SI maps to a | ||||
| single label in the label range. The first label is for SI=0, the | ||||
| second label is for SI=1, etc. | ||||
| Label: First label of the range, 20 bits. The labels are as defined | Label: First label of the range, 20 bits. The labels are as defined | |||
| in [I-D.draft-ietf-bier-mpls-encapsulation-10]. | in [RFC8296]. | |||
| 6.3. Optional BIER sub-domain BSL conversion sub-sub-TLV | ||||
| This sub-sub-TLV indicates whether the BFR is capable of imposing a | ||||
| different Bit String Length (BSL) than the one it received in a BIER | ||||
| encapsulated packet. Such a capability may allow future, advanced | ||||
| tree types which ensure simple migration procedures from one BSL to | ||||
| another in a given <MT,SD> or prevent stable blackholes in scenarios | ||||
| where not all routers support the same set of BSLs in a given | ||||
| <MT,SD>. Conversions are supported only between the set of BSLs | ||||
| advertised as supported by the router. It is carried within the BIER | ||||
| Info sub-TLV (Section 6.1). This sub-sub-TLV is optional and its | ||||
| absence indicates that the router is NOT capable of imposing | ||||
| different BSLs but will always forward the packet with the BSL | ||||
| unchanged. This sub-sub-TLV MAY occur at most once in a given BIER | ||||
| info sub-TLV. If multiple occurences of this sub-sub-TLV are | ||||
| received in a given BIER info sub-TLV the encapsulating sub-TLV MUST | ||||
| be ignored. | ||||
| 0 1 2 3 | ||||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Type | Length | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Type: value of 3 indicating BIER sub-domain BSL Conversion | ||||
| Length: 0 | ||||
| 7. Security Considerations | 7. Security Considerations | |||
| Implementations must assure that malformed TLV and Sub-TLV | Implementations must assure that malformed TLV and Sub-TLV | |||
| permutations do not result in errors which cause hard protocol | permutations do not result in errors which cause hard protocol | |||
| failures. | failures. | |||
| 8. Acknowledgements | 8. Acknowledgements | |||
| The RFC is aligned with the | The RFC is aligned with the | |||
| [I-D.draft-ietf-bier-ospf-bier-extensions-08] draft as far as the | [I-D.draft-ietf-bier-ospf-bier-extensions-10] draft as far as the | |||
| protocol mechanisms overlap. | protocol mechanisms overlap. | |||
| Many thanks for comments from (in no particular order) Hannes | Many thanks for comments from (in no particular order) Hannes | |||
| Gredler, Ijsbrand Wijnands, Peter Psenak and Chris Bowers. | Gredler, Ijsbrand Wijnands, Peter Psenak and Chris Bowers. | |||
| 9. References | 9. References | |||
| 9.1. Normative References | 9.1. Normative References | |||
| [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and | [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and | |||
| skipping to change at page 10, line 14 ¶ | skipping to change at page 9, line 29 ¶ | |||
| [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, | [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, | |||
| DOI 10.17487/RFC5308, October 2008, | DOI 10.17487/RFC5308, October 2008, | |||
| <https://www.rfc-editor.org/info/rfc5308>. | <https://www.rfc-editor.org/info/rfc5308>. | |||
| [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and | [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and | |||
| U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 | U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 | |||
| and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, | and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, | |||
| March 2016, <https://www.rfc-editor.org/info/rfc7794>. | March 2016, <https://www.rfc-editor.org/info/rfc7794>. | |||
| 9.2. Informative References | [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., | |||
| Przygienda, T., and S. Aldrin, "Multicast Using Bit Index | ||||
| Explicit Replication (BIER)", RFC 8279, | ||||
| DOI 10.17487/RFC8279, November 2017, | ||||
| <https://www.rfc-editor.org/info/rfc8279>. | ||||
| [I-D.draft-ietf-bier-architecture-08] | [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., | |||
| Wijnands et al., IJ., "Stateless Multicast using Bit Index | Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation | |||
| Explicit Replication Architecture", internet-draft draft- | for Bit Index Explicit Replication (BIER) in MPLS and Non- | |||
| ietf-bier-architecture-08.txt, Sep 2017. | MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January | |||
| 2018, <https://www.rfc-editor.org/info/rfc8296>. | ||||
| [I-D.draft-ietf-bier-mpls-encapsulation-10] | 9.2. Informative References | |||
| Wijnands et al., IJ., "Bit Index Explicit Replication | ||||
| using MPLS encapsulation", internet-draft draft-ietf-bier- | ||||
| mpls-encapsulation-10.txt, Sep 2017. | ||||
| [I-D.draft-ietf-bier-ospf-bier-extensions-08] | [I-D.draft-ietf-bier-ospf-bier-extensions-10] | |||
| Psenak et al., P., "OSPF Extension for Bit Index Explicit | Psenak et al., P., "OSPF Extension for Bit Index Explicit | |||
| Replication", internet-draft draft-ietf-bier-ospf-bier- | Replication", internet-draft draft-ietf-bier-ospf-bier- | |||
| extensions-08.txt, Oct 2017. | extensions-09.txt, Dec 2017. | |||
| [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
| Writing an IANA Considerations Section in RFCs", BCP 26, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
| RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
| <https://www.rfc-editor.org/info/rfc8126>. | <https://www.rfc-editor.org/info/rfc8126>. | |||
| Authors' Addresses | Authors' Addresses | |||
| Les Ginsberg (editor) | Les Ginsberg (editor) | |||
| Cisco Systems | Cisco Systems | |||
| End of changes. 35 change blocks. | ||||
| 107 lines changed or deleted | 80 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||