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

Lou Berger <lberger@labn.net> Fri, 08 August 2014 11:08 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 2F73E1B2A76 for <ccamp@ietfa.amsl.com>; Fri, 8 Aug 2014 04:08:57 -0700 (PDT)
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 iZw1j-wmOJJo for <ccamp@ietfa.amsl.com>; Fri, 8 Aug 2014 04:08:45 -0700 (PDT)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 8AC071B2AD6 for <ccamp@ietf.org>; Fri, 8 Aug 2014 04:08:36 -0700 (PDT)
Received: (qmail 10791 invoked by uid 0); 8 Aug 2014 11:08:32 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy7.mail.unifiedlayer.com with SMTP; 8 Aug 2014 11:08:32 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id cB8J1o0032SSUrH01B8Mfc; Fri, 08 Aug 2014 05:08:31 -0600
X-Authority-Analysis: v=2.1 cv=Yd4uuWhf c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=24ZoOwBWUcQA:10 a=QMpH5YO3Fa8A:10 a=KOA6Ij_2hQwA:10 a=HFCU6gKsb0MA:10 a=kj9zAlcOel0A:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=__PM_kchDCMA:10 a=i0EeH86SAAAA:8 a=48vgC7mUAAAA:8 a=mtvtAMpqFFzvbQ9d5nUA:9 a=CjuIK1q_8ugA:10 a=hPjdaMEvmhQA: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:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:To:From; bh=FFk3XjfEhdCmqcOhqutWMJxzwgFldO+nG3JmpCEO2XI=; b=DhTuFVIoJIbHlN2847xoCP4TCOuTv2lnKyMTkoyyR73nWzhSnmJKlQKacTJta7KDYQUzuJbSIMVQxYaPZxbVLrokvK6MyRxWM2wkGb4WWtIoS0cAYRmGsVcCtYHyalUq;
Received: from [50.166.163.124] (port=33360 helo=[10.0.1.38]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from <lberger@labn.net>) id 1XFi1y-0000er-PQ; Fri, 08 Aug 2014 05:08:18 -0600
From: Lou Berger <lberger@labn.net>
To: Leeyoung <leeyoung@huawei.com>, CCAMP <ccamp@ietf.org>, <draft-ietf-ccamp-wson-signaling@tools.ietf.org>
Date: Fri, 08 Aug 2014 07:08:17 -0400
Message-ID: <147b54e0130.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C0920C@dfweml706-chm.china.huawei.com>
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>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.4.0.53 (build: 2100462)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 50.166.163.124 authed with lberger@labn.net}
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/SJlXkGa60j1kbnSmUqyvt0QXqfo
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: Fri, 08 Aug 2014 11:08:57 -0000

Young,

Stating with the unintended change documented in v 08 is fine with me. I am 
a bit disappointed that we haven't heard from more wg participants. Perhaps 
we're suffering from August vacations...

I'll send some purposed changes to -08.

Lou


On August 7, 2014 4:08:51 PM Leeyoung <leeyoung@huawei.com> 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
> >> ....
> >>
> >>
> >>
> >
>
>