RE: Proposed response to the Liaison Statement on LMP Link Verifi cation

[John Drake <jdrake@calient.net>]

> -----Original Message-----
> From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com]
> Sent: Monday, April 28, 2003 3:08 PM
> To: John Drake
> Cc: Brungard, Deborah A, ALABS; Stephen Trowbridge;
> Jonathan.Lang@RinconNetworks.com; George Newsome;
> Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert);
> ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail);
> zinin@psg.com
> Subject: Re: Proposed response to the Liaison Statement on LMP Link
> Verifi cation
> 
> 
> John -
> 
> See inline...
> 
> Jonathan Sadler
> 
> John Drake wrote:
> 
> > Jonathan Sadler wrote:
> > > John Drake wrote:
> > > >> The liaison from T1X1 asked if it is necessary for two totally
> > > >> independent message formats to exist for the in-band 
> case as the
> > > >> function being performed by both G.7714.1 and the Jx 
> Test Message
> > > >> Connetivity Verification approach defined in 
> lmp-test-sonet-sdh is
> > > >> the same.
> > > >>
> > > > JD:  I don't think that is correct.  The LMP Test 
> procedure is used
> > > > to exchange the GMPLS identifiers for a given data 
> link.  Since the
> > > > GMPLS identifiers may not be globally unique, it is necessary to
> > > > qualify them with a Verify ID, which identifies the 
> particular Test
> > > > procedure the identifiers are associated with.  
> G.7714.1 is used to
> > > > exchange the transport level identifiers for a given link.
> > >
> > > G.7714.1 shows that the exchange of control plane 
> identifiers (e.g.
> > > GMPLS TE-Link IDs) is done as a part of service 
> capability exchange
> > > process which comes after the neighbor has been 
> discovered.  This was
> > > separated from the neighbor discovery mechanism to allow 
> the neighbor
> > > discovery function to be used by things other than the 
> control plane
> > > (i.e. management systems).
> > >
> > > It should be noted that Appendix III of G.7714.1 suggests 
> a way to use
> > > LMP's trace correlation mechanism to accomplish this, which then
> > > dovetails into the rest of LMPs processes.
> >
> > JD:  Your original statement, to which I responded, was:  
> "as the function
> > being performed by both G.7714.1 and the Jx Test Message 
> Connetivity Veri-
> > fication approach defined in lmp-test-sonet-sdh is the 
> same."  What you're
> > now saying is that there is a neighbor discovery piece to 
> G.7714.1 which
> > has no equivalent in the LMP Test procedures, followed by 
> the LMP Test pro-
> > cedure using the trace correlation tranport mechanism.
> 
> I tend to look things from a functional decomposition 
> perspective, and not at
> the specific bits/bytes.
> 
> The goal being sought is:
>   - determination that a link exists
>   - determination that it is not miswired
>   - exchange of control plane names for the endpoints of that link
> 
> Two in-band methods exist that accomplish this goal for a 
> SONET/SDH link.  They
> are:
>    draft-ietf-ccamp-lmp-test-sonet-sdh
>   and
>     G.7714.1 (including Appendix III)


JD:  What you're glossing over here is that fact that according to
your previous e-mail, Appendix III of G.7714.1 is actually the LMP
Test procedure using the trace correlation transport mechanism.  So,
even in G.7714.1 as it currently exists, the only way to exchange
control plane identifiers is the LMP Test procedure.

> 
> Both methods describe message formats that intrusively use 
> the Jx strings.
> While the formats are different, the function accomplished is 
> identical.


JD:  As I mentioned previously, neighbor discovery in G.7714.1 has
no LMP equivalent.  Exchange of control plane identifiers uses the
LMP Test procedure in both cases. 


> 
> > So, in spite of what the G.7714.1 proponents have been 
> saying, there doesn't
> > appear to be any functional overlap between the neighbor 
> discovery piece
> > of G.7714.1 and the LMP Test Procedure.
> 
> Not certain how you can say this given the above.
> 
> The fact that G.7714.1 took into account that neighbor 
> discovery can be used in
> the absence of the control plane, and therefore uses 
> transport plane identifiers
> in the Jx message format, doesn't change its functional 
> equivalence when it is
> used to support the control plane.
> 
> And if you don't want to maintain a control-plane namespace 
> separate from the
> transport-plane namespace, G.7714.1 does not proclude the 
> namespace mapping
> function being as simple as:
>   f(x) = x


JD:  Control plane identifiers have different requirements from
transport plane identifiers, which you implicitly acknowledged by
using LMP in G.7714.1 to exchange control plane identifiers


Snipped ...