[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LMP & neighbor discovery
Michiel,
Just because it is easy to specify the address of an endpoint in a 15 character field doesn't mean that this is the way to go. Why not put a 30 byte field in every message in order for vendors to add any extensions they'd like? In my mind, any extensions we add to LMP has to make sense in the framework of LMP. As I said before, there is absolutely no mention of CTPs and TTPs in the current LMP spec. Introducing anything that makes reference to CTPs/TTPs would require major rework to LMP spec and might have big impact on any vendor (on this earth) implementing LMP. I am not sure it makes sense at this point in the game.
I am not convinced that it is not possible to perform TTP->CTP or TTP->TTP link verification with the current spec. I am pretty positive that one can perform TTP->TTP link verification when one models the TTP as a component link.
Regarding the automatic discovery aspects of LMP, you are right that there is a deficiency with regards to non point-to-point configuration. Current framework of LMP works very well for point-to-point configurations. I do not know if we should extend the current spec to also allow auto-discovery of non point-to-point configuration. LMP is most useful in my mind in a point-to-point configuration, so I don't have much problems with the current limitation, which is that control channels for non point-to-point neighbors need to be manually provisioned.
Finally, I am not sure why you bring the 7200 OADX in the discussion. Is this a lame argument to discredit my interventions? I hope that we could have discussions at another level.
Regards,
Martin
-----Original Message-----
From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com]
Sent: Friday, May 31, 2002 5:59 AM
To: Martin Dubuc
Cc: ccamp@ops.ietf.org
Subject: Re: LMP & neighbor discovery
Hello Martin,
You seem to only be able to make bold statements without following
up on them:
- On your statement that we don't need TTP and CTP terminology
because you find these concepts complex:
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00751.html
Please follow up on my question for alternative terminology:
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00795.html
- On your statement that my proposal for neighbor discovery is
tailored specifically for Sonet/SDH:
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00786.html
Please follow up on my reply that it is more general
applicable:
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00795.html
- On your statement that we don't need to enhance the
discovery aspects of LMP:
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00751.html
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00797.html
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00840.html
Please follow up on Carmine's question in:
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00800.html
Would the background of your annoyance be that for your specific
product, 7200 OADX, you are only interested in LMP-WDM (i.e.
not LMP) ? I can understand that in a product that integrates
OADM and OXC, it is no problem to have a fixed (not operator
provisioned) control channel between the OADM and the OXC.
However, your specific product is not the only product on this
earth...
Best regards,
Michiel
Martin Dubuc wrote:
>
> Michiel,
>
> Neighbor discovery, through use of appropriate control channel management
> (see Section 3 and 9), is supported with the current LMP draft. There is
> no need for any extension to the draft for this purpose.
>
> Regards,
>
> Martin
> [...snip...]
--
+------------------------------------------------------------------+
| Michiel van Everdingen |
| Systems Engineer |
| Lucent Technologies - Optical Networking Group |
| Botterstraat 45, 1271 XL Phone : +31 35 687 4883 |
| P.O. Box 18, 1270 AA Fax : +31 35 687 5976 |
| Huizen, The Netherlands mailto:MvanEverdingen@lucent.com |
+------------------------------------------------------------------+