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

Lou Berger <lberger@labn.net> Wed, 05 March 2014 14:46 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF6E1A065E for <ccamp@ietfa.amsl.com>; Wed, 5 Mar 2014 06:46:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdZcOwISdBWH for <ccamp@ietfa.amsl.com>; Wed, 5 Mar 2014 06:46:03 -0800 (PST)
Received: from oproxy1-pub.mail.unifiedlayer.com (oproxy1-pub.mail.unifiedlayer.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id E8A261A0674 for <ccamp@ietf.org>; Wed, 5 Mar 2014 06:46:01 -0800 (PST)
Received: (qmail 13235 invoked by uid 0); 5 Mar 2014 14:44:57 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.mail.unifiedlayer.com with SMTP; 5 Mar 2014 14:44:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=JbfbQIbaXgopHy154xEA1OUW4sm5XWi4ppX8gO6iieY=; b=ZvEe+vRbc63ziuBrb+ieES+V1I28bnBb6Z1N8NFzFx44zh64qiSgODHfyWjrd8KoZDdm3mDpIVQ7Ti2MRFXRwwHqNAg8oNBBqPkbboixSwyhrGUdN2bflhCFI10VaoaS;
Received: from [69.89.31.113] (port=58236 helo=[IPv6:::1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1WLD45-0002To-0H; Wed, 05 Mar 2014 07:44:57 -0700
Message-ID: <5317387F.70106@labn.net>
Date: Wed, 05 Mar 2014 14:45:19 +0000
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Giovanni Martinelli (giomarti)" <giomarti@cisco.com>
References: <524AF9A9.3040006@labn.net> <5266E138.8080605@labn.net> <526FFE4F.30309@labn.net> <52710273.80805@labn.net> <94555AE2-9C13-4E81-8C6F-697383B762A9@cisco.com>
In-Reply-To: <94555AE2-9C13-4E81-8C6F-697383B762A9@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/cLyUgOChBxkNTnNRGSHaDpFXKQo
Cc: CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-wson-signaling@tools.ietf.org" <draft-ietf-ccamp-wson-signaling@tools.ietf.org>
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-wson-signaling
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Mar 2014 14:46:07 -0000

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 <lberger@labn.net> 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
>>>>> CCAMP@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> CCAMP mailing list
>>>> CCAMP@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>>
>>>
>>>
>
>