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

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

Alia,

The added classification of alternates looks fine, except I am
completely confused about your statement about NP. See inline.

Mike

Alia Atlas wrote:

Dear Rüdiger,

On 10/12/07, Rüdiger A Martin <[email-masked]>
wrote:

Dear
Alia, dear Alex,

we have taken a look at your document and would like to add a few

comments to the discussion already going on:

- The concept of node protecting LFAs is first mentioned on page 6. The

definition and explanation follows later.

True - The first place a node protecting LFA is mentioned, I've added a
reference to the section with the definition.

I don't see a clean way of defining it at/before that location.

-
There are several kinds of loop-free alternates. But the suggested

order of preference among those different LFAs does not become clear at

all in the draft. So there should be some paragraph where all possible

candidate types are listed and described with their pros and cons. That

description should include the protected failure types but also the

behavior in case of unprotected failures: e.g., I miss a clear statement

that downstream LFAs do not create any loops no matter what kind of

failures may happen. Based on this, a clear suggestion for an order of

preference can be given.

Yes, we didn't have consensus about the order of preferences - and it
depends

on what other types of protection are available in the network.  I
agree that this

would be useful.  How does the following added section (after 3.6)
sound?

"3.7.  LFA types and Trade-offs

LFAs can provide different amounts of protection and the decision

about which type to prefer is dependent upon network topology and

other techniques in use in the network.  This section describes the

different protection levels and the trade-offs associated with each.

1.  Primary Next-hop: When there are equal-cost primary next-hops,

using one as an alternate is guaranteed to not cause micro-loops

involving S. Traffic flows across the paths that the network will

converge to, but congestion may be experienced on the primary

paths since traffic is sent across fewer.  All primary next-hops

are downstream paths.

2.  Downstream Paths: A downstream path, unlike an LFA, is guaranteed

not to cause a micro-loop involving S regardless of the actual

failure detected.  However, the expected coverage of such

alternates in a network is expected to be poor.  All downstream

paths are LFAs.

3.  LFA: An LFA can have good coverage of a network, depending on

topology.  However, it is possible to get micro-loops involving S

if a more severe failure occurs than is protected against.

The different types of protection are abbreviated as LP (link-

protecting), NP (node-protecting) and SP (SRLG-protecting).

a.  LP, NP, and SP: If such an alternate exists, it gives protection

against all failures.

b.  LP and NP: Many networks may handle SRLG failures via another

method or may focus on node and link failures as being more

common.

c.  LP: A network may handle node failures via a high availability

technique and be concerned primarily about protecting the more

common link failure case.

d.  NP: These only exist on interfaces that aren't point-to-point.

If link protection is handled in a different layer, then an NP

alternate may be acceptable.

I'm completely confused by this last statement. Surely it is possible
to have a node protecting LFA on a pt-pt interface?

"

I'd welcome suggestions on how to improve this.

-
Page 7: "Since the funcionality of link and node protecting LFAs is

greater than that of downstream paths, a router SHOULD select a link and

node protecting LFA over a downstream path." - That reads like

downstream paths are generally worse. But of course a downstream link-

and node-protecting LFA is better than a non-downstream link- and

node-protecting LFA. So this point is strongly related to the point

mentioned earlier concerning the order of preference.

Added the clarification of "link-protecting downstream paths".

This is related to the observation (which we already have in section
1.1 "There are topologies where there may be either a node portecting
LFA, a downstream path, both or neither") i.e. node protecting LFAs and
link protecting downstream paths are not strict sub-sets.

-
A few comments on the algorithm on page 16 (besides I agree with

Stewarts comments):

* Step 10: This means, if the router prefers other primary next

hops, it prefers them no matter what kind of failures (links or nodes)

they protect. So this algorithm prefers a link-protecting primary over a

link- and node-protecting downstream LFA. (Depending on the order of the

candidates - see below.)

True -  this is intended to reflect the behavior for the network once
it has converged.

I could instead embed the preference at Step 16 - but that flexibility
is there already.

* The output of the algorithm depends on the order of the

candidate next hops.

1) Imagine that H_1 is a link-protecting primary next hop.

H_2 is a link- and node-protecting downstream LFA. Then H_1 will be

selected in the first iteration. During the second iteration, step 11

selects H2 instead.

2) Now imagine H_1' = H_2 and H_2' = H_1. Then the first

iteration selects H_1'. However, the second iteration selects H_2' as

the candidate in step 10. So the final result is H1.

I think this problem is due to the missing order of
preference.

Ah - nope - it is due to a missing step - added between step 10 &
11.

"If cand_type is not PRIMARY, P_i.alt_type is PRIMARY and the router
prefers other primary next-

hops for use as the alternate, then continue to the next
candidate next-hop"

Besides
we really appreciate this document and support the progression

of the document after consideration of the comments from above. We think

that Mike's idea to include explicitly that this may only provide a

partial solution is worth considering. But maybe together with the

statement that this is a really simple and easy to implement approach

since it does not require any support (i.e. signalling) from other
routers.

Ok - so at the end of the abstract, I've added

"This simple approach does not require any support from other routers.
The

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

dependent on the topology of the network."

Yes. That is a good point to make.

Thanks for the comments and suggestions!

Alia

Best
regards,

Rüdiger

--

_______________________________________________________

Dipl.-Inform. Rüdiger Martin

Department of Distributed Systems (Informatik III)

Insitute of Computer Science, University of Würzburg

Am Hubland, 97074 Würzburg, Germany

[email-masked]

Tel: +49 931 888-6651

Fax: +49 931 888-6632

_______________________________________________

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

---

From: "Alia Atlas" <[email-masked]>
Date: Mon, 12 Nov 2007 10:35:00 +0100

On Nov 9, 2007 12:01 PM, mike shand <[email-masked]> wrote:

> On 10/12/07, Rüdiger A Martin <[email-masked]> wrote:
> >
> > Dear Alia, dear Alex,
> >
> > - There are several kinds of loop-free alternates. But the suggested
> on what other types of protection are available in the network.  I agree
> that this
> would be useful.  How does the following added section (after 3.6) sound?
>
> I'm completely confused by this last statement. Surely it is possible to
> have a node protecting LFA on a pt-pt interface?
>

Yes - but I have already categorized that case as an alternate that is LP
and NP.    This is discussing alternates that are
only NP.  I'll make it clearer.

Thanks,
Alia

---

From: mike shand <[email-masked]>
Date: Mon, 12 Nov 2007 09:42:26 +0000

Ah yes, of course. Perhaps "NP only" would be sufficient clarification.

Mike

Alia Atlas wrote:

On Nov 9, 2007 12:01 PM, mike shand <[email-masked]>
wrote:

Alia,

Mike

Alia Atlas wrote:

Dear Rüdiger,

On 10/12/07, Rüdiger A Martin <[email-masked]
wrote:

Dear
Alia, dear Alex,

-

preference can be given.

are downstream paths.

paths are LFAs.

against all failures.

common.

Yes - but I have already categorized that case as an alternate that is
LP and NP.    This is discussing alternates that are

Thanks,

Alia