Re: Summary of LMP implementation/deployment reports

[Dimitri.Papadimitriou@alcatel.be]

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