< draft-ietf-lsr-ospf-prefix-originator-05.txt   draft-ietf-lsr-ospf-prefix-originator-06.txt >
LSR Working Group A. Wang LSR Working Group A. Wang
Internet-Draft China Telecom Internet-Draft China Telecom
Intended status: Standards Track A. Lindem Intended status: Standards Track A. Lindem
Expires: May 28, 2020 Cisco Systems Expires: January 1, 2021 Cisco Systems
J. Dong J. Dong
Huawei Technologies Huawei Technologies
P. Psenak P. Psenak
K. Talaulikar K. Talaulikar
Cisco Systems Cisco Systems
November 25, 2019 June 30, 2020
OSPF Prefix Originator Extension OSPF Prefix Originator Extensions
draft-ietf-lsr-ospf-prefix-originator-05 draft-ietf-lsr-ospf-prefix-originator-06
Abstract Abstract
This document defines Open Shortest Path First (OSPF) encodings to This document defines OSPF extensions to include information
advertise the router-id of the originator of inter-area prefixes for associated with the node originating a prefix along with the prefix
OSPFv2 and OSPFv3 Link-State Advertisements (LSAs). The source advertisement.
originator is needed in several multi-area OSPF use cases.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 28, 2020. This Internet-Draft will expire on January 1, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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. Conventions used in this document . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 3
4. Inter-Area Prefix Source Advertisement Use Cases . . . . . . 4 2.1. Prefix Source Router-ID Sub-TLV . . . . . . . . . . . . . 4
5. External Prefix Source Advertisement Use Cases . . . . . . . 5 2.2. Prefix Originator Sub-TLV . . . . . . . . . . . . . . . . 4
6. Prefix Source Router-ID sub-TLV . . . . . . . . . . . . . . . 6 3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 5
7. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7.1. Inter-Area Prefixes . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.2. External Prefixes . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Inter-Area Topology Retrieval Process . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Inter-Area Topology Retrieval Process . . . . . . . 10
Appendix B. Special Considerations on Inter-Area Topology Appendix B. Special Considerations on Inter-Area Topology
Retrieval . . . . . . . . . . . . . . . . . . . . . 11 Retrieval . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
[I-D.ietf-ospf-mpls-elc] defines mechanisms to advertise Entropy Prefix attributes are advertised in OSPFv2 [RFC2328] using the
Readable Label Depth (ERLD) for ingress Label Switching Routers (LSR) Extended Prefix Opaque Link State Advertisement (LSA) [RFC7684] and
to discover other LSR's capability of performing Entropy Label based in OSPFv3 [RFC5340] using the various Extended Prefix LSA types
load-balancing in MPLS networks. The ingress LSR can use this [RFC8362].
information to construct the appropriate label stack for specific
traffic requirements, especially in segment routed networks and other
deployments requiring stacked LSPs.
However, in inter-area scenarios, the Area Border Router (ABR) does
not advertise the originating OSPF router-id for inter-area prefixes.
An OSPF router in one area doesn't know the origin area of inter-area
prefixes and can't determine the router that originated these
prefixes or the ERLD capabilities of the destination. Therefore, it
is necessary to advertise the originator of these inter-area prefixes
to ensure the ingress LSR can construct the appropriate label stack.
More generally, [RFC8476] defines a mechanism to advertise multiple The identification of the originating router for a prefix in OSPF
types of supported Maximum SID Depths (MSD) at node and/or link varies by the type of the prefix and is currently not always
granularity. This information will be referred when the head-end possible. For intra-area prefixes, the originating router is
router starts to send traffic to destination prefixes. In inter-area identified by the advertising Router ID field of the area-scoped LSA
scenario, it is also necessary for the sender to learn the used for those prefix advertisements. However, for the inter-area
capabilities of the receivers associated with the inter-area prefixes advertised by the Area Border Router (ABR), the advertising
prefixes. Router ID field of their area-scoped LSAs is set to the ABR itself
and the information about the router originating the prefix
advertisement is lost in this process of prefix propagation across
areas. For Autonomous System (AS) external prefixes, the originating
router may be considered as the Autonomous System Border Router
(ASBR) and is identified by the advertising Router ID field of the
AS-scoped LSA used. However, the actual originating router for the
prefix may be a remote router outside the OSPF domain. Similarly,
when an ABR performs translation of Not-So-Stubby Area (NSSA)
[RFC3101] LSAs to AS-external LSAs, the information associated with
the NSSA ASBR (or the router outside the OSPF domain) is not conveyed
across the OSPF domain.
There is another scenario where knowing the originator of inter-area While typically the originator of information in OSPF is identified
prefixes is useful. For example, Border Gateway Protocol Link-State by its OSPF Router ID, it does not necessarily represent a reachable
(BGP-LS) [RFC7752] describes mechanisms using the BGP protocol to address for the router. The IPv4/IPv6 Router Address as defined in
advertise Link-State information. This information can enable a [RFC3630] and [RFC5329] for OSPFv2 and OSPFv3 respectively provide an
Software Definition Network (SDN) controller to automatically address to reach that router.
determine the underlay network topology.
However, if the underlay network is partitioned into multiple areas The primary use case for the extensions proposed in this document is
and running the OSPF protocol, it is not easy for the SDN controller to be able to identify the originator of the prefix in the network.
to rebuild the multi-area topology since ABR that connects multiple In cases where multiple prefixes are advertised by a given router, it
areas will normally hide the detailed topology for these non-backbone is also useful to be able to associate all these prefixes with a
areas. If only the internal routers within backbone area run the single router even when prefixes are advertised outside of the area
BGP-LS protocol, they just learn and report the summary network in which they originated. It also helps to determine when the same
information from the non-backbone areas. If the SDN controller can prefix is being originated by multiple routers across areas.
learn the originator of the inter-area prefixes, it is possible to
rebuild the inter-area topology.
[RFC7794] introduces the Intermediate System to Intermediate System This document proposes extensions to the OSPF protocol for inclusion
(IS-IS) "IPv4/IPv6 Source Router IDs" Type-Length-Value (TLV) to of information associated with the router originating the prefix
advertise the source of prefixes leaked from a different IS-IS level. along with the prefix advertisement. These extensions do not change
This TLV can be used in the above scenarios. Such solution can also the core OSPF route computation functionality. They provide useful
be applied in networks that run the OSPF protocol, but existing OSPF information for topology analysis and traffic engineering, especially
LSAs TLVs must be extended to include the router originating the on a controller when this information is advertised as an attribute
prefix. of the prefixes via mechanisms such as Border Gateway Protocol Link-
State (BGP-LS) [RFC7752].
This draft provides such solution for the OSPFv2 [RFC2328] and OSPFv3 Applications related to use of the prefix originating node
[RFC5340] protocols. information for topology reconstruction process on a controller and
the associated limitations are described in Appendix A and
Appendix B.
2. Conventions used in this document 1.1. 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 2. Protocol Extensions
The following terms are used in this document:
o ABR: Area Border Router
o ASBR: Autonomous System Border Router
o ERLD: Entropy Readable Label Depth
o EL: Entropy Label
o IS-IS: Intermediate System to Intermediate System
o LSA: Link-State Advertisement
o MSD: Maximum SID Depths
o NLRI: Network Layer Reachability Information
o OSPF: Open Shortest Path First
o SID: Segment IDentifier
o SDN: Software Definition Network
4. Inter-Area Prefix Source Advertisement Use Cases This document defines the Prefix Source Router-ID and the Prefix
Originator Sub-TLVs for inclusion of the Router ID and a reachable
address information for the router originating the prefix as a prefix
attribute.
Figure 1 illustrates a topology where OSPF is running in multiple 2.1. Prefix Source Router-ID Sub-TLV
areas. R0-R4 are routers in the backbone area, S1-S4 are internal
routers in area 1, and T1-T4 are internal routers in area 2. R1 and
R3 are ABRs between area 0 and area 1. R2 and R4 are ABRs between
area 0 and area 2. N1 is the network between router S1 and S2 and N2
is the network between router T1 and T2. Ls1 is the loopback address
of Node S1 and Lt1 is the loopback address of Node T1.
+-----------------+ For OSPFv2, the Prefix Source Router-ID Sub-TLV is an optional Sub-
|IP SDN Controller| TLV of the OSPFv2 Extended Prefix TLV [RFC7684]. For OSPFv3, the
+--------+--------+ Prefix Source Router-ID Sub-TLV is an optional Sub-TLV of the Intra-
| Area-Prefix TLV, Inter-Area-Prefix TLV, and External-Prefix TLV
| BGP-LS [RFC8362] when originating either an IPv4 [RFC5838] or an IPv6 prefix
| advertisement.
+---------------------+------+--------+-----+--------------+
| +--+ +--+ ++-+ ++-+ +-++ + -+ +--+|
| |S1+--------+S2+---+R1+---|R0+----+R2+---+T1+--------+T2||
| +-++ N1 +-++ ++-+ +--+ +-++ ++++ N2 +-++|
| | | | | || | |
| | | | | || | |
| +-++ +-++ ++-+ +-++ ++++ +-++|
| |S4+--------+S3+---+R3+-----------+R4+---+T3+--------+T4||
| +--+ +--+ ++-+ +-++ ++-+ +--+|
| | | |
| | | |
| Area 1 | Area 0 | Area 2 |
+---------------------+---------------+--------------------+
Figure 1: OSPF Inter-Area Prefix Originator Scenario The Prefix Source Router-ID Sub-TLV has the following format:
If S1 wants to send traffic to prefix Lt1 that is connected to T1 in 0 1 2 3
another area, it should know the ERLD and MSD values associated with 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
the node T1, and then construct the right label stack at the ingress +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
node for traffic destined to prefix Lt1. | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In another scenario, If R0 has some method to learn the originator of Figure 1: Prefix Source Router-ID Sub-TLV Format
network N1 and reports such information to IP SDN controller, then it
is possible for the controller to reconstruct the topology in the
non-backbone areas. The topology reconstruction process and its
limitations are described in the Appendix A and Appendix B.
5. External Prefix Source Advertisement Use Cases Where:
Figure 2 illustrates a topology where OSPF is running in different o Type: 4 for OSPFv2 and 27 for OSPFv3
domain that is connected by an Autonomous System Border Router
(ASBR). A, B, and C are routers in the Domain 1; C, D, and E are
routers in Domain 2. Router C is the ASBR between the two domains.
When router E receives an external prefix, it will redistribute it as o Length: 4
an AS-External LSA within domain 2. When C receives such LSA, the
originator information for such external prefix will be lost when it
encodes the prefix information with the current LSA format field. In
some situations, it will be helpful if C can advertise such
originator information.
+-------------------------------------------------------------------+ o OSPF Router ID : the OSPF Router ID of the OSPF router that
| | External Prefix | originated the prefix advertisement in the OSPF domain.
| +---+ +---+ +---+ +---+ +-|-+ |
| | A +-------+ B +----------| C +---------+ D +---------+ E |------|
| +---+ +---+ +---+ +---+ +---+ |
| Domain 1 | Domain 2 |
+-------------------------------------------------------------------+
Figure 2: OSPF External Prefix Originator Scenario A prefix advertisement MAY include more than one Prefix Source
Router-ID sub-TLV, one corresponding to each of the Equal-Cost Multi-
Path (ECMP) nodes that originated the given prefix.
From the above scenarios, we can conclude that it is useful to define A received Prefix Source Router-ID Sub-TLV with OSPF Router ID set to
the OSPF prefix originator sub TLV . 0 MUST be considered invalid and ignored. Additionally, reception of
such Sub-TLV SHOULD be logged as an error (subject to rate-limiting).
6. Prefix Source Router-ID sub-TLV 2.2. Prefix Originator Sub-TLV
[RFC7684] and [RFC8362] respectively define TLV-based LSAs for OSPFv2 For OSPFv2, the Prefix Originator Sub-TLV is an optional Sub-TLV of
and OSPFv3. These documents facilitate addition of new attributes the OSPFv2 Extended Prefix TLV [RFC7684]. For OSPFv3, the Prefix
for prefixes and provide the basis for a sub-TLV to advertise the Originator Sub-TLV is an optional Sub-TLV of the Intra-Area-Prefix
"Prefix Source Router ID". For OSPFv2, this sub-TLV is a sub-TLV of TLV, Inter-Area-Prefix TLV, and External-Prefix TLV [RFC8362] when
OSPFv2 Extended Prefix TLV which SHOULD be included in the "OSPFv2 originating either an IPv4 [RFC5838] or an IPv6 prefix advertisement.
Extended Prefix Opaque LSA" [RFC7684] for inter-area prefixes. For
OSPFv3, this sub-TLV is a sub-TLV of "Inter-Area-Prefix TLV", which
SHOULD be included in the "E-Inter-Area-Prefix-LSA" [RFC8362].
The "Prefix Source Router-ID" sub-TLV has the following format: The Prefix Originator Sub-TLV has the following format:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Source Router-ID | | Router Address (4 or 16 octects) |
+---------------------------------------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Prefix Source Router-ID sub-TLV Format
o Source Router-ID Sub-TLV Type: 4 (IANA TEMPORARY allocation) Figure 2: Prefix Originator Sub-TLV Format
[RFC7684] or 27 (IANA TEMPORARY allocation) [RFC8362]
o Length: 4 Where:
o Value: Router-ID of OSPFv2/OSPFv3 router that is the source of the o Type: TBD1 for OSPFv2 and TBD2 for OSPFv3
prefix.
This sub-TLV provides the same functionality as the IS-IS "IPv4/IPv6 o Length: 4 or 16
Source Router" TLV defined in [RFC7794].
7. Elements of Procedure o Router Address: A reachable IPv4 or IPv6 router address for the
router that originated the IPv4 or IPv6 prefix advertisement.
Such an address would be semantically equivalent to what may be
advertised in the OSPFv2 Router Address TLV [RFC3630] or in the
OSPFv3 Router IPv6 Address TLV [RFC5329].
The following sections describe the procedure to include the newly A prefix advertisement MAY include more than one Prefix Originator
defined "Source Router-ID Sub-TLV" in the related LSA for inter-area sub-TLV, one corresponding to each of the Equal-Cost Multi-Path
prefixes and external prefixes respectively. (ECMP) nodes that originated the given prefix.
7.1. Inter-Area Prefixes A received Prefix Originator Sub-TLV that has an invalid length (not
4 or 16) or a Reachable Address containing an invalid IPv4 or IPv6
address (dependent on address family of the associated prefix) MUST
be considered invalid and ignored. Additionally, reception of such
Sub-TLV SHOULD be logged as an error (subject to rate-limiting).
When an ABR, for example R2 in Figure 1, receives a Router-LSA [RFC7794] provides similar functionality for the Intermediate System
advertisement in area 2, it SHOULD originate the corresponding to Intermediate System (IS-IS) protocol.
"OSPFv2 Extended Prefix Opaque LSA" for OSPFv2 or "E-Inter-Area-
Prefix-LSA" for OSPFv3 that includes the Source Router-ID sub-TLV for
the network prefixes. For example, to identify the source router
prefix Lt1 and other inter-area prefixes in Figure 1.
When a router in another area, e.g., S1, receives such LSA, it then 3. Elements of Procedure
can ascertain that prefix Lt1 is associated with node T1 and obtain
the ERLD or MSD value from T1's Router-Information LSA [RFC7770] and
construct the right label stack at the ingress node S1 for traffic
destined to prefix Lt1.
When a router in another area, e.g., R0, receives such LSA, it learns This section describes the procedure for advertisement of the Prefix
the Prefix Source Router-id and includes it in the prefix information Source Router-ID and Prefix Originator Sub-TLVs along with the prefix
advertised to an SDN controller as described in advertisement.
[I-D.ietf-idr-bgp-ls-segment-routing-ext]. The SDN controller can
then use such information to build the inter-area topology according
to the process described in the Appendix A. The topology retrieval
process may not suitable for some environments as stated in
Appendix B.
7.2. External Prefixes The OSPF Router ID of the Prefix Source Router-ID is set to the OSPF
Router ID of the node originating the prefix in the OSPF domain.
When an ASBR, for example C in Figure 2, receives an AS-External LSA If the originating node is advertising an OSPFv2 Router Address TLV
for an external prefix in domain 2, it SHOULD extract the originator [RFC3630] or an OSPFv3 Router IPv6 Address TLV [RFC5329], then that
information from the "Advertising Router" field from the LSA header. value is set in the Router Address field of the Prefix Originator
When the prefix is advertised into domain 1 as an AS-External LSA, Sub-TLV. When the orignating node is not advertising such an
router C may also advertise the Source Router-ID using a AS-scoped address, implementations MAY support mechanisms to determine a
OSPFv2 Extended Prefix Opaque LSA or as a Sub-TLV in the OSPFv3 AS- reachable address belonging to the originating node to set in the
External LSA. Router Address field. Such mechanisms are outside the scope of this
document.
8. Security Considerations Implementations MAY support the selection of specific prefixes for
which the originating node information needs to be included with
their prefix advertisements.
Since this document extends the "OSPFv2 Extended Prefix LSA" and When an ABR generates inter-area prefix advertisements into its non-
"OSPFv3 E-Inter-Area-Prefix LSA", the security considerations for backbone areas corresponding to an inter-area prefix advertisement
[RFC7684] and [RFC8362] are applicable. from the backbone area, the only way to determine the originating
node information is based on the Prefix Source Router-ID and Prefix
Originator Sub-TLVs present in the inter-area prefix advertisement
originated into the backbone area by an ABR for another non-backbone
area. The ABR performs its prefix calculation to determine the set
of nodes that contribute to the best prefix reachability. It MUST
use the prefix originator information only from this set of nodes.
The ABR MUST NOT include the Prefix Source Router-ID or the Prefix
Originator Sub-TLVs when it is unable to determine the information of
the best originating node.
Modification of the "Prefix Source Sub-TLV" could be used for a Implementations MAY provide control on ABRs to selectively disable
Denial-of-Service attack and could inhibit the use cases described in the propagation of the originating node information across area
Section 4. If the OSPF domain is vulnerable to such attacks, OSPF boundaries.
authentication should be used as defined for OSPFv2 in [RFC5709] and
[RFC7474] and for OSPFv3 in [RFC7166].
Additionally, advertisement of the prefix source for inter-area Implementations MAY support the propagation of the originating node
prefixes facilitates reconstruction of the OSPF topology for other information along with a redistributed prefix into the OSPF domain
areas. Network operators may consider their topologies to be from another routing domain. The details of such mechanisms are
sensitive confidential data. For OSPFv3, IPsec can be used to outside the scope of this document. Such implementations MAY also
provide confidentiality [RFC4552]. Since there is no standard provide control on whether the Router Address in the Prefix
defined for native OSPFv2 IPsec, some form of secure tunnel is Originator Sub-TLV is set as the ABSR node address or as the address
required to provide confidentiality. of the actual node outside the OSPF domain that owns the prefix.
9. IANA Considerations When translating the NSSA prefix advertisements [RFC3101] to the AS
external prefix advertisements, the NSSA ABR, follows the same
procedures as an ABR generating inter-area prefix advertisements for
the propagation of the originating node information.
This specification defines the Prefix Source Router-ID sub-TLV as 4. Security Considerations
described in Section 6. This value should be added to the both
existing "OSPFv2 Extended Prefix TLV Sub-TLVs" and "OSPFv3 Extended-
LSA Sub-TLVs" registries.
The following sub-TLV is added to the "OSPFv2 Extended Prefix TLV Since this document extends the OSPFv2 Extended Prefix LSA, the
Sub-TLVs" registry. The allocation policy is IETF Review as defined security considerations for [RFC7684] are applicable. Similarly,
in [RFC7684] since this document extends the OSPFv3 E-Intra-Area-Prefix-LSA, E-
Inter-Area-Prefix-LSA, E-AS-External LSA and E-NSSA-LSA, the security
considerations for [RFC8362] are applicable.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. IANA Considerations
| Code Point | Description | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Prefix Source Sub-TLV | Allocation from IANA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Code Point in "OSPFv2 Extended Prefix TLV Sub-TLVs"
The following sub-TLV is added to the "OSPFv3 Extended-LSA Sub-TLVs" This document requests IANA for the allocation of the codepoint from
registry. The allocation policy is IETF Review as defined in the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry under the "Open
[RFC8362] Shortest Path First v2 (OSPFv2) Parameters" registry.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code Point | Description | Status | | Code | Description | IANA Allocation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Point | | Status |
| 27 | Prefix Source Sub-TLV | Allocation from IANA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | Prefix Source Router-ID Sub-TLV | early allocation done |
Figure 5: Code Point in "OSPFv3 Extended-LSA Sub-TLVs" | TBD1 | Prefix Originator Sub-TLV | pending |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10. Acknowledgement Figure 3: Code Points in OSPFv2 Extended Prefix TLV Sub-TLVs
This document requests IANA for the allocation of the codepoint from
the "OSPFv3 Extended Prefix TLV Sub-TLVs" registry under the "Open
Shortest Path First v3 (OSPFv3) Parameters" registry.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Description | IANA Allocation |
| Point | | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 27 | Prefix Source Router-ID Sub-TLV | early allocation done |
| TBD2 | Prefix Originator Sub-TLV | pending |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Code Points in OSPFv3 Extended-LSA Sub-TLVs
6. Acknowledgement
Many thanks to Les Ginsberg for his suggestions on this draft. Also Many thanks to Les Ginsberg for his suggestions on this draft. Also
thanks to Jeff Tantsura, Rob Shakir, Gunter Van De Velde, Goethals thanks to Jeff Tantsura, Rob Shakir, Gunter Van De Velde, Goethals
Dirk, Smita Selot, Shaofu Peng, and John E Drake for their valuable Dirk, Smita Selot, Shaofu Peng, and John E Drake for their valuable
comments. comments.
11. References 7. References
11.1. Normative References 7.1. Normative References
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>. <https://www.rfc-editor.org/info/rfc2328>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, RFC 3101, DOI 10.17487/RFC3101, January 2003,
<https://www.rfc-editor.org/info/rfc4552>. <https://www.rfc-editor.org/info/rfc3101>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>. <https://www.rfc-editor.org/info/rfc5340>.
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, DOI 10.17487/RFC5709, October
2009, <https://www.rfc-editor.org/info/rfc5709>.
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 7166,
DOI 10.17487/RFC7166, March 2014,
<https://www.rfc-editor.org/info/rfc7166>.
[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., [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <https://www.rfc-editor.org/info/rfc7684>. 2015, <https://www.rfc-editor.org/info/rfc7684>.
[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>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
F. Baker, "OSPFv3 Link State Advertisement (LSA) F. Baker, "OSPFv3 Link State Advertisement (LSA)
Extensibility", RFC 8362, DOI 10.17487/RFC8362, April Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
2018, <https://www.rfc-editor.org/info/rfc8362>. 2018, <https://www.rfc-editor.org/info/rfc8362>.
[RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 7.2. Informative References
"Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476,
DOI 10.17487/RFC8476, December 2018,
<https://www.rfc-editor.org/info/rfc8476>.
11.2. Informative References [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[I-D.ietf-idr-bgp-ls-segment-routing-ext] [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., "Traffic Engineering Extensions to OSPF Version 3",
and M. Chen, "BGP Link-State extensions for Segment RFC 5329, DOI 10.17487/RFC5329, September 2008,
Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 <https://www.rfc-editor.org/info/rfc5329>.
(work in progress), June 2019.
[I-D.ietf-ospf-mpls-elc] [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., R. Aggarwal, "Support of Address Families in OSPFv3",
and M. Bocci, "Signaling Entropy Label Capability and RFC 5838, DOI 10.17487/RFC5838, April 2010,
Entropy Readable Label-stack Depth Using OSPF", draft- <https://www.rfc-editor.org/info/rfc5838>.
ietf-ospf-mpls-elc-12 (work in progress), October 2019.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
Appendix A. Inter-Area Topology Retrieval Process Appendix A. Inter-Area Topology Retrieval Process
When an IP SDN Controller receives BGP-LS [RFC7752] information, it When an IP SDN Controller receives BGP-LS [RFC7752] information, it
should compare the prefix Network Layer Reachability Information should compare the prefix Network Layer Reachability Information
(NLRI) that is included in the BGP-LS NLRI. When it encounters the (NLRI) that is included in the BGP-LS NLRI. When it encounters the
same prefix but with different source router ID, it should extract same prefix but with different source router ID, it should extract
the corresponding area-ID, rebuild the link between these two source the corresponding area-ID, rebuild the link between these two source
routers in the non-backbone area. Below is one example that based on routers in the non-backbone area. Below is one example that based on
the Figure 1: the Figure 5 which illustrates a topology where OSPF is running in
multiple areas.
+-----------------+
|IP SDN Controller|
+--------+--------+
|
| BGP-LS
|
+---------------------+------+--------+-----+--------------+
| +--+ +--+ ++-+ ++-+ +-++ + -+ +--+|
| |S1+--------+S2+---+R1+---|R0+----+R2+---+T1+--------+T2||
| +-++ N1 +-++ ++-+ +--+ +-++ ++++ N2 +-++|
| | | | | || | |
| | | | | || | |
| +-++ +-++ ++-+ +-++ ++++ +-++|
| |S4+--------+S3+---+R3+-----------+R4+---+T3+--------+T4||
| +--+ +--+ ++-+ +-++ ++-+ +--+|
| | | |
| | | |
| Area 1 | Area 0 | Area 2 |
+---------------------+---------------+--------------------+
Figure 5: OSPF Inter-Area Prefix Originator Scenario
R0-R4 are routers in the backbone area, S1-S4 are internal routers in
area 1, and T1-T4 are internal routers in area 2. R1 and R3 are ABRs
between area 0 and area 1. R2 and R4 are ABRs between area 0 and
area 2. N1 is the network between router S1 and S2 and N2 is the
network between router T1 and T2. Ls1 is the loopback address of
Node S1 and Lt1 is the loopback address of Node T1.
Assuming we want to rebuild the connection between router S1 and Assuming we want to rebuild the connection between router S1 and
router S2 located in area 1: router S2 located in area 1:
a. Normally, router S1 will advertise prefix N1 within its router- a. Normally, router S1 will advertise prefix N1 within its router-
LSA. LSA.
b. When this router-LSA reaches the ABR router R1, it will convert b. When this router-LSA reaches the ABR router R1, it will convert
it into summary-LSA, add the Prefix Source Router-ID sub-TLV, it into summary-LSA, add the Source Router-ID Sub-TLV and the
which is router id of S1 in this example. Prefix Originator Sub-TLV, as described in Section 3.
c. R1 then floods this extension summary-LSA to R0, which is using c. R1 then floods this extension summary-LSA to R0, which is using
the BGP-LS protocol with IP SDN Controller. The controller then the BGP-LS protocol with IP SDN Controller. The controller then
knows the prefix for N1 is from S1. knows the prefix for N1 is from S1.
d. Router S2 will perform a similar process, and the controller will d. Router S2 will perform a similar process, and the controller will
also learn that prefix N1 is also from S2. also learn that prefix N1 is also from S2.
e. Then it can reconstruct the link between S1 and S2, using the e. Then it can reconstruct the link between S1 and S2, using the
prefix N1. The topology within Area 1 can then be reconstructed prefix N1. The topology within Area 1 can then be reconstructed
skipping to change at page 12, line 37 skipping to change at page 11, line 37
Peter Psenak Peter Psenak
Cisco Systems Cisco Systems
Pribinova Street 10 Pribinova Street 10
Bratislava, Eurovea Centre, Central 3 81109 Bratislava, Eurovea Centre, Central 3 81109
Slovakia Slovakia
Email: ppsenak@cisco.com Email: ppsenak@cisco.com
Ketan Talaulikar Ketan Talaulikar
Cisco Systems Cisco Systems
S.No. 154/6, Phase I, Hinjawadi
Pune 411 057
India India
Email: ketant@cisco.com Email: ketant@cisco.com
 End of changes. 67 change blocks. 
293 lines changed or deleted 258 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/