Re: [CCAMP] Overlay model framework and context

Gert Grammel <ggrammel@juniper.net> Tue, 25 December 2012 11:37 UTC

Return-Path: <ggrammel@juniper.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F4221F86E8 for <ccamp@ietfa.amsl.com>; Tue, 25 Dec 2012 03:37:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.067
X-Spam-Level:
X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_55=0.6, 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 ay+rkfzEDBgS for <ccamp@ietfa.amsl.com>; Tue, 25 Dec 2012 03:37:10 -0800 (PST)
Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 33E2621F86E7 for <ccamp@ietf.org>; Tue, 25 Dec 2012 03:37:10 -0800 (PST)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUNmP5Ubd7Ur4KJKmkqeMXzEY/OSPjCvI@postini.com; Tue, 25 Dec 2012 03:37:10 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; Tue, 25 Dec 2012 03:37:09 -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; Tue, 25 Dec 2012 03:37:09 -0800
Received: from va3outboundpool.messaging.microsoft.com (216.32.180.31) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 25 Dec 2012 03:44:32 -0800
Received: from mail110-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 25 Dec 2012 11:37:08 +0000
Received: from mail110-va3 (localhost [127.0.0.1]) by mail110-va3-R.bigfish.com (Postfix) with ESMTP id 336993000EF for <ccamp@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Tue, 25 Dec 2012 11:37:08 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -26
X-BigFish: PS-26(zz9371Ic89bh168aJ542I1432I4015Izz1de0h1202h1e76h1d1ah1d2ahzz8275bh8275dh1033IL18602ehz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h)
Received: from mail110-va3 (localhost.localdomain [127.0.0.1]) by mail110-va3 (MessageSwitch) id 1356435424720167_22534; Tue, 25 Dec 2012 11:37:04 +0000 (UTC)
Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.241]) by mail110-va3.bigfish.com (Postfix) with ESMTP id A1BC4E004A; Tue, 25 Dec 2012 11:37:04 +0000 (UTC)
Received: from CH1PRD0511HT002.namprd05.prod.outlook.com (157.56.245.197) by VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 25 Dec 2012 11:37:04 +0000
Received: from CH1PRD0511MB431.namprd05.prod.outlook.com ([169.254.8.143]) by CH1PRD0511HT002.namprd05.prod.outlook.com ([10.255.159.37]) with mapi id 14.16.0245.002; Tue, 25 Dec 2012 11:37:03 +0000
From: Gert Grammel <ggrammel@juniper.net>
To: Iftekhar Hussain <IHussain@infinera.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, CCAMP <ccamp@ietf.org>
Thread-Topic: [CCAMP] Overlay model framework and context
Thread-Index: AQHN3FoyMpRFmiKOO0C4+grxFeglZpgdBiiQgAAIXmmAC5uhgIAAxXS+
Date: Tue, 25 Dec 2012 11:37:02 +0000
Message-ID: <305443B66F0CD946A3107753337A031103FAD034@CH1PRD0511MB431.namprd05.prod.outlook.com>
References: <305443B66F0CD946A3107753337A031103FAA66E@CH1PRD0511MB431.namprd05.prod.outlook.com>, <4A1562797D64E44993C5CBF38CF1BE480440B1@ESESSMB301.ericsson.se> <305443B66F0CD946A3107753337A031103FAA68A@CH1PRD0511MB431.namprd05.prod.outlook.com>, <D7D7AB44C06A2440B716F1F1F5E70AE53F9B6E52@SV-EXDB-PROD1.infinera.com>
In-Reply-To: <D7D7AB44C06A2440B716F1F1F5E70AE53F9B6E52@SV-EXDB-PROD1.infinera.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.255.159.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%INFINERA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
Subject: Re: [CCAMP] Overlay model framework and context
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Dec 2012 11:37:14 -0000

Yes,

I meant OE connectivity in the edge node. It doesn't matter in most switching technologies, but for wavelength switching there may be some ugly constraints to consider.

Gert
________________________________________
From: Iftekhar Hussain
Sent: Tuesday, December 25, 2012 12:50:19 AM
To: Gert Grammel; Daniele Ceccarelli; CCAMP
Subject: RE: [CCAMP] Overlay model framework and context

For C " scales best but connectivity ...", by connectivity do you mean OEs interconnectivity?

BR,
Iftekhar
-----Original Message-----
From: Gert Grammel [mailto:ggrammel@juniper.net]
Sent: Monday, December 17, 2012 6:34 AM
To: Daniele Ceccarelli; CCAMP
Subject: Re: [CCAMP] Overlay model framework and context

