Return-Path: 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 8A23621F856D for ; Thu, 17 Jan 2013 08:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 sL9IsEzEQvXG for ; Thu, 17 Jan 2013 08:24:01 -0800 (PST) Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7B121F8792 for ; Thu, 17 Jan 2013 08:24:00 -0800 (PST) Received: by mail-bk0-f48.google.com with SMTP id jc3so1458791bkc.7 for ; Thu, 17 Jan 2013 08:23:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=LYIWKOHtadUl+0kblls7llyx8Kfg0CnUfBvpGC50xD0=; b=Sc7bw+p0I16M2AVspIXgpsPvAKDkJ6JRTPlWn3+G8pHgFU2sC4Dxboyb3HcgHArmvW srIeqOQ6LeY30qrpTEaDqw9FHcFx9Thuo7y5AX4UhqhU6mpQIQ5LoCNJFmqLsk4sOScQ 179QKVUdPnuo9sGeHJbPmIYrSK3dmXn+istUTmTL3tTBRQT9GHE1jr8I4faxfAoP954M oZZzBHf6IuRHC4lDYhst494RGCxXIuDl9MDMJfPQT0Uw3MX4FdkFzbjSJEac8Xh8QN4Y /TSivRDRf0WQ6EODfRiyWpOMCI1w/O3o2NvaVV2M4NxnZMAsoY82z/rGb38oeFNppd1H wnFw== MIME-Version: 1.0 X-Received: by 10.204.7.145 with SMTP id d17mr1708385bkd.84.1358439839604; Thu, 17 Jan 2013 08:23:59 -0800 (PST) Received: by 10.204.170.139 with HTTP; Thu, 17 Jan 2013 08:23:59 -0800 (PST) In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4806CC86@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE4806C450@ESESSMB301.ericsson.se> <6386D6323049044BA592CB99AB04BACB3F947CB8@SV-EXDB-PROD1.infinera.com> <6386D6323049044BA592CB99AB04BACB3F947D83@SV-EXDB-PROD1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4806CB06@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE4806CC86@ESESSMB301.ericsson.se> Date: Thu, 17 Jan 2013 11:23:59 -0500 Message-ID: From: Vishnu Pavan Beeram To: Daniele Ceccarelli Content-Type: multipart/alternative; boundary=0015175885ea16a0d504d37e6cbc Cc: CCAMP Subject: Re: [CCAMP] Overlay model framework v2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:24:05 -0000 --0015175885ea16a0d504d37e6cbc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Daniele, Hi! >> What you say is more than true but orthogonal to my point :-) I'm not sure what is orthogonal to your point. I was trying to make 2 points. - One was with respect to the "Virtual Topology" definition and I think we are more or less in sync with that. - The second point (example) was an attempt (guess I failed) to address your open-issue-4. I guess you would need to elaborate a bit more on that issue. I don't see how you can change the definition of the VL to avoid advertising the "connectivity constraints". Regards, -Pavan > It's only a matter of terminology. We defined: > > > 3. Virtual Topology: Virtual topology is a collection of one or > > more virtual or real provider network domain nodes that exist in > > the customer layer network and are interconnected via 0 or more > > virtual links. > > If we call it "Virtual Topology", the first thing that comes to the minds > is: its only a collection of virtual links and virtual nodes. > Snigdho's proposal was to call it differently so to better identify the > fact that it includes both virtual and real links/nodes, that's it. > The name he proposed, however, is again misleading, because calling it > "provider topology" makes me (and you) thinking of just real links/nodes, > doesn't it? > > I would suggest not to use either of the terms as both are misleading. > Maybe something like "exported topology", "CE-PE tology" or whatever. > > Daniele > > >-----Original Message----- > >From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > >Sent: gioved=EC 17 gennaio 2013 16.29 > >To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP > >Subject: RE: Overlay model framework v2 > > > >Daniele, > > > >We want to separate a Virtual Topology advertised to the > >clients (which is, generally speaking, different for different > >sets of clients) from provider real topology, which must be > >concealed from the clients. > >I disagree with Snigdho, when he is saying that a PE just has > >multiple aliases (one from each client name space). There is > >much more to this. The way I see it a PE contributes > >differently to different Virtual Topologies (each time with a > >different ID, sometimes as a whole, sometimes as split into > >several VNs, sometimes as a part of a large VN, possibly with > >a separate connectivity matrix. it also, depending on Virtual > >Topology, presents itself as switch of a different layer > >network, and so forth). Therefore, PE in the context of > >Virtual Topology is always a Virtual Node, even when it is > >mapped 1:1 onto real provider switch. In general, only VN can > >terminate a VL. > > > >Igor > > > >-----Original Message----- > >From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > >Sent: Thursday, January 17, 2013 9:53 AM > >To: Snigdho Bardalai; Igor Bryskin; CCAMP > >Subject: RE: Overlay model framework v2 > > > >Igor, Snigdho, > > > >I agree with Snigdho. Why don't we call it provider topology > >(or whatever) if it includes both virtual links/nodes and real > >links/nodes? I don't think it has anything to deal with naming space. > > > >Further replies in line > > > >I'd like to have feedbacks from you and all on Open Issue 4. > >That's an advertisement models draft issue but it's something > >that i can't really understand yet. > > > >BR > >Daniele > > > >>-----Original Message----- > >>From: Snigdho Bardalai [mailto:SBardalai@infinera.com] > >>Sent: gioved=EC 17 gennaio 2013 5.28 > >>To: Igor Bryskin; Daniele Ceccarelli; CCAMP > >>Subject: RE: Overlay model framework v2 > >> > >>Hi Igor, > >> > >>Not sure if the case you are citing qualifies a real node or > >link to be > >>called virtual. The client space name is simply an alias. > >> > >>Regards > >>Snigdho > >> > >>> -----Original Message----- > >>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > >>> Sent: Wednesday, January 16, 2013 3:04 PM > >>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP > >>> Subject: RE: Overlay model framework v2 > >>> > >>> Snigdho, > >>> > >>> > 3. Virtual Topology: Virtual topology is a collection of one or > >>> > more virtual or real provider network domain nodes that exist in > >>> > the customer layer network and are interconnected via 0 or more > >>> > virtual links. > >>> > >>> [SCB] Since the topology advertised by the provider network can > >>> contain real or virtual elements, why do we call it "virtual > >>> topology"? Should it simply be called "provider topology"? And then > >>> specify that it may contain both virtual or real elements. > >>> > >>> Virtual topology includes only virtual nodes. Even when we are > >>> considering real PEs terminating VLs, we must treat the PEs in the > >>> context of Virtual Topology as VNs since they must be named > >from the > >>> client naming space. > >>> > >>> Igor > >>> > >>> > >>> -----Original Message----- > >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > >>On Behalf > >>> Of Snigdho Bardalai > >>> Sent: Wednesday, January 16, 2013 5:48 PM > >>> To: Daniele Ceccarelli; CCAMP > >>> Subject: Re: [CCAMP] Overlay model framework v2 > >>> > >>> Hi Daniele, > >>> > >>> A few comments. Please see in-line. > >>> > >>> Thanks > >>> Snigdho > >>> > >>> > -----Original Message----- > >>> > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > >>> Behalf > >>> > Of Daniele Ceccarelli > >>> > Sent: Wednesday, January 16, 2013 7:33 AM > >>> > To: CCAMP > >>> > Subject: [CCAMP] Overlay model framework v2 > >>> > > >>> > Dear overlayers, > >>> > > >>> > Please find below a new version (v2) of the framework summary > >>> > reflecting the latest discussions. Again i hope i've captured all > >>> > the comments around, sorry if anything is missing, in case > >>just let > >>> > me know what i missed. > >>> > > >>> > BR > >>> > 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 provider layer > >network that > >>> is > >>> > maintained/controlled in and by the provider 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 > >>> > provider network domain nodes that are collectively > >>represented to > >>> > the clients as a single node that exists in the customer layer > >>> > network and is capable of terminating of access, inter-domain and > >>> virtual links. > >>> > >>> [SCB] Agree with Igor's comment - a virtual node can be a > >>combination > >>> of multiple nodes or a part of the single node, but to the customer > >>> node this is transparent. > > > >Yes, agree. > > > >>> > >>> > 3. Virtual Topology: Virtual topology is a collection of one or > >>> > more virtual or real provider network domain nodes that exist in > >>> > the customer layer network and are interconnected via 0 or more > >>> > virtual links. > >>> > >>> [SCB] Since the topology advertised by the provider network can > >>> contain real or virtual elements, why do we call it "virtual > >>> topology"? Should it simply be called "provider topology"? And then > >>> specify that it may contain both virtual or real elements. > > > >See above > > > >>> > >>> > 4. Overlay topology: is a superset of virtual > >topologies provided > >>> by > >>> > each of provider network domains, access and inter-domain links. > >>> > >>> [SCB] A more concise definition for the overlay topology is > >>- CE nodes > >>> + Access-links + provider topology as advertised by the provider > >>> network. > > > >We wanted to include also the possiblity of having multiple > >provider domains. > > > >>> > >>> > 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. CE (customer Edge): Something like the CN in RFC4208 > >>teminology > >>> > but (i) receiving virtual topology from the provider network and > >>> > requesting the set up of one of them or > >>> > (ii) requesting the computation and establishment of a path > >>> > accordingly to given constraints in the provider network and > >>> > receiving the parameters characterizing such path. (ii) =3D=3D UNI. > >>> > 7. PE (provider Edge): Something like the EN in RFC4208 > >>but able to > >>> > deal with (i) and (ii) above. > >>> > 8. PE-CE interface (former ONI) : Interface allowing for > >>signaling > >>> > and routing messages exchange between customer overlay > >>and provider > >>> > 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 CE to PE via signaling after the LSP > >>> > establishment in the core network or from CE to PE to be used as > >>> > path computation constraints, fall under the definition of > >>> > signaling info and not routing info). > >>> > 9. CE-CE (former O-NNI): Interface on the links between > >different > >>> > provider networks in the overlay model environment. Same > >features > >>> > of the CE-PE apply to this interface. > >>> > >>> [SCB] Is this "PE-PE" instead of "CE-CE"? > > > >Oooops! Definitely. > > > >>> > >>> > > >>> > + Statements > >>> > 1. In the context of overlay model we are aiming to build an > >>> > overlay topology for the customer network domains 2. > >The overlay > >>> > topology > >>> is > >>> > comprised of: > >>> > a) access links (links connecting client NEs to the provider > >>> > network domains). > >>> > They can be PSC or LSC. > >>> > b) inter-domain links (links interconnecting server network > >>> > domains) > >>> > c) virtual topology provided by the provider 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 CP instance for the customer network > >>> and > >>> > a separate instance for the provider network and in the CE-PE > >>> > interface case the provider network also surreptitiously > >>> participates > >>> > in the customer network by injecting virtual topology > >information > >>> > into it. > >>> > >>> [SCB] Specific implementations may or may not have a single > >instance > >>> for the provider and the overlay. > > > >Mmm, that's true. It MUST work with two different instances > >but no one prevents it to work with a single one. > > > >>> > >>> > 6. L1VPN (and LxVPN) in general is a type of service > >>provided over > >>> > the CE-PE interface (it falls under the UNI case as no routing > >>> > adjacency is in place between CE and PE). > >>> > >>> > > >>> > > >>> > + Advertisement models (to be detailed in dedicated > >>> > + document/documents) > >>> > The CE-PE interface in the overlay model context foresees > >>two types > >>> > of advertisement models.(names still to be agreed) A. > >>Augmented UNI: > >>> > The GMPLS UNI is defined in RFC4208 and augmented by a number of > >>> > actived draft (references to various drafts to be added). > >>> > The Augmented UNI is a particular type of CE-PE interface where > >>> > only signaling messages are exchanged between CE and PE. > >Messages > >>> > from CE to PE can include a set of parameters to be used > >>by the PE > >>> > as path computation constraints when computing a path in the > >>> > provider domain network, while messages from PE to CE can > >>include a > >>> > set of > >>> parameters > >>> > qualifying the LSP being established, like for example > >>SRLG, delay, > >>> > loss etc. > >>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply > >>> > called with the general CE-PE interface term?) allowing the > >>> > establishment of signaling and routing adjacency between > >>CE and PE. > >>> > Routing info passed from PE to CE comprise overlay topology > >>> > information including (but not limited to) virtual links, > >>> > connectivity matrices and access links with parameters qualifying > >>> each > >>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling > >>> > information > >>> and procedures are compliant with RFC4208. > >>> > > >>> > + Open issues/questions > >>> > 1. PCE-PCEP - do we need to include considerations about PCE and > >>> PCEP > >>> > into the overlay framework context? > >>> > >>> [SCB] IMO - this should be described in the overlay > >>framework document > >>> to establish the context. > > > >+1 > > > >>> > >>> > 2. BGP-LS needs to be considered > >>> > 3. Should potentials be included? E.g. I2RS? > >>> > 4. Virtual links: wouldn't a different definition of > >>virtual links > >>> > avoid the advertisement of connectivity matrices (this is > >>out of the > >>> > fwk scope but within the advertisement models one)? > >>> > Take this example: > >>> > PE1-----CE1 CE2-----PE2 > >>> > CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D=3DCE2 > >>> > CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D=3DCE2 > >>> > i.e. There are 2 VL connecting CE1 and CE2 that could be available > >>> for > >>> > PE1 and PE2 to set up an adjacency in the customer domain. CE1 > >>> > and/or > >>> > CE2 can be blocking nodes so VL1 and/or VL2 are available only > >>> > depending on the connectivity matrices of CE1 and CE2. Hence PEs > >>> > need to be aware of both VL and connectivity matrices. My > >>point is: > >>> > if CE1 advertises to PE1 only the VL that his connectivity matrix > >>> > allows to be connected to PE1 (e.g. VL1 only) and not all > >of them, > >>> > it should be possible to avoid the connectivity matrices > >>advertisement. > >>> > > >>> > > >>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > 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 > --0015175885ea16a0d504d37e6cbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Daniele, Hi!


