From yann.baud@schmid-telecom.ch Thu Nov 18 03:04:25 2010 Return-Path: X-Original-To: hubmib@core3.amsl.com Delivered-To: hubmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7AB3A6813 for ; Thu, 18 Nov 2010 03:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.441 X-Spam-Level: X-Spam-Status: No, score=0.441 tagged_above=-999 required=5 tests=[AWL=1.550, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hF8y1YuFwzgC for ; Thu, 18 Nov 2010 03:04:25 -0800 (PST) Received: from mail.schmid-telecom.ch (mail.schmid-telecom.ch [213.173.183.22]) by core3.amsl.com (Postfix) with ESMTP id 710263A681D for ; Thu, 18 Nov 2010 03:04:24 -0800 (PST) Received: from szexchange.schmid-telecom.com [10.100.100.66] by mail.schmid-telecom.ch with XWall v3.40 ; Thu, 18 Nov 2010 12:05:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB8710.779F471B" Date: Thu, 18 Nov 2010 12:05:09 +0100 Message-ID: <14D81EC6B257AC4AA681E4969BCC58BE01B8F05D@szexchange.schmid-telecom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hubmib] RFC 5066 Comment on PME initialization and aggregation Thread-Index: AcuHEHcXNLG6FwzvT1O4to4XqANPOw== From: "Baud, Yann" To: Subject: [Hubmib] RFC 5066 Comment on PME initialization and aggregation X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 11:06:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB8710.779F471B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I wish to comment on the penultimate paragraph of RFC 5066 section 3.1.3: =20 *Quoted* Note that the PCS port does not have to be operationally 'down' for the connection to succeed. In fact, a dynamic PME addition (and removal) MAY be implemented with an available PME being initialized first (by setting its ifAdminStatus to 'up') and then added to an operationally 'up' PCS port, by modifying a respective ifStackTable (and respective ifInvStackTable) entry. =20 In fact, PME addition to a PCS is impossible once the PME has been initialized, because the discovery and aggregation phases, which are done using ITU-T G.994.1 (G.Hs), must occur before PME training and activation in the PME initialization process. Once the PME is initialized, it is impossible=20 to configure the aggregation on the peer pme (IEEE 802.3 2008 61.4.7). =20 I would much welcome a clarification on this paragraph. =20 Best Regards, Yann ------_=_NextPart_001_01CB8710.779F471B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I wish to = comment on the=20 penultimate paragraph of RFC 5066 section 3.1.3:

*Quoted*

Note=20 that the PCS port does not have to be operationally 'down'=20 for

    the=20 connection to succeed. In fact, a dynamic PME addition=20 (and
    removal) MAY be implemented with an available = PME=20 being initialized
    first (by setting its = ifAdminStatus to=20 'up') and then added to an
    operationally 'up' PCS = port, by=20 modifying a respective ifStackTable
    (and = respective=20 ifInvStackTable) entry.

In fact, PME = addition to a=20 PCS is impossible once the PME has been initialized, = because

the discovery = and=20 aggregation phases, which are done using ITU-T G.994.1 = (G.Hs), must=20 occur before PME training and

activation in = the PME=20 initialization process. Once the PME=20 is initialized, it is impossible

to configure = the=20 aggregation on the peer pme (IEEE 802.3 2008 = 61.4.7).

I would much = welcome a=20 clarification on this paragraph.

Best=20 Regards,

Yann

------_=_NextPart_001_01CB8710.779F471B--