Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04

From: Lou Berger <[email-masked]>
Date: Thu, 03 Jan 2013 16:51:06 -0500

Hi Fatai,
	Happy new year.  Please see below for responses.

On 12/25/2012 3:33 AM, Fatai Zhang wrote:
>
> Hi Lou,
>
> Please see in-line below.
>
> A new version will be issued after all open issues are resolved.
>
>
>
>
>
> Best Regards
>
> Fatai
>
>
> -----Original Message-----
>> From: Lou Berger [mailto:[email-masked]]
>> Sent: Thursday, December 20, 2012 10:12 PM
>> To: Fatai Zhang
>> Cc: CCAMP; [email-masked]
>> Subject: Re: 答复: [CCAMP] WG Last Call comments on
draft-ietf-ccamp-gmpls-signaling-g709v3-04
>>
>> Fatai/Authors,
>>          Thank you for the mail, and sorry about my delayed response. BTW
>> please feel free to continue discussing the remaining open issues on the
>> list and reaching closure on the list (on specific text/resolutions)
>> prior to publishing the next rev.
>>
>> Please see below for inline responses.
>>
>> On 12/7/2012 4:53 AM, Fatai Zhang wrote:
>>> Hi Lou,
>>>
>>> Please see how the LC comments addressed below.
>>>
>>>
>>>
>>>
>>>
>>> Best Regards
>>>
>>> Fatai
>>>
>>>
>>> -----邮件原件-----
>>> 发件人: [email-masked] [mailto:[email-masked]] 代表
Lou Berger
>>> 发送时间: 2012年10月22日 10:01
>>> 收件人: CCAMP; [email-masked]
>>> 主题: [CCAMP] WG Last Call comments on
draft-ietf-ccamp-gmpls-signaling-g709v3-04
>>>
>>> Authors,
>>>     I have the following LC comments:
>>>
>>> General comments:
>>>
>>> - This document also needs some addition work on conformance language.
>>> I'll try to point out cases in the detailed comments below.
>>>
>> [Fatai] OK. Checked and refined based on your detailed comments.
>>>
>>
>> I think this rev is an improvement, but there's still more work needed.
>> I have made some specific comments/suggestions below.
>>
>>> - Section 5 essentially defines a new set of traffic parameters.  Given
>>> the changes, why not ask for a new C-TYPE and not worry about [RFC4328]
>>> compatibility/description?
>>>
>> [Fatai] Accepted to have a new C-TYPE and updated the text accordingly.
>>>
>>
>> Okay.
>>
>>> Detailed editorial and technical comments:
>>>
>>> - Please verify that abbreviations are defined before being used .
>>> There are a number of these.
>>>
>> [Fatai] Went through and updated.
>>
>> thanks.
>>
>>>
>>> - Please use a consistent decimal representation (sometimes commas are
>>> used other times periods)
>>>
>> [Fatai] OK. Commas are used.
>>
>> great, although a quick skim finds:
>> s/1,301.683.217/1,301,683.217
>>
>>
>>
>>>
>>> - the references [G709-v1] and [G709-v3] each actually refer to multiple
>>> documents, each documented needs to have it's own (correct) reference,
>>> i.g., [G709-v1] and [G709-v1a1]. The document text will need to be
>>> revisited to ensure the proper reference is made.
>>>
>> [Fatai] Accepted and used the same approach for framework draft.
>>
>> great
>>
>>
>>> -
>>>
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-signaling-g709v3-04.txt
>>> shows there are unresolved nits that need to resolved .
>>
>>
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-signaling-g709v3-05.txt
>> still shows a warning, notably:
>>
>>      (Using the creation date from RFC4328, updated by this document, for
>>      RFC5378 checks: 2005-01-17)
>>
>>   -- The document seems to lack a disclaimer for pre-RFC5378 work,
but may
>>      have content which was first submitted before 10 November 2008.
 If you
