draft-ietf-ospf-link-overload-07.txt   draft-ietf-ospf-link-overload-08.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: January 3, 2018 H. Gredler Expires: January 18, 2018 H. Gredler
Individual Individual
M. Nanduri M. Nanduri
ebay Corporation ebay Corporation
L. Jalil L. Jalil
Verizon Verizon
July 2, 2017 July 17, 2017
OSPF Link Overload OSPF Link Overload
draft-ietf-ospf-link-overload-07 draft-ietf-ospf-link-overload-08
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 January 3, 2018. This Internet-Draft will expire on January 18, 2018.
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 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . . . . . . . . . . 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.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. Remote IPv4 address sub-TLV . . . . . . . . . . . . . . . 5 4.2. Remote IPv4 address sub-TLV . . . . . . . . . . . . . . . 4
4.3. Local/Remote Interface ID . . . . . . . . . . . . . . . . 6 4.3. Local/Remote Interface ID . . . . . . . . . . . . . . . . 5
4.4. OSPFv3 Link-Overload sub-TLV . . . . . . . . . . . . . . 6 4.4. OSPFv3 Link-Overload sub-TLV . . . . . . . . . . . . . . 6
5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 7 5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 6
5.1. Point-to-point links . . . . . . . . . . . . . . . . . . 7 5.1. Point-to-point links . . . . . . . . . . . . . . . . . . 6
5.2. Broadcast/NBMA links . . . . . . . . . . . . . . . . . . 8 5.2. Broadcast/NBMA links . . . . . . . . . . . . . . . . . . 7
5.3. Point-to-multipoint links . . . . . . . . . . . . . . . . 8 5.3. Point-to-multipoint links . . . . . . . . . . . . . . . . 7
5.4. Unnumbered interfaces . . . . . . . . . . . . . . . . . . 8 5.4. Unnumbered interfaces . . . . . . . . . . . . . . . . . . 8
5.5. Hybrid Broadcast and P2MP interfaces . . . . . . . . . . 9 5.5. Hybrid Broadcast and P2MP interfaces . . . . . . . . . . 8
6. Backward compatibility . . . . . . . . . . . . . . . . . . . 9 6. Backward compatibility . . . . . . . . . . . . . . . . . . . 8
7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Pseudowire Services . . . . . . . . . . . . . . . . . . . 9 7.1. Pseudowire Services . . . . . . . . . . . . . . . . . . . 8
7.2. Controller based Traffic Engineering Deployments . . . . 10 7.2. Controller based Traffic Engineering Deployments . . . . 9
7.3. L3VPN Services and sham-links . . . . . . . . . . . . . . 11 7.3. L3VPN Services and sham-links . . . . . . . . . . . . . . 10
7.4. Hub and spoke deployment . . . . . . . . . . . . . . . . 11 7.4. Hub and spoke deployment . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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 3, line 34 skipping to change at page 3, line 33
by means of pseudo-wires or L2-circuits. Prior to devices in the by means of pseudo-wires or L2-circuits. Prior to devices in the
underlying network going offline for maintenance, it is useful to underlying network going offline for maintenance, it is useful to
divert the traffic away from the node before the maintenance is divert the traffic away from the node before the maintenance is
actually scheduled. Since the nodes in the underlying network are actually scheduled. Since the nodes in the underlying network are
not visible to OSPF, the existing stub router mechanism described in not visible to OSPF, the existing stub router mechanism described in
[RFC6987] cannot be used. An application specific to this use case [RFC6987] cannot be used. An application specific to this use case
is described in Section 7.1 is described in Section 7.1
This document provides mechanisms to advertise link-overload state in This document provides mechanisms to advertise link-overload state in
the flexible encodings provided by OSPFv2 Prefix/Link Attribute the flexible encodings provided by OSPFv2 Prefix/Link Attribute
Advertisement([RFC7684]) and RI LSA ([RFC7770]). Throughout this Advertisement([RFC7684]). Throughout this document, OSPF is used
document, OSPF is used when the text applies to both OSPFv2 and when the text applies to both OSPFv2 and OSPFv3. OSPFv2 or OSPFv3 is
OSPFv3. OSPFv2 or OSPFv3 is used when the text is specific to one used when the text is specific to one version of the OSPF protocol.
version of the OSPF protocol.
2. Motivation 2. Motivation
The motivation of this document is to reduce manual intervention The motivation of this document is to reduce manual intervention
during maintenance activities. The following objectives help to during maintenance activities. The following objectives help to
accomplish this in a range of deployment scenarios. accomplish this in a range of deployment scenarios.
1. Advertise impending maintenance activity so that traffic from 1. Advertise impending maintenance activity so that traffic from
both directions can be diverted away from the link. both directions can be diverted away from the link.
skipping to change at page 4, line 15 skipping to change at page 4, line 12
3. Advertise the maintenance activity to other nodes in the network 3. Advertise the maintenance activity to other nodes in the network
so that LSP ingress routers/controllers can learn of the so that LSP ingress routers/controllers can learn of the
impending maintenance activity and apply specific policies to re- impending maintenance activity and apply specific policies to re-
route the LSPs for traffic-engineering based deployments. route the LSPs for traffic-engineering based deployments.
4. Allow the link to be used as last resort link to prevent traffic 4. Allow the link to be used as last resort link to prevent traffic
disruption when alternate paths are not available. disruption when alternate paths are not available.
3. Flooding Scope 3. Flooding Scope
The link-overload information can be flooded in area scoped extended The link-overload information is flooded in area scoped Extended Link
link LSA [RFC7684] or a link scoped RI LSA [RFC7770] or both based on Opaque LSA [RFC7684]. The Link-Overload sub-TLV MAY be processed by
the needs of the application. Section 7 describes applications the head-end nodes or the controller as described in the Section 7.
requiring area scope as well as link scope link-overload information. The procedures for processing the Link-Overload sub-TLV is described
in Section 5.
3.1. Area scope flooding
For OSPFv2, Link-Overload sub-TLV is carried in the extended Link TLV
as defined in [RFC7684].
3.2. Link scope flooding
The link local scope RI LSA MAY carry the Link-Overload sub-TLV as
defined in Section 4. The link local scope RI-LSA corresponds to the
link on which the LSA arrives and there is no need to explicitly
specify the remote IPv4 address. The remote IPv4 address field MAY
be zero when the Link-Overload sub-TLV is carried in the link local
RI LSA. The Link-Overload sub-TLV MAY appear in any instance of the
link local RI-LSA. The Link-Overload sub-TLV is carried in the RI-
LSA for both OSPFv2 and OSPFv3.
4. Link-Overload sub-TLV 4. Link-Overload sub-TLV
4.1. OSPFv2 Link-overload sub-TLV 4.1. OSPFv2 Link-overload sub-TLV
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 in the Extended Link
link local scope RI LSA as defined in [RFC7770]. Opaque LSA as defined in [RFC7684].
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 1: Link-Overload sub-TLV for OSPFv2 Figure 1: Link-Overload sub-TLV for OSPFv2
Type : TBA (suggested value 5) Type : TBA (suggested value 5)
skipping to change at page 6, line 30 skipping to change at page 6, line 4
| Local Interface ID | | Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID | | Remote Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Local/Remote Interface ID sub-TLV Figure 3: Local/Remote Interface ID sub-TLV
Type : TBA (suggested value 11) Type : TBA (suggested value 11)
Length: 8 Length: 8
Value: 4 octets of Local Interface ID followed by 4 octets of Remote Value: 4 octets of Local Interface ID followed by 4 octets of Remote
interface ID. interface ID.
4.4. OSPFv3 Link-Overload sub-TLV 4.4. OSPFv3 Link-Overload sub-TLV
The OSPFv3 Link-Overload sub-TLV is carried in the link local scope The definition of OSPFv3 Link-Overload sub-TLV is defined below. The
OSPFv3 RI LSA as defined in [RFC7770]. area scope advertisement of Link-Overload sub-TLV for OSPFv3 will be
described in a separate document.
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 4: 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
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
Link TLV in the Extended Link Opaque LSA as defined in [RFC7684] for Link TLV in the Extended Link Opaque LSA as defined in [RFC7684] for
OSPFv2. The Link-Overload information is carried as a property of OSPFv2. The Link-Overload information is carried as a property of
the link and is flooded across the area. This information can be the link and is flooded across the area. This information can be
used by ingress routers or controllers to take special actions. An used by ingress routers or controllers to take special actions. An
application specific to this use case is described in Section 7.2. application specific to this use case is described in Section 7.2.
The precise action taken by the remote node at the other end of the The precise action taken by the remote node at the other end of the
link identified as overloaded depends on the link type. link identified as overloaded depends on the link type.
5.1. Point-to-point links 5.1. Point-to-point links
The node that has the link to be taken out of service SHOULD set The node that has the link to be taken out of service MUST set metric
metric of the link to MAX-METRIC (0xffff) and re- originate the of the link to MAX-METRIC (0xffff) and re- originate the Router-LSA.
Router-LSA. The TE metric SHOULD be set to MAX-TE-METRIC -1 The TE metric SHOULD be set to MAX-TE-METRIC -1 (0xfffffffe) and the
(0xfffffffe) and the node SHOULD re-originate the TE Link Opaque node SHOULD re-originate the TE Link Opaque LSAs. When a Link-
LSAs. When a Link-Overload sub-TLV is received for a point-to-point Overload sub-TLV is received for a point-to-point link, the remote
link, the remote node SHOULD identify the local link which node MUST identify the local link which corresponds to the overloaded
corresponds to the overloaded link and set the metric to MAX-METRIC link and set the metric to MAX-METRIC (0xffff)and the remote node
(0xffff)and the remote node SHOULD re-originate the router-LSA with MUST re-originate the router-LSA with the changed metric. The TE
the changed metric. The TE metric SHOULD be set to MAX-TE-METRIC -1 metric SHOULD be set to MAX-TE-METRIC -1 (0xfffffffe) and the TE
(0xfffffffe) and the TE opaque LSA for the link SHOULD be re- opaque LSA for the link SHOULD be re-originated with new value.
originated with new value.
Extended link opaque LSAs and the Extended link TLV are not scoped Extended link opaque LSAs and the Extended link TLV are not scoped
for multi-topology [RFC4915]. In multi-topology deployments for multi-topology [RFC4915]. In multi-topology deployments
[RFC4915], the Link-Overload sub-TLV carried in an Extended Link [RFC4915], the Link-Overload sub-TLV carried in an Extended Link
opaque LSA corresponds to all the topologies the link belongs to. opaque LSA corresponds to all the topologies the link belongs to.
The receiver node SHOULD change the metric in the reverse direction The receiver node SHOULD change the metric in the reverse direction
corresponding to all the topologies to which the reverse link belongs corresponding to all the topologies to which the reverse link belongs
and re-originate the Router LSA as defined in [RFC4915]. and re-originate the Router LSA as defined in [RFC4915].
When the originator of the Link-Overload sub-TLV purges the Extended When the originator of the Link-Overload sub-TLV purges the Extended
skipping to change at page 8, line 17 skipping to change at page 7, line 32
Broadcast or NBMA networks in OSPF are represented by a star topology Broadcast or NBMA networks in OSPF are represented by a star topology
where the Designated Router (DR) is the central point to which all where the Designated Router (DR) is the central point to which all
other routers on the broadcast or NBMA network connect logically. As other routers on the broadcast or NBMA network connect logically. As
a result, routers on the broadcast or NBMA network advertise only a result, routers on the broadcast or NBMA network advertise only
their adjacency to the DR. Routers that do not act as DR do not form their adjacency to the DR. Routers that do not act as DR do not form
or advertise adjacencies with each other. For the Broadcast links, or advertise adjacencies with each other. For the Broadcast links,
the MAX-METRIC on the remote link cannot be changed since all the the MAX-METRIC on the remote link cannot be changed since all the
neighbours are on same link. Setting the link cost to MAX-METRIC neighbours are on same link. Setting the link cost to MAX-METRIC
would impact paths going via all neighbours. would impact paths going via all neighbours.
The node that has the link to be taken out of service SHOULD set The node that has the link to be taken out of service MUST set metric
metric of the link to MAX-METRIC(0xffff) and re-originate the Router- of the link to MAX-METRIC(0xffff) and re-originate the Router-LSA.
LSA. The TE metric SHOULD be set to MAX-TE-METRIC -1(0xfffffffe) and The TE metric SHOULD be set to MAX-TE-METRIC -1(0xfffffffe) and the
the node SHOULD re-originate the TE Link Opaque LSAs. For a node SHOULD re-originate the TE Link Opaque LSAs. For a broadcast
broadcast link, the two part metric as described in [RFC8042] is link, the two part metric as described in [RFC8042] is used. The
used. The node originating the Link-Overload sub-TLV MUST set the node originating the Link-Overload sub-TLV MUST set the metric in the
metric in the Network-to-Router Metric sub-TLV to MAX-METRIC 0xffff Network-to-Router Metric sub-TLV to MAX-METRIC 0xffff for OSPFv2 and
for OSPFv2 and OSPFv3 and re-originate the LSAs the TLV is carried- OSPFv3 and re-originate the LSAs the TLV is carried-in. The nodes
in. The nodes that receive the two part metric should follow the that receive the two part metric should follow the procedures
procedures described in [RFC8042]. The backward compatibility described in [RFC8042]. The backward compatibility procedures
procedures described in [RFC8042] should be followed to ensure loop described in [RFC8042] should be followed to ensure loop free
free routing. routing.
5.3. Point-to-multipoint links 5.3. Point-to-multipoint links
Operation for the point-to-multipoint links is similar to the point- Operation for the point-to-multipoint links is similar to the point-
to-point links. When a Link-Overload sub-TLV is received for a to-point links. When a Link-Overload sub-TLV is received for a
point-to-multipoint link the remote node SHOULD identify the point-to-multipoint link the remote node MUST identify the neighbour
neighbour which corresponds to the overloaded link and set the metric which corresponds to the overloaded link and set the metric to MAX-
to MAX-METRIC (0xffff). The remote node MUST re-originate the METRIC (0xffff). The remote node MUST re-originate the Router-LSA
Router-LSA with the changed metric and flood into the OSPF area. 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 Local interface-id instead field in the Extended Link TLV carries the Local interface-id instead
of the IP address. The Local/Remote Interface ID sub-TLV MUST be of the IP address. The Local/Remote Interface ID sub-TLV MUST be
originated when there are multiple parallel unnumbered interfaces originated when there are multiple parallel unnumbered interfaces
between two nodes. Procedures to obtain interface-id of the remote between two nodes. One of the mechanisms to obtain interface-id of
side are defined in [RFC4203]. the remote 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 MUST 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-
originate the Router-LSA with the changed metric and flood into the originate the Router-LSA with the changed metric and flood into the
OSPF area. OSPF area.
6. Backward compatibility 6. Backward compatibility
The mechanism described in the document is fully backward compatible. The mechanism described in the document is fully backward compatible.
It is required that the originator of the Link-Overload sub-TLV as It is required that the originator of the Link-Overload sub-TLV as
well as the node at the remote end of the link identified as well as the node at the remote end of the link identified as
skipping to change at page 12, line 35 skipping to change at page 11, line 46
i) TBD - Link-Overload sub-TLV i) TBD - Link-Overload sub-TLV
BGP-LS Link NLRI Registry [RFC7752] BGP-LS Link NLRI Registry [RFC7752]
i)TBD - Link-Overload sub-TLV i)TBD - Link-Overload sub-TLV
10. Acknowledgements 10. Acknowledgements
Thanks to Chris Bowers for valuable inputs and edits to the document. Thanks to Chris Bowers for valuable inputs and edits to the document.
Thanks to Jeffrey Zhang and Acee Lindem for inputs. Thanks to Thanks to Jeffrey Zhang,Acee Lindem and Ketan Talaulikar for inputs.
Karsten Thomann for careful review and inputs on the applications Thanks to Karsten Thomann for careful review and inputs on the
where link-overload is useful. applications where link-overload is useful.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast
and Point-to-Multipoint Interface Type", RFC 6845, and Point-to-Multipoint Interface Type", RFC 6845,
DOI 10.17487/RFC6845, January 2013, DOI 10.17487/RFC6845, January 2013,
<http://www.rfc-editor.org/info/rfc6845>. <http://www.rfc-editor.org/info/rfc6845>.
skipping to change at page 13, line 11 skipping to change at page 12, line 25
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, <http://www.rfc-editor.org/info/rfc7684>. 2015, <http://www.rfc-editor.org/info/rfc7684>.
[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,
<http://www.rfc-editor.org/info/rfc7752>. <http://www.rfc-editor.org/info/rfc7752>.
[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, <http://www.rfc-editor.org/info/rfc7770>.
[RFC8042] Zhang, Z., Wang, L., and A. Lindem, "OSPF Two-Part [RFC8042] Zhang, Z., Wang, L., and A. Lindem, "OSPF Two-Part
Metric", RFC 8042, DOI 10.17487/RFC8042, December 2016, Metric", RFC 8042, DOI 10.17487/RFC8042, December 2016,
<http://www.rfc-editor.org/info/rfc8042>. <http://www.rfc-editor.org/info/rfc8042>.
11.2. Informative References 11.2. Informative 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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
 End of changes. 23 change blocks. 
93 lines changed or deleted 67 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/