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

Peter Psenak <ppsenak@cisco.com> Thu, 06 July 2017 07:30 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 85E731315EE for <ospf@ietfa.amsl.com>; Thu, 6 Jul 2017 00:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.503
X-Spam-Level:
X-Spam-Status: No, score=-14.503 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 avWSZxPmZfSy for <ospf@ietfa.amsl.com>; Thu, 6 Jul 2017 00:30:18 -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 1898C12F28B for <ospf@ietf.org>; Thu, 6 Jul 2017 00:30:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5529; q=dns/txt; s=iport; t=1499326218; x=1500535818; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2JXoROEbSSwvIk8f9yHqnt6IEzh+1kvXHimNKGTxRII=; b=gG9hVCfn2qvbQUL7ZXON3Gv3PHUVPKUI6zvTs+egXgaGkhQTsR8WUMaG aBt01AsPjQrHNc7Smg/tHfVsbv1DjcgYLM5R9LVKmuzUJKUjYDtyZy3RV b4W4GOsHwgHVArN0naqxPQQqXAh/xNMjIZFg6232NrLkke0tNLLO7vXMB A=;
X-IronPort-AV: E=Sophos;i="5.40,316,1496102400"; d="scan'208";a="653061588"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2017 07:30:16 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v667UFhX026022; Thu, 6 Jul 2017 07:30:16 GMT
Message-ID: <595DE709.6020005@cisco.com>
Date: Thu, 06 Jul 2017 09:30:17 +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: "Ketan Talaulikar (ketant)" <ketant@cisco.com>, Shraddha Hegde <shraddha@juniper.net>
CC: "ospf@ietf.org" <ospf@ietf.org>
References: <149905985522.4910.13981695380634800888@ietfa.amsl.com> <BN3PR05MB27060840BF4245B58A10B613D5D60@BN3PR05MB2706.namprd05.prod.outlook.com> <f8545063f7114e76a57a7945623d404b@XCH-ALN-008.cisco.com>
In-Reply-To: <f8545063f7114e76a57a7945623d404b@XCH-ALN-008.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/a4WMjsXDcLq2u0QTu8JHcK7dYHc>
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.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: Thu, 06 Jul 2017 07:30:20 -0000

On 06/07/17 05:50 , Ketan Talaulikar (ketant) wrote:
> Hi Shraddha,
>
> Thanks for taking care of some of the comments shared previously. Please find below some more that were probably missed or not taken care of.
>
> 1) I see that the use of link-local scope RI LSA has still been retained in this version and not sure why. RI LSA is for node attributes and it's use for signalling of link is not right IMO. Why not use the link-local scope Extended Link LSA instead?

an alternative would be to always flood area scope Extended Link LSA. It 
should not harm anything and could be used by other routers in area as a 
"heads-up" that remote link is becoming overloaded.


>
> 2) Sec 5.1, why is advertising of MAX-METRIC for the link to be overloaded a SHOULD and not a MUST? Isn't this mandatory to ensure backward compatibility? What if the router on which overload is signalled does not do MAX-METRIC but the implementation on the remote side end up doing MAX-METRIC. Would it not result in asymmetric metric in a un-intended manner? Please consider changing all SHOULD here to MUST to ensure backward compatibility.
>
> 3) Sec 5.4, can you please make similar change in language related to the RFC4203 reference as you've done in other parts in this version?
>
> Also I don't agree with the rationale you've given for not using LLS for the link-local signalling. Even if the hello processing were delegated to the LC, there are already a lot of protocol events which can happen via hello packets (which includes LLS) that require signalling update to the control plane OSPF main process. An implementation aspect such as this should hardly be a good reason to not use LLS for link-local signalling such as overload.

+1 on the above.

thanks,
Peter

>
> Thanks,
> Ketan
>
> -----Original Message-----
> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Shraddha Hegde
> Sent: 03 July 2017 11:11
> To: internet-drafts@ietf.org; i-d-announce@ietf.org
> Cc: ospf@ietf.org
> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt
>
> OSPF WG,
>
> New version of the ospf-link-overload draft is posted.
> Editorial comments received so far have been addressed in this version.
>
> There was one comments to move the link-overload sub-TLV to LLS in hello messages.
> Many implementations delegate the Hello processing to linecards/different deamons
> Once adjacency is established. Hello messages are not sent to control plane
> post adjacency establishment. The link-overload information typically needs to be processed
> after adjacency establishment, it introduces unnecessary complexity in hello processing.
> We had a discussion among authors on this and feel advertising link-overload sub-TLV
> in the LSAs is the most appropriate mechanism.
>
>
>
> Rgds
> Shraddha
>
> -----Original Message-----
> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
> Sent: Monday, July 3, 2017 11:01 AM
> To: i-d-announce@ietf.org
> Cc: ospf@ietf.org
> Subject: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt
>
>
> 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-07.txt
> 	Pages           : 14
> 	Date            : 2017-07-02
>
> 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 are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ospf-link-overload-07
> https://datatracker.ietf.org/doc/html/draft-ietf-ospf-link-overload-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-link-overload-07
>
>
> 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
> .
>