>>      have contacted all the original authors and they are all willing
to grant
>>      the BCP78 rights to the IETF Trust, then this is fine, and you
can ignore
>>      this comment.  If not, you may need to add the pre-RFC5378
disclaimer.
>>      (See the Legal Provisions document at
http://trustee.ietf.org/license-info for more information.)
>>
> [Fatai] Will update “Copyright Notice” section.

okay

>>
>>> I'm using line
>>> numbers from this url in my subsequent comments.
>>>
>> [...]
>>
>>> - Section 3.  Perhaps combine with section 1.
>>>
>> [Fatai] Accepted and refined.
>>>
>>
>> I don't see where this suggestion was followed, but that's okay, it was
>> just a suggestion.
>>
> [Fatai] OK.
>>
>> [...]
>>> - Section 5: assuming this is now a new c-type need text for that, as
>>> well as to formally defined the fields/field sizes.
>>>
>> [Fatai] Accepted to have a new C-TYPE and updated the text accordingly.
>>
>> Formal field definitions are missing and need to be added.
>>

> [Fatai] The format is the same as RFC4328. Did you mean that it
> needs “Length”, “Class-Num” and “C-Type”? If yes, I will add
> them. If you mean that it needs text to define all the fields, I
> think the text is already there (then this comment may be related
> to your other comments below).

Its important to differentiate the syntax (i.e., format) from the
semantics (i.e., usage).  How about:

Signal Type: 8 bits
   As defined in [RFC4328] Section 3.2.1, with the following additional
values:
  (insert lines 266-285)

Reserved: 8 bits
   As defined in [RFC4328] Section 3.2.5.

Tolerance: 16 bits
   (insert lines 296-298)

NVC: 16 bits
   As defined in [RFC4328] Section 3.2.3.

Multiplier (MT): 16 bits
   As defined in [RFC4328] Section 3.2.4.

Bit_Rate: 32 bits
   (insert lines 290-294)

The other parts, lines 287-288, 300-319 should be merged into section 5.1.

>>
>> Also the draft says:
>>
>>    Note that the error process on the traffic parameters MUST follow the
>>    rules defined in Section 6 of [RFC4328].
>>
>> Given the different fields, shouldn't any OTN-TDM related traffic
parameter processing now be defined in this document?
>>
> [Fatai] I just wanted to avoid the overlapped text (almost the same
text as RFC4328). Will accept your suggestion to expand the text as follows:
>
> There is no Adspec associated with the OTN-TDM SENDER_TSPEC. Either
> the Adspec is omitted or an Int-serv Adspec with the Default General
> Characterization Parameters and Guaranteed Service fragment is used,
> see [RFC2210].
>
> For a particular sender in a session, the contents of the FLOWSPEC
> object received in a Resv message SHOULD be identical to the contents
> of the SENDER_TSPEC object received in the corresponding Path
> message. If the objects do not match, a ResvErr message with a
> "Traffic Control Error/Bad Flowspec value" error SHOULD be generated.
>
> Intermediate and egress nodes MUST verify that the node itself, and
> the interfaces on which the LSP will be established, can support the
> requested Signal Type, NVC, Tolerance and Bit_Rate values. If the
> requested value(s) cannot be supported, the receiver node MUST
> generate a PathErr message with a "Traffic Control Error/Service
> unsupported" indication (see [RFC2205]).
>
> In addition, if the MT field is received with a zero value, the node
> MUST generate a PathErr message with a "Traffic Control Error/Bad
> Tspec value" indication (see [RFC2205]).
>

Is this a new section, perhaps 5.3?

>>
>>>
>> [...]
>>>
>>> - Lines 320-336,338-346 are essentially repeated in sections 5.1 and
>>> 5.2, why not move this text into their respective sections?
>>>
>> [Fatai] Accepted and refined the text.
>>
>>
>> I don't see where this suggestion was followed. For example:
>>
>> 287  In case of ODUflex(CBR), the Bit_Rate and Tolerance fields MUST be
>> 288  used together to represent the actual bandwidth of ODUflex, where:
>>
>> and
>>
>> 323  In case of ODUflex(CBR), the information of Bit_Rate and
Tolerance in
>> 324  the ODUflex traffic parameters MUST be used to determine the total
>> 325 number of tributary slots N in the HO ODUk link to be reserved. Here:
>>
> [Fatai] Sorry I should not say “Accepted and refined the text.”
> last time. They are not repeated. here, the text just describes the
> meaning of the corresponding fields (as we always do), so the above
> text should be there irrespectively. Section 5.1 & section 5.2
> describe “how” with more detail information including formulation,
> Table information and example.
>
If the text in the early part of 5 is revised as I suggest above (and
the other lines are merged as suggested above) then this comment will be
resolved.

>>
>>>
>>> - lines 445-468: Why not just carry "n" directly?
>>>
>> [Fatai] to make it consistent with ODUflex(CBR).
>>
>> Given that the recent decision to have an OTN-TDM specific set of
>> traffic parameters, doesn't it now make sense to just carry N directly?
>>
> [Fatai] No. “N” cannot be used for ODUflex(CBR) case.

Do you really mean "cannot"?  I may be missing something, but it would
seem less ambiguous/prone to interop issues if N was directly carried.

> It is better
> to have consistent format and the same meaning of one field for both
> ODUflex(CBR) and GFP. This is why we have section 5.1 &5.2 to
> describe the complex stuff.
>

I actually wasn't suggesting that N be carried in the bit rate field.
The bit rate field can either be set as described or to zero (i.e.,
ignored).  At the time, I was thinking about carrying N in the reserved
field. But perhaps the right place is MT, if my understanding is right
(would always be 1 otherwise). I'm open to either...

>>
>> [...]
>>
>>>
>>> - Line 576: "Padded bits" seems off, how about "Pad bits" or "Padding",
>>
>> Again, how about "Pad bits" or "Padding"?
>>
> [Fatai] OK. Should use “Pad bits” instead of “Padding bits”

“Pad bits” it is...

>>
>>> also bits aren't represented in label format (line 494)., also "behind"
>>> --> "after"
>>>
>> [Fatai] Accepted and updated.
>>>
>>
>> [...]
>>
>>>
>>> - Lines 658-660.  The normative language in 4328 isn't actually
>>> presented in the section titled "label distribution procedures" (or
>>> "rules" as section 4.2 is actually titled), so this paragraph doesn't
>>> make sense.  I suggest either (a) defining the full set of required
>>> procedures in this document, or (b) referring to the "required
>>> processing defined in [RFC4328]" and other rfcs as appropriate.
>>>
>> [Fatai] Accepted and updated accordingly.
>>>
>>> - Lines 662-667: what about generating upstream, suggested, label set,
>>> etc.  Perhaps you should rephrase much into more general rules.
>>>
>> [Fatai] Accepted and updated accordingly.
>>>
>>
>> I think section 6.2 still needs a bit of work.
>>
>> So are there procedures that an ingress must follow?
>> For example:
>> - Setting of fields in the label request object, such as the OTN-TDM
>> Switching Type defined in [OTN-OSPF].
>>
>> What about the egress, are there any special procedures?
>>
>> The final three paragraphs of the section introduce upstream behaviors
>> *after* you've described the downstream behavior without specifics of
>> the new upstream behavior. As a general rule and in this case in
>> particular, I really think it would be better to cover procedures in the
>> following order
>> - Ingress
>> - Generic upstream
>> - Generic downstream
>> - Egress
>>
>> Also, generic statements should not use conformance language,
>> particularly when more detailed rules/procedures, which include such
>> language, follow.
>>
>> If you'd like we can discuss/review details on the list once you have a
>> proposed revision. (I see a bunch of more minor comments on this
>> section, but don't think it makes sense to focus on these until the more
>> major comments are addressed.)
>>
> [Fatai] Will refine the text based on your suggestion. Do I need to
> copy so much text here for review?

It's up to you, but personally, I think it's better to discuss the text
on the list first rather than publishing and then discuss/wordsmith.
But this is just a personal preference.  Either way works. (draft
revision numbers are cheap after all.)

>>
>>
>> [...]
>>>
>>> - Lines 682-685: Who is this learning/identification accomplished?
>>>
>> [Fatai] Accepted and updated.
>>>
>>> - Lines 703-704: If this is the normative section defining requirement
>>> processing, the procedures need to be spelled out for all required
cases.
>>>
>> [Fatai] Accepted and updated accordingly.
>>>
>>> - Lines 706-707: I think this needs to be rephrased to be clear what
>>> behavior is required for a node to be conformant with this sentence.
>>>
>> [Fatai] Accepted and refined accordingly.
>>>
>>> - Lines 711-714: why "SHOULD" vs "MUST"?
>>>
>> [Fatai] Accepted and updated.
>>>
>>
>> I'll defer responses to the discussion on prior comment.
>>
>>> - Line 712: By "integrity of the label" do you mean "if the label is
>>> acceptable"?
>>>
>> [Fatai] Yes, and updated.
>>>
>>>
>>> - Line 725: By "reserved resource" do you mean "indicated resource"?
>>>
>> [Fatai] Yes, and updated.
>>>
>>> - Line 726: Does "do not match" mean "inconsistent"?
>>>
>> [Fatai] Yes, and updated.
>>
>> WRT lines 624-627, I think you still need additional specificity
>> differentiate upstream/downstream required behavior. Perhaps something
>> along the lines of:
>>
>>     When an upstream node receives a Resv message containing an

s/an/a

>>     LABEL object with an OTN-TDM label, the node MUST verify that
>>     the label is acceptable. If the label is not acceptable, the
>>     node MUST generate a ResvErr message with a "Routing
>>     problem/Unacceptable label value" indication.  Per [RFC3473],
>>     the generated ResvErr message MAY include an
>>     ACCEPTABLE_LABEL_SET object.  With the exception of label
>>     semantics, Downstream node processing a received ResvErr
>>     messages and of ACCEPTABLE_LABEL_SET objects is not modified
>>     by this document.
>>
>>     Similarly, when a downstream node receives a Path message
>>     containing an UPSTREAM_LABEL object with an OTN-TDM label,
>>     the node MUST verify that the label is acceptable. If the
>>     label is not acceptable, the node MUST generate a PathErr
>>     message with a "Routing problem/Unacceptable label value"
>>     indication.  Per [RFC3473], the generated ResvErr message MAY
>>     include an ACCEPTABLE_LABEL_SET object.  With the exception
>>     of label semantics, Downstream node processing received
>>     PathErr messages and of ACCEPTABLE_LABEL_SET objects is not
>>     modified by this document.
>>
>>     A received label SHALL be considered unacceptable when one of
>>     the following cases occurs:
>>
>>     - The received label doesn't conform with local policy.
>>
> [Fatai] OK. Accept your proposed text.
>>     ...
>>
>>>
>>> - Line 730, Drop "As".
>>>
>> [Fatai] Accepted and updated.
>>>
>>> - Section 6.4: Missing conformance language.
>>>
>> [Fatai] Went through and updated.
>>
>> New line 660:   The procedures are similar to section 6 of [RFC6344].
>>
>> Hereto,  If this is the normative section defining required processing,
>> the procedures need to be spelled out for all required cases or refer to
>> specific (and unmodified) procedures to follow in a reference document.
>> So either define the processing or say procures defined in <appropriate
>> reference> are followed.
>>
> [Fatai] OK, I think it is better to say “The procedures MUST follow
> Section 5 of [RFC6344].”

Are there any procedures defined in section6.3 that differ/add to 6344?
 If I'm not mistaken, the only thing is that ODUflex signal types cannot
use "multiplication". (Please confirm.)

Assuming I'm correct, how about replacing the contents of the section
with something along the lines of:

   Support for Virtual Concatenation, as defined by [RFC6344], is not
   modified by this document. With the exception of ODUflex signal
   types, signal multiplication as defined in [RFC6344] and [RFC4328].

>>
>>>
>>> - Lines 758-759: This reads like an informative statement, but includes
>>> conformance language.  How does a node conform?  I suggest rephrasing to
>>> be clear.
>>>
>> [Fatai] Accepted and updated.
>>>
>>
>> I think this section should be revised to ensure that the
>> responsibilities of each type of processing node (ingress, upstream,
>> downstream, egress) is clear.
>>
>> I guess, we'll have a thread on this section too...
>>
> [Fatai] Will refine the text based on your suggestion.

great.

>>
>> [...]
>>
>>>
>>> - Section 9, should also reference 4328 and cover delta in information
>>> and added risks.
>>>
>> [Fatai] Accepted and updated.
>>
>> We'll see if this is enough to keep the security reviewers happy...
>>
>>>
>>> - Section 10: This section needs some work.  (I'm assuming your familiar
>>> with rfc5226).
>>>
>> [Fatai] Accepted and updated.
>>>
>>
>> Better, but you should at least refer to the existing registries,
which already includes G-PIDs (see
http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml)
>>
>>> - Is it time to create a "Signal Type" registry?
>>>
>> [Fatai] We are not sure, because no "Signal Types" have been
registered in the existing RFCs (like RFC3473, RFC4328..).
>>>
>>
>> I think including a request to establish such a registry in this
>> document would be useful.  Is anyone up to proposing the requisite text?
>>
> [Fatai] OK to register “Signal Type”.

Is this a question or statement?

Thanks,
Lou

>>
>>    Value    Signal Type                           Reference
>>    -----    -----------                                ---------
>>    0        Not significant                      [this document]
>>    1        ODU1 (i.e., 2.5 Gbps)                 [this document]
>>    2        ODU2 (i.e., 10 Gbps)                  [this document]
>>    3        ODU3 (i.e., 40 Gbps)                  [this document]
>>    4        ODU4 (i.e., 100 Gbps)                 [this document]
>>    5        Reserved (for future use)              [this document]
>>    6        Optical Channel (Och) at 2.5 Gbps       [this document]
>>    7        OCh at 10 Gbps                      [this document]
>>    8        OCh at 40 Gbps                      [this document]
>>    9        OCh at 100 Gbps                     [this document]
>>    10       ODU0 (i.e., 1.25 Gbps)                [this document]
>>    11       ODU2e (i.e., 10Gbps for FC1200        [this document]
>>             and GE LAN)
>>    12~19    Reserved (for future use)             [this document]
>>    20       ODUflex(CBR) (i.e., 1.25*N Gbps)      [this document]
>>    21       ODUflex(Generic Framing            [this document]
>>             Procedure-Framed (GFP-F)),
>>             resizable (i.e., 1.25*N Gbps)
>>    22       ODUflex(GFP-F), non resizable        [this document]
>>             (i.e., 1.25*N Gbps)
>>       23~255   Reserved (for future use)             [this document]
>>
>>
>> Thanks,
>> Lou
>>
>>
>>> That's it on this document.
>>>
>>> Lou
>>> -
>>

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 15 Jan 2013 07:47:12 +0000

Hi Lou,

Sorry for late response because of my vacation.

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Friday, January 04, 2013 5:51 AM
To: Fatai Zhang
Cc: CCAMP; [email-masked]
Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04

Hi Fatai,

On 12/25/2012 3:33 AM, Fatai Zhang wrote:

Lou Berger

but may

If you

to grant

can ignore

disclaimer.

okay

Signal Type: 8 bits

values:

  (insert lines 266-285)

Reserved: 8 bits

Tolerance: 16 bits

   (insert lines 296-298)

NVC: 16 bits

Multiplier (MT): 16 bits

Bit_Rate: 32 bits

   (insert lines 290-294)

[Fatai] Got it. OK to accept your suggestion and try to update the text in this way.

text as RFC4328). Will accept your suggestion to expand the text as follows:

