Re: [CCAMP] Overlay model framework v2
Igor Bryskin <IBryskin@advaoptical.com> Thu, 17 January 2013 18:33 UTC
Return-Path: <IBryskin@advaoptical.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 7BC3321F87EE for <ccamp@ietfa.amsl.com>; Thu, 17 Jan 2013 10:33:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
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 jUrikP8Favbb for <ccamp@ietfa.amsl.com>; Thu, 17 Jan 2013 10:33:42 -0800 (PST)
Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id BC9BD21F8833 for <ccamp@ietf.org>; Thu, 17 Jan 2013 10:33:39 -0800 (PST)
Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r0HIXYYK021991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jan 2013 19:33:34 +0100
Received: from MUC-SRV-MBX1.advaoptical.com (172.20.1.95) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.118.0; Thu, 17 Jan 2013 19:33:34 +0100
Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX1.advaoptical.com (172.20.1.95) with Microsoft SMTP Server (TLS) id 15.0.516.32; Thu, 17 Jan 2013 19:33:33 +0100
Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0118.000; Thu, 17 Jan 2013 13:33:31 -0500
From: Igor Bryskin <IBryskin@advaoptical.com>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Snigdho Bardalai <SBardalai@infinera.com>, CCAMP <ccamp@ietf.org>
Thread-Topic: Overlay model framework v2
Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQAOJ5ugAAF4jxAAC1ZqcAAgY/iAAAnZVHD//8bogIAAUn/A//+8joCAAFMukP//sSSAgABE4WA=
Date: Thu, 17 Jan 2013 18:33:31 +0000
Message-ID: <CDAC6F6F5401B245A2C68D0CF8AFDF0A19159708@atl-srv-mail10.atl.advaoptical.com>
References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <CDAC6F6F5401B245A2C68D0CF8AFDF0A19107008@atl-srv-mail10.atl.advaoptical.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> <CDAC6F6F5401B245A2C68D0CF8AFDF0A191585E8@atl-srv-mail10.atl.advaoptical.com> <4A1562797D64E44993C5CBF38CF1BE4806CC86@ESESSMB301.ericsson.se> <CDAC6F6F5401B245A2C68D0CF8AFDF0A1915962F@atl-srv-mail10.atl.advaoptical.com> <4A1562797D64E44993C5CBF38CF1BE4806CDD9@ESESSMB301.ericsson.se> <CDAC6F6F5401B245A2C68D0CF8AFDF0A191596AC@atl-srv-mail10.atl.advaoptical.com> <4A1562797D64E44993C5CBF38CF1BE4806CE44@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4806CE44@ESESSMB301.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.21.1.81]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-17_06:2013-01-17, 2013-01-17, 1970-01-01 signatures=0
Subject: Re: [CCAMP] Overlay model framework v2
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, 17 Jan 2013 18:33:46 -0000
Daniele, You say a real link/node COULD be a part of a Virtual Topology. (==> How a real WDM link or ROADM could be a part of ODUk Virtual Topology?) I say a real link/node MAY be represented in it's entirety in a Virtual Topology by a virtual link/node which has 1:1 cardinality with the said real link/node. In other words the representation you are talking about according to my definition is just one of a variety of ways real links/nodes could be presented in a Virtual Topology. I think you are unnecessarily overcomplicating the model by distinguishing this private case. Igor -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Thursday, January 17, 2013 12:20 PM To: Igor Bryskin; Snigdho Bardalai; CCAMP Subject: RE: Overlay model framework v2 I think a virtual link COULD be a real link and a virtual node COULD be a real node. Agree that no provider wants to export the full topology, but there might be cases in which it could be useful to summarise a domain in E.G. X virtual nodes plus Y real nodes (where Y could be very small by !=0). I just wanted to include this case also. Daniele >-----Original Message----- >From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >Sent: giovedì 17 gennaio 2013 18.11 >To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >Subject: RE: Overlay model framework v2 > >The reason I like term "Virtual Topology" is simply because it >is entirely made up of virtual elements: nodes and links. If >you agree with me that provider does not disclose any of its >real network topology information, I don't see why the terms >"Exported Provider Topology" or "Summarized Provider Topology" >are better/less confusing. > >-----Original Message----- >From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >Sent: Thursday, January 17, 2013 12:04 PM >To: Igor Bryskin; Snigdho Bardalai; CCAMP >Subject: RE: Overlay model framework v2 > >Does this mean: the topology passed from the PE to the CE? >(hope this time i correctly used the acronims!!!) > >The new definition looks good to me if you're referring to the >virtual links/nodes only, but doesn't consider real >links/nodes any longer. > >I prefer the old definition and call it as Pavan suggested: >Exported Provider Topology" or "Summarized Provider Topology" > >BR >Daniele > >>-----Original Message----- >>From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>Sent: giovedì 17 gennaio 2013 17.23 >>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >>Subject: RE: Overlay model framework v2 >> >>Daniele, >> >>What I was saying is that the definition: >>> 3. Virtual Topology: Virtual topology is a collection of >>one or more >>> virtual or real provider network domain nodes that exist in the >>> customer layer network and are interconnected via 0 or >more virtual >>> links. >>Is not correct. It should say IMO: >>3. Virtual Topology: Virtual topology is a collection of one or more >>virtual nodes, supported by one or more provider network >domains, which >>exist in the customer layer network and are interconnected via 0 or >>more virtual links, supported by one or more provider network domains >> >>-----Original Message----- >>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >>Sent: Thursday, January 17, 2013 11:10 AM >>To: Igor Bryskin; Snigdho Bardalai; CCAMP >>Subject: RE: Overlay model framework v2 >> >>What you say is more than true but orthogonal to my point :-) >> >>It's only a matter of terminology. We defined: >> >>> 3. Virtual Topology: Virtual topology is a collection of >>one or more >>> virtual or real provider network domain nodes that exist in the >>> customer layer network and are interconnected via 0 or >more virtual >>> links. >> >>If we call it "Virtual Topology", the first thing that comes to the >>minds is: its only a collection of virtual links and virtual nodes. >>Snigdho's proposal was to call it differently so to better >identify the >>fact that it includes both virtual and real links/nodes, that's it. >>The name he proposed, however, is again misleading, because >calling it >>"provider topology" makes me (and you) thinking of just real >>links/nodes, doesn't it? >> >>I would suggest not to use either of the terms as both are >misleading. >>Maybe something like "exported topology", "CE-PE tology" or whatever. >> >>Daniele >> >>>-----Original Message----- >>>From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>>Sent: giovedì 17 gennaio 2013 16.29 >>>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP >>>Subject: RE: Overlay model framework v2 >>> >>>Daniele, >>> >>>We want to separate a Virtual Topology advertised to the >>clients (which >>>is, generally speaking, different for different sets of >clients) from >>>provider real topology, which must be concealed from the clients. >>>I disagree with Snigdho, when he is saying that a PE just has >>multiple >>>aliases (one from each client name space). There is much >more to this. >>>The way I see it a PE contributes differently to different Virtual >>>Topologies (each time with a different ID, sometimes as a whole, >>>sometimes as split into several VNs, sometimes as a part of a >>large VN, >>>possibly with a separate connectivity matrix. it also, depending on >>>Virtual Topology, presents itself as switch of a different layer >>>network, and so forth). Therefore, PE in the context of Virtual >>>Topology is always a Virtual Node, even when it is mapped 1:1 >>onto real >>>provider switch. In general, only VN can terminate a VL. >>> >>>Igor >>> >>>-----Original Message----- >>>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] >>>Sent: Thursday, January 17, 2013 9:53 AM >>>To: Snigdho Bardalai; Igor Bryskin; CCAMP >>>Subject: RE: Overlay model framework v2 >>> >>>Igor, Snigdho, >>> >>>I agree with Snigdho. Why don't we call it provider topology (or >>>whatever) if it includes both virtual links/nodes and real >>links/nodes? >>>I don't think it has anything to deal with naming space. >>> >>>Further replies in line >>> >>>I'd like to have feedbacks from you and all on Open Issue 4. >>>That's an advertisement models draft issue but it's something that i >>>can't really understand yet. >>> >>>BR >>>Daniele >>> >>>>-----Original Message----- >>>>From: Snigdho Bardalai [mailto:SBardalai@infinera.com] >>>>Sent: giovedì 17 gennaio 2013 5.28 >>>>To: Igor Bryskin; Daniele Ceccarelli; CCAMP >>>>Subject: RE: Overlay model framework v2 >>>> >>>>Hi Igor, >>>> >>>>Not sure if the case you are citing qualifies a real node or >>>link to be >>>>called virtual. The client space name is simply an alias. >>>> >>>>Regards >>>>Snigdho >>>> >>>>> -----Original Message----- >>>>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>>>> Sent: Wednesday, January 16, 2013 3:04 PM >>>>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP >>>>> Subject: RE: Overlay model framework v2 >>>>> >>>>> Snigdho, >>>>> >>>>> > 3. Virtual Topology: Virtual topology is a collection >of one or >>>>> > more virtual or real provider network domain nodes that >>exist in >>>>> > the customer layer network and are interconnected via >0 or more >>>>> > virtual links. >>>>> >>>>> [SCB] Since the topology advertised by the provider network can >>>>> contain real or virtual elements, why do we call it "virtual >>>>> topology"? Should it simply be called "provider topology"? >>And then >>>>> specify that it may contain both virtual or real elements. >>>>> >>>>> Virtual topology includes only virtual nodes. Even when we are >>>>> considering real PEs terminating VLs, we must treat the >PEs in the >>>>> context of Virtual Topology as VNs since they must be named >>>from the >>>>> client naming space. >>>>> >>>>> Igor >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >>>>On Behalf >>>>> Of Snigdho Bardalai >>>>> Sent: Wednesday, January 16, 2013 5:48 PM >>>>> To: Daniele Ceccarelli; CCAMP >>>>> Subject: Re: [CCAMP] Overlay model framework v2 >>>>> >>>>> Hi Daniele, >>>>> >>>>> A few comments. Please see in-line. >>>>> >>>>> Thanks >>>>> Snigdho >>>>> >>>>> > -----Original Message----- >>>>> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>> Behalf >>>>> > Of Daniele Ceccarelli >>>>> > Sent: Wednesday, January 16, 2013 7:33 AM >>>>> > To: CCAMP >>>>> > Subject: [CCAMP] Overlay model framework v2 >>>>> > >>>>> > Dear overlayers, >>>>> > >>>>> > Please find below a new version (v2) of the framework summary >>>>> > reflecting the latest discussions. Again i hope i've >>captured all >>>>> > the comments around, sorry if anything is missing, in case >>>>just let >>>>> > me know what i missed. >>>>> > >>>>> > BR >>>>> > Daniele >>>>> > >>>>> > >>>>> > + Disclaimer: >>>>> > 1. Packet opto integration is often considered but the >>>>work can be >>>>> > extented to any type of SC. Eg. TDM over LSC. >>>>> > >>>>> > + Terminology: >>>>> > 1. Virtual Link: A virtual link is a potential path >between two >>>>> > virtual or real network elements in a provider layer >>>network that >>>>> is >>>>> > maintained/controlled in and by the provider domain >>>control plane >>>>> > (and as such cannot transport any traffic/data and >>protected from >>>>> > being >>>>> > de-provisioned) and which can be instantiated in the >data plane >>>>> > (and then can carry/transport/forward traffic/data) preserving >>>>> > previously advertised attributes such as fate sharing >>>information. >>>>> > 2. Virtual Node: Virtual node is a collection of zero or more >>>>> > provider network domain nodes that are collectively >>>>represented to >>>>> > the clients as a single node that exists in the customer layer >>>>> > network and is capable of terminating of access, >>inter-domain and >>>>> virtual links. >>>>> >>>>> [SCB] Agree with Igor's comment - a virtual node can be a >>>>combination >>>>> of multiple nodes or a part of the single node, but to the >>customer >>>>> node this is transparent. >>> >>>Yes, agree. >>> >>>>> >>>>> > 3. Virtual Topology: Virtual topology is a collection >of one or >>>>> > more virtual or real provider network domain nodes that >>exist in >>>>> > the customer layer network and are interconnected via >0 or more >>>>> > virtual links. >>>>> >>>>> [SCB] Since the topology advertised by the provider network can >>>>> contain real or virtual elements, why do we call it "virtual >>>>> topology"? Should it simply be called "provider topology"? >>And then >>>>> specify that it may contain both virtual or real elements. >>> >>>See above >>> >>>>> >>>>> > 4. Overlay topology: is a superset of virtual >>>topologies provided >>>>> by >>>>> > each of provider network domains, access and >inter-domain links. >>>>> >>>>> [SCB] A more concise definition for the overlay topology is >>>>- CE nodes >>>>> + Access-links + provider topology as advertised by the provider >>>>> network. >>> >>>We wanted to include also the possiblity of having multiple provider >>>domains. >>> >>>>> >>>>> > 5. Access Link: Link between OC and OE. GMPLS runs on >>>>that link. It >>>>> > can support any of the SCs supported by the GMPLS. >>>>> > 6. CE (customer Edge): Something like the CN in RFC4208 >>>>teminology >>>>> > but (i) receiving virtual topology from the provider >>network and >>>>> > requesting the set up of one of them or >>>>> > (ii) requesting the computation and establishment of a path >>>>> > accordingly to given constraints in the provider network and >>>>> > receiving the parameters characterizing such path. (ii) == UNI. >>>>> > 7. PE (provider Edge): Something like the EN in RFC4208 >>>>but able to >>>>> > deal with (i) and (ii) above. >>>>> > 8. PE-CE interface (former ONI) : Interface allowing for >>>>signaling >>>>> > and routing messages exchange between customer overlay >>>>and provider >>>>> > network. Routing information consists on virtual topology >>>>> > advertisement. When there is no routing adjacency across the >>>>> interface >>>>> > it is equivalent to the GMPLS UNI defined in 4208. Signaling >>>>> > messages are compliant with RFC4208. Information >>related to path >>>>> > carachteristics, e.g. TE-metrics, collected SRLG, path >>>delay etc, >>>>> > either passed from CE to PE via signaling after the LSP >>>>> > establishment in the core network or from CE to PE to >be used as >>>>> > path computation constraints, fall under the definition of >>>>> > signaling info and not routing info). >>>>> > 9. CE-CE (former O-NNI): Interface on the links between >>>different >>>>> > provider networks in the overlay model environment. Same >>>features >>>>> > of the CE-PE apply to this interface. >>>>> >>>>> [SCB] Is this "PE-PE" instead of "CE-CE"? >>> >>>Oooops! Definitely. >>> >>>>> >>>>> > >>>>> > + Statements >>>>> > 1. In the context of overlay model we are aiming to build an >>>>> > overlay topology for the customer network domains 2. >>>The overlay >>>>> > topology >>>>> is >>>>> > comprised of: >>>>> > a) access links (links connecting client NEs to the >provider >>>>> > network domains). >>>>> > They can be PSC or LSC. >>>>> > b) inter-domain links (links interconnecting server network >>>>> > domains) >>>>> > c) virtual topology provided by the provider >network domains. >>>>> > Virtual Links + Virtual Nodes (TBD) + Connectivity >>Matrix (with a >>>>> set >>>>> > of parameters e.g. SRLG, optical impairments, delay >etc for each >>>>> > entry) describing connectivity between access links and virtual >>>>> links. >>>>> > 3. In the context of overlay model we manage hierarchy >>>>of overlay >>>>> > topologies with overlay/underlay relationships 4. In >>>the context >>>>> > of overlay model multi-layering and inter-layer >>>relationships are >>>>> > peripheral at best, it is all about horizontal network >>integration >>>>> 5. >>>>> > The overlay model assumes one CP instance for the >>customer network >>>>> and >>>>> > a separate instance for the provider network and in the CE-PE >>>>> > interface case the provider network also surreptitiously >>>>> participates >>>>> > in the customer network by injecting virtual topology >>>information >>>>> > into it. >>>>> >>>>> [SCB] Specific implementations may or may not have a single >>>instance >>>>> for the provider and the overlay. >>> >>>Mmm, that's true. It MUST work with two different instances >>but no one >>>prevents it to work with a single one. >>> >>>>> >>>>> > 6. L1VPN (and LxVPN) in general is a type of service >>>>provided over >>>>> > the CE-PE interface (it falls under the UNI case as no routing >>>>> > adjacency is in place between CE and PE). >>>>> >>>>> > >>>>> > >>>>> > + Advertisement models (to be detailed in dedicated >>>>> > + document/documents) >>>>> > The CE-PE interface in the overlay model context foresees >>>>two types >>>>> > of advertisement models.(names still to be agreed) A. >>>>Augmented UNI: >>>>> > The GMPLS UNI is defined in RFC4208 and augmented by a >>number of >>>>> > actived draft (references to various drafts to be added). >>>>> > The Augmented UNI is a particular type of CE-PE >interface where >>>>> > only signaling messages are exchanged between CE and PE. >>>Messages >>>>> > from CE to PE can include a set of parameters to be used >>>>by the PE >>>>> > as path computation constraints when computing a path in the >>>>> > provider domain network, while messages from PE to CE can >>>>include a >>>>> > set of >>>>> parameters >>>>> > qualifying the LSP being established, like for example >>>>SRLG, delay, >>>>> > loss etc. >>>>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could >be simply >>>>> > called with the general CE-PE interface term?) allowing the >>>>> > establishment of signaling and routing adjacency between >>>>CE and PE. >>>>> > Routing info passed from PE to CE comprise overlay topology >>>>> > information including (but not limited to) virtual links, >>>>> > connectivity matrices and access links with parameters >qualifying >>>>> each >>>>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling >>>>> > information >>>>> and procedures are compliant with RFC4208. >>>>> > >>>>> > + Open issues/questions >>>>> > 1. PCE-PCEP - do we need to include considerations >about PCE and >>>>> PCEP >>>>> > into the overlay framework context? >>>>> >>>>> [SCB] IMO - this should be described in the overlay >>>>framework document >>>>> to establish the context. >>> >>>+1 >>> >>>>> >>>>> > 2. BGP-LS needs to be considered 3. Should potentials be >>>>> > included? E.g. I2RS? >>>>> > 4. Virtual links: wouldn't a different definition of >>>>virtual links >>>>> > avoid the advertisement of connectivity matrices (this is >>>>out of the >>>>> > fwk scope but within the advertisement models one)? >>>>> > Take this example: >>>>> > PE1-----CE1 CE2-----PE2 >>>>> > CE1======VL1======CE2 >>>>> > CE1======VL2======CE2 >>>>> > i.e. There are 2 VL connecting CE1 and CE2 that could be >>available >>>>> for >>>>> > PE1 and PE2 to set up an adjacency in the customer domain. CE1 >>>>> > and/or >>>>> > CE2 can be blocking nodes so VL1 and/or VL2 are available only >>>>> > depending on the connectivity matrices of CE1 and CE2. >Hence PEs >>>>> > need to be aware of both VL and connectivity matrices. My >>>>point is: >>>>> > if CE1 advertises to PE1 only the VL that his >>connectivity matrix >>>>> > allows to be connected to PE1 (e.g. VL1 only) and not all >>>of them, >>>>> > it should be possible to avoid the connectivity matrices >>>>advertisement. >>>>> > >>>>> > >>>>> > =================================== >>>>> > DANIELE CECCARELLI >>>>> > System & Technology - PDU Optical & Metro >>>>> > >>>>> > Via E.Melen, 77 >>>>> > Genova, Italy >>>>> > Phone +390106002512 >>>>> > Mobile +393346725750 >>>>> > daniele.ceccarelli@ericsson.com >>>>> > www.ericsson.com >>>>> > >>>>> > This Communication is Confidential. We only send and >>>receive email >>>>> > on the basis of the term set out at >>>>> > www.ericsson.com/email_disclaimer >>>>> > >>>>> > _______________________________________________ >>>>> > 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 >>>> >>> >> >
- Re: [CCAMP] Overlay model framework v2 Lou Berger
- [CCAMP] Overlay model framework v2 Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework v2 Igor Bryskin
- Re: [CCAMP] Overlay model framework v2 Gert Grammel
- Re: [CCAMP] Overlay model framework v2 Dieter Beller
- Re: [CCAMP] Overlay model framework v2 Snigdho Bardalai
- Re: [CCAMP] Overlay model framework v2 Igor Bryskin
- Re: [CCAMP] Overlay model framework v2 Igor Bryskin
- Re: [CCAMP] Overlay model framework v2 Snigdho Bardalai
- Re: [CCAMP] Overlay model framework v2 Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework v2 Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework v2 Igor Bryskin
- Re: [CCAMP] Overlay model framework v2 Vishnu Pavan Beeram
- Re: [CCAMP] Overlay model framework v2 Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework v2 Igor Bryskin
- Re: [CCAMP] Overlay model framework v2 Vishnu Pavan Beeram
- Re: [CCAMP] Overlay model framework v2 Vishnu Pavan Beeram
- Re: [CCAMP] Overlay model framework v2 Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework v2 Vishnu Pavan Beeram
- Re: [CCAMP] Overlay model framework v2 Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework v2 Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework v2 Igor Bryskin
- Re: [CCAMP] Overlay model framework v2 Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework v2 Snigdho Bardalai
- Re: [CCAMP] Overlay model framework v2 Gert Grammel
- Re: [CCAMP] Overlay model framework v2 Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework v2 Igor Bryskin
- Re: [CCAMP] Overlay model framework v2 Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework v2 Lou Berger
- Re: [CCAMP] Overlay model framework v2 Igor Bryskin
- Re: [CCAMP] Overlay model framework v2 Lou Berger
- Re: [CCAMP] Overlay model framework v2 Igor Bryskin
- Re: [CCAMP] Overlay model framework v2 Lou Berger
- Re: [CCAMP] Overlay model framework v2 Igor Bryskin
- Re: [CCAMP] Overlay model framework v2 Lou Berger
- Re: [CCAMP] Overlay model framework v2 Igor Bryskin
- Re: [CCAMP] Overlay model framework v2 Lou Berger
- Re: [CCAMP] Overlay model framework v2 John E Drake
- Re: [CCAMP] Overlay model framework v2 Igor Bryskin
- Re: [CCAMP] Overlay model framework v2 Gert Grammel
- Re: [CCAMP] Overlay model framework v2 Gert Grammel
- Re: [CCAMP] Overlay model framework v2 Snigdho Bardalai
- Re: [CCAMP] Overlay model framework v2 Gert Grammel
- Re: [CCAMP] Overlay model framework v2 Dieter Beller
- Re: [CCAMP] Overlay model framework v2 Lou Berger
- [CCAMP] Additional overlay protocol extensions? (… Lou Berger
- Re: [CCAMP] Overlay model framework v2 Igor Bryskin
- Re: [CCAMP] Additional overlay protocol extension… Igor Bryskin
- Re: [CCAMP] Additional overlay protocol extension… Lou Berger
- Re: [CCAMP] Additional overlay protocol extension… Snigdho Bardalai
- Re: [CCAMP] Additional overlay protocol extension… Igor Bryskin
- Re: [CCAMP] Additional overlay protocol extension… Lou Berger
- Re: [CCAMP] Additional overlay protocol extension… BRUNGARD, DEBORAH A
- Re: [CCAMP] Additional overlay protocol extension… Igor Bryskin
- Re: [CCAMP] Additional overlay protocol extension… Lou Berger
- Re: [CCAMP] Additional overlay protocol extension… Igor Bryskin
- Re: [CCAMP] Additional overlay protocol extension… BRUNGARD, DEBORAH A
- Re: [CCAMP] Additional overlay protocol extension… John E Drake
- Re: [CCAMP] Additional overlay protocol extension… Gert Grammel
- Re: [CCAMP] Additional overlay protocol extension… John E Drake