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

"Zafar Ali (zali)" <zali@cisco.com> Mon, 03 February 2014 13:45 UTC

Return-Path: <zali@cisco.com>
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 425161A03FA for <ccamp@ietfa.amsl.com>; Mon, 3 Feb 2014 05:45:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.736
X-Spam-Level:
X-Spam-Status: No, score=-9.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 bq8ElhOWEOTl for <ccamp@ietfa.amsl.com>; Mon, 3 Feb 2014 05:44:57 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id EE78B1ADE84 for <ccamp@ietf.org>; Mon, 3 Feb 2014 05:29:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9200; q=dns/txt; s=iport; t=1391434180; x=1392643780; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=OkMYRqimHaTGE/aEFMnMAzNx8gHiwxpkamCSU4NdsDo=; b=OIYMfrz3d8NUV9dgahlBqBULKlPS2jdGCoXNJ9ksfATcwF0nlkT4F9/W aceCFoT25nOKv9R45oBJrUkLDZTryRkppiuhm00mhxHIzGp54iIIr4Ufi hpSH2vmTiAYxM/wovlwgKrhpNmaNu7HsYkg3Q5kHaUluVI66NIJTNSTba c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiYFAFuZ71KtJXG8/2dsb2JhbABZgww4V4MBuwgYbxZ0giUBAQEEIwQNRQwGAQYCEQMBAQEBAgIREgMCBB8RFAEICAIEAQ0FG4dWAxENjxmbcZdoDYkzF4Epi0qBPiUIEBsHBAIEgmWBSQSWPoFsgTKGIoUKhUOBb4E+gWhC
X-IronPort-AV: E=Sophos;i="4.95,772,1384300800"; d="scan'208";a="17517514"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-7.cisco.com with ESMTP; 03 Feb 2014 13:29:39 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s13DTdBU027708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Feb 2014 13:29:39 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.71]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Mon, 3 Feb 2014 07:29:39 -0600
From: "Zafar Ali (zali)" <zali@cisco.com>
To: "huubatwork@gmail.com" <huubatwork@gmail.com>, Iftekhar Hussain <IHussain@infinera.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Oscar González de Dios <ogondio@tid.es>, "Giovanni Martinelli (giomarti)" <giomarti@cisco.com>, Ramon Casellas <ramon.casellas@cttc.es>
Thread-Topic: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label Switching Routers
Thread-Index: AQHPHo1BydwR2IGn0keMwppSynySeZqfWVOAgAAFhICAAAU/AIAAAKAAgAQPSgD//8wDgIAAaU0A///y3YA=
Date: Mon, 03 Feb 2014 13:29:38 +0000
Message-ID: <CF1503FC.945B1%zali@cisco.com>
In-Reply-To: <52EF5EEC.6050602@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.86.240.107]
Content-Type: text/plain; charset="utf-8"
Content-ID: <445E9D60120B3A4DAFC47001AD850460@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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
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: Mon, 03 Feb 2014 13:45:00 -0000

Hi- 

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?

Thanks

Regards … Zafar


-----Original Message-----
From: Huub van Helvoort <huubatwork@gmail.com>
Reply-To: "huubatwork@gmail.com" <huubatwork@gmail.com>
Date: Monday, February 3, 2014 4:18 AM
To: zali <zali@cisco.com>, "Iftekhar com>" <IHussain@infinera.com>,
Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Oscar de Dios
<ogondio@tid.es>, "Giovanni Martinelli (giomarti)" <giomarti@cisco.com>,
"ramon.casellas@cttc.es" <ramon.casellas@cttc.es>
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label
Switching Routers

