Subject: More comments on the Backup-Computation draft

From: "Vishal Sharma" <[email-masked]>
Date: Wed, 11 Sep 2002 13:33:35 -0400

Hi Anna,

As a continuation of my previous email, here are a few more comments
on the draft. Some are editorial, some technical.

-Vishal

i) The draft mentions at various points "See Section 11". I think
what is meant is probably Section 10.

ii) References [lakshman] pp. 7 and [MPLS_DIFF] pp. 23 seem to
be missing.

iii) The definition of MP on pp. 4 says "in case of one-to-one
backup, this is where multiple detours converge." Not sure why
this has to be?

iv) In Section 6.2, when discussing the distributed computation
model, the last line on pp. 13 states "But again IGP-TE extensions
is a benefit, not a requirement for this solution to work." If IGP-TE
extensions are not used, is the assumption that the backup bandwidth
pool for all links is explicitly configured at every node?
(since an explicitly defined backup bandwidth pool is one of the
key pieces of this [distributed] model).

v) Section 7, pp. 17, para 3, mentions that "the first case [a downstream
router fails but a link does not] is typically identifiable by means of
RSVP Hellos or some fast IGP Hellos mechanism". How so? If I don't receive
Hellos, I know I cannot reach my neighbor, but cannot say anything about
whether
my neighbor or our intervening link is down. Yes?

vi) Section 12 states that the PCS being stateless is the preferred
approach.
How so?
It seems that for the centralized computation model (with zero b/w
reservations
for backup LSPs) to work, the PCS must keep state on which primary and
backup
LSPs are placed where, on how much b/w each uses, and on the residual
bandwidth
of each network link.

---

From: Anna Charny <[email-masked]>
Date: Thu, 12 Sep 2002 12:32:47 -0400

Hi Vishal,

Thanks a lot  for the comments. Please see in-line...

>what is meant is probably Section 10.

yes, you are right - thanks for noticing. Will correct

>ii) References [lakshman] pp. 7 and [MPLS_DIFF] pp. 23 seem to

Yes, we also noticed that - will add the references

>backup, this is where multiple detours converge." Not sure why

I am not sure I understand your concern?  It must be some wording issue 
here that I am missing. What would you say instead?

>key pieces of this [distributed] model).

We probably should clarify exactly what we mean here - I agree that the way 
we say may be misleading.
Let me try to explain what we really wanted to say - see if it makes sense. 
What we really meant was that there is a *limited* set of circumstances 
where the distributed model could work without IGP extensions.  For 
example, if the desire is to have strict bandwidth protection for the 
entire reservable bandwidth on a link (sort of a SONET replacement 
strategy), the max reservable bandwidth is configured to be strictly less 
than link speed on enough links, then the backup pool can be explicitly 
computed from the link speed and max reservable bandwidth.   Note that this 
does not really prevent configuring max reservable banwidth to exceed link 
capacity on *some* links. Strictly speaking you need to have non-zero 
backup pool on just enough links to be able to protect the traffic. Just 
exactly what is enough is very dependent on topology, of course.

That said, if no IGP extensions are defined for the backup pool, one is 
stuck with having some sort of network-wide policy that would allow 
deriving what the amount of backup bandwidth is that is available for the 
computation implicitly from the already available parameters.  You are 
quite right that for distributed model to support more flexible protection 
strategies, the IGP extension defining the value of the backup pool is 
necessary.

>my neighbor or our intervening link is down. Yes?

You are quite right that if you do not receive a Hello, then just by that 
fact you cannot tell whether it is a link or a node.  But the case that we 
describe above and that we believe IS identifiable, is when you know two 
things:

1) the link is UP
2) there are no Hellos

Then you do know it is the node that failed.  The case where we cannot tell 
(and that is what requires additional currently undefined mechanisms) is 
when the link is DOWN. Then of course there are no Hellos as well, and you 
cannot say whether it is the link or the node.

>LSPs are placed where, on how much b/w each uses, and on the residual

We meant to say that it is for the distributed approach that it is 
preferable to have a stateless PCS.  We should make sure it is clear from 
the text. You are quite right that in the centralized model (or at least in 
some implementations of the centralized model), the server cannot be 
stateless.  Note however that a centralized model COULD be stateless as 
well if what it is backing up is the bandwidth pools rather than the actual 
amount of used primary bandwidth.

Does this make sense?

Anna