Re: [CCAMP] draft-bccdg-ccamp-gmpls-ospf-agnostic

[Fatai Zhang <[e-mail]>]

Hi all,

Good summary. Thanks, Lyndon.

If we step back to look at "draft-ceccarelli-ccamp-gmpls-ospf-g709-01", we will see that 16bits are used to encode the bandwidth (although there is some difference, the main idea is similar).

Now, the draft has evolved into "draft-ceccarelli-ccamp-gmpls-ospf-g709-04.txt" after discussion among many experts.




Best Regards
 
Fatai
 
  ----- Original Message ----- 
  From: Ong, Lyndon 
  To: Rajan Rao ; Daniele Ceccarelli ; [e-mail] 
  Cc: Khuzema Pithewan ; [e-mail] 
  Sent: Wednesday, November 03, 2010 2:10 PM
  Subject: RE: [CCAMP] draft-bccdg-ccamp-gmpls-ospf-agnostic


  HI Rajan,

   

  I think you are being rather harsh in your comments on draft-bccdg, as there are a number of points in common between the two drafts:

  -          Both propose extensions to the encoding in RFC 4202, draft-ashok puts the extensions into the switching capability-specific part of the ISCD while draft-bccdg puts the extensions into a new sub-TLV.  Moreover while draft-ashok uses the existing ISCD format, it changes the interpretation of the Maximum LSP Bandwidth to apply specifically to ODUFlex bandwidth only (if I am understanding the draft correctly)

  -          Both propose to add bandwidth on a per-signal-type basis for ODUk switching, in a form that is more suited for OTN ODUk than bytes per second

  -          Both include a field to distinguish between advertisement of Max LSP Bandwidth and Unreserved Bandwidth

   

  Draft-bccdg optimizes encoding by advertising bandwidth for only priorities that are supported, rather than always advertising a full 8 levels of priority (draft-ashok also notes the possibility of doing this using a bitmap in the Reserved field).

   

  Draft-ashok optimizes encoding by using 16 bits rather than 32 bits to encode the available bandwidth for ODUk, taking into account that ODUFlex bandwidth is advertised separately in the Max LSP Bandwidth.

   

  If we step back from the bits and bytes there is probably more agreement than disagreement between the drafts.

   

  Cheers,

   

  Lyndon

   




  From: [e-mail] [mailto:[e-mail]] On Behalf Of Rajan Rao
  Sent: Tuesday, November 02, 2010 3:48 PM
  To: Daniele Ceccarelli; [e-mail]
  Cc: Khuzema Pithewan; [e-mail]
  Subject: Re: [CCAMP] draft-bccdg-ccamp-gmpls-ospf-agnostic

   

  Danielle, et al

   

  1)      BA-sub-TLV Vs. RFC-4202 extensions:

   

  It is not clear to us on what key issues BA sub-TLV is solving. We are not hearing any strong arguments against simple extensions to RFC4202 for OTN.  

   

  2)      On Optimization:

   

  The BA format can be optimized further by reducing the size by ½ for carrying each #ODUj info (format shown below).  Two bytes can easily address the number for any imaginable future OTN extensions.  The serviceType=ODUflex can continue to use 4 byte IEEE format.

   

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

        |   Available ODUs at Prio 0    |    Available ODUs at Prio 1       |

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        |   Available ODUs at Prio 2    |    Available ODUs at Prio 3       |

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        |   Available ODUs at Prio 4    |    Available ODUs at Prio 5       |

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        |   Available ODUs at Prio 6    |    Available ODUs at Prio 7       |

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   

  Variable length container:

  Inclusion of  ODUflex (variable length container) results in the following numbers:

   

  Example-1: for an OTU4 link with 7 signal types + 8 priorities 

  a) Draft-bccdg BA would require – 114 words

  b) Draft-ashok would require – 59 words  

   

  Example-2: for an OTU4 link with 7 signal types + 5 priorities 

  a)      Draft-bccdg would require – 70 words

  b)      Draft-ashok would require – 50 words 

   

  There is still a significant different in size.  The format mentioned above (also in draft-ashok) would help close the difference.

   

  Thanks

  Rajan

   

   

  From: Daniele Ceccarelli [mailto:[e-mail]] 
  Sent: Tuesday, November 02, 2010 7:57 AM
  To: Rajan Rao; [e-mail]
  Cc: Khuzema Pithewan; [e-mail]; George Frank; Ashok Kunjidhapatham; Biao Lu
  Subject: RE: draft-bccdg-ccamp-gmpls-ospf-agnostic

   

  Rajan,

   

  the comparison carried out in section 5.0 of draft-bccgd is between the BA-tlv and an advertisement based on RFC 4203 *as defined now*, not between the BA-tlv and draft-ashok. 

  A comparison with a document which is not an RFC or not even a WG document would not be fair in my opinion, it can be done on the mailing list, but not as a section of an ID.

   

  The example you're proposing is not complete. In the last mail you sent you said:

        "There seems to be an assumption that future technologies are going to be container based, which may not be the case. 

           - We do not know how TDM (post OTN) is going to evolve.   With ODUflex kind of functionality we are already moving away from fixed containers"

  but you removed from my example the variable length container and compared the two solutions just partially, considering only 6 fixed service types.

   

  Finally, efficiency enhancements can be simply applied also to the BA-tlv. In case priorities 0,2 and 7 are supported, the BA-tlv format is:

   

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      | Service Type  | M |  T.S. Flags   |     Reserved        |Pr= 0|      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |                           Bandwidth                           |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      | Service Type  | M |  T.S. Flags   |     Reserved        |Pr= 2|      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |                           Bandwidth                           |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      | Service Type  | M |  T.S. Flags   |     Reserved        |Pr= 7|      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |                           Bandwidth                           |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ but could be easily reworked using a bitmap for priorities (1 supported, 0 not) 

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      | Service Type  | M |  T.S. Flags   |  Reserved |1|0|1|0|0|0|0|1|      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |                           Bandwidth                           |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |                           Bandwidth                           |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |                           Bandwidth                           |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

  BR
  Daniele

   


