Hi Shraddha, I think this version addresses all my comments. I will do a detailed review this week and, most likely, start the WG last call. I encourage other WG members to do the same.
Thanks, Acee > On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <[email protected]> wrote: > > Hi Acee, > > New version draft-ietf-ospf-link-overload-06 is posted where the remote-ipv4 > addr is moved to a new sub-TLV. > Pls review. > > The authors of the draft believe that draft has undergone multiple > revisions/reviews and is ready for WG last call. > > Rgds > Shraddha > > > -----Original Message----- > From: OSPF [mailto:[email protected]] On Behalf Of Acee Lindem (acee) > Sent: Saturday, March 18, 2017 2:28 AM > Cc: [email protected] > Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt > > Hi Shraddha, et al, > > With respect to section 4.1, I agree that matching link endpoints in > OSPFv2 requires more information. However, this is a general problem and the > remote address should be a separate OSPFv2 Link Attribute LSA TLV rather than > overloading the link overload TLV ;^) > > Thanks, > Acee > > On 2/23/17, 11:18 AM, "OSPF on behalf of [email protected]" > <[email protected] on behalf of [email protected]> wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Open Shortest Path First IGP of the IETF. >> >> Title : OSPF Link Overload >> Authors : Shraddha Hegde >> Pushpasis Sarkar >> Hannes Gredler >> Mohan Nanduri >> Luay Jalil >> Filename : draft-ietf-ospf-link-overload-05.txt >> Pages : 13 >> Date : 2017-02-23 >> >> Abstract: >> When a link is being prepared to be taken out of service, the traffic >> needs to be diverted from both ends of the link. Increasing the >> metric to the highest metric on one side of the link is not >> sufficient to divert the traffic flowing in the other direction. >> >> It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be >> able to advertise a link being in an overload state to indicate >> impending maintenance activity on the link. This information can be >> used by the network devices to re-route the traffic effectively. >> >> This document describes the protocol extensions to disseminate link- >> overload information in OSPFv2 and OSPFv3. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-ospf-link-overload-05 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-link-overload-05 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
