Re: : VPLS Experience

Re: : VPLS Experience

> Frankly I'm surprised that there is so limited experience being talked
> about - when MPLS first came out there was a lot of talk about it.
> 
> A lack of interest only suggests either a lack of experience or that
> it is all so easy it's mundane...

We have VPLS in production (Juniper BGP based). It works but it is no
silver bullet:

- The VPLS code is less heavily used than other code - thus you are
more likely to experience bugs in this area than other code.

- Number of sites is an issue, mostly because traffic is replicated
at the ingress router. You can usually limit the amount of broadcast
and multicast traffic - but it is not easy to limit the amount of 
traffic to unknown *unicast* addresses (which then must be replicated
to all sites).

- If you want to make large multipoint L2 networks you *really* need
to look at your network design and figure out if you're not better
served by MPLS (L3) VPN - where multipoint comes for "free".

Steinar Haug, Nethelp consulting, sthaug <at> nethelp.no

Re: : VPLS Experience

Using VPLS is a good idea.
But in real life, do you need VPLS ? For very specific
needs, I think.
Remember LAN Emulation ? Really good idea.
But to troubleshoot... 

--- sthaug <at> nethelp.no wrote:

> > Frankly I'm surprised that there is so limited
> experience being talked
> > about - when MPLS first came out there was a lot
> of talk about it.
> > 
> > A lack of interest only suggests either a lack of
> experience or that
> > it is all so easy it's mundane...
> 
> We have VPLS in production (Juniper BGP based). It
> works but it is no
> silver bullet:
> 
> - The VPLS code is less heavily used than other code
> - thus you are
> more likely to experience bugs in this area than
> other code.
> 
> - Number of sites is an issue, mostly because
> traffic is replicated
> at the ingress router. You can usually limit the
> amount of broadcast
> and multicast traffic - but it is not easy to limit
> the amount of 
> traffic to unknown *unicast* addresses (which then
> must be replicated
> to all sites).
> 
> - If you want to make large multipoint L2 networks
> you *really* need
> to look at your network design and figure out if
> you're not better
> served by MPLS (L3) VPN - where multipoint comes for
> "free".
> 
> Steinar Haug, Nethelp consulting, sthaug <at> nethelp.no
> 
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe: 
> http://www.mplsrc.com/mplsops.shtml
> Archive:
> http://www.mplsrc.com/mpls-ops_archive.shtml
> 

		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

Re: : VPLS Experience

I think VPLS can not be compared with the complexity LANE had. But
there is a concern common to both technologies: scalability. LANE was
never scalable enough for large deployments. While VPLS (BGP version
and H-VPLS) are able to deal with that issue rather good.
VPLS is a great for multipoint ethernet interconnection. It is as hard
to troubleshoot as any other MPLS based VPNs, like rfc2547bis for
instance, which are quite popular. It seem to me that the market is
going VPLS's direction.
-Pedro Fortuna

On 09/11/05, Koyote France <koyotibus <at> yahoo.com> wrote:
> Using VPLS is a good idea.
> But in real life, do you need VPLS ? For very specific
> needs, I think.
> Remember LAN Emulation ? Really good idea.
> But to troubleshoot...
>
>
> --- sthaug <at> nethelp.no wrote:
>
> > > Frankly I'm surprised that there is so limited
> > experience being talked
> > > about - when MPLS first came out there was a lot
> > of talk about it.
> > >
> > > A lack of interest only suggests either a lack of
> > experience or that
> > > it is all so easy it's mundane...
> >
> > We have VPLS in production (Juniper BGP based). It
> > works but it is no
> > silver bullet:
> >
> > - The VPLS code is less heavily used than other code
> > - thus you are
> > more likely to experience bugs in this area than
> > other code.
> >
> > - Number of sites is an issue, mostly because
> > traffic is replicated
> > at the ingress router. You can usually limit the
> > amount of broadcast
> > and multicast traffic - but it is not easy to limit
> > the amount of
> > traffic to unknown *unicast* addresses (which then
> > must be replicated
> > to all sites).
> >
> > - If you want to make large multipoint L2 networks
> > you *really* need
> > to look at your network design and figure out if
> > you're not better
> > served by MPLS (L3) VPN - where multipoint comes for
> > "free".
> >
> > Steinar Haug, Nethelp consulting, sthaug <at> nethelp.no
> >
> > -------
> > The MPLS-OPS Mailing List
> > Subscribe/Unsubscribe:
> > http://www.mplsrc.com/mplsops.shtml
> > Archive:
> > http://www.mplsrc.com/mpls-ops_archive.shtml
> >
>
>
>
>
> __________________________________
> Yahoo! FareChase: Search multiple travel sites in one click.
> http://farechase.yahoo.com
>
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
>

