The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Clarification on Handling a specific event in LDP
Jack> It's an implementation detail for any implementor whose LSR gives out Jack> NULL labels No, it's only an issue if the LSR gives out NULL labels on sessions which are running in ordered DoD mode. If there aren't any such LSRs, then there's no problem in practice. (Even if the are such LSRs, it's still not clear that there's much of a problem in practice.) Jack> (1) Avoid the issue -- don't send NULL labels. :-) That works, but may have some costs. Jack> (2) Leave the NULL label in place; take no action. This doesn't work, as Dan points out. Jack> (3) Withdraw the NULL label; readvertise using a non-NULL label Jack> only if the session supports Unsolicited advertisement. This isn't the case we're talking about. Jack> (4) Withdraw the NULL label; readvertise using a non-NULL label Jack> regardless of the session's advertisement setting. This will probably upset the peer. Jack> (5) Advertise using a non-NULL label, without withdrawing the Jack> NULL label. The upstream peer *might* realize what you are Jack> trying to do... This will probably upset the peer. Once you withdraw a label, you have to wait for the upstream peer to request a new label. The upstream peer could probably get away with requesting a new label immediately, not percolating the withdraw upstream unless the new request is refused. Or the upstream peer could just percolate the withdraws upstream, in which case the ingress would have to reinitiate a request. I don't really see what else could be done without causing interoperability problems.
|
|