Re: [CCAMP] Overlay model framework and context

Lou Berger <lberger@labn.net> Wed, 19 December 2012 15:09 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 0AFC221F863C for <ccamp@ietfa.amsl.com>; Wed, 19 Dec 2012 07:09:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.957
X-Spam-Level:
X-Spam-Status: No, score=-100.957 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, 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 iijblJWpxTsb for <ccamp@ietfa.amsl.com>; Wed, 19 Dec 2012 07:09:46 -0800 (PST)
Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id D117F21F8618 for <ccamp@ietf.org>; Wed, 19 Dec 2012 07:09:46 -0800 (PST)
Received: (qmail 20373 invoked by uid 0); 19 Dec 2012 15:09:23 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 19 Dec 2012 15:09:23 -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=784QZz4uzHuL1Wb8Mzn+0yPZGbGKTV6Ked8r3g6yL9A=; b=zjJKo37rXeYlpgVqbG7BoPR72K493XpGWr3xZe8uwcHePK72URcVZS41xe3spkP6ZjcVsLbGrLvaPC6fiStAFqZ1SsrD0wvhPjR/v9w9eJzTKjiqPXHx379TEQhM8ssH;
Received: from box313.bluehost.com ([69.89.31.113]:44422 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1TlLGt-0005od-H4; Wed, 19 Dec 2012 08:09:23 -0700
Message-ID: <50D1D8A1.3060807@labn.net>
Date: Wed, 19 Dec 2012 10:09:21 -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>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48045007@ESESSMB301.ericsson.se>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
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: Wed, 19 Dec 2012 15:09:48 -0000

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
>>>
>>
> 
> 
>