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:[email protected]]
Sent: Friday, April 21, 2017 1:38 PM
To: Shraddha Hegde <[email protected]>; Acee Lindem (acee)
<[email protected]>
Cc: [email protected]
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:[email protected]] On Behalf Of Acee Lindem
(acee)
Sent: Saturday, March 18, 2017 2:28 AM
Cc: [email protected]
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 [email protected]"
<[email protected] on behalf of [email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
.
.
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
.
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
