<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2328 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml">
<!ENTITY RFC5340 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5340.xml">
<!ENTITY RFC3137 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3137.xml">
<!ENTITY RFC4203 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4203.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-ospf-link-overload-00" ipr="trust200902">
<front>
<title abbrev="OSPF link overload"> OSPF Link Overload</title>
<author initials="S." surname="Hegde" fullname="Shraddha Hegde">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>Embassy Business Park</street>
<city>Bangalore</city>
<region>KA</region>
<code>560093</code>
<country>India</country>
</postal>
<email>shraddha@juniper.net</email>
</address>
</author>
<author initials="P." surname="Sarkar" fullname="Pushpasis Sarkar">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>Embassy Business Park</street>
<city>Bangalore</city>
<region>KA</region>
<code>560093</code>
<country>India</country>
</postal>
<email>psarkar@juniper.net</email>
</address>
</author>
<author fullname="Hannes Gredler" initials="H." surname="Gredler">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>
<email>hannes@juniper.net</email>
</address>
</author>
<author fullname="Mohan Nanduri" initials="M." surname="Nanduri">
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>
<email>mnanduri@microsoft.com</email>
</address>
</author>
<author fullname="Luay Jalil" initials="L." surname="Jalil">
<organization>Verizon</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>luay.jalil@verizon.com</email>
</address>
</author>
<date day="19" month="October" year="2015"/>
<area>Routing</area>
<workgroup>Open Shortest Path First IGP</workgroup>
<keyword>MPLS</keyword>
<keyword>IGP</keyword>
<keyword>OSPF</keyword>
<abstract>
<t>  Many OSPFv2 or OSPFv3 deployments run on overlay networks provisioned by means of pseudo-wires or L2-circuits.
When the devices in the underlying network go for maintenance, it is useful to divert the traffic
away from the node before the maintenance is actually scheduled. Since the nodes in the underlying network are not visible to OSPF,
the existing stub router mechanism described in <xref target="RFC3137"/> cannot be used.</t>

<t>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 impending maintenance activity in the underlying network devices.
This information can be used by the network devices to re-route the traffic effectively.
 </t>
<t>This document describes the protocol extensions to disseminate
link overload information in OSPFv2 and OSPFv3.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction" anchor='intro'>

<t>When a node is being prepared for a planned maintenance or upgrade, 
<xref target="RFC3137"/> provides mechanisms to advertise the 
node being in an overload state by setting all outgoing link costs  to MAX-METRIC (0xffff). These procedures
are specific to the maintenance activity on a node and cannot be used when a single  link attached to the node
requires maintenance. </t>

<t>When a link is being prepared to be taken out of service, the traffic needs to be diverted from both ends of the link.
 Changing the metric on one side of the link
is not sufficient to divert the traffic flowing in both directions.  In traffic-engineering deployments, 
LSPs need to be moved away from the link without disrupting the services.
It is useful to be able to advertise the impending maintenance
activity on the link and to have LSP rerouting policies at the ingress to route the LSPs away from the link. </t>

 <t>It is useful for routers in OSPFv2 or OSPFv3 routing domain to be able to
advertise a  link being in an overload state to indicate impending maintenance activity on the link.
This document provides mechanisms to advertise link overload state in the flexible encodings provided by
OSPFv2 Prefix/Link Attribute Advertisement( <xref target="I-D.ietf-ospf-prefix-link-attr"/>) 
and OSPFv3 Extended LSA (<xref target="I-D.ietf-ospf-ospfv3-lsa-extend"/>).
Throughout this document, OSPF is used when the text applies to both
OSPFv2 and OSPFv3.  OSPFv2 or OSPFv3 is used when the text is
specific to one version of the OSPF protocol.
</t>
</section>

<section title="Motivation" anchor='Motivation'>

<t>The motivation of this document is to reduce manual intervention during maintenance activities.
The following objectives help to accomplish this in a range of deployment scenarios.</t>
<t>
<list style="numbers">
<t> Advertise impending maintenance activity so that the traffic from both directions 
can be diverted away from the link.</t>
<t> Allow the solution to be backward compatible so that nodes that do not understand the new advertisement do not
    cause routing loops.</t>
<t> Advertise the maintenance activity to other nodes in the network so that LSP ingress routers/controllers can learn the impending
    maintenance activity and apply specific policies to re-route the LSP for traffic-engineering based deployments.</t>
<t> Allow the link to be used as last resort link to prevent traffic disruption when alternate paths are not available.</t>

</list>
</t>
</section>

<section title='Link overload sub-TLV'>

