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

[Daniele Ceccarelli <[e-mail]>]

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:[e-mail]]
Sent: mercoledì 3 novembre 2010 8.12
To: Ong, Lyndon; Rajan Rao; Daniele Ceccarelli; [e-mail]
Cc: Khuzema Pithewan; [e-mail]
Subject: Re: [CCAMP] draft-bccdg-ccamp-gmpls-ospf-agnostic

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<mailto:[e-mail]>
To: Rajan Rao<mailto:[e-mail]> ; Daniele Ceccarelli<mailto:[e-mail]> ; [e-mail]<mailto:[e-mail]>
Cc: Khuzema Pithewan<mailto:[e-mail]> ; [e-mail]<mailto:[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


[cid:297163408@03112010-2339]
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