Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01

Shraddha Hegde <shraddha@juniper.net> Wed, 30 September 2015 03:04 UTC

Return-Path: <shraddha@juniper.net>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD7A1B5A9C for <ospf@ietfa.amsl.com>; Tue, 29 Sep 2015 20:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 nxQoCpepok-G for <ospf@ietfa.amsl.com>; Tue, 29 Sep 2015 20:04:35 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0110.outbound.protection.outlook.com [207.46.100.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6FD41B5A99 for <ospf@ietf.org>; Tue, 29 Sep 2015 20:04:34 -0700 (PDT)
Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (10.160.107.139) by BLUPR05MB1972.namprd05.prod.outlook.com (10.162.224.26) with Microsoft SMTP Server (TLS) id 15.1.280.20; Wed, 30 Sep 2015 03:04:31 +0000
Received: from BY1PR0501MB1381.namprd05.prod.outlook.com ([10.160.107.139]) by BY1PR0501MB1381.namprd05.prod.outlook.com ([10.160.107.139]) with mapi id 15.01.0280.017; Wed, 30 Sep 2015 03:04:31 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Pushpasis Sarkar <psarkar@juniper.net>, "Acee Lindem (acee)" <acee@cisco.com>
Thread-Topic: OSPF Link Overload - draft-hegde-ospf-link-overload-01
Thread-Index: AQHQ9/MdJMB0YsR7d0CkMD6XMtCYyZ5RXZAwgACngYCAAOZAsIAAjtgA///5vgCAAANVAIAAHdGAgAAGI4CAAAMzAIAAHeHwgAA2qwCAAHDQUA==
Date: Wed, 30 Sep 2015 03:04:30 +0000
Message-ID: <BY1PR0501MB13810C3D18F95BCADEE0D12BD54D0@BY1PR0501MB1381.namprd05.prod.outlook.com>
References: <D22B605B.32E55%acee@cisco.com> <BY1PR0501MB1381B0343F37E534E2CFAB8DD54F0@BY1PR0501MB1381.namprd05.prod.outlook.com> <D22EB65C.32FF9%acee@cisco.com> <BY1PR0501MB138107954EB733C69D388CC7D54E0@BY1PR0501MB1381.namprd05.prod.outlook.com> <D22FF12A.3323C%acee@cisco.com> <F41DF673-765D-44B2-9499-E47F3D2EABB7@juniper.net> <D22FFBCB.3325F%acee@cisco.com> <0E0FB058-0DC6-49BD-95BC-6E64584B1DAD@juniper.net> <C4D23725-19FA-4B30-9496-486836E001DA@cisco.com> <03C3AD8C-BA1F-4951-BE7E-367C95535484@juniper.net> <BY1PR0501MB1381D96FA2F88CF374D7E3C8D54E0@BY1PR0501MB1381.namprd05.prod.outlook.com> <ba7d718a973d4f17aa0d3392ad9d04c0@XCH-ALN-001.cisco.com>
In-Reply-To: <ba7d718a973d4f17aa0d3392ad9d04c0@XCH-ALN-001.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=shraddha@juniper.net;
x-originating-ip: [116.197.184.11]
x-microsoft-exchange-diagnostics: 1; BLUPR05MB1972; 5:yRFTor06ZcOMElcRsrpHClCA5fwAVMDuFB1UW3lbbwk4CVtBuTHxxMWERAoJLVzbNZmen8k61scWaCJu4/7wneztjethtMftHJBxVu+pfSGa6UUSSrW7CsbK6ymM4Ogn1xD3CnaiC7JmLNpG+3tSqA==; 24:C3zN/o6nAjJN3sKlIjRulfloKVSKqHL/OvldknrNZH/ayek7NFMOXl0GwmdKmQQraSPktol2baXLlg9QXFwwtK8RguemE9JNOdcUkQEXO3o=; 20:yLHMg+kAxhUk982W+dD8q4+0MkYR4TVR0Nm0O1BMxiOGawmBdG+0hk9xykcu9Byh0ArBJCsio4ikK95ewecdSA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1972;
x-microsoft-antispam-prvs: <BLUPR05MB19723D39DE11518C5FB2617CD54D0@BLUPR05MB1972.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014)(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:BLUPR05MB1972; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1972;
x-forefront-prvs: 071518EF63
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(164054003)(51694002)(24454002)(199003)(189002)(479174004)(10400500002)(54356999)(19580395003)(2900100001)(189998001)(40100003)(5001860100001)(122556002)(97736004)(92566002)(5001770100001)(5004730100002)(5001960100002)(68736005)(81156007)(62966003)(106356001)(5002640100001)(87936001)(5003600100002)(77096005)(11100500001)(93886004)(5008740100001)(106116001)(66066001)(46102003)(64706001)(50986999)(86362001)(15975445007)(33656002)(74316001)(102836002)(4001540100001)(5001830100001)(101416001)(2950100001)(5007970100001)(76176999)(230783001)(19580405001)(77156002)(76576001)(105586002)(99286002)(1941001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1972; H:BY1PR0501MB1381.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2015 03:04:30.9766 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1972
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/CWVzlCOKkvzWNL9rX8fjvtejWwI>
Cc: Hannes Gredler <hannes@gredler.at>, OSPF WG List <ospf@ietf.org>, Mohan Nanduri <mnanduri@microsoft.com>, "Jalil, Luay" <luay.jalil@verizon.com>
Subject: Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 30 Sep 2015 03:04:38 -0000

Les,

Pls see inline...

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] 
Sent: Wednesday, September 30, 2015 1:30 AM
To: Shraddha Hegde <shraddha@juniper.net>; Pushpasis Sarkar <psarkar@juniper.net>; Acee Lindem (acee) <acee@cisco.com>
Cc: Hannes Gredler <hannes@gredler.at>; OSPF WG List <ospf@ietf.org>; Mohan Nanduri <mnanduri@microsoft.com>; Jalil, Luay <luay.jalil@verizon.com>
Subject: RE: OSPF Link Overload - draft-hegde-ospf-link-overload-01

Shraddha -

The draft currently states that when overload is signaled that the neighbors on both ends of the link are supposed to advertise max-metric.  
<Shraddha.> There is no change in the draft. Both end still advertise MAX-METRIC. This metric is usable metric it does not indicate link is out of service.
        
So it is not clear to me why you are arguing that you should not change the metric. 
<Shraddha> I am sorry if any of the discussions gave you impression that metric should not be changed. Metric is increased to MAX-METRIC. This metric is usable metric.

Do you have a revision of the draft which no longer mandates changing the metric?
<Shraddha> Metric is very much changed. What I am trying to say is even if the metric is changed it's usable metric and hence does not mandate that the LSP
                      Moves away from the link.

Also, you need to more clear as regards what you are trying to achieve. Do you want the link to be completely unusable - or simply the link of last resort?
<Shraddha> It's a link of last resort. We cannot make the link completely unusable until the traffic is moved on different path.
 I thought it was clear in the draft. Will add more text to clarify this.

If the former then bringing the adjacency down will suffice.
<Shraddha>Bringing adjacency down is not an option. We don't need this draft  if adjacency can be brought down before moving services away from the link.

If the latter then max-metric is what you want.
<Shraddha>As I indicated before, max-metric can work in most common scenarios but not all. There could be cases where an alternate path cannot be found
Satisfying the constraints so LSP remains on the link undergoing maintenance since the link is still a last resort link. Having additional information that the link is overloaded
helps the controller in taking special actions like relaxing LSP constraints temporarily , setting up a new LSP and  moving traffic away from the link. Once all the services have moved away from link it can go for replacement.


Similar to Acee, I am not clear on what advantage signaling overload network wide gives you.
<Shraddha> In my personal opinion, there are use cases requiring the link-overload information to be available to the LSP ingress or controller.

                       If the WG decides, these are not valid use-cases and we do not need area wide flooding of the information, I am willing to change the draft
                        to carry the link overload TLV in hellos (LLS) or link local LSAs.

                       I would like to hear more opinions from the WG participants.

   Les

> -----Original Message-----
> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Shraddha Hegde
> Sent: Tuesday, September 29, 2015 10:06 AM
> To: Pushpasis Sarkar; Acee Lindem (acee)
> Cc: Hannes Gredler; OSPF WG List; Mohan Nanduri; Jalil, Luay
> Subject: Re: [OSPF] OSPF Link Overload - 
> draft-hegde-ospf-link-overload-01
> 
> Acee,
> 
> I am not sure if I am able to convey what I mean by the "controller use case"
> in the previous mail thread. Here is another attempt to explain the use case.
> 
> With metric change there is no guarantee that LSP will move to a 
> different path. If the current path satisfies all constraints of the 
> LSP and there is no better path Satisfying the constraints then the 
> LSP would remain up and very much on the link that is going to be 
> replaced. I mentioned in another mail thread, the high metric is Usable metric and does not mean "link down".
> 
> Link maintenance is a special scenario. The LSP MUST move out of the link.
> Controller can take special actions if it knows the link is in 
> overload state For
> Ex: Relax certain constraints of the LSP for the duration of 
> maintenance and move the LSP on a different path.
> All these activities should happen in a non- disruptive fashion for 
> the service and that’s the reason the link metric cannot be changed to 
> max-metric
> (0xffffffff)
> 
> If the "link overload" information remains at the link level, 
> controller needs to take action based on metric alone.
> It might work for most cases assuming there are better alternate paths 
> satisfying same constraints but we cannot guarantee LSPs will move 
> from the link in all cases. If we consider a case when multiple links 
> in the network go for maintenance/replacement simultaneously then 
> there is higher probability that alternate paths satisfying the 
> constraints can't be found and controller needs to perform special actions to move the LSPs around.
> 
> IMHO, "link overload" is a characteristic of the link just like color, 
> bandwidth etc and it makes sense to flood it area wide just like other 
> attributes of the link.
> 
> Rgds
> Shraddha
> 
> -----Original Message-----
> From: Pushpasis Sarkar
> Sent: Tuesday, September 29, 2015 8:27 PM
> To: Acee Lindem (acee) <acee@cisco.com>
> Cc: Shraddha Hegde <shraddha@juniper.net>; OSPF WG List 
> <ospf@ietf.org>; Hannes Gredler <hannes@gredler.at>; Mohan Nanduri 
> <mnanduri@microsoft.com>; Jalil, Luay <luay.jalil@verizon.com>
> Subject: Re: OSPF Link Overload - draft-hegde-ospf-link-overload-01
> 
> Hi Acee,
> 
> 
> 
> 
> On 9/29/15, 8:15 PM, "Acee Lindem (acee)" <acee@cisco.com> wrote:
> 
> 
> >I apologize if I offended you. I just wanted to avoid the circular 
> >discussions
> and repetition of information having no bearing on the issues raised.
> [Pushpasis] No no. You have not offended me in any ways. So we are 
> good then. I was worried that I might have offended you instead. :)
> >
> >
> >> [Pushpasis] Like mentioned already, and again in my opinion, this 
> >> will help
> the controller deal with scenarios where it needs to distinguish 
> between situations in which a link has been administratively put into ‘out-of-order’
> from situations where the link has degraded to a ‘malfunctioning’ 
> state and needs attention. Unfortunately I cannot come up with a 
> use-cases how this distinction can be used (other than diverting 
> service traffics away from the links). Perhaps some of the operators may throw more light.
> >
> >I’d like to hear from the operators (especially the authors Luay and Mohan).
> [Pushpasis] Me too :)
> >
> >
> >>
> >>
> >> Hoping I have not failed to communicate once more. If you still 
> >> feel so,
> please let me know. And I will refrain myself from answering on this 
> thread further.
> >
> >I think we are communicating now - the main question is what does 
> >this
> link-maintenance condition needs to be flooded throughout the OSPF 
> routing domain when it seems that link-local signaling would offer a 
> much more straight-forward solution. The response so far has been, 
> “For the controller use-case” without any explanation of why 
> increasing the forward and reverse metrics isn’t enough (especially 
> since you are doing this anyway for backward compatibility). Les Ginsberg raised the same point.
> [Pushpasis] I will not further exaggerate my already-expressed 
> reasoning as I do not have a definite use case in hand. Hoping some 
> operators in the working group may have more solid use-cases for this.
> 
> Thanks and Regards,
> -Pushpasis
> 
> >
> >Thanks,
> >Acee
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf