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.