Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label Switching Routers

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 04 February 2014 11:18 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 9A9A71A03E4 for <ccamp@ietfa.amsl.com>; Tue, 4 Feb 2014 03:18:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_FORM=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 ZsuZPVVg2QCL for <ccamp@ietfa.amsl.com>; Tue, 4 Feb 2014 03:18:54 -0800 (PST)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 18EBD1A039E for <ccamp@ietf.org>; Tue, 4 Feb 2014 03:18:53 -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 s14BInGq031211; Tue, 4 Feb 2014 11:18:49 GMT
Received: from 950129200 (3-239.197-178.cust.bluewin.ch [178.197.239.3]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s14BImrs031186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Feb 2014 11:18:49 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: huubatwork@gmail.com, 'Ramon Casellas' <ramon.casellas@cttc.es>, 'Oscar González de Dios' <ogondio@tid.es>
References: <CF1503FC.945B1%zali@cisco.com> <52EF9A9B.6040002@cttc.es> <52EFA6EA.1060903@gmail.com>
In-Reply-To: <52EFA6EA.1060903@gmail.com>
Date: Tue, 04 Feb 2014 11:18:46 -0000
Message-ID: <058901cf219a$df6e6d30$9e4b4790$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJY5s7iLBAlIpXZdQCSujbfVVmf2AIp651GAfqMUnyZcELhIA==
Content-Language: en-gb
Cc: 'CCAMP' <ccamp@ietf.org>
Subject: Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label Switching Routers
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: Tue, 04 Feb 2014 11:18:55 -0000

I think I see a general set of agreements coming along.

Appendix V.1 gives an example of needing 9 bits to encode m.
Although an Appendix is not part of the normative spec, we might assume two things from this appendix:
1. Currently only up to 8 bits are needed
2. The is a trend toward more than 8 bits

As Gabriele suggests, 16 bits is a lot. So I don't think we need to worry about extensibility if we go there.

I will update the I-D to make m 16 bits wide, and I will (continue to) say that the definition of m is per the slot width formula defined in G.694.1. This makes no comment within the draft on the legitimate values of m, but defers the data plane specification to the ITU-T.

As to describing such things in the framework, I would be opposed to an IETF document that describes the flexi-grid data plane in any detail. That is, IMNSHO, not our remit and not the scope of CCAMP. But we could ask the AD for an opinion on that ;-)

A

> -----Original Message-----
> From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Huub van Helvoort
> Sent: 03 February 2014 14:26
> To: Ramon Casellas; Oscar González de Dios
> Cc: CCAMP
> Subject: Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label Switching
> Routers
> 
> Hola Ramon,
> 
> G.694.1 does not define a maximum value for "m".
> 
> However G.697 gives in Appendix V.1: Wavelength ID.
> "m" = 9 bits (m is encoded as a 9-bit unsigned integer).
> 
> Regards, Huub.
> 
> 
>  >> I am happy if we don't need to do so. But is this not better than
> >> defining/ extending a new label format when ITU-T changes the data plane?
> >
> > Dear all,
> >
> > I may be missing something (apologies in advance if it is the case) and
> > since I don't have them here right now, for the sake of this discussion,
> > maybe could anyone point to the relevant part of the document(s) e.g.
> > G.694.1 / G.872 etc. where it is said that the value of m is bound to 256?
> > We are aware of the concept of frequency slot, nominal central
> > frequencies (n, and their values) and the concept of frequency slot
> > width, but I cannot recall now such a bound.
> >
> > Thanks
> > R.
> >
> 
> 
> --
> **************************************************************
> ***
>                请记住,你是独一无二的,就像其他每一个人一样
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp