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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 5 Oct 2015 13:44:34 +0000

Hi Shraddha,

I think the draft should explain why the existing stub-router support will not suffice or this will be a continuing source of confusion. Off the top of my head:

Since the metric is only being set to the maximum for the link in maintenance mode, the reverse metric needs to be set to maximum as well. Otherwise, incoming traffic will continue to use the link in maintenance mode for transit traffic destined for on links on the OSPF router that are still fully active and supporting transit traffic. In comparison, the stub router [RFCxxxx] will set the metric to max-metric for all the links and will discourage transit traffic for the OSPF router.

Thanks,
Acee

From: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 30, 2015 at 12:32 PM
To: Manav Bhatia <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem <[email-masked]<mailto:[email-masked]>>, OSPF WG List <[email-masked]<mailto:[email-masked]>>, Hannes Gredler <[email-masked]<mailto:[email-masked]>>, Luay Jalil <[email-masked]<mailto:[email-masked]>>, Mohan Nanduri <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01

Manav,

The draft is about a link going for maintenance and not about the node going for maintenance.
The draft talks about sending a “link overload” TLV associated with the link and the other end of the link
Setting metric to high value so that reverse traffic is also diverted away from the link.

Rgds
Shraddha

From: Manav Bhatia [mailto:[email-masked]]
Sent: Wednesday, September 30, 2015 7:32 PM
To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; OSPF WG List <[email-masked]<mailto:[email-masked]>>; Hannes Gredler <[email-masked]<mailto:[email-masked]>>; Jalil, Luay <[email-masked]<mailto:[email-masked]>>; Mohan Nanduri <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01

Hi,

I am probably joining the party quite late, so apologies in advance if the following has already been discussed and discarded.

Why cant the following be done:

Set the metric of all transit links/connections on an “overloaded” router to 0xffff in its Router LSAs. This will result this router to not be included as a transit node in its neighbors SPF tree.  Stub links can still be advertised with their normal metrics so that they are reachable even when a router is “overloaded”.

This way you can mimic IS-IS OL bit.

Cheers, Manav

On Mon, Sep 28, 2015 at 10:43 AM, Shraddha Hegde <[email-masked]<mailto:[email-masked]>> wrote:
Acee,

Thanks for picking up the draft for adoption.

I believe this draft is very useful in automating the link upgrade process and software upgrade process in overlay deployments and
hence support WG adoption as co-author.

I would like to  take this opportunity to discuss  few of the points raised during Prague meeting.

1. Whether to keep the "Link overload" advertisement at area level or at link level.

In controller based deployments, it's useful to advertise the impending maintenance of the link to the controller so that controller can take
Special actions based on the information. The use case is described in sec 5.2 in  the draft.
The draft advocates increasing the metric to usable high metric on both ends of the link. This is for backwards compatibility and to avoid need of flag
Day upgrade on all nodes.

 Controller cannot assign special meaning to the metric  for ex: Metric XXXX means the link going for maintenance and take different actions based on metric.

For a completely automated upgrade process, controller would need a fine grained and specific information that the link is going for maintenance so that the services that use the particular link find a different path forcefully while keeping the entire process non-disruptive.

2. Use of high metric  on either side of the link  to divert the traffic.

As I already mentioned before, draft advocates raising the reverse metric to a high metric  but that is for backwards compatibility and to avoid
Need for flag-day upgrade. There were suggestions at the Prague meeting to use lower bandwidth advertisements as well as removal of
Link characteristics to force the services on different path. These mechanisms would be disruptive and defeats the purpose of the draft.

3.  Backward compatibility

"Link-overload"  is a new information attached to a link and is very similar to a new constraint being added to the link.
This information is non-invasive in the sense that services that do not want to look at the new constraint (link overload)
May depend only on the metric to take specific actions.

Whereas services that have specialized requirement of providing non-disruptive upgrades can do so by processing the new constraint.

Section 4 in the draft talks about backwards compatibility.
I'll add more clarifications in the coming days.