--
Cumprimentos,
Pedro Fortuna

Re: : VPLS Experience

Yes, indeed, scalability was a problem with LANE. And
for VPLS too. H-VPLS is here to permit a better
scalability.
VPLS can be useful for some environnements where
Multipoint Ethernet is required (Clustering for
example where same IP subnet MUST be used between more
than 2 sites), but I don't think VPLS will replace
MPLS-VPN.

VPLS can be complex to troubleshoot too. (BPDU, ARP,
Broadcast... and L3). Yes, H-VPLS is good to
"simplify" these. But not so simple.

--- Pedro Fortuna <pedro.fortuna <at> gmail.com> wrote:

> I think VPLS can not be compared with the complexity
> LANE had. But
> there is a concern common to both technologies:
> scalability. LANE was
> never scalable enough for large deployments. While
> VPLS (BGP version
> and H-VPLS) are able to deal with that issue rather
> good.
> VPLS is a great for multipoint ethernet
> interconnection. It is as hard
> to troubleshoot as any other MPLS based VPNs, like
> rfc2547bis for
> instance, which are quite popular. It seem to me
> that the market is
> going VPLS's direction.
> -Pedro Fortuna
> 
> On 09/11/05, Koyote France <koyotibus <at> yahoo.com>
> wrote:
> > Using VPLS is a good idea.
> > But in real life, do you need VPLS ? For very
> specific
> > needs, I think.
> > Remember LAN Emulation ? Really good idea.
> > But to troubleshoot...
> >
> >
> > --- sthaug <at> nethelp.no wrote:
> >
> > > > Frankly I'm surprised that there is so limited
> > > experience being talked
> > > > about - when MPLS first came out there was a
> lot
> > > of talk about it.
> > > >
> > > > A lack of interest only suggests either a lack
> of
> > > experience or that
> > > > it is all so easy it's mundane...
> > >
> > > We have VPLS in production (Juniper BGP based).
> It
> > > works but it is no
> > > silver bullet:
> > >
> > > - The VPLS code is less heavily used than other
> code
> > > - thus you are
> > > more likely to experience bugs in this area than
> > > other code.
> > >
> > > - Number of sites is an issue, mostly because
> > > traffic is replicated
> > > at the ingress router. You can usually limit the
> > > amount of broadcast
> > > and multicast traffic - but it is not easy to
> limit
> > > the amount of
> > > traffic to unknown *unicast* addresses (which
> then
> > > must be replicated
> > > to all sites).
> > >
> > > - If you want to make large multipoint L2
> networks
> > > you *really* need
> > > to look at your network design and figure out if
> > > you're not better
> > > served by MPLS (L3) VPN - where multipoint comes
> for
> > > "free".
> > >
> > > Steinar Haug, Nethelp consulting,
> sthaug <at> nethelp.no
> > >
> > > -------
> > > The MPLS-OPS Mailing List
> > > Subscribe/Unsubscribe:
> > > http://www.mplsrc.com/mplsops.shtml
> > > Archive:
> > > http://www.mplsrc.com/mpls-ops_archive.shtml
> > >
> >
> >
> >
> >
> > __________________________________
> > Yahoo! FareChase: Search multiple travel sites in
> one click.
> > http://farechase.yahoo.com
> >
> > -------
> > The MPLS-OPS Mailing List
> > Subscribe/Unsubscribe: 
> http://www.mplsrc.com/mplsops.shtml
> > Archive:
> http://www.mplsrc.com/mpls-ops_archive.shtml
> >
> 
> 
> --
> Cumprimentos,
> Pedro Fortuna
> 

		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

