Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Peter Psenak <> Fri, 21 April 2017 08:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 091F912948E for <>; Fri, 21 Apr 2017 01:08:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5_qgzoZ39CDR for <>; Fri, 21 Apr 2017 01:08:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1D19A1288B8 for <>; Fri, 21 Apr 2017 01:08:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4961; q=dns/txt; s=iport; t=1492762100; x=1493971700; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LpixeFMZowk47r7MLToxQp6af7xRmwvoLC5CekZhb4c=; b=dpx9Z2dvqcg20ymSj5Zqwf+6dNC9mB2QCz1SHJZeb+Kfdbh9AW9xvJgX N/MKHO9KSXQPKbV7w6gixGPbuUA7GFvXOHwzCPI8lQ5i/Zxi7QBcvsUSz AhMUERjbt6m1iKlLMIUooaEN7NqkJcEi85GnhP+5vsh3l1aZnB47Iw0rQ Y=;
X-IronPort-AV: E=Sophos;i="5.37,229,1488844800"; d="scan'208";a="652325368"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2017 08:08:18 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id v3L88HE7017206; Fri, 21 Apr 2017 08:08:17 GMT
Message-ID: <>
Date: Fri, 21 Apr 2017 10:08:18 +0200
From: Peter Psenak <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Shraddha Hegde <>, "Acee Lindem (acee)" <>
CC: "" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Apr 2017 08:08:23 -0000

Hi Shraddha,

please find my comments below:

The draft defines two mechanisms:

a) signaling the link overload to the neighbor. The purpose is to 
advertise the link with max-metric from both directions.

b) flooding the Link-Overload sub-TLV inside the area. The purpose is to 
let "LSP ingress routers/controllers can learn of the impending 
maintenance activity"

1. Why do we need two mechanisms? Why is (b) needed, given that (a) 
results in link being advertised with max-metric in both directions?

How is treatement of remote link having max-metric different to the 
treatment of a link that has the Link-Overload sub-TLV? I would 
understand the difference if you say that the link having the 
Link-Overload sub-TLV must not be used during SPF, but nothing like that 
is mentioned in the draft and I understand why.

Is (b) needed to cover the case, where the signaling defined in (a) is 
not understood by the neighbor on the other side of the link? If yes, 
please state it in the draft.

2. For the signaling defined in (a)-  using the Router Information LSA 
for signaling something to the direct neighbor is a very dirty hack. As 
the name of the LSA says, it has been defined to signal capability of 
the node, which has nothing to do with what you are trying to use it 
for. We have to stop polluting the protocol with such hacks. RFC5613 
defines a Link-Local Signaling mechanism for OSPF and that is the one we 
should use for siganling between neighbors.


On 19/04/17 15:08 , Shraddha Hegde wrote:
> Hi Acee,
> New version draft-ietf-ospf-link-overload-06 is posted where the remote-ipv4 addr is moved to a new sub-TLV.
> Pls review.
> The authors of the draft believe that draft has undergone multiple revisions/reviews and is ready for WG last call.
> Rgds
> Shraddha
> -----Original Message-----
> From: OSPF [] On Behalf Of Acee Lindem (acee)
> Sent: Saturday, March 18, 2017 2:28 AM
> Cc:
> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
> Hi Shraddha, et al,
> With respect to section 4.1, I agree that matching link endpoints in
> OSPFv2 requires more information. However, this is a general problem and the remote address should be a separate OSPFv2 Link Attribute LSA TLV rather than overloading the link overload TLV ;^)
> Thanks,
> Acee
> On 2/23/17, 11:18 AM, "OSPF on behalf of"
> < on behalf of> wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Open Shortest Path First IGP of the IETF.
>>         Title           : OSPF Link Overload
>>         Authors         : Shraddha Hegde
>>                           Pushpasis Sarkar
>>                           Hannes Gredler
>>                           Mohan Nanduri
>>                           Luay Jalil
>> 	Filename        : draft-ietf-ospf-link-overload-05.txt
>> 	Pages           : 13
>> 	Date            : 2017-02-23
>> Abstract:
>>    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
>>    metric to the highest metric on one side of the link is not
>>    sufficient to divert the traffic flowing in the other direction.
>>    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 on the link.  This information can be
>>    used by the network devices to re-route the traffic effectively.
>>    This document describes the protocol extensions to disseminate link-
>>    overload information in OSPFv2 and OSPFv3.
>> The IETF datatracker status page for this draft is:
>> There's also a htmlized version available at:
>> A diff from the previous version is available at:
>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> Internet-Drafts are also available by anonymous FTP at:
>> _______________________________________________
>> OSPF mailing list
> _______________________________________________
> OSPF mailing list
> _______________________________________________
> OSPF mailing list
> .