Rgds
Shraddha

-----Original Message-----
From: OSPF [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Acee Lindem (acee)
Sent: Saturday, September 26, 2015 6:05 AM
To: OSPF WG List <[email-masked]<mailto:[email-masked]>>
Subject: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01

In Prague, there was consensus in the room that this use case was not covered by existing mechanisms and that it was a problem the WG should solve. There were differing opinions as to the exact solution but that should not preclude OSPF WG adoption.

Please indicate your support (or concerns) for adopting this as a WG Document.

Thanks,
Acee

_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf

_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 5 Oct 2015 13:48:11 +0000

Anil, 

On 9/30/15, 1:25 AM, "Anil Kumar S N (VRP Network BL)"
<[email-masked]> wrote:

>Hi All,
>
>In support of the draft : draft-hegde-ospf-link-overload-01
>Draft makes sense in below scenario I suppose, I could be wrong.
>
>Case where Router detectes some fault in link, would like to advertize
>link as unusable for a while.
>
>If any router using TI-LFA for FRR might be using this link for stiching
>P & Q-nodes. 
>Link Overload sub TLV might help LFA clacualting node to use some other
>link for that period of time.

It is already advertised at max-metric, for LFA/RLFA my implementation
(Ericsson) avoided using max-metric links…

Acee 

>
>Possibly router under maintainence could be refresh router LSA with out
>this link, Backward link check fails
>and link under maintaince will not be used. I think this would be treated
>as topology change which is not the case.
>
>I feel Overloading Node and Link are done for short period of time and
>might come handy while debugging/isolating network issues.
>
>Thanks & Regards
>Anil S N
>
>"Be liberal in what you accept, and conservative in what you send" - Jon
>Postel
>
>
>
>> From: OSPF [mailto:[email-masked]] On Behalf Of Pushpasis Sarkar
>> Sent: 30 September 2015 10:28
>> To: Les Ginsberg (ginsberg); Shraddha Hegde; Acee Lindem (acee)
>> Cc: Hannes Gredler; OSPF WG List; Mohan Nanduri; Jalil, Luay
>> Hi Les,
>> On 9/30/15, 9:45 AM, "Les Ginsberg (ginsberg)" <[email-masked]>
>> wrote:
>> 
>> >><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.
>> >
>> >[Les:] Which seems to me to be exactly the definition of link of last
>> resort i.e. in the absence of any other alternative use the link
>> undergoing maintenance.
>> >??
>> [Pushpasis] What if the operator does not want any traffic on those
>> links at all? Should not there be a way to ensure that as well?
>> 
>> >
>> [email-masked]

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Mon, 5 Oct 2015 14:17:25 +0000

Acee, 

	In My implementation, I sort all the connecting link paths. 
	I choose best link cost available, if not then I will use last resort max cost Link path.

	Anyways this draft is complimenting your case :) 

	A---B
	Lets say A is a P node and B is a Q node where B is under maintaince, makes B to a Link as Max Metric.
	Now you will still be using link A--B as A to B link cost is not updated. 

	This draft insists A to update its cost to Max metric, Which will force you to choose different link.

Thanks & Regards
Anil S N

“Be liberal in what you accept, and conservative in what you send” - Jon Postel

> From: Acee Lindem (acee) [mailto:[email-masked]]
> Sent: 05 October 2015 19:18
> To: Anil Kumar S N (VRP Network BL); Pushpasis Sarkar; Les Ginsberg
> (ginsberg); Shraddha Hegde
> Subject: Re: OSPF Link Overload - draft-hegde-ospf-link-overload-01
> 
> Anil,
> 
> >In support of the draft : draft-hegde-ospf-link-overload-01 Draft
> makes
> >sense in below scenario I suppose, I could be wrong.
> >
> >If any router using TI-LFA for FRR might be using this link for
> >stiching P & Q-nodes.
> >this link, Backward link check fails and link under maintaince will
> not
> >be used. I think this would be treated as topology change which is not
> >the case.
> >
> >"Be liberal in what you accept, and conservative in what you send" -
> >Jon Postel
> >
> >
> >
> >> >>cannot be found Satisfying the constraints so LSP remains on the
> >> >>link undergoing maintenance since the link is still a last resort
> link.
> >> >

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 5 Oct 2015 14:29:46 +0000

