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

Cyril Margaria <cyril.margaria@gmail.com> Tue, 05 August 2014 03:38 UTC

Return-Path: <cyril.margaria@gmail.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 0C98B1B27F3 for <ccamp@ietfa.amsl.com>; Mon, 4 Aug 2014 20:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 9_GjrbNAnJXG for <ccamp@ietfa.amsl.com>; Mon, 4 Aug 2014 20:38:13 -0700 (PDT)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F601B27F2 for <ccamp@ietf.org>; Mon, 4 Aug 2014 20:38:12 -0700 (PDT)
Received: by mail-we0-f178.google.com with SMTP id w61so319205wes.37 for <ccamp@ietf.org>; Mon, 04 Aug 2014 20:38:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TcH+5L0103bOWaj4Zw2UBPKWAO6auzlOju5JCegDayE=; b=m8ZYBjeB3gIbMEo30m4vnNiQmoLzikViTbhNSI9qSmw3NSOaborFJcH59mgd0C2Ofx 99LQwlfO25GuVOECmMgQwQZJzgOkAJV0XpS1ORT/7JOYwsK7NPXTRJv07MzuwXEh946O EqwdhMVQdNUZlNhzpG3huGo8nFF5KhtZ3ipZ8meUP/niNFmvDX37M6ix3Ii0SquecmNe +5eL2PWoLhMBw0JffmocW5Y7c3oePOEwS106YAST9mfp//QCn8+eCuFEZcrk+n0DuKlZ XGyLs+h6KNDEnnof6hIug8rZ5G3ixiAyYJykByKBlo3l6B7St+cW3FMG6zdVBrKgjXoh Tv4Q==
MIME-Version: 1.0
X-Received: by 10.194.222.5 with SMTP id qi5mr1544527wjc.62.1407209891629; Mon, 04 Aug 2014 20:38:11 -0700 (PDT)
Received: by 10.216.173.138 with HTTP; Mon, 4 Aug 2014 20:38:11 -0700 (PDT)
In-Reply-To: <53E0330B.9000706@labn.net>
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>
Date: Mon, 4 Aug 2014 23:38:11 -0400
Message-ID: <CADOd8-ta1RCwXkU3xoRStF=S=LudM-anvkhG8viSDMGVqsY3WQ@mail.gmail.com>
From: Cyril Margaria <cyril.margaria@gmail.com>
To: Lou Berger <lberger@labn.net>
Content-Type: multipart/alternative; boundary=001a11c1b326b7147304ffd99556
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/GrL2MZOon_Li0ALpqJg_Ue3wyIo
Cc: CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-wson-signaling@tools.ietf.org" <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
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, 05 Aug 2014 03:38:17 -0000

Hi,

I think that making the RB identifier globally unique in a domain is strong
constraint.
32 bit RB identifier were introduced to follow the unnumbered if id space,
allowing nodes  to use the same logic.
RB identifier space are more likely (and easily) locally-assigned ids, not
domain-globally aligned.
In addition this would make node configuration much more complicated, it
would be more error prone, and merging those administrative domains far for
seamless.

I agree with Lou that the required attributes are right for
LSP_REQUIRED_ATTRIBUTES (and could be considered for RSVP-RO, to force it
on a know transparent section). I see RBI using only RSVP-RO and not
LSP-REQUIRED-ATTRIBUTES for the reason mentioned above.

Cyril


On 4 August 2014 21:27, Lou Berger <lberger@labn.net> wrote:

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