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

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