Re: : VPLS Experience

> I think VPLS can not be compared with the complexity LANE had. But
> there is a concern common to both technologies: scalability.

Absolutely.

> While VPLS (BGP version and H-VPLS) are able to deal with that issue
> rather good.

Partial agreement here. Juniper BGP based VPLS is easy to deploy, the
*configuration* part is reasonably scalable. For the actual traffic you
still have the issue that broadcast/multicast/unknown unicast traffic is
replicated at the ingress router - with potentially severe consequences
for your backbone if you have many sites or the customer connection to
the ingress router is high bandwidth.

> VPLS is a great for multipoint ethernet interconnection. It is as hard
> to troubleshoot as any other MPLS based VPNs, like rfc2547bis for
> instance, which are quite popular.

Possibly harder. With MPLS based VPNs you can troubleshoot using IP
addresses. With VPLS you only have MAC addresses.

> It seem to me that the market is going VPLS's direction.

I don't see the market moving towards VPLS in any great numbers - to me
VPLS is more of a niche market.

Steinar Haug, Nethelp consulting, sthaug <at> nethelp.no

Re: : VPLS Experience

On 09/11/05, sthaug <at> nethelp.no <sthaug <at> nethelp.no> wrote:
> > I think VPLS can not be compared with the complexity LANE had. But
> > there is a concern common to both technologies: scalability.
>
> Absolutely.
>
> > While VPLS (BGP version and H-VPLS) are able to deal with that issue
> > rather good.
>
> Partial agreement here. Juniper BGP based VPLS is easy to deploy, the
> *configuration* part is reasonably scalable. For the actual traffic you
> still have the issue that broadcast/multicast/unknown unicast traffic is
> replicated at the ingress router - with potentially severe consequences
> for your backbone if you have many sites or the customer connection to
> the ingress router is high bandwidth.

H-VPLS with Multicast support attenuates this problem. Not supported
by Juniper though.

> > VPLS is a great for multipoint ethernet interconnection. It is as hard
> > to troubleshoot as any other MPLS based VPNs, like rfc2547bis for
> > instance, which are quite popular.
>
> Possibly harder. With MPLS based VPNs you can troubleshoot using IP
> addresses. With VPLS you only have MAC addresses.
Yes, IP troubleshooting is much simpler. Nevertheless, MPLS
troubleshooting per se, still scares many people, and both MPLS
L3VPN's and L2VPN's suffer from this.
I agree that H-VPLS should be a pain to troubleshoot. The network
management people must try to provider tools to ease this job.
I'm also interested to see how the VLAN based switching will simply
MAC troubleshooting.

> > It seem to me that the market is going VPLS's direction.
>
> I don't see the market moving towards VPLS in any great numbers - to me
> VPLS is more of a niche market.

Maybe right now it is, but in my opinion, I think that eventually, as
providers converge their networks through an MPLS core, VPLS demand
will grow.
Its natural that traditional L2 carriers, such as in the Carrier
Ethernet market, will be more interested in VPLS than other types of
service providers, because they want to be able to continue offering
pure L2 services to their customers.

Best Regards,
Pedro Fortuna

Re: : VPLS Experience

On 09/11/05, Koyote France <koyotibus <at> yahoo.com> wrote:
> Yes, indeed, scalability was a problem with LANE. And
> for VPLS too. H-VPLS is here to permit a better
> scalability.
> VPLS can be useful for some environnements where
> Multipoint Ethernet is required (Clustering for
> example where same IP subnet MUST be used between more
> than 2 sites), but I don't think VPLS will replace
> MPLS-VPN.
>
> VPLS can be complex to troubleshoot too. (BPDU, ARP,
> Broadcast... and L3). Yes, H-VPLS is good to
> "simplify" these. But not so simple.
I agree. I would be very interested in hearing comments on this, from
someone with experience with H-VPLS troubleshooting.

>
>
> --- Pedro Fortuna <pedro.fortuna <at> gmail.com> wrote:
>
> > I think VPLS can not be compared with the complexity
> > LANE had. But
> > there is a concern common to both technologies:
> > scalability. LANE was
> > never scalable enough for large deployments. While
> > VPLS (BGP version
> > and H-VPLS) are able to deal with that issue rather
> > good.
> > VPLS is a great for multipoint ethernet
> > interconnection. It is as hard
> > to troubleshoot as any other MPLS based VPNs, like
> > rfc2547bis for
> > instance, which are quite popular. It seem to me
> > that the market is
> > going VPLS's direction.
> > -Pedro Fortuna
> >
> > On 09/11/05, Koyote France <koyotibus <at> yahoo.com>
> > wrote:
> > > Using VPLS is a good idea.
> > > But in real life, do you need VPLS ? For very
> > specific
> > > needs, I think.
> > > Remember LAN Emulation ? Really good idea.
> > > But to troubleshoot...
> > >
> > >
> > > --- sthaug <at> nethelp.no wrote:
> > >
> > > > > Frankly I'm surprised that there is so limited
> > > > experience being talked
> > > > > about - when MPLS first came out there was a
> > lot
> > > > of talk about it.
> > > > >
> > > > > A lack of interest only suggests either a lack
> > of
> > > > experience or that
> > > > > it is all so easy it's mundane...
> > > >
> > > > We have VPLS in production (Juniper BGP based).
> > It
> > > > works but it is no
> > > > silver bullet:
> > > >
> > > > - The VPLS code is less heavily used than other
> > code
> > > > - thus you are
> > > > more likely to experience bugs in this area than
> > > > other code.
> > > >
> > > > - Number of sites is an issue, mostly because
> > > > traffic is replicated
> > > > at the ingress router. You can usually limit the
> > > > amount of broadcast
> > > > and multicast traffic - but it is not easy to
> > limit
> > > > the amount of
> > > > traffic to unknown *unicast* addresses (which
> > then
> > > > must be replicated
> > > > to all sites).
> > > >
> > > > - If you want to make large multipoint L2
> > networks
> > > > you *really* need
> > > > to look at your network design and figure out if
> > > > you're not better
> > > > served by MPLS (L3) VPN - where multipoint comes
> > for
> > > > "free".
> > > >
> > > > Steinar Haug, Nethelp consulting,
> > sthaug <at> nethelp.no
> > > >
> > > > -------
> > > > The MPLS-OPS Mailing List
> > > > Subscribe/Unsubscribe:
> > > > http://www.mplsrc.com/mplsops.shtml
> > > > Archive:
> > > > http://www.mplsrc.com/mpls-ops_archive.shtml
> > > >
> > >
> > >
> > >
> > >
> > > __________________________________
> > > Yahoo! FareChase: Search multiple travel sites in
> > one click.
> > > http://farechase.yahoo.com
> > >
> > > -------
> > > The MPLS-OPS Mailing List
> > > Subscribe/Unsubscribe:
> > http://www.mplsrc.com/mplsops.shtml
> > > Archive:
> > http://www.mplsrc.com/mpls-ops_archive.shtml
> > >
> >
> >
> > --
> > Cumprimentos,
> > Pedro Fortuna
> >
>
>
>
>
> __________________________________
> Yahoo! FareChase: Search multiple travel sites in one click.
> http://farechase.yahoo.com
>

--
Cumprimentos,
Pedro Fortuna

Re: : VPLS Experience

> On 09/11/05, Koyote France <koyotibus <at> yahoo.com> wrote:
>> Yes, indeed, scalability was a problem with LANE. And
>> for VPLS too. H-VPLS is here to permit a better
>> scalability.
>> VPLS can be useful for some environnements where
>> Multipoint Ethernet is required (Clustering for
>> example where same IP subnet MUST be used between more
>> than 2 sites), but I don't think VPLS will replace
>> MPLS-VPN.
>>
>> VPLS can be complex to troubleshoot too. (BPDU, ARP,
>> Broadcast... and L3). Yes, H-VPLS is good to
>> "simplify" these. But not so simple.
> I agree. I would be very interested in hearing comments on this, from
> someone with experience with H-VPLS troubleshooting.

	I think what you will find is that although
