Re: Last Call: <draft-kumaki-murai-l3vpn-rsvp-te-06.txt> (Support for RSVP-TE in L3VPNs) to Experimental RFC
Lou Berger <lberger@labn.net> Tue, 23 October 2012 00:40 UTC
Return-Path: <lberger@labn.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27441F0C49 for <ietf@ietfa.amsl.com>; Mon, 22 Oct 2012 17:40:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.168
X-Spam-Level:
X-Spam-Status: No, score=-101.168 tagged_above=-999 required=5 tests=[AWL=0.831, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUK1ITh4dAZj for <ietf@ietfa.amsl.com>; Mon, 22 Oct 2012 17:40:58 -0700 (PDT)
Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 2F2321F0429 for <ietf@ietf.org>; Mon, 22 Oct 2012 17:40:58 -0700 (PDT)
Received: (qmail 12683 invoked by uid 0); 23 Oct 2012 00:40:34 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 23 Oct 2012 00:40:34 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Pt/+3ILc5XazMa21Ayvofm+brPTrfkXdzZLYUBatIP8=; b=MAOZL+RXaCGIGKUWipIX2GO+zNUYOofrkxJ/s5tpxqFyc3hYAVmvriFC/SuOWyG/NEgiuUvS/UlTGc7CjFdLIUjR/mktUITmpbk1jVV3MuZQKHIhWOmgz+xnWk58TTOJ;
Received: from box313.bluehost.com ([69.89.31.113]:50891 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1TQSXq-00017u-BZ; Mon, 22 Oct 2012 18:40:34 -0600
Message-ID: <5085E77C.5020100@labn.net>
Date: Mon, 22 Oct 2012 20:40:28 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Last Call: <draft-kumaki-murai-l3vpn-rsvp-te-06.txt> (Support for RSVP-TE in L3VPNs) to Experimental RFC
References: <20120905224357.14197.39927.idtracker@ietfa.amsl.com>
In-Reply-To: <20120905224357.14197.39927.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: Adrian Farrel <afarrel@juniper.net>, draft-kumaki-murai-l3vpn-rsvp-te.all@tools.ietf.org, Dan King <daniel@olddog.co.uk>, Stewart Bryant <stbryant@cisco.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Oct 2012 00:40:59 -0000
Hello, I made this comment privately during the LC period. I don't mind sharing it more widely: > My high-order take away is that it seems to me that this draft runs > counter to hierarchy-based solutions that can solve this problem just > fine without any additional RSVP modifications. I therefore think > this draft should be run through a WG that is willing to reconcile > the approaches (and fully document their uses case supported by > hierarchy). Failing that, I think the draft should have an IESG > applicability note added saying that this is experimental only and > that standard hierarchy should be used to solve the problem in any > operational implementation/network. > > As to the technical details, the next hop as identified by the Path > message in the VPN context, will have a route and associated label > within the VPN context. This VPN label can be added to the Path > message, just as it would be for any VPN IP packet, and additional > labels may be added for PE-PE transport. In implementations that > rewrite the IP header, the IP destination can be set to the next > hop. The remote PE/next hop will receive the Path message with the > VPN label which will identify the VPN context/VRF. This PE will then > need to identify the packet as RSVP using either the router alert > mechanism or based on the IP header destination address. So I see no > reason for the modifications when the VAN-specific MPLS labels are > used. > > Shout if you think I missed something. Lou On 9/5/2012 6:43 PM, The IESG wrote: > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Support for RSVP-TE in L3VPNs' > <draft-kumaki-murai-l3vpn-rsvp-te-06.txt> as Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-10-03. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > IP Virtual Private Networks (VPNs) provide connectivity between sites > across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS > and a single provider edge (PE) node may provide access to multiple > customer sites belonging to different VPNs. > > The VPNs may support a number of customer services including RSVP and > RSVP-TE traffic. This document describes how to support RSVP-TE > between customer sites when a single PE supports multiple VPNs. > > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-kumaki-murai-l3vpn-rsvp-te/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-kumaki-murai-l3vpn-rsvp-te/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > Due to an error by the sponsoring Area Director, the Last Call on > this document (which completed on 3rd September) incorrectly > stated that this draft was intended that it be published as Informational. > The correct intention (as stated in the draft itself) is that it be > published as Experimental. > > This Last Call is to verify community consensus for publication of > this draft as Experimental. > > > > > >