Yasuhiro Ohara wrote:

> Hi Manral, Erblichs, Acee:
>
> Forgive me to reply by this all-in-one message for some of previous
> e-mails.

All,

I think we're digesting too much on the issue of whether or not a
given layer 2 technology can detect a link status change or loss of
connectivity. For the sake of argument, let's say that there are cases
where the layer 2 technology/implementation either doesn't support
link flap dampening or can't reliably detect layer 3 connectivity
loss/gain.

Yasu, Manav,

Irrespective of what is configured for the hello and router dead intervals,
the current value of MinLSInterval is 5 seconds. Even if adjacent routers
can lose and form an adjacency faster than the 5 second interval, they will
not re-originate their router LSAs any faster and routes will not flap. Do you
really feel there is a strong requirement for further dampening? If so, is
this requirement from a network operator? It would seem the best tact
would be to progressively delay link up event processing and/or neighbor
adjacency formation (bad news should always be propagated quickly). Anyway,
I'm not convinced it is necessary but that's not to say you shouldn't proceed.

Thanks,
Acee

>
> First, I have some prerequisions about this discussion. I guess we all
> want to decrease Hello-Interval and Dead-Interval to make convergence
> more faster, is this right ? I don't think Hello-Interval should be 10
> seconds because that's too long. And I am so impatient that I cannot
> wait for 40 seconds for my communication being revived each time the
> network topology changes.
>
> If we keep this in mind things may be changed bellow.
>
> VishwasM> Hi Yasu,
> VishwasM>
> VishwasM> If both ends of a link do have a link damping feature what
> VishwasM> problem would it still not solve. The hellos would not be
> VishwasM> causing any flap if the lower layer itself has taken care
> VishwasM> that the flap, because it would not convey a link up event
> VishwasM> till the link showed no failure for some time(as in RPR
> VishwasM> example below).
>
> What would it be done with the Hellos going through the link which is
> down but kept from notifying the upper layer ? It is obviously not
> good for L2 switches to keep this traffic in its own buffer and
> re-send it. (I believe all of the L2 flap dampening technology won't
> do this.)
>
> So, hellos may be dropped anyway whether L2 dampening feature is on or
> not (off).
>
> VishwasM> Yes, for congestion case something may be required. We have
> VishwasM> put that down in our draft congestion-control draft.
>
> Yes, I've read the draft and it'll be very effective where hello/dead
> are 10/40s (or similar). But none of this will solve the problem
> essentially.
>
> - Throttle setup of adjacency
> I guess prioritizing the adjacencies is the most bothering thing
> for network operators. The future world enforcing this to be
> involved is not attractive ...
> - DSCP marking of hello/ack
> This is for congestion and can do nothing with link down.
> - Use other control packets than hello as detect link live-ness
> This is also mainly for congestion I guess.
> Frequency of other control packets than hello is another critical
> issue for OSPF scalability and should be decreased. But in the
> other hand (ideally) the dead interval may not be so long to
> wait these kind of "OSPF update" to occur. Hence we should think
> we can use only the hellos to detect link flaps.
>
> # By the way, though the draft inform me a lot of valuable things,
> # I could not understand one part of it. 4.1.2's end paragraph says:
> # "Maintaining sequence number counters for different packet types
> # may solve this issue" but what is the sequence number and how a
> # implementation take care the packet reordering ?
>
> erblichs> Has anyone seen or invisioned an interaction with "link flap
> erblichs> dampening" and Moy's OSPF implimentation where he attempts
> erblichs> to accelerate bi-directional status? Chapt 1, p.2 1.1.1
> erblichs> Optimizations
> erblichs>
> erblichs> Basicly, can a damped link on one side prevent this
> erblichs> acceleration to occur?
> erblichs>
> erblichs> And should this accelerated method bunch the load on a
> erblichs> router and thus counter-intuitive to congestion control?
> erblichs> Especially with a set of routers all coming up at the same
> erblichs> time and then the bunching of adjacency formations.
>
> Could you explain more detail about this ? I understood this as a
> feature to simply make the adjacency to come up faster, and nothing
> has to do with the flap dampening.
>
> acee> Normally, it is the link up event that is dampened at layer 2
> acee> and it is normally done in a such a way that the OSPF hello
> acee> packets will not be received or will be dropped at a low level.
>
> OK, so I feel I can't admit L2's link flap dampening more and more.
>
> If the link up event is dropped and does not come up during the link
> physically flaps until someone take care of the link's problem, and if
> the link is the only one to reach a place (this is usual case), the
> place will be unreach very long time. I guess it's not acceptable.
>
> Today we implicitly dampen the flaps by keeping the hello/dead
> interval long (like 10/40s). The result of this dampened link while
> flaps is *UP*, realizing "Best effort" Internet policy because some
> packet may reach still through the flapping link.
>
> Are we really change this thing ? Can someone easily drop being
> unaware of how important the link's live-ness is, even partially ?
>
> VishwasM> Hi Manav,
> VishwasM>
> VishwasM> First, some good news. ;-) I hear IEEE is working on failure
> VishwasM> notification for Ethernet.
> VishwasM>
> VishwasM> As I see link flap damping, it has nothing to do with the
> VishwasM> other end but our own interface. So when we know that we are
> VishwasM> consistently flapping, we can have some way to prevent it. I
> VishwasM> guess all that you say, does not come into the picture at
> VishwasM> all in that case.
> VishwasM>
> VishwasM> In OSPF because we have a 3-way handshake hello mechanism,
> VishwasM> the link would not come up, and be used for routing table
> VishwasM> calculation, if either end damped it.
>
> No, I don't think so.
>
> In usual case below:
>
> [sw1]-[sw2]-[sw3]
> | |
> R1 R2
>
> If L2 switch [sw2] or the link connected to it flaps, R1 and R2 would
> not be able to recognize the flaps even if there's some conversation
> about the link's (L2) information above [sw1], [sw2] and [sw3].
> There are still possibilities of dropping Hellos. If the hello/dead
> intervals are so short, the frequency of OSPF calculation will be
> MinLSInterval (5sec). The network where the route changes each 5 secs
> are not acceptable.
>
> Yes, we have one major conflict in OSPF routing:
> "Converge fast but don't let a link flap".
>
> VishwasM> We can, for precaution sake do flap damping at OSPF
> VishwasM> layer. Ways to do it could be: -
> VishwasM>
> VishwasM> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I=-3
> VishwasM>
> VishwasM> and
> VishwasM>
> VishwasM> we could actually advertize the link metric with value
> VishwasM> 0xffff for such links. So in case there is no other path to
> VishwasM> a destination the link can still be used.
>
> That's very similar to what I am looking for ;p)
>
> But how did you recognize the flap ? All I want to know is this.
> How did you distinct the flap from the link completely down, when
> dead-interval have elapsed without receiving Hello ? How immediately
> could you recover the link's availability when the link's flaps
> vanished ?
>
> It is worth writing I-D for experimental/informational use, even
> though I admit it's an implementation issue.
>
> VishwasM> We could probably have more opinions on this. Alex/John ??
>
> Really waiting for your reply.
>
> regards !
> yasu
>
>

--
Acee

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]