Re: [CCAMP] Overlay model framework v2

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

Lou,

Snipped.  I think this discussion is pointing out that we may be having charter creep in the sense that we are starting to impinge upon the work of the L3/L2 VPN and MPLS WGs.

I am also having a hard time remembering what problem we are trying to solve.  We have been through enhancements to the overlay model, the GMPLS ENNI, and enhancements to virtual links, as well as one or two I have probably forgotten.

Irrespectively Yours,

John

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Lou Berger
> Sent: Tuesday, January 22, 2013 7:51 AM
> To: Igor Bryskin
> Cc: CCAMP
> Subject: Re: [CCAMP] Overlay model framework v2
> 
> Igor,
> 
> see below.
> 
> On 1/22/2013 10:05 AM, Igor Bryskin wrote:
> > Lou and Daniele,
> > Please, see my comments in-line,
> >
> > Cheers,
> > Igor
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> Behalf
> > Of Lou Berger
> > Sent: Monday, January 21, 2013 5:13 PM
> > To: Daniele Ceccarelli
> > Cc: CCAMP
> > Subject: Re: [CCAMP] Overlay model framework v2
> >
> > Thanks Daniele, See below.
> >
> > On 1/21/2013 9:41 AM, Daniele Ceccarelli wrote:
> >> Hi Lou,
> >>
> >> Please find comments in line
> >>
> >> BR
> >> Daniele
> >>
> >>> -----Original Message-----
> >>> From: Lou Berger [mailto:[e-mail]]
> >>> Sent: venerdì 18 gennaio 2013 18.27
> >>> To: Daniele Ceccarelli
> >>> Cc: CCAMP
> >>> Subject: Re: [CCAMP] Overlay model framework v2
> >>>
> >>> Daniele,
> >>> 	Very nice summary.  Just catching up, so sorry for the
> >>> (2 day) late response.
> >>>
> >>> I really like how the terminology has evolved and appreciate the
> >>> summary!
> >>>
> >>> I have a few detail comments, but before I go there I'd like to
> >>> cover one more open issue that I think will have some
> >>> (minor) ripple effects on the details.
> >>>
> >>> I think there's still the general issue of terminology to use when
> >>> referring to the entity that "uses an overlay" and the entity that
> >>> "instantiates the overlay".  In your mail and in discussion we
> have:
> >>>
> >>> - client (service)/OC/CN/customer
> >>>
> >>> and
> >>>
> >>> - server(or service)/OE/EN/provider
> >>>
> >>> I think we had discussed, and possibly agreed on, using VPN
> >>> terminology which would have us use the latter options, i.e.,
> >>> (overlay) customer/provider (edge).  This would mean eliminating
> any
> >>> references to client/server in the *generic
> >>> overlay* definitions.  Of course these terms may reemerge in other
> >>> contexts as they have before, e.g., rfc6215.
> >>
> >> Yes, i think we all agreed. If there are still terms different from
> >> customer/provider in the text it's because i missed them during the
> >> replacing.
> >>
> >
> > Great!  Glad I didn't miss something over the holidays!
> >
> > IB>> I personally have no problems with the VPN terminology. However,
> > IMO the terminology should be aligned with the RFC 4208 and George's
> > drafts.
> 
> My issue with 4208 is that UNI (and ENNI) are just too narrowly scoped
> to encompass the broad spectrum of overlays that are/have been
> discussed.
> 
> > One cannot use different terminology within the same framework,
> right?
> 
> Unfortunately we have no shortage of terminology defining (perhaps
> different flavors) of the same thing!
> 
> > Furthermore, both RFC4208 and ONTs are not necessarily about VPNs.
> 
> While I certainly agree that not all overlays need be VPNs, it seems to
> me that our discussions are best aligned with that set of terminology,
> and that UNI/ENNI can be described within the CE/PE/VN/VL/VT
> constructs.
> Perhaps with some tweaking in some cases.
> 
> 
> > The most important goal is to provide a solution for inter-domain
> > horizontal integration between networks with possibly different
> > switching technologies and independent addressing within the overlay
> > model.
> >
> 
> Sure.  It's also possible that an overlay will use the same switching
> technology (e.g., MPLS over MPLS, ODU1 over ODU4) or even (but probably
> less likely) the same address space (if a provider so chooses).
>