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: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On Behalf Of Rajan Rao
Sent: sabato 30 ottobre 2010 2.09
To: draft-bccdg-ccamp-gmpls-ospf-agnostic <at> tools.ietf.org
Cc: Khuzema Pithewan; ccamp <at> ietf.org
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