Re: Suggested Label Doubt

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

Yangguang,

    So, I was sure that this sort of discussion had occurred previously.  It
has.  For example, you and I had an exchange on almost the exact same subject
in March.  See "Question regarding bi-directional connection set up" and later
"Question regarding bi-directional connection set up - And Port-ID in Label
object" threads for details.  Both threads were discussed on both ccamp and
mpls mailing lists, but not all postings appear in both archives.  We SHOULD
strive to avoid repeating arguments.

    Please see responses recursively embedded below.

You wrote:

> Eric,
>
> Please see my response in line.
>
> > > 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'.
> >
>
> The key is that the likely is not likely in optical network.

By what definition of optical network?  It is certainly likely in lambda
switching.  Also, the 'G' in "GMPLS" does not stand for "optical".

>
>
> Basically, "suggested label" adds the local negotiation capability.
> (Theoretically), it's a good idea. But it's not necessary in the optical network.

Apparently, some people feel it is a good idea in practice, as  well.

This discussion has been hashed out multiple times before.

>
>
> > >
> > >
> > > (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.
> >
>
> Would you please give me an example that what I said is not true?

Okay.

Local significance - not every switch in an optical domain is necessarily
capable of performing the same kind of "optical switching".  This does not
mean that they cannot interoperate - but it does mean that they may not
interoperate in the way that you expect.  Under these circumstances, the
choice of "label" may have greater than local significance.  Moreover, you
cannot end up lambda switching two light beams of the same color into
a single piece of glass.

Upstream/Downstream indifference of choice - true in optical networks (at
least "Normally"), but not particularly relevant.  One or the other MUST
have the final say and the model to-date has been that the final word is
given by the downstream.  Given that there MAY BE a scenario in which one
or the other has less than complete knowledge, it is necessary to have a
negotiation/arbitration mechanism.

>
>
> Comparing to conventional IP MPLS, many "logical" value become "physical". This
> has many implications to GMPLS.

"All" logical values becoming physical MIGHT have implications on GMPLS.
"Many" absolutely DOES NOT have such implications, since protocols need
to support all interesting cases, not just many.

>
>
> > >
> > >
> > > (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.
> >
>
> I don't disagree with your point.
>
> Indeed, you make me believe that "suggested label" may be a good idea for
> conventional MPLS. Although it may add some complications.

Assume that it adds just a jot of complexity, and next to no benefit at all,
and it would not have been worth doing even when doing so would not also
have meant joggling specifications in mature stages.

>
>
> However, for optical network, I just don't see any application that can benefit
> from the current semantics of the "suggested label". Can you give me an example?

Examples have been given before.  I'll not repeat them.

>
>
> > >
> > >
> > > 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?
> >
>
> Then, what is likely to prevent the downstream node from distributing the exact
> same label again?

If you read the above carefully, you will note that the upstream requests
a new label while still retaining the old one.  In this case, the downstream
is required to give a different label.

>
>
> Again, because of the change of many concepts from "logical" to "physical", the
> role of upstream and downstream nodes are not different anymore in optical
> network. In this case, it's not a "suggested" label anymore. It's just a
> "distributed" label from upstream.

It sounds to me like you are making observations based on assumptions about
symmetry that are not necessarily true in all forms of "label" switching
that might be supported by GMPLS.  Is this the case?  If so, then these are
not particularly relevant observations.

>
>
> Thanks,
>
> Yangguang

To summarize, one objection raised in earlier discussions on the subject
of merging upstream label and suggested label was that one was a request
while the other was an assertion.  You would now like to address this by
making both assertions.  It seems to me that there are other objections.
It also seems to me that there is very little support to change the status
quo.

I suggest letting the issue drop.

--
Eric Gray