Eric Rosen wrote:
>
> Is this a practical problem for you, or simply a theoretical one?
>
It's an implementation detail for any implementor whose LSR gives out
NULL labels (either implicit or explicit). Specifically, what should
the behavior be when a NULL label has been sent upstream, and a "real"
(non-NULL) label becomes available from the next hop (either through
a next hop change or through receipt of a Label Mapping or an Address
message)? How is the behavior modified by the three major "knobs" of
LDP (DoD/Unsolicited, Ordered/Independent, Liberal/Conservative)?
RFC 3036 is silent on the matter, so I would assume that the behavior
is implementation-dependent, with the following possibilities (there
may be more, but these come to mind):
(1) Avoid the issue -- don't send NULL labels. :-)
(2) Leave the NULL label in place; take no action.
(3) Withdraw the NULL label; readvertise using a non-NULL label
only if the session supports Unsolicited advertisement.
(4) Withdraw the NULL label; readvertise using a non-NULL label
regardless of the session's advertisement setting.
(5) Advertise using a non-NULL label, without withdrawing the
NULL label. The upstream peer *might* realize what you are
trying to do...
It seems to me that any of these behaviors should be allowed; the
upstream peer should not interpret any of these behaviors as a
fatal error. Additionally, it seems evident that any of these
behaviors is "acceptable" -- the data flow in question should be
correctly forwarded regardless of which behavior is chosen.
Jack
|
Try Searching:
servers, voip, java, networking, microsoft ...
|
|
|
|