Re: Suggested Label Doubt

[Eric Gray <eric.gray@sandburst.com>]

Yangguang,

    Please see comments in line.

You wrote:

> Hello All,
>
> Just want to use this thread to clarify one of my confusions of current GMPLS
> signaling - "suggested label".
>
> In my understanding, the purpose of "suggested label" is to speed up circuit
> connection procedure by letting the upstream node to specify a label rather than
> following the conventional MPLS signaling procedure that receiving the label in
> the response.
>
> My questions are:
>
> (1) From a protocol design perspective, what's the benefit to suggest something
> that could be declined?

The benefit is in optimizing the likely.  As you point out below, it is likely
that the suggestion will be accepted, therefore - for the optimization reason
that you mention above (connection speedup) - it makes sense to allow the
'suggestion'.

>
>
> (2) Label is of local significance. In optical network, labels are physically
> bound, not logically bound. This is different from conventional IP network. This
> is also why there is no difference of which node (upstream or downstream) to
> choose the label in optical network. (Normally upstream and downstream node
> share almost the same knowledge of links that connect them.)

This is a presumption, not necessarily guaranteed.

>
>
> (3) In optical transport network, a upstream node may decline a label from a
> downstream node as a downstream node may decline a "suggested label" from a
> upstream node. The rejections are of the same reasons and frequency.

True.

>
>
>     Why do we need to make the suggested label's operation so special? and not
> necessary.

As you have just described, the semantics - as they are now specified
- make use of suggested label (from upstream) and distributed label
(from downstream) equally in the form of a suggestion.  But, look at how
this true: if the upstream peer does not like a label distributed to it, it is
required to request a new one (while holding onto the current one) and
then release the one it does not want to use.  The analog behavior for
a more forceful 'suggested' label woud be for the downstream to issue
a new label and then withdraw the requested label.  This behavior is
either explicitly disallowed or very much not supported in signaling.

Therefore, I would tend to look at the current approach as making the
suggested label NOT special.

>
>
> So I propose to change the semantic of the suggested label as such: (1) The
> suggested label object/TLV is optional (2) However, if it is presented, it is
> treated as the final decision. That is if the downstream node couldn't accept
> the "suggested label", a connection rejection is responded.
>
> I am looking forward to hearing your opinions.

I disagree.  For one thing, given the current signaling specifications, what
is likely to prevent the upstream from suggesting the exact same label
again?

>
>
> Regards,
>
> Yangguang

--
Eric Gray