Re: [CCAMP] Overlay model framework and context
Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Mon, 17 December 2012 15:03 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 79EE721F8661 for <ccamp@ietfa.amsl.com>; Mon, 17 Dec 2012 07:03:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.684
X-Spam-Level:
X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=1.164, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4]
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 vsmMDZflKpcM for <ccamp@ietfa.amsl.com>; Mon, 17 Dec 2012 07:03:29 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBAC21F85D4 for <ccamp@ietf.org>; Mon, 17 Dec 2012 07:03:25 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-e3-50cf343cdbc8
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DC.5C.10459.C343FC05; Mon, 17 Dec 2012 16:03:24 +0100 (CET)
Received: from ESESSMB301.ericsson.se ([169.254.1.209]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 16:03:24 +0100
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: Gert Grammel <ggrammel@juniper.net>, CCAMP <ccamp@ietf.org>
Thread-Topic: [CCAMP] Overlay model framework and context
Thread-Index: AQHN3FoyMpRFmiKOO0C4+grxFeglZpgdBiiQgAAIXmmAAAdKgA==
Date: Mon, 17 Dec 2012 15:03:23 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE48044172@ESESSMB301.ericsson.se>
References: <305443B66F0CD946A3107753337A031103FAA66E@CH1PRD0511MB431.namprd05.prod.outlook.com>, <4A1562797D64E44993C5CBF38CF1BE480440B1@ESESSMB301.ericsson.se> <305443B66F0CD946A3107753337A031103FAA68A@CH1PRD0511MB431.namprd05.prod.outlook.com>
In-Reply-To: <305443B66F0CD946A3107753337A031103FAA68A@CH1PRD0511MB431.namprd05.prod.outlook.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvja6tyfkAg25OiydzbrBYLNm1jMWB yWPJkp9MHtebrrIHMEVx2aSk5mSWpRbp2yVwZfT9qC3oz6vY9vQrSwPjz8guRk4OCQETiSuN /ewQtpjEhXvr2boYuTiEBA4xSvx9d4kdwlnCKPH1zzKmLkYODjYBK4knh3xAGkQE7CVmnpnP BmILC1hIrF17kBEibinRtHo6K4TtJDH1xQewOIuAqsS2D7/A6nkFvCXu3z3OCjH/O6PE8jmb wYo4BRIl3q5cB9bMKCArMWH3IrA4s4C4xK0n85kgLhWQWLLnPDOELSrx8vE/VghbUeLjq31Q 9XoSN6ZOYYOwtSWWLXzNDLFYUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyJ6bmJmTXm64 iREYCQe3/NbdwXjqnMghRmkOFiVxXq6k/f5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGEW7 Z24oEDWfsebJtklXti7xmPqo7F9w2QtrxYmH1ZaqzL3+3+ti35af0xbLv4v4H+T5zq30bF7D yain+3jiD21T8eF7GiRplfX8+bn97np7Xz6YkPz2n4xcm7v/mo3debM2vAjkunvvZLbE7KMp n5b9WH+ppVlO1Y2jPIJBa6/GnJiGfatrnDuVWIozEg21mIuKEwFO05TeUgIAAA==
Subject: Re: [CCAMP] Overlay model framework and context
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: Mon, 17 Dec 2012 15:03:33 -0000
I was suggesting to pick one of them :-) Defining and using all of them would surely end up in a mess. Cheers, Daniele >-----Original Message----- >From: Gert Grammel [mailto:ggrammel@juniper.net] >Sent: lunedì 17 dicembre 2012 15.34 >To: Daniele Ceccarelli; CCAMP >Subject: Re: [CCAMP] Overlay model framework and context > >Honestly, > >If there are three ways of doing it, I first would like to >define 3 unambiguous terms to name them. >After that we can decide what makes most sense. >A) doesn't look scalable >B) is better but still creates tons of links >C) scales best but connectivity needs to be taken into account. > >If we name A "virtual client link" VCL, then B could be a >"virtual attachment link" VAL and C a "virtual topological link" VTL. > >Gert > > > >________________________________________ >From: Daniele Ceccarelli >Sent: Monday, December 17, 2012 3:13:14 PM >To: Gert Grammel; CCAMP >Subject: RE: [CCAMP] Overlay model framework and context > >Hi Gert, > >Excellent catch. I totally missed it. > >Then we have two options for Virtual links definition...but >thinking a little bit more of it, there are actually 3 of them. > >OC1 OC2 > \ +---+IF2 IF3+---+ / > \IF1|OE1|-------------|OE2|IF4/ > +---+ +---+ > >A) Virtual link is from OC1 to OC2 >B) Virtual link is from IF1 to IF4 >C) Virtual link is from IF2 to IF3 > >Defining the virtual link as from IF2 to IF3 would need also >to include the connectivity matrices of OE1 and OE2, while >from IF1 to IF4 would remove the need for them as the >information related to the connectivity matrix is already >implied into the virtual link. Am i missing something? > >What would you suggest as the more reasonable definition? > >Cheers, >Daniele > > >>-----Original Message----- >>From: Gert Grammel [mailto:ggrammel@juniper.net] >>Sent: lunedì 17 dicembre 2012 14.27 >>To: Daniele Ceccarelli; CCAMP >>Subject: Re: [CCAMP] Overlay model framework and context >> >>Daniele, >> >>Thank you for summarizing the current state of discussion. To move >>forward and to encourage comments, let me point to some of the issues >>that are debated: >> >>1) Virtual Link: in the terminology statement a virtual link seems to >>connect two client elements. However later on the 3) virtual topology >>is composed of access links and virtual links. Hence. Virtual links >>connect server nodes, not client nodes. By doing so, segments (AL and >>VL) are created. >>2) The scalability consideration in the appendix for VL is based on >>terminology 1) rather than on virtual topology 3). >>This way it doesn't describe then the scalability of a virtual >>topology (which doesn't necessitate a full mesh) but rather that of a >>virtual node (which implies a full connectivity matrix). >> >>To sum up: >>1) we have to come up with a crisp definition of a VL in a virtual >>topology that is different from a terminology 1) VL. >>Here is a gap >>2) A Model based on a vitual node or 'terminology 1) links' >>create n**2 problems on client side and does not scale. >>3) 'VNT'-virtual-links 3) and access links are supposed to >address the >>scaling problem. We need to clean up our terminology. >Otherwise we end >>up associating limitations of terminology 1) links with >VNT-links that >>address those limitations. >> >>Now looking at the appendix it sadly reflects the terminology >confusion >>and jumps to assessment and conclusions. That's unfortunate: >> >>The first line says: >>Some notes on the Virtual Node: >>1. Virtual Link Model along, sadly, >>--> is it now about virtual nodes or virtual links or VNT links? >>2. The only way to avoid full-mesh of Virtual Links is by >>having intermediate nodes interconnecting Virtual Links in the middle >>of the virtual topology >>--> that's why access links are so useful. They end at server nodes >>--> which are connected via virtual links >>3. These intermediate nodes cannot be real server domain >>switches, because, generally speaking: >>--> in case of VNT-VLs no intermediate nodes are necessarily required >>4. --> No need to comment, this way doesn't scale anyway. >>5. If you want to compute SRLG-disjoint paths that could >>potentially go through a real server domain switch, the latter's >>connectivity matrix must expose "internal" SRLGs, so that the two >>services traversing the switch will not simultaneously fail >if a single >>internal element shared by the services fails >>--> who is 'you' that computes? A client selects among VNT >>virtual links based on exposed SRLGs, VLs are computed by the server >>with full knowledge of constraints. So what does an 'internal' SRLG >>mean to a server path computation? >>6. If you walk through all cases that need to be >>addressed when you are traffic engineering topologies with blocking >>switches, you will understand that there is absolutely no difference >>between a virtual node and real blocking real node. >>--> I suggest to model a complete network of say 5 nodes in a >>single VN and compare it with the model of a single real node. >> >>--> The assessments made have used a terminology definition >>that doesn't really capture the case made for VNT-VLs. >>That's why I would have had appreciated to split definitions and work >>items agreed among a group from individual assessments in separate >>emails. >>Nevertheless I consider the first part of your email (all except the >>appendix) as a good starting point for further clarification. >> >>Gert >>________________________________________ >>From: ccamp-bounces@ietf.org on behalf of Daniele Ceccarelli >>Sent: Monday, December 17, 2012 12:17:08 PM >>To: CCAMP >>Subject: [CCAMP] Overlay model framework and context >> >>Dear CCAMPers, >> >>In the last weeks several off-line discussions on the Overlay model >>framework and related works took place. Some discussions led to some >>sort of agreemet among a small group of people, some others >to a set a >>viable options, some others to totally open issues. I tried to >>summarize the output of such discussions below so to progress the >>discussions into a single thread on the WG ML. >> >>Please note that the aim of this mail is not to present a well shaped >>and conclusive idea to the WG but rather to provide the basis for >>starting a discussion from a barely shaped idea (step 1) instead of >>starting it from scratch (step 0). >> >>In addition you can find attached a slide depicting a proposal of the >>overlay scenario. >> >>Thanks, >>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 client layer network that is >>maintained/controlled in and by the server 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 server >>network domain nodes that are collectively represented to >the clients >>as a single node that exists in the client layer network and >is capable >>of terminating of access, inter-domain and virtual links. >> 3.Virtual Topology: Virtual topology is a collection of one or more >>virtual or real server network domain nodes that exist in the client >>layer network and are interconnected via 0 or more virtual links. >> 4. Overlay topology: is a superset of virtual topologies >provided by >>each of server network domains, access and inter-domain links. >> 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. Overlay Customer (OC): Something like the CN in RFC4208 >teminology >>but (i) receiving virtual topology from the core network and >requesting >>the set up of one of them or (ii) requesting the computation and >>establishment of a path accordingly to gien constraints in the core >>network and receiving the parameters characterizing such >path. (ii) == >>UNI. >> 7. Overlay Edge (OE): Something like the EN in RFC4208 but able to >>deal with (i) and (ii) above. >> 8. ONI : Overlay network interface: Interface allowing for signaling >>and routing messages exchange between Overlay and Core >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 OE to OC via signaling after the LSP establishment >>in the core network or from OC to OE to be used as path computation >>constraints, fall under the definition of signaling info and not >>routing info). >> 9. O-NNI (name to be found,maybe reused): Interface on the links >>between different core networks in the overlay model >environment, i.e. >>Between border OEs. Same features of the ONI apply to this interface. >>Could it be an E-NNI? A ONI? A new name is needed? >> >>+ Statements >> 1. In the context of overlay model we are aiming to build an overlay >>topology for the client network domains 2. The overlay topology is >>comprised of: >> a) access links (links connecting client NEs to the >server network >>domains). They can be PSC or LSC. >> b) inter-domain links (links interconnecting server network >>domains) >> c) virtual topology provided by the server 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 instance for the client network and a >>separate instance for the server network and in the ONI case >the server >>network also surreptitiously participates in the client network by >>injecting virtual topology information into it. >> 6. L1VPN (and LxVPN) in general is a service provided over >the ONI (it >>falls under the UNI case as no routing adjacency is in place >between OC >>and OE). >> >>+ Open issues/questions >> >> 1. PCE-PCEP - do we need to include considerations about PCE >and PCEP >>into the overlay framework context? >> 2. BGP-LS needs to be considered >> 3. Should potentials be included? E.g. I2RS? >> >>+ Appendix: >>Some notes on the Virtual Node: >>1. Virtual Link Model along, sadly, does not scale >>because of N**2 problem. IP over ATM and single-segment PWs have the >>same issue, that's why people invented multi-segment PWs >>2. The only way to avoid full-mesh of Virtual Links is by >>having intermediate nodes interconnecting Virtual Links in the middle >>of the virtual topology >>3. These intermediate nodes cannot be real server domain >>switches, because, generally speaking: >> a)Real switches belong to different layer network; >> b)Real switches are named from different naming space >> c)real switches individually may not have sufficient resources to >>terminate virtual links (while a group of real switches collectively >>will have) >> d)Presenting a group of real switches as a single virtual node have >>better scalability qualities >>4. Even if you map a virtual node on a single real node, >>you need to keep in mind that real server domain switches are, >>generally speaking, blocking switches and as such must expose their >>connectivity matrices >>5. If you want to compute SRLG-disjoint paths that could >>potentially go through a real server domain switch, the latter's >>connectivity matrix must expose "internal" SRLGs, so that the two >>services traversing the switch will not simultaneously fail >if a single >>internal element shared by the services fails >>6. If you walk through all cases that need to be >>addressed when you are traffic engineering topologies with blocking >>switches, you will understand that there is absolutely no difference >>between a virtual node and real blocking real node. >>7. Even in case of pure VL model, client NEs connected to >>server network domain must be upgraded so that they could understand >>the connectivity matrices advertised by the border nodes describing >>connectivity constraints between access links and virtual links they >>terminate. >> >> >> >>=================================== >>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 >> >> >> > >
- Re: [CCAMP] Overlay model framework and context Gert Grammel
- [CCAMP] Overlay model framework and context Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework and context Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework and context Gert Grammel
- Re: [CCAMP] Overlay model framework and context Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework and context Gert Grammel
- Re: [CCAMP] Overlay model framework and context Lou Berger
- Re: [CCAMP] Overlay model framework and context Igor Bryskin
- Re: [CCAMP] Overlay model framework and context Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework and context Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework and context Lou Berger
- Re: [CCAMP] Overlay model framework and context Daniele Ceccarelli
- [CCAMP] R: Overlay model framework and context BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] Overlay model framework and context Lou Berger
- Re: [CCAMP] R: Overlay model framework and context Lou Berger
- [CCAMP] R: R: Overlay model framework and context BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] Overlay model framework and context Daniele Ceccarelli
- Re: [CCAMP] R: Overlay model framework and context Daniele Ceccarelli
- [CCAMP] R: R: Overlay model framework and context BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] Overlay model framework and context Igor Bryskin
- Re: [CCAMP] Overlay model framework and context Igor Bryskin
- Re: [CCAMP] Overlay model framework and context Lou Berger
- Re: [CCAMP] Overlay model framework and context Lou Berger
- [CCAMP] 答复: Overlay model framework and context Fatai Zhang
- [CCAMP] 答复: R: R: Overlay model framework and con… Fatai Zhang
- [CCAMP] R: Overlay model framework and context BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] Overlay model framework and context Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework and context Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework and context Lou Berger
- Re: [CCAMP] Overlay model framework and context Daniele Ceccarelli
- Re: [CCAMP] R: R: Overlay model framework and con… Igor Bryskin
- Re: [CCAMP] Overlay model framework and context Lou Berger
- Re: [CCAMP] Overlay model framework and context Daniele Ceccarelli
- Re: [CCAMP] Overlay model framework and context Lou Berger
- Re: [CCAMP] Overlay model framework and context Igor Bryskin
- [CCAMP] R: R: R: Overlay model framework and cont… BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] R: R: Overlay model framework and con… Igor Bryskin
- Re: [CCAMP] Overlay model framework and context Snigdho Bardalai
- Re: [CCAMP] Overlay model framework and context Igor Bryskin
- Re: [CCAMP] R: R: Overlay model framework and con… John E Drake
- Re: [CCAMP] R: R: Overlay model framework and con… Igor Bryskin
- Re: [CCAMP] R: R: Overlay model framework and con… John E Drake
- Re: [CCAMP] R: R: Overlay model framework and con… Igor Bryskin
- Re: [CCAMP] R: R: Overlay model framework and con… John E Drake
- Re: [CCAMP] R: R: Overlay model framework and con… Igor Bryskin
- Re: [CCAMP] Overlay model framework and context Snigdho Bardalai
- Re: [CCAMP] Overlay model framework and context Igor Bryskin
- Re: [CCAMP] Overlay model framework and context Snigdho Bardalai
- Re: [CCAMP] Overlay model framework and context Igor Bryskin
- Re: [CCAMP] Overlay model framework and context Snigdho Bardalai
- Re: [CCAMP] Overlay model framework and context Igor Bryskin
- Re: [CCAMP] Overlay model framework and context Snigdho Bardalai
- Re: [CCAMP] Overlay model framework and context Snigdho Bardalai
- Re: [CCAMP] Overlay model framework and context John E Drake
- Re: [CCAMP] Overlay model framework and context Snigdho Bardalai
- [CCAMP] R: R: R: Overlay model framework and cont… BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] Overlay model framework and context Igor Bryskin
- Re: [CCAMP] Overlay model framework and context Snigdho Bardalai
- Re: [CCAMP] Overlay model framework and context Igor Bryskin
- Re: [CCAMP] Overlay model framework and context Iftekhar Hussain
- Re: [CCAMP] Overlay model framework and context Iftekhar Hussain
- Re: [CCAMP] Overlay model framework and context Iftekhar Hussain
- Re: [CCAMP] Overlay model framework and context Gert Grammel
- Re: [CCAMP] Overlay model framework and context Snigdho Bardalai
- Re: [CCAMP] Overlay model framework and context Igor Bryskin
- Re: [CCAMP] Overlay model framework and context Snigdho Bardalai
- Re: [CCAMP] Overlay model framework and context Gert Grammel
- Re: [CCAMP] Overlay model framework and context Daniele Ceccarelli