Re: Summary of LMP implementation/deployment reports

[Carmine Daloia <daloia@lucent.com>]

Dimitri,

Thanks for the explanation for why it is left as a separate document.

I disagree with one point.  You say that the bootstrap process would not 
cause anything in the lmp draft to be modified.

Once the controll address of the neighbor is learned via the bootstrap 
process, I don't see the purpose for Control Channel Management Procedure.

A link summary message can be sent directly to the controll address 
learned via the bootstrap process.  Therefore I would have expected the 
Control Channel Management Procedure to be removed completely or at 
least made optional.

Carmine

Dimitri.Papadimitriou@alcatel.be wrote:

> carmine,
>
> 1) this has been proposed in order to keep going with content 
> that has been discussed since more than two years now (and has 
> not been modified by the below mentioned document), 
> 2) since the result of the process (and the information it allows
> to discover) is at the end the same than the one obtained when 
> applying the test message procedure no subsequent mechanisms 
> are modified by the bootstrap approach
>
> 3) moreover, the bootstrap mechanisms have been identified (this 
> from the mailing list discussions) to be useful (up to now) for 
> sonet/sdh or more generally for "optical" environments only.
>
> thus i think this may justify the (good imho) idea to have two 
> separate documents (it results from the above points to be thus
> also justified from an implementation viewpoint) 
> thanks,
> - dimitri.
>
> Carmine Daloia wrote:
>  
> > Why is the procedure described in the lmp-bootstrap draft not included
> > in the lmp-draft?  Doesn't sound like lmp is complete without this
> > capability and therefore doesn't seem to make sense to have these in
> > separate drafts.
> >
> > Carmine
> >
> > Dimitri.Papadimitriou@alcatel.be wrote:
> >
> >    
> > > Carmine,
> > >
> > > this is why i have previously mentioned in my response
> > > that "a proposal has been made to bootstrap out-of-band
> > > control channels and discover the interface_id mappings
> > > (or associations) before establishing a control channel"
> > >
> > > see:
> > > http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
> > >
> > > thus the problem you've indicated in the below message is
> > > also addressed -
> > >
> > > so
> > > " So LMP can *build* the mappings (i.e., reduce
> > >
> > >
> > >      
> > > > operator provisioning) if the operator has previously provisioned the
> > > > remote node addresses for each and every data link. "
> > > >
> > > >
> > > >        
> > > may be now rephrased as
> > > " LMP can *build* the mappings (i.e., reduce operator provisioning)
> > >
> > >
> > >      
> > > > without any provisioning of the remote node addresses for each
> > > > and every data link"
> > > >
> > > >
> > > >        
> > > thanks,
> > > - dimitri.
> > >
> > > Carmine Daloia wrote:
> > >
> > >
> > >      
> > > > Kireeti, Dimitri,
> > > >
> > > > I realize that Section 5 in draft-ietf-ccamp-lmp-05.txt states that the
> > > > Link Connectivity Verification procedure (which is optional) may be used
> > > > to dynamically learn the id associations.  Is this what you mean by LMP
> > > > being able to *build* the mappings?  However this requires that an
> > > > operator *PROVISION* for each and every data link the remote node
> > > > address that the data link is terminated on.  Only with this
> > > > provisioning will the local node know the address to send the
> > > > BeginVerify message to.   So LMP can *build* the mappings (i.e., reduce
> > > > operator provisioning) if the operator has previously provisioned the
> > > > remote node addresses for each and every data link.  Doesn't seem like a
> > > > useful capability.
> > > >
> > > > Carmine
> > > >
> > > > Kireeti Kompella wrote:
> > > >
> > > >
> > > >
> > > >        
> > > > > Hi Carmine,
> > > > >
> > > > > On Tue, 3 Sep 2002, Carmine Daloia wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >          
> > > > > > So basically LMP is used to verify that the datalink id mappings stored
> > > > > > in the neighboring nodes match eachother.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >            
> > > > > Actually, LMP is used to *build* the mappings, not verify them.  If the
> > > > > mappings were already stored, LMP could be used to verify them -- but
> > > > > that is a secondary function.
> > > > >
> > > > > Kireeti (as a WG participant).
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >          
> > >