draft-ietf-ospf-link-overload-10.txt   draft-ietf-ospf-link-overload-11.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: May 30, 2018 H. Gredler Expires: July 5, 2018 H. Gredler
Individual Individual
M. Nanduri M. Nanduri
ebay Corporation ebay Corporation
L. Jalil L. Jalil
Verizon Verizon
November 26, 2017 January 1, 2018
OSPF Link Overload OSPF Link Overload
draft-ietf-ospf-link-overload-10 draft-ietf-ospf-link-overload-11
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 as being in an overload state to indicate able to advertise a link as 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 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 May 30, 2018. This Internet-Draft will expire on July 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Flooding Scope . . . . . . . . . . . . . . . . . . . . . . . 4 3. Flooding Scope . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 4 4.2. Remote IPv4 Address Sub-TLV . . . . . . . . . . . . . . . 4
4.3. Local/Remote Interface ID sub-TLV . . . . . . . . . . . . 5 4.3. Local/Remote Interface ID Sub-TLV . . . . . . . . . . . . 5
4.4. OSPFv3 Link-Overload sub-TLV . . . . . . . . . . . . . . 6 4.4. OSPFv3 Link-Overload sub-TLV . . . . . . . . . . . . . . 6
5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 6 4.5. BGP-LS Link-overload TLV . . . . . . . . . . . . . . . . 6
5.1. Point-to-point links . . . . . . . . . . . . . . . . . . 6 4.6. Distinguishing parallel links . . . . . . . . . . . . . . 7
5.2. Broadcast/NBMA links . . . . . . . . . . . . . . . . . . 7 5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 8
5.3. Point-to-multipoint links . . . . . . . . . . . . . . . . 7 5.1. Point-to-point links . . . . . . . . . . . . . . . . . . 8
5.4. Unnumbered interfaces . . . . . . . . . . . . . . . . . . 8 5.2. Broadcast/NBMA links . . . . . . . . . . . . . . . . . . 8
5.5. Hybrid Broadcast and P2MP interfaces . . . . . . . . . . 8 5.3. Point-to-multipoint links . . . . . . . . . . . . . . . . 9
6. Backward compatibility . . . . . . . . . . . . . . . . . . . 8 5.4. Unnumbered interfaces . . . . . . . . . . . . . . . . . . 9
7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 8 5.5. Hybrid Broadcast and P2MP interfaces . . . . . . . . . . 9
7.1. Pseudowire Services . . . . . . . . . . . . . . . . . . . 8 6. Backward compatibility . . . . . . . . . . . . . . . . . . . 10
7.2. Controller based Traffic Engineering Deployments . . . . 10 7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 10
7.3. L3VPN Services and sham-links . . . . . . . . . . . . . . 10 7.1. Pseudowire Services . . . . . . . . . . . . . . . . . . . 10
7.4. Hub and spoke deployment . . . . . . . . . . . . . . . . 11 7.2. Controller based Traffic Engineering Deployments . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7.3. L3VPN Services and sham-links . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7.4. Hub and spoke deployment . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 MaxLinkMetric overload state by setting all outgoing link costs to MaxLinkMetric
(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 on the node requires on a node and cannot be used when a single link on the node requires
maintenance. maintenance.
skipping to change at page 4, line 34 skipping to change at page 4, line 37
Opaque LSA as defined in [RFC7684]. 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 7)
Length: 0 Length: 0
4.2. Remote IPv4 address sub-TLV 4.2. Remote IPv4 Address Sub-TLV
This sub-TLV specifies the IPv4 address of remote endpoint on the This sub-TLV specifies the IPv4 address of remote endpoint on the
link. It is advertised in the Extended Link TLV as defined in link. It is advertised in the Extended Link TLV as defined in
[RFC7684]. This sub-TLV is optional and MAY be advertised in area- [RFC7684]. This sub-TLV is optional and MAY be advertised in area-
scoped Extended Link Opaque LSA to identify the link when there are scoped Extended Link Opaque LSA to identify the link when there are
multiple parallel links between two nodes. multiple parallel links between two nodes.
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 IPv4 address | | Remote IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Remote IPv4 address sub-TLV Figure 2: Remote IPv4 Address Sub-TLV
Type : TBA (suggested value 4) Type : TBA (suggested value 8)
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 when there are multiple parallel links identify the particular link when there are multiple parallel links
between two nodes. between two nodes.
4.3. Local/Remote Interface ID sub-TLV 4.3. Local/Remote Interface ID Sub-TLV
This sub-TLV specifies local and remote interface identifiers. It is This sub-TLV specifies local and remote interface identifiers. It is
advertised in the Extended Link TLV as defined in [RFC7684]. This advertised in the Extended Link TLV as defined in [RFC7684]. This
sub-TLV is optional and MAY be advertised in area-scoped Extended sub-TLV is optional and MAY be advertised in area-scoped Extended
Link Opaque LSA to identify the link when there are multiple parallel Link Opaque LSA to identify the link when there are multiple parallel
unnumbered links between two nodes. The local interface-id is unnumbered links between two nodes. The local interface-id is
generally readily available. One of the mechanisms to obtain remote generally readily available. One of the mechanisms to obtain remote
interface-id is described in [RFC4203]. interface-id is described in [RFC4203].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 9)
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 Link Overload sub-TLV is carried in the Router-Link TLV as The Link Overload sub-TLV is carried in the Router-Link TLV as
defined in the [I-D.ietf-ospf-ospfv3-lsa-extend] for OSPFv3. The defined in the [I-D.ietf-ospf-ospfv3-lsa-extend] for OSPFv3. The
Router-Link TLV contains the neighbour interface-id and can uniquely Router-Link TLV contains the neighbour interface-id and can uniquely
identify the link on the remote node. identify the link on the remote node.
skipping to change at page 6, line 22 skipping to change at page 6, line 39
identify the link on the remote node. identify the link on the remote node.
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 7)
Length: 0 Length: 0
4.5. BGP-LS Link-overload TLV
BGP-LS as defined in [RFC7752] is a mechanism to distribute network
information to external entities using BGP routing protocol. link-
overload is an imporatant link information that the external entities
can use for various usecases as defined in Section 7. BGP Link NLRI
is used to carry the link information. a new TLV called Link-
Overload is defined to describe the link attribute corresponding to
link-overload state.
4.6. Distinguishing parallel links
++++++++++I.w I.y +++++++++
|Router A|------------------|Router B |
| |------------------| |
++++++++++I.x I.z++++++++++
Figure 5: Parallel Linkls
Consider two routers A and B connected with two parallel point-to-
point interfaces. I.w and I.x represent the Interface address on
Router A's side and I.y and I.z represent Interface addresses on
Router B's side. The extended link opaque LSA as described in
[RFC7684] describes links using link-type, Link-ID and Link-data.
For ex. Link with address I.w is described as below on Router A.
Link-type = Point-to-point
Link-ID: Router-ID B
Link-Data = I.w
A third node (controller or head-end) in the network cannot
distinguish the Interface on router B which is connected to this
particular Interface with the above information. Interface with
address I.y or I.z could be chosen due to this ambiguity. In such
cases Remote-IPv4 Address sub-TLV should be originated and added to
the extended link-TLV. The usecases as described in Section 7
require controller or head-end nodes to interpret the link-overload
information and hence the need for the RemoteIPv4 address sub-TLV.
I.y is carried in the extended-link-TLV which unambiguously
identifies the interface on the remote side. OSPFv3 Router-link-TLV
as described in [I-D.ietf-ospf-ospfv3-lsa-extend] contains Interface
ID and neighbor's Interface-ID which can uniquely identify connecting
interface on the remote side and hence OSPFv3 does not require
seperate Remote-IPv6 address to be advertised along with OSPFv2-link-
overload-sub-TLV.
5. Elements of procedure 5. Elements of procedure
The Link-Overload sub-TLV indicates that the link identified by the As defined in [RFC7684] every link on the node will have a separate
sub-TLV is overloaded. The node that has the link to be taken out of Extended Link Opaque LSA. The node that has the link to be taken out
service SHOULD advertise the Link-Overload sub-TLV in the Extended of service SHOULD advertise the Link-Overload sub-TLV in the Extended
Link TLV of the Extended Link Opaque LSA as defined in [RFC7684] for Link TLV of the Extended Link Opaque LSA as defined in [RFC7684] for
OSPFv2. The Link-Overload information is advertised as a property of OSPFv2. The Link-Overload sub-TLV indicates that the link identified
the link and is flooded across the area. This information can be by the sub-TLV is overloaded. The Link-Overload information is
used by ingress routers or controllers to take special actions. An advertised as a property of the link and is flooded across the area.
application specific to this use case is described in Section 7.2. This information can be used by ingress routers or controllers to
take special actions. An 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 MUST set metric The node that has the link to be taken out of service MUST set metric
of the link to MaxLinkMetric (0xffff) and re-originate its router- of the link to MaxLinkMetric (0xffff) and re-originate its router-
LSA. The TE metric SHOULD be set to MAX-TE-METRIC (0xfffffffe) and LSA. The TE metric SHOULD be set to MAX-TE-METRIC (0xfffffffe) and
the node SHOULD re-originate the corresponding TE Link Opaque LSAs. the node SHOULD re-originate the corresponding TE Link Opaque LSAs.
skipping to change at page 9, line 35 skipping to change at page 11, line 22
CE1---------PE1----------PE2---------CE2 CE1---------PE1----------PE2---------CE2
| \ | \
| \ | \
| ------CE4 | ------CE4
| | | |
| | | |
| | | |
================================= =================================
Private VLAN Private VLAN
Figure 5: Pseudowire Services Figure 6: Pseudowire Services
In the example shown in Figure 5, when the PE1 node is going out of In the example shown in Figure 6, when the PE1 node is going out of
service for maintenance, service providers set the PE1 to overload service for maintenance, service providers set the PE1 to overload
state. The PE1 going in to overload state triggers all the CEs state. The PE1 going in to overload state triggers all the CEs
connected to the PE (CE1 in this case) to set their pseudowire links connected to the PE (CE1 in this case) to set their pseudowire links
passing via PE1 to link-overload state. The mechanisms used to passing via PE1 to link-overload state. The mechanisms used to
communicate between PE1 and CE1 is outside the scope of this communicate between PE1 and CE1 is outside the scope of this
document. CE1 sets the link-overload state on its private VLAN document. CE1 sets the link-overload state on its private VLAN
connecting CE3, CE2 and CE4 and changes the metric to MAX_METRIC and connecting CE3, CE2 and CE4 and changes the metric to MAX_METRIC and
re-originates the corresponding LSA. The remote end of the link at re-originates the corresponding LSA. The remote end of the link at
CE3, CE2, and CE4 also set the metric on the link to MaxLinkMetric CE3, CE2, and CE4 also set the metric on the link to MaxLinkMetric
and the traffic from both directions gets diverted away from the and the traffic from both directions gets diverted away from the
skipping to change at page 10, line 34 skipping to change at page 12, line 18
| |____________ | | | |____________ | |
| | | |
|--------- Primary Path ------------------| |--------- Primary Path ------------------|
PE1---------P1----------------P2---------PE2 PE1---------P1----------------P2---------PE2
| | | |
| | | |
|________P3________| |________P3________|
Alternate Path Alternate Path
Figure 6: Controller based Traffic Engineering Figure 7: 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 10Gbps. When P1->P2 link is being prepared bandwidth constraint of 10Gbps. When P1->P2 link is being prepared
for maintenance, the controller receives the link-overload for maintenance, the controller receives the link-overload
information, as there is no alternate path available which satisfies information, as there is no alternate path available which satisfies
the constraints, the controller chooses a path that is less optimal the constraints, the controller chooses a path that is less optimal
and temporarily sets up an alternate path via P1->P3->P2. Once the and 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
skipping to change at page 11, line 39 skipping to change at page 13, line 27
8. Security Considerations 8. Security Considerations
This document does not introduce any further security issues other This document does not introduce any further security issues other
than those discussed in [RFC2328] and [RFC5340]. than those discussed in [RFC2328] and [RFC5340].
9. IANA Considerations 9. IANA Considerations
This specification updates one OSPF registry: This specification updates one OSPF registry:
OSPF Extended Link TLVs Registry OSPFv2 Extended Link TLV Sub-TLVs
i) Link-Overload sub-TLV - Suggested value 5 i) Link-Overload Sub-TLV - Suggested value 7
ii) Remote IPv4 address sub-TLV - Suggested value 4 ii) Remote IPv4 Address Sub-TLV - Suggested value 8
iii) Local/Remote Interface ID sub-TLV - Suggested Value 11 iii) Local/Remote Interface ID Sub-TLV - Suggested Value 9
OSPFV3 Router Link TLV Registry OSPFv3 Extended-LSA sub-TLV Registry
i) Link-Overload sub-TLV - suggested value 4 i) Link-Overload sub-TLV - suggested value 7
BGP-LS Link NLRI Registry [RFC7752] BGP-LS Link NLRI Registry [RFC7752]
i)Link-Overload TLV - Suggested 1101 i)Link-Overload TLV - Suggested 1101
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, Acee Lindem and Ketan Talaulikar for inputs. Thanks to Jeffrey Zhang, Acee Lindem and Ketan Talaulikar for inputs.
Thanks to Karsten Thomann for careful review and inputs on the Thanks to Karsten Thomann for careful review and inputs on the
applications where link-overload is useful. applications where link-overload is useful.
11. References 11. References
 End of changes. 29 change blocks. 
51 lines changed or deleted 104 lines changed or added

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