Subject: Re: Comments on draft-ietf-rtgwg-ipfrr-spec-base-09

From: mike shand <[email-masked]>
Date: Fri, 09 Nov 2007 10:15:36 +0000

Alia,

Sorry about the delay in replying. It fell off my to do stack.

Responses in line below. I'll address your algorithm comment
responses in another email.

Mike

Alia Atlas wrote:

Hi Mike,

On 10/12/07, mike shand <[email-masked]> wrote:

I
support the progression of this document, but would like to see the

comments Stewart and I made earlier on the algorithm addressed and also

the few points below.

I addressed the comments on the algorithm in a separate email.  Here
are

responses to your points below.

In
addition, I wonder whether there should be something up front which

makes clear that this may only provide a partial solution (depending on

the topology). I know this is implicit in the body of the text, but I

think it would be useful to avoid any misunderstandings if the abstract

were a little more explicit on this point.

How about adding after "...The goal of this technology is to reduce the

micro-looping and packet loss that happens while routers converge

after a topology change due to a failure. ..."

"The extent to which this goal can be met by this specification is

dependant on the topology of the network."

Agreed.  I've added this.

Good

Mike

1.1.  Failure Scenarios

The alternate next-hop can protect against a single link
failure, a

single node failure, one or more shared risk link group
failures, or

a combination of these.

It might be better to say "failure of one or more links within a shared

risk link group".

yes - changed

good

Figure
5: Example where Continued Use of Alternate is Desirable

This is an example of a case where the new primary is not a
loop-free

alternate before the failure and therefore may have been
forwarding

traffic through S. This will occur when the path via a previously

upstream node is shorter than the the path via a loop-free
alternate

neighbor.  In these cases, it is useful to give sufficient time
to

ensure that the new primary neighbor and other nodes on the new

primary path have switched to the new route.

I wonder if it should be pointed out that while this is a good strategy

to minimize the occurrence of microloops, it does nothing to prevent
any

microloops which may occur more than one hop away.

Immediately before that figure, the draft discusses how the techniques
given

in the micro-loop prevention drafts should dictate the convergence
rules.

I've prefaced the references to those drafts with

"There are techniques available to handle the micro-forwarding loops

that can occur in a networking during convergence."

to give it a bit more context.

Yes. I think that covers it. The references talk about general loop
prevention, and it is now clear (although it already said so), that
this particular section is just talking about loops involving S.

based on the new network topology.  The use of the alternate next-

hops for packet forwarding SHOULD terminate:

a.  if the new primary next-hop was loop-free prior to the
topology

change, or

b.  if a configured hold-down, which represents a worst-case
bound on

the length of the network convergence transition, has
expired, or

c.  if notification of an unrelated topological change in the
network

is received.

We should probably add that if the primary link comes back before any
of

this has happened then you can just go back to using the primary link as

if nothing had happened. That of course pre-supposes that the failure

hadn't yet been advertised. If it HAS been advertised, then it requires

another advertisement to put it back how it was, but in any case (I

think) the old next hop can safely be used.

Once the failure has been advertised, I don't think we can just go back
to using

the old next hop.  It would depend on what else in the network has
already been

updated.  Can you explain why you don't think that additional
micro-loops might be

the result?

In the old topology P was downstream of S (obviously, since P was S's
next hop). In order to get a loop S would need to be downstream of P in
the new topology. Removing the link S-P from the topology cannot now
result in S being downstream of P.

It IS possible that, in the absence of controlled convergence, there
will be a microllop somewhere between P and D. But it is equally
possible that there will be a micro-loop on the path from S's alternate
to D.

Also, generally, there are hold-down times on links so that they can't
just bounce

back up before the link change has been advertised.  I don't think this
is a very useful

optimization and I'm a bit concerned about putting it in now without
some more thought.

In the general context of IPFRR solution with 100% protection, we have
been thinking that it may be sensible to delay the advertisment of the
change for a short time after the repair has been put in place, so that
if the link DOES come back in that time the rest of the network is not
disturbed at all. If you don't have 100% protection this may not be
such a good strategy, since those destination which are not being
protected will suffer a prolonged outage.

So in this context IF the link comes back before anything else has
happened, then just going back makes sense. But I take your point that
this is unlikely, given the hold downs and the desire to respond
reasonably quickly.

In any case, I don't feel strongly about all this, so let's just leave
it as it was.

Mike

Alia

_______________________________________________

rtgwg mailing list

[email-masked]

https://www1.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
rtgwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
rtgwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg