ietf
[Top] [All Lists]

RE: Overlays and encapsulations (was Re: Engineering discussions )

2014-03-09 18:42:14
Alia,

                Hmmm.  10 years ago is not (relatively) new?  :)

                I believe that - if we bring in some other examples - converged
networking is still an ongoing process.

                And PWE3 has been affected (in minor ways) by this process.

                See additional responses below...

From: Alia Atlas [mailto:akatlas(_at_)gmail(_dot_)com]
Sent: Sunday, March 09, 2014 6:14 PM
To: Eric Gray
Cc: 'IETF' (ietf(_at_)ietf(_dot_)org)
Subject: Re: Overlays and encapsulations (was Re: Engineering discussions )
Importance: High

Eric,

On Sun, Mar 9, 2014 at 6:02 PM, Eric Gray 
<eric(_dot_)gray(_at_)ericsson(_dot_)com<mailto:eric(_dot_)gray(_at_)ericsson(_dot_)com>>
 wrote:
Alia,

                I assume that this is a change of subject in part to 
demonstrate that we
can in fact have a technical discussion on this list.  :)
                But the question is a reasonable example whether that is the 
case or not.
It's something that struck me as being interesting to discuss and having 
general appeal and
benefiting from the perspective of many areas.  :-)

                IMO, two of the biggest drivers for this work in the IETF are 
location and
identity separation, and converged networking.
                 Just as examples, the work being looked into in NVo3 is one 
example of
one aspect of the first case (where end-user or server application locations are
being separated from specific network entry points or physical servers 
accessible
using IP addresses, for example) and both PWE3 and L2VPN are two currently
active examples of the second case (where - for instance - Ethernet traffic is 
to
be carried over an IP network).
Yes, I agree that identity separation is a driver.   I'm not as persuaded that 
converged
networking is driving new overlays and encapsulations - just b/c pseudo-wires 
have been
around for about 10 years.

Network convergence is an ongoing process, even now.  Admittedly, the changes
driven by this are mostly small - though arguably that is an artifact of the 
fact
that changes required to deployed equipment MUST be "mostly small" and this
means that we may choose a solution that involves small changes over one that
might have been a better long-term choice.

                I think the problems these examples are solving are 
self-evident.  That
may not be true for other cases.
I'm, of course, more interested in whether there are common drivers and whether 
all the
solutions need to be point solutions or are more generalizable.

The answer to this only seems obvious.

Ideal solutions are completely generalizable for all applications, both those 
that
exist now, and those that may come.

Then along came reality.

Point solutions have the advantages of being simpler to implement (taken one at
a time, of course) - i.e. - lower-cost, simpler testing associated with 
incremental
changes and earlier delivery.

From a strictly business perspective, point-solutions are also easier to 
justify as
each such solution can be easily tied to a specific customer need (hence revenue
opportunity) and early delivery means a faster ROI - but here I stray from 
purely
technical discussion.

In addition, each point solution deployed becomes part of the "field" against
which future changes MUST be compared for compatibility reasons - because
(for additional non-technical reasons) we cannot simply wish them away.

Hence generalization - while a goal - is not something we can easily apply to
a problem space (that has been partially solved in deployments) after the fact.

This is the reason why we currently have so many RFCs.  Many (possibly most?)
of them could be considered point solutions.  We could probably come up with
a single generalized RFC to replace them all.  Chances are good it would be lots
simpler - especially if it included function sub-setting, appropriate capability
negotiation, etc. AND assumed compatibility with existing solutions was not a
requirement.

It WOULD be interesting to see how the RFC Editor would deal with the list of
obsoleted RFCs.  Possibly by saying "see Appendix X."

We would then have a generalized solution to all networking problems and no
hope that anyone would use it in our collective lifetimes.

So it is likely that the best approach is to work toward a "point-solution" that
is generalized for the uses about which we are aware and compatible with the
cumulative "point-solutions" we know about.  I think we all agree that for this
to be useful, it MUST also be timely - which means we have to decide at some
point that we "have enough information" and get started.

And then we can look forward to a series of point solutions to address what
was out there, but we were not aware of.  This can be particularly difficult
when nobody is very willing to talk about what is "out there."

Point solutions - depressing as it may seem - are what us less-than-perfect
people have to look forward to.

--
Eric

--
Eric

From: ietf 
[mailto:ietf-bounces(_at_)ietf(_dot_)org<mailto:ietf-bounces(_at_)ietf(_dot_)org>]
 On Behalf Of Alia Atlas
Sent: Sunday, March 09, 2014 5:34 PM
To: heasley
Cc: Dave Crocker; IETF Disgust
Subject: Overlays and encapsulations (was Re: Engineering discussions )

In the last few years, there seems to be a drive towards overlays and additional
packet encapsulations.  What problems do you see these as solving?  Is there a
more focused way to consider the drivers and downsides?

Thoughts?

Alia

On Sun, Mar 9, 2014 at 5:29 PM, heasley 
<heas(_at_)shrubbery(_dot_)net<mailto:heas(_at_)shrubbery(_dot_)net>> wrote:
Sun, Mar 09, 2014 at 11:10:27AM +0000, Dave Crocker:
The phrasing of your suggestion presumes that you are currently
prevented from having those discussions.  But of course you aren't.

I believe the point is to separate general technical discussion from the
general everything else discussion, such as the draft-how-not-to-be-a-
wanker discussion, so that those here just for the technical aspects of
IETF need not wade through it.  Which I support.