Re: [CCAMP] R: G.709 signaling - encoding Type

Lou Berger <lberger@labn.net> Wed, 20 March 2013 13:52 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F2821F8CA4 for <ccamp@ietfa.amsl.com>; Wed, 20 Mar 2013 06:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_73=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBmYGDTpb-gL for <ccamp@ietfa.amsl.com>; Wed, 20 Mar 2013 06:52:53 -0700 (PDT)
Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id A3F1021F8CA0 for <ccamp@ietf.org>; Wed, 20 Mar 2013 06:52:52 -0700 (PDT)
Received: (qmail 18824 invoked by uid 0); 20 Mar 2013 13:52:29 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 20 Mar 2013 13:52:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=FgVPr53vD7QmZeogGa9XN4OIy6LZgpd7GOvhbT/NfK0=; b=oVWHN2IhmBrfqKhnSFaCtgX7PTw4Yec+XxFhxNWYDoE1fnTmrE65de6Z0h+Ad18n709/lkTUzZQuN2pAFUlbrzMtXdkdwRlIJGgdOfTym6OPPtdSW6u8XwQ34Y+V2813;
Received: from box313.bluehost.com ([69.89.31.113]:58476 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1UIJRN-00031G-DZ; Wed, 20 Mar 2013 07:52:29 -0600
Message-ID: <5149BF1F.7070905@labn.net>
Date: Wed, 20 Mar 2013 09:52:31 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Fatai Zhang <zhangfatai@huawei.com>
References: <650AA355E323C34D9D4AAEED952E053D3FB173C6@SV-EXDB-PROD2.infinera.com> <B9FEE68CE3A78C41A2B3C67549A96F4801C044@FR711WXCHMBA05.zeu.alcatel-lucent.com> <0182DEA5604B3A44A2EE61F3EE3ED69E1B2BA7D1@BL2PRD0510MB349.namprd05.prod.outlook.com> <13d65dd005e.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1B2BBB14@BL2PRD0510MB349.namprd05.prod.outlook.com> <514103A5.3010609@labn.net> <650AA355E323C34D9D4AAEED952E053D3FB179F0@SV-EXDB-PROD2.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4809F811@ESESSMB301.ericsson.se> <51421DB2.9000109@labn.net> <B9FEE68CE3A78C41A2B3C67549A96F4801C8D1@FR711WXCHMBA05.zeu.alcatel-lucent.com> <5142FF9E.3020804@labn.net> <F82A4B6D50F9464B8EBA55651F541CF835887297@SZXEML552-MBX.china.huawei.com>
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF835887297@SZXEML552-MBX.china.huawei.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>
Subject: Re: [CCAMP] R: G.709 signaling - encoding Type
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 20 Mar 2013 13:52:56 -0000

Great.  Will you propose/add some related text so we don't need to
revisit this again?

Lou

On 3/20/2013 5:27 AM, Fatai Zhang wrote:
> Hi Lou,
> 
> I agree on your conclusion, which I have pointed out one or two years ago when we discussed if it needs mapping information.
> 
> I think some people may forgot this. 
> =========================================================================================
> Per the presented slide and Table 7-10 of G.709, the mapping method/type is unique per combination of {ODUj, ODUk, TSG}.
> 
> 
> 
> 
> Best Regards
> 
> Fatai
> 
> 
> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: Friday, March 15, 2013 7:02 PM
> To: BELOTTI, SERGIO (SERGIO)
> Cc: CCAMP (ccamp@ietf.org)
> Subject: Re: [CCAMP] R: G.709 signaling - encoding Type
> 
> Sergio,
> 	Thank you for clarifying the requirement. I believe you are describing
> an issue that is a little different than what I understood from some
> earlier discussions.  Perhaps others were also in the same situation.
> 
> As I now understand it, the issue that is being raised is one related to
> ODUj LSPs that use an ODUk H-LSP as a hop, there is a need at all hops,
> including at *transit nodes*, to configure the mapping method (AMP, GMP)
> used from the ODUj onto the ODUk H-LSP.  This of course means that the
> mapping function needs to be set on a hop by hop basis for the ODUj LSP.
>  (I though an issue on and ODUk H-LSP was being raised.)
> 
> Or in other words there is an issue of per-hop resource
> allocation/management.
> 
> Per the presented slide and Table 7-10 of G.709, the mapping method/type
> is unique per combination of {ODUj, ODUk, TSG}.  Obviously any hop
> signaling an ODUj LSP will know and unambiguously be able to identify
> (in signaling) the ODUj and ODUk.  This just leaves the TSG.
> 
> Section 6.1 of the signalling draft already has text covering TSG as
> part of the per-hop label. So TSG is also already being signaled
> unambiguously.
> 
> It looks to me that all that is needed is a sentence or two stating that
> the mapping type is unambiguously based on the above.
> 
> Please let me know if I missed something.
> 
> Lou
> 
> On 3/15/2013 6:05 AM, BELOTTI, SERGIO (SERGIO) wrote:
>>
>> The requirement comes form discussion had last week related to tolerance .
>> We discovered from ITU experts, there is an attribute related to the adaptation function in case of multiplexing of ODUj into ODUk, 
>>
>>  oduTypeAndRate that configures the mapping method (AMP, GMP).
>>
>> Now , since obviously equipment cannot know whether configuration is provided via management or control plane , conclusion was that control plane should have an equivalent of this attribute in order to be able to configure the right adaptation.
>>
>> On the other hand this discussion is not new , since many time we discussed the opportunity to have dedicated object/fields to explicit adaptation information , at the moment not present in GMPLS.
>>
>> This is a summery of requirement.
>>
>> Thanks
>> Sergio
>>
>> Belotti Sergio-  System Architect
>> ALCATE-LUCENT  Optics Division
>> via Trento 30 Vimercate (MB) - Italy
>> phone +39 (039) 6863033
>> -----Messaggio originale-----
>> Da: Lou Berger [mailto:lberger@labn.net] 
>> Inviato: giovedì 14 marzo 2013 19.58
>> A: Daniele Ceccarelli
>> Cc: Rajan Rao; John E Drake; BELOTTI, SERGIO (SERGIO); CCAMP (ccamp@ietf.org)
>> Oggetto: Re: [CCAMP] G.709 signaling - encoding Type
>>
>> Daniele, (Sergio?)
>>
>> Can you summarize the data plane behavior/requirement that is the basis
>> for the change?  i.e., provide the reason why *any* change is required.
>>
>> Once we all understand the data plane requirements/constraints, we can
>> better decide which (hopefully existing) GMPLS mechanism is best suited
>> to support the requirement.
>>
>> Thank you,
>> Lou
>>
>> On 3/14/2013 2:41 PM, Daniele Ceccarelli wrote:
>>> Using the encoding was one of the possible suggestions.
>>>
>>> Indeed it has impacts on the routing and it might be worth avoiding it, but another solution is preferrable wrt relying on the Label Length (which might change for several reasons). I would prefer not to put a requirement on the Label lenght only because it is needed to retrieve the adaptation type.
>>>
>>> Other proposals are welcome. I had a chat with John this morning and he was proposing the utilization of a new field (even a single bit). That could be a viale option for me. Since we're removing the Tolerance from the traffic parameters we're going to have room for a new field.
>>>
>>> BR
>>> Daniele
>>>
>>>> -----Original Message-----
>>>> From: Rajan Rao [mailto:rrao@infinera.com] 
>>>> Sent: mercoledì 13 marzo 2013 19.51
>>>> To: Lou Berger; John E Drake
>>>> Cc: BELOTTI, SERGIO (SERGIO); CCAMP (ccamp@ietf.org); Daniele 
>>>> Ceccarelli
>>>> Subject: RE: [CCAMP] G.709 signaling - encoding Type
>>>>
>>>> Lou,
>>>>
>>>> The new encoding has implications in routing(new ISCDs).  I 
>>>> think we can minimize the impact using the two fields 
>>>> mentioned in my email below.   To be specific,
>>>>
>>>> For the case highlighted in the slide,  the Encoding is AMP 
>>>> when Signal Type = ODU1  in traffic spec Length Field  = 8 in  Label 
>>>>
>>>> Thanks
>>>> Rajan
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> Sent: Wednesday, March 13, 2013 6:54 PM
>>>> To: John E Drake
>>>> Cc: BELOTTI, SERGIO (SERGIO); Rajan Rao; CCAMP 
>>>> (ccamp@ietf.org); Daniele Ceccarelli
>>>> Subject: Re: [CCAMP] G.709 signaling - encoding Type
>>>>
>>>> John,
>>>>
>>>> See below.
>>>>
>>>> On 3/13/2013 6:40 PM, John E Drake wrote:
>>>>> Lou,
>>>>>
>>>>>  
>>>>>
>>>>> I must have been asleep but I don't remember hearing of an issue.
>>>>
>>>> No problem, looked like a few others had some trouble getting 
>>>> moving this AM too.
>>>>
>>>>>  It
>>>>> was my understanding that AMP and GMP both use G.709 encoding in the 
>>>>> data plane, so why would we want to make what appears to be an 
>>>>> artificial distinction?
>>>>
>>>> This was covered on slide 3 of Danielle's presentation.  
>>>> He/They can provide additional details/justification.
>>>>
>>>> Lou
>>>>
>>>>>
>>>>>  
>>>>>
>>>>> Irrespectively Yours,
>>>>>
>>>>>  
>>>>>
>>>>> John
>>>>>
>>>>>  
>>>>>
>>>>> *From:*Lou Berger [mailto:lberger@labn.net]
>>>>> *Sent:* Wednesday, March 13, 2013 3:27 PM
>>>>> *To:* John E Drake; BELOTTI, SERGIO (SERGIO); Rajan Rao
>>>>> *Cc:* CCAMP (ccamp@ietf.org); Daniele Ceccarelli
>>>>> *Subject:* Re: [CCAMP] G.709 signaling - encoding Type
>>>>>
>>>>>  
>>>>>
>>>>> John,
>>>>>
>>>>> Do you have an alternate proposal on how to address the issue, or do 
>>>>> you just see an issue?
>>>>>
>>>>> (If the former, the onus will fall on you to provide one. If the 
>>>>> latter, it'll fall to Sergio And Danielle to recap the presented
>>>>> issue.)
>>>>>
>>>>> Lou
>>>>>
>>>>>  
>>>>>
>>>>> On March 13, 2013 6:16:46 PM John E Drake wrote:
>>>>>
>>>>>     Hi,
>>>>>
>>>>>      
>>>>>
>>>>>     I don't think this is a good idea and I don't see any 
>>>> reason for it.
>>>>>
>>>>>      
>>>>>
>>>>>     Irrespectively Yours,
>>>>>
>>>>>      
>>>>>
>>>>>     John
>>>>>
>>>>>      
>>>>>
>>>>>     *From:*ccamp-bounces@ietf.org <mailto:ccamp-bounces@ietf.org>
>>>>>     [mailto:ccamp-bounces@ietf.org] *On Behalf Of *BELOTTI, 
>>>> SERGIO (SERGIO)
>>>>>     *Sent:* Wednesday, March 13, 2013 6:53 AM
>>>>>     *To:* Rajan Rao
>>>>>     *Cc:* CCAMP (ccamp@ietf.org <mailto:ccamp@ietf.org>)
>>>>>     *Subject:* [CCAMP] R: G.709 signaling - encoding Type
>>>>>
>>>>>      
>>>>>
>>>>>     Rao,
>>>>>
>>>>>      
>>>>>
>>>>>     it is a proposal: so you should read:  "encoding type can 
>>>>> indicate.
>>>>>
>>>>>      
>>>>>
>>>>>     Regards
>>>>>
>>>>>     Sergio
>>>>>
>>>>>      
>>>>>
>>>>>     *Belotti Sergio-  System Architect*
>>>>>
>>>>>     *ALCATE-LUCENT  Optics Division*
>>>>>
>>>>>     via Trento 30 Vimercate (MB) - Italy
>>>>>
>>>>>     phone +39 (039) 6863033
>>>>>
>>>>>     
>>>>>
>>>> ----------------------------------------------------------------------
>>>>> --
>>>>>
>>>>>     *Da:*ccamp-bounces@ietf.org <mailto:ccamp-bounces@ietf.org>
>>>>>     [mailto:ccamp-bounces@ietf.org] *Per conto di *Rajan Rao
>>>>>     *Inviato:* mercoledì 13 marzo 2013 14.40
>>>>>     *A:* CCAMP (ccamp@ietf.org <mailto:ccamp@ietf.org>)
>>>>>     *Oggetto:* [CCAMP] G.709 signaling - encoding Type
>>>>>
>>>>>      
>>>>>
>>>>>     Daniele,
>>>>>
>>>>>      
>>>>>
>>>>>     The presentation slide#3 says:  "encoding type indicates AMP or
>>>>>     GMP".   I don't think this is the case.  We use  G.709 ODUk as
>>>>>     encoding type.  There is no explicit indication of AMP or GMP
>>>>>     there.  Are you proposing to change this?
>>>>>
>>>>>      
>>>>>
>>>>>     Note that AMP/GMP can be inferred from Signal Type in 
>>>> traffic param
>>>>>     & Length field ( = 8) in the label.
>>>>>
>>>>>      
>>>>>
>>>>>     Thanks
>>>>>     Rajan
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>