Jerry
The effect of feedback is to alleviate the race conditions
that occur within a domain wrt updating the TE database.
Crankback is the only form of information that can travel
between domains since intimate topology knowledge is not useful.
The issue is that if people implement crank back only they don't
get the benefit of feedback and therefore have only solved part
of the problem. I agree that they can be independent. I think there
is benefit to linking them. Crankback within a domain does nothing
to alleviate the race conditions each LSP must learn the same
lessons.
I guess what frustrates me about this is we specifically
saw feedback as have an advantage over crankback and having
crankback specified as an alternative to feeback means the
message didn't get through. For example out of your draft you
point out drawbacks in feedback which I disagree do not exist.
Also note that feedback does not alone imply that rerouting
can be performed. A proper notify or failure reason must also
be taken into account.
From draft-iwata-mpls-crankback-02.txt
"
2. Explicit versus implicit rerouting indications
There have been problems in service provider networks when
"inferring" from indirect information that rerouting is allowed. In
the case of using an explicit rerouting indication, rerouting is
explicitly authorized and not inferred. In the feedback case [ASHW],
or in the current error sub-codes of the Notification message [CR-
LDP], one can infer a situation where rerouting can be done, but it
also can lead to other problems, which have been experienced in
practice, as illustrated below."
This implies to me that the authors feel that feedback is somehow
inferior to crankback. No mechanism is perfect. There are always
situations where under heavy load you don't make the best route
decisions. I do however fail to see the extra information that
feedback provides within a domain as being inferior to crankback.
Don
> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALCTA [mailto:gash@att.com]
> Sent: Monday, December 17, 2001 12:17 PM
> To: Fedyk, Don [BL60:1A00:EXCH]
> Cc: Ash, Gerald R (Jerry), ALCTA; Adrian Farrel; Atsushi
> Iwata; Norihito
> Fujita; Simon Marshall-Unitt; ccamp
> Subject: RE: Intra-area Crankback
>
>
> Hi Don,
>
> don> The feedback draft is intended for this type of operation.
> don> Feedback is best within the area crank back is best outside
> don> the area. We discussed all of this with the original authors
> don> many many times.
> don> Crankback is a primitive from of feedback.
>
> I recall perhaps one or two 'hallway discussions' along this
> line. Personally I think that feedback and crankback do
> different things, one is not a replacement for the other.
> Feedback feeds information to the TED, crankback is a
> reroute-notify to the head-end or border LSR. One can
> emulate a 'crankback' with a failure-notify, just as well as
> interpreting a feedback TLV as a 'crankback'. It is not the
> same as crankback nor a replacement for it.
>
> Both can provide needed functionality.
>
> Regards,
> Jerry
>