Re: [OSPF] draft-ietf-ospf-link-overload-06 - DR migration

[Alexander Okonnikov]

Hi Shraddha,


I thought that one of goals of the draft is to minimize manual 
intervention as a preparation for maintenance. My assumption is that 
workarounds do require some manual intervention. Are mentioned 
workarounds specific for particular implementation where BDR always 
generates Network LSA in addition to DR's Network LSA? Or is essence of 
workarounds in (manual) tuning of SPF delay timer?



Thank you.


25.04.2017 07:00, Shraddha Hegde пишет:


Yes. You are right.

This is a problem specific to BDR taking over the role of DR.

The problem you describe has been around for a while and I have seen 
people using


decent workarounds without requiring protocol changes to solve this 
problem.


Rgds

Shraddha

*From:*Alexander Okonnikov [mailto:alexander.okonni...@gmail.com]
*Sent:* Monday, April 24, 2017 3:33 PM
*To:* Shraddha Hegde <shrad...@juniper.net>; 
draft-ietf-ospf-link-overl...@ietf.org; ospf@ietf.org

*Subject:* Re: draft-ietf-ospf-link-overload-06 - DR migration

Hi Shraddha,

For planned link maintenance there still could be traffic disruption. 
Even if router with overloaded link is detached from broadcast link, 
the latter still could be used by other routers on this one. If router 
with overloaded link was DR, traffic between other routers on 
broadcast link could be disrupted. Am I correct?


24.04.2017 12:55, Shraddha Hegde пишет:

Hi Alexander,

The objective of this draft is to re-route the traffic from the
link that is expected to undergo maintenance

And the case of broadcast links  is explained in sec 5.2 which
achieves the objective.

The case you described may be relevant for unplanned link-down
events which is outside the scope of this draft.

Thanks

Shraddha

*From:*Alexander Okonnikov [mailto:alexander.okonni...@gmail.com]
*Sent:* Thursday, April 20, 2017 6:50 PM
*To:* draft-ietf-ospf-link-overl...@ietf.org
<mailto:draft-ietf-ospf-link-overl...@ietf.org>; ospf@ietf.org
<mailto:ospf@ietf.org>
*Subject:* draft-ietf-ospf-link-overload-06 - DR migration

Hi authors,

In case when the node that has the link to be overloaded is DR (for
broadcast/NBMA link case), taking this link out of service could be
disruptive. What if to modify procedure in such manner that when BDR
receives Link-Overload-sub-TLV from DR, it generates Network LSA in
advance, before taking DR role. The node with overloading link then
waits some time (for example, 3 secs) and changes its interface
priority
to 0.

Thank you.



___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] draft-ietf-ospf-link-overload-06 - DR migration

[Alexander Okonnikov]

Hi Shraddha,


For planned link maintenance there still could be traffic disruption. 
Even if router with overloaded link is detached from broadcast link, the 
latter still could be used by other routers on this one. If router with 
overloaded link was DR, traffic between other routers on broadcast link 
could be disrupted. Am I correct?



24.04.2017 12:55, Shraddha Hegde пишет:


Hi Alexander,

The objective of this draft is to re-route the traffic from the link 
that is expected to undergo maintenance


And the case of broadcast links  is explained in sec 5.2 which 
achieves the objective.


The case you described may be relevant for unplanned link-down events 
which is outside the scope of this draft.


Thanks

Shraddha

*From:*Alexander Okonnikov [mailto:alexander.okonni...@gmail.com]
*Sent:* Thursday, April 20, 2017 6:50 PM
*To:* draft-ietf-ospf-link-overl...@ietf.org; ospf@ietf.org
*Subject:* draft-ietf-ospf-link-overload-06 - DR migration

Hi authors,

In case when the node that has the link to be overloaded is DR (for
broadcast/NBMA link case), taking this link out of service could be
disruptive. What if to modify procedure in such manner that when BDR
receives Link-Overload-sub-TLV from DR, it generates Network LSA in
advance, before taking DR role. The node with overloading link then
waits some time (for example, 3 secs) and changes its interface priority
to 0.

Thank you.



___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

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

[Alexander Okonnikov]

Hi Christian,

See inline.

Thank you.

