Subject: Re: Single vs many solution(s)

From: Loa Andersson <[email-masked]>
Date: Tue, 27 May 2003 14:37:56 +0200

All,

since became co-chair of the ppvpn more or less over one single night,
I still have some reading to do to get up to speed on the ppvpn side.

However, I do have some opinions on e.g. "single vs. many" and where
we should try to go.

Some of them are "programatic", the type of position a wg chair will
always need to take - until provoen wrong. Others are specific and
realting to the discussion on the number of solutions for l2vpns in
ietf.

Programatic:

1. as a working group or as a standards organization it is our
    goal/task/duty to come up with one single standard per problem.

2. we need to recognize that there are several problems, and sometimes
    they look very similar, and that they may require very different
    solutions

3. not being able to agree on a single solution is not a failure, the
    standards organization don't make market decisions, at best it can
    be supportive. If we don't agree the market will decide.

Specific:

1. so far I've seen multiple solutions aiming to solve the same
    problen, e.g. the vkompella vs. kkompella discussion

2. the thread so far has been interesting, e.g. Ross' dsicussion on
    situations where "we" have taken decisions to forward more than one
    solutions. Though I don't think Ross would like to go as far as to
    say that we should aim for multiple solutions and let the market
    decide

3. if it is true that we are trying to solve one single problem - and
    given that this problem needs to be more precisely stated - then I
    will as wg chair work for one singel standard coming out of the wg

4. if on the other hand it is possible to show that there are two
    separate problem that requires separate solutions I will try to
    promote solutions that addresses the problems

5. the discussion on this thread so far is a bit of disappointment,
    since it very much goes along the lines "my solution is better than
    yours", rather than "I think the solution should be differnet from
    what you propose, because ..." or "yes you have a solution that will
    work in the situation you describe, but there are further problems
    that needs to be address by differnt solutions"

So until someone proven that that e.g. the kkompella and vkompella
addresses different problems I will try to make the wg adopt only one.
But I won't cry if we can't, we just send both of them "experimental"
and revisit the question in a couple of years and promote one of them
to PS (market decide).

If we can clearly desccribe the two problems we are trying to solve, and
it can be show that two solutions solves those two pa*roblems, then I'm
fully prepared send multiple solutions to IESG and request they are
made PS.

Any volunteer to try describe the problem space(s)?

I guess they same goes for the different discovery approaches.

/Loa

BTW - I suggest tht we start dropping copies to the ppvpn-list for
anything that is not vpn generic.

-- 
/Loa

mobile + 46 739 81 21 64
email: [email-masked]

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 27 May 2003 07:34:20 -0700

Folks,

I think that the following message is quite relevant to the discussion.

Yakov.
-----------------------------------------------------------------
Date:    Fri, 23 May 2003 10:04:39 EDT
To:      [email-masked]
From:    Frank Kastenholz <[email-masked]>
Subject: The One True Path To Nirvana

Folks,
I hate to inject a bit of reality into this but
whether the IETF decides to bless one-and-only-one
way to do FOO with the high-honor of "Standards Track
RFC" or allows multiple ways is only marginally
important.

Vendors, being interested in making money, try to
differentiate their products. The Offical IETF
Mantra in this regard is that vendor differentiation
arises out of things like quality. While true, it is not
the complete truth. Vendors will also have with their
own protocols as alternative ways to do FOO. The vendor's
marketing people will then tout their proprietary FOO
Protocol as "better" than the standard in various ways.
The proprietary FOO Protocol might even be what the 
vendor tried to get made a standard but failed (and
now there might be an installed base...)

Second, customers (bless their checkbooks and capex budgets)
sometimes what something that's not the standard. It could
have been something that was a candidate for standardizing
but didn't make it. It could be something that the customer
came up with. It could be some set of requirements that
the customer has (or thinks they have) that are not met
with the standard, requiring some non-standard-FOO.

Having multiple levels of standard really doesn't have
any effect on what vendors do or what customers want.
If the deltas from one level to the next are "just
bugfixes" then that's how they are treated by vendors.
If there are substantive changes in function (function-x
is available in proposed std, but not in draft, or vice
versa) then the implementation becomes the union of all
standard-levels, with config switches and the like. In other
words, the propose/draft/full hierarchy is little more than
feel-good self-gratification on the part of The Process Experts.

Btw, before I get roasted for heresy
a) There are always exceptions where things happen
   differently. When the right things happen, it's
   like winning the lottery. Enjoy it, but don't count
   on it
b) This is not a state of affairs that I find particularly
   desireable.  It is a state of affairs that does exist,
   however, and pretending that it does not exist is foolish.

