draft-ietf-ospf-link-overload-05.txt   draft-ietf-ospf-link-overload-06.txt 
Open Shortest Path First IGP S. Hegde Open Shortest Path First IGP S. Hegde
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Intended status: Standards Track P. Sarkar Intended status: Standards Track P. Sarkar
Expires: August 27, 2017 H. Gredler Expires: October 21, 2017 H. Gredler
Individual Individual
M. Nanduri M. Nanduri
Microsoft Corporation Microsoft Corporation
L. Jalil L. Jalil
Verizon Verizon
February 23, 2017 April 19, 2017
OSPF Link Overload OSPF Link Overload
draft-ietf-ospf-link-overload-05 draft-ietf-ospf-link-overload-06
Abstract Abstract
When a link is being prepared to be taken out of service, the traffic When a link is being prepared to be taken out of service, the traffic
needs to be diverted from both ends of the link. Increasing the needs to be diverted from both ends of the link. Increasing the
metric to the highest metric on one side of the link is not metric to the highest metric on one side of the link is not
sufficient to divert the traffic flowing in the other direction. sufficient to divert the traffic flowing in the other direction.
It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be
able to advertise a link being in an overload state to indicate able to advertise a link being in an overload state to indicate
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 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 August 27, 2017. This Internet-Draft will expire on October 21, 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 33 skipping to change at page 2, line 33
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Flooding Scope . . . . . . . . . . . . . . . . . . . . . . . 4 3. Flooding Scope . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Area scope flooding . . . . . . . . . . . . . . . . . . . 4 3.1. Area scope flooding . . . . . . . . . . . . . . . . . . . 4
3.2. Link scope flooding . . . . . . . . . . . . . . . . . . . 4 3.2. Link scope flooding . . . . . . . . . . . . . . . . . . . 4
4. Link-Overload sub-TLV . . . . . . . . . . . . . . . . . . . . 4 4. Link-Overload sub-TLV . . . . . . . . . . . . . . . . . . . . 4
4.1. OSPFv2 Link-overload sub-TLV . . . . . . . . . . . . . . 4 4.1. OSPFv2 Link-overload sub-TLV . . . . . . . . . . . . . . 4
4.2. OSPFv3 Link-Overload sub-TLV . . . . . . . . . . . . . . 5 4.2. Remote IPv4 address sub-TLV . . . . . . . . . . . . . . . 5
5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 5 4.3. Local/Remote Interface ID . . . . . . . . . . . . . . . . 6
5.1. Point-to-point links . . . . . . . . . . . . . . . . . . 6 4.4. OSPFv3 Link-Overload sub-TLV . . . . . . . . . . . . . . 6
5.2. Broadcast/NBMA links . . . . . . . . . . . . . . . . . . 6 5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 7
5.3. Point-to-multipoint links . . . . . . . . . . . . . . . . 7 5.1. Point-to-point links . . . . . . . . . . . . . . . . . . 7
5.4. Unnumbered interfaces . . . . . . . . . . . . . . . . . . 7 5.2. Broadcast/NBMA links . . . . . . . . . . . . . . . . . . 8
5.5. Hybrid Broadcast and P2MP interfaces . . . . . . . . . . 7 5.3. Point-to-multipoint links . . . . . . . . . . . . . . . . 8
6. Backward compatibility . . . . . . . . . . . . . . . . . . . 8 5.4. Unnumbered interfaces . . . . . . . . . . . . . . . . . . 8
7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 8 5.5. Hybrid Broadcast and P2MP interfaces . . . . . . . . . . 9
7.1. Pseudowire Services . . . . . . . . . . . . . . . . . . . 8 6. Backward compatibility . . . . . . . . . . . . . . . . . . . 9
7.2. Controller based Traffic Engineering Deployments . . . . 9 7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 9
7.3. L3VPN Services and sham-links . . . . . . . . . . . . . . 10 7.1. Pseudowire Services . . . . . . . . . . . . . . . . . . . 9
7.4. Hub and spoke deployment . . . . . . . . . . . . . . . . 10 7.2. Controller based Traffic Engineering Deployments . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7.3. L3VPN Services and sham-links . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7.4. Hub and spoke deployment . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
When a node is being prepared for a planned maintenance or upgrade, When a node is being prepared for a planned maintenance or upgrade,
[RFC6987] provides mechanisms to advertise the node being in an [RFC6987] provides mechanisms to advertise the node being in an
overload state by setting all outgoing link costs to MAX-METRIC overload state by setting all outgoing link costs to MAX-METRIC
(0xffff). These procedures are specific to the maintenance activity (0xffff). These procedures are specific to the maintenance activity
on a node and cannot be used when a single link attached to the node on a node and cannot be used when a single link attached to the node
requires maintenance. requires maintenance.
skipping to change at page 5, line 10 skipping to change at page 5, line 10
The Link-Overload sub-TLV identifies the link being in overload The Link-Overload sub-TLV identifies the link being in overload
state. It is carried in extended Link TLV as defined in [RFC7684] or state. It is carried in extended Link TLV as defined in [RFC7684] or
link local scope RI LSA as defined in [RFC7770]. link local scope RI LSA as defined in [RFC7770].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Link-Overload sub-TLV for OSPFv2 Figure 1: Link-Overload sub-TLV for OSPFv2
Type : TBA (suggested value 5)
Length: 0
4.2. Remote IPv4 address sub-TLV
This sub-TLV specifies the IPv4 address of the link on remote side.
It is carried in extended Link TLV as defined in [RFC7684].This sub-
TLV is optional and MAY be advertised in area scoped Extended Link
Opaque LSA to identify the link when there are multiple parallel
interfaces between two nodes.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Remote IPv4 address sub-TLV
Type : TBA (suggested value 4) Type : TBA (suggested value 4)
Length: 4 Length: 4
Value: Remote IPv4 address. The remote IP4 address is used to Value: Remote IPv4 address. The remote IP4 address is used to
identify the particular link that is in the overload state when there identify the particular link when there are multiple parallel links
are multiple parallel links between two nodes. between two nodes.
4.2. OSPFv3 Link-Overload sub-TLV 4.3. Local/Remote Interface ID
This sub-TLV specifies local and remote interface identifiers. It is
carried in extended Link TLV as defined in [RFC7684].This sub-TLV is
optional and MAY be advertised in area scoped Extended Link Opaque
LSA to identify the link when there are multiple parallel unnumbered
interfaces between two nodes. The procedures to originate this sub-
TLV is defined in [RFC4203]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Local/Remote Interface ID sub-TLV
Type : TBA (suggested value 11)
Length: 8
Value: 4 octets of Local Interface ID followed by 4 octets of Remote
interface ID.
4.4. OSPFv3 Link-Overload sub-TLV
The OSPFv3 Link-Overload sub-TLV is carried in the link local scope The OSPFv3 Link-Overload sub-TLV is carried in the link local scope
OSPFv3 RI LSA as defined in [RFC7770]. OSPFv3 RI LSA as defined in [RFC7770].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Link-Overload sub-TLV for OSPFv3 Figure 4: Link-Overload sub-TLV for OSPFv3
Type : TBA (Suggested value 4) Type : TBA (Suggested value 4)
Length: 0 Length: 0
The area scope advertisement of Link-Overload sub-TLV for OSPFv3 will The area scope advertisement of Link-Overload sub-TLV for OSPFv3 will
be described in a separate document. be described in a separate document.
5. Elements of procedure 5. Elements of procedure
The Link-Overload sub-TLV indicates that the link identified by the The Link-Overload sub-TLV indicates that the link identified by the
sub-TLV is overloaded. The node that has the link to be taken out of sub-TLV is overloaded. The node that has the link to be taken out of
service SHOULD originate the Link-Overload sub-TLV in the Extended service SHOULD originate the Link-Overload sub-TLV in the Extended
skipping to change at page 7, line 34 skipping to change at page 8, line 46
to MAX-METRIC (0xffff). The remote node MUST re-originate the to MAX-METRIC (0xffff). The remote node MUST re-originate the
Router-LSA with the changed metric and flood into the OSPF area. Router-LSA with the changed metric and flood into the OSPF area.
5.4. Unnumbered interfaces 5.4. Unnumbered interfaces
Unnumbered interface do not have a unique IP addresses and borrow Unnumbered interface do not have a unique IP addresses and borrow
address from other interfaces. [RFC2328] describes procedures to address from other interfaces. [RFC2328] describes procedures to
handle unnumbered interfaces in the context of the Router LSA. We handle unnumbered interfaces in the context of the Router LSA. We
apply a similar procedure to the Extended Link TLV carrying the Link- apply a similar procedure to the Extended Link TLV carrying the Link-
Overload sub-TLV in to handle unnumbered interfaces. The link-data Overload sub-TLV in to handle unnumbered interfaces. The link-data
field in the Extended Link TLV carries the interface-id instead of field in the Extended Link TLV carries the Local interface-id instead
the IP address. The Link-Overload sub-TLV carries the remote of the IP address. The Local/Remote Interface ID sub-TLV MUST be
interface-id in the remote-ip-address field if the interface is originated when there are multiple parallel unnumbered interfaces
unnumbered. Procedures to obtain interface-id of the remote side are between two nodes. Procedures to obtain interface-id of the remote
defined in [RFC4203]. side are defined in [RFC4203].
5.5. Hybrid Broadcast and P2MP interfaces 5.5. Hybrid Broadcast and P2MP interfaces
Hybrid Broadcast and P2MP interfaces represent a broadcast network Hybrid Broadcast and P2MP interfaces represent a broadcast network
modeled as P2MP interfaces. [RFC6845] describes procedures to handle modeled as P2MP interfaces. [RFC6845] describes procedures to handle
these interfaces. Operation for the Hybrid interfaces is similar to these interfaces. Operation for the Hybrid interfaces is similar to
the P2MP interfaces. When a Link-Overload sub-TLV is received for a the P2MP interfaces. When a Link-Overload sub-TLV is received for a
hybrid link the remote node SHOULD identify the neighbour which hybrid link the remote node SHOULD identify the neighbour which
corresponds to the overloaded link and set the metric to MAX-METRIC corresponds to the overloaded link and set the metric to MAX-METRIC
(0xffff). All the remote nodes connected to originator MUST re- (0xffff). All the remote nodes connected to originator MUST re-
skipping to change at page 9, line 22 skipping to change at page 10, line 22
CE1---------PE1----------PE2---------CE2 CE1---------PE1----------PE2---------CE2
| \ | \
| \ | \
| ------CE4 | ------CE4
| | | |
| | | |
| | | |
================================= =================================
Private VLAN Private VLAN
Figure 3: Pseudowire Services Figure 5: Pseudowire Services
In the example shown in Figure 3, when the PE1 node is going for In the example shown in Figure 5, when the PE1 node is going for
maintenance, service providers set the PE1 to overload state. The maintenance, service providers set the PE1 to overload state. The
PE1 going in overload state triggers all the CEs (In this example PE1 going in overload state triggers all the CEs (In this example
CE1)connected to the PE to set their pseudowire links passing via PE1 CE1)connected to the PE to set their pseudowire links passing via PE1
to link-overload state. The mechanisms used to communicate between to link-overload state. The mechanisms used to communicate between
PE1 and CE1 is outside the scope of this document. CE1 sets the PE1 and CE1 is outside the scope of this document. CE1 sets the
link-overload state on its private VLAN connecting CE3, CE2 and CE4 link-overload state on its private VLAN connecting CE3, CE2 and CE4
and modifies the metric to MAX_METRIC and floods the information, the and modifies the metric to MAX_METRIC and floods the information, the
remote end of the link at CE3, CE2, and CE4 also set the metric on remote end of the link at CE3, CE2, and CE4 also set the metric on
the link to MAX-METRIC and the traffic from both directions gets the link to MAX-METRIC and the traffic from both directions gets
diverted away from the link. diverted away from the link.
skipping to change at page 10, line 18 skipping to change at page 11, line 18
| |____________ | | | |____________ | |
| | | |
|--------- Primary Path ------------------| |--------- Primary Path ------------------|
PE1---------P1----------------P2---------PE2 PE1---------P1----------------P2---------PE2
| | | |
| | | |
|________P3________| |________P3________|
Alternate Path Alternate Path
Figure 4: Controller based Traffic Engineering Figure 6: Controller based Traffic Engineering
In the above example, PE1->PE2 LSP is set-up to satisfy a constraint In the above example, PE1->PE2 LSP is set-up to satisfy a constraint
of 10 Gbps bandwidth on each link. The links P1->P3 and P3->P2 have of 10 Gbps bandwidth on each link. The links P1->P3 and P3->P2 have
only 1 Gbps capacity and there is no alternate path satisfying the only 1 Gbps capacity and there is no alternate path satisfying the
bandwidth constraint of 10GB. When P1->P2 link is being prepared for bandwidth constraint of 10GB. When P1->P2 link is being prepared for
maintenance, the controller receives the link-overload information, maintenance, the controller receives the link-overload information,
as there is no alternate path available which satisfies the as there is no alternate path available which satisfies the
constraints, controller chooses a path that is less optimal and constraints, controller chooses a path that is less optimal and
temporarily sets up an alternate path via P1->P3->P2. Once the temporarily sets up an alternate path via P1->P3->P2. Once the
traffic is diverted, the P1->P2 link can be taken out of service for traffic is diverted, the P1->P2 link can be taken out of service for
 End of changes. 15 change blocks. 
40 lines changed or deleted 88 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/