Subject: RE: Single vs many solution(s)

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Wed, 7 May 2003 10:53:55 -0400

Alex,

[clipped]...

> 
>  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++
> 

Your proposal doesn't preclude the case where
a given protocol is used to implement 
mechanisms B, C and D if we assume that 
mechanism == protocol extension.

>  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.
>

That sounds logic, but is it really that simple? 
Consider this example, a protocol "x" made a choice "a"
of a particular extension for solving a given l2vpn problem, 
and later on it happens that "a" doesn't cover
exactly the set of scenarios the wg needs to look at,
and another choice "b" is proposed for the same problem
and piggybacked on the same protocol "x" ("b" makes
the 'architectural glue' mentioned above more likely to happen).

In your opinion what should the wg do? Pick only one 
option (a or b), or incorporate the two options
on the same protocol "x"?

I hope your answer will not include something
like 'it depends...' :-).

>  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)?"
> 

I am afraid what you are proposing (which sounds logic as well)
will cause the ppvpn wg to progress very slowly if we assume that
this "discussion" includes multiple proposals on existing
protocols and multiple proposals on new protocols, particularly
if it is not straightforward to answer the question 
"how can we best implement them?". 

Besides, I think you missed an important piece which is to
make sure that these functions (including
the 'architectural glue' mentioned above) needs to
meet a set of requirements.

Hamid.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 9 May 2003 10:04:49 -0700

Hamid,

> mechanism == protocol extension.

Well, this is not really a proposal, just an example of how the
framework MAY look, so don't read too much into what it precludes
or does not preclude.

> That sounds logic, but is it really that simple? Consider this
> example, a protocol "x" made a choice "a" of a particular extension
> for solving a given l2vpn problem, and later on it happens that "a"
> doesn't cover exactly the set of scenarios the wg needs to look at,
> and another choice "b" is proposed for the same problem and
> piggybacked on the same protocol "x" ("b" makes the 'architectural
> glue' mentioned above more likely to happen).

> In your opinion what should the wg do? Pick only one option (a or
> b), or incorporate the two options on the same protocol "x"?

> I hope your answer will not include something like 'it depends...'
> :-).

I am afraid it will be :) It's just too abstract to give any
reasonable answer.

To clarify my point above again, I'll give you an example--I think
that we don't need more than one Standard discovery mechanism for the
intra-domain scenario. That's the only meaning behind comparing
things like "B" vs "D || E || F".

Alex