[CCAMP] ODUflex questons for OTN OSPF, draft-ietf-ccamp-gmpls-ospf-g709v3-00

["Gruman, Fred" <[e-mail]>]

Hi Daniele,

 

I have a few questions on the advertisement of ODUflex.

 

1) For the advertisement of the Max LSP Bandwidth of the ODUflex(CBR)
signal type, it is not clear how the Max LSP BW should be computed.
Specifically, should the BW advertisement take into account the HO-OPU
bit rate tolerance?  I see a couple of possibilities:

  a. Max LSP BW ODUflex (CBR) = (# available TS) * (ODTUk.ts nominal bit
rate)

  b. Max LSP BW ODUflex (CBR) = (# available TS) * (ODTUk.ts nominal bit
rate) * (1-HO OPUk bit rate tolerance)

  

If bit rate tolerance is not accounted in the BW advertisement, then the
path computation function would need to adjust for this factor based on
an implicit assumption of the tolerance, which is 20 ppm for the HO OPUk
supported at this time.

 

In general, it would be nice to have examples of the Max LSP BW for
ODUflex(CBR) and ODUflex(GFP).

 

2) It is my understanding that the TSG bits indicate the tributary slot
granularity when the ODUk serves as a HO-ODU. It is not clear how to
fill in the TSG field for those ODUk signal types that do not support
the muxing of LO-ODU. This would apply to ODU0, ODU2e and ODUflex.
Should the field be set to 00 (currently reserved) or a different value?

 

There was a more general question on if this field was still needed on a
per signal type. Given that link bundling requires the same multiplexing
hierarchy across all links in the bundle, does the need for this field
go away. Or do we foresee that there could be cases where different TSG
could be supported in different levels of the multiplexing hierarchy.

 

3) For a link that supports the 3 types of ODUflex (CBR, GFP-resizable,
GFP-non-resizable), an implementation would need to advertise the Max
LSP BW and Unreserved BW against signal types of 20, 21, and 22. For
efficiency, is it permitted for implementations that support both
GFP-resizable and GFP-non-resizable, they MAY advertise the BW under the
resizable signal type (21) and have it implicitly understood that it
also supports GFP-non-resizable with the same BW.  (Note that
implementations could advertise them separately, especially if the BW
were different).  Or MUST implementations advertise GFP-resizable
(ST=21) and GFP-non-resizable (ST=22) explicitly.

 

Thanks,

Fred