Subject: RE: Single vs many solution(s)

From: [email-masked]
Date: Tue, 6 May 2003 00:40:51 +0100

Alex,

How is the word 'solution' to be interpreted in the sentence below?

"I believe the goal for the WG should be to work out a single solution."

Does 'solution' = 'protocol'... i.e. LDP vs. BGP? If so then I do not think
working towards a single solution based on which protocol is better for X or
Y is the best way forward. I think the seemingly never-ending debate on this
subject proves this point.

If however the word solution was replaced with 'set of detailed functional
specifications' then maybe we can move away from the LDP vs. BGP debate and
concentrate on developing a set of functional specifications created from
the ground up. This is in contrast to some of the existing 'solutions' which
seem to me to have been developed the wrong way round, i.e. we already use
protocol X for service Z, what changes do we need to make to protocol X in
order for it to be used for this new service Y.

If the functional specifications are well defined it should be clear which
protocols are most suited and there may be more than one. For example, one
protocol may be more suited for a specific function intra-AS and another
inter-AS. To use a simple analogy, OSPF is more suited for intra-AS routing
and BGP is more suited for inter-AS routing, but they both perform the
function 'routing'.

Some of the foundations for the functional specifications probably already
exist within the various requirement and solution drafts and just need
extracting. 

The main advantages of separate functional specifications being (1) that
they can be developed independently without having any impact on each other
(2) operators would be able to choose which protocol they wish to use to
perform a certain function based on their own specific requirements.

Richard

-----Original Message-----
From: Alex Zinin [mailto:[email-masked]]
Sent: 05 May 2003 22:27
To: [email-masked]
Cc: Yakov Rekhter
Subject: Single vs many solution(s)

Yakov,

[I took the liberty to change the subject line]

>> I believe the goal for the WG should be to work out
>> a single solution.

> That is certainly not in the charter. In fact the goal
> you stated above directly contradicts what is in the charter:

>    Multiple approaches are being developed as each approach 
>    has particular characteristics and differing scope of applicability.

Thanks for pointing out a possible contradiction. I don't think
it exists.

My opinion (and I think it would be safe for me to say it is
consistent with that of the IESG) is that as long as different
solutions are solving different problems (or, as the text of the
charter says, have different scopes of applicability), it is fine to
have more than one solution. However, for a single problem, we only
need a single STD'ized solution.

> And if you believe that for VPLS the goal should be a single
> solution, then why wouldn't you insist to have the same goal 
> for L3 VPNs ?

you forgot to add "and if you wouldn't insist on a single solution for
L3 VPNs, then why do you insist on this for L2 VPNs" ;-)

The reason is I don't want to restart the L3 VPN work in the IETF
and/or revisit the decisions that have been made in the past, while I
still see a reasonable opportunity to steer the L2 VPN work.

> Also, if you insist on a single solution, wouldn't that
> imply a single auto-discovery mechanism for VPLS ?

This would definitely be my preference.

Alex

---

From: Alex Zinin <[email-masked]>
Date: Mon, 5 May 2003 23:11:40 -0700

Richard,

 Thanks for your input, it is indeed very important for us to be on
 the same page here, and I happen to agree with most of what you said.

 I don't think that "solution" == "protocol", but rather a set of
 functional components, each addressing its particular problem. The
 framework would then put them all together.

 I also view as reasonable an approach where there is a difference
 between how intra-domain and inter-domain issues are solved.

 So, from this perspective, the framework MAY very easily look
 like this (mechanism == protocol or protocol extension):

  Data-plane              : mechanism A
  Intra-domain discovery  : mechanism B
  Intra-domain signaling  : mechanism C
  Inter-domain discovery  : mechanism D
  Inter-domain signaling  : mechanism C++

 Of course there must be some architectural glue that brings all
 the pieces together.
  
 What I would like us to avoid is solution space exploration, where
 we have many mechanisms for the same function we need, i.e, I would
 be disappointed to see us end up with a framework looking like:

  Data-plane              : mechanism A, or B, or C
  Intra-domain discovery  : mechanism D, or E, or F
  Intra-domain signaling  : mechanism G, or H, or I
  Inter-domain discovery  : mechanism J, or K, or L
  Inter-domain signaling  : mechanism M, or N, or O

 This would, in view, impact interoperability.

 We also seem to agree on the point I brought in my message
 to Mark:

> Regarding the considerations you mention above, in my
> opinion it would be wrong for us to start the discussion
> by saying "SPs have X and Y deployed in their networks,
> so we just have to decide whether we piggy-back on X or
> on Y." Instead I'd like to see a discussion ala "What are
> the functions we need? How can we best implement them?
> Do we have an existing protocol that would be the right
> fit for this functionality or do we need a new one(s)?"

 Yakov, regarding your question again--
 
> imply a single auto-discovery mechanism for VPLS ?

 --to refine my answer, I would say, my preference would be for the WG
 to come up with a single solution consisting with at most two
 discovery mechanisms--one for intra-domain and one for inter-domain
 problem space. It is ok if the intra-domain only part comes first.

-- 
Alex
http://www.psg.com/~zinin/

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 12 May 2003 08:36:43 -0700

Alex,

>  This would, in view, impact interoperability.

To avoid disappointing you the WG immediately needs to start the
discussion on whether to use L2TPv3 encapsulation or MPLS or MPLS
over GRE, or MPLS over IPSec.

Likewise the WG immediately needs to start the discussion on L2TPv3
vs LDP based signaling.

Likewise, the WG immediately needs to start the discussion on BGP
vs Radius based auto-discovery.

Yakov.

---

From: Alex Zinin <[email-masked]>
Date: Tue, 13 May 2003 10:37:52 -0700

Summarizing a bit:

> vs Radius based auto-discovery.

