draft-fedyk-gmpls-ethernet-pbt-00.txt
<alan.mcguire@bt.com> Thu, 06 July 2006 10:24 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyR1o-0004sc-IP for ccamp-archive@ietf.org; Thu, 06 Jul 2006 06:24:12 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyR1m-0004kk-27 for ccamp-archive@ietf.org; Thu, 06 Jul 2006 06:24:12 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1FyQtr-000JYy-Jo for ccamp-data@psg.com; Thu, 06 Jul 2006 10:15:59 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1
Received: from [217.32.164.137] (helo=smtp1.smtp.bt.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from <alan.mcguire@bt.com>) id 1FyQtr-000JYi-2V for ccamp@ops.ietf.org; Thu, 06 Jul 2006 10:15:59 +0000
Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 11:15:57 +0100
Received: from I2KM11-UKBR.domain1.systemhost.net ([193.113.197.28]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 11:15:56 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: draft-fedyk-gmpls-ethernet-pbt-00.txt
Date: Thu, 06 Jul 2006 11:15:55 +0100
Message-ID: <91A1302378CDCE41A2B8229D0BA7E5D50712E0B6@I2KM11-UKBR.domain1.systemhost.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-fedyk-gmpls-ethernet-pbt-00.txt
Thread-Index: AcaZLe5yO/C0CMCSQuC/mY0ecCDxpAACFi0QAMp1WpAAYDN3sACXBtLQ
From: alan.mcguire@bt.com
To: ccamp@ops.ietf.org, gels@rtg.ietf.org, dwfedyk@nortel.com
X-OriginalArrivalTime: 06 Jul 2006 10:15:56.0632 (UTC) FILETIME=[2B9D4580:01C6A0E5]
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Don, I think that you and your co-authors have produced a very good draft. It provides a concise description of the PBT concept and how the control plane can be employed. It also covers the main areas that need to be addressed Some observations and comments. For the protection options it would be useful to indicate if the schemes are undirectional, bidirectional, with APS or without, or whether there are any restrictions on use of these. It might also be useful to indicate how the VID's are allocated in each scheme, e.g. different VLAN Ids for each path in 1:1 There are a number of minor typo's (can send you a list) but the following one should be clarified for the group in relation to section 8.1: "In the case of CCM OAM cells the detection time is a typically 3.5 the CCM interval + the propagation delay from the fault" Are you refering to the fast detection interval for CCM frames? In which case this should be in ms. Also think it should be 3.3 ms, though would suggest you check latest version of Y.1731. Or do you mean something else? You state that the OAM parameters are tunable. I would expect that in most cases for the same service the OAM parameters would be the same (though potentially different for different services). Would you anticiptate that when a network operator sets up a path that the OAM parameters for that type of path are already known when the path is setup so that the OAM is immediately active, rather than being post setup activated? Similarly deactivated when reoved so that there are no false alarms. It would be helpful to add something about CAC and traffic engineering. When there is no over-subscription or partitioning of the VLAN space there is really nothing new to add. However, if the VID space is partitioned it would be useful to make some observations about how bandwidth is allocated/enforced between the different schemes. VLAN IDs are allocated to PBT or for other purposes. Would be useful to explicitly indicate if there any VLAN IDs that cannot be used in PBT. E.g. VLAN zero, VLAN 4095. When VLAN ID ranges are allocated to PBT are there any rules regarding this allocation on a per end point basis. For example can different endpoints have different VLAN ranges. If not then some scheme is required to achieve this, e.g. management. Regards, Alan
- draft-fedyk-gmpls-ethernet-pbt-00.txt Don Fedyk
- Re: draft-fedyk-gmpls-ethernet-pbt-00.txt Igor Bryskin
- RE: draft-fedyk-gmpls-ethernet-pbt-00.txt Don Fedyk
- Re: draft-fedyk-gmpls-ethernet-pbt-00.txt Igor Bryskin
- RE: draft-fedyk-gmpls-ethernet-pbt-00.txt Don Fedyk
- RE: draft-fedyk-gmpls-ethernet-pbt-00.txt Lucy Yong
- RE: draft-fedyk-gmpls-ethernet-pbt-00.txt Don Fedyk
- RE: draft-fedyk-gmpls-ethernet-pbt-00.txt Lucy Yong
- RE: draft-fedyk-gmpls-ethernet-pbt-00.txt Don Fedyk
- RE: draft-fedyk-gmpls-ethernet-pbt-00.txt Dimitri.Papadimitriou
- RE: draft-fedyk-gmpls-ethernet-pbt-00.txt Dimitri.Papadimitriou
- RE: draft-fedyk-gmpls-ethernet-pbt-00.txt Don Fedyk
- RE: draft-fedyk-gmpls-ethernet-pbt-00.txt Don Fedyk
- RE: draft-fedyk-gmpls-ethernet-pbt-00.txt Dimitri.Papadimitriou
- RE: draft-fedyk-gmpls-ethernet-pbt-00.txt Nurit Sprecher
- Re: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt YongLucy 73674
- draft-fedyk-gmpls-ethernet-pbt-00.txt alan.mcguire
- RE: draft-fedyk-gmpls-ethernet-pbt-00.txt Don Fedyk