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 protected] on behalf of [email protected]> wrote: >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 protected]>; OSPF WG List <[email protected]> >Cc: Pushpasis Sarkar <[email protected]>; Hannes Gredler ><[email protected]>; 'Mohan Nanduri' <[email protected]>; 'Jalil, >Luay' <[email protected]> >Subject: RE: OSPF Link Overload - draft-hegde-ospf-link-overload-01 > >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]] On Behalf Of Acee Lindem (acee) >Sent: Saturday, September 26, 2015 6:05 AM >To: OSPF WG List <[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] >https://www.ietf.org/mailman/listinfo/ospf > >_______________________________________________ >OSPF mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
