<?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">
]>
<?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-hegde-ospf-link-overload-01" 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="16" month="July" 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,
existing stub router mechanism described in <xref target="RFC3137"/> cannot be used.
It is useful for routers in OSPFv2 or OSPFv3 routing domain to be able to
advertise a  link being in overload state to indicate impending maintenance activity in the underlying network devices.
 </t>
<t>This document describes the protocol extensions to disseminate
link overload information in OSPFv2 and OSPFv3 protocol.</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> It is useful for routers in OSPFv2 or OSPFv3 routing domain to be able to
advertise a  link being in 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='Link overload sub TLV'>

<section title='OSPFv2 Link overload sub TLV'>
<t> 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 overload state when there are
       multiple parallel links between two nodes.
<vspace blankLines="1" />
</t>
</section>
<section title='OSPFv3 Link overload sub TLV'>
<t>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 which carries the
 sub TLV is overloaded. The node that has the link going  for maintenance, sets metric of the link to MAX-METRIC and re-originates the 
router LSA. The metric in the reverse direction also need to change to divert the traffic from reverse direction.
The node SHOULD originate Link overload sub TLV and include it in Extended link TLV and originate the
Extended Link Opaque LSA as defined in  <xref target="I-D.ietf-ospf-prefix-link-attr"/> for OSPFv2
and  E-Router-LSA as defined in <xref target="I-D.ietf-ospf-ospfv3-lsa-extend"/> for OSPFv3 and flood in the
OSPF area. </t>
 <t>when the originator of the Link Overload sub TLV, purges the extended link opaque LSA or re-originates without the Link Overload sub TLV,
 the metric on the remote node SHOULD be changed back to the original value.</t>
<t>Based on the link type of the overloaded link below actions MAY be taken by the receiver.</t>
<section title='Point-to-point links'>

<t>When a link overload TLV is received for a point-to-point link the receiver SHOULD identify the local link which corresponds to the
overloaded link and set the metric to MAX-METRIC (0xffff). Receiver node MUST re-originate  the router-LSA with the changed metric and flood 
into the OSPF area.</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.  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" />
When a link-overload TLV is received by the remote end for a broadcast/NBMA link
<vspace blankLines="1" />
-   If it’s DROther or BDR for that link, SHOULD not take any action.
-   If receiving node is DR for the link, it  MUST remove the originator of the link overload TLV from the list of connected neighbors  and
    MUST re-originate the network LSA and flood into the OSPF area.
</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 TLV is received for a point-to-multipoint link the receiver SHOULD identify the neighbor which corresponds to the
    overloaded link and set the metric to MAX-METRIC (0xffff). Receiver node MUST re-originate  the router-LSA with the changed metric and flood 
    into the OSPF area.</t>
</section>
    
</section>


<section title='Backward compatibility'>
   <t>The mechanism described in the document is fully backward compatible.It is required that the originator and receiver of 
   link-overload sub TLV understand the extensions defined in this document and in case of  broadcast links the originator 
   and the DR need to understand the extensions. Other nodes in the network compute based on increased metric and hence the feature is
   backward compatible.</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 to run over the pseudo-wire to get 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 the alternate path. Link overload feature provides facilities to achieve
this service by increasing the metric on the link but still allowing the traffic to use the link when there is no alternate path 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>Controller based deployments where the controller participates in the IGP protocol gets the link-overload information when the link maintenance is impending.
 Using this information controller finds an alternate path. If there are no alternate paths satisfying the traffic engineering constraints, controller might
 temporarily relax the constraints and put the service on different path. In the above example when P1->P2 link goes for maintenance, controller gets 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:
<vspace blankLines="1"/>
OSPF Extended Link TLVs Registry
<vspace blankLines="1"/>
   i) TBD – Link Overload TLV

  OSPFV3 Router Link TLV Registry
<vspace blankLines="1"/>
   i) TBD – Link Overload TLV
</t>
</section>
<section title='Acknowledgements'>
</section>


</middle>
<back>
<references title='Normative References'>
&RFC2328;
&RFC5340;
&RFC2119;
&RFC3137;
</references>
<references title='Informative 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"?>
</references>
</back>
</rfc>