Re: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08

Lou Berger <lberger@labn.net> Tue, 09 September 2014 18:54 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 BFAD41A010E for <ccamp@ietfa.amsl.com>; Tue, 9 Sep 2014 11:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level:
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
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 d3w_68cSD_vt for <ccamp@ietfa.amsl.com>; Tue, 9 Sep 2014 11:54:50 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 678CA1A00C2 for <ccamp@ietf.org>; Tue, 9 Sep 2014 11:54:50 -0700 (PDT)
Received: (qmail 8473 invoked by uid 0); 9 Sep 2014 18:54:49 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 9 Sep 2014 18:54:49 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id pCua1o00j2SSUrH01CudLc; Tue, 09 Sep 2014 18:54:47 -0600
X-Authority-Analysis: v=2.1 cv=F6LEKMRN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=KAMjFvWR21EA:10 a=kC4BAXwS1W4A:10 a=HFCU6gKsb0MA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=48vgC7mUAAAA:8 a=_35FxuIzPOAYEO43ruMA:9 a=wPNLvfGTeEIA:10 a=33rK67OTR_gA:10
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=nreO3bZgqOy3HJ9HKtAWzwnbejO8sW30tGNkJu6hA6I=; b=C9qyBbL9p4Iv7Cag7j9ZN6aHfF0KFjbh7NyfXmqtidGF73miVBWxV5h9URmxFBZZxEl+RXYdHQoU0hbzJHKURo5yB+2ORxCIq1g5u6SuGV76GxpCXs/lUB4XhiOYIbBh;
Received: from box313.bluehost.com ([69.89.31.113]:57135 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from <lberger@labn.net>) id 1XRQYl-0005QH-PE; Tue, 09 Sep 2014 12:54:35 -0600
Message-ID: <540F4CEB.1080103@labn.net>
Date: Tue, 09 Sep 2014 14:54:35 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Leeyoung <leeyoung@huawei.com>, "draft-ietf-ccamp-wson-signaling@tools.ietf.org" <draft-ietf-ccamp-wson-signaling@tools.ietf.org>
References: <53DD040A.6000809@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C08671@dfweml706-chm.china.huawei.com> <53DFF088.70506@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C086A9@dfweml706-chm.china.huawei.com> <53E0094F.60200@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C08831@dfweml706-chm.china.huawei.com> <53E0330B.9000706@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C0920C@dfweml706-chm.china.huawei.com>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C0920C@dfweml706-chm.china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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/GhcJi9aCNVh68mD_yufGOz4rOC4
Cc: CCAMP <ccamp@ietf.org>
Subject: Re: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08
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: Tue, 09 Sep 2014 18:54:51 -0000

Young/Authors/...,

How big is a typical and maximum-sized ResourceBlockInfo?

Thanks,
Lou

