Re: Proposed response to the Liaison Statement on LMP Link Verification

[Jonathan Sadler <[e-mail]>]

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.

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

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

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.

<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
============================================================