RE: Question on GMPLS contentions resolution

[Hang Liu <hliu@tellium.com>]

Guangzhi,

For this case, if Node 1 always maps the label in the RESV message and
creates RSB. LSP A will be set up. The suggested label in the PATH message
from Node 1 is only preference. LSP B will be rejected by Node 2.

Hang

-----Original Message-----
From: Guangzhi Li [mailto:gli@research.att.com]
Sent: Tuesday, August 28, 2001 9:52 AM
To: John Drake
Cc: Fong Liaw; ccamp@ops.ietf.org; mpls@UU.NET
Subject: Re: Question on GMPLS contentions resolution


John:

No. Node 1 may send out the PATH message to node 2 as the same time as node
2
sends out the RESV message to node 1. If the contention resolution is a
local
decision or policy implementation, node 1 may decide to fail LSP A since
node 1
has the higher node ID. Then both LSP A and LSP B are failed. This is not
what
we want. So, a consistent decision is required between these two nodes.

Thanks,

-- Guangzhi

John Drake wrote:

> Guangzhi,
>
> In Fong's note she indicated that the contention can be completely
resolved
> by node 2, so I'm not sure that there's an interoperability issue.  I.e.,
> node 1 is told the result of node 2's decision making process.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Guangzhi Li [mailto:gli@research.att.com]
> Sent: Monday, August 27, 2001 2:13 PM
> To: Fong Liaw
> Cc: ccamp@ops.ietf.org; mpls@UU.NET
> Subject: Re: Question on GMPLS contentions resolution
>
> Fong:
>
> Uni-directional LSP uses RESV to assign labels. IF a GMPLS network runs
both
> uni-directional and bi-directional together and uses the same port pool,
> then a PATH and a RESV may cross each other. I think that it should be
legal
> based on current GMPLS specification. IF this scenario happens, GMPLS has
to
> provide one standard way to handle this situation.
>
> Your suggestion works but it still involves the implementations of node 1
> and node 2. Both nodes should interperate the same way. That means RESV
> message always wins PATH message. No problem.
>
> I assume that the I/O ports of bi-didrectional LSP are paired together,
then
> suggested_label = upstream_label and suggested_label is hard binding. Note
> that contention happens in either this case or lack of resource. If
> suggested_label could be different upstream_label, no contention problem
at
> all.
>
> -- Guangzhi
>
> Fong Liaw wrote:
>
> > Guangzhi
> >
> > The GMPLS contention resolution applies to the scenario
> > that two Path messages cross each other.  Your example
> > have Resv and Path cross each other so the rule in the
> > contention resolution does not directly apply and is more
> > of a policy and implementation issue.
> >
> > Here is one possible solution and is within the
> > interpretation of the draft, IMHO. here it is.
> > If node 2 already sends Resv to node 1, LSP A should
> > be considered established and therefore LSP B should
> > be rejected by node 2. If node 2 hasn't sent back Resv,
> > LSP A is still in establishing mode and node 2 can resolve
> > the contention internally by rejecting LSP A or LSP B, based
> > on their setting up priority or it can change LSP A's
> > label and reprogram the cross-connect without ever noticed
> > by any external node.  In both cases, node 2 is the one
> > that resolve this contention.  Hope this helps.
> >
> > p.s. I think you meant to use LABEL_SET since
> > Suggested label is a suggestion, not a hard binding.
> >
> > Regards
> > -Fong
> >
> > >  -----Original Message-----
> > >  From: Guangzhi Li [mailto:gli@research.att.com]
> > >  Sent: Monday, August 27, 2001 6:17 AM
> > >  To: ccamp@ops.ietf.org; mpls@UU.NET
> > >  Cc: gli@research.att.com
> > >  Subject: Question on GMPLS contentions resolution
> > >
> > >
> > >  Dear GMPLS authors and all experts:
> > >
> > >  During GMPLS last call, I posted the same question on the
> > >  mailing list
> > >  without response. Please somebody spend a little time and
> > >  check with the
> > >  following example? Something seems not clear when the current GMPLS
> > >  contention resution schemes are applied on a framework with both
> > >  bi-directional and uni-directional LSPs. Your clarification
> > >  is very much
> > >  appreciated.
> > >
> > >  Sincerely,
> > >
> > >  Guangzhi
> > >
> > >  -------------------------------------------------------------
> > >  -------------------------------------
> > >
> > >  The issue arises because contention is resolved between
> > >  bi-directional
> > >  LSPs by the node with the higher node index while for uni-directional
> > >  LSPs, contention is resolved by the downstream node. Consider the
> > >  following example of two nodes with paired, bi-directional interfaces
> > >  (i.e., a transmitter/receiver pair of ports).  Node 1 with ID=100 and
> > >  node 2 with ID = 50.  Node 1 uses label 1 for the
> > >  transmitter port and
> > >  label 2 for the receiver port; node 2 uses label 4 for the
> > >  transmitter
> > >  port and label 3 for the receiver port.   We assume that a
> > >  bi-directional LSP requires a single I/O interface.
> > >
> > >  We consider two LSPs - a uni-directional LSP (LSP A) and a
> > >  bi-directional LSP (LSP B). Both LSPs are going from node 1
> > >  to node 2,
> > >  with the uni-directional LSP setup request arriving marginally before
> > >  the bi-directional LSP.  LSP A does not use a suggested
> > >  label, and thus
> > >  is assigned a label (port) by node 2.  Label 3 is assigned,
> > >  corresponding to label 1 at node 1.  At the same time, for LSP B (the
> > >  bi-directional LSP) node 1 assigns label 2, with suggested label 1.
> > >  Because node 1 has the higher node ID, node 2 will assume (due to the
> > >  contention resolution rule for bi-directional LSPs) that LSP
> > >  B wins the
> > >  contention and thus label 3 is assigned to LSP B.  Thus
> > >  label 1 at node
> > >  1 (label 3 at node 2) has been assigned to two different LSPs.  Both
> > >  LSPs have "won" the contention.
> > >
> > >