logo       
Google Custom Search
    AddThis Social Bookmark Button

Re: Clarification on Handling a specific event in LDP: msg#00065

Subject: Re: Clarification on Handling a specific event in LDP
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 ...
<Prev in Thread] Current Thread [Next in Thread>