[Fatai] Yes. Try to add a new section to describe what you want.

Tolerance in

resolved.

[Fatai] OK.

[Fatai] My misunderstanding here. I thought you proposed to replace “bit rate” with “N”.

[Fatai] Why not just use “bit rate” field to carry “N” because “N” implies bit rate? I am OK if you like to use a new filed (like “TS Number”) to occupy the reserved field even though that I prefer the original approach (ie., use “bit rate” field to carry “N”).

BTW, I don’t think MT is the right place (it will cause ambiguity if MT is used to indicate “TS Number”).

“Pad bits” it is...

[Fatai] OK, I will issue a new version to capture all the updates and make it easy for people to converge.

cases.

s/an/a

[Fatai] Right. Will accept your proposed text.

great.

[Fatai] A statement. I am planning to register “Signal Type”. If anyone has any opinion on this point, please share your comments before I update.

Thanks,

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 15 Jan 2013 11:56:21 -0500

Fatai,
	Please see below for responses in-line .
Lou

On 1/15/2013 2:47 AM, Fatai Zhang wrote:

>> Subject: Re: [CCAMP] WG Last Call comments on
> [Fatai] Got it. OK to accept your suggestion and try to update the

I assume this is a statement not a question. Let me know if there is a
question, or discussion point here.

> [Fatai] Yes. Try to add a new section to describe what you want.

Hereto, I assume this is a statement of intent not a question. Let me
know if there is a question, or discussion point here.

> [Fatai] My misunderstanding here. I thought you proposed to replace

Great.

> [Fatai] Why not just use “bit rate” field to carry “N” because “N”
> implies bit rate?  I am OK if you like to use a new filed (like “TS
> Number”) to occupy the reserved field even though that I prefer the
> original approach (ie., use “bit rate” field to carry “N”).

Are you proposing dropping carrying bit rates represented as an IEEE
floating point and just carrying N for ODUflex? This seems workable to
me, but we should ensure that there are no significant objections.

> MT is used to indicate “TS Number”).

I'm not sure which case you're referring to, but I don't think we need
to worry about it given your proposed encoding.

> make it easy for people to converge.

As you wish.

>>    types, signal multiplication as defined in [RFC6344] and [RFC4328].

s/as/is as

great

> [Fatai] A statement. I am planning to register “Signal Type”.

great.

Thanks,
Lou

> If anyone has any opinion on this point, please share your comments
> before I update.

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 16 Jan 2013 03:16:00 +0000

Hi Lou,

To avoid misunderstanding, I would like to clarify more on the following point.

>>> It is better to have consistent format and the same meaning of one field for both ODUflex(CBR) and GFP. This is why we have section 5.1 &5.2 to describe the complex stuff.

> [Fatai] Why not just use "bit rate" field to carry "N" because "N"

