Subject: RE: Single vs many solution(s)

From: "Vasile Radoaca" <[email-masked]>
Date: Tue, 6 May 2003 11:02:27 -0400

Alex,

 In addition of intra-domain/inter-domain issues, the VPLS problem space add
also specific issues:

1. A large variety of access type networks: LAN/VLAN, Q-in-Q, PWs, MinM
2. A variety of CPE devices: L2, L3 devices
3. A significant customer mac accumulation [oversubscription factor is a key
component of the VPLS Etehrnet service value], without any proper  model to
poof that would not impact the performance, security or stability of the
VPLS core mainly when it would work in paralel with other services like IP
VPN
4. Legacy inter-working
5. Different deployment scenarios - A VPLS solution maps on different
network topologies:
 a) it is possibile to start from the core and to extend to the access, by
employing simple access configurations - simple P2P or VLAN based.
 b) it is possible to start from the access and build VPLS without any MPLS
core. Later when the metro is growing an MPLS core can be employed to glu
such access networks.
 c) overlapping with current IP VPN networks
 
How we can deal with such issues, using your model below?

Cheers
  Vasile

-----Original Message-----
From: Alex Zinin [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2003 2:12 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Single vs many solution(s)

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--
 
> Also, if you insist on a single solution, wouldn't that
> 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/

Monday, May 5, 2003, 4:40:51 PM, [email-masked] wrote:
> 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: Tue, 6 May 2003 11:22:23 -0700

Vasile,

>  c) overlapping with current IP VPN networks

Nice list of considerations. I certainly hope we are not going to see
a separate solution for each possible combination.

> How we can deal with such issues, using your model below?

What problems do you see?

Alex