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

Alexander Okonnikov <alexander.okonnikov@gmail.com> Fri, 21 April 2017 12:29 UTC

Return-Path: <alexander.okonnikov@gmail.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDBF12948F for <ospf@ietfa.amsl.com>; Fri, 21 Apr 2017 05:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4uX3mmicw28 for <ospf@ietfa.amsl.com>; Fri, 21 Apr 2017 05:29:07 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0AAD126DCA for <ospf@ietf.org>; Fri, 21 Apr 2017 05:29:06 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id c80so44009346lfh.3 for <ospf@ietf.org>; Fri, 21 Apr 2017 05:29:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=xQlBlveJ3C0k3BatxiMQECs/6OX09a970lKI9PorkY0=; b=MszTAQHzU978qJqC2yf+PVW7E8X9GWCBrIcMzEASlwzRiYVsvoywQWDDeamK0P7h6p 76zpVX/GmoQoA9oyl5ZefaN0Yr2E5ob5b1O9FDZ5X9vUG4d2t3yjMlB6NggEg6h1p4Zr 4q+E5IRKtG7pc2+kNAEB5L0JzSw68P/8uu5PwpZbuUZZN5eRTHuD00mewMh5M9JUwt9y sIZuB94eKP+62E5/KSWn3wsywCo6d7adEbsskXpxAZTlp9zJeLEIXaO6aEP8nSgCT/Tw afruhUyYorsrTGBRHX/VuhCWWRq+stL93nLRx99rcXzslatCf+u97DrRnPpiydhRhL0s lVNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=xQlBlveJ3C0k3BatxiMQECs/6OX09a970lKI9PorkY0=; b=HviOeS8JZrUAxZQbiYXjBPNdlDD2CTsCxftMVJf+lT0zRQI16/dY4OQ+Cpq6+B+OCo pwVXqdJvOw0vKOs3is9PlBVZTGy5TP9x4+KQpTtjiXVBJlJCiDrXcgDjQn3/+stbOWWp GfFzFbFdA2NO5smNCFby+vy3bTAT49g+ODh7O5mMb1uSHqx4kXza6r/Rr1gSHxEAyoW3 VQmjQfXz2Ya+BkZLfYEniLJzJ7Z3lqgGCTICULy8VPSmx8cRix4yVjRbRNyc9AjlYiQd fURUM1LX4/2KH+L9GjkhMqulCEBPNdUoNg+zJdmHxcv9WSy8o9XnEgo010jsJHAV67kx 2tKQ==
X-Gm-Message-State: AN3rC/6G33+gdbW9jQO2T7M7Q1dYWeoiy5tiyKLQF9flhXQfCR8v9Zgi 12SjGl0EJJDEgg==
X-Received: by 10.46.92.194 with SMTP id q185mr4925996ljb.67.1492777745175; Fri, 21 Apr 2017 05:29:05 -0700 (PDT)
Received: from [192.168.1.17] (secretmaker-96.ip.PeterStar.net. [217.195.72.96]) by smtp.gmail.com with ESMTPSA id f20sm1566081lfa.21.2017.04.21.05.29.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 05:29:04 -0700 (PDT)
To: Peter Psenak <ppsenak@cisco.com>, Shraddha Hegde <shraddha@juniper.net>, "Acee Lindem (acee)" <acee@cisco.com>
References: <148786668469.20333.199396876398174521.idtracker@ietfa.amsl.com> <D4F1C502.A346C%acee@cisco.com> <BN3PR05MB27066BF8587D26282B08B579D5180@BN3PR05MB2706.namprd05.prod.outlook.com> <58F9BDF2.4040502@cisco.com> <BN3PR05MB2706DA68D0700949F9268706D51A0@BN3PR05MB2706.namprd05.prod.outlook.com> <58F9EA4B.7060704@cisco.com>
Cc: "ospf@ietf.org" <ospf@ietf.org>
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Message-ID: <0e8cb635-0d9f-f80a-5221-c1a88f24a194@gmail.com>
Date: Fri, 21 Apr 2017 15:29:03 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <58F9EA4B.7060704@cisco.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/_lublLVReatSL_qpBAOJxH2NQvg>
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Apr 2017 12:29:10 -0000

