RE: vpls scaling question

On Mon, 12 May 2003, Joris wils wrote:

> Steve,
>
> Questions for you:
> a) Why does each household need its own VLAN?  Why can a set of household
> not share a vlan, each household with its own, possibly statically assigned,
> MAC addresses?
>

Wonder the same thing.

IMHO, each household can rely on L3 routing for connectivity. L2VPN is a
critical element at IP backbone and transport networks only.

> b) If each household must have its own VLAN, then are such VLANs usually
> point2point Ethernet circuits to an Internet router?  It is far easier to
> handle very large numbers of point2point circuits, than very large numbers
> of multipoint VLANs.
>

Follow up question, do we need point-to-multiple VLAN in the backbone?

- Ping

> Cheers,
> Joris
>
> -----Original Message-----
> From: Wright, Steven [mailto:[email protected]]
> Sent: Monday, May 12, 2003 1:21 PM
> To: 'Loa Andersson'
> Cc: '[email protected]'
> Subject: RE: vpls scaling question
>
>
> Loa,
>
> 1) I'm not trying to create requirements here, just to understand what the
> group consensus is. i.e. is this  vpls thing intended to emulate current
> switch capabilities/constraints or do something more ?
>
> 2) Perhaps my terminology was confusing. I was referring to the case of a
> service provider with 10,000,000  customers, each with their own service
> instance. This indeed would be a blessing ! (assuming they all pay their
> bills). Each customer may only want a relatively few VLANs...
>
> 3) Is this a realistic target application ?? well that's always debatable!
> But consider the case of 1 AS per LATA -  and what's the max number of
> households / LATA ? Well there are metro's with 1-10,000,000 households...
>
> 4) Specific deployments depend on a lot more than design constraints (e.g.
> $).....
>   so ...see 1) above...
>
> regards
> Steven Wright
>
> > -----Original Message-----
> > From: Loa Andersson [mailto:[email protected]]
> > Sent: Sunday, May 11, 2003 6:17 AM
> > To: [email protected]
> > Cc: [email protected]
> > Subject: Re: vpls scaling question
> >
> >
> > Steve,
> >
> > just to make sure we are on the same field. For me a vpls is
> > a service I
> > as an oprator offer a customer, could you please give me a scenario
> > where that customer would need 10,000,000 VLANs.
> > If you are talikng about number of vpls's in the operator network,
> > 10,000,000 "service instances" is not a problem, in fact it would be a
> > blessing :)
> >
> > /Loa
> >
> > Steven.Wright wrote:
> > > to clarify the INTRA- AS vpls case
> > > I would like to better understand the expected capabilities
> > of  INTRA-AS
> > > vpls vs a network of Ethernet switches.
> > >
> > > What is the scaling objective for vpls ?
> > > Current generation Ethernet switches have evolved from the 4096
> > > VLAN/network to 4096 VLAN/port. Scale limits on  SP
> > Ethernet networks
> > > are typically driven by other factors e.g. MAC address table size,
> > > issues with multicast etc.
> > >
> > > Is vpls intended to tackle any of those scale constraints ?
> > or to put it
> > > another way...
> > > Current Ethernet switch networks can support on the order
> > of 10,000 VLAN
> > > service instances.  Will vpls enable scaling to the
> > 10,000,000 or so
> > > service instances/AS necessary to enable Ethernet as a
> > residential service ?
> > >
> > >
> > >
> > >
> > >
> > >     -----Original Message-----
> > >     *From:* Steven.Wright [mailto:[email protected]]
> > >     *Sent:* Wednesday, April 23, 2003 5:04 PM
> > >     *To:* *Subject:* vpls scaling question
> > >
> > >     vpls is proposed as a mechanism to enable large-scale
> > Ethernet networks.
> > >     Can anyone quantify for me at what stage flat Ethernet networks
> > >     break and vpls is required ?
> > >     i.e what should the decision criteria be to convert an Ethernet
> > >     network to a vpls network ?
> > >     Steven Wright
> > >     BellSouth
> > >
> >
> >
> > --
> > /Loa
> >
> > mobile + 46 739 81 21 64
> > email: [email protected]
> >
>
>
> *****
> "The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged material.  Any review, retransmission, dissemination or other use
> of, or taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited.  If you received
> this in error, please contact the sender and delete the material from all
> computers."
>
>
>