Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft
Lou Berger <lberger@labn.net> Thu, 19 July 2012 15:44 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 3949121F8714 for <ccamp@ietfa.amsl.com>; Thu, 19 Jul 2012 08:44:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.667
X-Spam-Level:
X-Spam-Status: No, score=-93.667 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345, 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 CmQXhrJe9b4m for <ccamp@ietfa.amsl.com>; Thu, 19 Jul 2012 08:44:55 -0700 (PDT)
Received: from oproxy10-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 2017C21F86EB for <ccamp@ietf.org>; Thu, 19 Jul 2012 08:44:55 -0700 (PDT)
Received: (qmail 16035 invoked by uid 0); 19 Jul 2012 15:45:44 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy10.bluehost.com with SMTP; 19 Jul 2012 15:45:44 -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=oISEHRSN4VyUBOaAwfyP/NOdIwuEvHd7y457aouRcKI=; b=FkX45EFOZUp5lnf6I4DiATL4rk7C1ylkGL6exk6EDaPLUXfzcKmA9Phr2T8+nI2aVThBJsNsmWQklsUG029B/zvl7/g/3dS4VOAhviNoGBo0B6dM3iSEf1/E3vyrHC9P;
Received: from box313.bluehost.com ([69.89.31.113]:47633 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1SrsvA-0004xV-Ev; Thu, 19 Jul 2012 09:45:44 -0600
Message-ID: <50082BA5.8070601@labn.net>
Date: Thu, 19 Jul 2012 11:45:41 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: John E Drake <jdrake@juniper.net>
References: <F82A4B6D50F9464B8EBA55651F541CF82CC528E5@SZXEML520-MBX.china.huawei.com> <500019A7.7060203@labn.net> <B5630A95D803744A81C51AD4040A6DAA22AE6FFF1B@ESESSCMS0360.eemea.ericsson.se> <5000304B.3080007@labn.net> <B5630A95D803744A81C51AD4040A6DAA22AE6FFFE2@ESESSCMS0360.eemea.ericsson.se> <50003B93.7060500@labn.net> <B5630A95D803744A81C51AD4040A6DAA22AE70032C@ESESSCMS0360.eemea.ericsson.se> <50040D47.7000209@labn.net> <F82A4B6D50F9464B8EBA55651F541CF82CC582C7@SZXEML520-MBX.china.huawei.com> <5E893DB832F57341992548CDBB333163A5A85B5D37@EMBX01-HQ.jnpr.net> <B5630A95D803744A81C51AD4040A6DAA22AE7B9867@ESESSCMS0360.eemea.ericsson.se> <5E893DB832F57341992548CDBB333163A5A87EEF8E@EMBX01-HQ.jnpr.net> <B5630A95D803744A81C51AD4040A6DAA22AE7B9A7F@ESESSCMS0360.eemea.ericsson.se> <5E893DB832F57341992548CDBB333163A5A87EF322@EMBX01-HQ.jnpr.net> <B5630A95D803744A81C51AD4040A6DAA22AE7B9CAE@ESESSCMS0360.eemea.ericsson.se> <5E893DB832F57341992548CDBB333163A5A87EF722@EMBX01-HQ.jnpr.net>
In-Reply-To: <5E893DB832F57341992548CDBB333163A5A87EF722@EMBX01-HQ.jnpr.net>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="GB2312"
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: "zhangguoying@mail.ritt.com.cn" <zhangguoying@mail.ritt.com.cn>, "ccamp@ietf.org" <ccamp@ietf.org>, Linyi <yi.lin@huawei.com>
Subject: Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft
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, 19 Jul 2012 15:44:56 -0000
John/All, It sounds like we've reach some agreement on this thread, right? (As participant in thread) I read that the conclusion is to not optimize for a very special corner case and: 1) basically treat the intra-OTN case the same as any other MRN/MLN case (leveraging GPID, and no new hierarchy object) 2) Use Daniele's new draft on MRN/MLN as the starting point in the discussion of how to address the limitations in MRN/MLN identified in this discussion. Did I miss anything? Thanks, Lou On 7/19/2012 7:09 AM, John E Drake wrote: > Daniele, > > What concerns me is that we are headed in a design direction in which > signaling is required to carry all of the information necessary to > allow any intermediate node to select the egress interface for an > LSP. The issue I have with this is that it requires every > intermediate node to have exactly the same capabilities as the > ingress/egress nodes, which makes the incremental introduction of new > capabilities more challenging. > > Allowing heterogeneous nodal capabilities is one of the reasons we > include all of this information in routing in the first place. > > Thanks, > > John > > Sent from my iPhone > >> -----Original Message----- >> From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >> Sent: Thursday, July 19, 2012 3:20 AM >> To: John E Drake; Fatai Zhang; Lou Berger >> Cc: ccamp@ietf.org; Khuzema Pithewan; zhangguoying@mail.ritt.com.cn; >> Linyi; xuyunbin@mail.ritt.com.cn; GRANDI, PIETRO VITTORIO (PIETRO >> VITTORIO); Diego Caviglia; Rajan Rao; IBryskin@advaoptical.com; >> BELOTTI, SERGIO (SERGIO) >> Subject: RE: 答复: 答复: Updates on OTN signaling draft >> >> That could be another option perfectly reasonable. >> >> However I don't know which one is faster and cheaper. An RFC bis >> modifies the behavior of existing implementaitons while an totally new >> object already defined that only needs to be imported into the new >> MRN/MLN extensions only applies to new implementations. >> I assume the existing ones rely on cranck-backs or EROs including, >> among the others, the egress interface (e.g. strict ERO). >> >> Thanks, >> Daniele >> >>> -----Original Message----- >>> From: John E Drake [mailto:jdrake@juniper.net] >>> Sent: mercoledì 18 luglio 2012 23.01 >>> To: Daniele Ceccarelli; Fatai Zhang; Lou Berger >>> Cc: ccamp@ietf.org; Khuzema Pithewan; >>> zhangguoying@mail.ritt.com.cn; Linyi; >>> xuyunbin@mail.ritt.com.cn; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); >>> Diego Caviglia; Rajan Rao; IBryskin@advaoptical.com; BELOTTI, SERGIO >>> (SERGIO) >>> Subject: RE: 答复: 答复: Updates on OTN signaling draft >>> >>> That's fair, but perhaps we should stipulate in an RFC >>> 3471/3473 bis that the ingress node MUST specify the egress interface >>> in the ERO? We seem to be spending a lot time and effort to work >>> around this. >>> >>> Sent from my iPhone >>> >>> >>>> -----Original Message----- >>>> From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >>>> Sent: Wednesday, July 18, 2012 10:02 AM >>>> To: John E Drake; Fatai Zhang; Lou Berger >>>> Cc: ccamp@ietf.org; Khuzema Pithewan; zhangguoying@mail.ritt.com.cn; >>>> Linyi; xuyunbin@mail.ritt.com.cn; GRANDI, PIETRO VITTORIO (PIETRO >>>> VITTORIO); Diego Caviglia; Rajan Rao; IBryskin@advaoptical.com; >>>> BELOTTI, SERGIO (SERGIO) >>>> Subject: RE: 答复: 答复: Updates on OTN signaling draft >>>> >>>> Hi John, >>>> >>>> Yes it is, but it falls in the case I call strict ERO. >>>> When I use the term loose ERO I refer to an ERO lacking of some info >>>> (exactly that piece of information), when I refer to a strict ERO I >>>> speak about an ERO including info of all the hops (hence including >>>> that piece of information, the rest of the path is >>> meaningless in this >>>> context). >>>> I know the terminology is not exact but I didn't want to invent new >>>> names when referring to an ERO with that info and ERO without it. >>>> >>>> BR >>>> Daniele >>>> >>>>> -----Original Message----- >>>>> From: John E Drake [mailto:jdrake@juniper.net] >>>>> Sent: mercoledì 18 luglio 2012 17.58 >>>>> To: Daniele Ceccarelli; Fatai Zhang; Lou Berger >>>>> Cc: ccamp@ietf.org; Khuzema Pithewan; >>> zhangguoying@mail.ritt.com.cn; >>>>> Linyi; xuyunbin@mail.ritt.com.cn; GRANDI, PIETRO VITTORIO (PIETRO >>>>> VITTORIO); Diego Caviglia; Rajan Rao; IBryskin@advaoptical.com; >>>>> BELOTTI, SERGIO >>>>> (SERGIO) >>>>> Subject: RE: 答复: 答复: Updates on OTN signaling draft >>>>> >>>>> Daniele, >>>>> >>>>> You are correct. One question though, isn't it the case that it is >>>>> sufficient for the ingress to specify the egress interface >>> in the ERO >>>>> rather than computing a strict ERO? >>>>> >>>>> Thanks, >>>>> >>>>> John >>>>> >>>>> Sent from my iPhone >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >>>>>> Sent: Wednesday, July 18, 2012 3:30 AM >>>>>> To: John E Drake; Fatai Zhang; Lou Berger >>>>>> Cc: ccamp@ietf.org; Khuzema Pithewan; >>>>>> zhangguoying@mail.ritt.com.cn; Linyi; xuyunbin@mail.ritt.com.cn; >>>>>> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia; Rajan >>>>>> Rao; IBryskin@advaoptical.com; BELOTTI, SERGIO (SERGIO) >>>>>> Subject: RE: 答复: 答复: Updates on OTN signaling draft >>>>>> >>>>>> Hi John, >>>>>> >>>>>> partially agree. I think the hierarchy is still needed for >>>>> those cases >>>>>> in which 3 or more layer are being involved, in >>> particular when the >>>>>> penultimate node, performing the choice of the FA, receives a >>>>>> signalling message of layer 2, needs to choose the FA at layer 3 >>>>>> and is not aware of layer 1. Let's try to make an example >>> (switched >>>>>> to plain text for the drawing): >>>>>> >>>>>> ODU1-LSP >>>>>> ..................................................... >>>>>> | | >>>>>> | ODU2-H-LSP | >>>>>> | +======================================+ >>>>>> | | | >>>>>> | | | >>>>>> | | ODU3-H-LSP | >>>>>> | | |-------------------------| >>>>>> | | | | >>>>>> +--+--+ +-----+ +--+--+ +---+-+ >>> +-----+ >>>>>> | | | | | | | | >>> | | >>>>>> | A +------+ B +------+ C +------+ D >>> |------+ E | >>>>>> | | | | | | | | >>> | | >>>>>> +-----+ +-----+ +-----+ +-----+ >>> +-----+ >>>>>> >>>>>> >>>>>> The LSP being signaled (ODUj), from A to E is an ODU1 >>>>> (called layer 1 >>>>>> above). B receives a path message related to the ODU1 and >>> starts a >>>>>> signaling for an ODU2. C receives the ODU2 path message whose >>>>>> destination is E and needs to "choose among a set >>>>> of"/"request the set >>>>>> up of" an ODU3 H-LSP from itself to E (loose ERO used). The >>>>> only thing >>>>>> that C knows is that the interface on E must be able to perform >> an >>>>>> ODU2->ODU3 demuxing to extract the client traffic from the ODU2. >>>>>> >>>>>> This is not correct, the demuxing capability required on the >>>>> interface >>>>>> on E is ODU1->ODU2->ODU3 and the only way to let C know it, is >>>>>> introducing the hierarchy in signaling. >>>>>> >>>>>> I think this is quite a corner case, more academic >>> speculation than >>>>>> real case, but if there is a 0,00001% possibility it can >>> happen, we >>>>>> should cover the case. >>>>>> >>>>>> Please note that the problem does not exist using a strict >>>>> ERO (which >>>>>> i wuold suggest :-) >>>>>> >>>>>> Thanks, >>>>>> Daniele >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> From: John E Drake [mailto:jdrake@juniper.net] >>>>>> Sent: martedì 17 luglio 2012 16.18 >>>>>> To: Fatai Zhang; Lou Berger; Daniele Ceccarelli >>>>>> Cc: ccamp@ietf.org; Khuzema Pithewan; >>>>> zhangguoying@mail.ritt.com.cn; >>>>>> Linyi; xuyunbin@mail.ritt.com.cn; GRANDI, PIETRO VITTORIO (PIETRO >>>>>> VITTORIO); Diego Caviglia; Rajan Rao; IBryskin@advaoptical.com; >>>>>> BELOTTI, SERGIO (SERGIO) >>>>>> Subject: RE: 答复: 答复: Updates on OTN signaling draft >>>>>> >>>>>> >>>>>> >>>>>> Fatai, >>>>>> >>>>>> >>>>>> >>>>>> To recap my previous emails: >>>>>> >>>>>> >>>>>> >>>>>> 1) TSG info needs to be carried in signaling in the >> GPID >>>>>> >>>>>> 2) Any node that performs CSPF and selects the egress >>>>>> interface for an LSP needs to ensure that interface’s TSG is >>>>>> compatible with the ingress interface’s TSG as indicated in >>>>> signaling >>>>>> (the GPID) >>>>>> >>>>>> 3) Signaling should not carry hierarchy info because >>>>>> signaling only instantiates a single ODUj >>>>>> >>>>>> 4) The ingress will sequentially signal multiple ODUj >> LSPs, >>>>>> each with a different value of j, in order to instantiate an OTN >>>>>> hierarchy between a given ingress/egress pair >>>>>> >>>>>> >>>>>> >>>>>> As an aside, just over a year ago, we had an extended >>>>> discussion of >>>>>> this topic in which I argued in support of the Infinera >>> approach of >>>>>> using a single signaling message to instantiate any necessary >>>>>> intermediate hierarchy in support of a given client ODUj, and >>>>>> nobody bought my arguments.. >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> >>>>>> >>>>>> From: Fatai Zhang [mailto:zhangfatai@huawei.com] >>>>>> Sent: Monday, July 16, 2012 7:03 PM >>>>>> To: Lou Berger; Daniele Ceccarelli >>>>>> Cc: John E Drake; ccamp@ietf.org; Khuzema Pithewan; >>>>>> zhangguoying@mail.ritt.com.cn; Linyi; xuyunbin@mail.ritt.com.cn; >>>>>> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia; >>>>> Rajan Rao; >>>>>> IBryskin@advaoptical.com; BELOTTI, SERGIO (SERGIO); Fatai Zhang >>>>>> Subject: 答复: 答复: 答复: Updates on OTN signaling draft >>>>>> >>>>>> >>>>>> >>>>>> Hi Lou, >>>>>> >>>>>> >>>>>> >>>>>> [snip] >>>>>> >>>>>> >>>>>> >>>>>> Let's understand where we are, :-), >>>>>> >>>>>> >>>>>> >>>>>> If my following understanding is not correct, please >>>>> list some items >>>>>> that we need to get the consensus. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> ================================================================= >>>>>> ====================================================== >>>>>> >>>>>> >>>>>> >>>>>> > Intra-OTN is missing, wrt actual MRN/MLN, the capability >> of >>>>>> signlaing the TSG, while Inter-OTN is missing also the Adaptation >>>>>> between client and server layers (e.g. Bit-sync vs Byte-sync >>>> mapping, >>>>>> X.86 vs GFP etc) >>>>>> >>>>>> > >>>>>> >>>>>> > [snip] >>>>>> >>>>>> >>>>>> >>>>>> fair enough. >>>>>> >>>>>> >>>>>> >>>>>> [Fatai] Did you mean (or agree) that intra-OTN is missing >> the >>>>>> capability of signaling the TSG? Should Inter-OTN be generic >>>> MRN/MLN? >>>>>> >>>>>> >>>>>> >>>>>> > It appears we came to the conclusion that a general >>>>> "intra switch >>>>>> cap" work is needed (non OTN specific). >>>>>> >>>>>> > >>>>>> >>>>>> > My proposal was to include the problem statement in >>>>> the bcg draft >>>>>> (so to make it cover both the inter and intra cases) and >>>>> then work on >>>>>> a different encoding draft (I'm not sure the OTN signaling is the >>>>>> right place for general intra switch cap encoding. Maybe a >>>>> pointer is >>>>>> more appropriate. >>>>>> >>>>>> >>>>>> >>>>>> Sounds workable to me (and aligned with what John was >> saying). >>>>>> Now let's see if others disagree or if we have consensus! >>>>>> >>>>>> >>>>>> >>>>>> [Fatai] I understood Daniele's proposal. However, >>>>> focusing on OTN >>>>>> signaling draft, did you mean that this draft (OTN signaling) >>>>>> should focus on OTN specific (intra-OTN) as what it is or this >>>>>> draft should remove TSG or hierachy information or bothe of them >>>>>> (ie., GPID extension for TSG and hierachy inforamtion in LSPA)? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> >>>>>> Fatai >>>>>> >>>>>> >>>>>> >>>>>> -----邮件原件----- >>>>>> 发件人: Lou Berger [mailto:lberger@labn.net] >>>>>> 发送时间: 2012年7月16日 20:47 >>>>>> 收件人: Daniele Ceccarelli >>>>>> 抄送: Fatai Zhang; John E Drake; ccamp@ietf.org; Khuzema >>>>> Pithewan; >>>>>> zhangguoying@mail.ritt.com.cn; Linyi; xuyunbin@mail.ritt.com.cn; >>>>>> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Diego Caviglia; >>>>> Rajan Rao; >>>>>> IBryskin@advaoptical.com; BELOTTI, SERGIO >>>>>> (SERGIO) >>>>>> 主题: Re: 答复: 答复: Updates on OTN signaling draft >>>>>> >>>>>> >>>>>> >>>>>> [snip] >>>>>> >>>>>> >>>>> >>>>> >>>
- [CCAMP] Updates on OTN signaling draft Fatai Zhang
- Re: [CCAMP] Updates on OTN signaling draft Lou Berger
- [CCAMP] 答复: Updates on OTN signaling draft Fatai Zhang
- Re: [CCAMP] 答复: Updates on OTN signaling draft Lou Berger
- [CCAMP] 答复: 答复: Updates on OTN signaling draft Fatai Zhang
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Lou Berger
- Re: [CCAMP] 答复: Updates on OTN signaling draft John E Drake
- [CCAMP] 答复: 答复: Updates on OTN signaling draft Fatai Zhang
- [CCAMP] 答复: 答复: 答复: Updates on OTN signaling draft Fatai Zhang
- Re: [CCAMP] 答复: 答复: 答复: Updates on OTN signaling … Lou Berger
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Lou Berger
- Re: [CCAMP] 答复: Updates on OTN signaling draft John E Drake
- [CCAMP] 答复: 答复: 答复: Updates on OTN signaling draft Fatai Zhang
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Daniele Ceccarelli
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Lou Berger
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Daniele Ceccarelli
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Lou Berger
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Daniele Ceccarelli
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Lou Berger
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Daniele Ceccarelli
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Lou Berger
- [CCAMP] 答复: 答复: 答复: Updates on OTN signaling draft Fatai Zhang
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft John E Drake
- Re: [CCAMP] 答复: 答复: 答复: Updates on OTN signaling … Lou Berger
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Daniele Ceccarelli
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Lou Berger
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Daniele Ceccarelli
- Re: [CCAMP] 答复: 答复: 答复: Updates on OTN signaling … Daniele Ceccarelli
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft John E Drake
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Daniele Ceccarelli
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft John E Drake
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Daniele Ceccarelli
- [CCAMP] 答复: 答复: 答复: Updates on OTN signaling draft Fatai Zhang
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft John E Drake
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Daniele Ceccarelli
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Daniele Ceccarelli
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Lou Berger
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Lou Berger
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft John E Drake
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft John E Drake
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Lou Berger
- [CCAMP] 答复: 答复: 答复: Updates on OTN signaling draft Fatai Zhang
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Daniele Ceccarelli
- [CCAMP] 答复: 答复: 答复: Updates on OTN signaling draft Fatai Zhang
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft John E Drake
- Re: [CCAMP] 答复: 答复: Updates on OTN signaling draft Daniele Ceccarelli
- Re: [CCAMP] 答复: 答复: 答复: Updates on OTN signaling … Julien Meuric
- Re: [CCAMP] 答复: 答复: 答复: Updates on OTN signaling … John E Drake
- Re: [CCAMP] 答复: 答复: 答复: Updates on OTN signaling … John E Drake
- Re: [CCAMP] 答复: 答复: 答复: Updates on OTN signaling … Julien Meuric