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.
:-)
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.
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 ?
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.