Re: [CCAMP] Overlay model framework and context
Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Wed, 19 December 2012 16:23 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 E036721F859C for <ccamp@ietfa.amsl.com>; Wed, 19 Dec 2012 08:23:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.35
X-Spam-Level:
X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=0.499, 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 vc27DpA3TY7x for <ccamp@ietfa.amsl.com>; Wed, 19 Dec 2012 08:23:54 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DBEAC21F8449 for <ccamp@ietf.org>; Wed, 19 Dec 2012 08:23:53 -0800 (PST)
X-AuditID: c1b4fb25-b7fb26d000006129-75-50d1ea18aed3
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 24.AB.24873.81AE1D05; Wed, 19 Dec 2012 17:23:52 +0100 (CET)
Received: from ESESSMB301.ericsson.se ([169.254.1.209]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 17:23:52 +0100
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: Lou Berger <lberger@labn.net>
Thread-Topic: [CCAMP] Overlay model framework and context
Thread-Index: Ac3cSA0EmhmMt2XQR3eDsLDm5eAESgAPpvQAAFPqDzAABwf3gAACrXmg///3AQD//+dnsA==
Date: Wed, 19 Dec 2012 16:23:50 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE480453D6@ESESSMB301.ericsson.se>
References: <4A1562797D64E44993C5CBF38CF1BE48042C3B@ESESSMB301.ericsson.se> <50CF764E.603@labn.net> <4A1562797D64E44993C5CBF38CF1BE48045007@ESESSMB301.ericsson.se> <50D1D8A1.3060807@labn.net> <4A1562797D64E44993C5CBF38CF1BE48045378@ESESSMB301.ericsson.se> <50D1E30E.8070407@labn.net>
In-Reply-To: <50D1E30E.8070407@labn.net>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvja7Eq4sBBvNWKVk8mXODxaKj+S2L A5PHkiU/mTw+bGpmC2CK4rJJSc3JLEst0rdL4Mr4e/I2W8G5rIotk3YzNjCeCuti5OSQEDCR WLLoCyOELSZx4d56ti5GLg4hgUOMErN+nGOEcJYwSsx9c5i5i5GDg03ASuLJIR+QBhEBRYmv HxcxgdjMAlISd291gQ0SFrCQWLv2ICNEjaVE0+rprCCtIgJhEt8vp4CYLAKqEpO2BXcxsnPw CnhLrLGG2LOUSeLTtHvsII2cAhoSzUc/MYPYjAKyEhN2L2KEWCQucevJfCaIiwUkluw5zwxh i0q8fPyPFcJWlNh5tp0Zol5P4sbUKWwQtrbEsoWvweK8AoISJ2c+YZnAKDYLydhZSFpmIWmZ haRlASPLKkb23MTMnPRyo02MwOg4uOW36g7GO+dEDjFKc7AoifOGu14IEBJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cC47ny76nx7MQ+1ZVUrOZumf4n4n9+gp/RsaUT0DguxZUcsDidN2RDd Fa6+5vipQy7arj43yjfM2tf77ML38ytS791UfxpdcNjv/z+PBXNkLvx4Zr8m9T/f148iPV3S 7NayDTUFCV1VTQl+j48+fpBpHXVG9vMM8SN8C/Oet32w0Z+x+Efn/sZgJZbijERDLeai4kQA 7r7qwFwCAAA=
Cc: CCAMP <ccamp@ietf.org>
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: Wed, 19 Dec 2012 16:23:57 -0000
Basically yes; being fussy i would say: For the signaling+routing(normal case): LB) customer interface with signaling and routing DC) ONI For the UNI case: LB) customer interface with UNI DC) UNI BR Daniele >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net] >Sent: mercoledì 19 dicembre 2012 16.54 >To: Daniele Ceccarelli >Cc: CCAMP >Subject: Re: [CCAMP] Overlay model framework and context > >Daniele, > If ONI is a superset (i.e., covers all cases), what's >the difference. >So the terminology options are: > >For the signaling+routing(normal case): > LB) customer interface with signaling and routing > DC) ONI with signaling and routing >For the UNI case: > LB) customer interface with UNI > DC) ONI with UNI > >Right? > >Lou > >On 12/19/2012 10:32 AM, Daniele Ceccarelli wrote: >> Lou, it's just a matter of convenience. >> >> Why should is say: >> "customer interface/link between an OE and an OC in the >overlay model context supporting both signaling and routing >message exchange that is called UNI when only signaling is supported" >> >> ...when i could simply say: ONI? :) >> >> BR >> Daniele >> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: mercoledì 19 dicembre 2012 16.09 >>> To: Daniele Ceccarelli >>> Cc: CCAMP >>> Subject: Re: [CCAMP] Overlay model framework and context >>> >>> Daniele, >>> see below. >>> >>> >>> On 12/19/2012 5:56 AM, Daniele Ceccarelli wrote: >>>> Hi Lou, >>>> >>>> Plese find replies in line. >>>> >>>> BR >>>> Daniele >>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: lunedì 17 dicembre 2012 20.45 >>>>> To: Daniele Ceccarelli >>>>> Cc: CCAMP >>>>> Subject: Re: [CCAMP] Overlay model framework and context >>>>> >>>>> >>>>> Daniele, >>>>> Thanks for getting this on-list discussion going. I have some >>>>> comments and questions: >>>>> >>>>> - So what's a "client layer network" in this context? >Perhaps you >>>>> mean OC or "(overlay) customer layer"? >>>> >>>> Yes. The terms client layer and server layer are >>> reminescences to be corrected. >>>> >>>>> >>>>> - So what's a "server layer network" in this context? >Perhaps you >>>>> mean OE or "(overlay) provider layer"? >>>> >>>> Again correct >>>> >>>>> >>>>> - For OC, I'd thing referring back to a CE in the VPN >context, and >>>>> likewise to a PE for an OE, is helpful context. >>>> >>>> In the case of the interface we generally define the ONI as >>> an overlay >>>> interface that in a particular case is called UNI. >>> >>> I have no idea what this means. I suspect it relates to comments >>> below, so will discuss there. >>> >>>> I would >>>> apply the same method: those nodes are called Overlay Customer and >>>> Overlay Edge and in the particular case of VPNs they are the >>> CE and PE >>>> respectively. What about that? >>>> >>> >>> How about: >>> >>> An OC is analogous to an L3VPN CE, and an OE is analogous >to an L3VPN >>> PE (with a provider based VPN). >>> >>>>> >>>>> - As you mention in the Appendix, (from the OC perspective) >>> there is >>>>> no difference between a virtual and real node (and >>> presumably link as >>>>> well). Given this and your comment in 8, that the ONI >can take the >>>>> form of a UNI or include both signaling and routing (i.e., a >>>>> peer/I-NNI or >>>>> E-NNI) what value is there in introducing the ONI term? >>> Said another >>>>> way, there's no specific term for the interface between a >CE and PE >>>>> in L3VPNs, so why do we need to introduce one in this context? >>>> >>>> We gave a name to the UNI, why don't giving to the ONI? >>> >>> Because redundant/unnecessary terminology only obfuscates. >>> >>> Why not customer interface/link? This has been sufficient >for L3VPNs. >>> >>>> >>>>> >>>>> I think this same comment probably holds for the O-NNI >>> (e.g., what's >>>>> the name of the interface between providers which support L3VPN >>>>> handoffs?)... >>>> >>>> I would suggest giving a name to that interface also in >>> order to distinguish between an "internal" and an "external" >>> link when multiple overlay provider network domains are present. >>>> >>> >>> How about inter-provider interface/link? Again, this has been >>> sufficient for L3VPNs. >>> >>> Lou >>> >>>>> >>>>> Much thanks, >>>>> Lou >>>>> >>>>> On 12/17/2012 6:17 AM, Daniele Ceccarelli wrote: >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> >
- 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