Re: [CCAMP] Overlay model framework and context
Lou Berger <lberger@labn.net> Wed, 19 December 2012 17:38 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 A065A21F857D for <ccamp@ietfa.amsl.com>; Wed, 19 Dec 2012 09:38:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.865
X-Spam-Level:
X-Spam-Status: No, score=-99.865 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_55=0.6, 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 sXWDcm5v61NR for <ccamp@ietfa.amsl.com>; Wed, 19 Dec 2012 09:38:56 -0800 (PST)
Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 86BF821F84F5 for <ccamp@ietf.org>; Wed, 19 Dec 2012 09:38:56 -0800 (PST)
Received: (qmail 4342 invoked by uid 0); 19 Dec 2012 17:38:35 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 19 Dec 2012 17:38:35 -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:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=KHBJZqLCwd2h5fu3MzbmZw+lBnl7PbxKSlY2LNOhpFo=; b=dI288WKTg1QjZ/XUaR65lCEM0pvnm9ZvyAozZo7c6sI0G3m+eGYei0aeuDglLs/0HDCjWl6CApCODsb78hxGwc4ye1qX4A0wQW4+h3clA95jDf4Ded0Qaaqk/b1Uv6hV;
Received: from [70.192.226.175] (port=6686 helo=[10.171.169.74]) by box313.bluehost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from <lberger@labn.net>) id 1TlNbG-0004Pc-MQ; Wed, 19 Dec 2012 10:38:35 -0700
From: Lou Berger <lberger@labn.net>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
Date: Wed, 19 Dec 2012 12:38:33 -0500
Message-ID: <13bb43ec50d.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <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> <4A1562797D64E44993C5CBF38CF1BE480453D6@ESESSMB301.ericsson.se>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 AquaMail/1.2.0.7 (build: 2100159)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 70.192.226.175 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: Wed, 19 Dec 2012 17:38:57 -0000
Okay. This helps .so to simplify even further, we have the following alternatives: ONI = overlay customer interface. Right? Lou On December 19, 2012 11:23:50 AM Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> wrote: > 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