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

[Daniele Ceccarelli <[e-mail]>]

Hi Fred,

please find answers in line.

BR and once again thanks for the careful review.
Daniele

________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of Gruman, Fred
Sent: venerdì 16 dicembre 2011 21.38
To: [e-mail]
Subject: [CCAMP] ODUflex questons for OTN OSPF, draft-ietf-ccamp-gmpls-ospf-g709v3-00

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)
[[DC]] I had the chance to speack only with some of the authors and not all, but our preference would be b. It should be easier for the head node from a computational point of view. I don't see any other difference between the two options. Is there any other one i'm missing?

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.
[[DC]] Issue already solved in the -01 version. The -01 version has not been published yet as we were waiting for the SC issue to be solved. By the way the idea was to have

      - TSG: Tributary Slot Granularity (3bit): Used for the
      advertisement of the supported Tributary Slot granularity

         - 0 - Reserved

         - 1 - 1.25 Gbps/2.5Gbps

         - 2 - 2.5 Gbps only

         - 3 - 1.25 Gbps only

         - 4 - Don't care

         - 5-7 - Reserved
[[DC]]

      Where value 1 is used on those interfaces where the fallback
      procedure is enabled and the default value of 1.25 Gbps can be
       falled back to 2.5 if needed.  Values 2 and 3 are used where there
      is no chance to modify the TSG.  In the former case the interface
      being advertised is a G.709v1 and in the latter the interface is a
      G.709v3 with fallback procedure disabled.  Value 4 is used for non
      multiplexed signal (i.e. non OTN client).



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.
[[DC]] MAY should be fine.


Thanks,
Fred