Subject: Re: [nvo3] Virtual Network - what's an instance?

From: Lucy yong <[email-masked]>
Date: Mon, 1 Jul 2013 19:44:51 +0000

Sorry, missing a critical word in my previous e-mail. This is what I mean to say:

IMO: if VSI, VFI, VRI, EVI terms have been used for long time to model
the entities on PE and if we are doing the similar thing in the nvo3
framework, it should be fine to use  VNI in the model. It should not be
requested to change because the problem statement uses the description
of the virtual network instance. We can still use the word "instance"
in the problem statement draft. To avoid the confusion, just state "an
instance of virtual network" as Larry suggests. We can easily address
the confusion.

Lucy

> -----Original Message-----
> From: Lucy yong
> Sent: Monday, July 01, 2013 2:41 PM
> To: 'Thomas Narten'
> Cc: [email-masked]
> Subject: RE: [nvo3] Virtual Network - what's an instance?
> 
> Hi Tom,
> 
> IMO: if VSI, VFI, VRI, EVI terms have been used for long time to model
> the entities on PE and if we are doing the similar thing in the nvo3
> framework, it should be fine to use  VNI in the model. It should be
> requested to change because the problem statement uses the description
> of the virtual network instance. We can still use the word "instance"
> in the problem statement draft. To avoid the confusion, just state "an
> instance of virtual network" as Larry suggests. We can easily address
> this conflict.
> 
> Regards,
> Lucy
> 
> > -----Original Message-----
> > From: Thomas Narten [mailto:[email-masked]]
> > Sent: Monday, July 01, 2013 1:35 PM
> > To: Lucy yong
> > Cc: [email-masked]
> > Subject: Re: [nvo3] Virtual Network - what's an instance?
> >
> > Lucy,
> >
> > > So this is because that the problem statement already uses it for
> > > different meaning.
> >
> > Yes, but it is also because we are talking about two different things,
> > and using the same terminology for different things tends to be
> > confusing.  IMO, there are times when referring to each of those
> > different things is important, so being able to distinguish them is
> > necessary.
> >
> > While I could change the problem statement to not use instance this
> > way, I hesitate at doing so. IMO, "instance" is an intuitive and
> > natural way to refer to a specific virtual network. And the term
> > "instance" is well known/used to refer to specific instantiations of
> a
> > an abstract term. This is just normal english.
> >
> > > Should the framework draft support the consistency to L2VPN/L3VPN
> or
> > > the nvo3 problem statement?  L2/L3VPN documents were generated much
> > > early without the description issues.
> >
> > I looked at the L3VPN framework (RFC4176). it does use similar
> > terminology:
> >
> > >    VPN Instance:
> > >
> > >       From a management standpoint, a VPN instance is the
> collection
> > of
> > >       configuration information associated with a specific VPN,
> > residing
> > >       on a PE router.
> >
> > Oddly enough, however, it defines the term and then doesn't actually
> > use it anywhere else in the document! The term "Instance" is used
> > exactly one time in the document, i.e., in the defintion. :-( Thus, I
> > hardly see this as a compelling precedent.
> >
> > Looking at the L2VPN framework (RFC 4664), it seems to use "instance"
> > more like the problem statement does. E.g, I find wording like:
> >
> > >    A "VPLS instance" consists of a set of VPLS Forwarders (no more
> > than
> > >    one per PE) connected by pseudowires.
> >
> > or
> >
> > >    Two CEs are connected to the same virtual backbone if and only
> if
> > >    they are members of the same VPLS instance (i.e., same VPN).
> >
> > or
> >
> > >    As Figure 3 indicates,
> > >    if a set of PEs support a common VPLS instance, then there is an
> > >    Emulated LAN, corresponding to that VPLS instance, to which each
> > of
> > >    those PE bridges attaches (via an emulated interface).
> >
> > I do not see "instance" used to refer only to the state on (say) a
> > local PE.
> >
> > Thomas