<section title='OSPFv2 Link overload sub-TLV'>
<t> The Link Overload sub-TLV is carried as part of the Extended Link TLV as defined in 
<xref target="I-D.ietf-ospf-prefix-link-attr"/> for OSPFv2. 

<vspace blankLines="2" />
<figure anchor="OSPFv2-link-overload-TLV" title="Link Overload sub-TLV for OSPFv2">
<artwork>
       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 IP address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

</artwork>
</figure>
<vspace blankLines="1" />

Type : TBA
<vspace blankLines="1" />
Length: 4
<vspace blankLines="1" />
Value: Remote IPv4 address. The remote IP4 address is used to identify the particular link that is in the overload state when there are
       multiple parallel links between two nodes.
<vspace blankLines="1" />
</t>
</section>
<section title='OSPFv3 Link Overload sub-TLV'>
<t>The Link Overload sub-TLV is carried in the Router-Link TLV as defined in the <xref target="I-D.ietf-ospf-ospfv3-lsa-extend"/> for OSPFv3.
The Router-Link TLV contains the neighbor interface-id and can uniquely identify the link on the remote node.
<vspace blankLines="2" />
<figure anchor="OSPFv3-link-overload-TLV" title="Link Overload sub-TLV for OSPFv3">
<artwork>
       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
</artwork>
</figure>
<vspace blankLines="1" />
Type : TBA 
<vspace blankLines="1" />
Length: 0
</t>
</section>


</section>
<section title='Elements of procedure'>
<t>The Link Overload sub-TLV indicates that the link identified in by the
 sub-TLV is overloaded. The node that has the link to be taken out of service sets metric of the link to MAX-METRIC (0xffff) and re-originates the 
Router-LSA.  The TE metric is set to MAX-TE-METRIC-1 (0xfffffffe) and the node also re-originates the TE Link Opaque LSAs.
The node SHOULD originate the Link Overload sub-TLV in the Extended Link TLV in the
Extended Link Opaque LSA as defined in  <xref target="I-D.ietf-ospf-prefix-link-attr"/> for OSPFv2
or in the E-Router-LSA as defined in <xref target="I-D.ietf-ospf-ospfv3-lsa-extend"/> for OSPFv3.  This LSA should be flooded in the
OSPF area. A node which supports this draft and is at the remote end of the link identified in the Link Overload sub-TLV MUST set the metric of the link 
in the reverse direction to MAX-METRIC.  In addition, the TE metric MUST be changed to 0xfffffffe.  The remote node MUST re-originate the Router-LSA and
TE link opaque LSA with these updated metrics, and flood them into the area.</t>

<t>When the originator of the Link Overload sub-TLV purges the Extended Link Opaque LSA or re-originates it without the Link Overload sub-TLV,
 the remote node must re-originate the appropriate LSAs with the metric and TE metric values set to their original values.</t>
 
<t>The precise action taken by the remote node at the other end of the link identified as overloaded depends on the link type.</t>

<section title='Point-to-point links'>
<t>When a Link Overload sub-TLV is received for a point-to-point link the remote node SHOULD identify the local link which corresponds to the
overloaded link and set the metric to MAX-METRIC (0xffff). The remote node MUST re-originate  the router-LSA with the changed metric and flood 
into the OSPF area. The TE metric SHOULD be set to MAX-TE-METRIC-1 (0xfffffffe) and the TE opaque LSA for the link MUST be re-originated with new value.</t>
</section>

<section title='Broadcast/NBMA links'>
<t>Broadcast or NBMA networks in OSPF are represented by a star topology where the Designated Router (DR) is the central point to
which all other routers on the broadcast or NBMA network connect logically.  As 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 or advertise adjacencies with each other. 
 For the Broadcast links, the MAX-METRIC on the outgoing link cannot be changed since all the neighbors are on same link. 
Setting the link cost to MAX-METRIC would impact paths going via all neighbors. 
<vspace blankLines="1" />
For a broadcast link, the two part metric as described in <xref target="I-D.ietf-ospf-two-part-metric"/> is used. The node originating the Link
Overload sub-TLV MUST set the MT metric in the Network-to-Router Metric sub-TLV to MAX-METRIC 0xffff for OSPFv2 and OSPFv3. The nodes 
that receive the two part metric should follow the procedures described in <xref target="I-D.ietf-ospf-two-part-metric"/>.
The backward compatibility procedures described in <xref target="I-D.ietf-ospf-two-part-metric"/> should be followed to ensure 
loop free routing. 

</t>
</section>

