RE: Fwd: Comments on GMPLS signalling drafts

["Fong Liaw" <fongliaw@yahoo.com>]

Lou

I was not in London, so probably just not being informed.
The proposed change does not create interoperability problem
since there is only one node that would resolves it,
but I have no problem keeping the current text either.  The problem
seems to be that the same question keeps on coming back and 
there are situations where a different resolution will result
in slightly better call setup.  A typical scenario is that
a call coming from network to user has gone a long way and
usually has priority on getting the resources. 

The question we are facing here is whether different
behavior, if does not create interoperability issue,
is allowed. From my read of the draft, it is not ...
Again, I have no problem with current text so you don't
have to convince me, I thought you agree with manoj's
comment and in that case the current text does not
reflect it.

Regards,
-Fong

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of Lou Berger
> Sent: Tuesday, December 18, 2001 3:22 PM
> To: Fong Liaw
> Cc: Berger, Lou; manoj juneja; Eric.Mannie@ebone.com;
> dimitri.papadimitriou@alcatel.be; ccamp@ops.ietf.org
> Subject: Re: Fwd: Comments on GMPLS signalling drafts
> 
> 
> Fong,
>          As you know, we've discussed this many times.  The last time it 
> was discussed in detail (London if memory serves) my memory is that we 
> decided to keep current working as is because (a) different vendor 
> approaches can lead to interoperability issues and (b) this is a common 
> tie-breaker solution.
> 
> Lou
> 
> 
> At 04:33 PM 12/14/2001, Fong Liaw wrote:
> 
> >Lou
> >
> >I am happy to see my interest protected, however
> >I think manoj is asking to insert the "optimization
> >vs. correctness" text into the draft. Right now,
> >-07 text says a node with higher node id MUST send
> >a PathErr etc. this does not allow for different
> >behavior.
> >
> >I would suggest to change the text slightly as
> >following:
> >
> >"To resolve contention, the node with the higher node
> >ID will
> >    win the contention and it MUST issue a
> >    ^^^ resolve
> >PathErr/NOTIFICATION message
> >^^^^^^^PathErr/Path/Notification
> >    with a "Routing problem/Label allocation failure"
> >indication.  "
> >                ^ for the LSP that loses in the
> >resolution.
> >
> >We can also specify the default behavior is that
> >"the LSP requested by a higher node id wins the
> >resolution."
> >
> >Regards,
> >-Fong
> >
> > > > >
> > > > >7. There is an example scenario for contention
> > > resolution in case of bi-
> > > > >directional LSPs. It should be mentioned that  :
> > > > >
> > > > >"contention resolution is an optimization, not a
> > > correctness issue ...
> > > > >and no procedure can provide optimal resolution
> > > in all cases. An
> > > > >implementor
> > > > >may do differently to provide better resolution."
> > > > >
> > > > >The above quotes are extracted from one of the
> > > mails from Fong Liaw.
> > > > >
> > > > >If this is the case then this should be mentioned
> > > in the drafts.
> > > > >
> > >
> > > Read the Acknowledgments section of the draft.  (I'm
> > > sure Fong will be
> > > happy to see you protecting her interests!)
> > >
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Check out Yahoo! Shopping and Yahoo! Auctions for all of
> >your unique holiday gifts! Buy at 
> ><http://shopping.yahoo.com>http://shopping.yahoo.com
> >or bid at <http://auctions.yahoo.com>http://auctions.yahoo.com
> 

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com