> implies bit rate?  I am OK if you like to use a new filed (like "TS

> Number") to occupy the reserved field even though that I prefer the

> original approach (ie., use "bit rate" field to carry "N").

[Fatai] There are two usages for " Bit_Rate " field as described in the lines 287-310.

(1)    For ODUflex(CBR), the Bit_Rate field indicates the nominal bit rate of ODUflex(CBR) expressed in bytes per second, encoded as a 32-bit IEEE single precision floating-point number. For this case, we MUST use 32-bit IEEE floating point instead of "N" (Please see more in section 5.1).

(2)    For ODUflex(GFP), we can change the text (the lines from 305 to 310) based on your suggestion, ie., the Bit_Rate field is used to carry "N" to indicate the nominal bit rate of the

ODUflex(GFP).

Therefore, I am proposing using one single filed ("Bit_Rate ") for these two cases, in this way, we can leave the "Reserved" bits for future.

Hope we are now at the same page.

Best Regards

Fatai

---

From: Lou Berger <[email-masked]>
Date: Thu, 17 Jan 2013 12:42:19 -0500

On 1/15/2013 10:16 PM, Fatai Zhang wrote:
>>>>> It is better to have consistent format and the same meaning of one
field for both ODUflex(CBR) and GFP. This is why we have section 5.1
&5.2 to describe the complex stuff.
>>> [Fatai] Why not just use “bit rate”field to carry “N”because “N”
>>> original approach (ie., use “bit rate”field to carry “N”).
>>
> (1)    For ODUflex(CBR), the Bit_Rate field indicates the nominal bit
> rate of ODUflex(CBR) expressed in bytes per second, encoded as a 32-bit
> IEEE single precision floating-point number. For this case, we MUST use
> 32-bit IEEE floating point instead of “N”(Please see more in section 5.1).

I guess you really still need (to be based on) the client signal rate at
the edges.

>
> (2)    For ODUflex(GFP), we can change the text (the lines from 305 to
> 310) based on your suggestion, ie., the Bit_Rate field is used to carry
> “N”to indicate the nominal bit rate of the
> ODUflex(GFP).

but you're says encoded as (N*Nominal Rate) right?  Wat's the value of
this vs just carrying N?

>
> Therefore, I am proposing using one single filed ("Bit_Rate ") for these
> two cases, in this way, we can leave the "Reserved" bits for future.

bits in the control plane are generally cheap, IMO it's better to have
simpler encoding than to optimize every bit (or 8 in this case).

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 21 Jan 2013 02:43:24 +0000

Hi Lou,

You said:
>but you're says encoded as (N*Nominal Rate) right? Wat's the value of this vs just carrying N?

[Fatai] The original way (in version 04&05) is putting (N* Nominal Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we can generalize to just use one single "Bit_Rate" field to carry IEEE float number for both cases, it seems that you don't agree on this value, :-) . Therefore, I (was) am saying that I am going to accept your suggestion to carry N for ODUflex(GFP). We are discussing where to put N for ODUflex(GFP).

You said:
>bits in the control plane are generally cheap, IMO it's better to have simpler encoding than to optimize every bit (or 8 in this case).

[Fatai] OK, I will add a new field (to occupy the reserved bits) to carry N.

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, January 18, 2013 1:42 AM
To: Fatai Zhang
Cc: CCAMP; [email-masked]
Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04

>>> [Fatai] Why not just use "bit rate"field to carry "N"because "N"
>>> original approach (ie., use "bit rate"field to carry "N").
>>
> 32-bit IEEE floating point instead of "N"(Please see more in section 5.1).

> "N"to indicate the nominal bit rate of the
> ODUflex(GFP).

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Jan 2013 13:11:15 -0500

Fatai,

On 1/20/2013 9:43 PM, Fatai Zhang wrote:
> [Fatai] The original way (in version 04&05) is putting (N* Nominal
> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we can
> generalize to just use one single "Bit_Rate" field to carry IEEE
> float number for both cases, it seems that you don't agree on this
> value, :-)

I've seen differences in calculated floating point values from different
implementations, so I just want to ensure that such cases are avoided.
I'm open to specific solutions and certainly will deffer on the
specifics assuming there is no opportunity for misinterpretation/interop
issues. I don't think the original passed this threshold, i.e.,:

         N = Ceiling of

   ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance)
   ---------------------------------------------------------------------
       ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance)

> . Therefore, I (was) am saying that I am going to accept
> your suggestion to carry N for ODUflex(GFP). We are discussing where
> to put N for ODUflex(GFP).
> 

> [Fatai] OK, I will add a new field (to occupy the reserved bits) to carry N.

As you see fit.

Just to clarify my understanding, ODUflex and Virtual concatenation can
never be combined for the same signal type/level, right? (Although an
ODUflex client signal could be carried over a virtual concatenated
ODUk).  Is this correct or did I miss something in G709?

Thanks,
Lou

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 23 Jan 2013 11:49:52 +0000

Hi Lou,

For ODUflex(CBR), the formula is from [G.709-2012] and it has been discussed before, so please trust that there is no opportunity for misinterpretation.
(Note that there are two cases, one is ODUflex(CBR) and another one is ODUflex(GFP)). 

In addtion, ODUflex cannot be concatenated by [G.709-2012].

I will issue a new version tomorrow to capture all your comments.

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, January 23, 2013 2:11 AM
To: Fatai Zhang
Cc: CCAMP; [email-masked]
Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04

Fatai,

         N = Ceiling of

As you see fit.

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 23 Jan 2013 10:08:06 -0500

Fatai,

On 1/23/2013 6:49 AM, Fatai Zhang wrote:
> Hi Lou,
> 
> For ODUflex(CBR), the formula is from [G.709-2012] and it has been
> discussed before, so please trust that there is no opportunity for
> misinterpretation. (Note that there are two cases, one is
> ODUflex(CBR) and another one is ODUflex(GFP)).
> 

Thanks for confirming my understanding.  This raises the question of if
the new traffic should just apply to ODUFlex?  Correct me if I'm wrong,
but I believe the [RFC4328] is sufficient in all other cases.  This may
also make it easier for early implementations of the draft as then they
can limit code changes from the (-03) rev to only ODUflex LSPs.

Just to be clear, I'm really just *asking* about this.  As I said
before, I'm open on specifics...

Any thoughts/comments? Authors?  Implementors?

Thanks,
Lou

---

From: "Gruman, Fred" <[email-masked]>
Date: Sun, 27 Jan 2013 15:28:29 +0000

Hi Lou, Fatai, Daniele,

I understand the latest change to the way bandwidth is signaled for ODUflex(GFP), i.e., signaling the number of tributary slots N instead of the bandwidth rate in bps.  I believe that this simplifies the signaling and interoperability so I'm in agreement with this change.

However, it seems we are now inconsistent between how we represent bandwidth in routing and signaling for ODUflex(GFP).  Routing advertises the bandwidth using a floating point representation of bandwidth, while signaling is using the number of tributary slots. It seems the same benefits would be obtained by advertising the max LSP bandwidth and unreserved bandwidth for ODUflex(GFP) in terms of the number of tributary slots.

Fred

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Wednesday, January 23, 2013 9:08 AM
To: Fatai Zhang
Cc: CCAMP; [email-masked]
Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04

Fatai,

Thanks,
Lou

>    ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance)
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: John E Drake <[email-masked]>
Date: Sun, 27 Jan 2013 17:47:17 +0000

Good catch.

