Re: [CCAMP] Mail regarding draft-ietf-ccamp-general-constraint-encode

Lou Berger <lberger@labn.net> Tue, 02 December 2014 00:19 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 508B71ACD63 for <ccamp@ietfa.amsl.com>; Mon, 1 Dec 2014 16:19:13 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 zktmh5DBHp8C for <ccamp@ietfa.amsl.com>; Mon, 1 Dec 2014 16:19:10 -0800 (PST)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id CE7F31ACCE6 for <ccamp@ietf.org>; Mon, 1 Dec 2014 16:19:09 -0800 (PST)
Received: (qmail 20923 invoked by uid 0); 2 Dec 2014 00:19:09 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy8.mail.unifiedlayer.com with SMTP; 2 Dec 2014 00:19:09 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id NQJx1p0082SSUrH01QK0Tw; Mon, 01 Dec 2014 17:19:09 -0700
X-Authority-Analysis: v=2.1 cv=dfgTgxne c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ORHgswgCnHsA:10 a=kj9zAlcOel0A:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=COqbBuI_nLcA:10 a=A92cGCtB03wA:10 a=i0EeH86SAAAA:8 a=AEDFM0qtAAAA:8 a=48vgC7mUAAAA:8 a=evG6XcbW5uUEr6tO6NgA:9 a=WQedgWL8d4dkzsGq:21 a=j2DyuRp7O4de6kk_:21 a=pxkTjRF1yfiNLMne:21 a=CjuIK1q_8ugA: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:CC:To:From; bh=EXh9X0MMObLkXPmXq+tkAbDdQ8hj+lGfSvShvOU3yQ4=; b=lnT4cN0MF+ThtsjsKqeqBoTLcGk0X7gf6dEz4iIaqeDVMxKlDsYXiAcDi9bFFbzxrun3kEXIyzyH79fShAM6EN3bhjqnsy4hLgzcyHVkOtu+E8kZMLYTjh6Q+KcUxQ1a;
Received: from [72.83.36.100] (port=44512 helo=[11.4.0.117]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from <lberger@labn.net>) id 1XvbBA-0002O9-Fy; Mon, 01 Dec 2014 17:18:57 -0700
From: Lou Berger <lberger@labn.net>
To: Leeyoung <leeyoung@huawei.com>, adrian@olddog.co.uk, draft-ietf-ccamp-general-constraint-encode@tools.ietf.org
Date: Mon, 01 Dec 2014 19:18:54 -0500
Message-ID: <14a085d29f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C5D81A@dfweml706-chm>
References: <059401d006fa$43247dc0$c96d7940$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C4E597@dfweml706-chm> <05f601d00c9d$d5e35a70$81aa0f50$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C5D761@dfweml706-chm> <547CF689.7010901@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C5D81A@dfweml706-chm>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.0.19 (build: 2100846)
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 72.83.36.100 authed with lberger@labn.net}
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/YX-UuSLNMJh8QSdJ6kpOhnGoHUQ
Cc: ccamp@ietf.org, Adrian Farrel <afarrel@juniper.net>
Subject: Re: [CCAMP] Mail regarding draft-ietf-ccamp-general-constraint-encode
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, 02 Dec 2014 00:19:13 -0000

Inform ... and wg support ...

Lou


On December 1, 2014 6:19:31 PM Leeyoung <leeyoung@huawei.com> wrote:

