for a while and I have seen
people using
decent workarounds without requiring protocol changes to solve this
problem.
Rgds
Shraddha
*From:*Alexander Okonnikov [mailto:alexander.okonni...@gmail.com]
*Sent:* Monday, April 24, 2017 3:33 PM
*To:* Shraddha Hegde <shrad...@juniper.net>;
draft-iet
the objective.
The case you described may be relevant for unplanned link-down events
which is outside the scope of this draft.
Thanks
Shraddha
*From:*Alexander Okonnikov [mailto:alexander.okonni...@gmail.com]
*Sent:* Thursday, April 20, 2017 6:50 PM
*To:* draft-ietf-ospf-link-overl...@ietf.org; ospf
Hi Christian,
See inline.
Thank you.
On 23 апр. 2017 г., 18:17 +0300, Christian Hopps <cho...@chopps.org>, wrote:
>
> Alexander Okonnikov <alexander.okonni...@gmail.com> writes:
>
> > Hi Christian,
> >
> > See inline.
> >
> > Thank you.
> &g
Hi Christian,
See inline.
Thank you.
-- Best regards, Alexander Okonnikov
On 21 апр. 2017 г., 18:36 +0300, Christian Hopps <cho...@chopps.org>, wrote:
>
> Alexander Okonnikov <alexander.okonni...@gmail.com> writes:
>
> > > no argument about the need of ar
Hi Peter,
See my comments inline.
Thanks.
21.04.2017 14:17, Peter Psenak пишет:
Hi Shraddha,
please see inline:
On 21/04/17 12:53 , Shraddha Hegde wrote:
Hi Peter,
Thanks for the detailed review. Pls see inline..
-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Hi authors,
In case when the node that has the link to be overloaded is DR (for
broadcast/NBMA link case), taking this link out of service could be
disruptive. What if to modify procedure in such manner that when BDR
receives Link-Overload-sub-TLV from DR, it generates Network LSA in
advance,
