BGP-LS Extensions for IS-IS Flood ReflectorsJuniper Networks1137 Innovation Way
SunnyvaleCA
USA
jhead@juniper.net
Juniper Networks1137 Innovation Way
SunnyvaleCA
USA
prz@juniper.net
This document defines new BGP-LS (BGP Link-State) TLVs in order to carry
IS-IS Flood Reflection information.IntroductionBGP Link-State RFC7752
defines mechanisms to advertise information about the underlying IGP in
BGP NLRI to an external entity (e.g. a controller). New BGP-LS TLVs
are required in order to faciliate IS-IS Flood Reflection
extensions.Requirements LanguageThe 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 RFC 2119.BGP-LS Extensions for IS-IS Flood ReflectorsThis document defines the following BGP-LS TLV code point value in
accordance with RFC7752 rules:
BGP-LS Flood Reflection TLV Code Points
TLV Code Point
Description
IS-IS TLV
TBD1
Flood Reflection TLV
TBD1 (161)
TLV formats are described in detail in subsequent subsections.BGP-LS TLVs for IS-IS Flood ReflectionThis TLV advertises Flood Reflector details. The semantics and values
of the fields in the TLV are described in .
where:
Type:
TBD1
Length:
5
IANA ConsiderationsThis section requests entries from the "BGP-LS Node Descriptor,
Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry for
the following TLVs:
Requested TLV Entries
IANA Requests
TLV Code Point
Description
TBD1
Flood Reflection TLV
Security ConsiderationsProcedures and protocol extensions defined in this document do not
affect the BGP security model. See the "Security Considerations"
section of for a discussion
of BGP security. Also, refer to
and for analyses of BGP security
issues. Security considerations for acquiring and distributing BGP-LS
information are discussed in .
The TLVs introduced in this document are used to propagate IS-IS
Flood Reflection TLVs defined in .
These TLVs represent IS-IS Flood Reflector state and are therefore
assumed to support any/all of the required security and authentication
mechanisms as described in to
prevent any security issues when propagating the TLVs into BGP-LS.
AcknowledgementsReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Guidelines for Writing an IANA Considerations Section in RFCsNorth-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGPIS-IS Flood ReflectionAnalysis of BGP, LDP, PCEP, and MSDP Issues According to the
Keying and Authentication for Routing Protocols (KARP) Design GuideA Border Gateway Protocol 4 (BGP-4)BGP Security Vulnerabilities Analysis