<section title='Point-to-multipoint links'>
   <t> 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 point-to-multipoint link the remote node SHOULD identify the neighbor which corresponds to the
    overloaded link and set the metric to MAX-METRIC (0xffff). The remote node MUST re-originate the Router-LSA with the changed metric and flood 
    into the OSPF area.</t>
</section>

<section title='Unnumbered interfaces'>
   <t> Unnumbered interface do not have a unique IP addresses and borrow address from other interfaces.  
   <xref target="RFC2328"/> describes procedures to handle unnumbered interfaces. 
   The link-data field in the Extended Link TLV carries the interface-id instead of the IP address. 
   The Link Overload sub-TLV carries the remote interface-id in the Remote-ip-address field if the interface is unnumbered.
   Procedures to obtain interface-id of the remote side is defined in  <xref target="RFC4203"/>. </t>
</section>
    
</section>


<section title='Backward compatibility'>
   <t>The mechanism described in the document is fully backward compatible.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 overloaded 
    understand the extensions defined in this document.  In the case of broadcast links, the backward
   compatibility procedures as described in
  <xref target="I-D.ietf-ospf-two-part-metric"/> are applicable.
.</t>

</section>

<section title='Applications'>
<section title='Pseudowire Services'> 

<figure anchor="Pseudo_wire_services" title="Pseudowire Services">
<artwork>
     
        ---------PE3----------------PE4----------
       |                                         |
       |                                         |
     CE1---------PE1----------------PE2---------CE2
       |                                         |
       |                                         |
        -----------------------------------------
                 Private VLAN

</artwork>
</figure>
 <t>Many service providers offer pseudo-wire services to customers using L2 circuits. The IGP protocol that
runs in the customer network would also run over the pseudo-wire to create seamless private network for the customer. 
Service providers want to offer overload kind of functionality when the PE device is taken-out for maintenance.
The provider should guarantee that the PE is taken out for maintenance only after the service is successfully diverted
on an alternate path. There can be large number of customers attached to a PE node and the remote end-points for these pseudo-wires 
are spread across the service provider's network. It is a tedious and error-prone process to change the metric for all pseudo-wires in both directions.
The link overload feature 
simplifies the process by increasing the metric on the link in the reverse direction as well so that traffic in both directions is diverted away from the PE
undergoing maintenance. The link-overload feature allows the link to be used as a last resort link so that traffic is not disrupted when alternative
paths are not available.</t>
</section>

<section title='Controller based Traffic Engineering Deployments'>  

<figure anchor="TE_deployments" title="Controller based Traffic Engineering">
<artwork>
                      _____________
                     |             |
        -------------| Controller  |--------------
       |             |____________ |             |
       |                                         |
       |  ------- Primary Path ---------------    |
       PE1---------P1----------------P2---------PE2
                   |                  |
                   |                  |
                   |________P3________|      
                   
                      Alternate Path

</artwork>
</figure>
 <t>In controller-based deployments where the controller participates in the IGP protocol, the controller can also receive the link-overload information as a warning that link maintenance is imminent.
 Using this information, the controller can find alternate paths for traffic using the affected link.  
 The controller can apply various policies and re-route the LSPs away from the link undergoing maintenance. 
 If there are no alternate paths satisfying the traffic engineering constraints, the controller might
 temporarily relax those constraints and put the service on a different path. In the above example when P1->P2 link is being prepared for maintenance, 
 the controller receives the link-overload information
 and sets up an alternate path via P1->P3->P2. Once the traffic is diverted, P1->P2 link can be taken out for maintenance/upgrade.</t>
</section>

</section>
<!-- HG: FIXME: add traffic-engineering reference -->
<section title='Security Considerations' anchor='sec-con'>
<t>
This document does not introduce any further security issues other
than those discussed in <xref target="RFC2328"/> and <xref target="RFC5340"/>.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">

<t>This specification updates one OSPF registry:</t>
<t><vspace blankLines="1"/>
OSPF Extended Link TLVs Registry</t>
<t><vspace blankLines="1"/>
  i) TBD – Link Overload sub TLV </t>

  <t>OSPFV3 Router Link TLV Registry</t>
 <t><vspace blankLines="1"/>
   i) TBD – Link Overload sub TLV</t>

</section>
<section title='Acknowledgements'>
<t>Thanks to Chris Bowers for valuable inputs and edits to the document.</t>
</section>


</middle>
<back>

<references title='Normative References'>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ospf-prefix-link-attr-03.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ospf-ospfv3-lsa-extend-06.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ospf-two-part-metric-01.xml"?>
</references>
<references title='Informative References'>
&RFC2328;
&RFC5340;
&RFC2119;
&RFC3137;
&RFC4203;
</references>

</back>
</rfc>