Re: [CCAMP] Overlay model framework and context

Gert Grammel <ggrammel@juniper.net> Tue, 15 January 2013 16:33 UTC

Return-Path: <ggrammel@juniper.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 3CBCA21F8623 for <ccamp@ietfa.amsl.com>; Tue, 15 Jan 2013 08:33:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.475
X-Spam-Level: ***
X-Spam-Status: No, score=3.475 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, 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, UNRESOLVED_TEMPLATE=3.132]
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 nIZpSoLG4K3Y for <ccamp@ietfa.amsl.com>; Tue, 15 Jan 2013 08:33:07 -0800 (PST)
Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8B721F8558 for <ccamp@ietf.org>; Tue, 15 Jan 2013 08:33:07 -0800 (PST)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUPWEw+bFSz5egMolmtNIOV47QDjkJ3gk@postini.com; Tue, 15 Jan 2013 08:33:07 PST
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 15 Jan 2013 08:29:46 -0800
Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 15 Jan 2013 08:29:45 -0800
Received: from va3outboundpool.messaging.microsoft.com (216.32.180.13) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 15 Jan 2013 08:31:36 -0800
Received: from mail257-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 15 Jan 2013 16:29:37 +0000
Received: from mail257-va3 (localhost [127.0.0.1]) by mail257-va3-R.bigfish.com (Postfix) with ESMTP id 199731A00231 for <ccamp@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Tue, 15 Jan 2013 16:28:55 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -30
X-BigFish: PS-30(zzbb2dI98dI9371Ic89bhd6eah168aJ148cI542I1432I4015I14ffIzz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL18602eh8275bh8275dhz2dh2a8h668h839h941hd25hf0ah1269h1288h12a5h12a9h12bdh12e1h137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h)
Received: from mail257-va3 (localhost.localdomain [127.0.0.1]) by mail257-va3 (MessageSwitch) id 1358267330460061_10289; Tue, 15 Jan 2013 16:28:50 +0000 (UTC)
Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.254]) by mail257-va3.bigfish.com (Postfix) with ESMTP id 5AB0513C0091; Tue, 15 Jan 2013 16:28:50 +0000 (UTC)
Received: from CH1PRD0511HT001.namprd05.prod.outlook.com (157.56.245.197) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 15 Jan 2013 16:28:43 +0000
Received: from CH1PRD0511MB431.namprd05.prod.outlook.com ([169.254.8.162]) by CH1PRD0511HT001.namprd05.prod.outlook.com ([10.255.159.36]) with mapi id 14.16.0257.004; Tue, 15 Jan 2013 16:28:42 +0000
From: Gert Grammel <ggrammel@juniper.net>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Lou Berger <lberger@labn.net>
Thread-Topic: [CCAMP] Overlay model framework and context
Thread-Index: AQHN3pwCHEOpWQ1fgUqGNU71PXGD15ghwmgAgAAOsACAAALngIAAApeAgCjlR1A=
Date: Tue, 15 Jan 2013 16:28:41 +0000
Message-ID: <305443B66F0CD946A3107753337A03111311938B@CH1PRD0511MB431.namprd05.prod.outlook.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> <50D32320.3010707@labn.net> <4A1562797D64E44993C5CBF38CF1BE48045B14@ESESSMB301.ericsson.se> <50D331E1.5000703@labn.net> <4A1562797D64E44993C5CBF38CF1BE48045BBA@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48045BBA@ESESSMB301.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.224.50]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.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: Tue, 15 Jan 2013 16:33:09 -0000

Hi Daniele,

The list wasn't so busy anymore in 2013 as it was the year before. Would you mind to summarize what is perceived the wording/abbreviations we are converging to? This way we could start updating the wording of the ENNI framework document.

Best

Gert

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Donnerstag, 20. Dezember 2012 16:52
To: Lou Berger
Cc: CCAMP
Subject: Re: [CCAMP] Overlay model framework and context

You thought the world was grey, I spent half an hour to write an email trying to convince you that world is white and now you're convinced that the world is black!!!  :)


>-----Original Message-----
>From: Lou Berger [mailto:lberger@labn.net]
>Sent: giovedì 20 dicembre 2012 16.42
>To: Daniele Ceccarelli
>Cc: Fatai Zhang; Igor Bryskin; BELOTTI, SERGIO (SERGIO); CCAMP
>Subject: Re: [CCAMP] Overlay model framework and context
>
>Daniele,
>
>The piece that's missing from your mail is that your "vpn" 
>terms have wider scope than just VPNs.  For example CEs, PEs, access
>interfaces|links, inter-domain interfaces|links have scope well beyond
>VPNs.
>
>An alternate conclusion (which you have me now leaning
>towards) is that we should just use CE and PE in place of OE and OC.
>
>Lou
>
>On 12/20/2012 10:32 AM, Daniele Ceccarelli wrote:
>> Excellent,
>> 
>> So you'd agree with the general overlay definitions of OC
>and OE. (which in the case of VPNs will be called CE and PE).
>> 
>> What about an analogous approach when we move from nodes to
>interfaces/links. A general name for the overlay most general case 
>where specific exisitng names can be places (the famous umbrella).
>> 
>> - In the more generic case of overlay: the nodes are called
>OC and OE
>> and the interface between OC and OE is called (ONI, OI, OCI, xxxlink 
>> or whatever)
>> - In the case of interface supporting signaling only: The (ONI, OI, 
>> OCI, xxxlink or whatever) is a particular case of (ONI, OI, OCI or
>> whatever) and is called UNI, and the nodes at its ends are called CN 
>> and EN (RFC4208)
>> - In the case of VPNs: the (ONI, OI, OCI, xxxlink or
>whatever) is called access link and the nodes are called CE and PE.
>> 
>> I see no other way of putting some order among all the
>already existing terms.
>> 
>> BR
>> Daniele
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Lou Berger [mailto:lberger@labn.net]
>>> Sent: giovedì 20 dicembre 2012 15.39
>>> To: Daniele Ceccarelli
>>> Cc: Fatai Zhang; Igor Bryskin; BELOTTI, SERGIO (SERGIO); CCAMP
>>> Subject: Re: [CCAMP] Overlay model framework and context
>>>
>>> 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
>>>>>
>>>>
>>>
>> 
>
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp