Andre, it's not that simple. You are not "using" LMP,
you are extending LMP to become a different protocol WDM-LMP.
[John
Drake]
This is simply not
true.
There is what Yakov calls LTSFGTC (Long Term Solutions For Generations To
Come) -- I believe LMP fits here and the OLI solution should not be based on
LMP.
[John
Drake]
This is just
rant
However, NTIP addresses an immediate need and does
not HAVE to be based on LMP.
[John
Drake]
Well, there is a
immediate need for a protocol that can support the OLI. However, as you
pointed out, since NTIP is slideware, it can't be an immediate solution to
that immediate need.
Bilel.
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.
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