> Lou,
>
> Absolutely, if there are any changes such as field sizes, I will inform the 
> WG of the change. I hope we don't have to go into that.
>
> Thanks,
> Young
>
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Monday, December 01, 2014 5:15 PM
> To: Leeyoung; adrian@olddog.co.uk; 
> draft-ietf-ccamp-general-constraint-encode@tools.ietf.org
> Cc: ccamp@ietf.org
> Subject: Re: [CCAMP] Mail regarding draft-ietf-ccamp-general-constraint-encode
>
> Young,
> 	Please keep in mind that *any* changes that impact behavior on the wire
> will need to be reviewed by the WG.  Changes in requirements language is
> pretty easy to make, but changing field sizes is another matter. -- Not
> saying it can't be done, and in fact, better now than in the field, but
> changes should be explicitly reviewed and discussed in the WG.
>
> Keep going as is, and let the WG know once a change is warranted.
>
> Lou
>
> On 12/01/2014 04:00 PM, Leeyoung wrote:
> > Hi Adrian,
> >
> > Thanks for providing further comment. Please see in-line for my response 
> to your comment.
> >
> > Best regards,
> > Young
> >
> > -----Original Message-----
> > From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> > Sent: Sunday, November 30, 2014 7:02 AM
> > To: Leeyoung; draft-ietf-ccamp-general-constraint-encode@tools.ietf.org
> > Cc: ccamp@ietf.org
> > Subject: RE: [CCAMP] Mail regarding 
> draft-ietf-ccamp-general-constraint-encode
> >
> > Hi Young,
> >
> > I've taken the email you attached and copied in the relevant parts below.
> >
> > This is good progress and everything I have deleted is a good change.
> >
> > This leaves us with just a few remaining points...
> >
> >>> Section 2 uses [RWA-Info] in a normative way. Please move
> >>> the referenced document into the Normative References
> >>> section.
> >>
> >> YOUNG>> When I moved [RWA-Info] to normative reference, the
> >> IDINIT gave me an error, so I moved it back to where it was.
> >
> > I think the issue that idnits will report is that this reference
> > is to a downref to an informational I-D.
> >
> > Two points:
> > 1. Don't worry about it being a reference to an I-D. That draft
> >    has completed IETF last call and is in IESG evaluation. It will
> >    be an RFC before this I-D becomes an RFC.
> > 2. A downref is what it is. You make a normative reference to an
> >    informative document, you create a downref. But that's OK. Just
> >    do what you have to do and we call it out in IETF last call.
> >
> > So, if [RWA-Info] is used as a normative reference, just make the
> > change. If you don't think it is, or you think it should not be,
> > then we can have that discussion.
> >
> > YOUNG>> I think [RWA-Info] is a normative reference. I will make change.
> > ---
> >
> >>> Section 2.3
> >>>
> >>>   All Local Interface IP Address are supplied in
> >>>   the context of the advertising node
> >>>
> >>> Aren't IP addresses scoped a little more widely?
> >>
> >> YOUNG>> Not sure if you meant IPv6? If so, why is it a little
> >> more widely?
> >
> > Sorry, I was too terse.
> >
> > You write that the IP addresses are supplied "in the context of" the
> > advertising node. I wonder what that means.
> >
> > I think this is the result of a bad block copy. You have...
> >
> >          0 -- Link Local Identifier
> >
> >    Indicates that the links in the Link Set are identified by link
> >    local identifiers. All link local identifiers are supplied in the
> >    context of the advertising node.
> >
> > ...which is perfectly reasonable.
> >
> > So you probably just mean...
> >
> >          1 -- Local Interface IPv4 Address
> >
> >          2 -- Local Interface IPv6 Address
> >
> >    Indicates that the links in the Link Set are identified by Local
> >    Interface IP Address.
> >
> > YOUNG>> Yes, it is clear. I would delete "All Local Interface IP Address 
> are supplied in the context of the advertising node."
> >
> > ---
> >
> >>> Section 2.4
> >>>
> >>> Priority needs some explanation or reference. Priority with
> >>> respect to what?
> >>>
> >>>   At least one priority
> >>>   level MUST be advertised that, unless overridden by local policy,
> >>>   SHALL be at priority level 0.
> >>>
> >>> I cannot parse this at all!
> >>
> >> YOUNG>> Priority is applied to the LSPs being setup or backup
> >> LSPs being setup. This field gives what labels are available to
> >> certain priority level associated with LSPs. I would add:
> >
> > Oh. Are you modelling this on the bandwidth availability fields of the
> > Interface Switching Capability Descriptor sub-TLV of the Link TLV in
> > OSPF for GMPLS?
> >
> > YOUNG>> Yes.
> >
> > You appear to be suggesting that some labels can be reserved for use by
> > LSPs of specific priorities. This is stricter and more constraining than
> > the bandwidth partitioning described in RFC 4202, but that's OK if that
> > is what people want to do.
> >
> > YOUNG>> Yes.
> >
> >> Note that the PRI flag identifies the priority of the LSP which is
> >> being set up. (Section 2.4)
> >>
> >> Note that the PRI flag identifies the priority of the backup LSP
> >> which is being set up. (Section 2.5)
> >
> > I think some more careful text is needed. The point I want to draw out
> > is that the priority you are describing here is not the priority of the
> > LSP being set up (which is what you are writing) but the availability
> > of a label for use by an LSP of a specific priority if an attempt is
> > made to set one up.
> >
> > YOUNG>> Yes, how about the following?:
> >
> > Note that the PRI flag identifies the availability of a label for use by 
> an LSP of a specific priority if an attempt is made to set one up. (Section 
> 2.4)
> >
> > Note that the PRI flag identifies the availability of a label for use by 
> a backup LSP of a specific priority if an attempt is made to set one up. 
> (Section 2.5)
> >
> >
> > You'll also need to explain how this factors in with preemption. Can
> > an LSP of priority 0 use a label marked as priority 3? If so, can it
> > use it:
> > - only when all priority 0, 1, and 2 labels have been used?
> > - only when it is not already in use for a priority 1, 2, or 3 LSP?
> > - at any time?
> >
> > YOUNG>> When a label is marked as priority N, this implies that the label 
> can be usable by any priorities 1, 2, ... N at any time. (This is for 
> setting up an LSP). In regards to preemption, how about the following 
> statement added to the text:
> >
> > "For preemption, the following rule applies: When a label is marked by an 
> LSP of priority N and available, an LSP of priority M (M<N) can use it only 
> when it is not already in use.
> >
> >
> > In the light of answers to those questions, how will you advertise
> > labels that are already in use on an interface? For example, suppose a
> > label was initially advertised as available for priorities, 0, 1, 2, and
> > 3. An LSP at priority 2 is set up using this label. Will you now
> > withdraw its advertisement (not available) or will you advertise it as
> > available at priorities 0 and 1? Or maybe you want to advertise it as in
> > use at priority 2 so that path computation can decide whether to
> > preempt or not.
> >
> > YOUNG>> Good question. I think the best choice is the last case. Once a 
> label is used, then advertise it as in use at priority "N" ("N" in which an 
> LSP at Priority "N" is set up using this label) so that path computation 
> can decide whether to preempt or not.
> >
> > I would add the following sentence:
> >
> > "Once a label is used for an LSP at a priority, say N, then this label is 
> advertised as in use at priority N."
> >
> >> Regarding "At least one priority
> >> level MUST be advertised that, unless overridden by local policy,
> >> SHALL be at priority level 0." --- I see the issue. There was a mixed
> >> up between priority 7 (lowest) and priority 0 (highest). It should
> >> have been priority level 0 which is in effect has no priority of
> >> labels so that any LSP level can grab such labels.
> >
> > What you have written here opens up something equally confusing. The
> > field in question is a bit map and is described as
> >
> >    A bit MUST be set (1) corresponding to each priority
> >    represented in the sub-TLV
> >
> > That clearly implies that more than one bit can be set. Yet you are
> > saying (I think) that setting bit 7 implies that the label is
> > available at all priorities. So why do you need a bit field and not
> > a simple integer?
> >
> > YOUNG>> Actually, to encode priority 7, it should be [1 1 1 1 1 1 1 1]. 
> Please note the description:
> >
> > "A bit MUST be set (1) corresponding to each priority represented in the 
> sub-TLV, and MUST NOT be set (0) when the corresponding priority is not 
> represented. At least one priority level MUST be advertised."
> >
> > I cannot recall why we decided to use a bit field as opposed to a simple 
> integer. I believe we used a bit field because RFC 3209 uses 8 bits for 
> Setup/Holding Priority in Section 4.7.2, the original contributor of this 
> section/encoding (I believe it was Rajan Rao) used 8 bit field. Do you 
> think this would be a problem?
> >
> >> How about:
> >>
> >> OLD:
> >>   At least one priority level MUST be advertised that, unless
> >>   overridden by local policy, SHALL be at priority level 0.
> >> NEW:
> >>   At least one priority level MUST be advertised.
> >
> > This change is fine, but on its own it doesn't address the other issues.
> >
> > YOUNG>> I hope this is related with the above explanation.
> >
> > ---
> >
> >>> 2.6.3
> >>>
> >>> Only support 4096 labels in a bitmap set? Really?
> >>
> >> YOUNG>> Yes, 2 ^^ 12 = 4096. It was originally written in the
> >> context of wavelength. Would this be sufficient?
> >
> > If you and the WG are OK with this, I suppose I am.
> >
> > You have 256 sub-matrices so you are allowing 2^20 labels which is,
> > I suppose, a good thing if you are trying to be generic and support
> > packet as well as wavelength.
> >
> > Of course, the sub-matrix approach does not allow a full 2^20 grid.
> >
> > To be clear, my concern is that you make this document (that claims to
> > be generic) sufficient to handle all manner of technologies from fine-
> > grained OTN, through flexi-grid, Ethernet, and packet.
> >
> > Perhaps it is OK to assume that limited cross-connect will be more
> > likely in wavelength systems and less likely in fine-grained systems.
> >
> > Recall that the worst case is that the label space is entirely
> > fragmented so that ranges don't work and every second label must be
> > explicitly reported.
> >
> > YOUNG>> Should I increase the Num Labels to be 20 bits if that makes you 
> comfortable?
> >
> > ---
> >
> > And finally, a new point, I'm afraid. Section 2 says...
> >
> >    The encodings are
> >    designed to be suitable for use in the GMPLS routing protocols OSPF
> >    [RFC4203] and IS-IS [RFC5307] and in the PCE protocol (PCEP)
> >    [RFC5440].
> >
> > It may be true that you have designed this information to be used in
> > PCEP, but PCEP doesn't carry resource availability information. Doesn't
> > that mean that designing for use in PCEP is "ambitious"?
> >
> > YOUNG>> PCEP for WSON is coming along... :) At least some if not all may 
> be applicable, which is yet to be determined.
> >
> > Thanks for the work,
> > Adrian
> >
> >
> >> -----Original Message-----
> >> From: Leeyoung [mailto:leeyoung@huawei.com]
> >> Sent: 24 November 2014 06:38
> >> To: adrian@olddog.co.uk; draft-ietf-ccamp-general-constraint-
> >> encode@tools.ietf.org
> >> Cc: ccamp@ietf.org
> >> Subject: RE: [CCAMP] Mail regarding 
> draft-ietf-ccamp-general-constraint-encode
> >>
> >> Hi Adrian,
> >>
> >> Attached is an email I sent (on Nov 4) in response to your AD review. Please
> > let
> >> me know if you have any question.
> >>
> >> Thanks,
> >> Young
> >>
> >> -----Original Message-----
> >> From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel
> >> Sent: Sunday, November 23, 2014 2:49 AM
> >> To: draft-ietf-ccamp-general-constraint-encode@tools.ietf.org
> >> Cc: ccamp@ietf.org
> >> Subject: [CCAMP] Mail regarding draft-ietf-ccamp-general-constraint-encode
> >>
> >> Hello,
> >>
> >> Where do we stand on a revision of this I-D to address my review?
> >>
> >> This is gating progress of
> >> - draft-ietf-ccamp-wson-signaling
> >> - draft-ietf-ccamp-wson-signal-compatibility-ospf
> >> - draft-ietf-ccamp-gmpls-general-constraints-ospf-te
> >> - draft-ietf-ccamp-rwa-wson-encode
> >>
> >> Thanks,
> >> Adrian
> >>
> >> _______________________________________________
> >> 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
> >
>
>