The MPLS WG Archive

[Anna Charny <acharny@cisco.com>]

Hi Vishal,

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

At 01:33 PM 9/11/2002 -0400, Vishal Sharma wrote:
>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.

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

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

Yes, we also noticed that - will add the references

>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?

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

>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).


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.



>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?

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.


>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.

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