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

"Giovanni Martinelli (giomarti)" <giomarti@cisco.com> Wed, 05 March 2014 13:27 UTC

Return-Path: <giomarti@cisco.com>
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 EA82C1A00BC for <ccamp@ietfa.amsl.com>; Wed, 5 Mar 2014 05:27:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Level:
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 FN80ngjy7tUG for <ccamp@ietfa.amsl.com>; Wed, 5 Mar 2014 05:27:05 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id EE76D1A002A for <ccamp@ietf.org>; Wed, 5 Mar 2014 05:27:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8573; q=dns/txt; s=iport; t=1394026021; x=1395235621; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PI3j7tyh8NWpzidDwn8cL59TK5pc6Fgf4+c9+YrrB40=; b=jwNO2ktlrewmm6Bnu0hSPDsjFgvCtuE+snSKEF+Fq9m0IhjtXqxgLkq4 n2zJYVAyuH4vh8O4yQBRMLOP/Ht5U1EK3cbww+iVCB2tWGop4DB4P1feA UakjPoG2Spq7i+sluNIHU3xNmtvEYusp7J6mvoe2eBMuYrVvQe7031tEF 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAPAkF1OtJV2Z/2dsb2JhbABagwY7V8ELgRYWdIIlAQEBAwEBAQFkBwsFCwIBCA4KLicLJQIEDgWHcQgNzWkXjgABAQoSMwcCgyKBFASYPYEykHmDLYFxOQ
X-IronPort-AV: E=Sophos;i="4.97,593,1389744000"; d="scan'208";a="308277996"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 05 Mar 2014 13:27:01 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s25DR1jN030550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Mar 2014 13:27:01 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.171]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 07:27:00 -0600
From: "Giovanni Martinelli (giomarti)" <giomarti@cisco.com>
To: Lou Berger <lberger@labn.net>
Thread-Topic: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-wson-signaling
Thread-Index: AQHPOHaWhG+mKsKvx022cDpfrk1U+w==
Date: Wed, 5 Mar 2014 13:27:00 +0000
Message-ID: <94555AE2-9C13-4E81-8C6F-697383B762A9@cisco.com>
References: <524AF9A9.3040006@labn.net> <5266E138.8080605@labn.net> <526FFE4F.30309@labn.net> <52710273.80805@labn.net>
In-Reply-To: <52710273.80805@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.104.226]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <FBB9662334B91445B5FD7D0306F7FEA3@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/emBBhnUV0BrKLVaZI6xHVyXchxg
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 13:27:08 -0000

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