RE: Timing of the upstream data path establishment

[John Drake <jdrake@calient.net>]

Harry,

I'm sorry, but I didn't realize that the admonition about not forwarding the
Path before the reverse
path had been configured had been added to the draft.  I think it's a
mistake and should be removed.

As Adrian points out, we discussed the issue many times and decided that it
wasn't worth worrying
about, since the devices we're talking about had a configuration latency
comparable to per hop
message processing latency;  i.e., O(msecs).  Moreover, as Adrian further
points out, many people that
are aware of the admonition ignore it.

If the egress device is really worried about when it can start transmitting,
it can always request
a Resv Confirm.

Thanks,

John

-----Original Message-----
From: Harry Mantakos [mailto:harry@meretrix.com]
Sent: Wednesday, May 23, 2001 12:12 PM
To: John Drake
Cc: 'Adam Shepherd'; ccamp@ops.ietf.org; mpls@UU.NET
Subject: Re: Timing of the upstream data path establishment 


>I don't think that this is an issue.  Suggested label allows a node to
begin
>to establish the forward direction as it progresses the Path message.
Since
>it controls the labels in the reverse direction, it can also begin to
>establish the reverse direction concurrently.

As I understand it, suggested label allows a single node to do
whatever hardware preparation is required for the upstream and
downstream data flows in parallel, but this preparation is
still necessarily done at each node in the path sequentially.
If it takes 'T' time to prep hardware for a single direction at a
single node, and there are 'N' nodes, you're looking at something
on the order of TN to establish the LSP. In the absence of suggested
label, you'd be looking at something like 2TN.

The suggested "3-way handshake" allows "preparation" to be done
at all nodes in the path in parallel. The circuit establishment
time can be reduced to something on the order of T (assuming suggested
label was chosen).
-harry