I think there is still a few outstanding issues with the current description.
1) Ideally the status TLV should be able to be carried in both the label mapping and notification messages. IMHO there is a lot of reasons for this:
- minimal messaging during both initial provisioning (if ducks are aligned right off the bat) and during a graceful
restart
- minimal state machine changes as we are not reusing label mapping as a notification mechanism for subsequent status
changes arising after the initial label mapping.
- simpler backwards compatibility (see #2 below)
2) Setting U=0 in status TLV carried in a label mapping message sorts out backwards compatibility support issues relatively quickly. We can provision PWs even if the attachment circuit is down where status TLV is supported. If the far end does not support status TLV, then the label mapping is rejected (net effect being the same as the semantics associated with the use of label withdraw to communicate status, aka as non-supporting far end rejects the mapping, net result is the same as not having offered it).
Even if we devise a per-session capability negotiation, I'd presume we'd still want u=0 as a safety mechanism. IMHO per session capability is useful (particularly w.r.t. graceful restart) where we do not want to blow off a lot of time up front negotiating what works on an PW by PW basis.
3) We need to sort out the precedence semantics of the use of group ID along with the status of individual components. Superficially it would appear that any group status change trumps any previously communicated individual statuses (w.r.t. the same class of error).
cheers
Dave