RE: Optical Link Interface

["Vasant Sahay" <[e-mail]>]

Hi Fong,
See my comments below
 
Regards
Vasant

-----Original Message-----
From: Fong Liaw [mailto:[e-mail]]
Sent: Monday, August 06, 2001 1:05 PM
To: Sahay, Vasant [SC9:6909:EXCH]; Fong Liaw; Andre Fredette; Jonathan Lang;
Jamoussi, Bilel [BL60:1A00-M:EXCH]; Aboul-Magd, Osama [CAR:1A00:EXCH]
Cc: [e-mail]
Subject: RE: Optical Link Interface


Hi, Vasant

-----Original Message-----
From: Vasant Sahay [mailto:[e-mail]]
Sent: Sunday, August 05, 2001 2:20 PM
To: Fong Liaw; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama
Aboul-Magd
Cc: [e-mail]
Subject: RE: Optical Link Interface


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. 
 
[Fong]  But LMP (which LMP-WDM uses the link-verification procedure) is out
for a long-long time. NTIP is quite recent.  We all have protocols that
works in our lab/product and did not bother to bring them out. LMP does have
first-mover advantage here.
[Sahay, Vasant] I agree with the fact that LMP is out there for a long time.
However IETF should not pick a solution based only on being a first-mover.
As we have said before LMP has a much wider scope than OLI and it is not
completely defined either. Hence using LMP for OLI has time-to-market and
design issues. NTIP on the other hand is a specifc solution, focused on
OXC-to-OLS interface.   
 
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. 
 
[Fong]  I would ask why would we make a protocol extensible if we do not
plan to extend it to do other functions. The fact that we can simply add a
sub-TLV to accomplish new functionality says that if I implement LMP, I have
better chance of re-using my implementation. Also, if after I implement
NTIP, do I still need to implement LMP so that an OLS can also work with a
router that is not a master controller ? Or would you propose we extend NTIP
to do that function as well ? If so, using your way of argument, I can claim
that NTIP is not complete in this aspect either.
[Sahay, Vasant] Two points here:
#1) protocol extension is a good thing. We should use it for unforeseen
extensions in future/ for supporting proprietary extensions etc.
However we have two competing proposals here. One (NTIP) already has
considered and incorporated the features specific to OLI. Other (WDM-LMP)
has not considered them and  you are proposing to enhance WDM-LMP to add
these extensions. I will save extensions for future use.
#2) You are arguing that you will end up implementing LMP for OXC-to-OXC and
NTIP for OXC-WDM so why not reduce the number of acronyms by basing OLI on
LMP ? We have gone in loops on this argument for several months now.
 
[Fong] From my read to LMP/LMP-WDM, LMP has also thought through the
control/data channel degradation issues and its implications to SLA. NTIP
has no mention of it. Simply said that NTIP does not address configuration
issues and therefore do not requirement persistent store does not really
simplify my implementation/system. I have no doubt that NTIP brought its own
contribution, but if NTIP wants to present itself as a superior/complete
protocol,  I am afraid you would not get strong support in that. 
[Sahay, Vasant] Thanks for appreciating NTIP's contribution. If you look at
the OLI requirements you will find more of it. We have no intentions of
touting any superiority. We are only requesting that our proposal be treated
fairly. It is in the best interest of the industry to go through the
comparison to see what suits them, as oppsoed to picking something just
because it is a first mover.
 
 We can continue the comparison game forever, but it will do no good to the
industry. IMHO, the best way forward is to streamline LMP/LMP-WDM, as
suggested by Bala, and I am sure Nortel will be able to contribute
significantly, using experience from NTIP.
[Sahay, Vasant ] Your opinion is valuable. However the way to pick solutions
in a standards body is not to make an adhoc choice (by a few people) about
streamlining one solution using contributions from others. We are comparing
them so that a larger number of members get a chance to look at the pros and
cons of both the solutions and decide what works best for them.
 
 
  
 
   Regards, -Fong
 Regards
Vasant
 
-----Original Message-----
From: Fong Liaw [mailto:[e-mail]]
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: [e-mail]
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:[e-mail]]
Sent: Thursday, August 02, 2001 2:46 PM
To: Vasant Sahay; Andre Fredette; Jonathan Lang; Bilel Jamoussi; Osama
Aboul-Magd
Cc: [e-mail]
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: [e-mail]
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:[e-mail]]
Sent: Wednesday, August 01, 2001 7:59 AM
To: Sahay, Vasant [SC9:6909:EXCH]
Cc: [e-mail]
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:[e-mail]
<mailto:[e-mail]> ]
Sent: Monday, July 30, 2001 1:51 PM
To: Jamoussi, Bilel [BL60:1A00-M:EXCH]
Cc: John Drake; [e-mail]
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:[e-mail]
<mailto:[e-mail]> ] 

Sent: Monday, July 30, 2001 8:14 AM 

To: 'Andre Fredette'; '[e-mail]' 

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:[e-mail]
<mailto:[e-mail]> ] 

Sent: Thursday, July 26, 2001 2:52 PM 

To: [e-mail] 

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:[e-mail]
<mailto:[e-mail]> ] 

>Sent: Wednesday, July 25, 2001 9:57 PM 

>To: [e-mail]; [e-mail]; 

>[e-mail] 

>Cc: [e-mail]; [e-mail]; 

>[e-mail] 

>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.