[Hubmib] FW: DISCUSS: draft-foschiano-udld

"Wijnen, Bert \(Bert\)" <bwijnen@alcatel-lucent.com> Thu, 19 July 2007 15:51 UTC

Return-path: <hubmib-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYIA-00010Y-2M; Thu, 19 Jul 2007 11:51:50 -0400
Received: from hubmib by megatron.ietf.org with local (Exim 4.43) id 1IBYI8-00010C-Cw for hubmib-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 11:51:48 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYI8-000104-28 for hubmib@ietf.org; Thu, 19 Jul 2007 11:51:48 -0400
Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBYI7-0004Te-7L for hubmib@ietf.org; Thu, 19 Jul 2007 11:51:47 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6JFpTVw019393; Thu, 19 Jul 2007 10:51:37 -0500 (CDT)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 10:51:14 -0500
Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 17:51:10 +0200
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 19 Jul 2007 17:51:09 +0200
Message-ID: <D4D321F6118846429CD792F0B5AF471F7E58E1@DEEXC1U02.de.lucent.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: DISCUSS: draft-foschiano-udld
Thread-Index: AcfKEiDYjXhHPOItT5+DOLvHof2BBAAB50fw
From: "Wijnen, Bert (Bert)" <bwijnen@alcatel-lucent.com>
To: STDS-802-1-L@listserv.ieee.org, STDS-802-3@listserv.ieee.org, hubmib@ietf.org
X-OriginalArrivalTime: 19 Jul 2007 15:51:10.0107 (UTC) FILETIME=[A0537EB0:01C7CA1C]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Cc: dromasca@avaya.com, foschia@cisco.com, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Hubmib] FW: DISCUSS: draft-foschiano-udld
X-BeenThere: hubmib@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Ethernet Interfaces an Hub MIB WG <hubmib.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/hubmib>, <mailto:hubmib-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:hubmib@ietf.org>
List-Help: <mailto:hubmib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/hubmib>, <mailto:hubmib-request@ietf.org?subject=subscribe>
Errors-To: hubmib-bounces@ietf.org

 
IEEE 802.1 and 802.3 experts and HUBMIB experts,
you might be interested to know about the following 
discussion. the document in question is:

   http://www.ietf.org/internet-drafts/draft-foschiano-udld-03.txt

Bert Wijnen 
HUBMIB WG chair and IETF liaison to IEEE 802.1

-----Original Message-----
From: Marco Foschiano [mailto:foschia@cisco.com] 
Sent: Thursday, July 19, 2007 7:34 AM
To: Romascanu, Dan (Dan)
Cc: iesg@ietf.org; Wijnen, Bert (Bert)
Subject: RE: DISCUSS: draft-foschiano-udld 

Thanks, Dan.

I agree it's a good clarification to add to the document.
I will follow the editor's directions w.r.t. any new edits/additions.

Regards,

Marco

At 07:14 AM 7/19/2007, Romascanu, Dan (Dan) wrote:
>Marco,
>
>Thank you for your answer.
>
>I should probably clarify that I issued the DISCUSS in order to make 
>sure that the RFC Editor and the other IESG members are aware about the

>following issues:
>
>1. That this document focuses on a technology at a layer that is out of

>the IETF scope and field of expertise of the majority of the IETF 
>participants 2. That at least part of the problem and scenarios of 
>mis-cabling that the document solves have a solution in the standard 
>space of another standards organization
>
>(I am a long time participant in IEEE 802, and I was a voting member of

>IEEE 802.3 during the period when IEEE 802.3ah - EFM was written)
>
>Your clarification below is useful as it shows what is the added value 
>of UDLD relative to what IEEE 802.3 ended by including in clause 57. I 
>would recommend that such text is made part of the document, but I will

>not hold the DISCUSS for this purposes. Actually I will probably clear 
>it after we have the discussion in the IESG telechat with the RFC 
>Editor and the other IESG members.
>
>Dan
>
>
>
>
>
> > -----Original Message-----
> > From: Marco Foschiano [mailto:foschia@cisco.com]
> > Sent: Thursday, July 19, 2007 1:16 PM
> > To: Romascanu, Dan (Dan)
> > Cc: foschia@cisco.com; iesg@ietf.org; bwijnen@alcatel-lucent.com
> > Subject: Re: DISCUSS: draft-foschiano-udld
> >
> > Dan,
> >
> > clause 57 of IEEE 802.3 states that "This clause defines the 
> > Operations, Administration, and Maintenance (OAM) sublayer, which 
> > provides mechanisms useful for monitoring link operation such as 
> > remote fault indication and remote loopback control."
> >
> > As a "monitoring" and notification mechanism, clause 57 merely 
> > includes an indication of bidirectionality (local_satisfied=TRUE,
> > remote_stable=TRUE) or of unidirectionality (when the states are not

> > both TRUE) in its discovery state machine, whether it's a permanent 
> > or transient condition.
> >
> > UDLD instead focuses on discovering a link that is permanently 
> > unidirectional in order to avoid false positives during transients 
> > and therefore be able to take permanent corrective actions in case 
> > of non-transient link glitches.
> >
> > Error correction and recovery mechanisms are missing from clause 57 
> > and are the traits that differentiate UDLD from other similar 
> > technologies. Because of its specific nature, clause 57 can be used 
> > in synergy with UDLD for monitoring and reporting purposes.
> >
> > Moreover, since the integrity of the L2 communication can have 
> > important repercussions on any upper layer protocol, UDLD (as well 
> > as clause 57 monitoring and reporting
> > capabilities) can be relevant in a
> > L3/L4 context as well. UDLD is indeed used in those contexts today 
> > and is not limited to pure L2 networks.
> >
> > Marco
> >
> >
> > At 04:19 PM 7/18/2007, Dan Romascanu wrote:
> > >Discuss:
> > >This document is documenting a Ethernet OAM function that
> > has little if
> > >nothing to do with the IETF scope. Moreover, there is at least one 
> > >standard method that I am aware about which can provide similar 
> > >functionality in the Ethernet OAM developped for Ethernet
> > First Mile,
> > >as per clause 57 of IEEE 802.3. The MIB modules that cover these 
> > >functions were developped in the IETF hubmib Working Group, which 
> > >is now close to being concluded. I would like to ask whether the 
> > >RFC Editor is aware of these issues and if the document underwent 
> > >an appropriate IEEE 802 expert review. At a least I would
> > suggest that a
> > >mention is made in the text of the document about the existence of 
> > >standards methods to detect mis-configuration of physical cabling.
> >


_______________________________________________
Hubmib mailing list
Hubmib@ietf.org
https://www1.ietf.org/mailman/listinfo/hubmib