On 8/7/2014 4:08 PM, Leeyoung wrote:
> Hi Lou,
>
> Based on Cyril's comment on RBI TLV, it is reasonable to think of its encoding using HOP Attribute TLV/ERO subobject per [RVSP-RO] which is the current text. 
>
> If, however, we were to separate RBI TLV from WA method TLV (i.e, putting this under LSP_REQUIRED_ATTRIBUTES Object), this adds more changes on current implementation. For a distributed WA perspective (which is the case this draft is dealing with), WA method need not be an LSP-level attribute, especially around Resource Blocks (Wavelength Conversion). If we can accept this, I think we can encode WA method TLV as HOP Attribute TLV encoded as ERO subobject. This implies the current 08 text is fine with some consistency check. 
>
> Young
>
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net] 
> Sent: Monday, August 04, 2014 8:28 PM
> To: Leeyoung; CCAMP; draft-ietf-ccamp-wson-signaling@tools.ietf.org
> Subject: Re: [CCAMP] Still have issues in WSON Processing HOP Attribute Encoding in draft-ietf-ccamp-wson-signaling-08
>
> Young,
>     I think the text is inconsistent (looking back on -07 and the emails).  My primary focus / desire at this time is clarifying the existing text without making any substantive technical changes. 
>
> The narrative implies [RSVP-RO], but the editors' intent was LSP_REQUIRED_ATRIBUTES object.  I personally (all hats off) think LSP_REQUIRED_ATTRIBUTES object is right for WA method and [RSVP-RO] is right for RBI.  With hats on, I'd like the text to reflect implementations and the LC.
>
> At this point it might be useful to hear from others in the WG.
>
> WG/All/Authors/Contributors,
>     Does anyone else care to weigh in?
>
> Thanks,
> Lou
>
> On 8/4/2014 7:00 PM, Leeyoung wrote:
>> Hi Lou,
>>
>> Good point on RBI info! I can think of the RB Identifier (32 bit field) to imply the node/interface to which wavelength conversion would take place if we were to use LSP_REQUIRED_ATRIBUTES object. In other words, making the RB Identifier globally significant in a domain, per hop treatment of the RBs is possible. 
>>
>> On the other hand, a better way to treat Resource Block Information seems to be using an alternative way (i.e., using HOP Attributes/ERO subobject per [RSVP-RO]). 
>>
>> If making the RB ID globally significant creates a problem, we need to make some technical changes to the draft. Let me know what you think.
>>
>> Regards,
>> Young
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Monday, August 04, 2014 5:30 PM
>> To: Leeyoung
>> Cc: CCAMP; draft-ietf-ccamp-wson-signaling@tools.ietf.org
>> Subject: Re: [CCAMP] Still have issues in WSON Processing HOP 
>> Attribute Encoding in draft-ietf-ccamp-wson-signaling-08
>>
>> Young,
>>     Thanks for the quick response.  I "get" how WA method works, but am less clear how Resource Block Information (e.g., Regeneration control and  Attribute Conversion control) works per node. For example, how would control of wavelength conversion at a particular node work?
>>
>> Perhaps just running through this one simple case will help...
>>
>> Again, as a reminder, the desire is to document existing intent rather than redefining the solution.
>>
>> Much thanks,
>> Lou
>>
>> On 8/4/2014 5:08 PM, Leeyoung wrote:
>>> Hi Lou,
>>>
>>> Since the LSP_REQUIRED_ATTRIBUTES object is meant to allow each 
>>> transit node to inspect the TLV's under it, each transit node will 
>>> inspect RBI or WA method and apply if it has relevance for the node; 
>>> otherwise just pass to the next hop. (Section 5 of RFC 5420 has this
>>> clause: "This means that this object SHOULD only be used for 
>>> attributes that require support at some transit LSRs and so require 
>>> examination at all transit LSRs.")
>>>
>>> This may not be optimal but a way to get around technical changes as you pointed out not to do so at this moment. 
>>>
>>> If we want this to be optimal and require technical changes to the draft, we can go with an alternative, utilizing [RSVP-RO] draft with ERO subobject/HOP Attributes to encode RBI or WA method as its TLVs. 
>>>
>>> Whichever the WG wants, we can go either way. 
>>>
>>> Thanks,
>>> Young
>>>
>>> -----Original Message-----
>>> From: Lou Berger [mailto:lberger@labn.net]
>>> Sent: Monday, August 04, 2014 3:44 PM
>>> To: Leeyoung; CCAMP; draft-ietf-ccamp-wson-signaling@tools.ietf.org
>>> Subject: Re: [CCAMP] Still have issues in WSON Processing HOP 
>>> Attribute Encoding in draft-ietf-ccamp-wson-signaling-08
>>>
>>> Young,
>>>    
>>> On 8/4/2014 4:29 PM, Leeyoung wrote:
>>>> Hi,
>>>>
>>>> Lou, here's my comment on your comment. In a nutshell replacing [RSVP-RO] with [RFC5420] will solve the confusion. 
>>>>
>>>> Please see in-line for details.
>>>>
>>>> Thanks,
>>>>
>>>> Young
>>> So you are saying that Resource Block Information and Wavelength Assignment Method are encoded end-to-end and *never* have hop/node/interface specific meaning (as they are each encoded as an Attribute TLV in an LSP_REQUIRED_ATTRIBUTE object), is this correct?
>>>
>>> ARE YOU SURE?  
>>>
>>> How do you envision the LSP_REQUIRED_ATTRIBUTE object conveying 
>>> per-hop information? (As discussed in section 3.2 and the first 
>>> paragraph on section 4.2.)
>>>
>>> Lou
>>> ....
>>>
>>>
>>>
>