Irrespectively Yours,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Gruman, Fred
> Sent: Sunday, January 27, 2013 7:28 AM
> To: Lou Berger; Fatai Zhang; Daniele Ceccarelli
> I understand the latest change to the way bandwidth is signaled for
> ODUflex(GFP), i.e., signaling the number of tributary slots N instead
> of the bandwidth rate in bps.  I believe that this simplifies the
> signaling and interoperability so I'm in agreement with this change.
> 
> However, it seems we are now inconsistent between how we represent
> bandwidth in routing and signaling for ODUflex(GFP).  Routing
> advertises the bandwidth using a floating point representation of
> bandwidth, while signaling is using the number of tributary slots. It
> seems the same benefits would be obtained by advertising the max LSP
> bandwidth and unreserved bandwidth for ODUflex(GFP) in terms of the
> number of tributary slots.
> 
> Fred
> 
> 
> 
> > I've seen differences in calculated floating point values from
> > different implementations, so I just want to ensure that such cases
> are avoided.
> > specifics assuming there is no opportunity for
> > misinterpretation/interop issues. I don't think the original passed
> this threshold, i.e.,:
> >
> >          N = Ceiling of
> >
> >> . Therefore, I (was) am saying that I am going to accept your
> >> suggestion to carry N for ODUflex(GFP). We are discussing where to
> >> put N for ODUflex(GFP).
> >>
> >
> >> You said:
> >>> bits in the control plane are generally cheap, IMO it's better to
> have simpler encoding than to optimize every bit (or 8 in this case).
> >>
> > Just to clarify my understanding, ODUflex and Virtual concatenation
> > can never be combined for the same signal type/level, right?
> (Although
> > an ODUflex client signal could be carried over a virtual concatenated
> >>>>>> The bit rate field can either be set as described or to zero
> >>>>>> (i.e., ignored).  At the time, I was thinking about carrying N
> in
> >>>>>> the reserved field. But perhaps the right place is MT, if my
> >>>>>> understanding is right (would always be 1 otherwise). I'm open
> to either...
> >>>>>>
> >>>>> Number") to occupy the reserved field even though that I prefer
> >>>>> the original approach (ie., use "bit rate"field to carry "N").
> >>>>
> >>>> Are you proposing dropping carrying bit rates represented as an
> >>>> IEEE floating point and just carrying N for ODUflex? This seems
> >>>> workable to me, but we should ensure that there are no significant
> objections.
> >>>
> >>> rate of ODUflex(CBR) expressed in bytes per second, encoded as a
> >>> 32-bit IEEE single precision floating-point number. For this case,
> >>> we MUST use 32-bit IEEE floating point instead of "N"(Please see
> more in section 5.1).
> >>
> >> I guess you really still need (to be based on) the client signal
> rate
> >> at the edges.
> >>
> >>>
> >>> 310) based on your suggestion, ie., the Bit_Rate field is used to
> >>> carry "N"to indicate the nominal bit rate of the ODUflex(GFP).
> >>
> >>> Therefore, I am proposing using one single filed ("Bit_Rate ") for
> >>> these two cases, in this way, we can leave the "Reserved" bits for
> future.
> >>
> >> bits in the control plane are generally cheap, IMO it's better to
> >> have simpler encoding than to optimize every bit (or 8 in this
> case).
> >>
> >> Lou
> >>
> >>>

---

From: Lou Berger <[email-masked]>
Date: Sun, 27 Jan 2013 17:29:35 -0500

Agreed.   Just a heads-up to all, immediately following the conclusion
of the LC discussion on the signaling document.  Given the technical
changes, there will be a second last call conducted.

Lou

On 1/27/2013 12:47 PM, John E Drake wrote:
>> Of Lou Berger

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 28 Jan 2013 00:46:53 +0000

All-

This impacts existing implementations based on draft versions (and hence
interop with these implementations moving forward). IMO this is a bigger
change for us to assume at the last call stage. Furthermore we have been
using IEEE floating point format for Unreserved Bandwidth/ Max LSP BW in
IEEE floating point format for other technologies. Overall, I think this
change suffers from the "law of diminishing returns".

Thanks

Regards Š Zafar

On 1/27/13 10:28 AM, "Gruman, Fred" <[email-masked]> wrote:

>ODUflex(GFP), i.e., signaling the number of tributary slots N instead of
>the bandwidth rate in bps.  I believe that this simplifies the signaling
>and interoperability so I'm in agreement with this change.
>
>bandwidth in routing and signaling for ODUflex(GFP).  Routing advertises
>the bandwidth using a floating point representation of bandwidth, while
>signaling is using the number of tributary slots. It seems the same
>benefits would be obtained by advertising the max LSP bandwidth and
>unreserved bandwidth for ODUflex(GFP) in terms of the number of tributary
>slots.
>
>Fred
>
>
>
>>>> [Fatai] There are two usages for " Bit_Rate " field as described in
>>>>the
>>>> lines 287-310.
>>>>
>>>>32-bit
>>>>carry
>>>>these

---

From: Lou Berger <[email-masked]>
Date: Sun, 27 Jan 2013 21:46:28 -0500

Zafar,
	Is your comment with respect to just routing or both signaling and
routing?

Also, when you say "implementations based on draft versions", do these
implementations include support for ODUflex?  (Which has really been the
focus of the discussion.)

BTW I took Fred's comments as related to just the new OTN-specific ISCD
definitions (section 4.1.2 of ospf-g709v3-05, in particular).  Note that
section 4.1.1 already carries N (number of ODUs) not IEEE floating point
representations of available bandwidth.

Much thanks,
Lou

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 28 Jan 2013 03:46:55 +0000

Hi Lou- 

Please see in-line.

Thanks

Regards...Zafar

>	Is your comment with respect to just routing or both signaling and

Both, including consistency between signaling and routing attributes.

>focus of the discussion.)

Yes, I was referring to ODUFlex. As you know, fixed ODU is signaled via
level (0 BW) so its not an issue.

>representations of available bandwidth.

What I meant is Unreserved Bandwidth at priority x and Max LSP Bandwidth
at priority x. 

