Re: Single vs many solution(s)

Hamid,

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

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.

>>   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...'
> :-).

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