Acee, If I understood your comment correctly, you are proposing that there are usecases for "link overload" feature Where only link local information flooding would suffice so that alternate should be provided in the document. I agree with you, will update the document and resubmit soon.
Rgds Shraddha -----Original Message----- From: Acee Lindem (acee) [mailto:a...@cisco.com] Sent: Monday, June 27, 2016 7:32 PM To: Acee Lindem (acee) <a...@cisco.com>; draft-ietf-ospf-link-overl...@ietf.org Cc: OSPF WG List <ospf@ietf.org> Subject: Re: [OSPF] "OSPF Link Overhead" - draft-ietf-ospf-link-overload-01 Speaking as WG co-chair: I think we can move towards WG last call with this addition. Note that the document needs to be refreshed as it will expire soon. Thanks, Acee On 6/27/16, 10:00 AM, "OSPF on behalf of Acee Lindem (acee)" <ospf-boun...@ietf.org on behalf of a...@cisco.com> wrote: >Speaking as WG member: > >One area of mild contention with this draft has been whether the >advertisement that the link is being taken out of service needs to be >advertised beyond the link endpoint router (which will take the >appropriate action of advertising the maximum link metric in the >reverse direction). We have gotten somewhat entangled into use case >discussions and whether or not this is really necessary. > >What I’d like to propose is that offer the alternative of advertising >the OSPF RI LSA with link-scope (fully supported by RFC 7770). This >way, the advertisement could be restricted to the local link in >situations where the knowledge doesn’t really need to go anywhere else. >Note that the current text doesn’t prevent this so this is merely a >matter of describing the use case. > >Thanks, >Acee > >_______________________________________________ >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
