Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

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 <shraddha@juniper.net> 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:ospf-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
> Sent: Saturday, March 18, 2017 2:28 AM
> Cc: ospf@ietf.org
> 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 internet-drafts@ietf.org"
> <ospf-bounces@ietf.org on behalf of internet-drafts@ietf.org> 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
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
> 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
> 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf