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

[John E Drake <[e-mail]>]

We disagree.

Irrespectively Yours,

John


> -----Original Message-----
> From: Igor Bryskin [mailto:[e-mail]]
> Sent: Thursday, December 20, 2012 12:08 PM
> To: John E Drake; BELOTTI, SERGIO (SERGIO); Fatai Zhang; Gert Grammel
> Cc: CCAMP
> Subject: RE: [CCAMP] R: R: Overlay model framework and context
> 
> The point is that the new definition explicitly requires maintaining CP
> state for server resources of the data link that has not been
> provisioned yet. This changes a lot of things.
> 
> -----Original Message-----
> From: John E Drake [mailto:[e-mail]]
> Sent: Thursday, December 20, 2012 2:37 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 don't actually see any substantive difference between the two
> definitions and the additional points you raise are not part of the new
> defintion.
> 
> Irrespectively Yours,
> 
> John
> 
> 
> > -----Original Message-----
> > From: Igor Bryskin [mailto:[e-mail]]
> > Sent: Thursday, December 20, 2012 11:24 AM
> > To: John E Drake; BELOTTI, SERGIO (SERGIO); Fatai Zhang; Gert Grammel
> > Cc: CCAMP
> > Subject: RE: [CCAMP] R: R: Overlay model framework and context
> >
> > 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:[e-mail]]
> > 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: [e-mail] [mailto:[e-mail]] 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:[e-mail]]
> > > 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:[e-mail]]
> > > 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
> > >
> > >
> > > -----邮件原件-----
> > > 发件人: [e-mail] [mailto:[e-mail]] 代表
> > > 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:[e-mail]]
> > > 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:[e-mail]]
> > > >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:[e-mail]]
> > > >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: [e-mail] [mailto:[e-mail]]
> > > >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:[e-mail]]
> > > >>> 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:[e-mail]]
> > > >>>>> 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 [phone]
> > > >>>>>> Mobile [phone]
> > > >>>>>> [e-mail] 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
> > > >>>>>> [e-mail]
> > > >>>>>> https://www.ietf.org/mailman/listinfo/ccamp
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>
> > > >> _______________________________________________
> > > >> CCAMP mailing list
> > > >> [e-mail]
> > > >> https://www.ietf.org/mailman/listinfo/ccamp
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > _______________________________________________
> > > CCAMP mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/ccamp
> > > _______________________________________________
> > > CCAMP mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/ccamp