OSPF WG,

New version of the ospf-link-overload draft is posted.
Editorial comments received so far have been addressed in this version.

There was one comments to move the link-overload sub-TLV to LLS in hello 
messages.
Many implementations delegate the Hello processing to linecards/different 
deamons
Once adjacency is established. Hello messages are not sent to control plane
post adjacency establishment. The link-overload information typically needs to 
be processed
after adjacency establishment, it introduces unnecessary complexity in hello 
processing.
We had a discussion among authors on this and feel advertising link-overload 
sub-TLV 
in the LSAs is the most appropriate mechanism.



Rgds
Shraddha

-----Original Message-----
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: Monday, July 3, 2017 11:01 AM
To: i-d-annou...@ietf.org
Cc: ospf@ietf.org
Subject: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt


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-07.txt
        Pages           : 14
        Date            : 2017-07-02

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 are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-link-overload-07
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-link-overload-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-link-overload-07


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

Reply via email to