Subject: Re: VPLS external Loop Protection Mechanism (VLPM) - draft-l2vpn-vlpm-01

From: "Boldy, Richard" <[email-masked]>
Date: Sat, 16 Mar 2013 17:16:21 -0400

Hi,

I'd like to advise you of the update to the posted ID as detailed below for consideration by the L2VPN working group.

A new version of I-D, draft-l2vpn-vlpm-01.txt
has been successfully submitted by Time Warner Cable and posted to the
IETF repository.

Filename:  draft-l2vpn-vlpm
Revision:  01
Title:  VPLS external Loop Protection Mechanism (VLPM)
Creation date:  2013-03-13
Group:  Individual Submission
Number of pages: 10
URL:             http://www.ietf.org/internet-drafts/draft-l2vpn-vlpm-01.txt
Status:          http://datatracker.ietf.org/doc/draft-l2vpn-vlpm
Htmlized:        http://tools.ietf.org/html/draft-l2vpn-vlpm-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-l2vpn-vlpm-01

Abstract:
    Virtual Private LAN Service (VPLS) as defined in RFC4761 [RFC4761]
    and RFC4762 [RFC4762] implementations are highly susceptible to
    layer-2 loops external to the PE customer-facing interface. Such
    loops impact performance and can have a detrimental effect on all
    VPLS traffic throughout the entire instance under certain
    conditions.

    Current Layer-2 loop detection and protection mechanisms do not
    function effectively here.

    This document describes a protocol function (VPLS External Loop
    Protection Mechanism (VLPM)) to offer VPLS service providers a
    mechanism for detecting such layer-2 loops and facilitating
    configurable actions without the need for inter-operation with
    customer network protocols, other VPLS PEs or sites.

The IETF Secretariat

Kind regards
Rich./

Rich Boldy
Principal Engineer
National Network Operations Engineering
Advanced Technology Group

13820 Sunrise Valley Dr | Herndon, VA 20171
Office: (703) 713 1573
Mobile:(512) 673-2719
Email:[email-masked]<mailto:[email-masked]>
AIM:rboldytwc

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 18 Mar 2013 14:27:51 -0700

Hi Richard,

What's the reason for using an "unknown unicast" and not just a regular
multicast
frame for this?

The problem you're trying to solve looks very similar to what TRILL needed
to solve.
TRILL uses IS-IS hellos to address this problem.

Anoop

On Sat, Mar 16, 2013 at 2:16 PM, Boldy, Richard
<[email-masked]>wrote:

> URL:
> http://www.ietf.org/internet-drafts/draft-l2vpn-vlpm-01.txt

---

From: "Boldy, Richard" <[email-masked]>
Date: Tue, 19 Mar 2013 14:54:09 -0400

Hi Anoop,

Good questions. Firstly though I'd like the group to note that I had a discussion with one of the chairs (Giles) today and I will be breaking this out into a requirement draft to be followed by a revised VLPM draft once the req doc is fleshed out.

That said I will try and answer the questions you posed as you graciously took the time to give feedback on this.

-----
Q1 - It's funny you ask this cos it did start life using a multicast frame but the decision was made to change this to use a specific unknown unicast address due to the following reasoning, but it's up for debate:

 1.  To remove the risk that the frames may get filtered due to multicast filtering either by IGMP Snooping, MAC ACL or specifically configured command line block statements in the external layer2 segment. IGMP Snooping should ignore reserved multicast allocated space however there is potential here for differing vendor interpretation/error/bugs etc. MAC ACL and specific command line blocking is also possible for unknown unicast however I think it's fair to say that this is less common and it would be much more acceptable to write into the terms of a VPLS service agreement that unknown unicast blocking was not to be in place than to do so for multicast blocking where a customer may not have any need for multicast frames in their network segment at all.
 2.  To ensure that the frame has the greatest chance of flooding through the entirety of the layer2 segment. Depending on configuration the layer2 segment could be pruning multicast.
 3.  Simply it seams more complicated to use a multicast address when there is no specific multicast need and to the same end it maybe easier to get the allocation for unicast for the same reason.

Q2 - Please correct me if I'm missing something but I think the solution to the TRILL problem was different in that it assumes that the full layer2 broadcast domain is under one administrative control or that at least there is some ability to "bookend" I.e There needs to be an Rbridge for de-encap. For this issue we are looking to protect a centralized broadcast domain from external layer2 segments that are not in the same administrative control and we do not want to try and inter–op here with a stateful protocol or anything that is topographically aware. We see this issue with trying to run STP with a "customer" also.

The intent is to be stateless so that the "customer" doesn't need to care too much about it and the service provider can standardize on a their ELAN service model without needing to care what the customer is doing except for setting some basic requirements such as split-horizon and no-unicast mac filtering.

-----
Thanks for your input.

R./

Rich Boldy
Principal Engineer
CCNP JNCIS-SP MEF-CECP

13820 Sunrise Valley Dr | Herndon, VA 20171
Office: (703) 713 1573
Mobile: (512) 673-2719
Email: [email-masked]<mailto:[email-masked]>
AIM:rboldytwc

From: Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>
To: Richard Boldy <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: VPLS external Loop Protection Mechanism (VLPM) - draft-l2vpn-vlpm-01

Hi Richard,

What's the reason for using an "unknown unicast" and not just a regular multicast
frame for this?

The problem you're trying to solve looks very similar to what TRILL needed to solve.
TRILL uses IS-IS hellos to address this problem.

Anoop

On Sat, Mar 16, 2013 at 2:16 PM, Boldy, Richard <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 19 Mar 2013 14:07:34 -0700

Hi Richard,

Thanks for the response.

One problem with using a unicast MAC in the DA is what happens if
someone spoofs that MAC address as a source MAC?  The bridges
would all learn this source MAC and the propagation of UPF frames
would be restricted.  Multicast addresses would not be subject to that
security limitation.

TRILL uses IS-IS for several functions.  The portion of IS-IS that
accomplishes
the objective of this draft for TRILL can be made to work where it is
operated
in a domain separate from the "core" broadcast domain that is being
protected from these loops.

I'm not very active in the VPLS area so I'll let others decide whether
the security concern is acceptable or not.

Anoop

On Tue, Mar 19, 2013 at 11:54 AM, Boldy, Richard
<[email-masked]>wrote:

>   Hi Anoop,
>
>  Good questions. Firstly though I'd like the group to note that I had a
> discussion with one of the chairs (Giles) today and I will be breaking this
> out into a requirement draft to be followed by a revised VLPM draft once
> the req doc is fleshed out.
>
>  That said I will try and answer the questions you posed as you
> graciously took the time to give feedback on this.
>
>  -----
> Q1 - It's funny you ask this cos it did start life using a multicast frame
> but the decision was made to change this to use a specific unknown unicast
> address due to the following reasoning, but it's up for debate:
>
>    1. To remove the risk that the frames may get filtered due to
>    multicast filtering either by IGMP Snooping, MAC ACL or specifically
>    configured command line block statements in the external layer2 segment.
>    IGMP Snooping should ignore reserved multicast allocated space however
>    there is potential here for differing vendor interpretation/error/bugs etc.
>    MAC ACL and specific command line blocking is also possible for unknown
>    unicast however I think it's fair to say that this is less common and it
>    would be much more acceptable to write into the terms of a VPLS service
>    agreement that unknown unicast blocking was not to be in place than to do
>    so for multicast blocking where a customer may not have any need for
>    multicast frames in their network segment at all.
>    2. To ensure that the frame has the greatest chance of flooding
>    through the entirety of the layer2 segment. Depending on configuration the
>    layer2 segment could be pruning multicast.
>    3. Simply it seams more complicated to use a multicast address when
>    there is no specific multicast need and to the same end it maybe easier to
>    get the allocation for unicast for the same reason.
>
>
>  Q2 - Please correct me if I'm missing something but I think the solution
> to the TRILL problem was different in that it assumes that the full layer2
> broadcast domain is under one administrative control or that at least there
> is some ability to "bookend" I.e There needs to be an Rbridge for de-encap.
> For this issue we are looking to protect a centralized broadcast domain
> from external layer2 segments that are not in the same administrative
> control and we do not want to try and inter–op here with a stateful
> protocol or anything that is topographically aware. We see this issue with
> trying to run STP with a "customer" also.
>
>  The intent is to be stateless so that the "customer" doesn't need to
> care too much about it and the service provider can standardize on a their
> ELAN service model without needing to care what the customer is doing
> except for setting some basic requirements such as split-horizon and
> no-unicast mac filtering.
>
>  -----
> Thanks for your input.
>
>  R./
>
>
>
>                        *Rich Boldy*
>
> Principal Engineer
> ** **
> Office: (703) 713 1573****
>
> Mobile: (512) 673-2719
>
> Email: [email-masked]
>      AIM:rboldytwc
>
>      *
>
>  *
>
>
>
>
>   From: Anoop Ghanwani <[email-masked]>
> To: Richard Boldy <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> On Sat, Mar 16, 2013 at 2:16 PM, Boldy, Richard <[email-masked]
> > wrote:
>
>>
> ------------------------------
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>