Jonathan,
Here are my comments on some excerpts.
Best
Vasant
>[vasant]----I see a contradiction in your statement. May be you can
clarify. Earlier you
>said you retransmit alarms until acknowledged. If you take that approcah
you dont need any
>protocol for message recovery-and you dont need any window sizes. So are
you recommending
>the "alarm-retransmission method" or the "window protocol method" ?
[Jonathan]alarm-retransmission.
----------
[vasant]The fact that you were recommending "window sizes" approach but now have chosen to go the "alarm-retransmission" route tells me not much thought has gone into it. This level of definition is what makes me nervous about the use of LMP as basis for OLI.
>>>>>>>>>[Jonathan]Are you speaking as a WDM vendor here?
[vasant]Yes. And on behalf of others too.
-----------------------------------------------------------------------------------------
-----Original Message-----
From: Jonathan Lang [mailto:jplang@calient.net]
Sent: Wednesday, August 01, 2001 1:16 AM
To: Sahay, Vasant [SC9:6909:EXCH]; Jonathan Lang; 'Mannie, Eric ';
Jamoussi, Bilel [BL60:1A00-M:EXCH]; '''Andre Fredette' ' ';
'''ccamp@ops.ietf.org' ' '
Subject: RE: Optical Link Interface
Vasant,
Please see inline comments.
Thanks,
Jonathan
>>>>>>>>From my point of view, I don't see any reason to replace a protocol
by
>>>>>>>>another one if they have the same functionalities.
>>The misconception here is that they have the same functionalities and
>>that LMP definition is complete. I believe there is a lot of discussion
>>and thought that needs to go into LMP if used as basis for OLI. WDM-LMP
>>being based on LMP will also suffer that thrash.
>[Jonathan]...and NTIP is complete and will not suffer any thrashing?
>[vasant]---- NTIP has a much smaller scope than LMP. It focuses on OXC-WDM
only. Hence the
>thrash (if at all) will be much less.
>
>>Let us start with reliable transport(or lack thereof).
>>How are failures conveyed reliably from WDM to OXC ?
>>
>LMP defines ACK messages, however I couldnt find any reference to how
>they should be used to recover lost messages.
>[Jonathan]Failures notification is idempotent. LMP is optimized to
>react to alarms rapidly and doesn't require stop-and-wait procedures.
>Alarms are treated as independent events. Eash alarm is transmitted until
>acknowledged (see Section 6). If an alarm status changes, prior to
>receiving the Ack, the new status is simply transmitted.
>For a procedural reference, LMP works very much like that of RSVP-TE
>message Ids in RFC2961.
>[vasant]-----that is a lot of traffic.Could cause bottlenecks. Also unlike
the usual >"telecom alarms" these events (I prefer that name) need to be
successfully received in
>"real time"(failure reporting ---say 10 millisecond). Which means the
periodic transmission
>rate will be 10s of milliseconds--until acknowledged. That will create a
lot of traffic for
>sure.The situation is not the same as RSVP refresh here. The refresh rate
will need to be
>much higher than RSVP.
[Jonathan]You're confusing RSVP refresh with RSVP message acks. Of course
the rate would be much higher than RSVP refresh rate.
>>WDM-LMP draft specifies that an ACK should be sent for each
>>channelStatus message. This level of definition is far from complete.
>>
>>So the question is if a few hundred failures were reported, what is the
>>nature of this ACK scheme for recovering lost messages ? Are we going to
>>recommend a stop and wait protocol or a sliding window protocol ? (A
>>stop and wait scheme is easy to implement but slow at recovering
>>messages ) Or is the recovery scheme beyond the scope of the protocol ?
>[Jonathan]Currently, a window size is intentionally not specified. We
>can add a recommendation in terms of message transmission and processing if
>that is helpful.
>[vasant]-----it is not that simple. Once you enter the world of sliding
window protocols,
>you have to test out the window sizes and timers for different networks and
operating
>systems.What I meant by reinventing TCP was this maturing cycle and the
sliding window
>part.Why put implementors through this pain when a readymade solution is
available in TCP?
[Jonathan]The message ack procedures of LMP are essentially the same as
those defined in RFC2961.
>[vasant]----I see a contradiction in your statement. May be you can
clarify. Earlier you
>said you retransmit alarms until acknowledged. If you take that approcah
you dont need any
>protocol for message recovery-and you dont need any window sizes. So are
you recommending
>the "alarm-retransmission method" or the "window protocol method" ?
[Jonathan]alarm-retransmission.
>>If a sliding window is chosen, the implementor will develop code to
>>reinvent what TCP does and will have to go through a maturing cycle for
>>his sliding window scheme. There will also be implementation issues
>>with managing real time OS timers at application level.
>[Jonathan]We certainly don't want to reinvent TCP. We don't need such a
>heavy-weight protocol for this interface. What we need is a reliable
>lightweight messaging protocol that can react to failures rapidly.
>>Keep in mind the WDM vendors are not in the business of developing
>>transmission protocols for reliablity.
[Jonathan]Are you speaking as a WDM vendor here?
>They need a solution that can be
>easily added to their existing systems, many of which are legacy
>systems.
>
>In contrast NTIP has thought through these issues and uses TCP as the
>reliable transport.
>
>
>To start with that is one fundamental difference in the transport of
>NTIP vs LMP or WDM-LMP
>
>I am concerned about such open items in LMP which will come to haunt
OLI
>later.
>
>Vasant
-----Original Message-----
From: Mannie, Eric [ mailto:Eric.Mannie@ebone.com
<mailto:Eric.Mannie@ebone.com> ]
Sent: Monday, July 30, 2001 3:21 PM
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]; ''Andre Fredette' ';
''ccamp@ops.ietf.org' '
Subject: RE: Optical Link Interface
Dear all,
>1. The stats are not that significant, since there was no "last call"
period announced in advance to gauge community interest.
Well, at least it shows some preferences for a specification based on an
existing protocol on which the IETF is working since a while and that
was
accepted as a WG document.
From my point of view, I don't see any reason to replace a protocol by
another one if they have the same functionalities.
So,
LMP-WDM: 8 + 1 = 9.
Kind regards,
Eric
Eric Mannie
EBONE
-----Original Message-----
From: Bilel Jamoussi
To: 'Andre Fredette'; 'ccamp@ops.ietf.org'
Sent: 7/30/01 5:14 PM
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.
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.
------
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
(b) there is significant baggage to be carried from LMP down to the
WDM-LMP
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.
I suggest merging the two proposals as follows:
- remove unnecessary LMP baggage
- adopt a client-server model
- allow for TCP as the transport
- clarify a simplified autodiscovery mechanism
Bilel.
-----Original Message-----
From: Andre Fredette [ mailto:fredette@photonex.com
<mailto:fredette@photonex.com>
< mailto:fredette@photonex.com <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
<mailto:kireeti@juniper.net>
< mailto:kireeti@juniper.net <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.