RE: Comparision to OIF UNI discovery? RE: I-D ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt

["Bernstein, Greg" <GregB@ciena.com>]

Hi Jonathan,
I understand this is addressing the In-band/In-fiber case, like we did at
with the OIF UNI, but the mechanism seems different.  Particularly in the
case of line or section DCC (the case most of us have already implemented
and interoperated with).

For a trail trace mechanism, i.e., you mention using J0.  If I recall this
doesn't solve George Swallows problem of a "dumb mux" between a router and a
SONET/SDH switch. I think J1 (path trace) was the solution we discussed way
back then. I think Michiel's e-mail probably summarized some of this best an
proposed a more general solution.  However, I still think mucking with this
part of the SONET/SDH signal needs to be done at ITU-T.  For the
transparent/pre-OTN stuff we could leave it with CCAMP along with WDM-LMP.

I did a check on OIF2000.089 and found the following:    oif2000.089.00 -
OIF OAM&P Working Group - Living List Author: Ren Wu     Company: Lucent
Technologies Date created: 04/24/2000     Date updated: 04/24/2000 Working
group(s): OAM&P
Abstract: The OIF OAM&P Working Group met on January 21 - February 1, 2000
in New Orleans, LA. The OAM&P WG Living List was updated during this
meeting. The updated Living List includes two additional issues (readline).
In addition, it was agreed to expa...

This doesn't seem like the right reference.  I saw Michiel referencing
OIF2000.159v2 some of my old work at OIF along these lines...

Greg

-----Original Message-----
From: Jonathan Lang [mailto:jplang@calient.net]
Sent: Tuesday, June 11, 2002 3:08 PM
To: Bernstein, Greg; ccamp@ops.ietf.org
Subject: RE: Comparision to OIF UNI discovery? RE: I-D
ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt


Greg,

> -----Original Message-----
> From: Bernstein, Greg [mailto:GregB@ciena.com]
> Sent: Tuesday, June 11, 2002 8:40 AM
> To: ccamp@ops.ietf.org
> Subject: Comparision to OIF UNI discovery? RE: I-D
> ACTION:draft-lang-ccam p-lmp-bootstrap-00.txt
> 
> 
> Hi John, Jonathan and Dimitri.  How does this compare to the OIF UNI auto
> discovery.  I recall that John and Jonathan were co-authors on that
> specification.  At first glance this looks like a different approach. Do
we
> need another approach?
The OIF UNI 1.0 describes how to bootstrap in-fiber/in-band control
channels. As mentioned in this ID, a proposal for bootstraping
out-of-fiber/out-of-band control channels was originally submitted to the
OIF as oif2000.089.0, but was defered for a later version of the UNI.

This ID is basically that proposal with more details fleshed out. We decided
to submit it as an ID because of the recent interest on the list.

This proposal is consistent with the if/ib case described in UNI 1.0 and
supported in the base LMP document. (This is mentioned in the Introduction
to this ID - I'm not sure if you read introductions.)

> 
> Also this seems fairly focused on SDH/G.709 type signals, i.e., trail
traces
> and DCC channels.  ITU-T already has work underway in the form of
G.7714.1.
> A liason has already been sent to IETF from ITU-T.
> 
> It seems to me that this work is better done as part of that effort, at
> least the SDH/G.709 aspects of it, since its technology specific and
> suggests reusing channels/mechanisms that are defined for other functions
by
> the ITU-T.
In the liason, it states, "Draft new Recommendation G.7714.1, which is based
on the OIF UNI 1.0 neighbour and service discovery specification and will be
developed to meet the protocol neutral discovery requirements in
Recommendation G.7714".

Since the OIF UNI 1.0 neighbor and service discovery spec. is based on LMP,
I think it is quite appropriate to do this work where LMP is being defined. 

(I couldn't find a version of G.7714.1. If there is a current version, can
you please post it.)

-Jonathan

> 
> Greg B.
> 
> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Tuesday, June 11, 2002 4:06 AM
> To: IETF-Announce; @ops.ietf.org@ciena.com
> Cc: ccamp@ops.ietf.org
> Subject: I-D ACTION:draft-lang-ccamp-lmp-bootstrap-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: Control Channel Bootstrap for LMP
> 	Author(s)	: J. Lang, J. Drake
> 	Filename	: draft-lang-ccamp-lmp-bootstrap-00.txt
> 	Pages		: 7
> 	Date		: 10-Jun-02
> 	
> The Link Management Protocol (LMP) requires that at least one bi-
> directional control channel is established between the nodes. The 
> control channel may be transmitted either in-band with the data 
> links or out-of-band over a separate wavelength, fiber, or IP 
> network. This draft specifies a simple procedure to dynamically 
> bootstrap control channels and exchange interface mappings using a 
> new LMP message that is transmitted in-band over the data links.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-boots
trap-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-lang-ccamp-lmp-bootstrap-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.