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 protected]<mailto:[email protected]>> Date: Wednesday, September 30, 2015 at 12:32 PM To: Manav Bhatia <[email protected]<mailto:[email protected]>> Cc: Acee Lindem <[email protected]<mailto:[email protected]>>, OSPF WG List <[email protected]<mailto:[email protected]>>, Hannes Gredler <[email protected]<mailto:[email protected]>>, Luay Jalil <[email protected]<mailto:[email protected]>>, Mohan Nanduri <[email protected]<mailto:[email protected]>> 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 protected]] Sent: Wednesday, September 30, 2015 7:32 PM To: Shraddha Hegde <[email protected]<mailto:[email protected]>> Cc: Acee Lindem (acee) <[email protected]<mailto:[email protected]>>; OSPF WG List <[email protected]<mailto:[email protected]>>; Hannes Gredler <[email protected]<mailto:[email protected]>>; Jalil, Luay <[email protected]<mailto:[email protected]>>; Mohan Nanduri <[email protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>] On Behalf Of Acee Lindem (acee) Sent: Saturday, September 26, 2015 6:05 AM To: OSPF WG List <[email protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