>>>of
>>>advertises
>>>Of
>>>>different
>>>>misinterpretation/interop
>>>>can
>>>>>>>>>(i.e.,
>>>>>>>IEEE
>>>>>have

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 28 Jan 2013 10:08:19 +0000

All,

I think the changes proposed are meaningful and would support them in an individual or early WG draft, but they don't seem to provide significative advantages to risk interworking issues with early implementations.
Moreover the changes don't allow us getting totally rid of of the bit_rate field as it is still needed for ODUflex (CBR).

My 2c
Daniele

>From: Zafar Ali (zali) [mailto:[email-masked]] 
>Sent: lunedì 28 gennaio 2013 4.47
>To: Lou Berger
>Cc: Gruman, Fred; Fatai Zhang; Daniele Ceccarelli; CCAMP; 
>[email-masked]
>>implementations include support for ODUflex?  (Which has really been 
>>the focus of the discussion.)
>
>Yes, I was referring to ODUFlex. As you know, fixed ODU is 
>signaled via level (0 BW) so its not an issue.
>
>>
>>definitions (section 4.1.2 of ospf-g709v3-05, in particular).  Note 
>>that section 4.1.1 already carries N (number of ODUs) not 
>IEEE floating 
>>point representations of available bandwidth.
>
>What I meant is Unreserved Bandwidth at priority x and Max LSP 
>Bandwidth at priority x. 
>
>>
>>Much thanks,
>>Lou
>>
>>> This impacts existing implementations based on draft versions (and 
>>> hence interop with these implementations moving forward). 
>IMO this is 
>>> a bigger change for us to assume at the last call stage. 
>Furthermore 
>>> we have been using IEEE floating point format for Unreserved 
>>> Bandwidth/ Max LSP BW in IEEE floating point format for other 
>>> technologies. Overall, I think this change suffers from the 
>"law of diminishing returns".
>>> 
>>> Thanks
>>> 
>>> Regards Š Zafar
>>> 
>>> 
>>>>bandwidth, while  signaling is using the number of tributary slots. 
>>>>It seems the same  benefits would be obtained by 
>advertising the max 
>>>>LSP bandwidth and  unreserved bandwidth for ODUflex(GFP) in 
>terms of 
>>>>the number of tributary  slots.
>>>>
>>>> Fred
>>>>
>>>>
>>>>
>>>> Thanks for confirming my understanding.  This raises the 
>question of 
>>>> if the new traffic should just apply to ODUFlex?  Correct 
>me if I'm 
>>>> wrong, but I believe the [RFC4328] is sufficient in all 
>other cases.  
>>>> This may also make it easier for early implementations of 
>the draft 
>>>> as then they can limit code changes from the (-03) rev to 
>only ODUflex LSPs.
>>>>
>>>>>> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we 
>>>>>> can generalize to just use one single "Bit_Rate" field to carry 
>>>>>> IEEE float number for both cases, it seems that you 
>don't agree on 
>>>>>> this value, :-)
>>>>>
>>>>>(Although an  ODUflex client signal could be carried over 
>a virtual 
>>>>>concatenated  ODUk).  Is this correct or did I miss something in 
>>>>>G709?
>>>>>
>>>>> Thanks,
>>>>> Lou
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Best Regards
>>>>>>
>>>>>> Fatai
>>>>>>
>>>>>>>>>> I actually wasn't suggesting that N be carried in 
>the bit rate  
>>>>>>>>>>field.
>>>>>>>>>>in the  reserved  field. But perhaps the right place 
>is MT, if 
>>>>>>>>>>my understanding is  right  (would always be 1 
>otherwise). I'm 
>>>>>>>>>>open to either...
>>>>>>>>>>
>>>>>>>>> implies bit rate?  I am OK if you like to use a new 
>filed (like 
>>>>>>>>>"TS
>>>>>>>>workable  to  me, but we should ensure that there are no 
>>>>>>>>significant objections.
>>>>>>>
>>>>>>> [Fatai] There are two usages for " Bit_Rate " field as 
>described 
>>>>>>> in the lines 287-310.
>>>>>>>
>>>>>>> (1)    For ODUflex(CBR), the Bit_Rate field indicates 
>the nominal
>>>>>>>bit
>>>>>>>32-bit  IEEE single precision floating-point number. For this 
>>>>>>>case, we MUST  use  32-bit IEEE floating point instead of 
>>>>>>>"N"(Please see more in section  5.1).
>>>>>>
>>>>>> rate at the edges.
>>>>>>> (2)    For ODUflex(GFP), we can change the text (the 
>lines from 305
>>>>>>>to
>>>>>>> Therefore, I am proposing using one single filed ("Bit_Rate ") 
>>>>>>> for these two cases, in this way, we can leave the "Reserved" 
>>>>>>> bits for future.
>>>>>>

---

From: Lou Berger <[email-masked]>
Date: Mon, 28 Jan 2013 15:25:52 -0500

All,
	We would like to try to close the discussion on the G.709
drafts so that we can move rapidly towards publication request.  The
discussion of (one of my) LC comments has resulted in several options
for the signaling ODU-related traffic parameters, and the point has
been raised that realigning routing with signaling should be discussed.

Please keep in mind that the objective of any PS is interoperability,
and that there may be early implementations that match g709v3-04.

The basic question is one of if N, the number of time slots needed to
support a ODUflex(GFP) signal, should be carried as a calculated IEEE
floating point number or directly.   Options 1 and 2 below reflect the
former, options 3 and 4 match the latter.  It is worth noting that only
options 1 and 2 are proposed for ODUflex(GFP), i.e., N must be
calculated for ODUflex(CBR) signal types with all options.

Please state your support for one the options and, if you wish, the
justification for your position:

1) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-04
   i.e., redefine [RFC4328] Traffic Parameters c-type when used with
   OTN-TDM labels. ODUflex(GFP) number of tributary slots (N) is
   encoded as:

   ... the Bit_Rate field for ODUflex(GFP) MUST
   equal to one of the 80 values listed below:

       1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts;
       9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts;
       33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts.

2) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-05
   i.e., use a new C-type for OTN-TDM labels.  Encoding details
   unchanged from g709v3-04.
   (This option addresses the issue of the same c-type needing to
    be parsed based on label/switching type.)

3) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-06
   i.e.,  use a new C-type for OTN-TDM labels. N is directly carried
   for ODUflex(GFP) only.

4) Discussed, but not in any draft
   Use draft-ietf-ccamp-gmpls-signaling-g709v3-04 encoding for all
   but ODUflex(GFP), and define new ODUflex(GFP) specific Traffic
   Parameters based on g709v3-06, presumably with unused fields
   removed.
   (This also addresses the issue of the same c-type needing to be
    parsed based on label type, but means there are different types
    based on signal type.)

Option 1 and 2 do not imply any changes to routing, while options 3 and
4 may.  Routing implications will be discussed based on the results of
this poll, and only if there is consensus to support positions 3 or 4.

We hope to make a consensus call by the end of the week, but will
continue the discussion as needed.

Much thanks,
Lou (and Deborah)

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 29 Jan 2013 02:26:53 +0000

Hi Lou,

I would pick up option 2 (better than option 1) because of the following reasons, even though I spent much time to convince you (but I failed). 

(1) There will be consistent between signaling draft (need crank-back) and the existing routing draft (we all spent so much time on routing draft to get the consensus).
(2) There will be consistent for "Bit_Rate" filed for both ODUflex(CBR) and ODUflex(GFP) cases (ie, it only needs one single "Bit_Rate" field). 
(3) I don't think option 3&4 are better than option 1&2 for interworking with early implementations (I think all the authors are from vendors, we know this very well. Usually/sometimes, there is actually no compatibility/interworking issue in the real world).

For option 3, I am fine because I appreciate the work that I have done, :-), if we don't count the additional work on routing draft. 

Anyway, please don't think about option 4, I don't see any significant advantages by doing that besides more work and more discussions. 

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, January 29, 2013 4:26 AM
To: CCAMP
Subject: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

All,

Much thanks,
Lou (and Deborah)

---

From: Lou Berger <[email-masked]>
Date: Mon, 28 Jan 2013 21:55:55 -0500

Fatai,
	Thanks for the input.

On 1/28/2013 9:26 PM, Fatai Zhang wrote:
> Hi Lou,
> 
> I would pick up option 2 (better than option 1) because of the
> following reasons, 

> even though I spent much time to convince you (but
> I failed).

I'm not sure what your referring to, but I'm also not sure we really
need to discuss it further.  As I said on 1/23, I'm open to specifics
(that ease interoperability and implementation, including for early
adopters).

I have yet to state my poll response.  I think 2 is a perfectly fine
approach, and more so than some of the other options.  I'll wait at
least a little bit before I state my actual preferred ordering.

It'll be interesting to see if others in the WG agree with your current
prioritization.

Thanks,
Lou

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Tue, 29 Jan 2013 16:40:39 +0000

Hi Lou, C-campers: 

I would pick Option 2; it's cleaner and  addresses the issue related to
overloading the same c-type.

Thanks

Regards…Zafar

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Monday, January 28, 2013 3:25 PM
To: "[email-masked]" <[email-masked]>
Subject: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call
comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

>> I think the changes proposed are meaningful and would support them in
>>an individual or early WG draft, but they don't seem to provide
>>significative advantages to risk interworking issues with early
>>implementations.
>> Moreover the changes don't allow us getting totally rid of of the
>>bit_rate field as it is still needed for ODUflex (CBR).
>> 
>> My 2c
>> Daniele
>> 
>>