------------------------------------------------------------------------------

  From: Rajan Rao [mailto:[e-mail]] 
  Sent: lunedì 1 novembre 2010 21.03
  To: Daniele Ceccarelli; [e-mail]
  Cc: Khuzema Pithewan; [e-mail]; George Frank; Ashok Kunjidhapatham; Biao Lu
  Subject: RE: draft-bccdg-ccamp-gmpls-ospf-agnostic

  Daniele,

   

  This draft makes incorrect assumptions about size calculations in section-5.0.   We do not see any size advantage with BA approach.  In fact sizes are higher compared to SCSI extensions proposed in our draft (draft-ashok).  Here is the comparison:

   

  Example-1: for an OTU4 link with 6 signal types + 8 priorities 

  a)      Draft-bccdg BA would require – 98 words

  b)      Draft-ashok would require – 49 words  

  -          includes main ISCD + TDM-SCSI + SCSI extension for OTN

   

  Example-2: for an OTU4 link with 6 signal types + 5 priorities 

  a)      Draft-bccdg would require – 60 words

  b)      Draft-ashok would require – 43 words 

  -          includes main ISCD + TDM-SCSI + SCSI extension for OTN

   

  If we were to address backwards compatibility in BA approach, your numbers will go up by another 11 words; this is not included above.  

   

  If efficiency relating to limited number of priorities is the main concern, it can be addressed in different ways (e.g. using a bit-map as shown in section 5.4.2.1 our draft).  There is no need to repeat signal type for every priority.

   

  Thanks

  Rajan

   

  From: Daniele Ceccarelli [mailto:[e-mail]] 
  Sent: Monday, November 01, 2010 1:47 AM
  To: Rajan Rao; [e-mail]
  Cc: Khuzema Pithewan; [e-mail]
  Subject: RE: draft-bccdg-ccamp-gmpls-ospf-agnostic

   

  Hi Rajan,

   

  Thanks for your comments/questions, i see the real aim of the ID has not been properly percieved and i'd like it to be clear. Hope my replies help. Please find them in line [DC]

   

  BR
  Daniele

   


------------------------------------------------------------------------------

  From: [e-mail] [mailto:[e-mail]] On Behalf Of Rajan Rao
  Sent: sabato 30 ottobre 2010 2.09
  To: [e-mail]
  Cc: Khuzema Pithewan; [e-mail]
  Subject: [CCAMP] draft-bccdg-ccamp-gmpls-ospf-agnostic

  Authors,

   

  We are trying to understand the generalization that is described in the draft.  Here are comments/questions:

   

  1)      Service Type: There seems to be an assumption that future technologies are going to be container based, which may not be the case.  

  -          We do not know how TDM (post OTN) is going to evolve.   With ODUflex kind of functionality we are already moving away from fixed containers. 

  [DC] -There is no such assumption. Advertising the service type using a 32bits field allows for advertising any type of bandwidth (e.g. unreserved, max LSP)  in Bytes/sec using IEEE floating point. This means that not only container based service types can be advertised but any type of service (like for example MPLS-TP). The ID states that:

   

   

  "o Bandwidth (32 bits): Independently on the type of bandwidth being   advertised (see M field), this field is expressed in Bytes/sec in   IEEE floating point format unless differently stated in technology   specific documents." 

  Then theOTN specific ID already addressed the case of non fixed containers stating that the unreserved bandwdith for OTN is advertised in number of ODUs when fixed containers are advertised and in Bytes/sec when ODUflex is being advertised.

  2)      If a customer deploys hybrid NEs that supports both SNET + OTN, what is advertised by each NE?

  -          SONET BW using BA or use RFC 4202 way? 

   [DC] -There is a SONET/SDH specific ID defining BA sub-TLV technology specific extensions, please have a look at it: http://tools.ietf.org/id/draft-ong-ccamp-gmpls-ospf-sdh-00.txt.

  3)      If we introduce OTN box into a Sonet network, what is the expected behavior?

  -          Say Sonet is using RFC 4202 based BW advertisement 

  [DC] - It is quite an extreme scenario in my opinion, but backward compatibility can be easily achieved having a "new" node advertising bandwidth using both BA-tlv and RFC4202 formats (the amount of information advertised via RFC4202 is not much, it would not affect the network scalability). 

  4)      Repeating signal type for each priority is inefficient.   

  [DC] - It would be inefficient if all the 8 priorities were advertised (as RFC4204 does), but they aren't. Only supported priorities are advertised. This increases efficiency a lot. An example is shown in the applicability section:

  http://tools.ietf.org/html/draft-bccdg-ccamp-gmpls-ospf-agnostic-00#section-5

   

  Thanks

  Rajan