Re: [CCAMP] Overlay model framework v2

[Igor Bryskin <[e-mail]>]

Lou,

At my home we have a rule: if something is not being used for one year, it is pronounced  trash that is unlikely to be ever used, which is just taking space of something better and more contemporary and hence must be thrown away.  So I suggest implementing the same or similar rule in our CCAMP home:  let's make an inventory of existing CCAMP RFCs and throw away those that have never seen any interoperability tests and were never part of any product or solution.

Besides, I believe nothing (terminology, architecture,  protocol solutions, etc.)  of MLN/MRN is relevant to what we are/were trying to achieve with ONTs. 

Igor

-----Original Message-----
From: Lou Berger [mailto:[e-mail]] 
Sent: Tuesday, January 22, 2013 12:31 PM
To: Igor Bryskin; John E Drake
Cc: CCAMP; Stewart Bryant; [e-mail]; 'George Swallow (swallow)'
Subject: RE: [CCAMP] Overlay model framework v2

Igor,

Sorry to disappoint. I still see a relationship whether we reuse the terminology or not. I suspect that I am not alone in this.

Lou



On January 22, 2013 12:07:14 PM Igor Bryskin <[e-mail]> wrote:
> I was about to commend you on having stopped referring to MLN/MRN. I 
> was wrong and I agree with John that we are basically quite lost in 
> this discussion and may be should drop it precisely to not produce 
> another framework as useful as MLN/MRN.
>
> Igor
>
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Tuesday, January 22, 2013 11:51 AM
> To: John E Drake
> Cc: Igor Bryskin; CCAMP; Stewart Bryant; [e-mail]; 'George 
> Swallow (swallow)'
> Subject: Re: [CCAMP] Overlay model framework v2
>
> From my perspective, at a high-level the discussion is really about 
> how best to revise/update MLN(MRN) to align with current (and desired) usage.
>
> Lou
>
> On 1/22/2013 11:38 AM, John E Drake wrote:
> > 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.
> >>> IB>> 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).
> >>
> >
> >
> >
> >
> >
>