FW: DISCUSS: draft-foschiano-udld
"Wijnen, Bert \(Bert\)" <[email protected]> Thu, 19 Jul 2007 17:51:09 +0200
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <[email protected]> |
=20 IEEE 802.1 and 802.3 experts and HUBMIB experts, you might be interested to know about the following=20 discussion. the document in question is: http://www.ietf.org/internet-drafts/draft-foschiano-udld-03.txt Bert Wijnen=20 HUBMIB WG chair and IETF liaison to IEEE 802.1 -----Original Message----- From: Marco Foschiano [mailto:[email protected]]=20 Sent: Thursday, July 19, 2007 7:34 AM To: Romascanu, Dan (Dan) Cc: [email protected]; Wijnen, Bert (Bert) Subject: RE: DISCUSS: draft-foschiano-udld=20 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=20 >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=20 >participants 2. That at least part of the problem and scenarios of=20 >mis-cabling that the document solves have a solution in the standard=20 >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=20 >of UDLD relative to what IEEE 802.3 ended by including in clause 57. I=20 >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=20 >it after we have the discussion in the IESG telechat with the RFC=20 >Editor and the other IESG members. > >Dan > > > > > > > -----Original Message----- > > From: Marco Foschiano [mailto:[email protected]] > > Sent: Thursday, July 19, 2007 1:16 PM > > To: Romascanu, Dan (Dan) > > Cc: [email protected]; [email protected]; [email protected] > > Subject: Re: DISCUSS: draft-foschiano-udld > > > > Dan, > > > > clause 57 of IEEE 802.3 states that "This clause defines the=20 > > Operations, Administration, and Maintenance (OAM) sublayer, which=20 > > provides mechanisms useful for monitoring link operation such as=20 > > remote fault indication and remote loopback control." > > > > As a "monitoring" and notification mechanism, clause 57 merely=20 > > includes an indication of bidirectionality (local_satisfied=3DTRUE, > > remote_stable=3DTRUE) or of unidirectionality (when the states are = not > > both TRUE) in its discovery state machine, whether it's a permanent=20 > > or transient condition. > > > > UDLD instead focuses on discovering a link that is permanently=20 > > unidirectional in order to avoid false positives during transients=20 > > and therefore be able to take permanent corrective actions in case=20 > > of non-transient link glitches. > > > > Error correction and recovery mechanisms are missing from clause 57=20 > > and are the traits that differentiate UDLD from other similar=20 > > technologies. Because of its specific nature, clause 57 can be used=20 > > in synergy with UDLD for monitoring and reporting purposes. > > > > Moreover, since the integrity of the L2 communication can have=20 > > important repercussions on any upper layer protocol, UDLD (as well=20 > > 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=20 > > 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=20 > > >standard method that I am aware about which can provide similar=20 > > >functionality in the Ethernet OAM developped for Ethernet > > First Mile, > > >as per clause 57 of IEEE 802.3. The MIB modules that cover these=20 > > >functions were developped in the IETF hubmib Working Group, which=20 > > >is now close to being concluded. I would like to ask whether the=20 > > >RFC Editor is aware of these issues and if the document underwent=20 > > >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=20 > > >standards methods to detect mis-configuration of physical cabling. > >