Subject: comments on feedback draft

From: "Zhang, Jeffrey" <[email-masked]>
Date: Wed, 10 Nov 1999 10:02:31 -0500

Continue the comments in the MPLS session on 11/10:

1. flood when reservation fails

   if a reservation fails, in addition to the feedback, the
   routing protocol better off immediately flood current resource
   information, so that all other ingress nodes know about this and
   avoid making the same mistake.

   this flood should not be considered excessive because once it's
   flooded, chances of getting more reservation failure on the node
   becomes much smaller.

2. intermediate nodes could tap into the feedback if they want,
   so that they can also use the most recent resource info in their
   calculation (for example, an intermediate node
   could also be an ingress node for some other FECs).

3. ABRs should intercept the feedback if the upstream is not in
   the same area.

Jeffrey

---

From: Joel Halpern <[email-masked]>
Date: Wed, 10 Nov 1999 16:56:48 -0500

With regard to flooding when a signaling message fails, this depends
upon a couple of issues:
1) If the base reflooding time is long, this can be useful way to speed
convergence.
2) If significant change in resource availability does NOT itself
trigger updates, then this (failure) would be a very good signal.
3) On the other hand, this (failure) can be due to a combination of
minor changes to state and just the wrong size of request.  As such, it
may be an update that does not really matter to most people.
Re-Flooding has a system wide cost.  Putting an extra TLV in an error
message that needs to be sent anyway is nearly free.  So, the cost
trade-off is not always obvious.

Yours,
Joel M. Halpern

-----Original Message-----
From: Zhang, Jeffrey [mailto:[email-masked]]
Sent: Wednesday, November 10, 1999 10:03 AM
To: [email-masked]
Subject: comments on feedback draft

Jeffrey

---

From: "Don Fedyk" <[email-masked]>
Date: Fri, 12 Nov 1999 12:20:57 -0500

Jeffrey 

I agree with Joel 

1. Our view was that flooding is controlled 
by your IGP independent of the feedback message. This can 
be time based or trigger based on some significant thresholds
but not on the simply on basis of a failed request.

2. Yes it is a local optimization to have the intermediate 
nodes skim off the feedback information. It really depends 
on your architecture. The gains are marginal though. 

3. We have not specified multidomain for the feedback. The 
feedback logically terminates on the border node for an
area. You have a choice of options for when it comes to
multidomain.

Don

> From: Joel Halpern [mailto:[email-masked]]
> Sent: Wednesday, November 10, 1999 4:57 PM
> To: [email-masked]
> Subject: RE: comments on feedback draft
> 
>