>> What you say is more than true but orthogonal to = my point :-)

I'm not sure what is orthogonal to your point.=A0
I was trying to make 2 points.=A0
- One was with respect to the "Virtual Topology"= ; definition and I think we are more or less in sync with that.=A0
- The second point (example) was an attempt (guess I failed) to address you= r open-issue-4. I guess you would need to elaborate a bit more on that issu= e. I don't see how you can change the definition of the VL to avoid adv= ertising the "connectivity constraints".

Regards,
-Pavan


It's only a matter of terminology. We defined:

> =A03. Virtual Topology: Virtual topology is a collection of one or
> more virtual or real provider =A0network domain nodes that exist in > the customer layer network and are interconnected =A0via 0 or more
> virtual links.

If we call it "Virtual Topology", the first thing that come= s to the minds is: its only a collection of virtual links and virtual nodes= .
Snigdho's proposal was to call it differently so to better identify the= fact that it includes both virtual and real links/nodes, that's it. The name he proposed, however, is again misleading, because calling it &quo= t;provider topology" makes me (and you) thinking of just real links/no= des, doesn't it?

I would suggest not to use either of the terms as both are misleading. Mayb= e something like "exported topology", "CE-PE tology" or= whatever.

Daniele

>-----Original Message-----
>From: Igor Bryskin [mailto:= IBryskin@advaoptical.com]
>Sent: gioved=EC 17 gennai= o 2013 16.29
>To: Daniele Ceccarelli; Snigdho Bardalai; CCAMP
>Subject: RE: Overlay model framework v2
>
>Daniele,
>
>We want to separate a Virtual Topology advertised to the
>clients (which is, generally speaking, different for different
>sets of clients) from provider real topology, which must be
>concealed from the clients.
>I disagree with Snigdho, when he is saying that a PE just has
>multiple aliases (one from each client name space). There is
>much more to this. The way I see it a PE contributes
>differently to different Virtual Topologies (each time with a
>different ID, sometimes as a whole, sometimes as split into
>several VNs, sometimes as a part of a large VN, possibly with
>a separate connectivity matrix. it also, depending on Virtual
>Topology, presents itself as switch of a different layer
>network, and so forth). Therefore, PE in the context of
>Virtual Topology is always a Virtual Node, even when it is
>mapped 1:1 onto real provider switch. In general, only VN can
>terminate a VL.
>
>Igor
>
>-----Original Message-----
>From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
>Sent: Thursday, January 17, 2013 9:53 AM
>To: Snigdho Bardalai; Igor Bryskin; CCAMP
>Subject: RE: Overlay model framework v2
>
>Igor, Snigdho,
>
>I agree with Snigdho. Why don't we call it provider topology
>(or whatever) if it includes both virtual links/nodes and real
>links/nodes? I don't think it has anything to deal with naming spac= e.
>
>Further replies in line
>
>I'd like to have feedbacks from you and all on Open Issue 4.
>That's an advertisement models draft issue but it's something >that i can't really understand yet.
>
>BR
>Daniele
>
>>-----Original Message-----
>>From: Snigdho Bardalai [mailto:SBardalai@infinera.com]
>>Sent: gioved=EC 17 gennaio 2013 5.28
>>To: Igor Bryskin; Daniele Ceccarelli; CCAMP
>>Subject: RE: Overlay model framework v2
>>
>>Hi Igor,
>>
>>Not sure if the case you are citing qualifies a real node or
>link to be
>>called virtual. The client space name is simply an alias.
>>
>>Regards
>>Snigdho
>>
>>> -----Original Message-----
>>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
>>> Sent: Wednesday, January 16, 2013 3:04 PM
>>> To: Snigdho Bardalai; Daniele Ceccarelli; CCAMP
>>> Subject: RE: Overlay model framework v2
>>>
>>> Snigdho,
>>>
>>> > =A03. Virtual Topology: Virtual topology is a collection = of one or
>>> > more virtual or real provider =A0network domain nodes tha= t exist in
>>> > the customer layer network and are interconnected =A0via = 0 or more
>>> > virtual links.
>>>
>>> [SCB] Since the topology advertised by the provider network ca= n
>>> contain real or virtual elements, why do we call it "virt= ual
>>> topology"? Should it simply be called "provider topo= logy"? And then
>>> specify that it may contain both virtual or real elements.
>>>
>>> Virtual topology includes only virtual nodes. Even when we are=
>>> considering real PEs terminating VLs, we must treat the PEs in= the
>>> context of Virtual Topology as VNs since they must be named >from the
>>> client naming space.
>>>
>>> Igor
>>>
>>>
>>> -----Original Message-----
>>> From: ccamp-bounces@= ietf.org [mailto:ccamp-bounce= s@ietf.org]
>>On Behalf
>>> Of Snigdho Bardalai
>>> Sent: Wednesday, January 16, 2013 5:48 PM
>>> To: Daniele Ceccarelli; CCAMP
>>> Subject: Re: [CCAMP] Overlay model framework v2
>>>
>>> Hi Daniele,
>>>
>>> A few comments. Please see in-line.
>>>
>>> Thanks
>>> Snigdho
>>>
>>> > -----Original Message-----
>>> > From: ccamp-bou= nces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On
>>> Behalf
>>> > Of Daniele Ceccarelli
>>> > Sent: Wednesday, January 16, 2013 7:33 AM
>>> > To: CCAMP
>>> > Subject: [CCAMP] Overlay model framework v2
>>> >
>>> > Dear overlayers,
>>> >
>>> > Please find below a new version (v2) of the framework sum= mary
>>> > reflecting the latest discussions. Again i hope i've = captured all
>>> > the comments around, sorry if anything is missing, in cas= e
>>just let
>>> > me know what i missed.
>>> >
>>> > BR
>>> > Daniele
>>> >
>>> >
>>> > + Disclaimer:
>>> > =A01. Packet opto integration is often considered but the=
>>work can be
>>> > extented to any type of SC. Eg. TDM over LSC.
>>> >
>>> > + Terminology:
>>> > =A01. Virtual Link: A virtual link is a potential path be= tween two
>>> > virtual or real network =A0elements in a provider layer >network =A0that
>>> is
>>> > maintained/controlled in and by the provider =A0domain >control plane
>>> > (and as such cannot transport any traffic/data and protec= ted from
>>> > being
>>> > =A0de-provisioned) and which can be instantiated in the d= ata plane
>>> > (and then can =A0carry/transport/forward traffic/data) pr= eserving
>>> > previously advertised attributes such as =A0fate sharing<= br> >information.
>>> > =A02. =A0Virtual Node: Virtual node is a collection of ze= ro or more
>>> > provider network domain =A0nodes that are collectively >>represented to
>>> > the clients as a single node that =A0exists in the custom= er layer
>>> > network and is capable of terminating of access, =A0inter= -domain and
>>> virtual links.
>>>
>>> [SCB] Agree with Igor's comment - a virtual node can be a<= br> >>combination
>>> of multiple nodes or a part of the single node, but to the cus= tomer
>>> node this is transparent.
>
>Yes, agree.
>
>>>
>>> > =A03. Virtual Topology: Virtual topology is a collection = of one or
>>> > more virtual or real provider =A0network domain nodes tha= t exist in
>>> > the customer layer network and are interconnected =A0via = 0 or more
>>> > virtual links.
>>>
>>> [SCB] Since the topology advertised by the provider network ca= n
>>> contain real or virtual elements, why do we call it "virt= ual
>>> topology"? Should it simply be called "provider topo= logy"? And then
>>> specify that it may contain both virtual or real elements.
>
>See above
>
>>>
>>> > =A04. Overlay topology: =A0is a superset of virtual
>topologies provided
>>> by
>>> > each of =A0provider network domains, access and inter-dom= ain links.
>>>
>>> [SCB] A more concise definition for the overlay topology is >>- CE nodes
>>> + Access-links + provider topology as advertised by the provid= er
>>> network.
>
>We wanted to include also the possiblity of having multiple
>provider domains.
>
>>>
>>> > =A05. Access Link: Link between OC and OE. GMPLS runs on<= br> >>that link. It
>>> > can support =A0any of the SCs supported by the GMPLS.
>>> > =A06. CE (customer Edge): Something like the CN in RFC420= 8
>>teminology
>>> > but (i) receiving =A0virtual topology from the provider n= etwork and
>>> > requesting the set up of one of them or
>>> > =A0(ii) requesting the computation and establishment of a= path
>>> > accordingly to given constraints =A0in the provider netwo= rk and
>>> > receiving the parameters characterizing such path. (ii) = =3D=3D UNI.
>>> > =A07. PE (provider Edge): Something like the EN in RFC420= 8
>>but able to
>>> > deal with (i) and (ii) above.
>>> > =A08. PE-CE interface (former ONI) : Interface allowing f= or
>>signaling
>>> > and routing messages =A0exchange between customer overlay=
>>and provider
>>> > network. Routing information consists on =A0virtual topol= ogy
>>> > advertisement. When there is no routing adjacency across = the
>>> interface
>>> > it is equivalent to the GMPLS UNI defined in 4208. Signal= ing
>>> > messages are compliant with =A0RFC4208. Information relat= ed to path
>>> > carachteristics, e.g. TE-metrics, collected SRLG, =A0path=
>delay etc,
>>> > either passed from CE to PE via signaling after the LSP >>> > establishment in the core network or from CE to PE to be = used as
>>> > path computation constraints, fall =A0under the definitio= n of
>>> > signaling info and not routing info).
>>> > =A09. CE-CE (former O-NNI): Interface on the links betwee= n
>different
>>> > provider networks =A0in the overlay model environment. Sa= me
>features
>>> > of the CE-PE apply to this interface.
>>>
>>> [SCB] Is this "PE-PE" instead of "CE-CE"?<= br> >
>Oooops! Definitely.
>
>>>
>>> >
>>> > + Statements
>>> > =A01. In the context of overlay model we are aiming to bu= ild an
>>> > overlay topology for =A0the customer network domains =A02= .
>The overlay
>>> > topology
>>> is
>>> > comprised of:
>>> > =A0 =A0 a) access links (links connecting client NEs to t= he provider
>>> > network domains).
>>> > =A0They can be PSC or LSC.
>>> > =A0 =A0 b) inter-domain links (links interconnecting serv= er network
>>> > domains)
>>> > =A0 =A0 c) virtual topology provided by the provider netw= ork domains.
>>> > Virtual Links =A0+ Virtual Nodes (TBD) + Connectivity Mat= rix (with a
>>> set
>>> > of parameters e.g. SRLG, =A0optical impairments, delay et= c for each
>>> > entry) describing connectivity between access links and v= irtual
>>> links.
>>> > =A03. In the context of overlay model we manage =A0hierar= chy
>>of overlay
>>> > topologies =A0with overlay/underlay relationships =A04. I= n
>the context
>>> > of overlay model multi-layering and inter-layer
>relationships =A0are
>>> > peripheral at best, it is all about horizontal network in= tegration
>>> 5.
>>> > The overlay model assumes one CP instance for the custome= r network
>>> and
>>> > a separate =A0instance for the provider network and in th= e CE-PE
>>> > interface case the provider =A0network also surreptitious= ly
>>> participates
>>> > in the customer network by injecting =A0virtual topology<= br> >information
>>> > into it.
>>>
>>> [SCB] Specific implementations may or may not have a single >instance
>>> for the provider and the overlay.
>
>Mmm, that's true. It MUST work with two different instances
>but no one prevents it to work with a single one.
>
>>>
>>> > =A06. L1VPN (and LxVPN) in general is a type of service >>provided over
>>> > the CE-PE interface =A0(it falls under the UNI case as no= routing
>>> > adjacency is in place between CE and PE).
>>>
>>> >
>>> >
>>> > + Advertisement models (to be detailed in dedicated
>>> > + document/documents)
>>> > =A0The CE-PE interface in the overlay model context fores= ees
>>two types
>>> > of advertisement =A0models.(names still to be agreed) A.<= br> >>Augmented UNI:
>>> > The GMPLS UNI is defined in RFC4208 and augmented by =A0a= number of
>>> > actived draft (references to various drafts to be added).=
>>> > =A0The Augmented UNI is a particular type of CE-PE interf= ace where
>>> > only signaling messages =A0are exchanged between CE and P= E.
>Messages
>>> > from CE to PE can include =A0a set of parameters to be us= ed
>>by the PE
>>> > as path computation constraints =A0when computing a path = in the
>>> > provider domain network, while messages from PE =A0to CE = can
>>include a
>>> > set of
>>> parameters
>>> > qualifying the LSP being established, =A0like for example=
>>SRLG, delay,
>>> > loss etc.
>>> > B. ONI: The GMPLS ONI is a CE-PE interface (this could be= simply
>>> > called with the =A0general CE-PE interface term?) allowin= g the
>>> > establishment of signaling and routing adjacency =A0betwe= en
>>CE and PE.
>>> > Routing info passed from PE to CE comprise overlay topolo= gy
>>> > information including =A0(but not limited to) virtual lin= ks,
>>> > connectivity matrices and access links with parameters qu= alifying
>>> each
>>> > of them in terms of e.g. SRLG, loss, delay etc. Signaling=
>>> > information
>>> and procedures are =A0compliant with RFC4208.
>>> >
>>> > + Open issues/questions
>>> > =A01. PCE-PCEP - do we need to include considerations abo= ut PCE and
>>> PCEP
>>> > into the overlay framework context?
>>>
>>> [SCB] IMO - this should be described in the overlay
>>framework document
>>> to establish the context.
>
>+1
>
>>>
>>> > =A02. BGP-LS needs to be considered
>>> > =A03. Should potentials be included? E.g. I2RS?
>>> > =A04. Virtual links: wouldn't a different definition = of
>>virtual links
>>> > avoid the advertisement of connectivity matrices (this is=
>>out of the
>>> > fwk scope but within the advertisement models one)?
>>> > Take this example:
>>> > PE1-----CE1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CE2-----PE2
>>> > =A0 =A0 =A0 =A0 CE1=3D=3D=3D=3D=3D=3DVL1=3D=3D=3D=3D=3D= =3DCE2
>>> > =A0 =A0 =A0 =A0 CE1=3D=3D=3D=3D=3D=3DVL2=3D=3D=3D=3D=3D= =3DCE2
>>> > i.e. There are 2 VL connecting CE1 and CE2 that could be = available
>>> for
>>> > PE1 and PE2 to set up an adjacency in the customer domain= . CE1
>>> > and/or
>>> > CE2 can be blocking nodes so VL1 and/or VL2 are available= only
>>> > depending on the connectivity matrices of CE1 and CE2. He= nce PEs
>>> > need to be aware of both VL and connectivity matrices. My=
>>point is:
>>> > if CE1 advertises to PE1 only the VL that his connectivit= y matrix
>>> > allows to be connected to PE1 (e.g. VL1 only) and not all=
>of them,
>>> > it should be possible to avoid the connectivity matrices<= br> >>advertisement.
>>> >
>>> >
>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> > DANIELE CECCARELLI
>>> > System & Technology - PDU Optical & Metro
>>> >
>>> > Via E.Melen, 77
>>> > Genova, Italy
>>> > Phone +390106002512
>>> > Mobile +393346725750
>>> > daniel= e.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
h= ttps://www.ietf.org/mailman/listinfo/ccamp

--0015175885ea16a0d504d37e6cbc--