Re: [CCAMP] Overlay model framework v2
Snigdho Bardalai <SBardalai@infinera.com> Wed, 16 January 2013 22:47 UTC
Return-Path: <SBardalai@infinera.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 25CB611E80B8 for <ccamp@ietfa.amsl.com>; Wed, 16 Jan 2013 14:47:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 BLZO8B4AJ9IW for <ccamp@ietfa.amsl.com>; Wed, 16 Jan 2013 14:47:37 -0800 (PST)
Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2033211E809A for <ccamp@ietf.org>; Wed, 16 Jan 2013 14:47:37 -0800 (PST)
Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0318.004; Wed, 16 Jan 2013 14:47:36 -0800
From: Snigdho Bardalai <SBardalai@infinera.com>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, CCAMP <ccamp@ietf.org>
Thread-Topic: Overlay model framework v2
Thread-Index: Ac3z/soRExnVDsCQRoefc5lUb0kQPQAOJ5ug
Date: Wed, 16 Jan 2013 22:47:35 +0000
Message-ID: <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com>
References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.100.96.93]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.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: Wed, 16 Jan 2013 22:47:38 -0000
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. > 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. > 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. > 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"? > > + 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. > 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. > 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
- 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