Re: New Version Notification for draft-boldy-l2vpn-vplsloop-req-00.txt

"Boldy, Richard" <richard.boldy@twcable.com> Fri, 12 April 2013 15:14 UTC

Return-Path: <richard.boldy@twcable.com>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5F421F8700 for <l2vpn@ietfa.amsl.com>; Fri, 12 Apr 2013 08:14:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.138
X-Spam-Level: *
X-Spam-Status: No, score=1.138 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WuaEyOJL55U for <l2vpn@ietfa.amsl.com>; Fri, 12 Apr 2013 08:14:48 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE3C21F86FA for <l2vpn@ietf.org>; Fri, 12 Apr 2013 08:14:47 -0700 (PDT)
X-SENDER-IP: 10.136.163.14
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos; i="4.87,462,1363147200"; d="png'150?scan'150,208,217,150"; a="56320551"
Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 12 Apr 2013 11:14:45 -0400
Received: from PRVPEXVS14.corp.twcable.com ([10.136.163.49]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 12 Apr 2013 11:14:47 -0400
From: "Boldy, Richard" <richard.boldy@twcable.com>
To: "l2vpn@ietf.org" <l2vpn@ietf.org>
Date: Fri, 12 Apr 2013 11:14:39 -0400
Subject: Re: New Version Notification for draft-boldy-l2vpn-vplsloop-req-00.txt
Thread-Topic: New Version Notification for draft-boldy-l2vpn-vplsloop-req-00.txt
Thread-Index: Ac43kHgItVHX9SugTu614dtKdhuocg==
Message-ID: <CD8D9B19.8D650%richard.boldy@twcable.com>
In-Reply-To: <83FEE822-F3F2-47BF-A34F-C1AB6B71635C@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.2.120421
acceptlanguage: en-US
Content-Type: multipart/related; boundary="_004_CD8D9B198D650richardboldytwcablecom_"; type="multipart/alternative"
MIME-Version: 1.0
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2013 15:14:49 -0000

Hi Folks,

Just to follow up on Giles email below. I'd like to get a simple yes/no response on if you think this is a real world problem that needs a solution.

We are particularly interest in service provider comments but I'd like to get a simple straw-poll on adoption by the WG here asap.

Outside of the WG I've received a great deal of interest in this and my proposed solution so I'd like to re-start discussion on the solution draft of this preferably within the WG if possible.

Rgds
Rich./




Rich Boldy
Principal Engineer
National Network Operations Engineering
Advanced Technology Group
CCNP JNCIS-SP MEF-CECP

[cid:17564400-F75F-444C-BB81-85E383882B3A]

13820 Sunrise Valley Dr | Herndon, VA 20171
Office: (703) 713 1573
Mobile: (512) 673-2719
Email: richard.boldy@twcable.com
AIM:rboldytwc





From: Giles Heron <giles.heron@gmail.com<mailto:giles.heron@gmail.com>>
To: Richard Boldy <richard.boldy@twcable.com<mailto:richard.boldy@twcable.com>>
Cc: "l2vpn@ietf.org<mailto:l2vpn@ietf.org>" <l2vpn@ietf.org<mailto:l2vpn@ietf.org>>
Subject: Re: New Version Notification for draft-boldy-l2vpn-vplsloop-req-00.txt

Thanks Rich

WG - please take a moment to review the draft and to give feedback.

I'd be particularly interested in feedback from SPs as to whether they see this as a requirement for their VPLS networks.

Giles

On 21 Mar 2013, at 15:13, "Boldy, Richard" <richard.boldy@twcable.com<mailto:richard.boldy@twcable.com>> wrote:

Hi,
At the request of one of our Chairs (Giles) the REQ draft below replaces my original draft - "draft-l2vpn-vlpm' as a requirements draft for this solution.
Once reviewed and chewed I'll be submitting my proposed solution draft (as per my original ID) but I welcome any others.
Let's put the solution discussion on the shelf for now till we get a good peer review on this REQ.
Kind regards
Rich./
Rich Boldy
Principal Engineer
National Network Operations Engineering
Advanced Technology Group
CCNP MEF-CECP

<CE42269E-D6FE-4EE1-B6FF-B091393A5BF3[1].png>
13820 Sunrise Valley Dr | Herndon, VA 20171
Office: (703) 713 1573
Mobile:
(512) 673-2719
Email:
richard.boldy@twcable.com<mailto:richard.boldy@twcable.com>
AIM:rboldytwc
From: "internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>" <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
To: Richard Boldy <richard.boldy@twcable.com<mailto:richard.boldy@twcable.com>>
Subject: New Version Notification for draft-boldy-l2vpn-vplsloop-req-00.txt
A new version of I-D, draft-boldy-l2vpn-vplsloop-req-00.txt
has been successfully submitted by Time Warner Cable and posted to the
IETF repository.
Filename: draft-boldy-l2vpn-vplsloop-req
Revision: 00
Title: VPLS External Loop Detection and Protection Requirements
Creation date: 2013-03-21
Group: Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-boldy-l2vpn-vplsloop-req-00.txt
Status:          http://datatracker.ietf.org/doc/draft-boldy-l2vpn-vplsloop-req
Htmlized:        http://tools.ietf.org/html/draft-boldy-l2vpn-vplsloop-req-00
Abstract:
     Virtual Private LAN Service (VPLS) implementations, as defined in
     [RFC4761] and [RFC4762], are highly susceptible to layer-2 loops
     external to the PE customer-facing interface. Such loops impact
     performance and can have a detrimental affect 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 the requirements for a protocol function
     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 customer sourced frames.

The IETF Secretariat
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.