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

[Alexander Okonnikov <[e-mail]>]

Hi Peter,

See my comments inline.

Thanks.

21.04.2017 14:17, Peter Psenak пишет:
> Hi Shraddha,
>
> please see inline:
>
> On 21/04/17 12:53 , Shraddha Hegde wrote:
>> Hi Peter,
>>
>> Thanks for the detailed review. Pls see inline..
>>
>> -----Original Message-----
>> From: Peter Psenak [mailto:[e-mail]]
>> Sent: Friday, April 21, 2017 1:38 PM
>> To: Shraddha Hegde <[e-mail]>; Acee Lindem (acee) 
>> <[e-mail]>
>> Cc: [e-mail]
>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>>
>> Hi Shraddha,
>>
>> please find my comments below:
>>
>> The draft defines two mechanisms:
>>
>> a) signaling the link overload to the neighbor. The purpose is to 
>> advertise the link with max-metric from both directions.
>>
>> b) flooding the Link-Overload sub-TLV inside the area. The purpose is 
>> to let "LSP ingress routers/controllers can learn of the impending 
>> maintenance activity"
>>
>> 1. Why do we need two mechanisms? Why is (b) needed, given that (a) 
>> results in link being advertised with max-metric in both directions?
>>
>> How is treatement of remote link having max-metric different to the 
>> treatment of a link that has the Link-Overload sub-TLV? I would 
>> understand the difference if you say that the link having the 
>> Link-Overload sub-TLV must not be used during SPF, but nothing like 
>> that is mentioned in the draft and I understand why.
>>
>> Is (b) needed to cover the case, where the signaling defined in (a) 
>> is not understood by the neighbor on the other side of the link? If 
>> yes, please state it in the draft.
>> <Shraddha> Metric alone cannot be used as an indication for impending 
>> maintenance activity. When other nodes like ingress/controller need 
>> to understand the impending maintenance activity, area level 
>> advertisement would be needed. Application specific to this is 
>> described in sec 7.2
>
> no argument about the need of area level flooding - Router LSA with 
> the max metric will be flooded within the area.
>
> I have read the section 7.2 several times, but I still do not 
> understand what is the purpose of the Link-Overload sub-TLV there. 
> What is the controller going to do when it receives the area scoped 
> Link-Overload sub-TLV and how it is different to the case where the 
> link is advertised in the Router LSA with max-metric in both directions?
The fact that link metric has been maximized could not be a trigger for 
LSP recalculation. Some implementations consider IGP topology change as 
a trigger for LSP recalculation, but others - don't. Also, max metric 
itself doesn't tell about exact reason for what link metric was 
increased. It could be result of IGP-LDP synchronization, for example, 
which is irrespective to TE LSPs. From the other hand, when 
head-end/controller receives explicit indication (Link-overload), it 
could interpret it safely as a trigger to reroute LSP, even if 
overloaded link is only link that satisfies constrains (from CSPF 
perspective). Otherwise, increased metric could not be enough reason to 
relax constrains for LSP.
>
>>
>> 2. For the signaling defined in (a)-  using the Router Information 
>> LSA for signaling something to the direct neighbor is a very dirty 
>> hack. As the name of the LSA says, it has been defined to signal 
>> capability of the node, which has nothing to do with what you are 
>> trying to use it for. We have to stop polluting the protocol with 
>> such hacks. RFC5613 defines a Link-Local Signaling mechanism for OSPF 
>> and that is the one we should use for siganling between neighbors.
>> <Shraddha>  LLS is a good mechanism to use for signaling link level 
>> information that are useful before the adjacency is established. 
>> Section 2 RFC 5613  states that the LLS is not expected to be used 
>> for use-cases which cause routing changes. Link-overload does result 
>> into routing changes and is best handled using link local scope LSAs.
>
> - LLS can be used to signal information prior to adjacency bringup as 
> well as when the adjacency is FULL state. There are existing LLS TLVs 
> that are send when adjacency is in FULL state.
>
> - in your case the use of LLS would be to change the metric on the 
> link in the reverse direction. That is not resulting in any routing 
> changes directly (look at it as the remote configuration request). 
> It's the max-metric in the Router LSA that is going to change the 
> routing. So using LLS to signal what you need is perfectly valid.
>
> I just can not see how we can standardize the use of RI LSA for what 
> you are proposing to use it - it's completely wrong IMHO.
>
> thanks,
> Peter
>
>>
>> thanks,
>> Peter
>>
>>
>>
>> On 19/04/17 15:08 , Shraddha Hegde 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:[e-mail]] On Behalf Of Acee Lindem
>>> (acee)
>>> Sent: Saturday, March 18, 2017 2:28 AM
>>> Cc: [e-mail]
>>> 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 [e-mail]"
>>> <[e-mail] on behalf of [e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ospf
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ospf
>>> .
>>>
>>
>> .
>>
>
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf