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

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 1 Nov 2010 09:47:03 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of Rajan Rao
Sent: sabato 30 ottobre 2010 2.09
To: [email-masked]
Cc: Khuzema Pithewan; [email-masked]
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 the OTN 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

---

From: Rajan Rao <[email-masked]>
Date: Mon, 1 Nov 2010 12:11:25 -0700

John et al,

It is not clear what key issues the BA sub-TLV is solving.    The question is why RFC 4202 with simple extensions won't work?   We have shown in our draft that this can be easily done for OTN.

Thanks
Rajan

From: John E Drake [mailto:[email-masked]]
Sent: Saturday, October 30, 2010 7:24 AM
To: Rajan Rao; [email-masked]
Cc: [email-masked]; Ashok Kunjidhapatham; Khuzema Pithewan; Biao Lu; George Frank
Subject: RE: draft-bccdg-ccamp-gmpls-ospf-agnostic

Comments inline.   The point you continue to ignore is that the information in the BA could be re-encoded however the group decides.

Sent from my iPhone

From: Rajan Rao [mailto:[email-masked]]
Sent: Friday, October 29, 2010 5:09 PM
To: [email-masked]
Cc: [email-masked]; Ashok Kunjidhapatham; Khuzema Pithewan; Biao Lu; Ext - [email-masked]
Subject: draft-bccdg-ccamp-gmpls-ospf-agnostic

Authors,

JD:  The default is IEEE floating point bytes per second.  A technology specific advertisement can change the units.  ODUj is advertised with an instance count, while  ODUflex is advertised with the default.

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

JD:  SDH would be advertised using 4202, unless a technology specific SDH BA is defined.  In this case, during the transition period the nodes that understand both would probably advertise both.  Note that SDH signaling is not changed by the new BA.

JD:  Ships in the night.

JD:  No, it is necessary.  You will not have the same bandwidth at different priority levels.

Thanks
Rajan

---

From: Rajan Rao <[email-masked]>
Date: Mon, 1 Nov 2010 13:02:42 -0700

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:[email-masked]]
Sent: Monday, November 01, 2010 1:47 AM
To: Rajan Rao; [email-masked]
Cc: Khuzema Pithewan; [email-masked]
Subject: RE: draft-bccdg-ccamp-gmpls-ospf-agnostic

Hi Rajan,

BR
Daniele

[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:

   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.

 [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.

Thanks
Rajan

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 2 Nov 2010 15:57:19 +0100

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:[email-masked]]
Sent: lunedì 1 novembre 2010 21.03
To: Daniele Ceccarelli; [email-masked]
Cc: Khuzema Pithewan; [email-masked]; George Frank; Ashok Kunjidhapatham; Biao Lu
Subject: RE: draft-bccdg-ccamp-gmpls-ospf-agnostic

Daniele,

Thanks
Rajan

Hi Rajan,

BR
Daniele

   specific documents."

Thanks
Rajan

---

From: John E Drake <[email-masked]>
Date: Tue, 2 Nov 2010 08:05:17 -0700

But except at the time a link is first advertised, it is extremely unlikely that the bandwidths at multiple priorities is the same, so I don't think the complexity introduced by the bit vector is worth the cost.

Sent from my iPhone

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

Rajan,

      |                           Bandwidth                           |

      |                           Bandwidth                           |

      |                           Bandwidth                           |

      |                           Bandwidth                           |

      |                           Bandwidth                           |

      |                           Bandwidth                           |

BR
Daniele

Thanks
Rajan

Hi Rajan,

BR
Daniele

   specific documents."

Thanks
Rajan

---

From: Rajan Rao <[email-masked]>
Date: Tue, 2 Nov 2010 15:48:13 -0700

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

Rajan,

      |                           Bandwidth                           |

      |                           Bandwidth                           |

      |                           Bandwidth                           |

      |                           Bandwidth                           |

      |                           Bandwidth                           |

      |                           Bandwidth                           |

BR
Daniele

Thanks
Rajan

Hi Rajan,

BR
Daniele

   specific documents."

Thanks
Rajan

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 3 Nov 2010 02:10:13 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Rajan Rao
Sent: Tuesday, November 02, 2010 3:48 PM
To: Daniele Ceccarelli; [email-masked]
Cc: Khuzema Pithewan; [email-masked]
Subject: Re: [CCAMP] draft-bccdg-ccamp-gmpls-ospf-agnostic

Danielle, et al

2)      On Optimization:

Thanks

Rajan

Rajan,

 

BR
Daniele

Daniele,

Thanks

Rajan

Hi Rajan,

BR
Daniele

Authors,

 

 [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 <http://tools.ietf.org/id/draft-ong-ccamp-gmpls-ospf-sdh-00.txt> .

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

Thanks

Rajan

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 03 Nov 2010 15:11:51 +0800

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 ; [email-masked] 
  Cc: Khuzema Pithewan ; [email-masked] 
  Sent: Wednesday, November 03, 2010 2:10 PM
  Subject: RE: [CCAMP] draft-bccdg-ccamp-gmpls-ospf-agnostic

  HI Rajan,

  Cheers,

  Lyndon

  Danielle, et al

  2)      On Optimization:

  a) Draft-bccdg BA would require – 114 words

  b) Draft-ashok would require – 59 words  

  a)      Draft-bccdg would require – 70 words

  b)      Draft-ashok would require – 50 words 

  Thanks

  Rajan

  Rajan,

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      | 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

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

  Daniele,

  a)      Draft-bccdg BA would require – 98 words

  b)      Draft-ashok would require – 49 words  

  a)      Draft-bccdg would require – 60 words

  b)      Draft-ashok would require – 43 words 

  Thanks

  Rajan

  Hi Rajan,

  BR
  Daniele

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

  Authors,

   

  "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." 

  Thanks

  Rajan

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 3 Nov 2010 10:09:06 +0100

Fatai, Lyndon,

good point, thanks.

Rajan,
if the only problem is the number of bytes used it is possible to enhance the BA-tlv so to maximize the bandwidth utilization. I've already shown you a possible example in previous mails.
*But* such enhancement is not so simple, we need to investigate how the technology specific flags impact the bandwidth advertisement. You're making some assumptions (if i correctly understood) that could not be always true: e.g. every OTN node supports all multiplexing capabilities.
It is possible that same service type and same priority have different bandwdiths being advertised for different Technology specific flags.

If the problem is backward compatibility, it is possible to address them inserting the newly defined pieces of information into the technology specific part of the ISCD (solution already taken into account but we preferred to go for the new sub-tlv) with related bandwidth inefficiency issues due to the fact that the common part of the ISCD cannot be re-defined for ODUflex advertisement.

The first problem related to the re-definition of the ISCD common part is obviously the lost of backward compatibility and the second is related to the fact that so doing you're closing the door to possible future extensions like, for example, the definition of a second type of variable container (how would you advertise the bandwidth for ODUflexA and ODUflexB?)
Reworking RFC4202 could lead not only to bandwidth inefficiency but also to future extensions, this is one of the reasons for choosing a new sub-tlv.

Despite all these considerations, i agree with Lyndon when he says that the main concepts of the two IDs are the same.

Daniele

________________________________
From: Fatai Zhang [mailto:[email-masked]]
Sent: mercoledì 3 novembre 2010 8.12
To: Ong, Lyndon; Rajan Rao; Daniele Ceccarelli; [email-masked]
Cc: Khuzema Pithewan; [email-masked]
Subject: Re: [CCAMP] draft-bccdg-ccamp-gmpls-ospf-agnostic

Hi all,

Best Regards

Fatai

----- Original Message -----
From: Ong, Lyndon<mailto:[email-masked]>
To: Rajan Rao<mailto:[email-masked]> ; Daniele Ceccarelli<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Cc: Khuzema Pithewan<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]>
Sent: Wednesday, November 03, 2010 2:10 PM
Subject: RE: [CCAMP] draft-bccdg-ccamp-gmpls-ospf-agnostic

HI Rajan,

Cheers,

Lyndon

Danielle, et al

2)      On Optimization:

Thanks
Rajan

Rajan,

      |                           Bandwidth                           |

      |                           Bandwidth                           |

      |                           Bandwidth                           |

      |                           Bandwidth                           |

      |                           Bandwidth                           |

      |                           Bandwidth                           |

BR
Daniele

Thanks
Rajan

Hi Rajan,

BR
Daniele

   specific documents."

Thanks
Rajan

---

From: Rajan Rao <[email-masked]>
Date: Wed, 3 Nov 2010 09:59:21 -0700

Lyndon,

We completely agree on the points you have listed below.  Keeping the bits/bytes aside we are trying to understand the “agnostic” part of draft-bccdg.  As such this can be easily achieved again with extensions in SCSI.

Thanks
Rajan

From: Ong, Lyndon [mailto:[email-masked]]
Sent: Tuesday, November 02, 2010 11:10 PM
To: Rajan Rao; Daniele Ceccarelli; [email-masked]
Cc: Khuzema Pithewan; [email-masked]
Subject: RE: [CCAMP] draft-bccdg-ccamp-gmpls-ospf-agnostic

HI Rajan,

Cheers,

Lyndon

Danielle, et al

2)      On Optimization:

Thanks
Rajan

Rajan,

      |                           Bandwidth                           |

      |                           Bandwidth                           |

      |                           Bandwidth                           |

      |                           Bandwidth                           |

      |                           Bandwidth                           |

      |                           Bandwidth                           |

BR
Daniele

Thanks
Rajan

Hi Rajan,

BR
Daniele

   specific documents."

Thanks
Rajan