Acee,

I am in the process of revising the draft. Will include details you mentioned.

Rgds
Shraddha

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Monday, October 05, 2015 7:15 PM
To: Shraddha Hegde <[email-masked]>; Manav Bhatia <[email-masked]>
Cc: OSPF WG List <[email-masked]>; Hannes Gredler <[email-masked]>; Jalil, Luay <[email-masked]>; Mohan Nanduri <[email-masked]>
Subject: Re: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01

Hi Shraddha,

Thanks,
Acee

Manav,

Rgds
Shraddha

Hi,

Cheers, Manav

Rgds
Shraddha

-----Original Message-----
From: OSPF [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Acee Lindem (acee)
Sent: Saturday, September 26, 2015 6:05 AM
To: OSPF WG List <[email-masked]<mailto:[email-masked]>>
Subject: [OSPF] OSPF Link Overload - draft-hegde-ospf-link-overload-01

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 5 Oct 2015 16:03:08 +0000

>you to choose different link.

Right - max-metric in both directions is enough for all flavors of LFA. I
was referring to the necessity of the OSPFv2 link attribute for the the
LFA use-cast. 

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 8 Oct 2015 21:07:09 +0000

Hi Shraddha, 
If this is truly TE, why would you use the OSPF prefix/link attribute
instead of the actual TE metric specified in RFC 3630?
Thanks,
Acee 

On 9/29/15, 1:05 PM, "Shraddha Hegde" <[email-masked]> wrote:

>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
>
>From: Pushpasis Sarkar
>Sent: Tuesday, September 29, 2015 8:27 PM
>To: Acee Lindem (acee) <[email-masked]>
>Cc: Shraddha Hegde <[email-masked]>; OSPF WG List <[email-masked]>;
>Hannes Gredler <[email-masked]>; Mohan Nanduri
><[email-masked]>; Jalil, Luay <[email-masked]>
>Hi Acee,
>On 9/29/15, 8:15 PM, "Acee Lindem (acee)" <[email-masked]> 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

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 9 Oct 2015 03:55:53 +0000

Acee,

The Link overload sub TLV would go in extended link TLV since the use case is applicable to TE as well as non- TE deployments.
The metric change on the reverse side applies to TE TLV as well as  ROUTER LSA.
 IGP metric set to 0xffff and TE metric set to oxfffffffe.
This wasn't very clear in the -01 version of the draft. Will submit the -02 version very soon.

Rgds
Shraddha

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Friday, October 09, 2015 2:37 AM
To: Shraddha Hegde <[email-masked]>; Pushpasis Sarkar <[email-masked]>
Cc: OSPF WG List <[email-masked]>; Hannes Gredler <[email-masked]>; Mohan Nanduri <[email-masked]>; Jalil, Luay <[email-masked]>
Subject: Re: OSPF Link Overload - draft-hegde-ospf-link-overload-01

Hi Shraddha,
If this is truly TE, why would you use the OSPF prefix/link attribute instead of the actual TE metric specified in RFC 3630?
Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 9 Oct 2015 11:23:47 +0000

Hi Shraddha, 

On 10/8/15, 11:55 PM, "Shraddha Hegde" <[email-masked]> wrote:

>Acee,
>
>The Link overload sub TLV would go in extended link TLV since the use
>case is applicable to TE as well as non- TE deployments.

Please resubmit as a WG document (draft-ietf-ospf-link-overload-00.txt) -
there has been a lot of interest in this function and the details.

Thanks,
Acee

>Cc: OSPF WG List <[email-masked]>; Hannes Gredler <[email-masked]>;
>Mohan Nanduri <[email-masked]>; Jalil, Luay
><[email-masked]>