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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 26 Sep 2015 00:34:33 +0000

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

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 28 Sep 2015 05:13:31 +0000

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]] On Behalf Of Acee Lindem (acee)
Sent: Saturday, September 26, 2015 6:05 AM
To: OSPF WG List <[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]
https://www.ietf.org/mailman/listinfo/ospf

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 28 Sep 2015 13:32:17 +0000

Hi Shraddha, 

On 9/28/15, 1:13 AM, "Shraddha Hegde" <[email-masked]> wrote:

>I believe this draft is very useful in automating the link upgrade
>process and software upgrade process in overlay deployments and
>In controller based deployments, it's useful to advertise the impending
>maintenance of the link to the controller so that controller can take
>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

I’m not sure why anyone would even consider using a mechanism other than
the metric to divert IP routed traffic. I don’t think we need to discuss
this any further as it only dilutes the discussion of the real questions.

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

Why does the controller care whether the link is out of service due to
maintenance or some other reason? In any case, the link is unavailable and
TE traffic should be diverted.

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

In a completely automated upgrade process, the controller would be
orchestrating the link maintenance and wouldn’t require the router to tell
them about it. 

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

There is no disagreement about using metric to divert traffic or why the
reverse metric must be increased as well - no more discussion is
necessary. 

>"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)
>Whereas services that have specialized requirement of providing
>non-disruptive upgrades can do so by processing the new constraint.
>

I think one point that would be good to explain is why OSPF stub router
alone isn’t enough to support link maintenance.

Thanks,
Acee

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 28 Sep 2015 23:09:03 +0000

In the discussion of this document thus far two major concerns have been expressed:

1)Advertising information which is of use only to the neighbor in an advertisement which is area scoped is wrong

2)The scope of the problem to be addressed is not yet well defined. In particular whether TE attributes also need to be modified and if so how this would relate to the link overload signaling approach.

I can believe that there is work here that is of interest to the WG and there may be a solution that is ultimately judged to be of value to deployments, but I would like to see a version of the draft that gets some greater degree of consensus before taking this on as a WG item. Right now I feel there is considerable doubt as to whether the draft is headed in the right direction.

I encourage the authors to consider the significant feedback received in Prague and reassess what problems need to be solved and how best to do so.

   Les

> Sent: Friday, September 25, 2015 5:35 PM
> To: OSPF WG List
> solve. There were differing opinions as to the exact solution but that should
> not preclude OSPF WG adoption.
>

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 29 Sep 2015 02:56:45 +0000

Resending to mailing list as I didn't see it delivered in last posting...

Rgds
Shraddha