---

From: "Gruman, Fred" <[email-masked]>
Date: Tue, 29 Jan 2013 17:54:33 +0000

Hi Lou,

I am not clear on option 2 as when I look into draft-ietf-ccamp-gmpls-signaling-g709v3-05, the IANA section shows the c-type for the GENERALIZE_LABEL defined in RFC 3473, not a new c-type.

OTN-TDM Generalized Label Object: 

       o OTN-TDM Generalized Label Object: Class = 16, C-Type = 2 (see 
         Section 5.1) 

I'm open to either carrying ODUflex(GFP) bandwidth as floating-point or integer N, but would like to see consistency between routing and signaling documents.

Regards,
Fred

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Tuesday, January 29, 2013 10:41 AM
To: Lou Berger; CCAMP
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

Hi Lou, C-campers: 

Thanks

Regards…Zafar

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 29 Jan 2013 18:31:47 +0000

Option 2 for me too.

Main reason? I don't have to change the routing ID! :-) ...obviously joking.

Other reasons? Agree with Fatai and Zafar. And prefer 2) to 1) because defines a new C-type.

BR
Daniele 

>Sent: martedì 29 gennaio 2013 17.41
>To: Lou Berger; CCAMP
>Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG 
>Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)
>
>Hi Lou, C-campers: 
>
>I would pick Option 2; it's cleaner and  addresses the issue 
>related to overloading the same c-type.
>
>Thanks
>
>Regards…Zafar
>
>
>Subject: [CCAMP] Poll on ODUFlex-related encoding (was: WG 
>Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)
>
>>All,
>>	We would like to try to close the discussion on the 
>G.709 drafts so 
>>that we can move rapidly towards publication request.  The discussion 
>>of (one of my) LC comments has resulted in several options for the 
>>signaling ODU-related traffic parameters, and the point has 
>been raised 
>>that realigning routing with signaling should be discussed.
>>
>>>>> implementations include support for ODUflex?  (Which has really 
>>>>> been the focus of the discussion.)
>>>>
>>>>>>> of  the bandwidth rate in bps.  I believe that this simplifies 
>>>>>>> the signaling  and interoperability so I'm in agreement with
>>>> this change.
>>>>>>>
>>>>>>> advertises  the bandwidth using a floating point representation 
>>>>>>> of bandwidth, while  signaling is using the number of 
>tributary slots.
>>>>>>> Cc: CCAMP; 
>>>>>>>> Cc: CCAMP; 
>>>>>>>>> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that 
>>>>>>>>> we can generalize to just use one single "Bit_Rate" field to 
>>>>>>>>> carry IEEE float number for both cases, it seems that you
>>>> don't agree on
>>>>>>>>> this value, :-)
>>>>>>>>
>>>>>>>>> Cc: CCAMP; 
>>>>>>>>>> To avoid misunderstanding, I would like to clarify 
>more on the 
>>>>>>>>>> following point.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> field for both ODUflex(CBR) and GFP. This is why we have 
>>>>>>>>> section
>>>>>>>>> 5.1
>>>>>>>>>>>>> The bit rate field can either be set as described or to 
>>>>>>>>>>>>> zero (i.e.,  ignored).  At the time, I was thinking about
>>>> carrying N
>>>>>>>>> I guess you really still need (to be based on) the client 
>>>>>>>>> signal rate at the edges.
>>>>>>>>>
>>>>>>>>>>

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 Jan 2013 13:46:47 -0500

Fred,
	Thanks for the input.

>        o OTN-TDM Generalized Label Object: Class = 16, C-Type = 2 (see 

I didn't notice that inconsistency.  Per
http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-05#section-5:
 The traffic parameters for OTN-TDM capable Switching Type are carried
 in the OTN-TDM SENDER_TSPEC and FLOWSPEC objects. The objects have
 the following class and type:

    -  OTN-TDM SENDER_TSPEC Object: Class = 12, C-Type = 7 (TBA)
    -  OTN-TDM FLOWSPEC Object: Class = 9, C-Type = 7 (TBA)

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 Jan 2013 13:53:35 -0500

Daniele,
	Joking aside, I think it may add value to the discussion to highlight
your rational for not wanting to change routing.  (You are after all the
editor of the routing draft.)

Is it:
- Just avoiding work for the editor (i.e., your joke...)?
- Minimizing a change at this late date?
- Minimizing impact on an early implementation?
- Something completely different?

If you don't mind sharing...

Thanks,
Lou

---

From: "Gruman, Fred" <[email-masked]>
Date: Tue, 29 Jan 2013 20:04:53 +0000

Hi Lou,

Just to confirm, your option 2 where you state "use a new C-type for OTN-TDM labels", it was not the intent to have a new c-type for the label itself, but a new c-type for the sender-tspec/flowspec (traffic parameters). If so, I misunderstood the option and now understand the proposals.

Thanks,
Fred

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2013 12:47 PM
To: Gruman, Fred
Cc: Zafar Ali (zali); CCAMP
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

Fred,
	Thanks for the input.

Lou

---

From: "Gruman, Fred" <[email-masked]>
Date: Tue, 29 Jan 2013 20:09:13 +0000

As an additional item, if we are planning to reuse existing IANA codepoint for the GENERALIZED_LABEL, why are we listing OTN-TDM Generalized Label Object in the IANA section?  This appears to imply that we are asking for a new IANA assignment, which is not the case for the label object.  Further the reference to Section 5.1 does not have anything to do with the label but traffic parameters.

Regards,
Fred

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gruman, Fred
Sent: Tuesday, January 29, 2013 2:05 PM
To: Lou Berger
Cc: CCAMP
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

Hi Lou,

Thanks,
Fred

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2013 12:47 PM
To: Gruman, Fred
Cc: Zafar Ali (zali); CCAMP
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

Fred,
	Thanks for the input.

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 Jan 2013 16:42:02 -0500

Fred,

Confirmed.  Option 2 had a shortened form of the text of option 1 that
fully spelled it out.  Sorry for the confusion.

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 Jan 2013 16:47:28 -0500

Authors,
	Please respond to Fred anytime you're ready, but please do update the
subject line as appropriate (as the comment has little to do with the
poll).  Also ensure the next rev of the draft includes any necessary update.

Thanks,
Lou

-------- Original Message --------
Subject: RE: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call
comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)
Date: Tue, 29 Jan 2013 20:09:13 +0000
From: Gruman, Fred <[email-masked]>
To: Gruman, Fred <[email-masked]>, Lou Berger <[email-masked]>
CC: CCAMP <[email-masked]>

As an additional item, if we are planning to reuse existing IANA
codepoint for the GENERALIZED_LABEL, why are we listing OTN-TDM
Generalized Label Object in the IANA section?  This appears to imply
that we are asking for a new IANA assignment, which is not the case for
the label object.  Further the reference to Section 5.1 does not have
anything to do with the label but traffic parameters.

Regards,
Fred

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Gruman, Fred
Sent: Tuesday, January 29, 2013 2:05 PM
To: Lou Berger
Cc: CCAMP
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call
comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

Hi Lou,

Just to confirm, your option 2 where you state "use a new C-type for
OTN-TDM labels", it was not the intent to have a new c-type for the
label itself, but a new c-type for the sender-tspec/flowspec (traffic
parameters). If so, I misunderstood the option and now understand the
proposals.

Thanks,
Fred

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Tuesday, January 29, 2013 12:47 PM
To: Gruman, Fred
Cc: Zafar Ali (zali); CCAMP
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call

Fred,
	Thanks for the input.

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 30 Jan 2013 02:56:14 +0000

