Hi Pushpasis, > On Sep 29, 2015, at 10:23 AM, Pushpasis Sarkar <[email protected]> wrote: > > Hi Acee, > > > > On 9/29/15, 6:07 PM, "Acee Lindem (acee)" <[email protected]> wrote: > >> Speaking as a WG participant: >> >> Hi Pushpasis, >> >> 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 :)
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. > >> >> On 9/29/15, 8:25 AM, "Pushpasis Sarkar" <[email protected]> wrote: >> >>> >>> On 9/29/15, 5:17 PM, "Acee Lindem (acee)" <[email protected]> wrote: >>> >> So, to sum up #1 and #2, you feel this approach is more “logical”. This is >> a subjective argument. > [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. > >> >> >> 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. > [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. 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. > >> >> >> 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? > [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). > > > 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 > > Thanks once again and regards. > -Pushpasis >> >> Thanks, >> Acee >> >>> >>> >>> Thanks >>> -Pushpasis >>> >>>> >> _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
