[CCAMP] R: Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)
"BELOTTI, SERGIO (SERGIO)" <sergio.belotti@alcatel-lucent.com> Wed, 30 January 2013 10:17 UTC
Return-Path: <sergio.belotti@alcatel-lucent.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 DC1BC21F858C for <ccamp@ietfa.amsl.com>; Wed, 30 Jan 2013 02:17:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.049
X-Spam-Level:
X-Spam-Status: No, score=-9.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+qkaDNm19WB for <ccamp@ietfa.amsl.com>; Wed, 30 Jan 2013 02:17:48 -0800 (PST)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA3F21F8457 for <ccamp@ietf.org>; Wed, 30 Jan 2013 02:17:36 -0800 (PST)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0UAHOXx001341 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Jan 2013 11:17:28 +0100
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 30 Jan 2013 11:17:27 +0100
From: "BELOTTI, SERGIO (SERGIO)" <sergio.belotti@alcatel-lucent.com>
To: Fatai Zhang <zhangfatai@huawei.com>, Lou Berger <lberger@labn.net>
Date: Wed, 30 Jan 2013 11:17:25 +0100
Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)
Thread-Index: AQHN/ZXCuS8hTs+eckmWtA0MM2hSFphfguWQgAInNUA=
Message-ID: <F050945A8D8E9A44A71039532BA344D822405DE87B@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
References: <5105E684.4030607@labn.net> <B6585D85A128FD47857D0FD58D8120D3B35B5B@xmb-rcd-x14.cisco.com> <4A1562797D64E44993C5CBF38CF1BE48073D01@ESESSMB301.ericsson.se> <5106DED0.3090008@labn.net> <F82A4B6D50F9464B8EBA55651F541CF835859742@SZXEML552-MBX.china.huawei.com>
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF835859742@SZXEML552-MBX.china.huawei.com>
Accept-Language: it-IT, en-US
Content-Language: it-IT
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: it-IT, en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Cc: CCAMP <ccamp@ietf.org>
Subject: [CCAMP] R: Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)
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, 30 Jan 2013 10:17:50 -0000
Hi all, Option 2 is my preference too. I share completely motivations provided by Fatai. Thanks. Best Regards Sergio Belotti Sergio - System Architect ALCATEL-LUCENT Optics Division -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Fatai Zhang Inviato: martedì 29 gennaio 2013 3.27 A: Lou Berger; CCAMP Oggetto: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Hi Lou, I would pick up option 2 (better than option 1) because of the following reasons, even though I spent much time to convince you (but I failed). (1) There will be consistent between signaling draft (need crank-back) and the existing routing draft (we all spent so much time on routing draft to get the consensus). (2) There will be consistent for "Bit_Rate" filed for both ODUflex(CBR) and ODUflex(GFP) cases (ie, it only needs one single "Bit_Rate" field). (3) I don't think option 3&4 are better than option 1&2 for interworking with early implementations (I think all the authors are from vendors, we know this very well. Usually/sometimes, there is actually no compatibility/interworking issue in the real world). For option 3, I am fine because I appreciate the work that I have done, :-), if we don't count the additional work on routing draft. Anyway, please don't think about option 4, I don't see any significant advantages by doing that besides more work and more discussions. Best Regards Fatai -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger Sent: Tuesday, January 29, 2013 4:26 AM To: CCAMP Subject: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) All, We would like to try to close the discussion on the G.709 drafts so that we can move rapidly towards publication request. The discussion of (one of my) LC comments has resulted in several options for the signaling ODU-related traffic parameters, and the point has been raised that realigning routing with signaling should be discussed. Please keep in mind that the objective of any PS is interoperability, and that there may be early implementations that match g709v3-04. The basic question is one of if N, the number of time slots needed to support a ODUflex(GFP) signal, should be carried as a calculated IEEE floating point number or directly. Options 1 and 2 below reflect the former, options 3 and 4 match the latter. It is worth noting that only options 1 and 2 are proposed for ODUflex(GFP), i.e., N must be calculated for ODUflex(CBR) signal types with all options. Please state your support for one the options and, if you wish, the justification for your position: 1) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-04 i.e., redefine [RFC4328] Traffic Parameters c-type when used with OTN-TDM labels. ODUflex(GFP) number of tributary slots (N) is encoded as: ... the Bit_Rate field for ODUflex(GFP) MUST equal to one of the 80 values listed below: 1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts; 9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts; 33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts. 2) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-05 i.e., use a new C-type for OTN-TDM labels. Encoding details unchanged from g709v3-04. (This option addresses the issue of the same c-type needing to be parsed based on label/switching type.) 3) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-06 i.e., use a new C-type for OTN-TDM labels. N is directly carried for ODUflex(GFP) only. 4) Discussed, but not in any draft Use draft-ietf-ccamp-gmpls-signaling-g709v3-04 encoding for all but ODUflex(GFP), and define new ODUflex(GFP) specific Traffic Parameters based on g709v3-06, presumably with unused fields removed. (This also addresses the issue of the same c-type needing to be parsed based on label type, but means there are different types based on signal type.) Option 1 and 2 do not imply any changes to routing, while options 3 and 4 may. Routing implications will be discussed based on the results of this poll, and only if there is consensus to support positions 3 or 4. We hope to make a consensus call by the end of the week, but will continue the discussion as needed. Much thanks, Lou (and Deborah) On 1/28/2013 5:08 AM, Daniele Ceccarelli wrote: > All, > > I think the changes proposed are meaningful and would support them in an individual or early WG draft, but they don't seem to provide significative advantages to risk interworking issues with early implementations. > Moreover the changes don't allow us getting totally rid of of the bit_rate field as it is still needed for ODUflex (CBR). > > My 2c > Daniele > > >> -----Original Message----- >> From: Zafar Ali (zali) [mailto:zali@cisco.com] >> Sent: lunedì 28 gennaio 2013 4.47 >> To: Lou Berger >> Cc: Gruman, Fred; Fatai Zhang; Daniele Ceccarelli; CCAMP; >> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >> Subject: Re: [CCAMP] WG Last Call comments on >> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >> >> Hi Lou- >> >> Please see in-line. >> >> Thanks >> >> Regards...Zafar >> >> On 1/27/13 9:46 PM, "Lou Berger" <lberger@labn.net> wrote: >> >>> Zafar, >>> Is your comment with respect to just routing or both >> signaling and >>> routing? >> >> Both, including consistency between signaling and routing attributes. >> >>> >>> Also, when you say "implementations based on draft versions", >> do these >>> implementations include support for ODUflex? (Which has really been >>> the focus of the discussion.) >> >> Yes, I was referring to ODUFlex. As you know, fixed ODU is >> signaled via level (0 BW) so its not an issue. >> >>> >>> BTW I took Fred's comments as related to just the new >> OTN-specific ISCD >>> definitions (section 4.1.2 of ospf-g709v3-05, in particular). Note >>> that section 4.1.1 already carries N (number of ODUs) not >> IEEE floating >>> point representations of available bandwidth. >> >> What I meant is Unreserved Bandwidth at priority x and Max LSP >> Bandwidth at priority x. >> >>> >>> Much thanks, >>> Lou >>> >>> On 1/27/2013 7:46 PM, Zafar Ali (zali) wrote: >>>> All- >>>> >>>> This impacts existing implementations based on draft versions (and >>>> hence interop with these implementations moving forward). >> IMO this is >>>> a bigger change for us to assume at the last call stage. >> Furthermore >>>> we have been using IEEE floating point format for Unreserved >>>> Bandwidth/ Max LSP BW in IEEE floating point format for other >>>> technologies. Overall, I think this change suffers from the >> "law of diminishing returns". >>>> >>>> Thanks >>>> >>>> Regards Š Zafar >>>> >>>> >>>> On 1/27/13 10:28 AM, "Gruman, Fred" >> <fred.gruman@us.fujitsu.com> wrote: >>>> >>>>> Hi Lou, Fatai, Daniele, >>>>> >>>>> I understand the latest change to the way bandwidth is >> signaled for >>>>> ODUflex(GFP), i.e., signaling the number of tributary slots >> N instead >>>>> of the bandwidth rate in bps. I believe that this simplifies the >>>>> signaling and interoperability so I'm in agreement with >> this change. >>>>> >>>>> However, it seems we are now inconsistent between how we >> represent >>>>> bandwidth in routing and signaling for ODUflex(GFP). Routing >>>>> advertises the bandwidth using a floating point representation of >>>>> bandwidth, while signaling is using the number of tributary slots. >>>>> It seems the same benefits would be obtained by >> advertising the max >>>>> LSP bandwidth and unreserved bandwidth for ODUflex(GFP) in >> terms of >>>>> the number of tributary slots. >>>>> >>>>> Fred >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>> Behalf Of Lou Berger >>>>> Sent: Wednesday, January 23, 2013 9:08 AM >>>>> To: Fatai Zhang >>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>> >>>>> Fatai, >>>>> >>>>> On 1/23/2013 6:49 AM, Fatai Zhang wrote: >>>>>> Hi Lou, >>>>>> >>>>>> For ODUflex(CBR), the formula is from [G.709-2012] and it >> has been >>>>>> discussed before, so please trust that there is no >> opportunity for >>>>>> misinterpretation. (Note that there are two cases, one is >>>>>> ODUflex(CBR) and another one is ODUflex(GFP)). >>>>>> >>>>>> In addtion, ODUflex cannot be concatenated by [G.709-2012]. >>>>> >>>>> Thanks for confirming my understanding. This raises the >> question of >>>>> if the new traffic should just apply to ODUFlex? Correct >> me if I'm >>>>> wrong, but I believe the [RFC4328] is sufficient in all >> other cases. >>>>> This may also make it easier for early implementations of >> the draft >>>>> as then they can limit code changes from the (-03) rev to >> only ODUflex LSPs. >>>>> >>>>> Just to be clear, I'm really just *asking* about this. As I said >>>>> before, I'm open on specifics... >>>>> >>>>> Any thoughts/comments? Authors? Implementors? >>>>> >>>>> Thanks, >>>>> Lou >>>>> >>>>> >>>>>> I will issue a new version tomorrow to capture all your comments. >>>>>> >>>>>> >>>>>> Best Regards >>>>>> >>>>>> Fatai >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>> Sent: Wednesday, January 23, 2013 2:11 AM >>>>>> To: Fatai Zhang >>>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>> >>>>>> Fatai, >>>>>> >>>>>> On 1/20/2013 9:43 PM, Fatai Zhang wrote: >>>>>>> Hi Lou, >>>>>>> >>>>>>> You said: >>>>>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the >>>>>>>> value of this vs just carrying N? >>>>>>> >>>>>>> [Fatai] The original way (in version 04&05) is putting >> (N* Nominal >>>>>>> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we >>>>>>> can generalize to just use one single "Bit_Rate" field to carry >>>>>>> IEEE float number for both cases, it seems that you >> don't agree on >>>>>>> this value, :-) >>>>>> >>>>>> I've seen differences in calculated floating point values from >>>>>> different implementations, so I just want to ensure that >> such cases >>>>>> are avoided. >>>>>> I'm open to specific solutions and certainly will deffer on the >>>>>> specifics assuming there is no opportunity for >>>>>> misinterpretation/interop issues. I don't think the >> original passed >>>>>> this threshold, i.e.,: >>>>>> >>>>>> N = Ceiling of >>>>>> >>>>>> ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate >>>>>> tolerance) >>>>>> >>>>>> ----------------------------------------------------------- >> ---------- >>>>>> ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate >> tolerance) >>>>>> >>>>>>> . Therefore, I (was) am saying that I am going to accept your >>>>>>> suggestion to carry N for ODUflex(GFP). We are >> discussing where to >>>>>>> put N for ODUflex(GFP). >>>>>>> >>>>>> >>>>>>> You said: >>>>>>>> bits in the control plane are generally cheap, IMO it's >> better to >>>>>>>> have simpler encoding than to optimize every bit (or 8 in this >>>>>>>> case). >>>>>>> >>>>>>> [Fatai] OK, I will add a new field (to occupy the reserved bits) >>>>>>> to carry N. >>>>>> >>>>>> As you see fit. >>>>>> >>>>>> Just to clarify my understanding, ODUflex and Virtual >> concatenation >>>>>> can never be combined for the same signal type/level, right? >>>>>> (Although an ODUflex client signal could be carried over >> a virtual >>>>>> concatenated ODUk). Is this correct or did I miss something in >>>>>> G709? >>>>>> >>>>>> Thanks, >>>>>> Lou >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Best Regards >>>>>>> >>>>>>> Fatai >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>> Sent: Friday, January 18, 2013 1:42 AM >>>>>>> To: Fatai Zhang >>>>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 1/15/2013 10:16 PM, Fatai Zhang wrote: >>>>>>>> Hi Lou, >>>>>>>> >>>>>>>> To avoid misunderstanding, I would like to clarify more on the >>>>>>>> following point. >>>>>>>> >>>>>>>> >>>>>>>>>>>> It is better to have consistent format and the same meaning >>>>>>>>>>>> of one >>>>>>> field for both ODUflex(CBR) and GFP. This is why we have section >>>>>>> 5.1 >>>>>>> &5.2 to describe the complex stuff. >>>>>>>>>>> I actually wasn't suggesting that N be carried in >> the bit rate >>>>>>>>>>> field. >>>>>>>>>>> The bit rate field can either be set as described or to zero >>>>>>>>>>> (i.e., ignored). At the time, I was thinking about >> carrying N >>>>>>>>>>> in the reserved field. But perhaps the right place >> is MT, if >>>>>>>>>>> my understanding is right (would always be 1 >> otherwise). I'm >>>>>>>>>>> open to either... >>>>>>>>>>> >>>>>>>>>> [Fatai] Why not just use "bit rate"field to carry >> "N"because "N" >>>>>>>>>> implies bit rate? I am OK if you like to use a new >> filed (like >>>>>>>>>> "TS >>>>>>>>>> Number") to occupy the reserved field even though >> that I prefer >>>>>>>>>> the original approach (ie., use "bit rate"field to carry "N"). >>>>>>>>> >>>>>>>>> Are you proposing dropping carrying bit rates >> represented as an >>>>>>>>> IEEE floating point and just carrying N for ODUflex? >> This seems >>>>>>>>> workable to me, but we should ensure that there are no >>>>>>>>> significant objections. >>>>>>>> >>>>>>>> [Fatai] There are two usages for " Bit_Rate " field as >> described >>>>>>>> in the lines 287-310. >>>>>>>> >>>>>>>> (1) For ODUflex(CBR), the Bit_Rate field indicates >> the nominal >>>>>>>> bit >>>>>>>> rate of ODUflex(CBR) expressed in bytes per second, >> encoded as a >>>>>>>> 32-bit IEEE single precision floating-point number. For this >>>>>>>> case, we MUST use 32-bit IEEE floating point instead of >>>>>>>> "N"(Please see more in section 5.1). >>>>>>> >>>>>>> I guess you really still need (to be based on) the client signal >>>>>>> rate at the edges. >>>>>>> >>>>>>>> >>>>>>>> (2) For ODUflex(GFP), we can change the text (the >> lines from 305 >>>>>>>> to >>>>>>>> 310) based on your suggestion, ie., the Bit_Rate field >> is used to >>>>>>>> carry "N"to indicate the nominal bit rate of the ODUflex(GFP). >>>>>>> >>>>>>> but you're says encoded as (N*Nominal Rate) right? Wat's the >>>>>>> value of this vs just carrying N? >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Therefore, I am proposing using one single filed ("Bit_Rate ") >>>>>>>> for these two cases, in this way, we can leave the "Reserved" >>>>>>>> bits for future. >>>>>>> >>>>>>> bits in the control plane are generally cheap, IMO it's >> better to >>>>>>> have simpler encoding than to optimize every bit (or 8 in this >>>>>>> case). >>>>>>> >>>>>>> Lou >>>>>>> >>>>>>>> >>>>>>>> Hope we are now at the same page. >>>>>>>> >>>>>>>> >>>>>>>> Best Regards >>>>>>>> >>>>>>>> Fatai >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> >>>> >>>> >>>> >> >> > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp
- [CCAMP] WG Last Call: g709-framework, g709-info-m… Lou Berger
- [CCAMP] WG Last Call comments on draft-ietf-ccamp… Lou Berger
- [CCAMP] WG Last Call comments on draft-ietf-ccamp… Lou Berger
- [CCAMP] WG Last Call comments on draft-ietf-ccamp… Lou Berger
- [CCAMP] WG Last Call comments on draft-ietf-ccamp… Lou Berger
- [CCAMP] 答复: WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] WG Last Call: g709-framework, g709-in… Lou Berger
- [CCAMP] 答复: WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] 答复: WG Last Call comments on draft-ie… Lou Berger
- [CCAMP] 答复: 答复: WG Last Call comments on draft-ie… Fatai Zhang
- Re: [CCAMP] 答复: 答复: WG Last Call comments on draf… Lou Berger
- Re: [CCAMP] 答复: 答复: WG Last Call comments on draf… BRUNGARD, DEBORAH A
- [CCAMP] Fwd: Re: 答复: 答复: WG Last Call comments on… Huub van Helvoort
- [CCAMP] 答复: 答复: 答复: WG Last Call comments on draf… Fatai Zhang
- [CCAMP] 答复: 答复: 答复: WG Last Call comments on draf… Fatai Zhang
- Re: [CCAMP] 答复: 答复: 答复: WG Last Call comments on … Lou Berger
- [CCAMP] 答复: 答复: 答复: 答复: WG Last Call comments on … Fatai Zhang
- Re: [CCAMP] 答复: 答复: 答复: 答复: WG Last Call comments… Lou Berger
- [CCAMP] 答复: 答复: 答复: 答复: 答复: WG Last Call comments… Fatai Zhang
- [CCAMP] 答复: WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] 答复: WG Last Call comments on draft-ie… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Gruman, Fred
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… John E Drake
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Zafar Ali (zali)
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Zafar Ali (zali)
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Daniele Ceccarelli
- [CCAMP] Poll on ODUFlex-related encoding (was: WG… Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Zafar Ali (zali)
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Gruman, Fred
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Daniele Ceccarelli
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Gruman, Fred
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Gruman, Fred
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Lou Berger
- [CCAMP] Fwd: RE: Poll on ODUFlex-related encoding… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Khuzema Pithewan
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Daniele Ceccarelli
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Fatai Zhang
- [CCAMP] R: Poll on ODUFlex-related encoding (was:… BELOTTI, SERGIO (SERGIO)
- [CCAMP] R: Poll on ODUFlex-related encoding (was:… BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Rajan Rao
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Margaria, Cyril (NSN - DE/Munich)
- Re: [CCAMP] Poll on ODUFlex-related encoding Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding Daniele Ceccarelli
- Re: [CCAMP] Poll on ODUFlex-related encoding Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Lou Berger
- [CCAMP] R: Poll on ODUFlex-related encoding BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] R: Poll on ODUFlex-related encoding Lou Berger
- [CCAMP] R: R: Poll on ODUFlex-related encoding BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] R: R: Poll on ODUFlex-related encoding Lou Berger
- [CCAMP] R: R: R: Poll on ODUFlex-related encoding BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] Poll on ODUFlex-related encoding Zafar Ali (zali)
- Re: [CCAMP] Poll on ODUFlex-related encoding John E Drake
- Re: [CCAMP] Poll on ODUFlex-related encoding Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Fred Gruman
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- [CCAMP] R: Poll on ODUFlex-related encoding BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] Poll on ODUFlex-related encoding Daniele Ceccarelli
- [CCAMP] R: Poll on ODUFlex-related encoding BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] R: Poll on ODUFlex-related encoding Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Gruman, Fred