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