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