Subject: Re: [CCAMP] Feedback on draft-shiomoto-ccamp-switch-programming-02

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 26 Oct 2010 15:30:34 +0100

Hi Femi,

Good questions.

> I recently read this draft and thought it was pretty
interesting.
> I like the motivation behind it and the way you try to
correlate
> what may be inferred from the different pertinent RFCs as to

> guidelines as to how LSRs should behave during the LSP set
>  up phase.
> 
> However, one of the things that struck me while reading it
> was that it'd be really useful for the draft to try to
identify
> definitively when it is safe for any LSR to forward the Path
> or Resv message before programming its cross-connect,
> exploiting pipelining to try to minimise the total time to
set
> up the LSP.  You allude to this several times in the draft
but
> wonder if it'd be worthy of more consideration in the
> draft?

You're right. It would be really nice to be able to be
definitive about this.
But I am not sure that a node can "know" much without first
probing the network (for example, with protocol extensions)
and that would (of course) defeat the point of pipelining.

There are so many variables introduced by path length and by
other nodes. It even seems unlikely that a vendor would give a
pessimistic view of how long it takes them to programme and
stabilise their cross-connects.

> Admittedly, an LSR cannot make any assumptions about how
> long any other LSR in the path takes to program the cross-
> connect or whether or not they support pipelining. However,
> I think it is always safe for an LSR  to forward the message
> provided it knows that the time it takes to program the
cross-
> connect is less than the minimum possible time it
> takes for the message to reach the end-point.  I guess
> estimating this latter time is the difficult part ;-)  The
only
> thing I thought may help is trying to use the relative
location
> of a given LSR in the path (based on info in an ERO, if
used)
> to guide?

I think the best we can do is set out some of these
considerations so that a smart implementation has a chance to
make some assumptions and choices.

The points you raise certainly give some bullets we can add to
a list, and I'll think about any others we can think of. In
fact, it is relatively easy to come up with a formula from
which is it possible to deduce worst-case scenarios.

Cheers,
Adrian