Re: [CCAMP] R: R: Overlay model framework and context

Igor Bryskin <IBryskin@advaoptical.com> Thu, 20 December 2012 19:24 UTC

Return-Path: <IBryskin@advaoptical.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 1B57A21F8A79 for <ccamp@ietfa.amsl.com>; Thu, 20 Dec 2012 11:24:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.774
X-Spam-Level: ***
X-Spam-Status: No, score=3.774 tagged_above=-999 required=5 tests=[AWL=-1.769, 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_17=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_55=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45]
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 d4YMELwXecZS for <ccamp@ietfa.amsl.com>; Thu, 20 Dec 2012 11:24:46 -0800 (PST)
Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4B521F8A85 for <ccamp@ietf.org>; Thu, 20 Dec 2012 11:24:45 -0800 (PST)
Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id qBKJOXpI013153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Dec 2012 20:24:33 +0100
Received: from MUC-SRV-MBX2.advaoptical.com (172.20.1.96) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.99.0; Thu, 20 Dec 2012 20:24:33 +0100
Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.516.32; Thu, 20 Dec 2012 20:24:32 +0100
Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0099.000; Thu, 20 Dec 2012 14:24:30 -0500
From: Igor Bryskin <IBryskin@advaoptical.com>
To: John E Drake <jdrake@juniper.net>, "BELOTTI, SERGIO (SERGIO)" <sergio.belotti@alcatel-lucent.com>, "Fatai Zhang" <zhangfatai@huawei.com>, Gert Grammel <ggrammel@juniper.net>
Thread-Topic: [CCAMP] R: R: Overlay model framework and context
Thread-Index: AQHN3golIyFRtaiE00OqrXfRSQzfIpghS9yAgACDEyCAABGTkIAABK0QgAB6+4D//63AkA==
Date: Thu, 20 Dec 2012 19:24:29 +0000
Message-ID: <CDAC6F6F5401B245A2C68D0CF8AFDF0A191016A8@atl-srv-mail10.atl.advaoptical.com>
References: <4A1562797D64E44993C5CBF38CF1BE48042C3B@ESESSMB301.ericsson.se> <50CF764E.603@labn.net> <4A1562797D64E44993C5CBF38CF1BE48045007@ESESSMB301.ericsson.se> <50D1D8A1.3060807@labn.net> <4A1562797D64E44993C5CBF38CF1BE48045378@ESESSMB301.ericsson.se> <F050945A8D8E9A44A71039532BA344D822403FB33C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <50D1E347.2070602@labn.net> <F050945A8D8E9A44A71039532BA344D822403FB364@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4A1562797D64E44993C5CBF38CF1BE4804541E@ESESSMB301.ericsson.se> <F050945A8D8E9A44A71039532BA344D822403FB3C5@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <F82A4B6D50F9464B8EBA55651F541CF835841B7F@SZXEML552-MBX.china.huawei.com> <CDAC6F6F5401B245A2C68D0CF8AFDF0A191014DD@atl-srv-mail10.atl.advaoptical.com> <F050945A8D8E9A44A71039532BA344D822403FB7F1@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <CDAC6F6F5401B245A2C68D0CF8AFDF0A191015F3@atl-srv-mail10.atl.advaoptical.com> <0182DEA5604B3A44A2EE61F3EE3ED69E0B6D5856@BL2PRD0510MB349.namprd05.prod.outlook.com>
In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E0B6D5856@BL2PRD0510MB349.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.21.1.81]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2012-12-20_06:2012-12-20, 2012-12-20, 1970-01-01 signatures=0
Cc: CCAMP <ccamp@ietf.org>
Subject: Re: [CCAMP] R: R: 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 19:24:48 -0000

John,

We define virtual link as:
> 1. Virtual Link: is a potential path between two virtual or real 
> server domain 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.

This definition is noticeably different from the one you mention and IMO suits our goals better because it requires maintaining a state for each resource that the VL depends upon even when the underlying data link is not provisioned. The said resource can be shared with other VLs but cannot be de-provisioned  or taken by some unrelated service. This is important because:
a) it allows for determining fate sharing information for VLs with non-existing underlying data link;
b) provides some reasonable guarantee that VL can be committed (data link will be created) at the time when it is needed
c) the fate sharing information will not change after the VL is committed, i.e. the network planning can be performed before the VL is committed 
d) etc.

