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

"Adrian Farrel" <adrian@olddog.co.uk> Sun, 28 December 2014 15:56 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 776521A86EA for <ccamp@ietfa.amsl.com>; Sun, 28 Dec 2014 07:56:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.9
X-Spam-Level:
X-Spam-Status: No, score=-96.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_FROM=2.3, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 pJSEuxGrfNlu for <ccamp@ietfa.amsl.com>; Sun, 28 Dec 2014 07:56:51 -0800 (PST)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980ED1A86F6 for <ccamp@ietf.org>; Sun, 28 Dec 2014 07:56:50 -0800 (PST)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBSFuhWc028671; Sun, 28 Dec 2014 15:56:43 GMT
Received: from 950129200 (089144196101.atnat0005.highway.a1.net [89.144.196.101]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBSFufB1028643 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 28 Dec 2014 15:56:42 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> <05f601d00c9d$d5e35a70$81aa0f50$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C5D761@dfweml706-chm> <097601d00e29$660d4ca0$3227e5e0$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C5DA07@dfweml706-chm>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C5DA07@dfweml706-chm>
Date: Sun, 28 Dec 2014 15:56:44 -0000
Message-ID: <014001d022b6$e1ede180$a5c9a480$@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+sjWTEiLmBJESkHT75mFJgte4EgG2FbWLAodK7cIBGvVkVwIQ3OgVAinShP6d+2Z3oA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21208.000
X-TM-AS-Result: No--31.567-10.0-31-10
X-imss-scan-details: No--31.567-10.0-31-10
X-TMASE-MatchedRID: 8HTFlOrbAtGI0KPyMNrNUlaOpp/sV5nVNGx8ao+Wz5VrE1c4mB5Umry+ AbgLgbEp/67f+jN9ByyDqNIN5mGUKMOQecnAhEpbuIwLnB3Aqp18qFsaDjny1rl+cLJWP9lZBD2 fxTbcYN/46a69zWhmnPEcfBb5iqA2CpuZLe/V2zGzI1v7J4hECqwxCUEjPydt58v7MqNbTw/M/U lhjZwKfyWwkau9HFC6cF/AsxNS3N/uw4fb5UOuVWA/V00XWjDtL34I8IpvQcJxbzq/5b4iXXAWu ORm0TIapliFwfiZWPgt+oXPUQ+VlKWi2g/zG9Y2SHCU59h5KrG+8YVU8r+aqM1BXOF9hjmyuwJl h8th33FhWE87Wm/AatPM7q3GYc3LbXK/7rgzL95DP8uRDLPyZuD8QblN6KNVhc+Jw4LMtcDQUnf gr5SMKLA0qasmWOM0W0mM9XFuCEy8gZ3CDqQ7fPnCl+sgkNd7BdebOqawiLsCFDipSeunnE42Kx kK7ucbTx7sMqrj3/Ay3+shJPXKqHsRVu35DItMbBu6+EIezdwsCc2iFTIxrd14Aqe8EzF8UCGUR MUMPT30Q/qVi/M29RO1LOiZ70hnNYO4oQt1fr7Y5KPiokD1BhlYUUPTpSKSFI12R/0aTZuUfpET B+BNo0jNhuJ5nO86HTpFicpO5Hh12dvTysHrbHpwT5vp/xal7ux50y4R2diFmddrIUs34sEYHnJ ZxFh9wHzYvPeYJMzCpS1REqn926it8bTkCLiD8jbzfqNu/QSVZfG8cr6tXup7wgGRqw6kIZnpVU 5Vh5YAfBN/i6OHPGd5QUatALTD8akDfOEEt3ueAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtlExlQIQeRG0=
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/ObV5XPZXY-QkpjFNP1uu_lO6-R4
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, 28 Dec 2014 15:56:53 -0000

Looks like no-one in the WG had anything to say about these changes. I was
hoping someone else was reading them, after all, the WG (and perhaps your
co-authors) is supposed to be interested in publication of the document.

Well, since you were waiting for me before posting a revision, here are my
comments. After you have fixed them, please post a new version and we will
continue.

Thanks,
Adrian

---

New text in Section 2 has some typos
> {sr port, src label, sdt port, dst label}. 

---

Section 2
When you reduced the Connectivity field to 4 bits you moved the Matrix ID field
onto a 4 bit boundary. That's OK if it is what you want to do, but it is also
unusual.

---

Section 2.4
I think your new text is not quite right.

> When a label is marked by an LSP of priority M and available, an LSP  
> of priority N (N<=M) can use it only when it is not already in use.  

I don't think this makes sense. You seem to be trying to say two things in one
paragraph. Perhaps...

When a label is advertised as available for priorities 0, 1, ... M it may be
used by any LSP of priority N <= M.
When a label is in use by an LSP of priority M is may be used by an LSP of
priority N < M if LSP preemption is supported.

---

In 2.5
> If a label is available
> at priority M it MUST be available at each priority N < M.

Yeah, but you need to say what has to be in the advertisement. So...

  If a label is available
  at priority M it MUST be advertised as available at each priority N < M.

Otherwise people will think that setting just one bit is OK and that the
availability at other priorities is inferred.

---

The length field in your final example in A.2 seems to have got worse!
8*4=32 (I think)

---



In Section 2.5
> The same LSP set up and pre-emption rules specified in Section 2.5  
> apply here. 
s/2.5/2.4/





> -----Original Message-----
> From: Leeyoung [mailto:leeyoung@huawei.com]
> Sent: 02 December 2014 16:57
> 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,
> 
> Thanks for your further details. Please see inline for my response.
Diff-marked
> file attached for your check. Please let me know if we need further trimming
> down or this is ready to move on. Thanks.
> 
> Best regards,
> Young
> 
> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Tuesday, December 02, 2014 6:14 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
> 
> I think we're very nearly there. Thanks for chasing the last details.
> 
> Trimming down still further...
> 
> > >> Section 2.4
> >
> > 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."
> 
> I think what you are doing here is describing RSVP-TE pre-emption. If so, it
is
> better to leave that in 3209.
> 
> I think you just need text like...
> 
> "The PRI field indicates the availability of the labels for use in LSP set up
> and pre-emption as described in [RFC3209]."
> 
> YOUNG>> Thanks, will include the suggested text.
> 
> > 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."
> 
> OK, but do you have a way to advertise "in use at priority N"?
> I think it could be done with a new field.
> Or it could be done by changing "available for 0--M" to "available for
0--(N-1)"
> (where N<=M)
> 
> YOUNG>> Aha...I would do it by changing "available for 0---M" to available for
0--
> -(N-1) (where N<=M) to avoid introducing a new field. Thanks for this great
> suggestion. So I would introduce the following text in Section 2.5:
> 
> "When a label is marked by an LSP of priority M and available, an LSP of
priority N
> (N<=M) can use it only when it is not already in use."
> 
> "When a label was initially advertised as available for priorities, 0, 1,...,M
and once
> a label is used for an LSP at a priority, say N (N<=M), then this label is
advertised
> as available for 0,...,N-1."
> 
> And in Section 2.6:
> 
> "The same LSP set up and pre-emption rules specified in Section 2.5 apply
here."
> 
> > > 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."
> 
> While I can accept that the way to encode priority 7 is 0b11111111, the text
> doesn't say that! The text says you set one bit for each priority that is
> allowed, and that has to be read in conjunction with "if it is available at
> priority M it MUST be available at each priority N < M" if you want to arrive
at
> the right result.
> 
> YOUNG>> I would still stick to a bit field (the next discussion) as this was a
WG
> decision. In light of that decision, I agree with you that we need an
additional
> phrase you suggested: "If a label is available at
> priority M it MUST be available at each priority N < M" (In Sections 2.5 and
2.6)
> 
> But...
> 
> > 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?
> 
> I really think that using a bit field is just going to cause confusion.
> It has led us to spend a lot of time already trying to fathom how the bits are
> to be set and interpreted.
> We have ended up with you explaining that if I set bit N I must also set bit n
> for n = 0 to N-1.
> So, you have stated that there are only 8 valid settings of the PRI field (0,
> x80, xC0, xE0, xF0, xF8, xFC, xFE, xFF).
> It would seem easier (to me) to have the only 8 settings of the PRI field be
(0,
> 1, 2, 3, 4, 5, 6, 7)
> 
> Please note that RFC 3209 uses a one byte field to encode an integer in the
> range 0 to 7. Just because there are eight bits available doesn't mean it is a
> bit field! (I am now thinking, OMG, how many people have implemented Holding
> Priority and Setup Priority as bit fields?)
> 
> YOUNG>> I am afraid to say that this happened already in some implementation.
> 
> Now, and to be completely clear, I am not saying to the WG "I wouldn't have
> done
> it like this." The WG is free to choose how to encode PRI.
> So, if you want to remain as a bit map, that's OK. You'll just have to spend
> some more time getting the description clear.
> 
> YOUNG>> I would stick to what it is. I added the description clear: "If a
label is
> available at
> priority M it MUST be available at each priority N < M" (In Sections 2.5 and
2.6)
> 
> > >> 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?
> 
> Not about making me comfortable! (But thanks for caring :-)
> It's about doing the right thing.
> 
> Does the WG think it is OK as it is and provides enough scope for generic use?
> If so, move on.
> If not, what are the implications of allowing up to 2^20 bits in the bit map?
> Because that is a lot of bytes!
> 
> YOUNG>> I would stay as it is. Thanks.
> 
> 
>