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

[John Drake <[e-mail]>]

See below.

>From my perspective, the LMP Test procedure using the trace
correlation transport mechanism can be used to support the
exchange of control plane identifiers in G.7714.1 networks
and the G.7714.1 Neighbor Discovery message cannot be used
to support the LMP Test procedure with the intrusive Jx
transport mechanisms.

This is pretty much what I have said all along and I am now
done with this thread.
  

> -----Original Message-----
> From: Jonathan Sadler [mailto:[e-mail]]
> Sent: Tuesday, April 29, 2003 1:47 PM
> To: John Drake
> Cc: Brungard, Deborah A, ALABS; Stephen Trowbridge;
> [e-mail]; George Newsome;
> [e-mail]; Wijnen, Bert (Bert);
> [e-mail]; [e-mail]; Ron Bonica (E-mail);
> [e-mail]
> Subject: Re: Proposed response to the Liaison Statement on LMP Link
> Verification
> 
> 
> John -
> 
> See inline...
> 
> Jonathan Sadler
> 0         1         2         3         4         5         6
> 0123456789012345678901234567890123456789012345678901234567890123456789
> 
> John Drake wrote:
> 
> > Jonathan Sadler wrote:
> > > 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 Verification 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 procedure 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.
> 
> Remember, the subject for discussion here is the message sent
> in-band in the Jx trace bytes.  The use of the LMP Test
> procedure in Appendix III is limited to the trace correlation
> method, which is sent over the DCN.


JD:  And that is because the Neighbor Discovery message does not
contain sufficient information (i.e., Verify ID) to be used for
exchanging control plane identifiers, which was my original point.


> 
> > > 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.
> 
> Incorrect assertion.  Both the neighbor discovery method in
> G.7714.1 and intrusive Jx messages defined in lmp-test-sonet-sdh
> achieve goals 1 and 2.


JD:  No, the intrusive Jx messages defined in the LMP Test procedure
accomplish goals 1, 2, and 3 simultaneously.


> 
> Goal 3 was identified by G.7714 to be technology independent,
> and therefore something that should be carried over the DCN.


JD:  That's fine.  This was the point I made to Rajender last
week.  Just don't claim that the Neighbor Discovery message can
be used to support the LMP Test procedure with the intrusive Jx
transport mechanisms, because, as I have pointed out on numerous
occasions, it doesn't contain the necessary information.


> 
> Jx does not need to be involved in mechanism that accomplishes
> Goal 3.  This is why it does not appear in the Jx message format.


JD:  As mentioned above, the LMP Test procedure using the intrusive Jx
transport mechanisms accomplishes goal 1, 2, and 3 simultaneously.  If
you don't want to do this in G.7714.1 networks, that is your choice.


> 
> <SNIP>
> 
> ============================================================
> The information contained in this message may be privileged 
> and confidential and protected from disclosure.  If the 
> reader of this message is not the intended recipient, or an 
> employee or agent responsible for delivering this message to 
> the intended recipient, you are hereby notified that any 
> reproduction, dissemination or distribution of this 
> communication is strictly prohibited. If you have received 
> this communication in error, please notify us immediately by 
> replying to the message and deleting it from your computer.
> 
> Thank you.
> Tellabs
> ============================================================
>