[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Optical Link Interface
Andre,
I am
glad you agree that NTIP had mentioned link verification in the first draft. The
reason for not elaborating on it's details was that we didnt want to jump into
implementation details of all the features at once. We believe in building
consensus on requirements and scope of the interface and then describing all the
implementation details.
By the
way, you and Jonathan have not responded to my previous
two ccamp-postings.
Vasant
Let's try to be accurate Vasant.
Link
verification was not part of the initial NTIP spec (other than to mention that
it would be good to do). You've added a couple paragraphs to the recent
spec, but still don't have it fully specified, and do not even have the
requisite messages defined.
Sounds like "on the fly design" to
me.
By the way, just like everything else in NTIP, I'm sure it can be
made to work, but WHY????? LMP already does it.
Andre
At
02:20 PM 8/5/2001 -0700, Vasant Sahay wrote:
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.
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.
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
-
- -----Original Message-----
- From:
Vasant Sahay [mailto:vasants@nortelnetworks.com]
- Sent:
Thursday, August 02, 2001 2:46 PM
- To:
Vasant Sahay; Andre Fredette; Jonathan Lang; Bilel Jamoussi;
Osama Aboul-Magd
- Cc:
ccamp@ops.ietf.org
- Subject:
RE: Optical Link Interface
- 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
- -----Original Message-----
- From: Sahay, Vasant [SC9:6909:EXCH]
- Sent: Wednesday, August 01, 2001 3:15 PM
- To: Andre Fredette
- Cc: ccamp@ops.ietf.org
- Subject: RE: Optical Link Interface
- 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".
-
- >>>>>>> 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.
- [Sahay, Vasant ]
- If we used TCP for LMP it will certainly be broken because LMP
is a WAN protocol and has to consider round trip delays, variable
losses and congestion. But not so for NTIP. NTIP runs in a controlled
local environment where the congestion control sophistications can be
disabled.
- By the way, we are not married to TCP. In fact while co-authoring
the OLI requirements we have only asked for a reliable transport. It can
be one of the many available prorocols used for reliable transport.
- The fundamental difference (in reliable transmission) between NTIP
and LMP is that NTIP is layered to run over a reliable transport
protocol, whereas WDM-LMP has an application implementing the
reliablity.
-
- Also, in this context, on the LMP-baggage front, you will need two
flavors of retransmission schemes one for WAN (LMP) traffic, and the
other for local traffic (WDM-LMP). Does that sound like extra work
?
-
- >>>>>>>>>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.
- [Sahay, Vasant]
- The complexity of a readymade module is not a consideration. The
complexity of WDM-LMP and LMP code to be developed is the question here.
The objective is to compare the development and integration risk and not
the states within TCP or any existing transport protocol for that
matter.
-
- Vasant
- ---Original Message-----
- From: Andre Fredette [mailto:fredette@photonex.com]
- Sent: Wednesday, August 01, 2001 7:59 AM
- To: Sahay, Vasant [SC9:6909:EXCH]
- Cc: ccamp@ops.ietf.org
- Subject: RE: Optical Link Interface
- 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.