Re: [CCAMP] Mail regarding draft-ietf-ccamp-general-constraint-encode
"Adrian Farrel" <adrian@olddog.co.uk> Sun, 30 November 2014 13:02 UTC
Return-Path: <adrian@olddog.co.uk>
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 D73BF1A00F5 for <ccamp@ietfa.amsl.com>; Sun, 30 Nov 2014 05:02:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.001
X-Spam-Level:
X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 NyHplFV62sjh for <ccamp@ietfa.amsl.com>; Sun, 30 Nov 2014 05:02:21 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B614F1A00B5 for <ccamp@ietf.org>; Sun, 30 Nov 2014 05:02:20 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id sAUD25Mt014022; Sun, 30 Nov 2014 13:02:05 GMT
Received: from 950129200 ([149.254.186.148]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id sAUD23or014015 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 30 Nov 2014 13:02:05 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Leeyoung' <leeyoung@huawei.com>, draft-ietf-ccamp-general-constraint-encode@tools.ietf.org
References: <059401d006fa$43247dc0$c96d7940$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C4E597@dfweml706-chm>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C4E597@dfweml706-chm>
Date: Sun, 30 Nov 2014 13:02:01 -0000
Message-ID: <05f601d00c9d$d5e35a70$81aa0f50$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQD+sjWTEiLmBJESkHT75mFJgte4EgG2FbWLngx/89A=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21140.007
X-TM-AS-Result: No--21.414-10.0-31-10
X-imss-scan-details: No--21.414-10.0-31-10
X-TMASE-MatchedRID: 8HTFlOrbAtGBnJ5ETtWXfQCwcUB5CbVqfLPKYyLDlAdLjXXGQy6nlIP+ YDa/Dhu9g9qGGwiBgQZCcfCEbwy8mg7WYEeNmTZn85L5JHGOAXArHkgIan9a0Wquw69QUQrL9BQ FWu9qPYasRiy0190rtY4r8X/s3fgSavaCW5zqiNopa6LJktEjgDDK+BrjR19aYz65TQfoDKui53 lxf0EQ0561I1jwKbISyDhr7IruFkyX8atgS7Yv2IbBPrt55wnwX+sxr/a0LGjSYAzZ6KmqWv2Ku aqAQwlD+naNJLwSJ6kdIku7+9OjPRwWcp9rVIRcXP5rFAucBUEpq7l+pMQuk5gWnaLDiGghB7XW BXOexYUAczVa8CFzX3z3h8f8rvig3yrJOsLaRnn0hv/rD7WVZI8XIw+hLgbPInzOyTDR1usmaIE OOTCvRYN62a4Gb26h6RDyQrqYBWKewo7UNFLLPd1AWya8PZoX8rPh3yI68cljEYffELkJAMprMg +WQ2IiZClGcL9tHyeAmNq8Y5gGYJOD/r6k201RACs2C3nGlBhezmeoa8MJ82IBSgSVB+WjdE7AB QfxM9d4boln+0mdvsRab/kqwX/XpgJfRIroQYl14YvTNMD3hSlayzmQ9QV047E6rstCUYsCYv9g yH6vUR27Gc4HL7kEMWfPqIhN3J6Kx7xD7ImGetNtHlqACwPXNjuRIfuOU0fNyfof8Fi1fXAWuOR m0TIa7rYjKjSGs+0t+oXPUQ+VlILZBzOZKTcQuZH4LSX2+NXWSrKtwxqWpSf6nnnZywjVlicJiN 9fUhGCexSMe66++ZYlxuk1ogQA+zoAW8R15l+eAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtlExlQIQeRG0=
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/RrAIA42owwr1SHe87YeOq-86gws
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Mail regarding draft-ietf-ccamp-general-constraint-encode
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Sun, 30 Nov 2014 13:02:25 -0000
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. --- >> 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. --- >> 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? 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. > 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. 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? 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. > 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? > 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. --- >> 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. --- 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"? 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] 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