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

Peter Psenak <ppsenak@cisco.com> Fri, 21 April 2017 13:08 UTC

Return-Path: <ppsenak@cisco.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 8595012944C for <ospf@ietfa.amsl.com>; Fri, 21 Apr 2017 06:08:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 YkxIYqLOChxJ for <ospf@ietfa.amsl.com>; Fri, 21 Apr 2017 06:08:13 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1C31273B1 for <ospf@ietf.org>; Fri, 21 Apr 2017 06:08:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9046; q=dns/txt; s=iport; t=1492780093; x=1493989693; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=m1SLh74UtFLRArdN580aGtvSfSTdMTnlUfBGszaeC04=; b=DO2IQqtn4S+IJyFOEi6mkMCBviz5NbWEy8l7cKfccL1b/ut5m+PFIuPW XemnbRTD+FqFceW52togjPSaL+k5bn+Iz666b9JLmbIwDWFpyTeELi9eD NvA1O9Uy1dSbCVucWmOjcg5ByY3fFNpGOnQYvD8p/wZoe9pHWZz5YPVW5 4=;
X-IronPort-AV: E=Sophos;i="5.37,229,1488844800"; d="scan'208";a="651311721"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2017 13:08:11 +0000
Received: from [10.147.24.18] ([10.147.24.18]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v3LD8Aub021268; Fri, 21 Apr 2017 13:08:10 GMT
Message-ID: <58FA043A.8040402@cisco.com>
Date: Fri, 21 Apr 2017 15:08:10 +0200
From: Peter Psenak <ppsenak@cisco.com>
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: Alexander Okonnikov <alexander.okonnikov@gmail.com>, Shraddha Hegde <shraddha@juniper.net>, "Acee Lindem (acee)" <acee@cisco.com>
CC: "ospf@ietf.org" <ospf@ietf.org>
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> <0e8cb635-0d9f-f80a-5221-c1a88f24a194@gmail.com>
In-Reply-To: <0e8cb635-0d9f-f80a-5221-c1a88f24a194@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/5h8kPwwyDvIVSVQgJs5U9B1NohU>
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 13:08:16 -0000

Hi Alex,

please see inline:

On 21/04/17 14:29 , Alexander Okonnikov wrote:
> 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.

fair enough.
I would propose authors to include the above reasoning in the draft.

thanks,
Peter


>>
>>>
>>> 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
>
> .
>