RE: Advancing the Protocol and Morin Drafts

Thomas Morin <thomas.morin@orange-ftgroup.com> Mon, 13 October 2008 08:15 UTC

Return-Path: <l3vpn-bounces@ietf.org>
X-Original-To: l3vpn-archive@megatron.ietf.org
Delivered-To: ietfarch-l3vpn-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA79C3A682B; Mon, 13 Oct 2008 01:15:10 -0700 (PDT)
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130613A6827 for <l3vpn@core3.amsl.com>; Mon, 13 Oct 2008 01:15:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBgOYJ0xC-QV for <l3vpn@core3.amsl.com>; Mon, 13 Oct 2008 01:15:09 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id CD6373A657C for <l3vpn@ietf.org>; Mon, 13 Oct 2008 01:15:08 -0700 (PDT)
Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 10:14:41 +0200
Received: from [10.193.15.31] ([10.193.15.31]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Oct 2008 10:14:40 +0200
Subject: RE: Advancing the Protocol and Morin Drafts
From: Thomas Morin <thomas.morin@orange-ftgroup.com>
To: "Luyuan Fang (lufang)" <lufang@cisco.com>
In-Reply-To: <DD7E9F364F33B54881C225192D4872D7A878D9@xmb-rtp-211.amer.cisco.com>
References: <DD7E9F364F33B54881C225192D4872D7A878D9@xmb-rtp-211.amer.cisco.com>
Content-Type: text/plain
Organization: France Telecom R&D - Orange Labs
Date: Mon, 13 Oct 2008 10:14:40 +0200
Message-Id: <1223885680.5574.37.camel@l-at11168.FTRD>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Oct 2008 08:14:40.0668 (UTC) FILETIME=[BDA9C5C0:01C92D0B]
Cc: L3VPN <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
Sender: l3vpn-bounces@ietf.org
Errors-To: l3vpn-bounces@ietf.org

Hi Luyuan,

Luyuan Fang :
>
> When there is substantial deployment in the field with the existing
> approach, making a newer proposal a must and the exiting one an optional
> is business/operation/customer impacting. 

The statement above doesn't match the reality of the documents being
discussed: draft-ietf-l3vpn-2547bis-mcast does *NOT* include the
existing draft-rosen deployments ; *whatever* option is chosen inside
draft-ietf-l3vpn-2547bis-mcast -- including the one closest to
draft-rosen -- any draft-rosen deployment will have to go through a
migration phase to become in line with the current IET specs.

> Many folks spoke out here are running live networks, this is not a 
> theoretical debate. 

Believe me, the many operators co-authoring
draft-morin-l3vpn-mvpn-considerations are not taking this issue by the
theoretical side...

-Thomas



> > -----Original Message-----
> > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf
> 
> > Of Marshall Eubanks
> > Sent: Wednesday, October 01, 2008 10:04 AM
> > To: l3vpn@ietf.org
> > Cc: Ross Callon
> > Subject: Advancing the Protocol and Morin Drafts
> > 
> > This email starts a 3 week call for input, to expire October 23, 2008,
> 
> > for the following steps:
> > 
> > 1.) To accept draft-morin-l3vpn-mvpn-considerations-03 as a working 
> > group document;  and
> > 
> > 2.) To turn this document into a requirements draft, with mandatory to
> 
> > implement features for an interoperable implementation. The authors 
> > have indicated that they are willing to do this.
> > 
> > Our intention is, if this approach is accepted, to then begin WG last 
> > call to submit to the IESG for publication:
> > 
> > draft-ietf-l3vpn-2547bis-mcast
> > draft-ietf-l3vpn-2547bis-mcast-bgp
> > 
> > We expect that these two documents will be submitted more or less as 
> > is (i.e., certainly with any new bug fixes or other necessary 
> > corrections and improvements, but without specific mandatory to 
> > implement feature description in those drafts).
> > 
> > Please respond to the list with your recommendations for these two 
> > courses of action.
> > 
> > Regards
> > Marshall & Danny
> 
>