Internet DRAFT - draft-senthil-bier-te-ospfv2-extensions
draft-senthil-bier-te-ospfv2-extensions
OSPF Senthil. Dhanaraj, Ed.
Internet-Draft J. Xie
Intended status: Standards Track Huawei
Expires: September 17, 2018 March 16, 2018
OSPFv2 Extensions for BIER-TE
draft-senthil-bier-te-ospfv2-extensions-00.txt
Abstract
BIER-TE: Traffic Engineering for Bit Index Explicit Replication
(BIER) is a variant of BIER [RFC8279] to support explicit path
engineering. BIER-TE defines a (loose) source routed multicast
forwarding method where every hop and destination in the TE path is
identified via bits in the bitstring of the BIER header in the data
packets. BIER-TE forwarding architecture is described in [I-D.draft-
ietf-bier-te-arch]. Control framework for Traffic Engineering with
BIER-TE forwarding plane is explained in [I-D.draft-eckert-teas-bier-
te-framework].
This document describes the OSPF [RFC2328] protocol extension
required for BIER-TE control framework with MPLS encapsulation
[RFC8296]. Support for other encapsulation types is outside the
scope of this document. The use of multiple encapsulation types is
outside the scope of this document.
Status of This Memo
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 September 17, 2018.
Dhanaraj & Xie Expires September 17, 2018 [Page 1]
Internet-Draft OSPFv2 Extensions for BIER-TE March 2018
Copyright Notice
Copyright (c) 2018 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Flooding of the BIER-TE information in OSPF . . . . . . . . . 3
2.1. BIER-TE TLV . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. BIER-TE MPLS Encapsulation Sub-TLV . . . . . . . . . . . 5
2.3. BIER-TE-LocalDecap Sub-TLV . . . . . . . . . . . . . . . 6
2.4. BIER-TE-FloodAdj Sub-TLV . . . . . . . . . . . . . . . . 7
2.5. BIER-TE-P2PAdj Sub-TLV . . . . . . . . . . . . . . . . . 8
2.6. BIER-TE-LANAdj Sub-TLV . . . . . . . . . . . . . . . . . 9
2.7. BIER-TE-NodeAdj Sub-TLV . . . . . . . . . . . . . . . . . 11
2.8. Flooding scope of BIER Information . . . . . . . . . . . 12
3. Security Considerations . . . . . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
4.1. OSPF Router Information (RI) TLVs Registry . . . . . . . 12
4.2. OSPFv2 Extended Link TLV Sub-TLVs Registry . . . . . . . 12
4.3. OSPFv2 Extended Prefix TLV Sub-TLVs Registry . . . . . . 13
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
6. Normative References . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
BIER-TE: Traffic Engineering for Bit Index Explicit Replication is an
architecture that provides optimal multicast forwarding with explicit
path engineering through a "BIER-TE domain". BIER-TE defines a
(loose) source routed multicast forwarding method where every
intermediate hop and the destination in the TE path is identified via
bits in a bitstring of the BIER header in the data packets.
BIER-TE control framework supports different deployment options as
follows,
Dhanaraj & Xie Expires September 17, 2018 [Page 2]
Internet-Draft OSPFv2 Extensions for BIER-TE March 2018
Option-1: Pure centralized controller based network, where in the
controller (SDN-Controller, PCE-CC .. ) would directly communicate
with all the BFRs (including BFIRs and BFERs) via southbound APIs
like (Yang, RestConf, PCEP ..) to learn the BIER-TE capabilities,
parameters, assign unique bit-positions to adjacencies and program
BIFTs to each BFRs directly. In this option, BIER-TE does not
depend on IGP routing underlay to advertise BIER-TE parameters.
Option-2: Controller based network, where in the controller (PCE
..) learns the BIER-TE capabilities, parameters from the network.
Configuration of BIER-TE domain and assignment of bit-position to
adjacencies can be done manually at each BFR. Each BFR advertises
the self BIER-TE parameters via IGP to other BFRs. BGP Speaker
(BGP-LS) can share the BIER-TE parameters along with the other LS
information to the Controller. Controller can autonomously
calculate the BIER-TE path and communicate the bit-string and
other parameters required to program the BIFT at the BFIR by
southbound APIs (like PCEP ..).
Option-3: Controller less network, where in configuration of BIER-
TE domain and assignment of bit-position to adjacencies is done
manually at each BFR by the operator. Each BFR advertises the
self BIER-TE parameters via IGP to other BFRs including BFIRs.
Each BFIR can autonomously calculate the BIER-TE path.
As explained above, BIER-TE framework which uses option-2 or option-3
depends upon the IGP protocols (OSPF, ISIS ..) to advertise the BIER-
TE capabilities and associated parameters (bit-positions, labels) to
the other BFRs in the network.
This document describes the OSPF [RFC2328] protocol extension
required for BIER-TE control framework with MPLS encapsulation
[RFC8296]. Support for other encapsulation types is outside the
scope of this document. The use of multiple encapsulation types is
outside the scope of this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Flooding of the BIER-TE information in OSPF
Like BIER, BIER-TE supports multiple sub-domains, SI and BFR-id as
described in section 7 of [I-D.draft-ietf-bier-te-arch]. However
unlike BIER, the BIER-TE sub-domain is not necessarily be associated
with a IGP prefix of the BFR.
Dhanaraj & Xie Expires September 17, 2018 [Page 3]
Internet-Draft OSPFv2 Extensions for BIER-TE March 2018
Given that BIER-TE sub-domain information is not necessarily be
associated with a IGP prefix of BFR, the OSPF Router Information
Opaque LSA [RFC7770] has been chosen for the advertisement of BIER-TE
sub-domain information and, MPLS labels associated with the BIER-TE
sub-domain.
BIER-TE assigns a bit-position for each adjacency (a.k.a each hop and
destination). OSPFv2 Extended Link Opaque LSA [RFC7684] is chosen to
advertise the bit-position assigned for adjacency type forward-
connected (described in section 3.2.1 of [I-D.draft-ietf-bier-te-
arch]) and OSPFv2 Extended Prefix Opaque LSA is chosen to advertise
the bit-position assigned for adjacency type forward-routed
(described in section 3.2.2 of [I-D.draft-ietf-bier-te-arch]) .
2.1. BIER-TE TLV
The BIER-TE TLV is a top-level TLV of the Router Information Opaque
LSA (defined in [RFC7770]) and is defined for distributing BIER-TE
sub-domain information.
The BIER-TE TLV is OPTIONAL. If BIER-TE TLV is not advertised by the
node, such node is considered as not being BIER-TE capable.
BIER-TE TLVs MAY appear multiple times in a RI LSA, one per each
BIER-TE sub-domain.
The BIER-TE has the following format:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-domain-ID | MT-ID | BFR-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+- -+
| |
Type: TBD.
Length: Variable, dependent on Sub-TLVs.
Sub-domain-ID: Unique value identifying the BIER-TE sub-domain
within the BIER-TE domain. A BFR MAY use the same sub-domain for
BIER and BIER-TE.
Dhanaraj & Xie Expires September 17, 2018 [Page 4]
Internet-Draft OSPFv2 Extensions for BIER-TE March 2018
MT-ID: Multi-Topology ID (as defined in [RFC4915]) that identifies
the topology that is associated with the BIER-TE sub-domain.
BFR-id: A 2 octet field encoding the BFR-id, as documented in
section 7.3 of [I-D.draft-ietf-bier-te-arch]. If the BFR is not
locally configured with a valid BFR-id to be used for BIER-TE sub-
domain, the value of this field is set to 0, which is defined as
illegal in [RFC8279].
At each BFR, BIER-TE sub-domain MUST be associated with one and only
one OSPF topology that is identified by the MT-ID. If the
association between BIER-TE sub-domain and OSPF topology advertised
in the BIER-TE TLV by other BFRs is in conflict with the association
locally configured on the receiving router, the BIER-TE TLV MUST be
ignored.
If the MT-ID value is outside of the values specified in [RFC4915],
the BIER Sub-TLV MUST be ignored.
If a BFR advertises the same Sub-domain-ID in multiple BIER-TE TLVs,
the BRF MUST be treated as if it did not advertise a BIER-TE TLV for
such sub-domain.
All BFRs MUST detect advertisement of duplicate valid BFR-IDs for a
given MT-ID and Sub-domain-ID. When such duplication is detected by
the BFR, it MUST behave as described in section 5 of [RFC8279].
2.2. BIER-TE MPLS Encapsulation Sub-TLV
The BIER-TE MPLS Encapsulation Sub-TLV is a Sub-TLV of the BIER-TE
TLV. The BIER-TE MPLS Encapsulation Sub-TLV is used in order to
advertise MPLS specific information used for BIER-TE. It MAY appear
multiple times in the BIER-TE TLV.
The BIER-TE MPLS Encapsulation Sub-TLV has the following format:
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 | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|BS Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD.
Dhanaraj & Xie Expires September 17, 2018 [Page 5]
Internet-Draft OSPFv2 Extensions for BIER-TE March 2018
Length: 8 octets.
Max SI : A 1 octet field encoding the Maximum Set Identifier
(section 1 of [RFC8296]), used in the encapsulation for this BIER-
TE sub-domain for this bitstring length.
Label: A 3 octet field, where the 20 rightmost bits represent the
first label in the label range. The 4 leftmost bits MUST be
ignored.
Bit String Length: A 4 bits field encoding the supported BitString
length associated with this sub-domain. The values allowed in
this field are specified in section 2 of [RFC8296].
The "label range" is the set of labels beginning with the Label and
ending with (Label + (Max SI)). A unique label range is allocated
for each BitString length and Sub-domain-ID. These labels are used
for BIER-TE forwarding as described in [I-D.draft-ietf-bier-te-arch].
The size of the label range is determined by the number of Set
Identifiers (SI) 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.
If the BS length is set to a value that does not match any of the
allowed values specified in [RFC8296], the BIER-TE MPLS Encapsulation
Sub-TLV MUST be ignored.
If same BS length is repeated in multiple BIER-TE MPLS Encapsulation
Sub-TLV inside the same BIER-TE TLV, the BIER-TE MPLS Encapsulation
TLV MUST be ignored.
Label ranges within all BIER-TE MPLS Encapsulation Sub-TLVs
advertised by the same BFR MUST NOT overlap. If the overlap is
detected, the advertising router MUST be treated as if it did not
advertise any BIER-TE MPLS Encapsulation Sub-TLV.
2.3. BIER-TE-LocalDecap Sub-TLV
The BIER-TE-LocalDecap Sub-TLV is an optional Sub-TLV of the BIER-TE
TLV. The BIER-TE LocalDecap Sub-TLV is used in order to advertise
the bit-position of the local_decap adjacency.
The BIER-TE LocalDecap Sub-TLV has the following format:
Dhanaraj & Xie Expires September 17, 2018 [Page 6]
Internet-Draft OSPFv2 Extensions for BIER-TE March 2018
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-domain-ID | MT-ID | Adjacency bit-position |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD.
Length: 8 octets.
Sub-domain-ID: Unique value identifying the BIER-TE sub-domain
within the BIER-TE domain.
MT-ID: Multi-Topology ID (as defined in [RFC4915]) that identifies
the topology that is associated with the BIER-TE sub-domain.
Adjacency bit-position: A 2 octet field encoding the adjacency
bit-position for the local-decap adjacency.
Flags: TBD.
Reserved: SHOULD be set to 0 while sending and MUST be ignored on
reception.
If a BFR advertises multiple BIER-TE-LocalDecap Sub-TLVs under the
same BIER-TE TLV, then the BRF MUST be treated as if it did not
advertise a BIER-TE-LocalDecap Sub-TLV.
It MAY be possible that the same bit-position is assigned for
different BFRs when the BFR is a leaf BFER. Hence the advertisement
of same bit-position by different BFRs SHOULD be allowed.
2.4. BIER-TE-FloodAdj Sub-TLV
The BIER-TE-FloodAdj Sub-TLV is an optional Sub-TLV of the BIER-TE
TLV. The BIER-TE-FloodAdj Sub-TLV is used in order to advertise the
bit-position for the flood adjacency type which would flood the
multicast packet in all the local adjacencies.
The BIER-TE-FloodAdj Sub-TLV has the following format:
Dhanaraj & Xie Expires September 17, 2018 [Page 7]
Internet-Draft OSPFv2 Extensions for BIER-TE March 2018
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-domain-ID | MT-ID | Adjacency bit-position |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD.
Length: 8 octets.
Sub-domain-ID: Unique value identifying the BIER-TE sub-domain
within the BIER-TE domain.
MT-ID: Multi-Topology ID (as defined in [RFC4915]) that identifies
the topology that is associated with the BIER-TE sub-domain.
Adjacency bit-position: A 2 octet field encoding the adjacency
bit-position for the flood adjacency type.
Flags: TBD.
Reserved: SHOULD be set to 0 while sending and MUST be ignored on
reception.
If a BFR advertises multiple BIER-TE-FloodAdj Sub-TLVs under the same
BIER-TE TLV, then the BRF MUST be treated as if it did not advertise
a BIER-TE-FloodAdj Sub-TLV.
2.5. BIER-TE-P2PAdj Sub-TLV
The BIER-TE-P2PAdj Sub-TLV is an optional Sub-TLV of the Extended
Link TLV in Extended Link Opaque LSA (defined in [RFC7684]) and is
defined for distributing the bit-position assigned for the forward-
connected p2p adjacency.
The BIER-TE-P2PAdj Sub-TLV has the following format:
Dhanaraj & Xie Expires September 17, 2018 [Page 8]
Internet-Draft OSPFv2 Extensions for BIER-TE March 2018
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-domain-ID | MT-ID | Adjacency bit-position |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Weight | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD.
Length: 8 octets.
Sub-domain-ID: Unique value identifying the BIER-TE sub-domain
within the BIER-TE domain.
MT-ID: Multi-Topology ID (as defined in [RFC4915]) that identifies
the topology that is associated with the BIER-TE sub-domain.
Adjacency bit-position: A 2 octet field encoding the adjacency
bit-position for the adjacency.
Flags: TBD.
Weight: TBD.
Reserved: SHOULD be set to 0 while sending and MUST be ignored on
reception.
If a BFR advertises the multiple BIER-TE-P2PAdj Sub-TLVs under the
same Extended Link TLV, then the BRF MUST be treated as if it did not
advertise a BIER-TE-P2PAdj Sub-TLV for the Adjacency.
It MAY be possible that the same bit-position is assigned for
different P2P adjacencies with in same or different BFR. Hence the
advertisement of same Adjacency bit-position across different
Extended Link Opaque LSA by the same BFR or different BFR SHOULD be
allowed.
2.6. BIER-TE-LANAdj Sub-TLV
The BIER-TE-LANAdj Sub-TLV is an optional Sub-TLV of the Extended
Link TLV in Extended Link Opaque LSA (defined in [RFC7684]) and is
defined for distributing the bit-position assigned for the forward-
connected LAN adjacency.
The BIER-TE-LANAdj Sub-TLV has the following format:
Dhanaraj & Xie Expires September 17, 2018 [Page 9]
Internet-Draft OSPFv2 Extensions for BIER-TE March 2018
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-domain-ID | MT-ID | Adjacency bit-position |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Weight | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD.
Length: 12 octets.
Sub-domain-ID: Unique value identifying the BIER-TE sub-domain
within the BIER-TE domain.
MT-ID: Multi-Topology ID (as defined in [RFC4915]) that identifies
the topology that is associated with the BIER-TE sub-domain.
Adjacency bit-position: A 2 octet field encoding the adjacency
bit-position for the adjacency.
Flags: TBD.
Weight: TBD.
Reserved: SHOULD be set to 0 while sending and MUST be ignored on
reception.
Neighbor ID: The Router ID of the neighbor for which the LANAdj-
bit-position is advertised.
If a BFR advertises the multiple BIER-TE-LANAdj Sub-TLVs for the same
Neighbor ID under the same Extended Link TLV, then the BRF MUST be
treated as if it did not advertise a BIER-TE-P2PAdj Sub-TLV for the
Neighbor.
It MAY be possible that the same bit-position is assigned for
different LAN adjacencies with in same or different BFR. Hence the
advertisement of same Adjacency bit-position across different
Extended Link Opaque LSA by the same BFR or different BFR SHOULD be
allowed.
Dhanaraj & Xie Expires September 17, 2018 [Page 10]
Internet-Draft OSPFv2 Extensions for BIER-TE March 2018
2.7. BIER-TE-NodeAdj Sub-TLV
The BIER-TE-NodeAdj Sub-TLV is an optional Sub-TLV of the Extended
Prefix TLV in Extended Prefix Opaque LSA (defined in [RFC7684]) and
is defined for distributing the bit-position assigned for the
forward-routed adjacency.
The BIER-TE-NodeAdj Sub-TLV has the following format:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-domain-ID | MT-ID | Adjacency bit-position |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD.
Length: 8 octets.
Sub-domain-ID: Unique value identifying the BIER-TE sub-domain
within the BIER-TE domain.
MT-ID: Multi-Topology ID (as defined in [RFC4915]) that identifies
the topology that is associated with the BIER-TE sub-domain.
Adjacency bit-position: A 2 octet field encoding the adjacency
bit-position for the adjacency.
Flags: TBD.
Reserved: SHOULD be set to 0 while sending and MUST be ignored on
reception.
Neighbor ID: The Router ID of the neighbor for which the LANAdj-
bit-position is advertised.
If a BFR advertises the multiple BIER-TE-NodeAdj Sub-TLVs under the
same Extended Prefix TLV, then the BRF MUST be treated as if it did
not advertise a BIER-TE-NodeAdj Sub-TLV.
If the same bit-position is advertised for different prefix within
same or different BFR, then the BFR(s) advertising the duplicate bit-
position MUST be treated as if they did not advertise the BIER-TE-
NodeAdj Sub-TLV for the prefix.
Dhanaraj & Xie Expires September 17, 2018 [Page 11]
Internet-Draft OSPFv2 Extensions for BIER-TE March 2018
2.8. Flooding scope of BIER Information
TBD.
3. Security Considerations
This document introduces new TLVs, Sub-TLVs for existing OSPF Router
Information Opaque LSA and new Sub-TLVs for existing OSPF Extended
Prefix TLV and OSPFV2 Extended Link TLV. It does not introduce any
new security risks to OSPF. Existing security extensions as
described in [RFC2328], [RFC7684] and [RFC7770] apply.
It is assumed that both BIER and OSPF layer is under a single
administrative domain. There can be deployments where potential
attackers have access to one or more networks in the OSPF routing
domain. In these deployments, stronger authentication mechanisms
such as those specified in [RFC7474] SHOULD be used.
Implementations MUST assure that malformed TLV and Sub-TLV defined in
this document are detected and do not provide a vulnerability for
attackers to crash the OSPF router or routing process. Reception of
malformed TLV or Sub-TLV SHOULD be counted and/or logged for further
analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be rate-
limited to prevent a Denial of Service (DoS) attack (distributed or
otherwise) from overloading the OSPF control plane.
4. IANA Considerations
The document requests new allocations from the OSPF registries as
follows
4.1. OSPF Router Information (RI) TLVs Registry
BIER-TE TLV: 16
BIER-TE MPLS Encapsulation Sub-TLV: 17
BIER-TE-LocalDecap Sub-TLV : 18
BIER-TE-FloodAdj Sub-TLV : 19
4.2. OSPFv2 Extended Link TLV Sub-TLVs Registry
BIER-TE-P2PAdj Sub-TLV : 10
BIER-TE-LanAdj Sub-TLV : 11
Dhanaraj & Xie Expires September 17, 2018 [Page 12]
Internet-Draft OSPFv2 Extensions for BIER-TE March 2018
4.3. OSPFv2 Extended Prefix TLV Sub-TLVs Registry
BIER-TE-NodeAdj Sub-TLV : 12
5. Acknowledgments
TBD
6. Normative References
[I-D.eckert-teas-bier-te-framework]
Eckert, T., "Framework for Traffic Engineering with BIER-
TE forwarding (Bit Index Explicit Replication with Traffic
Engineering)", draft-eckert-teas-bier-te-framework-00
(work in progress), March 2018.
[I-D.ietf-bier-te-arch]
Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic
Engineering for Bit Index Explicit Replication (BIER-TE)",
draft-ietf-bier-te-arch-00 (work in progress), January
2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/info/rfc4915>.
[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
"Security Extension for OSPFv2 When Using Manual Key
Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
<https://www.rfc-editor.org/info/rfc7474>.
[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, <https://www.rfc-editor.org/info/rfc7684>.
Dhanaraj & Xie Expires September 17, 2018 [Page 13]
Internet-Draft OSPFv2 Extensions for BIER-TE March 2018
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <https://www.rfc-editor.org/info/rfc7770>.
[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>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., 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, <https://www.rfc-editor.org/info/rfc8296>.
Authors' Addresses
Senthil Dhanaraj (editor)
Huawei
Email: senthil.dhanaraj@huawei.com
Xie Jingrong
Huawei
Email: xiejingrong@huawei.com
Dhanaraj & Xie Expires September 17, 2018 [Page 14]
