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.