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

John E Drake <jdrake@juniper.net> Thu, 20 December 2012 19:01 UTC

Return-Path: <jdrake@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 4586F21F84F5 for <ccamp@ietfa.amsl.com>; Thu, 20 Dec 2012 11:01:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.69
X-Spam-Level:
X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[AWL=-3.985, 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, 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 iCGNVd4IsAyb for <ccamp@ietfa.amsl.com>; Thu, 20 Dec 2012 11:01:23 -0800 (PST)
Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 62F5C21F84F9 for <ccamp@ietf.org>; Thu, 20 Dec 2012 11:01:21 -0800 (PST)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUNNggJvZUBCM+tnhYXEdZAr9wavIoCUC@postini.com; Thu, 20 Dec 2012 11:01:21 PST
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 20 Dec 2012 11:00:14 -0800
Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 20 Dec 2012 11:00:13 -0800
Received: from db3outboundpool.messaging.microsoft.com (213.199.154.142) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 20 Dec 2012 11:07:41 -0800
Received: from mail113-db3-R.bigfish.com (10.3.81.228) by DB3EHSOBE008.bigfish.com (10.3.84.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Dec 2012 19:00:12 +0000
Received: from mail113-db3 (localhost [127.0.0.1]) by mail113-db3-R.bigfish.com (Postfix) with ESMTP id D7174440262 for <ccamp@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Thu, 20 Dec 2012 19:00:10 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -81
X-BigFish: PS-81(zzbb2dI98dI9371Ic89bh168aJ15cbKJ148cI542I1432I1418I4015I111aIzz1de0h1202h1e76h1d1ah1d2ahzz1033IL18602eh8275bh8275dhz2dh2a8h668h839h941hd25hf0ah1269h1288h12a5h12a9h12bdh12e1h137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h)
Received: from mail113-db3 (localhost.localdomain [127.0.0.1]) by mail113-db3 (MessageSwitch) id 1356030007914517_17563; Thu, 20 Dec 2012 19:00:07 +0000 (UTC)
Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.254]) by mail113-db3.bigfish.com (Postfix) with ESMTP id D27AE2000A7; Thu, 20 Dec 2012 19:00:07 +0000 (UTC)
Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 20 Dec 2012 19:00:03 +0000
Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.110]) by BL2PRD0510HT001.namprd05.prod.outlook.com ([10.255.100.36]) with mapi id 14.16.0245.002; Thu, 20 Dec 2012 19:00:02 +0000
From: John E Drake <jdrake@juniper.net>
To: Igor Bryskin <IBryskin@advaoptical.com>, "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: AQHN3tR2EyIlD6SfV0uWPczluqb0CJgiCgsw
Date: Thu, 20 Dec 2012 19:00:01 +0000
Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E0B6D5856@BL2PRD0510MB349.namprd05.prod.outlook.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>
In-Reply-To: <CDAC6F6F5401B245A2C68D0CF8AFDF0A191015F3@atl-srv-mail10.atl.advaoptical.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.224.52]
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%ADVAOPTICAL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$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] 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:01:27 -0000

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