Internet Engineering Task Force | S. Dhanaraj, Ed. |
Internet-Draft | Huawei |
Updates: 8296 (if approved) | IJ. Wijnands |
Intended status: Standards Track | P. Psenak |
Expires: January 9, 2020 | Cisco Systems, Inc. |
Z. Zhang | |
Juniper Networks. | |
G. Yan | |
J. Xie | |
Huawei | |
July 08, 2019 |
LSR Extensions for BIER over Ethernet
draft-ietf-bier-lsr-ethernet-extensions-01
Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. BIER can be supported in MPLS and non-MPLS networks.
This document specifies the required extensions to the IS-IS, OSPFv2 and OSPFv3 protocols for supporting BIER in non-MPLS networks using BIER in Ethernet encapsulation.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Bit Index Explicit Replication (BIER) [RFC8279] is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. BIER can be supported in MPLS and non-MPLS networks.
[RFC8296] specifies a common BIER header format for both MPLS and non-MPLS networks, though the first 20-bits of the BIER header (referred as BIFT-id) is a "MPLS Label" in case of MPLS networks and is a "domain-wide-unique-value" representing the combination of SD-BSL-SI in case of non-MPLS networks. [I-D.ietf-bier-non-mpls-bift-encoding] specifies two optional ways of statically assigning domain-wide-unique mapping between BIFT-id's and SD-BSL-SI combination.
However, BIER architecture [RFC8279] does not require domain-wide-unique BIFT-id's to be used (even for non-MPLS encapsulation). As discussed in [I-D.zzhang-bier-rift], the BIFT-id in case of non-MPLS encapsulation can also just be a local 20-bit opaque value and signaled just like in MPLS case. This doucment updates section 2.2.1.1 of [RFC8296] that the BIFT-id for a SD-BSL-SI in case of non-MPLS encapsulation need not be unique through out the BIER domain. In such a case when the BIFT-id is not unique, the BIFT-id in the packet is expected to change as the packet travels.
As an example, suppose a particular BIER domain contains a SD (SD 0), supports two BSLs (256 and 512), and contains 1024 BFRs. A BFR that is provisioned for above SD, and that supports both BSLs, could advertise the following set of BIFT-id's:
Notice that the example uses ranges of continuous BIFT-id's:
Strictly speaking, using contiguous range is not required, but it is done for the purpose of simplified signaling similar to MPLS label blocks (notice that locally assigning BIFT-id ranges requires no manual processing just like in the case of MPLS label block allocation).
Processing and forwarding of BIER packets requires special software and hardware capabilities. The BFRs supporting a BIER encapsulation type MUST advertise this capability (along with the other required parameters specific to the encapsulation) to the other routers in BIER domain. This advertisement, for example, will enable the other BFRs in the BIER domain in deciding, whether to include or exclude the advertising router from the BAR and/or IPA algorithm while computing the multicast path for a specific encapsulation type.
[RFC8401], [RFC8444] and [I-D.ietf-bier-ospfv3-extensions] specifies the required extensions to the IS-IS [RFC1195], OSPFv2 [RFC2328] and OSPFv3 [RFC8362] protocols respectively for the distribution of BIER sub-domain information including the Sub-sub-TLV required to support BIER in MPLS encapsulation for MPLS networks.
This document specifies the required extensions to the IS-IS [RFC1195], OSPFv2 [RFC2328] and OSPFv3 [RFC8362] protocols for supporting BIER using BIER in Ethernet encapsulation with dynamically and locally assigned BIFT-id's.
Support for other encapsulation types are outside the scope of this document.
Some of the terminology specified in [RFC8279] is replicated here and extended by necessary definitions:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
A BIER sub-domain MAY support multiple BIER encapsulation types like BIER-MPLS, BIER-ETH. The different encapsulation types supported by a BFR in a sub-domain MUST share the same BFR-id. This would allow the BFR's in transit to translate the encapsulation from one type to the other while forwarding the packet in the BIER sub-domain.
When a BFIR/BFR supports multiple BIER encapsulation types, when sending to a BIER neighbor it MUST use a type that the neighbor also supports. If the neighbor also supports more than one encapsulation type that this BFIR/BFR supports, the type selection could be a matter of local policy and is outside the scope of this document.
BIER Info sub-TLV defined in [RFC8401] is used to advertise the sub-domain id, and other associated parameters of the sub-domain like BFR-id, MT, BAR, IPA.
This document introduces new sub-sub-TLV under BIER Info sub-TLV to advertise the ethernet encapsulation capability and other associated parameters of the encapsulation.
This sub-sub-TLV carries the information for the BIER Ethernet encapsulation including the BitString length supported for a certain <MT,SD> pair.
It is advertised within the BIER Info sub-TLV defined in [RFC8401] which in-turn is carried within the TLVs 235, 237 [RFC5120] or TLVs 135 [RFC5305], or TLV 236 [RFC5308].
This sub-sub-TLV MAY appear multiple times within a single BIER Info sub-TLV. If the same BitString length is repeated in multiple BIER Ethernet encapsulation sub-sub-TLVs inside the same BIER Info sub-TLV, the BIER Info 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max SI |BS Len | BIFT-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BIER Sub-TLV defined in [RFC8444] is used to advertise the sub-domain id, and other associated parameters of the sub-domain like BFR-id, MT, BAR, IPA.
This document introduces new Sub-TLV under BIER Sub-TLV to advertise the ethernet encapsulation capability and other associated parameters of the encapsulation.
This Sub-TLV carries the information for the BIER Ethernet encapsulation including the BitString length supported for a certain <MT,SD> pair.
It is advertised within the BIER Sub-TLV defined in [RFC8444] which in-turn is carried within the OSPFv2 Extended Prefix TLV defined in [RFC7684].
This Sub-TLV MAY appear multiple times within a single BIER Sub-TLV. If the same BitString length is repeated in multiple BIER Ethernet encapsulation Sub-TLVs inside the same BIER Sub-TLV, the BIER 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max SI | BIFT-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |BS Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BIER Sub-TLV defined in [I-D.ietf-bier-ospfv3-extensions] is used to advertise the sub-domain id, and other associated parameters of the sub-domain like BFR-id, MT, BAR, IPA.
This document introduces new Sub-TLV under BIER Sub-TLV to advertise the ethernet encapsulation capability and other associated parameters of the encapsulation.
This Sub-TLV carries the information for the BIER Ethernet encapsulation including the BitString length supported for a certain <MT,SD> pair.
It is advertised within the BIER Sub-TLV defined in [I-D.ietf-bier-non-mpls-bift-encoding] which in-turn is carried within the Intra-Area-Prefix TLV or Inter-Area-Prefix TLV in OSPFv2 Extended LSA TLV defined in [RFC8362].
This Sub-TLV MAY appear multiple times within a single BIER Sub-TLV. If the same BitString length is repeated in multiple BIER Ethernet encapsulation Sub-TLVs inside the same BIER Sub-TLV, the BIER 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max SI | BIFT-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |BS Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310] and the security concerns for IS-IS extensions for BIER are addressed in [RFC8401]. This document introduces new sub-sub-TLV for the already existing IS-IS TLVs defined for distributing the BIER sub-domain information in [RFC8401]. It does not introduce any new security risks to IS-IS.
Security concerns and required extensions for OSPFv2 are addressed in [RFC2328] and [RFC7684] and the security concerns for OSPFv2 extensions for BIER are addressed in [RFC8444]. This document introduces new Sub-TLV for the already existing OSPFv2 TLV defined for distributing the BIER sub-domain information in [RFC8444]. It does not introduce any new security risks to OSPFv2.
The document requests new allocations from the IANA registries as follows
The author wants to thank Antonie Przygienda for his comments and suggestions.
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
[RFC8279] | Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T. and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017. |
[RFC8296] | Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J., Aldrin, S. and I. Meilik, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 2018. |
[RFC8401] | Ginsberg, L., Przygienda, T., Aldrin, S. and Z. Zhang, "Bit Index Explicit Replication (BIER) Support via IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018. |
[RFC8444] | Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., Przygienda, T., Zhang, J. and S. Aldrin, "OSPFv2 Extensions for Bit Index Explicit Replication (BIER)", RFC 8444, DOI 10.17487/RFC8444, November 2018. |
[I-D.ietf-bier-non-mpls-bift-encoding] | Wijnands, I., Xu, X. and H. Bidgoli, "An Optional Encoding of the BIFT-id Field in the non-MPLS BIER Encapsulation", Internet-Draft draft-ietf-bier-non-mpls-bift-encoding-01, October 2018. |
[I-D.ietf-bier-ospfv3-extensions] | Psenak, P., Kumar, N. and I. Wijnands, "OSPFv3 Extensions for BIER", Internet-Draft draft-ietf-bier-ospfv3-extensions-00, May 2019. |
[I-D.zzhang-bier-rift] | Zhang, Z., Ma, S. and Z. Zhang, "Supporting BIER with RIFT", Internet-Draft draft-zzhang-bier-rift-00, March 2018. |
[RFC1195] | Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990. |
[RFC2328] | Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998. |
[RFC5120] | Przygienda, T., Shen, N. and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008. |
[RFC5304] | Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008. |
[RFC5305] | Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008. |
[RFC5308] | Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008. |
[RFC5310] | Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R. and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009. |
[RFC7684] | Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J. and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015. |
[RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
[RFC8362] | Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V. and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018. |