Honestly,

If there are three ways of doing it, I first would like to define 3 unambiguous terms to name them.
After that we can decide what makes most sense.
A) doesn't look scalable
B) is better but still creates tons of links
C) scales best but connectivity needs to be taken into account.

If we name A "virtual client link" VCL, then B could be a "virtual attachment link" VAL and C a "virtual topological link" VTL.

Gert



________________________________________
From: Daniele Ceccarelli
Sent: Monday, December 17, 2012 3:13:14 PM
To: Gert Grammel; CCAMP
Subject: RE: [CCAMP] Overlay model framework and context

Hi Gert,

Excellent catch. I totally missed it.

Then we have two options for Virtual links definition...but thinking a little bit more of it, there are actually 3 of them.

OC1                               OC2
  \    +---+IF2       IF3+---+    /
   \IF1|OE1|-------------|OE2|IF4/
       +---+             +---+

A) Virtual link is from OC1 to OC2
B) Virtual link is from IF1 to IF4
C) Virtual link is from IF2 to IF3

Defining the virtual link as from IF2 to IF3 would need also to include the connectivity matrices of OE1 and OE2, while from IF1 to IF4 would remove the need for them as the information related to the connectivity matrix is already implied into the virtual link. Am i missing something?

What would you suggest as the more reasonable definition?

Cheers,
Daniele


>-----Original Message-----
>From: Gert Grammel [mailto:ggrammel@juniper.net]
>Sent: lunedì 17 dicembre 2012 14.27
>To: Daniele Ceccarelli; CCAMP
>Subject: Re: [CCAMP] Overlay model framework and context
>
>Daniele,
>
>Thank you for summarizing the current state of discussion. To move
>forward and to encourage comments, let me point to some of the issues
>that are debated:
>
>1) Virtual Link: in the terminology statement a virtual link seems to
>connect two client elements. However later on the 3) virtual topology
>is composed of access links and virtual links. Hence. Virtual links
>connect server nodes, not client nodes. By doing so, segments (AL and
>VL) are created.
>2) The scalability consideration in the appendix for VL is based on
>terminology 1) rather than on virtual topology 3).
>This way it doesn't describe then the  scalability of a virtual
>topology (which doesn't necessitate a full mesh) but rather that of a
>virtual node (which implies a full connectivity matrix).
>
>To sum up:
>1) we have to come up with a crisp definition of a VL in a virtual
>topology that is different from a terminology 1) VL.
>Here is a gap
>2) A Model based on a vitual node or 'terminology 1) links'
>create n**2 problems on client side and does not scale.
>3) 'VNT'-virtual-links 3) and access links are supposed to address the
>scaling problem. We need to clean up our terminology. Otherwise we end
>up associating limitations of terminology 1) links with VNT-links that
>address those limitations.
>
>Now looking at the appendix it sadly reflects the terminology confusion
>and jumps to assessment and conclusions. That's unfortunate:
>
>The first line says:
>Some notes on the Virtual Node:
>1.      Virtual Link Model along, sadly,
>--> is it now about virtual nodes or virtual links or VNT links?
>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
>--> that's why access links are so useful. They end at server nodes
>--> which are connected via virtual links
>3.      These intermediate nodes cannot be real server domain
>switches, because, generally speaking:
>--> in case of VNT-VLs no intermediate nodes are necessarily required
>4.  --> No need to comment, this way doesn't scale anyway.
>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
>--> who is 'you' that computes? A client selects among VNT
>virtual links based on exposed SRLGs, VLs are computed by the server
>with full knowledge of constraints. So what does an 'internal' SRLG
>mean to a server path computation?
>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.
>--> I suggest to model a complete network of say 5 nodes in a
>single VN and compare it with the model of a single real node.
>
>--> The assessments made have used a terminology definition
>that doesn't really capture the case made for VNT-VLs.
>That's why I would have had appreciated to split definitions and work
>items agreed among a group from individual assessments in separate
>emails.
>Nevertheless I consider the first part of your email (all except the
>appendix) as a good starting point for further clarification.
>
>Gert
>________________________________________
>From: ccamp-bounces@ietf.org on behalf of Daniele Ceccarelli
>Sent: Monday, December 17, 2012 12:17:08 PM
>To: CCAMP
>Subject: [CCAMP] Overlay model framework and context
>
>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
>
>
>