If the goal of the WG is to produce the IETF Standards for L2 VPNs, I
think the WG should indeed be discussing which mechanisms should be
chosen as mandatory to implement. Not requiring a mandatory one will
affect interoperability, and more than one mandatory mechanism per
function are just not needed--one is enough. If folks believe other
(optional to implement) mechanisms would really add value, I don't
think anyone would object. The key point here is if we want
implementations of the IETF standard to interoperate, we need to
define the minimal function set to be supported.

Monday, May 12, 2003, 10:08:22 AM, Yakov Rekhter wrote:
> Agreed. In fact, I don't quite understand why some folks on this
> list insist that the IETF should be in the business of making
> business decisions...

I don't think anyone is trying to insist on that, quite on the
contrary. I think there's a general agreement that the IETF should NOT
be making business decisions, and the disagreement is in which
decisions are business and which are technical.

If we come here believing that the IETF is nothing but a market
battlefield, then we can call any situation where more than one
existing implementation is available a "business issue", and agree
that trying to resolve it would cost too much blood, so "the market"
should pick the one that they like more.

If instead we believe that the IETF is an engineering organization,
where we come to work together on something we can later use to
interoperate in SP networks (even though we may have our own existing
implementations), I think we should be ready to sit down, talk to each
other and try to build consensus on what should that IETF Standard be.

Which mindset do we choose?

Alex

---

From: Alex Zinin <[email-masked]>
Date: Tue, 13 May 2003 10:37:52 -0700

Summarizing a bit:

Alex

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 20 May 2003 08:48:47 -0700

Alex,

> Which mindset do we choose?

The one that reflects reality, and not the one that reflects wishful
thinking. With this in mind the following from Ross' e-mail answers
your question.

   The reality is that neither the IETF nor any other 
   standards body is good at choosing between major approaches. When 
   we have tried to do this (or when any other standards group has tried
   this) we have failed more often than succeeded. Where we have let more
   than one major approach be progressed, we have succeeded most of the
   time (although usually most of the approaches eventually go away). 
   
   Standards groups such as the IETF are very good at taking any one well 
   defined solution and working out all of the details. If there are two main
   approaches, then we are very good at having two groups of people 
   progress the two approaches. This allows vendors to build interoperable 
   solutions. This is essential for data communications networks to 
   progress and to work well. Where there have been more than one
   approach progressed, the competition between approaches have made
   the proponents of each approach improve their approach as much as
   possible and has given us better standards. 
   
   If we look at some examples from history, there is a very clear trend 
   that progressing two or slightly more approaches works out okay. Bad 
   approaches go away because they don't work well when deployed (for 
   example, scaling might be difficult, or stability might be lacking). 
   Trying to pick one winner in a heavily politicized large group just
   doesn't work. Committees aren't very good at figuring out where there 
   are going to be problems. 

Yakov.

---

From: "Mark Seery" <[email-masked]>
Date: Tue, 20 May 2003 22:36:26 -0700

Yakov,

[SNIPPED]

your question. <<

As I have stated before I am generally sympathetic to the idea that there
are very different service providers with very different requirements; and
therefore perhaps multiple standards are called for. But, some comments.

I did think Ross's email was excellent, but some further color to his
comments might be beneficial.

In the case of developing RIP, OSPF, BGP4, etc. we kind of lucked out (or
perhaps it was good intentions) in the sense that all three could be used
easily in the same network - and together - because it was relatively simple
to export/import routes (where applicable and advisable) because they all
used the same addressing structure, so a route was a route was route which
could be imported into the kernel (or its equivalent). So things worked out
nicely. But what if they had all used different addressing structures, or
where othewise incompatible?

In the case of the Ethernet example, things actually did not work out so
well. First it has to be noted that even the IEEE recognized the need for
some level of interoperability, so IEEE 802.2 was defined for all
(Standardized by the IEEE) Ethernet MACs. But even this did not produce good
results. Bridging between Ethernet, TR, and FDDI was **very** painful. There
are many reasons, some related to some interesting layer 3 encapsulations,
in the case of IPX, the old canonical/non-canonical issue, function points,
blah, blah, blah.....etc. Now we can argue that eventually it all worked out
well because the industry trended in one direction, but for the peroid where
vendors had to support all three, it was extremely painful; on both an
interoperability and chip level (in the case of TR); and all three had to be
supported because their vendors could claim the legitimcay of being
standards.

So at a minimum, it would be nice to see obvious (meaning it may be occuring
but not visible) evidence of cooperation between competing proposals to
identify areas of commonality, and seek interoperability. More generally,
such a process may lead to other levels of cooperation.

To date we have asked the binary question of single or many. Is there also
some intermediate states?

Best,
Mark

---

From: Alex Zinin <[email-masked]>
Date: Fri, 23 May 2003 16:22:25 -0700

Yakov,

> thinking.

My approach (which you may call "wishful thinking") is the second one
above--to treat IETF as an engineering organization and expect people
(vendors, users, researchers) to talk and work together on IETF
standards. I don't know what your "reality"-based one is.

> With this in mind the following from Ross' e-mail answers
> your question.

Not really.

A key notion in Ross'es explanation is a "major approach". If we apply
the "major approach" argument to every situation where more than one
direction is possible, we will end up with exploration of the solution
space.

Therefore, it is important to distinguish between a "major approach"
and a "mechanism performing a specific function within a major
approach". Within the VPN context, it seems reasonable to say that L3
VPNs and L2 VPNs are fundamentally different major approaches. Within
L2 VPNs, it also seems reasonable to say that VPLS and VPWS are two
different major approaches as they are used to provide different
services. On the other hand, can we call LDP-based and BGP-based VPLS
signalling "major approaches", or are they rather two possible
variants for a quite narrow-scoped signalling function?

Alex

---

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]