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 > > > >
- [CCAMP] Mail regarding draft-ietf-ccamp-general-c… Adrian Farrel
- Re: [CCAMP] Mail regarding draft-ietf-ccamp-gener… Leeyoung
- Re: [CCAMP] Mail regarding draft-ietf-ccamp-gener… Leeyoung
- Re: [CCAMP] Mail regarding draft-ietf-ccamp-gener… Adrian Farrel
- Re: [CCAMP] Mail regarding draft-ietf-ccamp-gener… Adrian Farrel
- Re: [CCAMP] Mail regarding draft-ietf-ccamp-gener… Leeyoung
- Re: [CCAMP] Mail regarding draft-ietf-ccamp-gener… Lou Berger
- Re: [CCAMP] Mail regarding draft-ietf-ccamp-gener… Leeyoung
- Re: [CCAMP] Mail regarding draft-ietf-ccamp-gener… Lou Berger
- Re: [CCAMP] Mail regarding draft-ietf-ccamp-gener… Adrian Farrel
- Re: [CCAMP] Mail regarding draft-ietf-ccamp-gener… Leeyoung
- Re: [CCAMP] Mail regarding draft-ietf-ccamp-gener… Adrian Farrel
- Re: [CCAMP] Mail regarding draft-ietf-ccamp-gener… Leeyoung