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

[Lou Berger <[e-mail]>]

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

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

> Hi Lou,
>
> Sorry for late response because of my vacation.
>
> Please see in-line below.
>
>
>
>
> Best Regards
>
> Fatai
>
> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: Friday, January 04, 2013 5:51 AM
>> To: Fatai Zhang
>> Cc: CCAMP; [e-mail]
>> Subject: Re: [CCAMP] WG Last Call comments on
draft-ietf-ccamp-gmpls-signaling-g709v3-04
>>
>>
>> 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:[e-mail]]
>>>> Sent: Thursday, December 20, 2012 10:12 PM
>>>> To: Fatai Zhang
>>>> Cc: CCAMP; [e-mail]
>>>> 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
>>>>>
>>>>>
>>>>> -----邮件原件-----
>>>>> 发件人: [e-mail] [mailto:[e-mail]] 代表
>> Lou Berger
>>>>> 发送时间: 2012年10月22日 10:01
>>>>> 收件人: CCAMP; [e-mail]
>>>>> 主题: [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.
>>
> [Fatai] Got it. OK to accept your suggestion and try to update the
> text in this way.

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

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

>>
>>>>
>>>>>
>>>> [...]
>>>>>
>>>>> - 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.
>>
> [Fatai] OK.

>>
>>>>
>>>>>
>>>>> - 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.
>>
> [Fatai] My misunderstanding here. I thought you proposed to replace
> “bit rate” with “N”.

Great.

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

> BTW, I don’t think MT is the right place (it will cause ambiguity if
> 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.

>>
>>
>>>>
>>>> [...]
>>>>
>>>>>
>>>>> - 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.)
>>
> [Fatai] OK, I will issue a new version to capture all the updates and
> make it easy for people to converge.

As you wish.

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

s/as/is as

>>
> [Fatai] Right. Will accept your proposed text.

great

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

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