< draft-xu-lsr-ospf-flooding-reduction-in-msdc-02.txt   draft-xu-lsr-ospf-flooding-reduction-in-msdc-03.txt >
Network Working Group X. Xu Network Working Group X. Xu
Internet-Draft Alibaba, Inc Internet-Draft Alibaba, Inc
Intended status: Standards Track L. Fang Intended status: Standards Track L. Fang
Expires: October 24, 2019 Expedia, Inc Expires: April 14, 2020 Expedia, Inc
J. Tantsura J. Tantsura
Apstra, Inc. Apstra, Inc.
S. Ma S. Ma
Juniper Juniper
April 22, 2019 October 12, 2019
OSPF Flooding Reduction in MSDC OSPF Flooding Reduction in Massively Scale Data Centers (MSDCs)
draft-xu-lsr-ospf-flooding-reduction-in-msdc-02 draft-xu-lsr-ospf-flooding-reduction-in-msdc-03
Abstract Abstract
OSPF is commonly used as an underlay routing protocol for MSDC OSPF is one of the used underlay routing protocol for MSDC (Massively
(Massively Scalable Data Center) networks. For a given OSPF router Scalable Data Center) networks. For a given OSPF router within the
within the CLOS topology, it would receive multiple copies of exactly CLOS topology, it would receive multiple copies of exactly the same
the same LSA from multiple OSPF neighbors. In addition, two OSPF LSA from multiple OSPF neighbors. In addition, two OSPF neighbors
neighbors may send each other the same LSA simultaneously. The may send each other the same LSA simultaneously. The unnecessary
unnecessary link-state information flooding wastes the precious link-state information flooding wastes the precious process resource
process resource of OSPF routers greatly due to the fact that there of OSPF routers greatly due to the presence of too many OSPF
are too many OSPF neighbors for each OSPF router within the CLOS neighbors for each OSPF router within the CLOS topology. This
topology. This document proposes some extensions to OSPF so as to document proposes extensions to OSPF so as to reduce the OSPF
reduce the OSPF flooding within MSDC networks greatly. The reduction flooding within such MSDC networks. The reduction of the OSPF
of the OSPF flooding is much beneficial to improve the scalability of flooding is much beneficial to improve the scalability of MSDC
MSDC networks. These modifications are applicable to both OSPFv2 and networks. These modifications are applicable to both OSPFv2 and
OSPFv3. OSPFv3.
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
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 October 24, 2019. This Internet-Draft will expire on April 14, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Modifications to Current OSPF Behaviors . . . . . . . . . . . 4 3. Modifications to Legacy OSPF Behaviors . . . . . . . . . . . 4
3.1. OSPF Routers as Non-DRs . . . . . . . . . . . . . . . . . 4 3.1. OSPF Routers as Non-DRs . . . . . . . . . . . . . . . . . 4
3.2. Controllers as DR/BDR . . . . . . . . . . . . . . . . . . 5 3.2. Controllers as DR/BDR . . . . . . . . . . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
OSPF is commonly used as an underlay routing protocol for Massively OSPF is commonly used as an underlay routing protocol for Massively
Scalable Data Center (MSDC) networks where CLOS is the most popular Scalable Data Center (MSDC) networks where CLOS is the most popular
topology. For a given OSPF router within the CLOS topology, it would topology. MSDCs are also called Large-Scale Data Centers.
receive multiple copies of exactly the same LSA from multiple OSPF
neighbors. In addition, two OSPF neighbors may send each other the For a given OSPF router within the CLOS topology, it would receive
same LSA simultaneously. The unnecessary link-state information multiple copies of exactly the same LSA from multiple OSPF neighbors.
flooding wastes the precious process resource of OSPF routers greatly In addition, two OSPF neighbors may send each other the same LSA
simultaneously. The unnecessary link-state information flooding
significantly wastes the precious process resource of OSPF routers
and therefore OSPF could not scale very well in MSDC networks. and therefore OSPF could not scale very well in MSDC networks.
To simplify the network management task, centralized controllers are To simplify the network management task, centralized controllers are
becoming fundamental network elements in most MSDCs. One or more becoming fundamental network elements in most MSDCs. One or more
controllers are usually connected to all routers within the MSDC controllers are usually connected to all routers within an MSDC
network via a Local Area Network (LAN) which is dedicated for network network via a Local Area Network (LAN) which is dedicated for network
management purpose (called management LAN), as shown in Figure 1. management purpose (called management LAN), as shown in Figure 1.
+----------+ +----------+ +----------+ +----------+
|Controller| |Controller| |Controller| |Controller|
+----+-----+ +-----+----+ +----+-----+ +-----+----+
|DR |BDR |DR |BDR
| | | |
| | | |
---+---------+---+----------+-----------+---+---------+-Management LAN ---+---------+---+----------+-----------+---+---------+-Management LAN
skipping to change at page 3, line 40 skipping to change at page 3, line 43
| / // \ | / -- \ | | / // \ | / -- \ |
| / // \ | / -- \ | | / // \ | / -- \ |
| / // \ | / -- \ | | / // \ | / -- \ |
| / // \ | / -- \ | | / // \ | / -- \ |
+-+- //* +\\+-/-+ +---\-++ +-+- //* +\\+-/-+ +---\-++
|Router| |Router| |Router| |Router| |Router| |Router|
+------+ +------+ +------+ +------+ +------+ +------+
Figure 1 Figure 1
With the assistance of controllers acting as OSPF Designated Router With the assistance of these controllers which are acting as OSPF
(DR)/Backup Designated Router (BDR) for the management LAN, OSPF Designated Router (DR)/Backup Designated Router (BDR) for the
routers within the MSDC network don't need to exchange any other management LAN, OSPF routers within the MSDC network don't need to
types of OSPF packet than the OSPF Hello packet among them. As exchange any other types of OSPF packet than the OSPF Hello packet
specified in [RFC2328], these Hello packets are used for the purpose among them. As specified in [RFC2328], these Hello packets are used
of establishing and maintaining neighbor relationships and ensuring for the purpose of establishing and maintaining neighbor
bidirectional communication between OSPF neighbors, and even the DR/ relationships and ensuring bidirectional communication between OSPF
BDR election purpose in the case where those OSPF routers are neighbors, and even the DR/BDR election purpose in the case where
connected to a broadcast network. In order to obtain the full those OSPF routers are connected to a broadcast network. In order to
topology information (i.e., the fully synchronized link-state obtain the full topology information (i.e., the fully synchronized
database) of the MSDC's network, these OSPF routers just need to link-state database) of the MSDC's network, these OSPF routers only
exchange the link-state information with the controllers being need to exchange the link-state information with the controllers
elected as OSPF DR/BDR for the management LAN instead. being elected as OSPF DR/BDR for the management LAN instead.
To further suppress the flooding of multicast OSPF packets originated To further suppress the flooding of multicast OSPF packets originated
from OSPF routers over the management LAN, OSPF routers would not from OSPF routers over the management LAN, OSPF routers would not
send multicast OSPF Hello packets over the management LAN. Instead, send multicast OSPF Hello packets over the management LAN. Instead,
they just wait for OSPF Hello packets originated from the controllers they just wait for OSPF Hello packets originated from the controllers
being elected as OSPF DR/BDR initially. Once OSPF DR/BDR for the being elected as OSPF DR/BDR initially. Once OSPF DR/BDR for the
management LAN have been discovered, they start to send OSPF Hello management LAN have been discovered, they start to send OSPF Hello
packets directly (as unicasts) to OSPF DR/BDR periodically. In packets directly (as unicasts) to OSPF DR/BDR periodically. In
addition, OSPF routers would send other types of OSPF packets (e.g., addition, OSPF routers would send other types of OSPF packets (e.g.,
Database Descriptor packet, Link State Request packet, Link State Database Descriptor packet, Link State Request packet, Link State
Update packet, Link State Acknowledgment packet) to OSPF DR/BDR for Update packet, Link State Acknowledgment packet) to OSPF DR/BDR for
the management LAN as unicasts as well. In contrast, the controllers the management LAN as unicasts as well. In contrast, the controllers
being elected as OSPF DR/BDR would send OSPF packets as specified in being elected as OSPF DR/BDR would send OSPF packets as specified in
[RFC2328]. As a result, OSPF routers would not receive OSPF packets [RFC2328]. As a result, OSPF routers within the MSDC would not
from one another unless these OSPF packets are forwarded as unknown receive OSPF packets from one another unless these OSPF packets are
unicasts over the management LAN. Through the above modifications to forwarded as unknown unicasts over the management LAN. Through these
the current OSPF router behaviors, the OSPF flooding is greatly modifications to the legacy OSPF router behaviors, the OSPF flooding
reduced, which is much beneficial to improve the scalability of MSDC is greatly reduced, which is much beneficial to improve the overall
networks. These modifications are applicable to both OSPFv2 scalability of MSDC networks. These modifications specified in this
[RFC2328] and OSPFv3 [RFC5340]. document are applicable to both OSPFv2 [RFC2328] and OSPFv3
[RFC5340].
Furthermore, the mechanism for OSPF refresh and flooding reduction in The mechanism for OSPF refresh and flooding reduction in stable
stable topologies as described in [RFC4136] could be considered as topologies as described in [RFC4136] may be considered as well.
well.
2. Terminology 2. Terminology
This memo makes use of the terms defined in [RFC2328]. This memo makes use of the terms defined in [RFC2328].
3. Modifications to Current OSPF Behaviors 3. Modifications to Legacy OSPF Behaviors
3.1. OSPF Routers as Non-DRs 3.1. OSPF Routers as Non-DRs
After the exchange of OSPF Hello packets among OSPF routers, the OSPF After the exchange of OSPF Hello packets among OSPF routers, the OSPF
neighbor relationship among them would transition to and remain in neighbor relationship among them would transition to and remain in
the TWO-WAY state. OSPF routers would originate Router-LSAs and/or the 2-WAY state. OSPF routers would originate Router-LSAs and/or
Network-LSAs accordingly depending upon the link-types. Note that Network-LSAs accordingly depending upon the link-types. Note that
the neighbors in the TWO-WAY state would be advertised in the Router- the neighbors in the 2-WAY state would be advertised in the Router-
LSAs and/or Network-LSA. This is a little bit different from the LSAs and/or Network-LSA. This is slightly different from the legacy
OSPF router behavior as specified in [RFC2328] where the neighbors in OSPF router behavior as specified in [RFC2328] where the neighbors in
the TWO-WAY state would not be advertised. However, these self- the TWO-WAY state would not be advertised. However, these self-
originated LSAs need not to be exchanged directly among them anymore. originated LSAs need not to be exchanged directly among them anymore.
Instead, these LSAs just need to be sent solely to the controllers Instead, these LSAs only need to be sent solely to the controllers
being elected as OSPF DR/BDR for the management LAN. being elected as OSPF DR/BDR for the management LAN.
To further reduce the flood of multicast OSPF packets over the To further reduce the flood of multicast OSPF packets over the
management LAN, OSPF routers SHOULD send OSPF packets as unicasts. management LAN, OSPF routers SHOULD send OSPF packets as unicasts.
More specifically, OSPF routers SHOULD send unicast OSPF Hello More specifically, OSPF routers SHOULD send unicast OSPF Hello
packets periodically to the controllers being elected as OSPF DR/BDR. packets periodically to the controllers being elected as OSPF DR/BDR.
In other words, OSPF routers would not send any OSPF Hello packet In other words, OSPF routers SHOULD NOT send any OSPF Hello packet
over the management LAN until they have found OSPF DR/BDR for the over the management LAN until they have found an OSPF DR/BDR for the
management LAN. Note that OSPF routers SHOULD NOT be elected as OSPF management LAN. Note that OSPF routers, within the MSDC, SHOULD NOT
DR/BDR for the management LAN (This is done by setting the Router be elected as OSPF DR/BDR for the management LAN (This is done by
Priority of those OSPF routers to zero). As a result, OSPF routers setting the Router Priority of those OSPF routers to zero). As a
would not see each other over the management LAN. Furthermore, OSPF result, OSPF routers would not see each other over the management
routers SHOULD send all other types of OSPF packets than OSPF Hello LAN. Furthermore, OSPF routers SHOULD send all other types of OSPF
packets (i.e., Database Descriptor packet, Link State Request packet, packets than OSPF Hello packets to the controllers being elected as
Link State Update packet, Link State Acknowledgment packet) to the OSPF DR/BDR as unicasts as well.
controllers being elected as OSPF DR/BDR as unicasts as well.
To avoid the data traffic from being forwarded across the management To avoid the data traffic from being forwarded across the management
LAN, the cost of all OSPF routers' interfaces to the management LAN LAN, the cost of all OSPF routers' interfaces to the management LAN
SHOULD be set to the maximum value. SHOULD be set to the maximum value.
When a given OSPF router lost its connection to the management LAN, When a given OSPF router lost its connection to the management LAN,
it SHOULD actively establish FULL adjacency with all of its OSPF it SHOULD actively establish FULL adjacency with all of its OSPF
neighbors within the CLOS network. As such, it could obtain the full neighbors within the MSDC network. As such, it could obtain the full
LSDB of the CLOS network while flooding its self-originated LSAs to LSDB of the MSDC network while flooding its self-originated LSAs to
the remaining part of the whole network. That's to say, for a given the remaining part of the whole network. That's to say, for a given
OSPF router within the CLOS network, it would not actively establish OSPF router within the MSDC network, it would not actively establish
FULL adjacency with its OSPF neighbor in the TWO-WAY state by FULL adjacency with its OSPF neighbor in the 2-WAY state by default.
default. However, it SHOULD NOT refuse to establish FULL adjacency However, it SHOULD NOT refuse to establish FULL adjacency with a
with a given OSPF neighbors when receiving Database Description given OSPF neighbors when receiving Database Description Packets from
Packets from that OSPF neighbor. that OSPF neighbor.
3.2. Controllers as DR/BDR 3.2. Controllers as DR/BDR
The controllers being elected as OSPF DR/BDR would send OSPF packets The controllers being elected as OSPF DR/BDR would send OSPF packets
as multicasts or unicasts as per [RFC2328]. In addition, Link State as multicasts or unicasts as per [RFC2328]. In addition, Link State
Acknowledgment packets are RECOMMENDED to be sent as unicasts rather Acknowledgment packets are RECOMMENDED to be sent as unicasts rather
than multicasts if possible. than multicasts.
4. Acknowledgements 4. Acknowledgements
The authors would like to thank Acee Lindem for his valuable comments The authors would like to thank Acee Lindem and Mohamed Boucadair for
and suggestions on this document. their valuable comments and suggestions on this document.
5. IANA Considerations 5. IANA Considerations
TBD. TBD.
6. Security Considerations 6. Security Considerations
TBD. TBD.
7. References 7. References
 End of changes. 20 change blocks. 
72 lines changed or deleted 73 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/