RE: draft-fedyk-gmpls-ethernet-pbt-00.txt

["Don Fedyk" <dwfedyk@nortel.com>]

Hi Alan 

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of alan.mcguire@bt.com
>  
> 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
These are bi-directional. The plans is OAM and protection is
bidirectional.  We should clarify in the document if it is APS.  My
opinion is it is close to APS. 
> 
> 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:
You can send me any typo fixes. 

> "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?
Yes

> 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?
We will clarify, Yes Milliseconds, Yes Y.1731. 

> 
> 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).
Yes on a service basis but also based on an any protection coordination
requirements (underlying capability). 

> 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? 
Immediate activation would be the normal approach. 
> Similarly deactivated when reoved so that there are no false alarms.
This requirement is for a graceful shutdown mode?  GMPLS does have
administrative signals but we have not looked to see if these would be
appropriate for this particular case. 

> 
> 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.
We could look at this and describe it. 


> 
> 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.
Good points we should clarify this policy. 

Thanks,
Don 

> 
> Regards,
> Alan 
> 
> 
>