| < draft-ietf-bier-isis-extensions-03.txt | draft-ietf-bier-isis-extensions-04.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: March 26, 2017 Juniper Networks | Expires: September 28, 2017 Juniper Networks | |||
| S. Aldrin | S. Aldrin | |||
| J. Zhang | J. Zhang | |||
| Juniper Networks, Inc. | Juniper Networks, Inc. | |||
| September 22, 2016 | March 27, 2017 | |||
| BIER support via ISIS | BIER support via ISIS | |||
| draft-ietf-bier-isis-extensions-03 | draft-ietf-bier-isis-extensions-04 | |||
| 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 http://datatracker.ietf.org/drafts/current/. | Drafts is at http://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 March 26, 2017. | This Internet-Draft will expire on September 28, 2017. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2017 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 | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://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 | |||
| skipping to change at page 2, line 45 ¶ | skipping to change at page 2, line 45 ¶ | |||
| 6.3. Optional BIER sub-domain Tree Type sub-sub-TLV . . . . . 9 | 6.3. Optional BIER sub-domain Tree Type sub-sub-TLV . . . . . 9 | |||
| 6.4. Optional BIER sub-domain BSL conversion sub-sub-TLV . . . 9 | 6.4. Optional BIER sub-domain BSL conversion sub-sub-TLV . . . 9 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
| 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 | 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 1. Introduction | 1. Introduction | |||
| Bit Index Explicit Replication (BIER) | Bit Index Explicit Replication (BIER) | |||
| [I-D.draft-ietf-bier-architecture-04] defines an architecture where | [I-D.draft-ietf-bier-architecture-05] defines an architecture where | |||
| all intended multicast receivers are encoded as bitmask in the | all intended multicast receivers are encoded as bitmask in the | |||
| Multicast packet header within different encapsulations such as | Multicast packet header within different encapsulations such as | |||
| [I-D.draft-ietf-bier-mpls-encapsulation-05]. A router that receives | [I-D.draft-ietf-bier-mpls-encapsulation-06]. A router that receives | |||
| such a packet will forward the packet based on the Bit Position in | such a packet will forward the packet based on the Bit Position in | |||
| the packet header towards the receiver(s), following a precomputed | the packet header towards the receiver(s), following a precomputed | |||
| tree for each of the bits in the packet. Each receiver is | tree for each of the bits in the packet. Each receiver is | |||
| represented by 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 | |||
| [I-D.draft-ietf-bier-architecture-04] is replicated here and extended | [I-D.draft-ietf-bier-architecture-05] is replicated here and 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- | |||
| skipping to change at page 6, line 30 ¶ | skipping to change at page 6, line 30 ¶ | |||
| no tree type is advertised tree type 0 is assumed. The supported | no tree type is advertised tree type 0 is assumed. The supported | |||
| tree type MUST be consistent for all routers supporting a given | tree type MUST be consistent for all routers supporting a given | |||
| <MT,SD>. | <MT,SD>. | |||
| 5.5. Label advertisements for MPLS Encapsulation | 5.5. 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 label range size 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-04]). Any router that violates | [I-D.draft-ietf-bier-architecture-05]). Any router that violates | |||
| this condition MUST be excluded from BIER BFTs for <MT,SD>. | this condition MUST be excluded from BIER BFTs for <MT,SD>. | |||
| 5.6. BFR-id Advertisements | 5.6. 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 advertisments. 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- | |||
| skipping to change at page 7, line 44 ¶ | skipping to change at page 7, line 44 ¶ | |||
| Type: as indicated in IANA section. | Type: as indicated in IANA section. | |||
| Length: 1 octet. | Length: 1 octet. | |||
| Reserved: MUST be 0 on transmission, ignored on reception. May be | Reserved: MUST be 0 on transmission, ignored on reception. May be | |||
| used in future versions. 8 bits | used in future versions. 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-04]. If no BFR-id has been | [I-D.draft-ietf-bier-architecture-05]. If no BFR-id has been | |||
| assigned this field is set to the invalid BFR-id. | assigned this field is set to 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 | |||
| [I-D.draft-ietf-bier-mpls-encapsulation-05]. | [I-D.draft-ietf-bier-mpls-encapsulation-06]. | |||
| o The label range size MUST be greater than 0. | 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 | | | Lbl Range Size|BS Len | Label | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type: value of 1 indicating MPLS encapsulation. | Type: value of 1 indicating MPLS encapsulation. | |||
| Length: 1 octet. | Length: 1 octet. | |||
| Local BitString Length (BS Len): Encoded bitstring length as per [I- | Local BitString Length (BS Len): Encoded bitstring length as per [I- | |||
| D.draft-ietf-bier-mpls-encapsulation-05]. 4 bits. | D.draft-ietf-bier-mpls-encapsulation-06]. 4 bits. | |||
| Label Range Size: Number of labels in the range used on | Label Range Size: Number of labels in the range used on | |||
| encapsulation for this BIER sub-domain for this bitstring length, | encapsulation for this BIER sub-domain for this bitstring length, | |||
| 1 octet. | 1 octet. | |||
| 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-05]. | in [I-D.draft-ietf-bier-mpls-encapsulation-06]. | |||
| 6.3. Optional BIER sub-domain Tree Type sub-sub-TLV | 6.3. Optional BIER sub-domain Tree Type sub-sub-TLV | |||
| This sub-sub-TLV carries the information associated with the | This sub-sub-TLV carries the information associated with the | |||
| supported BIER tree type for a <MT,SD> combination. It is carried | supported BIER tree type for a <MT,SD> combination. It is carried | |||
| within the BIER Info sub-TLV (Section 6.1) that the router | within the BIER Info sub-TLV (Section 6.1) that the router | |||
| participates in as BFR. This sub-sub-TLV is optional and its absence | participates in as BFR. This sub-sub-TLV is optional and its absence | |||
| has the same semantics as its presence with Tree Type value 0 (SPF). | has the same semantics as its presence with Tree Type value 0 (SPF). | |||
| When Tree Type 0 is used it is recommended that this sub-sub-TLV be | When Tree Type 0 is used it is recommended that this sub-sub-TLV be | |||
| omitted in order to reduce the space consumed in the parent TLV. | omitted in order to reduce the space consumed in the parent TLV. | |||
| skipping to change at page 10, line 22 ¶ | skipping to change at page 10, line 22 ¶ | |||
| 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-04] draft as far as the | [I-D.draft-ietf-bier-ospf-bier-extensions-05] 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. Normative References | 9. Normative References | |||
| [I-D.draft-ietf-bier-architecture-04] | [I-D.draft-ietf-bier-architecture-05] | |||
| Wijnands et al., IJ., "Stateless Multicast using Bit Index | Wijnands et al., IJ., "Stateless Multicast using Bit Index | |||
| Explicit Replication Architecture", internet-draft draft- | Explicit Replication Architecture", internet-draft draft- | |||
| ietf-bier-architecture-04.txt, Jul 2016. | ietf-bier-architecture-05.txt, Oct 2016. | |||
| [I-D.draft-ietf-bier-mpls-encapsulation-05] | [I-D.draft-ietf-bier-mpls-encapsulation-06] | |||
| Wijnands et al., IJ., "Bit Index Explicit Replication | Wijnands et al., IJ., "Bit Index Explicit Replication | |||
| using MPLS encapsulation", internet-draft draft-ietf-bier- | using MPLS encapsulation", internet-draft draft-ietf-bier- | |||
| mpls-encapsulation-05.txt, Jul 2016. | mpls-encapsulation-06.txt, Dec 2016. | |||
| [I-D.draft-ietf-bier-ospf-bier-extensions-04] | [I-D.draft-ietf-bier-ospf-bier-extensions-05] | |||
| 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-04.txt, Sep 2016. | extensions-05.txt, Mar 2017. | |||
| [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 | |||
| dual environments", RFC 1195, DOI 10.17487/RFC1195, | dual environments", RFC 1195, DOI 10.17487/RFC1195, | |||
| December 1990, <http://www.rfc-editor.org/info/rfc1195>. | December 1990, <http://www.rfc-editor.org/info/rfc1195>. | |||
| [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, | |||
| <http://www.rfc-editor.org/info/rfc2119>. | <http://www.rfc-editor.org/info/rfc2119>. | |||
| End of changes. 20 change blocks. | ||||
| 20 lines changed or deleted | 20 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/ | ||||