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 >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> > > >
- [CCAMP] G.709 signaling - encoding Type Rajan Rao
- [CCAMP] R: G.709 signaling - encoding Type BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] G.709 signaling - encoding Type John E Drake
- Re: [CCAMP] G.709 signaling - encoding Type Lou Berger
- Re: [CCAMP] G.709 signaling - encoding Type John E Drake
- Re: [CCAMP] G.709 signaling - encoding Type Lou Berger
- Re: [CCAMP] G.709 signaling - encoding Type Rajan Rao
- Re: [CCAMP] G.709 signaling - encoding Type Daniele Ceccarelli
- Re: [CCAMP] G.709 signaling - encoding Type Rajan Rao
- Re: [CCAMP] G.709 signaling - encoding Type Lou Berger
- Re: [CCAMP] G.709 signaling - encoding Type Daniele Ceccarelli
- Re: [CCAMP] G.709 signaling - encoding Type Rajan Rao
- [CCAMP] R: G.709 signaling - encoding Type BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] R: G.709 signaling - encoding Type Lou Berger
- Re: [CCAMP] R: G.709 signaling - encoding Type Fatai Zhang
- Re: [CCAMP] R: G.709 signaling - encoding Type Lou Berger
- [CCAMP] R: R: G.709 signaling - encoding Type BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] R: R: G.709 signaling - encoding Type Lou Berger
- Re: [CCAMP] G.709 signaling - encoding Type Zafar Ali (zali)
- Re: [CCAMP] R: R: G.709 signaling - encoding Type Daniele Ceccarelli
- Re: [CCAMP] R: R: G.709 signaling - encoding Type Lou Berger
- [CCAMP] Examples in draft-ietf-ccamp-gmpls-ospf-g… Gruman, Fred
- Re: [CCAMP] Examples in draft-ietf-ccamp-gmpls-os… Daniele Ceccarelli