Cheers,
Igor

-----Original Message-----
From: John E Drake [mailto:jdrake@juniper.net] 
Sent: Thursday, December 20, 2012 2:00 PM
To: Igor Bryskin; BELOTTI, SERGIO (SERGIO); Fatai Zhang; Gert Grammel
Cc: CCAMP
Subject: RE: [CCAMP] R: R: Overlay model framework and context

Igor,

I think the definition in RFC4847 is correct for our purposes:  

"Virtual link: A provider network Traffic Engineering (TE) link advertised to customers in routing information for purposes that include path computation. A direct data link may or may not exist between the two end points of a virtual link."

Irrespectively Yours,

John


> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf 
> Of Igor Bryskin
> Sent: Thursday, December 20, 2012 9:06 AM
> To: BELOTTI, SERGIO (SERGIO); Fatai Zhang; Gert Grammel
> Cc: CCAMP
> Subject: Re: [CCAMP] R: R: Overlay model framework and context
> 
> Sergio,
> 
> 1. According to MRN/MLN is it possible to name a virtual link  from an 
> independent naming space, if yes, please, provide the quote;
> 
> 2. According to MRN/MLN is it possible to terminate a virtual link by 
> a virtual node? What is relationship between VNs and VLs? How MLN/MRN 
> solves the O(N**2) problem presented by VNT made of VLs?
> How MLN/MRN address the blocking nature of nodes that terminate VLs 
> and access links? Please, provide the quote
> 
> 3. How MLN/MRN addresses the situation when VL with non-existing data 
> link is advertised, and 3 sec later some service takes a resource, 
> making impossible to provision the data link when it is needed? In 
> other words, how MLN/MRN guarantees that the advertised virtual link 
> is actually useful? Please, provide the quote
> 
> 4. How MLN/MRN addresses the mutual exclusive nature of multiple VLs 
> mapped onto the same physical provider network resource? Please, 
> provide the quote.
> 
> You also said:
> SB> it is possible to route a higher-layer LSP into a lower layer
>    on the assumption that proper hierarchical LSPs in the lower layer
>    will be dynamically created (triggered) as needed.
> 
> Is it possible according to MLN/MRN to route a client LSP into *higher 
> or the same layer* provider LSP?
> According to the framework we are discussing it is possible, because 
> we are not talking about network layers, rather, overlays/underlays, 
> which have arbitrary layer relationship.
> 
> Cheers,
> Igor
> 
> 
> -----Original Message-----
> From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel- 
> lucent.com]
> Sent: Thursday, December 20, 2012 11:32 AM
> To: Igor Bryskin; Fatai Zhang; Gert Grammel
> Cc: CCAMP; Lou Berger; Daniele Ceccarelli
> Subject: R: [CCAMP] R: R: Overlay model framework and context
> 
> Hi Igor,
> 
> See in line
> 
> Thanks
> 
> Cheers
> 
> Sergio
> 
> Belotti Sergio - System Architect
> ALCATEL-LUCENT  Optics Division
> 
> -----Messaggio originale-----
> Da: Igor Bryskin [mailto:IBryskin@advaoptical.com]
> Inviato: giovedì 20 dicembre 2012 16.34
> A: Fatai Zhang; Lou Berger; BELOTTI, SERGIO (SERGIO); Daniele 
> Ceccarelli
> Cc: CCAMP
> Oggetto: RE: [CCAMP] R: R: Overlay model framework and context
> 
> Fatai,
> You said:
>      (3) Virtual link
> 
>          I see the definition in RFC4847, it says " Virtual link: A
> provider network Traffic Engineering (TE) link    advertised to
> customers in routing information for purposes that include path 
> computation. A direct data link may or may not exist between the two 
> end points of a virtual link."
> 
> IB>> It is not accurate because in the context of this discussion 
> IB>> there
> is no direct (1:1) correlation between the virtual link advertised to 
> the customer and the provider link. Generally speaking:
> a) virtual link exists in a different layer network;
> 
> SB> as in MRN
> 
> b) virtual link may be mapped to a chain of provider (existing or not 
> yet existing) links
> 
> SB> as in MRN
> 
> c)virtual link may be mapped to a hierarchy (stack) of provider links.
> In short, virtual link is decoupled from provider links.
> 
> SB> it is possible to route a higher-layer LSP into a lower layer
>    on the assumption that proper hierarchical LSPs in the lower layer
>    will be dynamically created (triggered) as needed.
> 
>  what is the difference in this definition of Virtual TE-link in MRN 
> context?
> 
> Furthermore, the definition does not say what terminates virtual link.
> In our definition it can be terminated either by OE (overlay edge) or 
> VN (virtual node). Virtual link (as well as VN) is named from the 
> customer name space which is independent from provider (underlay) 
> space.
> 
> SB> I think for Fatai as for me the difference of your concept of
> virtual link is what already defined in IETF (MRN, L1VPN ) is not so 
> clear to justify a new definition.
> 
> 
> 
> Cheers,
> Igor
> 
> Cheers
> 
> Sergio
> 
> 
> -----Original Message-----
> From: Fatai Zhang [mailto:zhangfatai@huawei.com]
> Sent: Wednesday, December 19, 2012 9:31 PM
> To: Lou Berger; Igor Bryskin; BELOTTI, SERGIO (SERGIO); Daniele 
> Ceccarelli
> Cc: CCAMP
> Subject: 答复: [CCAMP] R: R: Overlay model framework and context
> 
> Hi Daniele and all,
> 
> Thanks for your useful information.
> 
> I agree with Sergio that it is better to use the existing terms to 
> avoid confusion if there are no significant differences between the 
> new terms and the existing ones.
> 
> I would like to discuss the terms with you guys.
> 
> (1) ONI & O-NNI vs (UNI & E-NNI)
> 
> Is there any inconvenience if we use E-NNI to replace O-NNI? I don't 
> see any difference between them.
> 
> Regarding ONI, the difference between UNI and ONI from your text is 
> that routing is allowed to exchange over ONI because it is assumed 
> that only signaling is allowed over UNI. I checked UNI definition in 
> G.8080, it does say that " Note, there is no routing function 
> associated with the UNI reference point.", but G.8080 allows resource 
> discovery can be allowed over UNI. However, if this is the only 
> difference between ONI and UNI, can we extend the UNI definition to 
> allow routing over UNI? We know that discovery (LMP) could be allowed 
> in OIF UNI 1.0R2 (is LMP signaling?). Can we simply regard routing here as resource discovery?
> :-)
> 
> (2) OC&OE vs (CE&PE)
> 
> I more like CE&PE than OC&OE, because CE&PE are so friendly for people.
> I just checked Y.1311 to see the definition of CE&PE. Actually, CE&PE 
> are just abbreviations. I think CE&PE are generic enough to fit 
> overlay context. How about to re-define CE&PE in the simliar way in 
> RFC4847 even though CE&PE is not suitable for overlay context?
> 
> I don't see the fundamental difference between the figure in the slide 
> and Figure 1 in RFC4208 besides these new terms.
> 
> (3) Virtual link
> 
> I see the definition in RFC4847, it says " Virtual link: A provider 
> network Traffic Engineering (TE) link advertised to customers in 
> routing information for purposes that include path computation. A 
> direct data link may or may not exist between the two end points of a 
> virtual link."
> 
> Is this not accurate?
> 
> (4) I think we can get more useful information from the existing IETF 
> drafts (LiVPN RFC/drafts) and ITU-T recommendations such as G.8080, 
> Y.1311, Y.1312....
> 
> 
> Best Regards
> 
> Fatai
> 
> 
> -----邮件原件-----
> 发件人: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 代表
> BELOTTI, SERGIO (SERGIO)
> 发送时间: 2012年12月20日 0:58
> 收件人: Daniele Ceccarelli
> 抄送: CCAMP
> 主题: [CCAMP] R: R: Overlay model framework and context
> 
> Ciao Daniele,
> 
> See in line
> 
> Thanks
> Sergio
> 
> Belotti Sergio - System Architect
> ALCATEL-LUCENT  Optics Division
> 
> -----Messaggio originale-----
> Da: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
> Inviato: mercoledì 19 dicembre 2012 17.48
> A: BELOTTI, SERGIO (SERGIO); Lou Berger
> Cc: CCAMP
> Oggetto: RE: R: [CCAMP] Overlay model framework and context
> 
> Hi Sergio,
> 
> A VPN is one of the many things (services) that can be done in an 
> overlay context and my proposal was to call such nodes OE and OC when 
> generally referring to them withing the overlay context. If in such 
> context you are proving a VPN, then the OE is a PE and the OC is a CE, 
> but only for the VPN. They are not a PE and a CE for every other 
> service going through them that is not a VPN.
> 
> SB> In the context of L1VPN , Overlay  stands for a Service Model, 
> SB> here
> it seems as though we change in the opposite in which you have a 
> network topology and VPN is a service on that. This creates some 
> confusion in my mind .
> 
> Take for example the "kilt". You don't call "kilt" every skirt. When 
> you're in the context of traditional scottish male clothing you call 
> it "kilt", otherwise it's generally called skirt. (apologies for the 
> example but a better one didn't come to my mind).
> 
> SB> Very good example
> 
> Wrt the MRN what is your proposal? Calling the virtual te-links just 
> VNT?
> 
> SB> Just taken the definition that are already there . So just
> reference them.
> 
> 
> Ciao
> Daniele
> 
> 
> >-----Original Message-----
> >From: BELOTTI, SERGIO (SERGIO)
> >[mailto:sergio.belotti@alcatel-lucent.com]
> >Sent: mercoledì 19 dicembre 2012 17.04
> >To: Lou Berger; Daniele Ceccarelli
> >Cc: CCAMP
> >Subject: R: R: [CCAMP] Overlay model framework and context
> >
> >Lou,
> >
> >I misunderstood your assumption sorry, yes we agree in the definition 
> >for OE and OC but referring to PE and CE as helpful reference in the 
> >definition.
> >
> >Sergio
> >
> >Belotti Sergio - System Architect
> >ALCATEL-LUCENT  Optics Division
> >
> >-----Messaggio originale-----
> >Da: Lou Berger [mailto:lberger@labn.net]
> >Inviato: mercoledì 19 dicembre 2012 16.55
> >A: BELOTTI, SERGIO (SERGIO)
> >Cc: Daniele Ceccarelli; CCAMP
> >Oggetto: Re: R: [CCAMP] Overlay model framework and context
> >
> >
> >Sergio,
> >       I'm not sure we're in agreement.  I'm fine with the OE/OC 
> >terminology.
> > (which shouldn't be too surprising...)
> >
> >Lou
> >
> >On 12/19/2012 10:46 AM, BELOTTI, SERGIO (SERGIO) wrote:
> >> Hi Daniele,
> >>
> >> Thanks a lot for your effort to summarize mail exchange.
> >>
> >> About the content and definitions , I would support the Lou
> position.
> >> I think that in this context many of the concepts and
> >definitions have been proposed , are already present in the IETF 
> >document.
> >>
> >> ONI definition and OE and OC definitions surely does not
> >help to clarify scenarios that has been already debated in the VPN 
> >context .
> >>
> >> I support UNI only definition without to complicate
> >proliferating with other interface definitions, and the usage of CE
> ,PE
> >for nodes.
> >> Moreover I have also perplexity about the definition of
> >Virtual Link and Virtual Topology.
> >>
> >> What are the difference and the added values to have very
> >similar definitions to what already well defined in the MRN context ?
> >>
> >> Thanks again for your effort.
> >>
> >> Ciao
> >> Sergio
> >>
> >> Belotti Sergio - System Architect
> >> ALCATEL-LUCENT  Optics Division
> >>
> >> -----Messaggio originale-----
> >> Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]
> >Per conto di Daniele Ceccarelli
> >> Inviato: mercoledì 19 dicembre 2012 16.32
> >> A: Lou Berger
> >> Cc: CCAMP
> >> Oggetto: Re: [CCAMP] Overlay model framework and context
> >>
> >>  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
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >> _______________________________________________
> >> 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