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

Lou Berger <lberger@labn.net> Thu, 21 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 1148821F9056 for <ccamp@ietfa.amsl.com>; Thu, 21 Mar 2013 06:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.53
X-Spam-Level:
X-Spam-Status: No, score=-101.53 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6, 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 hiQN-tJIJEuz for <ccamp@ietfa.amsl.com>; Thu, 21 Mar 2013 06:52:05 -0700 (PDT)
Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id A626521F8AB7 for <ccamp@ietf.org>; Thu, 21 Mar 2013 06:52:03 -0700 (PDT)
Received: (qmail 8594 invoked by uid 0); 21 Mar 2013 13:51:40 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 21 Mar 2013 13:51:40 -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=VLf8JBXdVCxGibKB28g1gFyVeZKByb15wqSFsGe0ViA=; b=O7JJ7/3RmDMgkAutBnztejYpw0SYGTpaI3QzzgadMgvZukkfQt7asf4+Jd+io29b3i5xwUUpqz+gSoJnAV1dkm+1o+0nSWJb+GAK9SECkrdWMheL/6tjHNJk7OwsSmz6;
Received: from box313.bluehost.com ([69.89.31.113]:34548 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1UIfu7-0005Cv-Us; Thu, 21 Mar 2013 07:51:40 -0600
Message-ID: <514B106C.9010203@labn.net>
Date: Thu, 21 Mar 2013 09:51:40 -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: Daniele Ceccarelli <daniele.ceccarelli@ericsson.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> <5149BF1F.7070905@labn.net> <B9FEE68CE3A78C41A2B3C67549A96F4801D32E@FR711WXCHMBA05.zeu.alcatel-lucent.com> <5149E808.2050203@labn.net> <4A1562797D64E44993C5CBF38CF1BE480A2029@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE480A2029@ESESSMB301.ericsson.se>
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: 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: Thu, 21 Mar 2013 13:52:19 -0000

Daniele,

	See below for one addition:
On 3/21/2013 9:34 AM, Daniele Ceccarelli wrote:
> Lou,
> 
> OK. No changes to signaling re explicit indication of mapping and/or TSG in the label.

I think it would be a good idea to add a comment on this in the
signaling document so that we don't have to revisit it yet again...

Lou

> 
> Trying to summarize, please correct me if i'm missing something.
> 
> - Framework: no changes
> - Info: no changes
> - Signaling: i) GPID list check and ii) add a note on G.709 HEX values vs GPID DEC values
> - Routing: new version needed to address the latest last call comments but no other change needed
> 
> BR
> Daniele
> 
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net] 
>> Sent: mercoledì 20 marzo 2013 17.47
>> To: BELOTTI, SERGIO (SERGIO)
>> Cc: Fatai Zhang; CCAMP (ccamp@ietf.org); Daniele Ceccarelli
>> Subject: Re: R: [CCAMP] R: G.709 signaling - encoding Type
>>
>> Sergio,
>> 	Thank you for clarifying why you/Daniele raised this 
>> topic.  My preference/recommendation would be to not make any 
>> change.  I have multiple reasons for this, primarily:
>>
>> 1) TSG is already unambiguous, although it is true that it must be
>>   derived.  Adding a second field that carries it explicit allows for
>>   inconsistencies and therefore adds error cases that must be detected
>>   and handled.
>>
>> 2) I'm not a big fan of guessing what the future holds.  I do agree
>>   that we can't preclude what might happen, and need to be supported,
>>   but I don't see a lot of value in defining mechanisms today that
>>   aren't needed today and might just be useful in the future.  In this
>>   particular example, if this ever really becomes an issue, we can
>>   just define a new label format.
>>
>> 3) We've had this discussion at least once before and agreed to the
>>   current approach.  Revising past decisions is fine if there's good
>>   cause, such as new information or issues identified/discovered, but
>>   this doesn't seem to apply in this case.
>>
>> This said, I think we all would prefer to not prematurely 
>> limit discussion on this, but also don't want to drag this on too long.
>>
>> So it's really important that if there is anyone who supports 
>> making a change, that they should speak up and state their 
>> justification for the change (and soon)...
>>
>> Thanks,
>> Lou
>>
>> On 3/20/2013 10:04 AM, BELOTTI, SERGIO (SERGIO) wrote:
>>> Hi Lou,Fatai
>>>
>>> In my summary you are reffering to I said:
>>>
>>> ">> 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."
>>>
>>> It is recognized by everybody that we can retrieve information 
>>> regarding mapping by the triple you indicated. The 
>> discussion is if it 
>>> is the case to consider the opportunity to make explicit (in the 
>>> label? ) the adaptation information . The fact that now with TSG we 
>>> are able to understand the present mapping adopted in OTN, cannot 
>>> assure in the future that for any possible extension regarding 
>>> adaptation this triple can not be sufficient.
>>>
>>> Since I'm one of the author but I'm not alone ..I cannot decide for 
>>> everybody but just warn about.
>>>
>>
>>>
>>> Best Regards
>>>
>>> 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: mercoledì 20 marzo 2013 14.53
>>> A: Fatai Zhang
>>> Cc: BELOTTI, SERGIO (SERGIO); CCAMP (ccamp@ietf.org)
>>> Oggetto: Re: [CCAMP] R: G.709 signaling - encoding Type
>>>
>>> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
> 
> 
>