H-VPLS makes deployment of equipment a bit more
scaleable, that it adds another layer to
trouble-shooting, making it even more difficult
than managing MPLS or ethernet.

	--Tom

>> --- Pedro Fortuna <pedro.fortuna <at> gmail.com> wrote:
>>
>>> I think VPLS can not be compared with the complexity
>>> LANE had. But
>>> there is a concern common to both technologies:
>>> scalability. LANE was
>>> never scalable enough for large deployments. While
>>> VPLS (BGP version
>>> and H-VPLS) are able to deal with that issue rather
>>> good.
>>> VPLS is a great for multipoint ethernet
>>> interconnection. It is as hard
>>> to troubleshoot as any other MPLS based VPNs, like
>>> rfc2547bis for
>>> instance, which are quite popular. It seem to me
>>> that the market is
>>> going VPLS's direction.
>>> -Pedro Fortuna
>>>
>>> On 09/11/05, Koyote France <koyotibus <at> yahoo.com>
>>> wrote:
>>>> Using VPLS is a good idea.
>>>> But in real life, do you need VPLS ? For very
>>> specific
>>>> needs, I think.
>>>> Remember LAN Emulation ? Really good idea.
>>>> But to troubleshoot...
>>>>
>>>>
>>>> --- sthaug <at> nethelp.no wrote:
>>>>
>>>>>> Frankly I'm surprised that there is so limited
>>>>> experience being talked
>>>>>> about - when MPLS first came out there was a
>>> lot
>>>>> of talk about it.
>>>>>>
>>>>>> A lack of interest only suggests either a lack
>>> of
>>>>> experience or that
>>>>>> it is all so easy it's mundane...
>>>>>
>>>>> We have VPLS in production (Juniper BGP based).
>>> It
>>>>> works but it is no
>>>>> silver bullet:
>>>>>
>>>>> - The VPLS code is less heavily used than other
>>> code
>>>>> - thus you are
>>>>> more likely to experience bugs in this area than
>>>>> other code.
>>>>>
>>>>> - Number of sites is an issue, mostly because
>>>>> traffic is replicated
>>>>> at the ingress router. You can usually limit the
>>>>> amount of broadcast
>>>>> and multicast traffic - but it is not easy to
>>> limit
>>>>> the amount of
>>>>> traffic to unknown *unicast* addresses (which
>>> then
>>>>> must be replicated
>>>>> to all sites).
>>>>>
>>>>> - If you want to make large multipoint L2
>>> networks
>>>>> you *really* need
>>>>> to look at your network design and figure out if
>>>>> you're not better
>>>>> served by MPLS (L3) VPN - where multipoint comes
>>> for
>>>>> "free".
>>>>>
>>>>> Steinar Haug, Nethelp consulting,
>>> sthaug <at> nethelp.no
>>>>>
>>>>> -------
>>>>> The MPLS-OPS Mailing List
>>>>> Subscribe/Unsubscribe:
>>>>> http://www.mplsrc.com/mplsops.shtml
>>>>> Archive:
>>>>> http://www.mplsrc.com/mpls-ops_archive.shtml
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> __________________________________
>>>> Yahoo! FareChase: Search multiple travel sites in
>>> one click.
>>>> http://farechase.yahoo.com
>>>>
>>>> -------
>>>> The MPLS-OPS Mailing List
>>>> Subscribe/Unsubscribe:
>>> http://www.mplsrc.com/mplsops.shtml
>>>> Archive:
>>> http://www.mplsrc.com/mpls-ops_archive.shtml
>>>>
>>>
>>>
>>> --
>>> Cumprimentos,
>>> Pedro Fortuna
>>>
>>
>>
>>
>>
>> __________________________________
>> Yahoo! FareChase: Search multiple travel sites in one click.
>> http://farechase.yahoo.com
>>
>
>
> --
> Cumprimentos,
> Pedro Fortuna
>
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

: MPLS LDP Neighbour Flapping