Re: Advancing the Protocol and Morin Drafts

Ben Niven-Jenkins <benjamin.niven-jenkins@bt.com> Fri, 10 October 2008 16:24 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 9D9043A69FF; Fri, 10 Oct 2008 09:24:14 -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 C1B163A687C for <l3vpn@core3.amsl.com>; Fri, 10 Oct 2008 09:24:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 WlYepC-J6QrE for <l3vpn@core3.amsl.com>; Fri, 10 Oct 2008 09:24:12 -0700 (PDT)
Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 978BC3A686D for <l3vpn@ietf.org>; Fri, 10 Oct 2008 09:24:12 -0700 (PDT)
Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 17:24:26 +0100
Received: from 10.215.40.109 ([10.215.40.109]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Fri, 10 Oct 2008 16:24:25 +0000
User-Agent: Microsoft-Entourage/12.12.0.080729
Date: Fri, 10 Oct 2008 17:24:23 +0100
Subject: Re: Advancing the Protocol and Morin Drafts
From: Ben Niven-Jenkins <benjamin.niven-jenkins@bt.com>
To: "Luyuan Fang (lufang)" <lufang@cisco.com>, l3vpn@ietf.org
Message-ID: <C5154047.CB15%benjamin.niven-jenkins@bt.com>
Thread-Topic: Advancing the Protocol and Morin Drafts
Thread-Index: Ackq22IVXcYVaWuNTVSpYzh1QFICugAAoMdgAAWwnSo=
In-Reply-To: <DD7E9F364F33B54881C225192D4872D7A878D9@xmb-rtp-211.amer.cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 10 Oct 2008 16:24:26.0939 (UTC) FILETIME=[AA01A0B0:01C92AF4]
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

Luyuan,

I think you may be presupposing the final output.  If draft-morin is
accepted as a WG draft it comes under WG change control.  It is not asking
to send draft-morin to IESG as-is but whether to use draft-morin as the
initial basis for a document to describe a set of mandatory mechanisms for
mVPN.

There are more components to mVPN than just BGP Vs PIM for C-multicast
routing (although that would appear to be the most contentious).  The
current solution specifications make no stance on any of them.  It may be
that if consensus truly cannot be reached on a specific area of the mVPN
solution then we may need to leave that specific area open (ala L2VPN
signalling) but sending the specifications drafts as they stand today to
IESG and then calling it a day and leaving the whole solution space open is
IMO (as an operator) not an acceptable way forward.

Personally, I believe some of the AT&T comments to be somewhat irrelevant to
this specific poll because although they are extremely valid comments in
their own right they are not specific to draft-morin but to the whole mVPN
solution space (i.e. the current mVPN WG solution drafts also do not address
them) and then the question to my mind becomes do we want to progress the
current solutions drafts in the best way now and address the additional
items later or hold up progression of the whole mVPN solution space while we
address the additional items.  I am not in favour of the latter and that is
not the question currently being asked by the WG chairs AFAICT.

Ben 


On 10/10/2008 15:41, "Luyuan Fang (lufang)" <lufang@cisco.com> wrote:

>  
> 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. Many folks spoke out here are
> running live networks, this is not a theoretical debate. I don't see we
> can get consensus here.
> 
> Could we still proceed with the two protocol drafts, like we did for
> L2VPN - both LDP signaling and BGP signaling became standards? I think
> that would be useful comparing with no standards for MVPN at all.
> 
> Thanks,
> Luyuan
> 
> 
>> -----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
> 
>