-----Original Message-----
From: Shraddha Hegde 
Sent: Monday, September 28, 2015 10:43 AM
To: 'Acee Lindem (acee)' <[email-masked]>; OSPF WG List <[email-masked]>
Cc: Pushpasis Sarkar <[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

Acee,

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.

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.

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.

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

Rgds
Shraddha

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

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 29 Sep 2015 03:01:34 +0000

Hi Shraddha, 
This was two and there were, at least, two responses. Please refer to the
archive: https://mailarchive.ietf.org/arch/search/?email_list=ospf

Thanks,
Acee

On 9/28/15, 10:56 PM, "OSPF on behalf of Shraddha Hegde"
<[email-masked] on behalf of [email-masked]> wrote:

>Cc: Pushpasis Sarkar <[email-masked]>; Hannes Gredler
><[email-masked]>; 'Mohan Nanduri' <[email-masked]>; 'Jalil,
>Luay' <[email-masked]>
>process and software upgrade process in overlay deployments and hence
>support WG adoption as co-author.
>
>of flag Day upgrade on all nodes.
>
>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.
>
>want to look at the new constraint (link overload) May depend only on the
>metric to take specific actions.
>

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 29 Sep 2015 05:07:16 +0000

Acee,

Pls see inline...

Rgds
Shraddha

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Monday, September 28, 2015 7:02 PM
To: Shraddha Hegde <[email-masked]>; OSPF WG List <[email-masked]>
Cc: Pushpasis Sarkar <[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, 

>of flag Day upgrade on all nodes.

I’m not sure why anyone would even consider using a mechanism other than the metric to divert IP routed traffic. I don’t think we need to discuss this any further as it only dilutes the discussion of the real questions.
<Shraddha> Agree that it's sufficient to use the metric alone for ip routed traffic. The area level information flooding is needed for TE and controller based applications.
                      The LSPs are not brought down  if there is usable metric on the link. We want to keep the metric (or TE metric) usable until traffic is diverted which is the whole     purpose of the draft.
                      "Link overload" information is used as a characteristic of the link ("like color")  and flood across area. Ingress node (or controller) uses this information to re-compute
                       And move the LSP to a different path.

>XXXX means the link going for maintenance and take different actions 

Why does the controller care whether the link is out of service due to maintenance or some other reason? In any case, the link is unavailable and TE traffic should be diverted.
<Shraddha> The metric set on the link is still a usable metric (0xffff) for OSPF and (0xfffffffe) for TE metric.  The metric needs to be usable metric otherwise the whole process becomes disruptive.

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

In a completely automated upgrade process, the controller would be orchestrating the link maintenance and wouldn’t require the router to tell them about it. 
<Shraddha> My perspective is that the controller (via some mgmt. interface) configures the link to be replaced with  "overload config" and recomutation of LSPs
                     (either at ingress or at controller) is triggered
                      Via IGP/BGP-LS updates. 
                      
                     Would like to hear more from others (especially operators) on this.                   

>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 

There is no disagreement about using metric to divert traffic or why the reverse metric must be increased as well - no more discussion is necessary. 
<Shraddha>Ok good.

>want to look at the new constraint (link overload) May depend only on 
>the metric to take specific actions.
>

I think one point that would be good to explain is why OSPF stub router alone isn’t enough to support link maintenance.
<Shraddha> sure will add that.

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 29 Sep 2015 11:47:35 +0000

Hi Shraddha, 

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

><[email-masked]>; 'Mohan Nanduri' <[email-masked]>; Jalil,
>Luay <[email-masked]>
><Shraddha> Agree that it's sufficient to use the metric alone for ip
>routed traffic. The area level information flooding is needed for TE and
>controller based applications.
>                      The LSPs are not brought down  if there is usable
>metric on the link. We want to keep the metric (or TE metric) usable
>until traffic is diverted which is the whole     purpose of the draft.
>                      "Link overload" information is used as a
>characteristic of the link ("like color")  and flood across area. Ingress
>node (or controller) uses this information to re-compute
>maintenance or some other reason? In any case, the link is unavailable
>and TE traffic should be diverted.
><Shraddha> The metric set on the link is still a usable metric (0xffff)
>for OSPF and (0xfffffffe) for TE metric.  The metric needs to be usable
>metric otherwise the whole process becomes disruptive.

You still didn’t answer my question. Why would the action for TE LSPs not
always be to divert the traffic when the TE metric on one of the component
links is 0xfffffffe. You still have not convinced me that the additional
link attribute provides any value add beyond setting the metric to 0xffff
and TE Metric to 0xfffffffe.

Thanks,
Acee

>orchestrating the link maintenance and wouldn’t require the router to
>tell them about it.
><Shraddha> My perspective is that the controller (via some mgmt.
>interface) configures the link to be replaced with  "overload config" and
>recomutation of LSPs

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 29 Sep 2015 12:25:18 +0000

Hi Acee,

>and TE Metric to 0xfffffffe.

[Pushpasis] Couple of reasons why I feel Link overload is better.
1. Logically I feel flag is better than a meaning associated with a special value of a attribute which does not indicate the same exact condition. 
2. There is already a 'node-overload' mechanism for taking out a router for maintenance. And so using a ‘link-overhead’ seemed more logical approach.
3. Finally, a metric is applicable in one direction only. This means, while taking out a link for maintenance the operator needs to manually set the metric (with special value) on both sides of the link. However with this proposal operator needs to set the overload on one side of the link and the other-side of the link will automatically put the link on overload and that will take both-side transient traffic off the link.
4. Additionally, the overload attribute can help the controller distinguish between a link that has been intentionally taken out of service versus a link that whose metric has degraded due to other reasons (e.g. a link may metric may dynamically degraded due to some change in S/N ratio etc). 

Thanks
-Pushpasis

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 29 Sep 2015 12:37:14 +0000

Speaking as a WG participant:

Hi Pushpasis, 

We seem to be a having a failure to communicate.

On 9/29/15, 8:25 AM, "Pushpasis Sarkar" <[email-masked]> wrote:

>1. Logically I feel flag is better than a meaning associated with a
>special value of a attribute which does not indicate the same exact
>condition. 
>2. There is already a 'node-overload' mechanism for taking out a router
>for maintenance. And so using a ‘link-overhead’ seemed more logical
>approach.

So, to sum up #1 and #2, you feel this approach is more “logical”. This is
a subjective argument.

>3. Finally, a metric is applicable in one direction only. This means,
>while taking out a link for maintenance the operator needs to manually
>set the metric (with special value) on both sides of the link. However
>with this proposal operator needs to set the overload on one side of the
>link and the other-side of the link will automatically put the link on
>overload and that will take both-side transient traffic off the link.

The alternative is using link-local signaling to tell the neighbor that
the link is going down for maintenance. Hence, the metric and TE metric
are set in both directions. I thought we already established that there is
no debate on this issue. Hopefully, we can refrain from any more lengthy
explanations on setting the metrics or how TE works.

>4. Additionally, the overload attribute can help the controller
>distinguish between a link that has been intentionally taken out of
>service versus a link that whose metric has degraded due to other reasons
>(e.g. a link may metric may dynamically degraded due to some change in
>S/N ratio etc).

Which bring us back to my original question that is still unanswered, why
would the controller action of diverting traffic be any different for an
LSP on which one of the component links has max metric?

Thanks,
Acee

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Tue, 29 Sep 2015 05:38:49 -0700

Support

Ahmed

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 29 Sep 2015 14:23:57 +0000

Hi Acee,

>We seem to be a having a failure to communicate.
[Pushpasis] I am very sorry if I have really broken the communication channel here. But I thought we were communicating well so far :)

>So, to sum up #1 and #2, you feel this approach is more “logical”. This is
[Pushpasis] Offcourse, all the points here is my personal opinion. I don’t claim that they are anyone else’. Others may or may not agree with them.

>explanations on setting the metrics or how TE works.
[Pushpasis] But the alternative you are suggesting does not seem to be specified in any document so far. I maybe wrong, but I thought this way of signaling to the neighbor about the link is going down on this side and asking neighbor to take down at his end was being proposed for the first-time in this document. You can correct me if my knowledge / understanding is wrong, and I shall take back statement immediately.

>LSP on which one of the component links has max metric?
[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. 

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.

Thanks once again and regards.
-Pushpasis

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 29 Sep 2015 14:45:55 +0000

Hi Pushpasis, 

> On Sep 29, 2015, at 10:23 AM, Pushpasis Sarkar <[email-masked]> wrote:
> 
> Hi Acee,
> 
> 
> 

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] But the alternative you are suggesting does not seem to be specified in any document so far. I maybe wrong, but I thought this way of signaling to the neighbor about the link is going d…

The link-local signaling alternative was suggested to satisfy this use case both times this draft was presented in OSPF WG meetings. I’m glad we don’t have a competing document since that is always painful to resolve. 

> [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 administrati…

I’d like to hear from the operators (especially the authors Luay and Mohan). 

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

Thanks,
Acee

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 29 Sep 2015 14:57:22 +0000

Hi Acee,

>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. :)
>I’d like to hear from the operators (especially the authors Luay and Mohan).
[Pushpasis] Me too :)
>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…
[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

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 29 Sep 2015 16:26:42 +0000

Acee,

Pls see inline..

Rgds
Shraddha

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Tuesday, September 29, 2015 5:18 PM
To: Shraddha Hegde <[email-masked]>; OSPF WG List <[email-masked]>
Cc: Pushpasis Sarkar <[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, 

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

>>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.
>
>I’m not sure why anyone would even consider using a mechanism other 
>than the metric to divert IP routed traffic. I don’t think we need to 
>discuss this any further as it only dilutes the discussion of the real questions.
>routed traffic. The area level information flooding is needed for TE 
>and controller based applications.
>characteristic of the link ("like color")  and flood across area. 
>Ingress node (or controller) uses this information to re-compute
>> 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.
>

You still didn’t answer my question. Why would the action for TE LSPs not always be to divert the traffic when the TE metric on one of the component links is 0xfffffffe. You still have not convinced me that the additional link attribute provides any value add beyond setting the metric to 0xffff and TE Metric to 0xfffffffe.

<Shraddha> oxfffffffe is a usable metric it does not mean link is out of service.
There may be some links which have been assigned this metric which aren't really going down for maintenance. (Well , I have personally seen a deployment which used such a weird metric on the link) IMHO we should not assign any special meaning to usable metric values.

I would like to repeat myself here that we do not want to use a metric that means link is out of service (For ex;0xffffffff)
If we do so , the LSP goes down and service is affected.

Thanks,
Acee

>interface) configures the link to be replaced with  "overload config" 
>and recomutation of LSPs
>>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.
>
>There is no disagreement about using metric to divert traffic or why 
>the reverse metric must be increased as well - no more discussion is 
>necessary.
><Shraddha>Ok good.
>
>
>>
>>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.
>>

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 29 Sep 2015 17:05:38 +0000

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) <[email-masked]>
Cc: Shraddha Hegde <[email-masked]>; 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 Acee,