>Hello Zafar,
>
>Do you mean that every time the ITU needs another bit the RFC has to
>be changed, e.g. now define/use 8 bits and in the future 9 or 10...
>
>Regards, Huub.
>
>
>> I agree and don't see any strong reason for why CCAMP should not go with
>> m=16. However, at the moment we can say that usage of only x number of
>> bits is define (to match current DP definition in ITU-T).
>>
>> Thanks
>>
>> Regards … Zafar
>>
>>
>> -----Original Message-----
>> From: "Iftekhar com>" <IHussain@infinera.com>
>> Date: Monday, February 3, 2014 1:07 AM
>> To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Oscar de Dios
>> <ogondio@tid.es>, "Giovanni Martinelli (giomarti)" <giomarti@cisco.com>,
>> "ramon.casellas@cttc.es" <ramon.casellas@cttc.es>
>> Cc: "ccamp@ietf.org" <ccamp@ietf.org>
>> Subject: Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label
>> Switching Routers
>>
>>> This is a very interesting discussion.  I believe extending the value
>>>of
>>> m to 16-bit makes sense. BTW, that is why in our label definition we
>>>had
>>> proposed a 16-bit for the m to begin with.
>>>
>>> Regarding "why not", all along there has been recurring theme of not
>>> getting ahead of ITU definitions. So I am afraid, we can be selective.
>>> Having said this, if the collective wisdom is to go ahead - that is
>>>fine
>>> with me. But then let us look at all aspects and solutions (routing,
>>> signaling, etc.).
>>>
>>> Regarding the "entire spectrum slot is feasible", I agree. So let us
>>> first start with discussing/capturing this requirement/use case in the
>>> framework document?
>>>
>>> Best regards,
>>> Iftekhar
>>> -----Original Message-----
>>> From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
>>> Sent: Friday, January 31, 2014 8:08 AM
>>> To: Oscar González de Dios; Giovanni Martinelli (giomarti); Ramon
>>>Casellas
>>> Cc: CCAMP
>>> Subject: Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label
>>> Switching Routers
>>>
>>>>> My thoughts, exactly, although no strong opinion. I guess the other
>>>>> question would be "why not"?
>>>
>>> +1
>>>
>>> We still have 16 bits reserved...
>>>
>>> BR
>>> Daniele
>>>
>>>> -----Original Message-----
>>>> From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Oscar
>>>> González de Dios
>>>> Sent: venerdì 31 gennaio 2014 17:06
>>>> To: Giovanni Martinelli (giomarti); Ramon Casellas
>>>> Cc: CCAMP
>>>> Subject: Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC
>>>> Label Switching Routers
>>>>
>>>> Hi, my 2 cents...
>>>>
>>>>    With the encoding, you should be able to describe a frequency slot
>>>> as big as the whole spectrum available in the band. If 8 bits (that
>>>> give a width of
>>>> 1593,75 GHz using the granularity of 6,25) is not enough, then it MUST
>>>> be extended to a bigger value. The flexi-grid framework allows a
>>>> hierarchy of frequency slots, so the ³entire spectrum² slot is
>>>> feasible and in line with current ITU recommendations. We are not
>>>> saying a single signal uses that amount of spectrum.
>>>>
>>>>
>>>>   Oscar
>>>>
>>>>
>>>> El 31/01/14 16:47, "Giovanni Martinelli (giomarti)"
>>>> <giomarti@cisco.com>
>>>> escribió:
>>>>
>>>>>
>>>>> On 31 Jan 2014, at 16:27, Ramon Casellas <ramon.casellas@cttc.es>
>>>> wrote:
>>>>>
>>>>>> El 31/01/2014 15:03, Loa Andersson escribió:
>>>>>>> Adrian,
>>>>>>>
>>>>>>> I do not have any problem with that, unless there is a intended
>>>>>>> use of the reserved field.
>>>>>>>
>>>>>> Loa, Adrian, all,
>>>>>>
>>>>>> My thoughts, exactly, although no strong opinion. I guess the other
>>>>>> question would be "why not"?
>>>>>> If, as Adrian mentions, we constrain the its use as defined in
>>>>>> G.694.1 while leaving room for growth, at least the encoding would
>>>>>> be more likely be reused (as opposed to the WSON -> SSON).
>>>>>>
>>>>>
>>>>> GM> is not mere reuse but future protocol compatibility.  Sounds to
>>>>> GM> me
>>>>> that¹s better to allocate few more bits know than looking for them in
>>>>> the future. Btw, to answer Loa doubts, there¹s no idea about how
>>>>> using reserved bits right now.
>>>>>
>>>>> Cheers
>>>>> G
>>>>>
>>>>>
>>>>>> For what is worth, individual drafts that are considering extending
>>>>>> RSVP-TE for signaling media channels would also be affected. The
>>>>>> underlying idea is to propose new types for the sender template and
>>>>>> the flowspec in the flow descriptor to accommodate for the requested
>>>>>> and allocated slot width. Right now, only the "m" parameter is
>>>>>> encoded with the corresponding padding/reserved bytes.
>>>>>>
>>>>>> Regards,
>>>>>> Ramon
>>>>>>
>>>>>> PS: much like Adrian's draft, the label encoding proposed in
>>>>>> http://tools.ietf.org/html/draft-li-ccamp-flexible-grid-label-00
>>>>>> also took into account the fact that a reduced number of bits would
>>>>>> suffice to cover G.694.1
>>>>>>
>>>>>>> On 2014-01-31 19:44, Adrian Farrel wrote:
>>>>>>>> Hi Gabriele,
>>>>>>>>
>>>>>>>> IIRC this topic has come up in various discussions.
>>>>>>>> I think the discussion ran aground when we tried to understand
>>>>>>>> what ITU-T SG15
>>>>>>>> Q6 data plane capabilities this increased value of "m" modelled.
>>>>>>>>
>>>>>>>> I believe that we could easily increase the size of the m field,
>>>>>>>> but as I  understand the status of the Q6 work, we would still
>>>>>>>> need to constrain its use  as defined in G.694.1. Maybe that is
>>>>>>>> the best
>>>>>>>> compromise: it gives us scope for  future expansion, but it makes
>>>>>>>> (for now) the value strictly limited according to  the current
>>>>>>>> definition of the data plane we are controlling.
>
>
>-- 
>*****************************************************************
>               请记住,你是独一无二的,就像其他每一个人一样