Hi Shraddha,
That is correct and the proposed RI LSA extensions could be used in both
situations - just with different flooding scopes.
Thanks,
Acee
On 6/30/16, 9:27 AM, "Shraddha Hegde" wrote:
>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) ;
>draft-ietf-ospf-link-overl...@ietf.org
>Cc: OSPF WG List
>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)"
> 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