Mailing List Archive: Cisco: NSP

VPLS and BPDU

Index | Next | Previous | View Threaded

saku at ytti

Jun 13, 2012, 1:02 AM

Post #1 of 8 (779 views)
Permalink

VPLS and BPDU

Not really c-nsp specific, but MEF doesn't appear to have public mailing
list and as this contains operational matters, it probably won't interest
nanog.

How are people handling BPDUs in their VPLS products? Reading MEF[0]
requirements, only product where you are allowed to tunnel BPDU, is
point-to-point, all multipoint either must peer or discard. Now maybe it is
just me, but I don't want my PE router to have hundred different MST, PVST,
RST, REP etc processes running. I don't want to change my PE MST instance
configs when ever customer does changes to their MST.
Infact, I don't want any flavour of any STP anywhere near my PE.

I want to tunnel BPDU over the VPLS network, as if my VPLS is stupid hub.
But as MEF does not allow this, it must silly idea. And I'm pretty sure my
customers expect to see BPDU pass the network transparently. I could, even
if my access is metro L2, do MAC-rewrite/L2PT to facilitate tunneling.

But surely MEF has given this lot more thought, so what am I missing?

[0] http://www.metroethernetforum.org/PDF_Documents/technical-specifications/MEF_6.1.1.pdf
--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

daniel at shunoshu

Jun 13, 2012, 1:34 AM

Post #2 of 8 (733 views)
Permalink

Re: VPLS and BPDU [In reply to]

On Wed, Jun 13, 2012 at 10:02 AM, Saku Ytti <saku [at] ytti> wrote:
> I want to tunnel BPDU over the VPLS network, as if my VPLS is stupid hub.
> But as MEF does not allow this, it must silly idea. And I'm pretty sure my
> customers expect to see BPDU pass the network transparently. I could, even
> if my access is metro L2, do MAC-rewrite/L2PT to facilitate tunneling.
>
> But surely MEF has given this lot more thought, so what am I missing?

are you talking about "EP-LAN" or "EVP-LAN" services? If "stupid hub"
means you're transparent for all customer frames including CE-vlans,
I'm assuming EP-LAN (?)
for "EP-LAN", the requirement is that BPDUs *must* be tunneled (see
flowchart in 8.1).

--
Daniel.
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

saku at ytti

Jun 13, 2012, 6:13 AM

Post #3 of 8 (728 views)
Permalink

Re: VPLS and BPDU [In reply to]

On (2012-06-13 10:34 +0200), Daniel Verlouw wrote:

> for "EP-LAN", the requirement is that BPDUs *must* be tunneled (see
> flowchart in 8.1).

The URL I linked, which clarifies BPDU handling, section 8.1.3 'L2CP
Requirements for Ethernet Private LAN (EP-LAN) Service' says 'Must Peer on
all UNIs or Discard on all UNIs'

I'm having great troubles understanding 8.1.3 as permission to tunnel.
--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

philxor at gmail

Jun 13, 2012, 6:44 AM

Post #4 of 8 (729 views)
Permalink

Re: VPLS and BPDU [In reply to]

I haven't looks at all of the latest MEF specs myself but in reality we tunnel STP frames. There are a couple instances where misconfigurations have led to looping which peering may have solved but we do not want to be asking customers about there STP setups and it wouldn't scale.

We do encourage customers to connect to the VPLS using L3 interfaces if they can. However there are some folks using VPLS who actually need L2, even if a minor amount.

Phil

On Jun 13, 2012, at 9:13 AM, Saku Ytti <saku [at] ytti> wrote:

> On (2012-06-13 10:34 +0200), Daniel Verlouw wrote:
>
>> for "EP-LAN", the requirement is that BPDUs *must* be tunneled (see
>> flowchart in 8.1).
>
> The URL I linked, which clarifies BPDU handling, section 8.1.3 'L2CP
> Requirements for Ethernet Private LAN (EP-LAN) Service' says 'Must Peer on
> all UNIs or Discard on all UNIs'
>
> I'm having great troubles understanding 8.1.3 as permission to tunnel.
> --
> ++ytti
> _______________________________________________
> cisco-nsp mailing list cisco-nsp [at] puck
> 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
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

daniel at shunoshu

Jun 13, 2012, 7:18 AM

Post #5 of 8 (732 views)
Permalink

Re: VPLS and BPDU [In reply to]