Hi Peter,

See my comments inline.

Thanks.

21.04.2017 14:17, Peter Psenak пишет:
> Hi Shraddha,
>
> please see inline:
>
> On 21/04/17 12:53 , Shraddha Hegde wrote:
>> Hi Peter,
>>
>> Thanks for the detailed review. Pls see inline..
>>
>> -----Original Message-----
>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>> Sent: Friday, April 21, 2017 1:38 PM
>> To: Shraddha Hegde <shraddha@juniper.net>; Acee Lindem (acee) 
>> <acee@cisco.com>
>> Cc: ospf@ietf.org
>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>>
>> 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.
>> <Shraddha> Metric alone cannot be used as an indication for impending 
>> maintenance activity. When other nodes like ingress/controller need 
>> to understand the impending maintenance activity, area level 
>> advertisement would be needed. Application specific to this is 
>> described in sec 7.2
>
> no argument about the need of area level flooding - Router LSA with 
> the max metric will be flooded within the area.
>
> I have read the section 7.2 several times, but I still do not 
> understand what is the purpose of the Link-Overload sub-TLV there. 
> What is the controller going to do when it receives the area scoped 
> Link-Overload sub-TLV and how it is different to the case where the 
> link is advertised in the Router LSA with max-metric in both directions?
The fact that link metric has been maximized could not be a trigger for 
LSP recalculation. Some implementations consider IGP topology change as 
a trigger for LSP recalculation, but others - don't. Also, max metric 
itself doesn't tell about exact reason for what link metric was 
increased. It could be result of IGP-LDP synchronization, for example, 
which is irrespective to TE LSPs. From the other hand, when 
head-end/controller receives explicit indication (Link-overload), it 
could interpret it safely as a trigger to reroute LSP, even if 
overloaded link is only link that satisfies constrains (from CSPF 
perspective). Otherwise, increased metric could not be enough reason to 
relax constrains for LSP.
>
>>
>> 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.
>> <Shraddha>  LLS is a good mechanism to use for signaling link level 
>> information that are useful before the adjacency is established. 
>> Section 2 RFC 5613  states that the LLS is not expected to be used 
>> for use-cases which cause routing changes. Link-overload does result 
>> into routing changes and is best handled using link local scope LSAs.
>
> - LLS can be used to signal information prior to adjacency bringup as 
> well as when the adjacency is FULL state. There are existing LLS TLVs 
> that are send when adjacency is in FULL state.
>
> - in your case the use of LLS would be to change the metric on the 
> link in the reverse direction. That is not resulting in any routing 
> changes directly (look at it as the remote configuration request). 
> It's the max-metric in the Router LSA that is going to change the 
> routing. So using LLS to signal what you need is perfectly valid.
>
> I just can not see how we can standardize the use of RI LSA for what 
> you are proposing to use it - it's completely wrong IMHO.
>
> thanks,
> Peter
>
>>
>> thanks,
>> Peter
>>
>>
>>
>> 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 [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem
>>> (acee)
>>> Sent: Saturday, March 18, 2017 2:28 AM
>>> Cc: ospf@ietf.org
>>> 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 internet-drafts@ietf.org"
>>> <ospf-bounces@ietf.org on behalf of internet-drafts@ietf.org> 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:
>>>> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/
>>>>
>>>> There's also a htmlized version available at:
>>>> https://tools.ietf.org/html/draft-ietf-ospf-link-overload-05
>>>>
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-link-overload-05
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission until the htmlized version and diff are available at
>>>> tools.ietf.org.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> OSPF mailing list
>>>> OSPF@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> OSPF@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ospf
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> OSPF@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ospf
>>> .
>>>
>>
>> .
>>
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf