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, in response to some of your points and questions:

(a) G.7714.1 is new work on automatic discovery specific to SDH/G.709
approved to move forward at the meeting in Geneva. It starts with OIF UNI
discovery as a base and will modify as appropriate.  I expect contributions
on this to come into the T1X1 meeting next week in Greensboro NC.  Maybe you
can come out and discuss. 

(b) Protocol mechanisms can be very similar but their use much different.
For example in-band/in-fiber OIF-UNI discovery only uses the
CONFIG/CONFIG_ACK with the CCID set to the port number. Periodic hellos
aren't needed (we have many ways of telling whether the DCCs are working).
Link verification isn't needed since it gets included with the
config/config-ack.  Hence this seems quite different from the intent within
the LMP draft.

(c) Concerning J0, section DCC, line DCC: Each of these is a different
mechanism with different pros and cons.  In addition, J0 and section DCC
apply at a different layer than line DCC.  This is also true for J1 (path
trace), J2 (vt path trace).  The transport network is layered and hence the
notion of "layer adjacency discovery" in G.7714 or of multi-layer discovery
as discussed in OIF2000.159v2.

(d) What mechanism to use at which layer (TTP or CTP, i.e., trail or test
signal) depends somewhat on the layers involved.  There are subtleties with
the SONET/SDH overhead and practical implementations.  For example, I'd
really like a "line trace", like we have a section trace (J0) and a path
trace (J1), but its not there.  Hence, why I think these types of
discussions belong at T1/ITU-T.

(e) I didn't see pre-OTN transparent work such as LMP and LMP-DWDM including
previously standardized technologies such as SONET, SDH and G.709.  I really
don't see LMP applying to these technologies in its current incarnation. I
think performance monitoring, fault management, automated discovery, control
channel management for these technologies belongs in a different forum.

(f) I thought that the LMP messages were going to go over UDP. The latest
draft (I've got) still says IP. Was a decision reversed?

Greg

-----Original Message-----
From: Jonathan Lang [mailto:jplang@calient.net]
Sent: Tuesday, June 11, 2002 4:06 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 3:51 PM
> To: Jonathan Lang; ccamp@ops.ietf.org
> Subject: RE: Comparision to OIF UNI discovery? RE: I-D
> ACTION:draft-lang- ccam p-lmp-bootstrap-00.txt
> 
> 
> 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).
The ID we submitted addresses the Out-of-band/out-of-fiber case. The ib/if
case is already supported in LMP today (the OIF UNI 1.0 is aligned with
LMP).

> 
> 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. 
The ID we submitted supports multiple options. J0 is but one.

> 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.
SONET/SDH & GigE are included in pre-OTN.

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

Ooops. This should be oif2000.289

Did you get a chance to post G.7714.1?

-Jonathan

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