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

[Peter Psenak <[e-mail]>]

Hi Alex,

please see inline:

On 21/04/17 14:29 , Alexander Okonnikov wrote:
> 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.

fair enough.
I would propose authors to include the above reasoning in the draft.

thanks,
Peter


>>
>>>
>>> 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
>
> .
>