Hi
Fong,
Control channel management is a basic requirement
for any OLI implementation and all proposals on the table have it. Likewise
NTIP and WDM-LMP both have mentioned link verification from the very
beginning. So there is really no differentiation between the
protocol-requirements in that regard.
[Fong] But LMP
(which LMP-WDM uses the link-verification procedure) is out for a long-long
time. NTIP is quite recent. We all have protocols that works in
our lab/product and did not bother to bring them out. LMP does have
first-mover advantage here.
[Sahay,
Vasant] I agree with the fact that LMP is out there for a long time.
However IETF should not pick a solution based only on being a
first-mover. As we have said before LMP has a much wider scope than OLI and
it is not completely defined either. Hence using LMP for OLI has
time-to-market and design issues. NTIP on the other hand is a specifc
solution, focused on OXC-to-OLS
interface.
Your suggestions to enhance LinkSummary message and
to create a new data-link-sub-TLV actually support my point of "on the
fly design" of WDM-LMP. Please see my comments below.
[Fong] I would
ask why would we make a protocol extensible if we do not plan to extend it
to do other functions. The fact that we can simply add a sub-TLV to
accomplish new functionality says that if I implement LMP, I have better
chance of re-using my implementation. Also, if after I implement NTIP, do I
still need to implement LMP so that an OLS can also work with a router that
is not a master controller ? Or would you propose we extend NTIP to do that
function as well ? If so, using your way of argument, I can claim that NTIP
is not complete in this aspect either.
[Sahay, Vasant] Two points
here:
#1) protocol extension is a good thing. We should
use it for unforeseen extensions in future/ for supporting proprietary
extensions etc.
However we have two competing proposals here. One
(NTIP) already has considered and incorporated the features specific to OLI.
Other (WDM-LMP) has not considered them and you are proposing to
enhance WDM-LMP to add these extensions. I will save extensions for
future use.
#2) You are arguing that you will end up
implementing LMP for OXC-to-OXC and NTIP for OXC-WDM so why not reduce the
number of acronyms by basing OLI on LMP ? We have gone in loops on this
argument for several months
now.
[Fong] From my read
to LMP/LMP-WDM, LMP has also thought through the control/data channel
degradation issues and its implications to SLA. NTIP has no mention of it.
Simply said that NTIP does not address configuration issues and therefore do
not requirement persistent store does not really simplify my
implementation/system. I have no doubt that NTIP brought its own
contribution, but if NTIP wants to present itself as a superior/complete
protocol, I am afraid you would not get strong support in that.
[Sahay, Vasant] Thanks for
appreciating NTIP's contribution. If you look at the OLI requirements you
will find more of it. We have no intentions of touting any superiority. We
are only requesting that our proposal be treated fairly. It is in the
best interest of the industry to go through the comparison to see what suits
them, as oppsoed to picking something just because it is a first
mover.
We can continue the comparison game
forever, but it will do no good to the industry. IMHO, the best way forward
is to streamline LMP/LMP-WDM, as suggested by Bala, and I am sure
Nortel will be able to contribute significantly, using experience from
NTIP.
[Sahay, Vasant ] Your opinion
is valuable. However the way to pick solutions in a standards body is
not to make an adhoc choice (by a few people) about streamlining one
solution using contributions from others. We are comparing them so that
a larger number of members get a chance to look at the pros and cons of both
the solutions and decide what works best for
them.
Regards,
-Fong
Regards
Vasant
-----Original
Message-----
From: Fong Liaw
[mailto:fliaw@zaffire.com]
Sent: Friday, August 03, 2001 8:46
PM
To: Sahay, Vasant [SC9:6909:EXCH]; Andre Fredette; Jonathan
Lang; Jamoussi, Bilel [BL60:1A00-M:EXCH]; Aboul-Magd, Osama
[CAR:1A00:EXCH]
Cc: ccamp@ops.ietf.org
Subject: RE:
Optical Link Interface
Hi Vasant
I have been watching this thread for a while. I
believe both LMP, LMP-WDM,
and NTIP bring contribution to the OLI
requirements. Single out requirements
from NTIP is not a fair statement since
LMP/LMP-WDM can claim the same for
bringing in the importance of
link verification and control channel maintenance etc..
More comments below. Best Regards,
-Fong
Andre, Jonathan,
Besides broken reliable transport in LMP I will
like to list a few more items here. Let us start with
"resynchronization across
OLI".
When an LMP session fails for some reason and
recovers later, WDM-LMP or LMP do not mention the requirements or
behavior for any resynchronization to recover the defect reports that
might be lost during that window.
NTIP has thought through these behaviors.
[Fong] It is
quite often that MPLS/GMPLS authors leave this level of details to
sensible implementations. Sending LinkSummary message after
re-establishing LMP adjacency is sensible implementation.
:-)
[Sahay, Vasant
]
LMP and WDM-LMP propose use of this field to
synchronize "the interface IDs and properties of TE links". These are
static properties of TE links and their identifiers. That is all. It is
not proposed to be used for synchronization of any dynamic
information like failure reporting.
As you said, an
implementor can use his imagination and add more TLVs to achieve
synchronization of failure status as well.
But that brings out my point about an
incomplete specification that risks implementors creating their own
interpretations of the protocol.
The current WDM-LMP philosophy is "we
defined some general purpose messages and hopefully we will be able
to solve all problems by using them. If we discover missing
requirements or behaviors, then we will add new TLVs". This
approach could be OK in case WDM-LMP was the only proposal and everybody
was committed to incrementally revising it and patching up all the
missing pieces by going over all the unthought-of behaviors. But that is
not the case. NTIP has already thought through these requirements,
behaviors and the messages. NTIP does not leave these protocol design
decisions to implementors to decide on the
fly.
NTIP sessions go thru a resync process upon a
restart. During resync, WDM and
OXC exchange information on the failures/defects that might have been
lost while the session was down. Also, if the NTIP session went
down while OXC instructed the WDM to start monitoring some ports for
defects or for trace, obviously the command would be lost. NTIP resync
also recovers such lost commands.
[Fong] This is
easily supported by adding a data-link sub-TLV in LinkSummary
message.
[Sahay, Vasant ]
Same point again. Missing piece in LMP. Already
throught thru in NTIP. Why not use NTIP instead of fixing missing pieces
in WDM-LMP based on feedback from NTIP
?
NTIP has also thought thru related requirements
regarding persistence of information on equipment. WDM-LMP or LMP has no
thought on such issues.
For example if a WDM box reboots for some
reason, should it remember which ports it was supposed to monitor for
defects and trace ? Or should the OXC instruct it again for which ports
to monitor ? If WDM equipment has to remember which ports it had to
monitor, it translates into a requirement for WDM to have persistent
storage.
As mentioned above NTIP resync process solves
these issues. For details please refer to NTIP draft .--)
[Fong] I am not quite sure NTIP thought through
its requirement of WDM persistent storage either :-)
Since the Configuration update message has CStat but
there is no message for a PXC to configure the WDM. This translates to
NTIP also requiring persistent store. If this is the case, why would the
monitor and trace request not be in persistent store ? If the
model is that the OLS does not have persistent store, then it would not
know which port is enabled and would not be able to report a
Configuration state. Can you clarify ?
[Sahay, Vasant
]
Here is the
explanation.
Model is indeed
that OLS does not need persistent store. During resynchronization phase,
the OXC requests the status of all the ports it is interested in. Then
OLS responds with its "dymanic" status for the requested ports. The
burden of remembering which ports are to be monitored is on OXC and it
teaches the OLS which ports to monitor. The key part here is recovering
any updates that were lost while the link was down.Then onwards it is
plain vanilla.
By the way, your
last sentence refers to a "configuration state". We are not discussing
configuration of OLS or the administrative states of ports here. But we
are refereing to dynamic defect status on ports and enabling of defect
reporting on OLS ports.
The point is to show that NTIP has thought
through issues specific to OXC-to-DWDM interface. LMP and WDM-LMP have
not.
Vasant
Andre,
>>>>>>
Funny you should say this given that the colleagues you
reference in your note claim that LMP is not needed at all.
[Sahay, Vasant
]
I am wondering
how we can keep our discussion positive and constructive instead of
pointing out assertions or getting into legal analysis of
statements.
My statement neither confirms nor denies my
colleague's stand on "need for LMP". The statement simply is "Andre if
you were to base OLI on LMP you will suffer the
baggage".
Vasant,
You identify
what you think is extra work, but I believe your concerns derive
from misunderstandings on your part. Please see my comments
below.
At 08:17 PM 7/31/2001 -0700, Vasant Sahay wrote:
Andre,
Bilel, Osama and I have discussed the LMP related
extra-work with you in our teleconference a few months ago.
The
scope of LMP is much wider than just OLI. Before LMP gets accepted
as a standard, there is a lot of functionality and requirements in
LMP that have to be agreed upon. Dependence on LMP will only
complicate and delay OLI.
Funny you should
say this given that the colleagues you reference in your note claim
that LMP is not needed at all. However, your assertion that
there is still a lot of functionality that needs to be added to LMP
is just that, an assertion. Furthermore, if this is truly the
case, it would be easy to separate the base LMP functionality (i.e.,
99% of what's currently in LMP), and create a separate document for
the additional LMP functionality you believe is needed. This
is done all the time in the IETF.
Also, as I've said
recently, I believe the only additional feature in LMP which is not
required by the OLI requirements is link bundling. The
mechanisms for this feature may still be useful, but can also be
easily ignored.
Besides, reliable transport of failure-messages
is broken in LMP. The current LMP and WDM-LMP drafts imply that
the application will have to build a mechanism for tracking and
retransmitting lost messages. This translates into additional
baggage for OLI.
I believe (with a lot of
other people) that the use of TCP for this protocol is broken.
Please refer to the numerous previous posts regarding this
issue.
As an example LMP has ability to isolate faults.
It is not needed for OLI. You can argue that you will reuse the
same messages in OLI to report faults, but it is not the same
thing. When LMP gets fully defined with states and procedures then
we will find that the procedure for handling a failure message
between two OXCs (LMP), is very different than that for between
OXC and DWDM (OLI). As an aside my take is that failure-isolation
does not even belong fully in LMP. It is a function that belongs
between connection-management and link
management.
Fault isolation is not an
integral part of the LMP protocol. The LMP spec describes how
switching devices (e.g., OXCs) can use the fault notification
information from LMP to localize faults and make the appropriate
switching decisions. We clearly spelled out in LMP-WDM that
the OLS does not participate in fault localization (only fault
detection and notification).
There are more examples of extra work due to LMP
but we can discuss them one at a time.
The
above concerns are the only ones you have ever mentioned.
Given my explanations above, I still don't believe you have
Identified any examples of "extra work".
I did a quick back of the envelope and came up
with a total of 24 states and 46 events in LMP. That is a lot of
states for a simple protocol. This does not even include the
application states for (potential) retransmission of
messages.
After you have fully specified
NTIP, I'm sure that the only difference will be attributable to the
treatment of application-level acks (which the majority on this
discussion list feel are required for a correct protocol).
Furthermore if you want to compare true protocol complexity,
add the TCP states and events to your NTIP count, handle fail-over
of TCP sessions, and then come talk to me.
Andre
Cheers
Vasant
From:
Andre Fredette [mailto:fredette@photonex.com]
Sent:
Monday, July 30, 2001 1:51 PM
To: Jamoussi, Bilel
[BL60:1A00-M:EXCH]
Cc: John Drake;
ccamp@ops.ietf.org
Subject: RE: Optical Link
Interface
Bilel,
I might not have worded my
response exactly as John did (being the nice guy that I am), but I
agree with his answers.
In particular, you continue to talk
about "unnecessary LMP baggage", or
"complexity", but cannot describe what it is.
Andre
At 01:24 PM 7/30/2001 -0700, John Drake
wrote:
- -----Original Message-----
- From: Bilel Jamoussi [mailto:jamoussi@nortelnetworks.com]
- Sent: Monday, July 30, 2001 8:14 AM
- To: 'Andre Fredette'; 'ccamp@ops.ietf.org'
- Subject: RE: Optical Link Interface
- Andre,
- 2 comments on you statistics, then a proposal to
progress:
- 1. The stats are not that significant, since there was no
"last call" period announced in advance to gauge community
interest.
- [John Drake]
- This is silly. Who else would you like to hear from?
- 2. I do not think IETF uses company affiliation when
measuring consensus. If it did, then the fact that 3 from Nortel
are supporting NTIP, is an indication that there is an immediate
need for NTIP given Nortel is a key player in this
space.
- [John Drake]
- The fact that you perceive yourself to be a key player
shouldn't a priori give your opinion any additional weight
- ------
- All,
- Now to focus the discussion back on the OLI solutions (NTIP
or LMP-WDM, or a merged version),
- - There is consensus on a single protocol which I
respect.
- - Key distinctions between NTIP and WDM-LMP:
- 1. WDM-LMP assumes that LMP is a priority, people will
implement LMP, hence WDM-LMP is a natural extension. The issues
here are:
- (a) this assumption is not accurate, the functions of NTIP
(or WDM-LMP) are more urgent than LMP
- [John Drake]
- What is the basis for this assertion? When we
started the LMP-WDM work we asked you to work on it with us
- and you refused, citing lack of need.
- (b) there is significant baggage to be carried from LMP down
to the WDM-LMP
- [John Drake]
- You've made this assertion inumerable times, and have been
asked inumerable times to enumerate what this
- excess baggage is. You have yet to do so.
- 2. WDM-LMP assumes a peer model between the OXC and the WDM
system. The issue:
- - this model doesn't reflect the reality that OXC and WDM
are two different devices - the OXC-WDM relationship is
client-server one.
- [John Drake]
- This is an assertion. Some of the co-authors of the
LMP WDM draft work for WDM vendors and they're happy with
- the peer relationship between the two devices
- I suggest merging the two proposals as follows:
- - remove unnecessary LMP baggage
- [John Drake]
- Once again, this would be what?
- - adopt a client-server model
- [John Drake]
- No
- - allow for TCP as the transport
- [John Drake]
- No one but you and your co-authors think that this is either
necessary or desirable
- - clarify a simplified autodiscovery mechanism
- Bilel.
- -----Original Message-----
- From: Andre Fredette [mailto:fredette@photonex.com]
- Sent: Thursday, July 26, 2001 2:52 PM
- To: ccamp@ops.ietf.org
- Subject: RE: Optical Link Interface
- From my count on the mailing list we have the
following results so far:
- LMP-WDM: 8
- NTIP: 3 (All from Nortel)
- Agnostic: 1
- And then there are the other 16 co-authors of LMP-WDM who
haven't posted
- (perhaps because they don't think they have any new points
to add).
- Andre
- At 02:00 PM 7/26/2001 -0400, Martin Dubuc wrote:
- >Kireeti,
- >
- >I have been following this thread with great interest. I
agree with your
- >conclusion that we should pick one protocol and move
forward.
- >
- >You are talking about WG reaching a consensus. I cannot
see how this is
- >possible given the two very different views I see in the
latest email
- >exchanges.
- >
- >How can we resolve the current dispute? What forum
should we use to make
- >a final decision on this?
- >
- >Martin
- >
- >-----Original Message-----
- >From: Kireeti Kompella [mailto:kireeti@juniper.net]
- >Sent: Wednesday, July 25, 2001 9:57 PM
- >To: jamoussi@nortelnetworks.com;
kireeti@juniper.net;
- >osama@nortelnetworks.com
- >Cc: bon@nortelnetworks.com; ccamp@ops.ietf.org;
- >vasants@nortelnetworks.com
- >Subject: RE: Optical Link Interface
- >
- >
- >Hi Osama,
- >
- > > Even though I don't think reviving CR-LDP and
RSVP-TE history will get
- >us
- > > anywhere
- >
- >"Those who forget (ignore) history are doomed to repeat
it."
- >
- >Yes, it makes for painful recollections. We're
living with the
- >consequences now, though, and I don't want to
again.
- >
- > > the existence of two protocols here have proven to
be useful.
- >
- >That's not what I'm hearing, either from customers, or
from the
- >WG (admittedly, the sample is small).
- >
- >Listen carefully: I don't want LMP-WDM and NTIP moving
forward.
- >Just NTIP (or NTIP and LMP) is OKAY if that is what the
WG
- >consensus is. LMP-WDM and LMP works too.
- >
- >So: you've got the WG chairs (scarred and grumpy), the
ADs
- >and TA (speak up if I'm misrepresenting you), and
customers
- >saying, Pick one protocol and move forward. Let's
do that.
- >And, please, as Vijay says, let's resolve this
already.
- >
- >Kireeti.