Re: [CCAMP] WG Last Call Comments on "GMPLS Enhancement for Signal and Network Element Compatibility of Wavelength Switched Optical Networks"

[Acee Lindem <[e-mail]>]

Hi Young,

From: Leeyoung <[e-mail]<mailto:[e-mail]>>
Date: Thursday, February 6, 2014 11:40 AM
To: Ericsson <[e-mail]<mailto:[e-mail]>>, Lou Berger <[e-mail]<mailto:[e-mail]>>
Cc: CCAMP <[e-mail]<mailto:[e-mail]>>
Subject: RE: [CCAMP] WG Last Call Comments on "GMPLS Enhancement for Signal and Network Element Compatibility of Wavelength Switched Optical Networks"

Hi Acee and Lou,

Here’s the working document and the idnits results.

Acee, Please see inline for my comments to your comments. I have incorporated all your comments except one – I need your clarification.

Thanks.
Young

From: Acee Lindem [mailto:[e-mail]]
Sent: Wednesday, February 05, 2014 4:11 PM
To: Leeyoung
Cc: CCAMP
Subject: Re: [CCAMP] WG Last Call Comments on "GMPLS Enhancement for Signal and Network Element Compatibility of Wavelength Switched Optical Networks"

Hi Young,

On Feb 3, 2014, at 7:21 PM, Leeyoung <[e-mail]<mailto:[e-mail]>> wrote:


Hi Acee,

Here’s my comments inline on your comments.

Thanks.
Young

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Acee Lindem
Sent: Tuesday, October 29, 2013 5:16 PM
To: CCAMP
Subject: [CCAMP] WG Last Call Comments on "GMPLS Enhancement for Signal and Network Element Compatibility of Wavelength Switched Optical Networks"

I have the following comments on the subject draft:

1.      State the action to take if the new TLV and sub-TLVs or their attendant encodings are malformed. You should log the problem and ignore the entire LSA, subsuming TLV, or just the sub-TLV in GMPLS path computations.
YOUNG>>  In Section 5.2, added:

“In case where the new sub-TLVs or their attendant encodings are
   malformed, the proper action would be to log the problem and ignore
   just the sub-TLVs in GMPLS path computations rather than ignoring
   the entire LSA.”

See inline.

YOUNG>> Which inline are you referring to?

I meant this to be at the top.





2.      Section 2 - Your definition of "At most once" is semantically wrong. "At most once" means the TLV or sub-TLV can be include one time or not at all. It has nothing to with whether or not it should be specified. I hope we are not going to attempt to change the English language with this draft.
YOUNG>> Corrected.  Is a new text OK with you?

“All sub-TLVs defined here may occur at most once in any given Optical Node TLV. If more than one copy of a sub-TLV is received,
   only the first one of the same type is accommodated and the rest are ignored upon receipt.”

Yes - although I’d replace “accommodated” with “processed”.

YOUNG>> OK. Corrected.




3.      Section 3 - Figure 1 should not span multiple pages and the scale is off by one - it should be shifted right 1 column.
YOUNG>>  Done

Ok.




4.      Section 6 - Explicitly state which are IANA registries are being extended. Since you are adding a new TLV, you will also need a new registry for the sub-TLVs. Seehttp://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xhtml#top-level for examples.

YOUNG>> Done. Please check if the corrections are good.

It would be easier for IANA if you explicitly state that you are creating two new registries.

    A new IANA registry will be created for sub-TLVs of the Optical Node Property TLV. The following sub-TLVs are allocated in this specification.

                        o
                        o
                        o

   Additionally, a new IANA registry will be created for nested sub-TLVs of the Resource Block Information sub-TLV. The following sub-TLVs are allocated in this specification.

                       o
                       o
                       o
YOUNG>> I reshuffled the order starting from the Optical Node Property TLV, and its sub-TLVs and nested-TLVs; then WSON-LSC Switching Type TLV and its sub-TLVs.
Please see the enclosed working version.

Ok – Looks good.
Thanks,
Acee




Thanks,
Acee






Editorial Comments:

I would suggest the following corrections:


125c125
<    to allow both multiple WSON signal types and common hybrid electro
---
>    to support both multiple WSON signal types and common hybrid electro
197c197
<    node. It is constructed of a set of sub-TLVs. There are no ordering
---
>    node. It is comprised of a set of sub-TLVs. There are no ordering
203c203
<    encodings of these properties are defined in [WSON-Encode].
---
>    encodings for these properties are defined in [WSON-Encode].
253,254c253
<    router, as described in [RFC3630] and [RFC5250]. Resource Block
<    Information
---
>    router, as described in [RFC3630] and [RFC5250].
279,280c278,279
<    The detail encodings of these sub-TLVs are found in [WSON-Encode] as
<    indicated in the table below.
---
>    The detailed encodings of these sub-TLVs are found in [WSON-Encode]
>    as indicated in the table below.
293c292
<    relation to the switching device. In particular it indicates the
---
>    relation to the switching device. In particular, it indicates the
302,303c301,302
<    reach or leave all the resources. Resource Block Wavelength
<    Constraints sub-TLV describe these properties.
---
>    reach or leave all the resources. The Resource Block Wavelength
>    Constraints sub-TLV describes these properties.
316c315
<    case then wavelength availability on these shared fibers is needed
---
>    case, then wavelength availability on these shared fibers is needed
353c352
<    Bandwidth TLV are defined (TBA by IANA):
---
>    Bandwidth sub-TLVs are defined (TBA by IANA):
402c401
<    produce LSAs that exceed the IP Maximum Transmission Unit (MTU). In
---
>    produce LSAs that exceeds the IP Maximum Transmission Unit (MTU). In
417,422c416,421
<    is received for a system path cannot make use of the other four sub-
<    TLVs since it does not know the nature of the resources, e.g., are
<    the resources wavelength converters, regenerators, or something
<    else. Once this sub-TLV is received path computation can proceed
<    with whatever of the additional types of sub-TLVs it may have
<    received (there use is dependent upon the system type). If path
---
>    is received for a system, path compuation cannot make use of the
>    other four sub-TLVs since it does not know the nature of the
>    resources, e.g., are the resources wavelength converters,
>    regenerators, or something else. Once this sub-TLV is received,
>    path computation can proceed with whatever sub-TLVs it may have
>    received (their use is dependent upon the system type). If path
433c432
<    these sub-TLVs then there is the possibility of either (a) path
---
>    these sub-TLVs, then there is the possibility of either (a) path

Thanks,
Acee

<draft-ietf-ccamp-gmpls-general-constraints-ospf-te-07.txt>