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

[Jonathan Lang <jplang@calient.net>]

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.