Re: [CCAMP] R: R: G.709 signaling - encoding Type
Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Thu, 21 March 2013 13:34 UTC
Return-Path: <daniele.ceccarelli@ericsson.com>
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 E351A21F8D27 for <ccamp@ietfa.amsl.com>; Thu, 21 Mar 2013 06:34:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.449
X-Spam-Level:
X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_35=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4]
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 Fu0IAv-ffjR1 for <ccamp@ietfa.amsl.com>; Thu, 21 Mar 2013 06:34:43 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EABD821F8CC8 for <ccamp@ietf.org>; Thu, 21 Mar 2013 06:34:42 -0700 (PDT)
X-AuditID: c1b4fb25-b7f366d000004d10-22-514b0c71ee94
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 89.D7.19728.17C0B415; Thu, 21 Mar 2013 14:34:42 +0100 (CET)
Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 14:34:41 +0100
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: Lou Berger <lberger@labn.net>, "BELOTTI, SERGIO (SERGIO)" <sergio.belotti@alcatel-lucent.com>
Thread-Topic: R: [CCAMP] R: G.709 signaling - encoding Type
Thread-Index: AQHOJU05gAIjvQUa+kilQ0/Q6dR2IZiuiPeAgAADUQCAAC1zAIABJUUw
Date: Thu, 21 Mar 2013 13:34:40 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE480A2029@ESESSMB301.ericsson.se>
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>
In-Reply-To: <5149E808.2050203@labn.net>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+JvjW4Rj3egwcZjzBZP5txgsehofsti sWzzb3aLvubzrA4sHq3P9rJ6tBx5y+qxZMlPJo8Pm5rZAliiuGxSUnMyy1KL9O0SuDKe/vcq 6MivOLn7JFMD4/LILkZODgkBE4n25QfZIWwxiQv31rN1MXJxCAkcYpTYeeAvM4SzhFFi29Jj QA4HB5uAlcSTQz4gpohAskT71UyQXmaBEImdS/6CzREWsJa4seM+K4gtImAj8XbtLCaIcjeJ WZOdQcIsAqoSBz6tYwSxeQW8Jf7vWMwIsWkuu8Sz3jdgvZwCGhJTupeAzWQUkJWYsHsRI8Qu cYlbT+YzQdwsILFkz3lmCFtU4uXjf6wQtqLEzrPtzBD1ehI3pk5hg7C1JZYtfM0MsVhQ4uTM JywTGMVmIRk7C0nLLCQts5C0LGBkWcXInpuYmZNebrSJERhHB7f8Vt3BeOecyCFGaQ4WJXHe cNcLAUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY859WZlRL1G20fyzyXS1+7tQzF76VbhVe lPls2pfV2x79/Z3LfV3Q/lz8tb2631If/VhQdIJlbtvJxrhkm3PczX2LvSYaadvOKTpxMGvS +vSDZxslGXgO/ZQNWD/Lc+EOG92DfHdbWm7G72stvvuf+w6f1IydfZKNkkcuPTE7s+uDwETN C4lh3EosxRmJhlrMRcWJADTZe3FxAgAA
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:34:45 -0000
Lou, OK. No changes to signaling re explicit indication of mapping and/or TSG in the label. 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