[Pushpasis] Me too :)

Thanks and Regards,
-Pushpasis

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 29 Sep 2015 19:59:58 +0000

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.  So it is not clear to me why you are arguing that you should not change the metric. Do you have a revision of the draft which no longer mandates changing the metric?

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?
If the former then bringing the adjacency down will suffice.
If the latter then max-metric is what you want.

Similar to Acee, I am not clear on what advantage signaling overload network wide gives you.

   Les

> From: OSPF [mailto:[email-masked]] 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)
> 
> 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
> 
> Cc: Shraddha Hegde <[email-masked]>; OSPF WG List
> <[email-masked]>; Hannes Gredler <[email-masked]>; Mohan Nanduri
> <[email-masked]>; Jalil, Luay <[email-masked]>
> >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.
> >
> >> 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: Wed, 30 Sep 2015 03:04:30 +0000

Les,

Pls see inline...

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Wednesday, September 30, 2015 1:30 AM
To: Shraddha Hegde <[email-masked]>; Pushpasis Sarkar <[email-masked]>; Acee Lindem (acee) <[email-masked]>
Cc: Hannes Gredler <[email-masked]>; OSPF WG List <[email-masked]>; Mohan Nanduri <[email-masked]>; Jalil, Luay <[email-masked]>
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

> 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".
> 
> 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.
> 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
> 
> [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. :)
> >
> >
> 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.
> >
> please let me know. And I will refrain myself from answering on this 
> thread further.
> >
> 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: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 30 Sep 2015 04:15:33 +0000

