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 protected]] Sent: Friday, October 09, 2015 2:37 AM To: Shraddha Hegde <[email protected]>; Pushpasis Sarkar <[email protected]> Cc: OSPF WG List <[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 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 protected]> 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 > >-----Original Message----- >From: Pushpasis Sarkar >Sent: Tuesday, September 29, 2015 8:27 PM >To: Acee Lindem (acee) <[email protected]> >Cc: Shraddha Hegde <[email protected]>; OSPF WG List <[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 > >Hi Acee, > > > > >On 9/29/15, 8:15 PM, "Acee Lindem (acee)" <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/ospf