On 23 апр. 2017 г., 18:17 +0300, Christian Hopps <cho...@chopps.org>, wrote:
>
> Alexander Okonnikov <alexander.okonni...@gmail.com> writes:
>
> > Hi Christian,
> >
> > See inline.
> >
> > Thank you.
> >
> > -- Best regards, Alexander Okonnikov
> >
> > On 21 апр. 2017 г., 18:36 +0300, Christian Hopps <cho...@chopps.org>, wrote:
> >
> > Alexander Okonnikov <alexander.okonni...@gmail.com> writes:
> >
> > 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
> >
> > But you have to change the code anyway to make a new TLV work, right? So
> > what old code does isn't really relevant, unless I misunderstand things.
> >
> > Not sure that understood your point. Yes, implementation that supports this 
> > feature will trigger LSP recalculation on receiving Link-overload sub-TLV, 
> > but will not necessary do so in response to max
> > metric. Former signals that physical/logical link maintenance is planned, 
> > latter - that IGP link property is modified (may be due to planned IGP link 
> > or IGP process maintenance). Two are not always
> > correlate. Ignorance of IGP topology changes from LSP recalculation 
> > perspective could be design intent, and not unsupported feature or 
> > deficiency of particular implementation. In some implementations
> > it could be enabled/disabled by configuration knob. So, even with 
> > introducing support of link-overload implementation is not obligated to 
> > react to IGP topology changes with LSP recalculation. With 'max
> > metric only' approach it is not possible to distinguish whether link metric 
> > was increased due to link overload mode, or due to some other reason.
>
> Are these actual scenarios that really matter or would actually be used
> by an operator? Do you know of operators that wish to perform "IGP link
> maintenance" (not sure how that is different from "link maintenance") on
> a link, that doesn't involve simply removing the link from service?
Yes, I has my own experience with migrating IGP for some operator. We migrated 
from using of single IS-IS instance to multiple instances of IS-IS. As part of 
migration we was moving IGP links (not IP links themselves) from one instance 
to another ones. From IGP point of view this is losing and establishing of 
adjacencies. If other routers trigger RSVP LSP recalculation, their RSVP LSPs 
would be rerouted around maintained router. Fortunately, the implementation 
doesn't consider IGP topology changes as a trigger to make RSVP LSPs 
recalculation, and data plane worked as if there was no IGP maintaining. Notice 
that re-establishing RSVP LSPs (even with MBB procedure) has some negative 
effects, like put additional traffic load on some links (detoured traffic), 
stress CPU on routers, and out-of-ordering (new path is shorter) or delaying 
(new path is longer) packets.
>
> > 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.
> >
> > But IGP-LDP synchronization happens when a link initially comes up. Is
> > the point then of the new TLV to simply avoid this slight delay on
> > link-up in using the link for TE?
> >
> > Yes, but it is only one of cases. Enabling LDP on link or restarting LDP 
> > process, for example, are other viable triggers for 'max metric'. Also, it 
> > could be that other usage of 'max metric' will be invented in the
> > future.
>
> Max-metric is meant to signal "don't use link if at all possible" nothing
> el

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

[Alexander Okonnikov]

Hi Christian,

See inline.

Thank you.

-- Best regards, Alexander Okonnikov

On 21 апр. 2017 г., 18:36 +0300, Christian Hopps <cho...@chopps.org>, wrote:
>
> Alexander Okonnikov <alexander.okonni...@gmail.com> writes:
>
> > > 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
>
> But you have to change the code anyway to make a new TLV work, right? So
> what old code does isn't really relevant, unless I misunderstand things.
Not sure that understood your point. Yes, implementation that supports this 
feature will trigger LSP recalculation on receiving Link-overload sub-TLV, but 
will not necessary do so in response to max metric. Former signals that 
physical/logical link maintenance is planned, latter - that IGP link property 
is modified (may be due to planned IGP link or IGP process maintenance). Two 
are not always correlate. Ignorance of IGP topology changes from LSP 
recalculation perspective could be design intent, and not unsupported feature 
or deficiency of particular implementation. In some implementations it could be 
enabled/disabled by configuration knob. So, even with introducing support of 
link-overload implementation is not obligated to react to IGP topology changes 
with LSP recalculation. With 'max metric only' approach it is not possible to 
distinguish whether link metric was increased due to link overload mode, or due 
to some other reason.
>
> > 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.
>
> But IGP-LDP synchronization happens when a link initially comes up. Is
> the point then of the new TLV to simply avoid this slight delay on
> link-up in using the link for TE?
Yes, but it is only one of cases. Enabling LDP on link or restarting LDP 
process, for example, are other viable triggers for 'max metric'. Also, it 
could be that other usage of 'max metric' will be invented in the future.
>
> Thanks,
> Chris.
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

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

[Alexander Okonnikov]

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:ppse...@cisco.com]
Sent: Friday, April 21, 2017 1:38 PM
To: Shraddha Hegde ; Acee Lindem (acee) 


Cc: ospf@ietf.org
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.
 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.
  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:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
(acee)
Sent: Saturday, March 18, 2017 2:28 AM
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: 

[OSPF] draft-ietf-ospf-link-overload-06 - DR migration

[Alexander Okonnikov]

Hi authors,

In case when the node that has the link to be overloaded is DR (for
broadcast/NBMA link case), taking this link out of service could be
disruptive. What if to modify procedure in such manner that when BDR
receives Link-Overload-sub-TLV from DR, it generates Network LSA in
advance, before taking DR role. The node with overloading link then
waits some time (for example, 3 secs) and changes its interface priority
to 0.

Thank you.

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf