[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LMP & neighbor discovery

Martin,

See below.

Carmine


Martin Dubuc wrote:
2B192BF55E1A4440A1176A12D86600C915C8BE@edgsvr04.edgeflow.edgeflow.com"> 
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 don't think anyone really cares about the exact terminology so long as it is clear and understandable. What is more important is making sure that LMP actually provides what is needed.  Until LMP does provide what is needed, I don't think its too late to change a LMP specification. Isn't this still a work in progress?
2B192BF55E1A4440A1176A12D86600C915C8BE@edgsvr04.edgeflow.edgeflow.com"> 


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.

    The reason why Michiel stated
that LMP is not applicable for TTP->CTP or TTP->TTP is because the
current LMP specification requires the TTP generating the test signal to
change its Access Point Identifier over time which is not in line with G.831.
G.831 requires that the TTP API be constant over time. Michiel's proposal
satisfies the G.831 requirement (see Michiel's email http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html)
. 

    
2B192BF55E1A4440A1176A12D86600C915C8BE@edgsvr04.edgeflow.edgeflow.com">
      
 
 
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.

      

      So you agree that LMP
does cover discovery when a point-to-point control channel exists across
each data link. So this seems to imply that Discovery is within the scope
of LMP. From reading the emails on this topic the past few weeks it is obvious
that this was not clear to many on the ccamp list and even not clear to folks
that are listed on the LMP specification itself.

      

Given that Discovery is within the scope of LMP, what is being proposed is
that we meed to make it applicable/useful to network configurations that
do not support a point-to-point control channel across each data link. A
big portion of the LMP specification introduction describes Photonic Cross-connects,
yet Photonic Cross-connects will not be capable of supporting a point-to-point
control channel in each of its data links. So given that PXCs are within
the Framework of LMP and Discovery is as well, it would make sense to me
that Discovery would apply to PXCs. Its also going to be important for the
new "intelligent-switched" network to interwork with the embedded switches
that are controlled by the management plane. This leads to the need to support
discovery across serial-compound link connections, which LMP does not. Shouldn't
the ability to interwork with the embedded base be considered in LMP or is
LMP only applicable for new start-up companies building entirely new networks?
      

      
2B192BF55E1A4440A1176A12D86600C915C8BE@edgsvr04.edgeflow.edgeflow.com">
        
 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...]