RE: Optical Link Interface

[Jonathan Lang <jplang@calient.net>]

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.