Subject: RE: More comments on the Backup-Computation draft

From: "Vishal Sharma" <[email-masked]>
Date: Thu, 3 Oct 2002 13:09:13 -0400

Hi Anna,

Sorry for the long delay in responding. I agree with most of
your thoughts below.

Please see comments in-line.

-Vishal

> -----Original Message-----
> From: Anna Charny [mailto:[email-masked]]
> Sent: Thursday, September 12, 2002 12:33 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: More comments on the Backup-Computation draft
>
>
> 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?

As I think about it, I think I understand what you were trying
to say. The thought, I think, was that if one-to-one backup
is used for several (or all) links on an LSP, it might be expected
that multiple detours would merge at a given MP.
If that is so, perhaps a clearer wording would help here.

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

Agreed!

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

Yes, for your model, that is what I thought would be necessary.
(There are other shared models, where the sharing is not necessarily
as good as what might be possible in your approach, where new IGP
extensions could be avoided, but that is the subject of another
discussion.)

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

Agreed.

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

But, even in the bandwidth pools case, would the PCS not have (or want to)
keep track of which primary LSPs can be backed on to which secondary
LSPs (to communicate this to the respective head ends), so that,
upon failure, the HE's know exactly what to backup where (that is,
which traffic to direct where), and can set up their tables accordingly.

-Vishal