Shraddha -

> From: Shraddha Hegde [mailto:[email-masked]]
> Sent: Tuesday, September 29, 2015 8:05 PM
> To: Les Ginsberg (ginsberg); Pushpasis Sarkar; Acee Lindem (acee)
> To: Shraddha Hegde <[email-masked]>; Pushpasis Sarkar
> <[email-masked]>; Acee Lindem (acee) <[email-masked]>
> Cc: Hannes Gredler <[email-masked]>; OSPF WG List <[email-masked]>;
> Mohan Nanduri <[email-masked]>; Jalil, Luay
> <[email-masked]>
> 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.
> 
> <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.
> 
> <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
> 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.
> <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.
> 
> <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.
??

   Les

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

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 30 Sep 2015 04:57:56 +0000

Hi Les,

>[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?

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Wed, 30 Sep 2015 05:25:56 +0000

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.

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)
> >>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?
> 
> >

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 30 Sep 2015 06:42:55 +0000

Perhaps the last resort for all the nodes in the network for primary/backup path computations. 
But I see having this additional information of link undergoing maintenance @ controller can help  
operator to craft  a policy to use/not-to-use this path at all for certain LSPs.

I am fine with this addition of this information.

--
Uma C.

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Pushpasis Sarkar
Sent: Tuesday, September 29, 2015 9:58 PM
To: Les Ginsberg (ginsberg); Shraddha Hegde; 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

Hi Les,

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 30 Sep 2015 10:00:43 +0000

On 9/30/15, 12:57 AM, "Pushpasis Sarkar" <[email-masked]> wrote:

>>>cannot be
>[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?

We have this mechanism - you don’t advertise the link…

Acee

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 30 Sep 2015 10:35:20 +0000

Hi Acee,

>We have this mechanism - you don’t advertise the link…

[Pushpasis] I will then ask, what if he/she still want that link to be advertised (because we want to it to be visible) but yet not use it if it still fails some policy? 

Thanks 
-Pushpasis

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 30 Sep 2015 13:02:51 +0000

> On Sep 30, 2015, at 6:35 AM, Pushpasis Sarkar <[email-masked]> wrote:
> 
> Hi Acee,
> 
> 
> 
> 

Then don’t advertise the adjacency on the link…. You can always advertise it as a stub link. 

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 30 Sep 2015 13:20:58 +0000

>operator to craft  a policy to use/not-to-use this path at all for

Maybe you can describe this use case as I fail to see it.

Thanks,
Acee

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 30 Sep 2015 13:50:46 +0000

Hi Acee,

>Then don’t advertise the adjacency on the link…. You can always advertise it as a stub link. 
[Pushpasis] I would prefer to not do anything more here but just set the overload flag. Converting a full two-way adjacency to a stub link looks to me a little more complex for this case. I would not rule out the alternative provided by you. But to me a separate flag always looks cleaner.

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 30 Sep 2015 19:32:24 +0530

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]>
wrote:

> I believe this draft is very useful in automating the link upgrade process
> and software upgrade process in overlay deployments and
> ends of the link. This is for backwards compatibility and to avoid need of
> flag
> XXXX means the link going for maintenance and take different actions based
> on metric.
>
> grained and specific information that the link is going for maintenance so
> that the services that use the particular link find a different path
> Need for flag-day upgrade. There were suggestions at the Prague meeting to
> use lower bandwidth advertisements as well as removal of

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 30 Sep 2015 16:32:18 +0000

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]>
Cc: Acee Lindem (acee) <[email-masked]>; 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,

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

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

Cheers, Manav

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

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

_______________________________________________
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