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

From: <[email-masked]>
Date: Thu, 6 Jul 2006 11:15:55 +0100

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

---

From: "Don Fedyk" <[email-masked]>
Date: Thu, 6 Jul 2006 15:56:36 -0400

Hi Alan 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
>  
> 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
> 
> 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 
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. 

> 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