| < draft-xu-lsr-isis-flooding-reduction-in-msdc-01.txt | draft-xu-lsr-isis-flooding-reduction-in-msdc-02.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: April 21, 2019 Expedia, Inc | Expires: October 24, 2019 Expedia, Inc | |||
| J. Tantsura | J. Tantsura | |||
| Apstra, Inc. | Apstra, Inc. | |||
| S. Ma | S. Ma | |||
| Juniper | Juniper | |||
| October 18, 2018 | April 22, 2019 | |||
| IS-IS Flooding Reduction in MSDC | IS-IS Flooding Reduction in MSDC | |||
| draft-xu-lsr-isis-flooding-reduction-in-msdc-01 | draft-xu-lsr-isis-flooding-reduction-in-msdc-02 | |||
| Abstract | Abstract | |||
| IS-IS is commonly used as an underlay routing protocol for MSDC | IS-IS is commonly used as an underlay routing protocol for MSDC | |||
| (Massively Scalable Data Center) networks. For a given IS-IS router | (Massively Scalable Data Center) networks. For a given IS-IS router | |||
| within the CLOS topology, it would receive multiple copies of exactly | within the CLOS topology, it would receive multiple copies of exactly | |||
| the same LSP from multiple IS-IS neighbors. In addition, two IS-IS | the same LSP from multiple IS-IS neighbors. In addition, two IS-IS | |||
| neighbors may send each other the same LSP simultaneously. The | neighbors may send each other the same LSP simultaneously. The | |||
| unneccessary link-state information flooding wastes the precious | unnecessary link-state information flooding wastes the precious | |||
| process resource of IS-IS routers greatly due to the fact that there | process resource of IS-IS routers greatly due to the fact that there | |||
| are too many IS-IS neighbors for each IS-IS router within the CLOS | are too many IS-IS neighbors for each IS-IS router within the CLOS | |||
| topology. This document proposes some extensions to IS-IS so as to | topology. This document proposes some extensions to IS-IS so as to | |||
| reduce the IS-IS flooding within MSDC networks greatly. The | reduce the IS-IS flooding within MSDC networks greatly. The | |||
| reduction of the IS-IS flooding is much beneficial to improve the | reduction of the IS-IS flooding is much beneficial to improve the | |||
| scalability of MSDC networks. | scalability of MSDC networks. | |||
| Requirements Language | Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| 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 April 21, 2019. | This Internet-Draft will expire on October 24, 2019. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2018 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 | |||
| skipping to change at page 2, line 43 ¶ | skipping to change at page 2, line 43 ¶ | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | |||
| 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 | |||
| 7.2. Informative References . . . . . . . . . . . . . . . . . 6 | 7.2. Informative References . . . . . . . . . . . . . . . . . 6 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 1. Introduction | 1. Introduction | |||
| IS-IS is commonly used as an underlay routing protocol for Massively | IS-IS 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 | |||
| toplogy. For a given IS-IS router within the CLOS topology, it would | topology. For a given IS-IS router within the CLOS topology, it would | |||
| receive multiple copies of exactly the same LSP from multiple IS-IS | receive multiple copies of exactly the same LSP from multiple IS-IS | |||
| neighbors. In addition, two IS-IS neighbors may send each other the | neighbors. In addition, two IS-IS neighbors may send each other the | |||
| same LSP simultaneously. The unnecessary link-state information | same LSP simultaneously. The unnecessary link-state information | |||
| flooding wastes the precious process resource of IS-IS routers | flooding wastes the precious process resource of IS-IS routers | |||
| greatly and therefore IS-IS could not scale very well in MSDC | greatly and therefore IS-IS could not scale very well in MSDC | |||
| networks. | 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 the MSDC | |||
| skipping to change at page 3, line 45 ¶ | skipping to change at page 3, line 45 ¶ | |||
| | / // \ | / -- \ | | | / // \ | / -- \ | | |||
| | / // \ | / -- \ | | | / // \ | / -- \ | | |||
| +-+- //* +\\+-/-+ +---\-++ | +-+- //* +\\+-/-+ +---\-++ | |||
| |Router| |Router| |Router| | |Router| |Router| |Router| | |||
| +------+ +------+ +------+ | +------+ +------+ +------+ | |||
| Figure 1 | Figure 1 | |||
| With the assistance of a controller acting as IS-IS Designated | With the assistance of a controller acting as IS-IS Designated | |||
| Intermediate System (DIS) for the management LAN, IS-IS routers | Intermediate System (DIS) for the management LAN, IS-IS routers | |||
| within the MSDC network don't need to exchange any IS-IS Protocl | within the MSDC network don't need to exchange any IS-IS Protocol | |||
| Datagram Units (PDUs) other than Hello packets among them. In order | Datagram Units (PDUs) other than Hello packets among them. In order | |||
| to obtain the full topology information (i.e., the fully synchronized | to obtain the full topology information (i.e., the fully synchronized | |||
| link-state database) of the MSDC's network, these IS-IS routers would | link-state database) of the MSDC's network, these IS-IS routers would | |||
| exchange the link-state information with the controller being elected | exchange the link-state information with the controller being elected | |||
| as IS-IS DIS for the management LAN instead. | as IS-IS DIS for the management LAN instead. | |||
| To further suppress the flooding of multicast IS-IS PDUs originated | To further suppress the flooding of multicast IS-IS PDUs originated | |||
| from IS-IS routers over the management LAN, IS-IS routers would not | from IS-IS routers over the management LAN, IS-IS routers would not | |||
| send multicast IS-IS Hello packets over the management LAN. | send multicast IS-IS Hello packets over the management LAN. | |||
| Insteads, they just wait for IS-IS Hello packets originated from the | Instead, they just wait for IS-IS Hello packets originated from the | |||
| controller being elected as IS-IS DIS initially. Once an IS-IS DIS | controller being elected as IS-IS DIS initially. Once an IS-IS DIS | |||
| for the management LAN has been discovered, they start to send IS-IS | for the management LAN has been discovered, they start to send IS-IS | |||
| Hello packets directly (as unicasts) to the IS-IS DIS periodically. | Hello packets directly (as unicasts) to the IS-IS DIS periodically. | |||
| In addition, IS-IS routers would send IS-IS PDUs to the IS-IS DIS for | In addition, IS-IS routers would send IS-IS PDUs to the IS-IS DIS for | |||
| the management LAN as unicasts as well. In contrast, the controller | the management LAN as unicasts as well. In contrast, the controller | |||
| being elected as IS-IS DIS would send IS-IS PDUs as before. As a | being elected as IS-IS DIS would send IS-IS PDUs as before. As a | |||
| result, IS-IS routers would not receive IS-IS PDUs from one another | result, IS-IS routers would not receive IS-IS PDUs from one another | |||
| unless these IS-IS PDUs are forwarded as unknown unicasts over the | unless these IS-IS PDUs are forwarded as unknown unicasts over the | |||
| management LAN. Through the above modifications to the current IS-IS | management LAN. Through the above modifications to the current IS-IS | |||
| router behaviors, the IS-IS flooding is greatly reduced, which is | router behaviors, the IS-IS flooding is greatly reduced, which is | |||
| skipping to change at page 4, line 50 ¶ | skipping to change at page 4, line 50 ¶ | |||
| In other words, IS-IS routers would not send any IS-IS Hello packet | In other words, IS-IS routers would not send any IS-IS Hello packet | |||
| over the management LAN until they have found an IS-IS DIS for the | over the management LAN until they have found an IS-IS DIS for the | |||
| management LAN. Note that IS-IS routers SHOULD NOT be elected as IS- | management LAN. Note that IS-IS routers SHOULD NOT be elected as IS- | |||
| IS DIS for the management LAN (This is done by setting the DIS | IS DIS for the management LAN (This is done by setting the DIS | |||
| Priority of those IS-IS routers to zero). As a result, IS-IS routers | Priority of those IS-IS routers to zero). As a result, IS-IS routers | |||
| would not see each other over the management LAN. In other word, IS- | would not see each other over the management LAN. In other word, IS- | |||
| IS routers would not establish adjacencies with one other. | IS routers would not establish adjacencies with one other. | |||
| Furthermore, IS-IS routers SHOULD send all the types of IS-IS PDUs to | Furthermore, IS-IS routers SHOULD send all the types of IS-IS PDUs to | |||
| the controller being elected as IS-IS DIS as unicasts as well. | the controller being elected as IS-IS DIS 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 IS-IS routers' interfaces to the management LAN | LAN, the cost of all IS-IS routers' interfaces to the management LAN | |||
| SHOULD be set to the maximum value. | SHOULD be set to the maximum value. | |||
| When a given IS-IS router lost its connection to the management LAN, | When a given IS-IS router lost its connection to the management LAN, | |||
| it SHOULD actively establish adjacency with all of its IS-IS | it SHOULD actively establish adjacency with all of its IS-IS | |||
| neighbors within the CLOS network. As such, it could obtain the full | neighbors within the CLOS network. As such, it could obtain the full | |||
| LSDB of the CLOS network while flooding its self-originated LSPs to | LSDB of the CLOS network while flooding its self-originated LSPs to | |||
| the remaining part of the whole CLOS network through these IS-IS | the remaining part of the whole CLOS network through these IS-IS | |||
| neighbor. | neighbor. | |||
| End of changes. 10 change blocks. | ||||
| 10 lines changed or deleted | 10 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/ | ||||