< draft-xu-ospf-flooding-reduction-in-msdc-00.txt   draft-xu-ospf-flooding-reduction-in-msdc-01.txt >
Network Working Group X. Xu Network Working Group X. Xu
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track January 4, 2017 Intended status: Standards Track L. Fang
Expires: July 8, 2017 Expires: November 5, 2017 ebay
J. Tantsura
Individual
May 4, 2017
OSPF Flooding Reduction in MSDC OSPF Flooding Reduction in MSDC
draft-xu-ospf-flooding-reduction-in-msdc-00 draft-xu-ospf-flooding-reduction-in-msdc-01
Abstract Abstract
OSPF is commonly used as a underlay routing protocol for MSDC OSPF is commonly used as an underlay routing protocol for MSDC
(Massively Scalable Data Center) networks. This document proposes (Massively Scalable Data Center) networks. For a given OSPF router
some extensions to OSPF so as to reduce the OSPF flooding within MSDC within the CLOS topology, it would receive multiple copies of exactly
networks greatly. The reduction of the OSPF flooding is much the same LSA from multiple OSPF neighbors. In addition, two OSPF
beneficial to improve the scalability of MSDC networks. These neighbors may send each other the same LSA simultaneously. The
modifications are applicable to both OSPFv2 and OSPFv3. unneccessary link-state information flooding wastes the precious
process resource of OSPF routers greatly due to the fact that there
are too many OSPF neighbors for each OSPF router within the CLOS
topology. This document proposes some extensions to OSPF so as to
reduce the OSPF flooding within MSDC networks greatly. The reduction
of the OSPF flooding is much beneficial to improve the scalability of
MSDC networks. These modifications are applicable to both OSPFv2 and
OSPFv3.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 July 8, 2017. This Internet-Draft will expire on November 5, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 2, line 17 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Modifications to Current OSPF Behaviors . . . . . . . . . . . 4 3. Modifications to Current 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 . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
OSPF is commonly used as a underlay routing protocol for Massively OSPF is commonly used as an underlay routing protocol for Massively
Scalable Data Center (MSDC) networks. In addition, centrolized Scalable Data Center (MSDC) networks where CLOS is the most popular
controllers are becoming fundemental network elements in most MSDCs. toplogy. For a given OSPF router within the CLOS topology, it would
One or more controllers are usually connected to all routers within receive multiple copies of exactly the same LSA from multiple OSPF
the MSDC network via a Local Area Network (LAN) which is dedicated neighbors. In addition, two OSPF neighbors may send each other the
for network management purpose (called management LAN), as shown in same LSA simultaneously. The unnecessary link-state information
Figure 1. flooding wastes the precious process resource of OSPF routers greatly
and therefore OSPF could not scale very well in MSDC networks.
To simplify the network management task, centralized controllers are
becoming fundamental network elements in most MSDCs. One or more
controllers are usually connected to all routers within the MSDC
network via a Local Area Network (LAN) which is dedicated for network
management purpose (called management LAN), as shown in Figure 1.
+----------+ +----------+ +----------+ +----------+
|Controller| |Controller| |Controller| |Controller|
+----+-----+ +-----+----+ +----+-----+ +-----+----+
|DR |BDR |DR |BDR
| | | |
| | | |
---+---------+---+----------+-----------+---+---------+-Management LAN ---+---------+---+----------+-----------+---+---------+-Management LAN
| | | | | | | | | |
|Non-DR |Non-DR |Non-DR |Non-DR |Non-DR |Non-DR |Non-DR |Non-DR |Non-DR |Non-DR
skipping to change at page 3, line 37 skipping to change at page 3, line 37
| / // \ | / -- \ | | / // \ | / -- \ |
| / // \ | / -- \ | | / // \ | / -- \ |
| / // \ | / -- \ | | / // \ | / -- \ |
| / // \ | / -- \ | | / // \ | / -- \ |
+-+- //* +\\+-/-+ +---\-++ +-+- //* +\\+-/-+ +---\-++
|Router| |Router| |Router| |Router| |Router| |Router|
+------+ +------+ +------+ +------+ +------+ +------+
Figure 1 Figure 1
With the assistance of controllers acting as OSPF DR/BDR for the With the assistance of controllers acting as OSPF Designated Router
management LAN, OSPF routers within the MSDC network don't need to (DR)/Backup Designated Router (BDR) for the management LAN, OSPF
exchange any other type of OSPF packet than the OSPF Hello packet routers within the MSDC network don't need to exchange any other
among them. As specified in [RFC2328], these Hello packets are used types of OSPF packet than the OSPF Hello packet among them. As
for the purpose of establishing and maintaining neighbor specified in [RFC2328], these Hello packets are used for the purpose
relationships and ensuring bidirectional communication between OSPF of establishing and maintaining neighbor relationships and ensuring
neighbors, and even the Designated Router (DR)/Backup Designated bidirectional communication between OSPF neighbors, and even the DR/
Router (BDR) election purpose in the case where those OSPF routers BDR election purpose in the case where those OSPF routers are
are connected to a broadcast network. In order to obtain the full connected to a broadcast network. In order to obtain the full
topology information (i.e., the fully synchronized link-state topology information (i.e., the fully synchronized link-state
database) of the MSDC's network, these OSPF routers would exchange database) of the MSDC's network, these OSPF routers just need to
the link-state information with the controllers being elected as OSPF exchange the link-state information with the controllers being
DR/BDR for the management LAN instead. 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. Insteads, send multicast OSPF Hello packets over the management LAN. Insteads,
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 would not receive OSPF packets
from one another unless these OSPF packets are forwarded as unknown from one another unless these OSPF packets are forwarded as unknown
unicasts over the management LAN. Through the above modifications to unicasts over the management LAN. Through the above modifications to
the current OSPF router behaviors, the OSPF flooding is greatly the current OSPF router behaviors, the OSPF flooding is greatly
reduced which is much beneficial to improve the scalability of MSDC reduced, which is much beneficial to improve the scalability of MSDC
networks. These modifications are applicable to both OSPFv2 networks. These modifications are applicable to both OSPFv2
[RFC2328] and OSPFv3 [RFC5340]. [RFC2328] and OSPFv3 [RFC5340].
Furthermore, the mechanism for OSPF refresh and flooding reduction in Furthermore, the mechanism for OSPF refresh and flooding reduction in
stable topologies as described in [RFC2328] could be considered as stable topologies as described in [RFC4136] could be considered as
well. well.
1.1. Requirements Language 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", "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].
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 Current 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 transitions to and remains in neighbor relationship among them would transition to and remain in
the TWO-WAY state. OSPF routers would originate Router-LSAs and the TWO-WAY state. OSPF routers would originate Router-LSAs and/or
Network-LSAs as per [RFC2328]. However, these self-originated LSAs Network-LSAs accordingly depending upon the link-types. Note that
need not to be exchanged directly among them anymore. Instead, these the neighbors in the TWO-WAY state would be advertised in the Router-
LSAs just need to be sent solely to the controllers being elected as LSAs and/or Network-LSA. This is a little bit different from the
OSPF DR/BDR for the management LAN. OSPF router behavior as specified in [RFC2328] where the neighbors in
the TWO-WAY state would not be advertised. However, these self-
originated LSAs need not to be exchanged directly among them anymore.
Instead, these LSAs just need to be sent solely to the controllers
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 would 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 OSPF DR/BDR for the
management LAN. Note that OSPF routers SHOULD NOT be elected as OSPF management LAN. Note that OSPF routers SHOULD NOT be elected as OSPF
DR/BDR for the management LAN (This is done by setting the Router DR/BDR for the management LAN (This is done by setting the Router
Priority of those OSPF routers to zero). As a result, OSPF routers Priority of those OSPF routers to zero). As a result, OSPF routers
would not see each other over the management LAN. Furthermore, OSPF would not see each other over the management LAN. Furthermore, OSPF
routers SHOULD send all other types of OSPF packets than OSPF Hello routers SHOULD send all other types of OSPF packets than OSPF Hello
packets (i.e., Database Descriptor packet, Link State Request packet, packets (i.e., Database Descriptor packet, Link State Request packet,
Link State Update packet, Link State Acknowledgment packet) to the Link State Update packet, Link State Acknowledgment packet) to the
controllers being elected as OSPF DR/BDR as unicasts as well. controllers being elected as OSPF DR/BDR as unicasts as well.
To advoid 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,
it SHOULD actively establish FULL adjacency with all of its OSPF
neighbors within the CLOS network. As such, it could obtain the full
LSDB of the CLOS network while flooding its self-originated LSAs to
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
FULL adjacency with its OSPF neighbor in the TWO-WAY state by
default. However, it SHOULD NOT refuse to establish FULL adjacency
with a given OSPF neighbors when receiving Database Description
Packets from 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 if Acknowledgment packets are RECOMMENDED to be sent as unicasts rather
possible. than multicasts if possible.
4. Acknowledgements 4. Acknowledgements
TBD. The authors would like to thank Acee Lindem for his 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
skipping to change at page 6, line 20 skipping to change at page 6, line 37
[RFC4136] Pillay-Esnault, P., "OSPF Refresh and Flooding Reduction [RFC4136] Pillay-Esnault, P., "OSPF Refresh and Flooding Reduction
in Stable Topologies", RFC 4136, DOI 10.17487/RFC4136, in Stable Topologies", RFC 4136, DOI 10.17487/RFC4136,
July 2005, <http://www.rfc-editor.org/info/rfc4136>. July 2005, <http://www.rfc-editor.org/info/rfc4136>.
[RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
R. Aggarwal, "Support of Address Families in OSPFv3", R. Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, DOI 10.17487/RFC5838, April 2010, RFC 5838, DOI 10.17487/RFC5838, April 2010,
<http://www.rfc-editor.org/info/rfc5838>. <http://www.rfc-editor.org/info/rfc5838>.
Author's Address Authors' Addresses
Xiaohu Xu Xiaohu Xu
Huawei Huawei
Email: xuxiaohu@huawei.com Email: xuxiaohu@huawei.com
Luyuan Fang
ebay
Email: lufang@ebay.com
Jeff Tantsura
Individual
Email: jefftant@gmail.com
 End of changes. 19 change blocks. 
47 lines changed or deleted 79 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/