Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-wson-signaling

[Lou Berger <[e-mail]>]

Sounds good.  Thanks,
Lou

On 3/5/2014 1:27 PM, Giovanni Martinelli (giomarti) wrote:
> Hi Lou,
>
> sorry missed to ask a somewhat trivial detail in my last reply
>
> On 30 Oct 2013, at 13:58, Lou Berger <[e-mail]> wrote:
>
>> Authors,
>>
>> Sorry, I missed an important one when writing up my notes:
>>
>> Somewhere you should state that the LSPs signaled per the document must use
>>    Switching Type = WSON-LSC [WSON-OSPF]
>>    Encoding Type = Lambda [RFC3471]
>>    Label format = per [RFC6205]
>>
>
> GM> ok
>
>> You should probably also state that this draft updates 5205 in that it
>> permits use of the defined label type for WSON-LSC.  This will need to
>> be mentioned in both the abstract and in the body.
>>
>
> GM> I guess you mean update 6205 in the sense that  (from RFC6205 section 1)
>
> “
> This document presents details that are specific to the use of GMPLS
>     with LSC equipment.
> "
>
> become LCS and WSON-LSC equipments. Correct?
>
> Cheers
> G
>
>
>
>
>> Lou
>>
>> On 10/29/2013 2:28 PM, Lou Berger wrote:
>>> Authors,
>>> 	I have some comments on this document. Most are strictly
>>> editorial. Note that I'm the document shepherd, see RFC 4858 for more
>>> information.
>>>
>>> - Please address my general comments on the WSON document set
>>>
>>> - in document
>>>   s/Bi-Directional/Bidirectional
>>>
>>> - Abstract
>>>   s/Such extensions are necessary/Such extensions are applicable
>>>   drop "bidirectional LSPs, and"
>>>
>>> - Section 1
>>>
>>>    These extensions build on previous work for the control of lambda
>>>    and G.709 based networks.
>>>
>>>   Please add appropriate references.
>>>
>>>   It seems to that it would be worth mentioning the rwa-info document
>>>   and the encoding document in this section.
>>>
>>> - section 3.1
>>>   s/MUST/needs to
>>>
>>> - Section 3.3
>>>   s/MAY/can
>>>   s/MAY/need to be
>>>
>>> - Section 3.4
>>>   s/MAY/can
>>>
>>> - section 3.5 title
>>>   s/Out of Scope/Optical Impairments
>>>
>>> - Section 4.2:
>>>    To target a specific node, this section defines a WSON_Processing
>>>    object as part of the LSP_REQUIRED_ATTRIBUTE and follows procedures
>>>    defined in [RSVP-RO].
>>>
>>>    The content of this object is defined in the subsequent sections.
>>>    (See Section 4.3 for <RBInformation> TLV and Section 4.4 for
>>>    <WavelengthSelection> TLV, respectively.)
>>>
>>> Do you mean
>>>
>>>    To target a specific node, this section defines a WSON_Processing
>>>    HOP Attribute TLV which is processed according to the procedures
>>>    defined in [RSVP-RO].
>>>
>>>    The content of this TLV is defined in the subsequent sections.
>>>    (See Section 4.3 for <RBInformation> sub-TLV and Section 4.4 for
>>>    <WavelengthSelection> sub-TLV, respectively.)
>>>
>>>   if yes, also need to s/WSON Processing object/WSON Processing TLV
>>>   in rest of document.
>>>
>>> - Section 4.2
>>>   You need to define the Length.  Perhaps. replace the whole definition:
>>> OLD
>>>
>>>    The WSON Processing object encoding is defined as:
>>>
>>>     0                   1                   2                   3
>>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>    |            Type               |             Length            |
>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>    |                                                               |
>>>    ~                            Value                              ~
>>>    |                                                               |
>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> NEW
>>>   The WSON Processing carries sub-TLVs of the same format as a HOP
>>>   Attributes TLV, as defined in [RSVP-RO].
>>>
>>> - Section 4.3. "... PathErr SHALL be generated." Which code/value?
>>>   Are you sure? Generally malformed messages don't result in a PathErr.
>>>   What is an upstream node expected to do with the PathErr?
>>>
>>>   How should other parsing errors be handled?
>>>
>>>   What about allocation errors?
>>>
>>> - Section 4.4
>>>
>>>   I'm really confused by this sub-tlv.  Is it intended to be an end to
>>> end construct, information that is used/updated hop-by-hop, or used at
>>> specific hops only?  I suspect that the desire is for this to be
>>> communicated end to end and accessible at each hop.  If so, it looks
>>> like then intent is for this to be carried as a TLV in the
>>> LSP_ATTRIBUTES Object.  Is this correct?  If so the section needs to be
>>> updated accordingly.
>>>
>>> - Section 5
>>>
>>> I'm really not sure that this section adds anything beyond what is
>>> already stated in other documents/RFCs, and it doesn't match this
>>> documenting being a protocol specification.  I can see some informative
>>> value in the third paragraph.  I suggest moving just this paragraph to
>>> the end of section 4.3 and dropping the rest.
>>>
>>> - Section 6
>>>   I think this section needs to be replaced.  Perhaps use the following
>>> which is based on draft-ietf-ccamp-gmpls-signaling-g709v3
>>>
>>>    This document is builds on the mechanisms defined in  [RFC3473],
>>>    and only differs in specific information communicated. As such,
>>>    this document introduces no new security considerations to the
>>>    existing GMPLS signaling protocols. See [RFC3473], for
>>>    details of the supported security measures. Additionally,
>>>    [RFC5920] provides an overview of security vulnerabilities and
>>>    protection mechanisms for the GMPLS control plane.
>>>
>>> - Section 7
>>>   This section needs a bit of work  See
>>> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-12#section-11
>>> for an example.  Contact me off list if you think need help with
>>> specific text.
>>>
>>> That's it on this one,
>>> Lou
>>>
>>>
>>> On 10/22/2013 4:34 PM, Lou Berger wrote:
>>>>
>>>> All,
>>>> 	Given the recent draft submission deadline and only one comment being
>>>> received to date, we'd like to extend the WG more time for review.
>>>>
>>>> These drafts represent significant work by the authors and WG, so please
>>>> review and let the WG know what you think (positive or negative)!
>>>>
>>>> Please have all comments in by October 29.
>>>>
>>>> Thank you,
>>>> Lou (and Deborah)
>>>>
>>>> On 10/1/2013 12:34 PM, Lou Berger wrote:
>>>>> All,
>>>>>
>>>>> This mail begins working group last call on the WSON documents.  As
>>>>> there are 6 documents in this set, the last call will be three weeks.
>>>>> The documents included in the last call are:
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18
>>>>> (Informational, IPR Disclosed)
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11
>>>>> (Standards Track, IPR Disclosed)
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21
>>>>> (Standards Track)
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05
>>>>> (Standards Track, IPR Disclosed)
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-12
>>>>> (Standards Track, IPR Disclosed)
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 (Standards
>>>>> Track) Also has one open issue that will need to be resolved as part of
>>>>> LC, see http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52.
>>>>>
>>>>> This working group last call ends on October 22.  Comments should be
>>>>> sent to the CCAMP mailing list.  Please remember to include the
>>>>> technical basis for any comments.
>>>>>
>>>>> Positive comments, e.g., "I've reviewed this document and believe it is
>>>>> ready for publication", are welcome!
>>>>>
>>>>> Please note that we're still missing some IPR statements.  Any
>>>>> forthcoming publication request will be delayed by late IPR
>>>>> statements/disclosures.
>>>>>
>>>>>
>>>>> Thank you,
>>>>> Lou (and Deborah)
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> CCAMP mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>>
>>>
>>>
>
>