Hi Fred,

You are right, this is a legacy error. 

I will remove OTN-TDM Generalized Label Object from IANA section.

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gruman, Fred
Sent: Wednesday, January 30, 2013 4:09 AM
To: Gruman, Fred; Lou Berger
Cc: CCAMP
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

Regards,
Fred

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gruman, Fred
Sent: Tuesday, January 29, 2013 2:05 PM
To: Lou Berger
Cc: CCAMP
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

Hi Lou,

Thanks,
Fred

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2013 12:47 PM
To: Gruman, Fred
Cc: Zafar Ali (zali); CCAMP
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

Fred,
	Thanks for the input.

Lou

---

From: Khuzema Pithewan <[email-masked]>
Date: Wed, 30 Jan 2013 06:46:35 +0000

I would prefer option#1/2.

Thanks
Khuzema

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Wednesday, January 30, 2013 3:12 AM
To: Gruman, Fred
Cc: CCAMP
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

Fred,

Confirmed.  Option 2 had a shortened form of the text of option 1 that fully spelled it out.  Sorry for the confusion.

Lou

On 1/29/2013 3:04 PM, Gruman, Fred wrote:
> Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last 
> Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)
> 
> Fred,
> 	Thanks for the input.
> 
>> Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last 
>> Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)
>>
>> Hi Lou, C-campers: 
>>
>> I would pick Option 2; it's cleaner and  addresses the issue related 
>> to overloading the same c-type.
>>
>> Thanks
>>
>> Regards…Zafar
>>
>>
>>> 	We would like to try to close the discussion on the G.709 drafts so 
>>> that we can move rapidly towards publication request.  The 
>>> discussion of (one of my) LC comments has resulted in several 
>>> options for the signaling ODU-related traffic parameters, and the 
>>> point has been raised that realigning routing with signaling should be discussed.
>>>
>>> Please keep in mind that the objective of any PS is 
>>> interoperability, and that there may be early implementations that match g709v3-04.
>>>
>>> The basic question is one of if N, the number of time slots needed 
>>> to support a ODUflex(GFP) signal, should be carried as a calculated IEEE
>>> former, options 3 and 4 match the latter.  It is worth noting that 
>>> only options 1 and 2 are proposed for ODUflex(GFP), i.e., N must be 
>>> 4 may.  Routing implications will be discussed based on the results 
>>> of this poll, and only if there is consensus to support positions 3 or 4.
>>>
>>>> I think the changes proposed are meaningful and would support them 
>>>> in an individual or early WG draft, but they don't seem to provide 
>>>>>> definitions (section 4.1.2 of ospf-g709v3-05, in particular).  
>>>>>> Note that section 4.1.1 already carries N (number of ODUs) not
>>>>> IEEE floating
>>>>>>> This impacts existing implementations based on draft versions 
>>>>>>> (and hence interop with these implementations moving forward).
>>>>> IMO this is
>>>>>>>> of bandwidth, while  signaling is using the number of tributary slots.
>>>>>>>> Just to be clear, I'm really just *asking* about this.  As I 
>>>>>>>> said before, I'm open on specifics...
>>>>>>>>
>>>>>>>>> I'm open to specific solutions and certainly will deffer on 
>>>>>>>>> the specifics assuming there is no opportunity for 
>>>>>>>>> concatenated  ODUk).  Is this correct or did I miss something 
>>>>>>>>> in G709?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Lou
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best Regards
>>>>>>>>>>
>>>>>>>>>> Fatai
>>>>>>>>>>
>>>>>>>>>>> 32-bit  IEEE single precision floating-point number. For 
>>>>>>>>>>> this case, we MUST  use  32-bit IEEE floating point instead 
>>>>>>>>>>> of "N"(Please see more in section  5.1).
>>>>>>>>>>
>>>>>>>>>>> Therefore, I am proposing using one single filed ("Bit_Rate 
>>>>>>>>>>> ") for these two cases, in this way, we can leave the "Reserved"
>>>>>>>>>>> bits for future.
>>>>>>>>>>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 30 Jan 2013 08:36:22 +0000

Lou, 

it was really just a joke, no hidden meanings. 
If we find a reasonable solution for signaling that implies modifications to the routing we will modify the routing too (here I agree with Fred that alignment between signaling and routing is a SHOULD, if not a MUST).

Indepndently from changes to the routing i still believe that option 2 is the most reasonable. The fact that it is one of the options that does not imply changes to the routing is just a coincidence.

Thanks,
Daniele

>Sent: martedì 29 gennaio 2013 19.54
>To: Daniele Ceccarelli
>Cc: CCAMP
>	Joking aside, I think it may add value to the 
>discussion to highlight your rational for not wanting to 
>change routing.  (You are after all the editor of the routing draft.)
>
>Is it:
>Last Call 
>>>> point has
>>>>>>>>> From: [email-masked] 
>[mailto:[email-masked]] On 
>>>>>>>>> Behalf Of  Lou Berger
>>>>>>>>>>>> but you're says encoded as (N*Nominal Rate) right? 
>Wat's the 
>>>>>>>>>>>> value of  this vs just carrying N?
>>>>>>>>>>>
>>>>>>>>>>> but you're says encoded as (N*Nominal Rate) right?  
>Wat's the 
>>>>>>>>>>> value of  this vs just carrying N?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 30 Jan 2013 08:58:05 +0000

Hi Daniele and Lou,

To avoid work back and forth, I would point out that we can still get the coincidence between signaling and routing if we adopt option 3 and change routing draft.

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, January 30, 2013 4:36 PM
To: Lou Berger
Cc: CCAMP
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

Lou, 

Thanks,
Daniele

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 30 Jan 2013 11:17:25 +0100

Hi all,

Option 2 is my preference too. I share completely motivations provided by Fatai.

Thanks.

Best Regards
Sergio

Belotti Sergio - System Architect
ALCATEL-LUCENT  Optics Division
-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Fatai Zhang
Inviato: martedì 29 gennaio 2013 3.27
A: Lou Berger; CCAMP
Oggetto: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

Hi Lou,

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, January 29, 2013 4:26 AM
To: CCAMP
Subject: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

All,

Much thanks,
Lou (and Deborah)

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 30 Jan 2013 11:33:03 +0100

Hi Fatai,
 This is true but clearly would not match one of your motivation of preference ..that in fact I share

"(3) I don't think option 3&4 are better than option 1&2 for interworking with early implementations.

Leave apart other work on routing for which , with Daniele, we spent time in these months.
So I would again push for Option 2.

Cheers
Sergio

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Fatai Zhang
Inviato: mercoledì 30 gennaio 2013 9.58
A: Daniele Ceccarelli; Lou Berger
Cc: CCAMP
Oggetto: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

Hi Daniele and Lou,

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, January 30, 2013 4:36 PM
To: Lou Berger
Cc: CCAMP
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

Lou,

Thanks,
Daniele

---

From: Rajan Rao <[email-masked]>
Date: Thu, 31 Jan 2013 19:19:41 +0000

Prefer option#1 or #2.

Thanks
Rajan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Khuzema Pithewan
Sent: Tuesday, January 29, 2013 10:47 PM
To: Lou Berger; Gruman, Fred
Cc: CCAMP
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

Thanks
Khuzema

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Wednesday, January 30, 2013 3:12 AM
To: Gruman, Fred
Cc: CCAMP
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

Fred,

Lou

On 1/29/2013 3:04 PM, Gruman, Fred wrote:
> in the OTN-TDM SENDER_TSPEC and FLOWSPEC objects. The objects have the 
> following class and type:
>