Re: [CCAMP] Overlay model framework and context
Lou Berger <lberger@labn.net> Thu, 20 December 2012 14:39 UTC
Return-Path: <lberger@labn.net>
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 1E9F021F8853 for <ccamp@ietfa.amsl.com>; Thu, 20 Dec 2012 06:39:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.233
X-Spam-Level:
X-Spam-Status: No, score=-100.233 tagged_above=-999 required=5 tests=[AWL=-1.223, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 IwK7MauVj0qy for <ccamp@ietfa.amsl.com>; Thu, 20 Dec 2012 06:39:51 -0800 (PST)
Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id BF31421F850C for <ccamp@ietf.org>; Thu, 20 Dec 2012 06:39:51 -0800 (PST)
Received: (qmail 13007 invoked by uid 0); 20 Dec 2012 14:39:30 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 20 Dec 2012 14:39:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=7qiLQ7zNLaWqzQ8iZEgL5eehy/qqP2zjUQ9roIQvdTs=; b=o2ZqIuUW5LYdRfN4k3S6+ONFTvxn/cdQp8flke4y8uSH6C8l7SJ8DrQPPPYZYt0Ld62L+ESAsUF+0wi3b48r6cSvmkT4Pk5dD2Y6uprCgc7ztZUM4nGCzq580ET8L4O8;
Received: from box313.bluehost.com ([69.89.31.113]:35956 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1TlhHV-00044S-Le; Thu, 20 Dec 2012 07:39:30 -0700
Message-ID: <50D32320.3010707@labn.net>
Date: Thu, 20 Dec 2012 09:39:28 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
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> <4A1562797D64E44993C5CBF38CF1BE480456A7@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE480456A7@ESESSMB301.ericsson.se>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
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 14:39:53 -0000
Daniele, Just my opinion, but I see overlays as the (much) more generic term. I think LxVPNs are types of overlays, as are traditional layered networks, as are the technologies that match/will result from discussions taking place in the NVO3 context. Lou On 12/20/2012 5:22 AM, Daniele Ceccarelli wrote: > 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