[CCAMP] 答复: Overlay model framework and context

Fatai Zhang <zhangfatai@huawei.com> Thu, 20 December 2012 01:44 UTC

Return-Path: <zhangfatai@huawei.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 D379421F8A5D for <ccamp@ietfa.amsl.com>; Wed, 19 Dec 2012 17:44:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.861
X-Spam-Level: ***
X-Spam-Status: No, score=3.861 tagged_above=-999 required=5 tests=[AWL=-1.327, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, 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_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
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 RtYoLDAKxxMl for <ccamp@ietfa.amsl.com>; Wed, 19 Dec 2012 17:44:35 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1022721F89EB for <ccamp@ietf.org>; Wed, 19 Dec 2012 17:44:33 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMQ85348; Thu, 20 Dec 2012 01:44:32 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 01:44:18 +0000
Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 01:44:28 +0000
Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.142]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Thu, 20 Dec 2012 09:44:24 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: Lou Berger <lberger@labn.net>, Igor Bryskin <IBryskin@advaoptical.com>, "BELOTTI, SERGIO (SERGIO)" <sergio.belotti@alcatel-lucent.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
Thread-Topic: [CCAMP] Overlay model framework and context
Thread-Index: Ac3cSA0EmhmMt2XQR3eDsLDm5eAESgAA+90AAFIdqgAADaepgAAL4JUAABWmQyA=
Date: Thu, 20 Dec 2012 01:44:24 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF835841B4C@SZXEML552-MBX.china.huawei.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>
In-Reply-To: <50D248B8.1090506@labn.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.72.159]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: CCAMP <ccamp@ietf.org>
Subject: [CCAMP] =?gb2312?b?tPC4tDogIE92ZXJsYXkgbW9kZWwgZnJhbWV3b3JrIGFu?= =?gb2312?b?ZCBjb250ZXh0?=
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 01:44:36 -0000

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 (which may be in the same, lower or higher layer network than of 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 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