On Wed, Jun 13, 2012 at 3:13 PM, Saku Ytti <saku [at] ytti> wrote:
> On (2012-06-13 10:34 +0200), Daniel Verlouw wrote:
> The URL I linked, which clarifies BPDU handling, section 8.1.3 'L2CP
> Requirements for Ethernet Private LAN (EP-LAN) Service' says 'Must Peer on
> all UNIs or Discard on all UNIs'
>
> I'm having great troubles understanding 8.1.3 as permission to tunnel.

as explained in 8.1, it's a two step logic;

First step is based on destination mac only.
STP destination mac is 01-80-C2-00-00-00, so for EP-LAN, table B
applies, which reads "must tunnel".

Second step (table F in 8.1.3) only comes into play for destination
macs 01-80-C2-00-00-01 through -0A and 01-80-C2-00-00-0E, but STP does
not run on those macs at all normally so only step 1 applies.

and note this document only applies to L2CP with destination macs in
the 01-80-C2-00-00-00 to -0F range. E.g. for Cisco and others
proprietary stuff using other macs you can do whatever you please.

--
Daniel.
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

saku at ytti

Jun 13, 2012, 10:40 AM

Post #6 of 8 (721 views)
Permalink

Re: VPLS and BPDU [In reply to]

On (2012-06-13 16:18 +0200), Daniel Verlouw wrote:

> and note this document only applies to L2CP with destination macs in
> the 01-80-C2-00-00-00 to -0F range. E.g. for Cisco and others
> proprietary stuff using other macs you can do whatever you please.

So would your interpretation of VLAN based options be, that tunneling means
explicitly frames which have STP DMAC during transit? If I've changed the
STP DMAC for EVP-LAN transit, I'm not sending STP DMAC and I'm not
violating the requirement of peering STP?

I'm fearing that I'm trying to be 'clever' working around with intent of
the standard.
But if this is within the spirit of the standard, and I can say I'm EVP-LAN
compliant when I'm rewriting STP DMACs during transit , this is great news.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

daniel at shunoshu

Jun 14, 2012, 3:19 AM

Post #7 of 8 (714 views)
Permalink

Re: VPLS and BPDU [In reply to]

On Wednesday, June 13, 2012 at 7:40 PM, Saku Ytti wrote:

So would your interpretation of VLAN based options be, that tunneling means
explicitly frames which have STP DMAC during transit? If I've changed the
STP DMAC for EVP-LAN transit, I'm not sending STP DMAC and I'm not
violating the requirement of peering STP?

my understanding is that you, as provider of the service, cannot do that.
MEF doesn't have a notion of 'in transit', it only describes the end-to-end
service parameters from the customer' perspective.
Tunneling means passing the L2CP frame without change across the -service-.
If you rewrite on ingress and revert to the original mac on egress,
effectively that's unmodified.
For vlan-based services, table C states must *not* tunnel. Then step 2
comes into play which states peer or discard.

If the -customer- would rewrite the dst mac prior to ingressing into your
service, that would be fine.

To be honest, I don't understand why MEF states it must not be tunneled on
any of the vlan-based services, and if someone from MEF or a MEF-member is
lurking, I'd love to hear some good reasoning for this as well :-)

--
Daniel.
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

saku at ytti

Jun 14, 2012, 4:09 AM

Post #8 of 8 (711 views)
Permalink

Re: VPLS and BPDU [In reply to]

On (2012-06-14 12:19 +0200), Daniel Verlouw wrote:

> If the -customer- would rewrite the dst mac prior to ingressing into your
> service, that would be fine.

Thanks Daniel I really appreciate your thoughts on the matter.

I have pretty much same feeling, it wouldn't be MEF compliant product if
I'd do this hackery. And I'd love to advertise that we've read related
standards and are compliant to them instead of ninja NIHing it.
If I would do it, I would do it at customer site on managed CE, but I don't
think that much changes the situation, I would be in violation of MEF.

> To be honest, I don't understand why MEF states it must not be tunneled on
> any of the vlan-based services, and if someone from MEF or a MEF-member is
> lurking, I'd love to hear some good reasoning for this as well :-)

Quite. But if I'm not blind MEF does not even have public mailing list,
they seem to be ivory tower to the power of rad even compared to IETF.

So there is good chance that I'm not talking crazy, wanting to tunnel BPDU
in VLAN based multipoint MEF, but problem might be that MEF does not know
what people in real world want. Tunneling seem better for provider and
customer.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads