[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Optical Link Interface



Title: RE: Optical Link Interface

Dimitri,

Thanks for your advice. I don't know what information model you are looking at. Does it belong to LTSFGTC class?

The immediate problem is the inter-working between OXC-LS, and for that you don't need LMP. I suggest you have your model kept with other "obsolete information models"

Regards;

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: osama@nortelnetworks.com

 -----Original Message-----
From:   Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be]
Sent:   Wednesday, July 25, 2001 6:56 PM
To:     Andre Fredette
Cc:     Ould-Brahim, Hamid [CAR:1A00:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH]; Jonathan Lang; ccamp
Subject:        Re: Optical Link Interface

 << File: Card for Dimitri Papadimitriou >> Hi Andre et all,

The argument you stated in your previous e-mail is fundamental,
as explained in the document we have a protocol for the OXC-OXC
interaction so that the "logical" solution is to extend the
proposed protocol to the intra-link exchange of information
whatever kind of device it is (WDM or others).

Sorry Vijay, from this point of view it is not only a carrier
facility but also related to the consistency of the approach
proposed by your supplier. Use the same protocol for both
functions is one of the key element to achieve the expected
objective.

Consequently, the solution proposed by Osama and colleagues can
be clearly put on the shelf of the "lost protocols" because even
if fulfilling the same requirements it doesn't fit into a
consistent informational model.

Regards,
Dimitri. 

Andre Fredette wrote:
>
> At 03:40 PM 7/25/2001 -0400, Hamid Ould-Brahim wrote:
>
> > Andre,
> >
> >>
> >> Osama,
> >>
> >> [Note: I tried to trim this note down to the key arguments so that
> >> it is easier to follow.]
> >>
> >> My main argument (and I believe it is shared by the rest of the
> >> LMP-WDM co-authors) is as follows:
> >> 1. LMP exists.
> >> 2. LMP solves most of the OLI problems,
> >> 3. Therefore, let's use LMP.
> >>
> >> Osama's main argument is:
> >> 1. I don't think LMP should exist.
> >> 2. Therefore let's create a new protocol.
> >>
> >> Given that the members of the working group have decided that LMP
> >> will be developed, I don't think Osama's argument is reasonable.
> >>
> >> We went through that before and the WG has decided to make
> >> explicit the clarification that the issue is just between
> >> LMP-WDM and NTIP and not between LMP and NTIP.
> >
>
> The whole point of LMP-WDM is to use an existing protocol to solve a
> new problem rather than create a new protocol just for the sake of
> creating a new one.  If there is a technical argument against using
> LMP for this problem, let's hear it!
>
> >>
> >> Besides that I think that some of the arguments
> >> advanced are:
> >>
> >> 1. The issue is not how many protocols need to be advanced.
> >
>
> This is a significant issue.
>
> >>
> >> 2. The choice of advancing a given protocol should be
> >>    influenced by whether it is deployed or likely to be
> >>    widely deployed. And this applies even in the case
> >>    of one single protocol.
> >>
> >> 3. No matter what protocol(s) is/are selected,
> >>    it is the market who makes the final decision.
> >>
> >> Hamid.
> >>
> >> At 10:41 AM 7/25/2001 -0700, Jonathan Lang wrote:
> >>
> >> >              [Osama] what is the limitation here? Are you saying
> >> >      having a simple design is a limitation? Not everything has
> >> >      to be complex.
> >> >      [Jonathan]  Other DWDM vendors are not happy with the
> >> >      master-slave model.  Also, the claim that NTIP is simple is
> >> >      an explicit assertion and you seem to be trying to make an
> >> >      implicit assertion that LMP is complex.
> >> >
> >>
> >> On the master-slave issue.  There is clearly some information that
> >> the line system does not need.  For example, I don't expect the
> >> Link Characteristics need to be advertised from OXC to OLS.  I
> >> think this works fine within the context of LMP.
> >>
> >> You have made claims of complexity, but have never been able to
> >> back them up with fact.
> >>
> >> >      Given the CR-LDP fiasco in MPLS, it was clearly stated by
> >> >      the ADs and
> >> >      Working Group chairs in Minnesota that only one protocol
> >> >      will progress in
> >> >      the IETF.
> >> >
> >> >      [Osama] I don't understand why CR-LDP and RSVP-TE have been
> >> >      brought to this discussion. This is a completely different
> >> >      situation. LMP hasn't seen the  wide deployment that RSVP-TE
> >> >      has. The example is inadequate.
> >> >
> >> >      [Jonathan] CR-LDP and RSVP-TE were both being developed
> >> >      prior to either one of them being widely deployed.  The
> >> >      effort involved in developing 2 protocols concurrently to do
> >> >      the same thing is widely perceived as being counter
> >> >      productive.
> >> >
> >>
> >> Given the choice between specifying and implementing two protocols
> >> that do basically the same thing and one, I think the choice
> >> should be clear.
> >>
> >> Andre
> >