[c-nsp] PWHE vs BVI on Bridge Domain - l2vpn ios xr

[Aaron]

Additional services aside for the moment (qos, load balancing, etc) ....from
a layer 2 switching/bridging and layer 3 routing perspective, is there
something that one does that the other won't do ?  trying to understand why
cisco would make a way to accomplish l2 and l3 using two different
constructs....bg:bd w/ac's and pw's and w/bvi for l3..... then also this
pwhe stuff with xconnect groups, p2p xconnects, interfacelists, and PW
interface for L3   ??


Aaron

-----Original Message-----
From: brad dreisbach [mailto:bradd at ntt.net] 
Sent: Thursday, June 06, 2013 6:10 PM
To: Luis Anzola
Cc: Aaron; <cisco-nsp at puck.nether.net>
Subject: Re: [c-nsp] PWHE vs BVI on Bridge Domain - l2vpn ios xr

On Thu, Jun 06, 2013 at 06:24:23PM -0400, Luis Anzola wrote:
> Hi Aaron,
> 
> Take a look on the PWHE and BVI interface capabilities in terms of feature
set (qos, sec, routing, etc) and you will probably find the answer to your
question, e.g. QoS is not supported on BVI interfaces.
> 
> QoS on PWHE Interfaces:
>  IPv4 and IPv6 address-families are supported.
> Policy maps on both ingress and egress PW-HE. Both ingress and egress
support policing, marking, and queuing within hardware limitations.
> Policies at the port for the transit traffic can be applied simultaneously
with policies for PWHE interfaces.
> Policy is replicated on all PWHE members. This means the rate specified in
the PWHE policy-map is limited to the lowest rate of all the pin down
members. For example, if the PW-HE interface has both 1G and 10G pin down
members, the rate is limited to 1G. if the 10G member has a shaper of 900
mbps, the rate of the PWHE interface policy is limited to 900 mbps.
> Port shaping policy on the member interface will impact the PWHE traffic
passing through that port.
> Best regards, 
> 

i thought QoS on bvi was supported as of 4.3, granted there are some 
limitations.

http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.3/qos/conf
iguration/guide/b_qos_cg43asr_chapter_0100.html#concept_0C713A476AC94459A988
65A4191D9AAD

when i evaluated the two features i preferred the bvi solution, but our
requirements may be different than yours. the main reason was that pwhe has 
load balancing problems. when using pwhe with bundles it will only use a
single
member for the pwhe traffic(at least at the moment, i hope they are fixing
that). 

> Luis
> 
> Sent from my iPhone
> 
> On Jun 6, 2013, at 5:36 PM, "Aaron" <aaron1 at gvtc.com> wrote:
> 
> > From a previous post, I got curious about PWHE since I didn't know what
it
> > was.
> > 
> > 
> > 
> > I looked at someone's config and read a little about it on cisco.com.
> > 
> > 
> > 
> > It seems that what I'm reading about PWHE and what I saw in a previous
> > config of a previous post, I've used a construct of l2vpn, bridge group,
> > bridge domain, neighbors for pw's, and bvi for L3 to accomplish a
similar
> > function as what someone else used with xconnect groups, p2p xconnects,
> > interfacelists, and PW interface for L3
> > 
> > 
> > 
> > Why would I use one method over the other?
> > 
> > 
> > 
> > Aaron
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/