So, the short answer is that multiple-competing-FOOs is
a fact of life. We live with it. We deal with it. Whatever
the IETF does, it will not go away. 

That said, what the IETF _can_ do is to make the problem
easier to deal with by
- getting the technical quality of things as high as we
  can as early as we can. That means -00 of the draft,
  if possible (yes, I know it won't happen, but the sooner,
  the better)
- getting drafts and changes and RFCs through the system
  faster (without sacrificing quality).
Ideally, -00 of the ID comes out 1 week after the first BOF
and there are no changes made to it, ever.

Frank Kastenholz

This is all my personal opinion and does not have anything to do
with what my employer says, thinks, does, etc.

---

From: [email-masked]
Date: Tue, 27 May 2003 16:15:01 +0100

Yakov

I think the phrase "Vendors, being interested in making money" from the
message below sums it up nicely;-)

Perhaps standardisation and interoperability may only be "marginally
important" to some large vendors that have the luxury of a large installed
customer base, or to some providers where a non-standard feature is the only
fix to a unique requirement.

However, I would suggest that for large operators looking at the
*possibility* of using MPLS as their next co pkt-sw core, standardisation
and interoperability would be extremely important. The L2 MPLS VPN solutions
are not just quick 'value add features' (which I think some people seem to
perceive them to be, due to the fact that they can be deployed using
existing networks and protocols with minimal changes).

L2 MPLS VPNs offer operators the *potential* to migrate existing co pkt-sw
services (i.e. ATM, Frame Relay) onto a single platform that one might
expect to be around for another 20 years or so to justify its investment. I
would suggest that proper standardisation (especially at the architectural
level) is a prerequisite for protecting this investment.

Richard

 > -----Original Message-----
 > From: Yakov Rekhter [mailto:[email-masked]]
 > Sent: 27 May 2003 15:34
 > To: [email-masked]; [email-masked]
 > Subject: Re: Single vs many solution(s) 
 > 
 > 
 > Folks,
 >

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Tue, 27 May 2003 11:22:34 -0400

Loa,

>     problen, e.g. the vkompella vs. kkompella discussion
<snip>...

> addresses different problems I will try to make the wg adopt only one.

<snip>....

> Any volunteer to try describe the problem space(s)?

I think since vkompella vs kkompella discussions (or more precisely
kkompella discussions) we have been moving from
one issue/topic to another not related to the drafts themselves and
if I summarize the item we can list:

a) Are there strong *technical* issues with kkompella proposal?

  There was a debate, the draft is now WG document so I assume
  the chairs and ADs concluded that there are no major technical issues 
  stopping the WG to work on the proposal. So let's move on from
  that item.
  
b) Should the WG work on more than one distinct solution
   for the same problem (problem == l2vpn service)?

   Given a) and adopting other drafts the answer is yes. 
   In fact we also indirectly debated that since IPLS and VPLS provide 
   the same "service", then a potential question is 

   "Should the wg consider IPLS and VPLS
   as solving the same problem or different problems?" 

   If it is the same problem should the wg focus only on VPLS (as a 
   superset service)? or should the WG treat l2vpn services
   for IP host/routers-based CEs as different l2vpn services?
  
c) Should the solutions all progress as PS or experimental?
   
   It looks to me it is premature to debate that item at this
   point in time.

d) Do we need multiple mechanisms for the same problem?
   (e.g., Radius and BGP discovery)?

   In my view this question should be contrasted to the approach taken 
   in solving the l2vpn problem and the requirements
   addressed in the solution. There are problems that
   are services and there are those that are mechanisms.

   Since we are working on a per-solution style, it is logical that 
   protocol choices made in one solution may not be acceptable to 
   others or will not meet the requirements for other solution. In that
   respect having multiple mechanisms (using multiple protocols)
   to be used in one or more solutions is a consequence
   of both the approach taken and the reality of ppvpn problem space
   -as being 'provider-centric technology/services' instead of
   being only 'protocol-centric' problem. Therefore I don't
   see the value of addressing this item (nothing wrong 
   discussing the technical aspects though).

e) Concerns on the use of BGP (routing protocol) for implementing
   VPN functions.

   Using BGP for implementing VPN functions is a valid approach 
   and so far since l3vpns we know about the applicability of 
   BGP-based mechanisms in the field more than any other mechanism. 

   It looks to me Yakov's request to put clearly on the table
   the IESG concerns (if any) for this item is a reasonable request. 
   That will allow the WG to debate the items that are really of 
   concerns or need to be addressed and highlighted..and that will just
   improve the quality of wg outputs. 

<snip> 

> anything that is not vpn generic.

If I am not mistaken, I think the debate on l2vpn mailing list is on 
the charter only.

Hamid.