Re: [CCAMP] Overlay model framework and context
Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Thu, 20 December 2012 10:22 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 403C821F85DF for <ccamp@ietfa.amsl.com>; Thu, 20 Dec 2012 02:22:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.487
X-Spam-Level:
X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[AWL=-2.180, BAYES_00=-2.599, CN_BODY_35=0.339, 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, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 Np4tO5GBeKte for <ccamp@ietfa.amsl.com>; Thu, 20 Dec 2012 02:22:49 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1529D21F8581 for <ccamp@ietf.org>; Thu, 20 Dec 2012 02:22:48 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-f3-50d2e6f7b568
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5A.EA.10459.7F6E2D05; Thu, 20 Dec 2012 11:22:48 +0100 (CET)
Received: from ESESSMB301.ericsson.se ([169.254.1.209]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 11:22:47 +0100
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: Fatai Zhang <zhangfatai@huawei.com>, Lou Berger <lberger@labn.net>, Igor Bryskin <IBryskin@advaoptical.com>, "BELOTTI, SERGIO (SERGIO)" <sergio.belotti@alcatel-lucent.com>
Thread-Topic: [CCAMP] Overlay model framework and context
Thread-Index: Ac3cSA0EmhmMt2XQR3eDsLDm5eAESgAPpvQAAFPqDzAAC9tFgAAL4JUAAAV55wAAE0X84A==
Date: Thu, 20 Dec 2012 10:22:46 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE480456A7@ESESSMB301.ericsson.se>
References: <4A1562797D64E44993C5CBF38CF1BE48042C3B@ESESSMB301.ericsson.se> <50CF764E.603@labn.net> <4A1562797D64E44993C5CBF38CF1BE48045007@ESESSMB301.ericsson.se> <CDAC6F6F5401B245A2C68D0CF8AFDF0A191012D6@atl-srv-mail10.atl.advaoptical.com> <50D248B8.1090506@labn.net> <F82A4B6D50F9464B8EBA55651F541CF835841B4C@SZXEML552-MBX.china.huawei.com>
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF835841B4C@SZXEML552-MBX.china.huawei.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="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje6PZ5cCDFa+5bJ4MucGi8WpnnZG i47mtywWyzb/Zrfoaz7P6sDqcXbBH1aP1md7WT1ajrxl9Viy5CeTx4dNzWwBrFFcNimpOZll qUX6dglcGZ9n9bEUHJnCWHFr4QzWBsY7Exi7GDk5JARMJFYde8EEYYtJXLi3nq2LkYtDSOAQ o8SSdY+ZIZwljBJ/jy5i6WLk4GATsJJ4csgHJC4isJVRYt69bmaQbmYBKYm7t7rApgoLWEis XXsQzBYRsJRoWj2dFaRXRCBMYusOI5Awi4CqRNeyY4wgYV4Bb4murZUgYSGBh0wSv84bgNic QNXnl08Eu41RQFZiwu5FjBCbxCVuPZkPdbOAxJI955khbFGJl4//sULYihIfX+2DqteSmNfw mwnCVpSY0v2QHcTmFRCUODnzCcsERrFZSMbOQtIyC0nLLCQtCxhZVjGy5yZm5qSXG25iBEbY wS2/dXcwnjoncohRmoNFSZw3zPVCgJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGTL7pHy8f fxDY28Ak0/n3RvsM6e8WpzXKOQprHZ1W3zfx3JnK8pRlh2PRtZvGrE1drofFLVVeOBgKdF9R DWsXCGqXNDt/dmPjo3s5UYZ3+jfu530ypS3AYVqwhFHdYYtuhf1nFhkrJj/uVHd2eJu09QXP QV/m40uEq5kueykaJDfYLVF1O6fEUpyRaKjFXFScCAAUFAkvfgIAAA==
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: Thu, 20 Dec 2012 10:22:51 -0000
I prefer using reference points instead of links. Access link and inter-domain links means tens of things in different contexts, while e.g. UNI means one single thing and clearly identifies the context. BTW it's just a preference, I don't mind how we'll finally call it. There's one thing I would rather like to clarify and it's the relationship with VPNs. We have two options: 1) Is a VPN a particular case of the overlay model? or 2) Is the overlay model a particular case of VPN? I think this can help a lot with terminology. I've always assumed 1) but from what I read I tend to see that 2) has several supporters. BR Daniele >-----Original Message----- >From: Fatai Zhang [mailto:zhangfatai@huawei.com] >Sent: giovedì 20 dicembre 2012 2.44 >To: Lou Berger; Igor Bryskin; BELOTTI, SERGIO (SERGIO); >Daniele Ceccarelli >Cc: CCAMP >Subject: 答复: [CCAMP] Overlay model framework and context > >Hi all, > >Support. > >People are more familiar with the existing things like "access >links" and "inter-domain links" (or E-NNI links). > > > > >Best Regards > >Fatai > >-----邮件原件----- >发件人: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 代表 >Lou Berger >发送时间: 2012年12月20日 7:08 >收件人: Igor Bryskin >抄送: CCAMP >主题: Re: [CCAMP] Overlay model framework and context > >Igor, > >You said: >IB>> I like "access links" and "inter-domain links" better. > >This works for me. > >Lou > >On 12/19/2012 12:27 PM, Igor Bryskin wrote: >> Lou, please see my answers to your questions >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >On Behalf >> Of Daniele Ceccarelli >> Sent: Wednesday, December 19, 2012 5:57 AM >> To: Lou Berger >> Cc: CCAMP >> Subject: Re: [CCAMP] Overlay model framework and context >> >> 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"? >> >> IB>> Client layer is where Overlay Network topology exists. >It includes: >> a) access links (connecting OCs to OEs) >> b) virtual links (connecting OE / OVNs (Overlay Virtual >Nodes) within >> a given server domain) >> c) inter-domain links (connecting OE to OE that belong to >neighboring >> server domains) All three categories exist in the same client layer >> and named from the same naming space >> >> 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"? >> >> IB>> It is the layer where the UNT (Underlay Network >Topology) exists >> IB>> (which may be in the same, lower or higher layer >network than of >> IB>> the ONT) >> >> 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. >> IB>> agree >> >> In the case of the interface we generally define the ONI as >an overlay interface that in a particular case is called UNI. >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? >> >>> >>> - As you mention in the Appendix, (from the OC perspective) >there is >>> no difference between a virtual and real node >> IB>> Agree >> >> (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? >> >> IB>> As long as it allows for both or either signaling >and/or routing >> IB>> exchanges >> >>> >>> 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. >> >> IB>> I like "access links" and "inter-domain links" better. >Note also that a "link" and "node" are TE topology concepts >and orthogonal to CP interfaces (which are Signaling/Routing >speakers). If you mean by "internal" and "external" links the >CP connectivity, than I agree with you. >> >>> >>> 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 >>>> >>> >> _______________________________________________ >> 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 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