From david.freedman@uk.clara.net Mon Feb 6 06:38:52 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE9421F8645 for ; Mon, 6 Feb 2012 06:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 aqKm+xa4AjmV for ; Mon, 6 Feb 2012 06:38:51 -0800 (PST) Received: from staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [IPv6:2001:a88:0:fff7::68]) by ietfa.amsl.com (Postfix) with ESMTP id 4532C21F8642 for ; Mon, 6 Feb 2012 06:38:50 -0800 (PST) Received: from [195.157.10.59] (port=25517 helo=SRVGREXCAS02.claranet.local) by staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [80.168.65.68]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1RuPiT-0003BJ-1I for l3vpn@ietf.org (return-path ); Mon, 06 Feb 2012 14:38:49 +0000 Received: from SRVGREXMB01.claranet.local ([10.75.5.11]) by SRVGREXCAS02.claranet.local ([fe80::cd6a:3120:3174:a299%10]) with mapi id 14.01.0339.001; Mon, 6 Feb 2012 14:38:49 +0000 From: David Freedman To: "l3vpn@ietf.org" Subject: RFC4577 Question Thread-Topic: RFC4577 Question Thread-Index: AQHM5N0JFWdVZN6YQ0yY4p36kOg29Q== Date: Mon, 6 Feb 2012 14:38:48 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.18.6.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <4F10882EAAFC0F46A91804921B650C4F@claranet.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 14:38:52 -0000 Hiya, I have a question pertaining to RFC4577 "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)" RFC4577 makes the following requirement of creating Sham Links (Sec 4.2.7.3): -------------- An OSPF protocol packet is regarded as having been received on a particular Sham Link if and only if the following three conditions hold: - The packet arrives as an MPLS packet, and its MPLS label stack causes it to be "delivered" to the local Sham Link endpoint address. - The packet's IP destination address is the local Sham Link endpoint address. - The packet's IP source address is the remote Sham Link endpoint address. --------------- Can I ask why a requirement for the OSPF protocol packet to be MPLS exists? Imagining that only the CE router runs OSPF, and runs BGP with the PE router, since the (OSPF) routing information is injected into the BGP at the PE router, and also labelled (As per RFC4364) , surely an MPLS LSP directly from the OSPF endpoint is not required? =20 I currently have a use-case whereby I do not wish to run the OSPF protocol on the PE router, but am happy to do this on the CE, I'd like to be able to form the sham link between the CE routers, without having to introduce MPLS to them, since I speak BGP with the PE which is capable of labelling, and the BGP is also responsible for consistent routing between the two, surely this restriction shouldn't need to exist? Regards David Freedman Claranet From acee.lindem@ericsson.com Mon Feb 6 06:52:39 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDE221F84DD for ; Mon, 6 Feb 2012 06:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 PKK-fhep-a4T for ; Mon, 6 Feb 2012 06:52:39 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0479D21F84D4 for ; Mon, 6 Feb 2012 06:52:38 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q16EqbM4004206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Feb 2012 08:52:38 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.135]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 6 Feb 2012 09:52:35 -0500 From: Acee Lindem To: David Freedman Date: Mon, 6 Feb 2012 09:52:33 -0500 Subject: Re: RFC4577 Question Thread-Topic: RFC4577 Question Thread-Index: Aczk3vZFMabk0uRpTPeXjbnZ2kpeIg== Message-ID: <9BE89D02-6BFF-4E13-9687-E05E101237C7@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 14:52:40 -0000 Hi David,=20 You are envisioning a topology that is not supported by RFC4577. You simply= cannot have a sham link w/o running OSPF on the PE.=20 I've been in discussions of running OSPF as an OTT protocol but there is no= standard and it is not RFC4577.=20 Hope this helps, Acee On Feb 6, 2012, at 9:38 AM, David Freedman wrote: > Hiya, >=20 > I have a question pertaining to RFC4577 >=20 > "OSPF as the Provider/Customer Edge Protocol for > BGP/MPLS IP Virtual Private Networks (VPNs)" >=20 > RFC4577 makes the following requirement of creating > Sham Links (Sec 4.2.7.3): >=20 >=20 >=20 > -------------- >=20 > An OSPF protocol packet is regarded as having been received on a > particular Sham Link if and only if the following three conditions > hold: >=20 > - The packet arrives as an MPLS packet, and its MPLS label stack > causes it to be "delivered" to the local Sham Link endpoint > address. >=20 > - The packet's IP destination address is the local Sham Link > endpoint address. >=20 > - The packet's IP source address is the remote Sham Link endpoint > address. >=20 > --------------- >=20 >=20 > Can I ask why a requirement for the OSPF protocol > packet to be MPLS exists? >=20 > Imagining that only the CE router runs OSPF, and runs BGP with > the PE router, since the (OSPF) routing information is injected > into the BGP at the PE router, and also labelled (As per RFC4364) > , surely an MPLS LSP directly from the OSPF endpoint is not required? >=20 > I currently have a use-case whereby I do not wish to run the OSPF > protocol on the PE router, but am happy to do this on the CE, > I'd like to be able to form the sham link between the CE routers, > without having to introduce MPLS to them, since I speak BGP with > the PE which is capable of labelling, and the BGP is also responsible > for consistent routing between the two, surely this restriction > shouldn't need to exist? >=20 >=20 > Regards >=20 > David Freedman >=20 > Claranet >=20 >=20 From internet-drafts@ietf.org Mon Feb 6 08:39:05 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A5421F8620; Mon, 6 Feb 2012 08:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 rxuHJWAwjJeo; Mon, 6 Feb 2012 08:39:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517C721F8613; Mon, 6 Feb 2012 08:39:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-mvpn-bidir-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120206163904.1204.75040.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2012 08:39:04 -0800 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 16:39:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Work= ing Group of the IETF. Title : MVPN: Using Bidirectional P-Tunnels Author(s) : Yiqun Cai Eric C. Rosen IJsbrand Wijnands Arjen Boers Filename : draft-ietf-l3vpn-mvpn-bidir-01.txt Pages : 16 Date : 2012-02-06 The documents specifying multicast support for BGP/MPLS IP VPNs allow customer multicast data to be transported through a service provider's network through a set multicast tunnels. Such tunnels are advertised by BGP in a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel Attribute". The base specifications allow the PMSI Tunnel Attribute to advertise bidirectional multicast distribution trees as "PMSI Tunnels"; however, those documents do not provide all the necessary details for using those tunnels. These details are provided in this document. This document also specifies the procedures for assigning customer multicast flows to specific bidirectional PMSI tunnels. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mvpn-bidir-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l3vpn-mvpn-bidir-01.txt From touch@isi.edu Mon Feb 6 15:20:54 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A97D21F8711 for ; Mon, 6 Feb 2012 15:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=-1.103, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] 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 YMTPhVo1yYvt for ; Mon, 6 Feb 2012 15:20:54 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1B95F21F870B for ; Mon, 6 Feb 2012 15:20:54 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q16NKaV5006285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Feb 2012 15:20:36 -0800 (PST) Message-ID: <4F306044.4060407@isi.edu> Date: Mon, 06 Feb 2012 15:20:36 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Larry Kreeger Subject: Re: Network Virtualization Overlay Control Plane Requirements posted References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 23:20:54 -0000 Hi, all, Regarding issues with tunnels and fragmentation, we're still planning to complete the following summary: J. Touch, M. Townsley, “Tunnels in the Internet Architecture,” draft-ietf-intarea-tunnels-00.txt, Feb. 2010. We have an update in the works. Regarding the requirements overall, it might be useful to look at an actual example of an overlay control plane: Y. E. Yang, J. Touch, G. Finn, “The X-Bone API,” ISI Technical Report ISI-TR-2005-611, Dec 2005. Both are cached on my pubs pages. Joe On 1/31/2012 10:20 AM, Larry Kreeger wrote: > This needed moderator approval for Bcc...so I am posting it directly > now. - Larry > > ------ Forwarded Message > *From: *Larry Kreeger > *Date: *Mon, 30 Jan 2012 11:40:36 -0800 > *To: * > *Subject: *[nvo3] Network Virtualization Overlay Control Plane > Requirements posted > > To: nvo3 mailing list > Bcc: l2vpn, l3vpn, dc, armd, vpn4dc mailing lists > > Hi everyone, > > I have recently posted a first draft of the Control Plane requirements > for Network Virtualization Overlays. > > http://www.ietf.org/id/draft-kreeger-nvo3-overlay-cp-00.txt > > This draft is a follow-up to > draft-narten-nvo3-overlay-problem-statement-01 ( > http://tools.ietf.org/html/draft-narten-nvo3-overlay-problem-statement-01 ) > which makes the case for overlay networks in data centers (not > restricted to L2 over L3) and the need for control plane solutions. > > If you have not read draft-narten-nvo3-overlay-problem-statement-01, I > highly suggest reading it first because the posted control plane reqs > document picks up where it left off. > > Since the posted draft is a followup to > draft-narten-nvo3-overlay-problem-statement-01 , and there is already an > NVO3 mailing list, please join and post any discussion and/or comments > to nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > Thank you, > Larry Kreeger > ------------------------------------------------------------------------ > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > ------ End of Forwarded Message From internet-drafts@ietf.org Thu Feb 9 11:45:25 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F59321F8729; Thu, 9 Feb 2012 11:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 T5NK-wG+B3LW; Thu, 9 Feb 2012 11:45:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F3F21F86FA; Thu, 9 Feb 2012 11:45:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-mvpn-wildcards-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120209194522.3839.79599.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2012 11:45:22 -0800 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 19:45:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Work= ing Group of the IETF. Title : Wildcards in Multicast VPN Auto-Discovery Routes Author(s) : Eric C. Rosen Yakov Rekhter Ray (Lei) Qiu Filename : draft-ietf-l3vpn-mvpn-wildcards-02.txt Pages : 18 Date : 2012-02-09 In "Multicast Virtual Private Networks" (MVPNs), customer multicast flows are carried in "tunnels" through a service provider's network. The base specifications for MVPN define BGP multicast VPN "auto-discovery routes", and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel. However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel. Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN. This document eliminates these restrictions by specifying the use of "wildcard" elements in the customer flow identifiers. With wildcard elements, a single auto-discovery route can refer to multiple customer flows, or even to all customer flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mvpn-wildcards-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l3vpn-mvpn-wildcards-02.txt From iesg-secretary@ietf.org Thu Feb 9 15:20:58 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF9E21F85F7; Thu, 9 Feb 2012 15:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 8CF8uAH5dFex; Thu, 9 Feb 2012 15:20:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E411321F85B8; Thu, 9 Feb 2012 15:20:56 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Wildcards in Multicast VPN Auto-Discovery Routes) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120209232056.12045.92506.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2012 15:20:56 -0800 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 23:20:58 -0000 The IESG has received a request from the Layer 3 Virtual Private Networks WG (l3vpn) to consider the following document: - 'Wildcards in Multicast VPN Auto-Discovery Routes' as a Proposed Standard 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-02-23. 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 In "Multicast Virtual Private Networks" (MVPNs), customer multicast flows are carried in "tunnels" through a service provider's network. The base specifications for MVPN define BGP multicast VPN "auto-discovery routes", and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel. However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel. Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN. This document eliminates these restrictions by specifying the use of "wildcard" elements in the customer flow identifiers. With wildcard elements, a single auto-discovery route can refer to multiple customer flows, or even to all customer flows. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-l3vpn-mvpn-wildcards/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-l3vpn-mvpn-wildcards/ No IPR declarations have been submitted directly on this I-D. From ice@cisco.com Fri Feb 10 03:25:02 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EDC21F8593 for ; Fri, 10 Feb 2012 03:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=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 g0hROZVHt+hy for ; Fri, 10 Feb 2012 03:25:01 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2B38F21F8592 for ; Fri, 10 Feb 2012 03:25:01 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q1ABJRRT029793 for ; Fri, 10 Feb 2012 12:19:27 +0100 (CET) Received: from ams-iwijnand-87111.cisco.com (ams-iwijnand-87111.cisco.com [10.55.191.156]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q1ABJQlm021706; Fri, 10 Feb 2012 12:19:27 +0100 (CET) From: IJsbrand Wijnands Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 Date: Fri, 10 Feb 2012 12:19:25 +0100 Message-Id: <6EABF66C-AF44-49D6-AA8F-728C894ED957@cisco.com> To: L3VPN mailing list Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 11:25:02 -0000 Dear L3VPN, We presented draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 to the = MPLS WG last IETF in Taipei and received a comment that this should be = discussed in L3VPN. As it looks there is not going to be a L3VPN meeting = in Paris, for that reason I'm sending out this email to solicit input on = this draft. This draft describes a solution to be used in a VPN environment, but it = is not intended to be used as a generic solution for Multicast VPNs. It = is for specific deployments where traffic is bundled in 'service' VPNs = within a Providers network, following similar procedures and rationale = as described in draft-ietf-mpls-mldp-in-band-signaling-05. These VPNs = are not generic customer VPNs, but used to transport content such as = IPTV or financial data through a Providers network. The basic idea is that the ingress PE's VRF RD is added to the mLDP FEC = opaque encoding to make it unique and VPN specific. This follows the = same model as described in draft-ietf-mpls-mldp-recurs-fec-04 section 3. = We had a similar discussion regarding the use of the RD in the opaque = encoding and decided to accept it as WG document in the MPLS WG. Some may say this solution does not follow the multicast procedures as = documented in draft-ietf-l3vpn-2547bis-mcast-10, and for that reason = should not be allowed. However, 1. This is not any different from draft-ietf-mpls-mldp-recurs-fec-04 = section 3. 2. This draft is driven by customer interest. 3. This solution relies on existing IP-VPN BGP procedures without = additional extensions. For that reason we like to see = draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 progress as WG = document in the MPLS WG. We welcome your feedback, Thx, The authors. From yakov@juniper.net Thu Feb 16 05:54:19 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E2E21F8757 for ; Thu, 16 Feb 2012 05:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.755 X-Spam-Level: X-Spam-Status: No, score=-105.755 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 w+Nilcj-+YzG for ; Thu, 16 Feb 2012 05:54:18 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id B023221F8646 for ; Thu, 16 Feb 2012 05:54:14 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTz0KhChTZlMVlZ0LKoQwSgKN0VKaN0MT@postini.com; Thu, 16 Feb 2012 05:54:18 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 16 Feb 2012 05:52:09 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q1GDq8120797; Thu, 16 Feb 2012 05:52:08 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201202161352.q1GDq8120797@magenta.juniper.net> To: Subject: draft-rekhter-l3vpn-virtual-hub-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <97535.1329400328.1@juniper.net> Date: Thu, 16 Feb 2012 05:52:08 -0800 From: Yakov Rekhter X-EXCLAIMER-MD-CONFIG: f8e27f27-03b2-4c3e-9447-119194e72cb6 Cc: yakov@juniper.net, luay.jalil@verizon.com, hj2387@att.com, bruno.decraene@orange-ftgroup.com, raggarwa_1@yahoo.com, ju1738@att.com X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 13:54:19 -0000 Dear L3VPN WG chairs, The authors of draft-rekhter-l3vpn-virtual-hub-02.txt would like you to poll the L3VPN WG for accepting draft-rekhter-l3vpn-virtual-hub-02.txt as an L3VPN WG document. Yakov From agmalis@gmail.com Fri Feb 17 08:03:13 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD38221F8678 for ; Fri, 17 Feb 2012 08:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 uwhqgFGARi63 for ; Fri, 17 Feb 2012 08:03:12 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C3D5221F8673 for ; Fri, 17 Feb 2012 08:03:12 -0800 (PST) Received: by ghbg16 with SMTP id g16so2139084ghb.31 for ; Fri, 17 Feb 2012 08:03:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qo+pOcLQhmQqG3f1JdKA6jLtiHBiPJZWwnI/aHAKgNo=; b=nfiPZ+SQA2MFYhUXEfm28487igA/gNkhJTW+Ff8OaycVkC5AHiz86c9UPYWE3EHH+K bdwSae24aqTec+zbmK6SIUjPllfqdQLClh4qXPqFRXArO2THzzVTDozAl5Z9L4fvks0d I29kP5Np0qMUffGgfQuSdxEUBDER8Weix2rrM= Received: by 10.50.203.100 with SMTP id kp4mr9391922igc.6.1329494592262; Fri, 17 Feb 2012 08:03:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.171.106 with HTTP; Fri, 17 Feb 2012 08:02:51 -0800 (PST) In-Reply-To: <201202161352.q1GDq8120797@magenta.juniper.net> References: <201202161352.q1GDq8120797@magenta.juniper.net> From: "Andrew G. Malis" Date: Fri, 17 Feb 2012 11:02:51 -0500 Message-ID: Subject: Re: draft-rekhter-l3vpn-virtual-hub-02.txt To: Yakov Rekhter Content-Type: text/plain; charset=ISO-8859-1 Cc: l3vpn@ietf.org, bruno.decraene@orange-ftgroup.com, luay.jalil@verizon.com, hj2387@att.com, raggarwa_1@yahoo.com, ju1738@att.com X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 16:03:13 -0000 Support. Cheers, Andy On Thu, Feb 16, 2012 at 8:52 AM, Yakov Rekhter wrote: > Dear L3VPN WG chairs, > > The authors of draft-rekhter-l3vpn-virtual-hub-02.txt would like > you to poll the L3VPN WG for accepting > draft-rekhter-l3vpn-virtual-hub-02.txt as an L3VPN WG document. > > Yakov From ben@niven-jenkins.co.uk Mon Feb 20 03:30:15 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FF621F872D for ; Mon, 20 Feb 2012 03:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.833 X-Spam-Level: X-Spam-Status: No, score=-102.833 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 ztOfvC+A5Rqf for ; Mon, 20 Feb 2012 03:30:14 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6E16621F8723 for ; Mon, 20 Feb 2012 03:30:14 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=xxx.dhcp.cachelogic.com) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RzRRd-0000wa-05; Mon, 20 Feb 2012 11:30:13 +0000 Subject: Re: draft-rekhter-l3vpn-virtual-hub-02.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <201202161352.q1GDq8120797@magenta.juniper.net> Date: Mon, 20 Feb 2012 11:30:09 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0F9E07D2-EFAB-43F5-B46B-ADAB969D1AB3@niven-jenkins.co.uk> References: <201202161352.q1GDq8120797@magenta.juniper.net> To: Yakov Rekhter X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: l3vpn@ietf.org, bruno.decraene@orange-ftgroup.com, luay.jalil@verizon.com, hj2387@att.com, raggarwa_1@yahoo.com, ju1738@att.com X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 11:30:15 -0000 Hi Yakov, On 16 Feb 2012, at 13:52, Yakov Rekhter wrote: > Dear L3VPN WG chairs, >=20 > The authors of draft-rekhter-l3vpn-virtual-hub-02.txt would like > you to poll the L3VPN WG for accepting > draft-rekhter-l3vpn-virtual-hub-02.txt as an L3VPN WG document. I was just wondering what is the overlap, if any, with the hub & spoke = section of draft-rosen-l3vpn-mvpn-extranet-04, does your draft & the hub = & spoke elements of Eric's draft cover the same material or are they = solving different problems? Thanks Ben >=20 > Yakov From yakov@juniper.net Mon Feb 20 06:13:10 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC2421F8744 for ; Mon, 20 Feb 2012 06:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.799 X-Spam-Level: X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 tteDSvBY-0Xk for ; Mon, 20 Feb 2012 06:13:10 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 59F8C21F8741 for ; Mon, 20 Feb 2012 06:13:03 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKT0JU7d4kKrt8xA51mebTALBUjmp4tIgl@postini.com; Mon, 20 Feb 2012 06:13:09 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 20 Feb 2012 06:12:36 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q1KECV148813; Mon, 20 Feb 2012 06:12:32 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201202201412.q1KECV148813@magenta.juniper.net> To: Ben Niven-Jenkins Subject: Re: draft-rekhter-l3vpn-virtual-hub-02.txt In-Reply-To: <0F9E07D2-EFAB-43F5-B46B-ADAB969D1AB3@niven-jenkins.co.uk> References: <201202161352.q1GDq8120797@magenta.juniper.net> <0F9E07D2-EFAB-43F5-B46B-ADAB969D1AB3@niven-jenkins.co.uk> X-MH-In-Reply-To: Ben Niven-Jenkins message dated "Mon, 20 Feb 2012 11:30:09 +0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26595.1329747137.1@juniper.net> Date: Mon, 20 Feb 2012 06:12:17 -0800 From: Yakov Rekhter X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: l3vpn@ietf.org, Yakov Rekhter , luay.jalil@verizon.com, hj2387@att.com, bruno.decraene@orange-ftgroup.com, raggarwa_1@yahoo.com, ju1738@att.com X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 14:13:10 -0000 Ben, > Hi Yakov, > > On 16 Feb 2012, at 13:52, Yakov Rekhter wrote: > > > Dear L3VPN WG chairs, > > > > The authors of draft-rekhter-l3vpn-virtual-hub-02.txt would like > > you to poll the L3VPN WG for accepting > > draft-rekhter-l3vpn-virtual-hub-02.txt as an L3VPN WG document. > > I was just wondering what is the overlap, if any, with the hub & > spoke section of draft-rosen-l3vpn-mvpn-extranet-04, does your > draft & the hub & spoke elements of Eric's draft cover the same > material or are they solving different problems? The latter - my draft and the hub & spoke elements of Eric's draft are solving different problems. E.g., Eric's draft describes how a service provider can offer its VPN customers hub-and-spoke connectivity (e.g., "a system in one spoke site cannot send traffic and cannot receive traffic from a system in a different spoke site"), while my draft covers customers who want full mesh connectivity (any site can talk to any other site, without going through some third site). Yakov. From mn1921@att.com Mon Feb 20 14:55:10 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA8D21F85FB for ; Mon, 20 Feb 2012 14:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 51wrlsOvZkwQ for ; Mon, 20 Feb 2012 14:55:09 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id A474521F85F2 for ; Mon, 20 Feb 2012 14:54:55 -0800 (PST) X-Env-Sender: mn1921@att.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1329778494!16610953!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15806 invoked from network); 20 Feb 2012 22:54:54 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-11.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Feb 2012 22:54:54 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1KMtOxJ001065; Mon, 20 Feb 2012 17:55:24 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1KMtLwX001043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Feb 2012 17:55:21 -0500 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by sflint01.pst.cso.att.com (RSA Interceptor); Mon, 20 Feb 2012 17:54:44 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.48]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.01.0355.002; Mon, 20 Feb 2012 17:54:44 -0500 From: "NAPIERALA, MARIA H" To: IJsbrand Wijnands , L3VPN mailing list Subject: RE: Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 Thread-Topic: Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 Thread-Index: AQHM5+amOkenuSI7yUWI83iVAElikJZGc2AQ Date: Mon, 20 Feb 2012 22:54:43 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80EA96F22@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <6EABF66C-AF44-49D6-AA8F-728C894ED957@cisco.com> In-Reply-To: <6EABF66C-AF44-49D6-AA8F-728C894ED957@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.131.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 22:55:10 -0000 In my opinion, draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 fits well = within MPLS WG. It adds to a MLDP set of procedures to allow "virtualizatio= n" of MLDP in-band signaling. I am in support for progressing it in MPLS WG. Regards, Maria=20 > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of IJsbrand Wijnands > Sent: Friday, February 10, 2012 6:19 AM > To: L3VPN mailing list > Subject: Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 >=20 > Dear L3VPN, >=20 > We presented draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 to the > MPLS WG last IETF in Taipei and received a comment that this should be > discussed in L3VPN. As it looks there is not going to be a L3VPN > meeting in Paris, for that reason I'm sending out this email to solicit > input on this draft. >=20 > This draft describes a solution to be used in a VPN environment, but it > is not intended to be used as a generic solution for Multicast VPNs. It > is for specific deployments where traffic is bundled in 'service' VPNs > within a Providers network, following similar procedures and rationale > as described in draft-ietf-mpls-mldp-in-band-signaling-05. These VPNs > are not generic customer VPNs, but used to transport content such as > IPTV or financial data through a Providers network. >=20 > The basic idea is that the ingress PE's VRF RD is added to the mLDP FEC > opaque encoding to make it unique and VPN specific. This follows the > same model as described in draft-ietf-mpls-mldp-recurs-fec-04 section > 3. We had a similar discussion regarding the use of the RD in the > opaque encoding and decided to accept it as WG document in the MPLS WG. >=20 > Some may say this solution does not follow the multicast procedures as > documented in draft-ietf-l3vpn-2547bis-mcast-10, and for that reason > should not be allowed. > However, >=20 > 1. This is not any different from draft-ietf-mpls-mldp-recurs-fec-04 > section 3. > 2. This draft is driven by customer interest. > 3. This solution relies on existing IP-VPN BGP procedures without > additional extensions. >=20 > For that reason we like to see draft-wijnands-mpls-mldp-vpn-in-band- > signaling-00 progress as WG document in the MPLS WG. >=20 > We welcome your feedback, >=20 > Thx, >=20 > The authors. From wwwrun@rfc-editor.org Mon Feb 20 14:59:00 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43A721E8016; Mon, 20 Feb 2012 14:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 kHd4l3cU-2Xz; Mon, 20 Feb 2012 14:59:00 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD1E21E8010; Mon, 20 Feb 2012 14:59:00 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 62A1AB1E01A; Mon, 20 Feb 2012 14:53:55 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6514 on BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs From: rfc-editor@rfc-editor.org Message-Id: <20120220225355.62A1AB1E01A@rfc-editor.org> Date: Mon, 20 Feb 2012 14:53:55 -0800 (PST) Cc: l3vpn@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 22:59:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6514 Title: BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs Author: R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter Status: Standards Track Stream: IETF Date: February 2012 Mailbox: raggarwa_1@yahoo.com, erosen@cisco.com, thomas.morin@orange-ftgroup.com, yakov@juniper.net Pages: 59 Characters: 145112 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt URL: http://www.rfc-editor.org/rfc/rfc6514.txt This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK] This document is a product of the Layer 3 Virtual Private Networks Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Mon Feb 20 14:59:17 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC9B21E804D; Mon, 20 Feb 2012 14:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 yJM6wpASM5Xj; Mon, 20 Feb 2012 14:59:16 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9154C21E804E; Mon, 20 Feb 2012 14:59:16 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 12630B1E01B; Mon, 20 Feb 2012 14:54:12 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6515 on IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN From: rfc-editor@rfc-editor.org Message-Id: <20120220225412.12630B1E01B@rfc-editor.org> Date: Mon, 20 Feb 2012 14:54:12 -0800 (PST) Cc: l3vpn@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 22:59:17 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6515 Title: IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN Author: R. Aggarwal, E. Rosen Status: Standards Track Stream: IETF Date: February 2012 Mailbox: raggarwa_1@yahoo.com, erosen@cisco.com Pages: 8 Characters: 17550 Updates: RFC6514 I-D Tag: draft-ietf-l3vpn-mvpn-infra-addrs-05.txt URL: http://www.rfc-editor.org/rfc/rfc6515.txt To provide Multicast VPN (MVPN) service, Provider Edge routers originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN") BGP routes; they also originate unicast VPN routes that carry MVPN-specific attributes. These routes encode addresses from the customer's address space, as well as addresses from the provider's address space. These two address spaces are independent, and the address family (IPv4 or IPv6) of the two spaces may or may not be the same. These routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies the address family of the provider addresses. To ensure interoperability, this document specifies that provider IPv4 addresses are always encoded in these update messages as 4-octet addresses, and that the distinction between IPv4 and IPv6 is signaled solely by the length of the address field. Specific cases are explained in detail. This document updates RFC 6514. [STANDARDS-TRACK] This document is a product of the Layer 3 Virtual Private Networks Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Mon Feb 20 14:59:30 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7798D21E805A; Mon, 20 Feb 2012 14:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.949 X-Spam-Level: X-Spam-Status: No, score=-103.949 tagged_above=-999 required=5 tests=[AWL=1.128, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 D9eG1dRlIh12; Mon, 20 Feb 2012 14:59:30 -0800 (PST) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id EDD9D21E8054; Mon, 20 Feb 2012 14:59:29 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 7A185B1E012; Mon, 20 Feb 2012 14:54:25 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6516 on IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages From: rfc-editor@rfc-editor.org Message-Id: <20120220225425.7A185B1E012@rfc-editor.org> Date: Mon, 20 Feb 2012 14:54:25 -0800 (PST) Cc: l3vpn@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 22:59:30 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6516 Title: IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages Author: Y. Cai, E. Rosen, Ed., I. Wijnands Status: Standards Track Stream: IETF Date: February 2012 Mailbox: ycai@cisco.com, erosen@cisco.com, ice@cisco.com Pages: 6 Characters: 11992 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l3vpn-mvpn-spmsi-joins-02.txt URL: http://www.rfc-editor.org/rfc/rfc6516.txt The specification for Multicast Virtual Private Networks (MVPNs) contains an option that allows the use of PIM as the control protocol between provider edge routers. It also contains an option that allows UDP-based messages, known as Selective Provider Multicast Service Interface (S-PMSI) Join messages, to be used to bind particular customer multicast flows to particular tunnels through a service provider's network. This document extends the MVPN specification (RFC 6513) so that these options can be used when the customer multicast flows are IPv6 flows. [STANDARDS-TRACK] This document is a product of the Layer 3 Virtual Private Networks Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Mon Feb 20 14:59:47 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D39821E8063; Mon, 20 Feb 2012 14:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.012 X-Spam-Level: X-Spam-Status: No, score=-104.012 tagged_above=-999 required=5 tests=[AWL=1.065, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Zg-aznXvgXG5; Mon, 20 Feb 2012 14:59:46 -0800 (PST) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id EFEF721E8069; Mon, 20 Feb 2012 14:59:42 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 8F7A5B1E017; Mon, 20 Feb 2012 14:54:38 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6517 on Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution From: rfc-editor@rfc-editor.org Message-Id: <20120220225438.8F7A5B1E017@rfc-editor.org> Date: Mon, 20 Feb 2012 14:54:38 -0800 (PST) Cc: l3vpn@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 22:59:47 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6517 Title: Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution Author: T. Morin, Ed., B. Niven-Jenkins, Ed., Y. Kamite, R. Zhang, N. Leymann, N. Bitar Status: Informational Stream: IETF Date: February 2012 Mailbox: thomas.morin@orange.com, ben@niven-jenkins.co.uk, y.kamite@ntt.com, raymond.zhang@alcatel-lucent.com, n.leymann@telekom.de, nabil.n.bitar@verizon.com Pages: 41 Characters: 102395 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l3vpn-mvpn-considerations-06.txt URL: http://www.rfc-editor.org/rfc/rfc6517.txt More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks. To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Layer 3 Virtual Private Networks Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Mon Feb 20 15:09:23 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2057821F852D; Mon, 20 Feb 2012 15:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 6Ueau2yXM+sr; Mon, 20 Feb 2012 15:09:22 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8988A21F852A; Mon, 20 Feb 2012 15:09:21 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5ABD2B1E015; Mon, 20 Feb 2012 14:53:44 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6513 on Multicast in MPLS/BGP IP VPNs From: rfc-editor@rfc-editor.org Message-Id: <20120220225344.5ABD2B1E015@rfc-editor.org> Date: Mon, 20 Feb 2012 14:53:44 -0800 (PST) Cc: l3vpn@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 23:09:23 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6513 Title: Multicast in MPLS/BGP IP VPNs Author: E. Rosen, Ed., R. Aggarwal, Ed. Status: Standards Track Stream: IETF Date: February 2012 Mailbox: erosen@cisco.com, raggarwa_1@yahoo.com Pages: 88 Characters: 213780 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l3vpn-2547bis-mcast-10.txt URL: http://www.rfc-editor.org/rfc/rfc6513.txt In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. [STANDARDS-TRACK] This document is a product of the Layer 3 Virtual Private Networks Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From jeff.tantsura@ericsson.com Mon Feb 20 23:14:52 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A7A21F8504 for ; Mon, 20 Feb 2012 23:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] 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 HRftFdATdsPy for ; Mon, 20 Feb 2012 23:14:51 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6C021F8501 for ; Mon, 20 Feb 2012 23:14:51 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q1L7EnAk003149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Feb 2012 01:14:50 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.140]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 21 Feb 2012 02:14:49 -0500 From: Jeff Tantsura To: IJsbrand Wijnands , L3VPN mailing list Date: Tue, 21 Feb 2012 02:14:54 -0500 Subject: Re: Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 Thread-Topic: Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 Thread-Index: AczwaH7V06nBnrTzQ96ycOMdq0kW8Q== Message-ID: In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80EA96F22@MISOUT7MSGUSR9I.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 07:14:52 -0000 I support progress of this document as WG document in the MPLS WG. --=20 Regards, Jeff > >> -----Original Message----- >> From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf >> Of IJsbrand Wijnands >> Sent: Friday, February 10, 2012 6:19 AM >> To: L3VPN mailing list >> Subject: Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 >>=20 >> Dear L3VPN, >>=20 >> We presented draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 to the >> MPLS WG last IETF in Taipei and received a comment that this should be >> discussed in L3VPN. As it looks there is not going to be a L3VPN >> meeting in Paris, for that reason I'm sending out this email to solicit >> input on this draft. >>=20 >> This draft describes a solution to be used in a VPN environment, but it >> is not intended to be used as a generic solution for Multicast VPNs. It >> is for specific deployments where traffic is bundled in 'service' VPNs >> within a Providers network, following similar procedures and rationale >> as described in draft-ietf-mpls-mldp-in-band-signaling-05. These VPNs >> are not generic customer VPNs, but used to transport content such as >> IPTV or financial data through a Providers network. >>=20 >> The basic idea is that the ingress PE's VRF RD is added to the mLDP FEC >> opaque encoding to make it unique and VPN specific. This follows the >> same model as described in draft-ietf-mpls-mldp-recurs-fec-04 section >> 3. We had a similar discussion regarding the use of the RD in the >> opaque encoding and decided to accept it as WG document in the MPLS WG. >>=20 >> Some may say this solution does not follow the multicast procedures as >> documented in draft-ietf-l3vpn-2547bis-mcast-10, and for that reason >> should not be allowed. >> However, >>=20 >> 1. This is not any different from draft-ietf-mpls-mldp-recurs-fec-04 >> section 3. >> 2. This draft is driven by customer interest. >> 3. This solution relies on existing IP-VPN BGP procedures without >> additional extensions. >>=20 >> For that reason we like to see draft-wijnands-mpls-mldp-vpn-in-band- >> signaling-00 progress as WG document in the MPLS WG. >>=20 >> We welcome your feedback, >>=20 >> Thx, >>=20 >> The authors. > From robert@raszuk.net Tue Feb 21 03:08:18 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E5C21F8795 for ; Tue, 21 Feb 2012 03:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 noS7eqAl1G9h for ; Tue, 21 Feb 2012 03:08:17 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 3090721F878B for ; Tue, 21 Feb 2012 03:08:17 -0800 (PST) Received: (qmail 28656 invoked by uid 399); 21 Feb 2012 11:08:16 -0000 Received: from unknown (HELO ?172.16.0.194?) (pbs:robert@raszuk.net@91.221.145.233) by mail1310.opentransfer.com with ESMTPM; 21 Feb 2012 11:08:16 -0000 X-Originating-IP: 91.221.145.233 Message-ID: <4F437B21.5000102@raszuk.net> Date: Tue, 21 Feb 2012 12:08:17 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: IJsbrand Wijnands , L3VPN mailing list Subject: Re: Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 References: <6EABF66C-AF44-49D6-AA8F-728C894ED957@cisco.com> In-Reply-To: <6EABF66C-AF44-49D6-AA8F-728C894ED957@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 11:08:18 -0000 Hi, I support to accept this draft as WG document in either L3VPN or MPLS WG. Regards, R. > Dear L3VPN, > > We presented draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 to the > MPLS WG last IETF in Taipei and received a comment that this should > be discussed in L3VPN. As it looks there is not going to be a L3VPN > meeting in Paris, for that reason I'm sending out this email to > solicit input on this draft. > > This draft describes a solution to be used in a VPN environment, but > it is not intended to be used as a generic solution for Multicast > VPNs. It is for specific deployments where traffic is bundled in > 'service' VPNs within a Providers network, following similar > procedures and rationale as described in > draft-ietf-mpls-mldp-in-band-signaling-05. These VPNs are not generic > customer VPNs, but used to transport content such as IPTV or > financial data through a Providers network. > > The basic idea is that the ingress PE's VRF RD is added to the mLDP > FEC opaque encoding to make it unique and VPN specific. This follows > the same model as described in draft-ietf-mpls-mldp-recurs-fec-04 > section 3. We had a similar discussion regarding the use of the RD in > the opaque encoding and decided to accept it as WG document in the > MPLS WG. > > Some may say this solution does not follow the multicast procedures > as documented in draft-ietf-l3vpn-2547bis-mcast-10, and for that > reason should not be allowed. However, > > 1. This is not any different from draft-ietf-mpls-mldp-recurs-fec-04 > section 3. 2. This draft is driven by customer interest. 3. This > solution relies on existing IP-VPN BGP procedures without additional > extensions. > > For that reason we like to see > draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 progress as WG > document in the MPLS WG. > > We welcome your feedback, > > Thx, > > The authors. > > > From rajiva@cisco.com Tue Feb 21 04:32:48 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C123E21F8795 for ; Tue, 21 Feb 2012 04:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.004 X-Spam-Level: X-Spam-Status: No, score=-7.004 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 zAvK-okHjELW for ; Tue, 21 Feb 2012 04:32:44 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D547921F86BD for ; Tue, 21 Feb 2012 04:32:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2487; q=dns/txt; s=iport; t=1329827565; x=1331037165; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=XKXUDvwVCn28RQQ+F6sA+Yy7vO4X/IHGpGZAE3QRLu8=; b=Ojmg6JlJT67wu+wv7iXFrty66YtZjmb0xgmf5nPuXq2rvKAdcYd/rJEB odmf5zp6Ndn5TRrlxgsztiqGPuw3mg2Rm590xOT0IvEXy8AAsYAjjX4up mTczeEMgHOFiLl+DBlf+pTDjKOBqvuekB4tY++p3PNwA2kX0hVkBZcx07 Q=; X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="60562861" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 21 Feb 2012 12:32:44 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1LCWirm020310; Tue, 21 Feb 2012 12:32:44 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 06:32:44 -0600 Received: from 72.163.62.136 ([72.163.62.136]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Tue, 21 Feb 2012 12:32:43 +0000 Subject: Re: Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 References: Content-Transfer-Encoding: quoted-printable From: "Rajiv Asati (rajiva)" Content-Type: text/plain; charset="us-ascii" Thread-Topic: Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 Thread-Index: AczwlOi/5uvq02h6RieFa2myPdZLtg== In-Reply-To: Message-ID: <21C0E50D-99D6-467D-922B-3B263767002C@cisco.com> Date: Tue, 21 Feb 2012 07:32:41 -0500 To: "Jeff Tantsura" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 21 Feb 2012 12:32:44.0323 (UTC) FILETIME=[E9158730:01CCF094] Cc: L3VPN mailing list X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 12:32:48 -0000 Support. Cheers, Rajiv Sent from my Phone On Feb 21, 2012, at 2:14 AM, "Jeff Tantsura" wr= ote: > I support progress of this document as WG document in the MPLS WG. > --=20 > Regards, > Jeff >=20 >=20 >=20 >>=20 >>> -----Original Message----- >>> From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf >>> Of IJsbrand Wijnands >>> Sent: Friday, February 10, 2012 6:19 AM >>> To: L3VPN mailing list >>> Subject: Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 >>>=20 >>> Dear L3VPN, >>>=20 >>> We presented draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 to the >>> MPLS WG last IETF in Taipei and received a comment that this should be >>> discussed in L3VPN. As it looks there is not going to be a L3VPN >>> meeting in Paris, for that reason I'm sending out this email to solicit >>> input on this draft. >>>=20 >>> This draft describes a solution to be used in a VPN environment, but it >>> is not intended to be used as a generic solution for Multicast VPNs. It >>> is for specific deployments where traffic is bundled in 'service' VPNs >>> within a Providers network, following similar procedures and rationale >>> as described in draft-ietf-mpls-mldp-in-band-signaling-05. These VPNs >>> are not generic customer VPNs, but used to transport content such as >>> IPTV or financial data through a Providers network. >>>=20 >>> The basic idea is that the ingress PE's VRF RD is added to the mLDP FEC >>> opaque encoding to make it unique and VPN specific. This follows the >>> same model as described in draft-ietf-mpls-mldp-recurs-fec-04 section >>> 3. We had a similar discussion regarding the use of the RD in the >>> opaque encoding and decided to accept it as WG document in the MPLS WG. >>>=20 >>> Some may say this solution does not follow the multicast procedures as >>> documented in draft-ietf-l3vpn-2547bis-mcast-10, and for that reason >>> should not be allowed. >>> However, >>>=20 >>> 1. This is not any different from draft-ietf-mpls-mldp-recurs-fec-04 >>> section 3. >>> 2. This draft is driven by customer interest. >>> 3. This solution relies on existing IP-VPN BGP procedures without >>> additional extensions. >>>=20 >>> For that reason we like to see draft-wijnands-mpls-mldp-vpn-in-band- >>> signaling-00 progress as WG document in the MPLS WG. >>>=20 >>> We welcome your feedback, >>>=20 >>> Thx, >>>=20 >>> The authors. >>=20 >=20 From yakov@juniper.net Wed Feb 22 05:06:57 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8B221F87E2 for ; Wed, 22 Feb 2012 05:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.885 X-Spam-Level: X-Spam-Status: No, score=-105.885 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 FFAwa0cu6LG6 for ; Wed, 22 Feb 2012 05:06:57 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id C011B21F87A2 for ; Wed, 22 Feb 2012 05:06:56 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKT0Tobzfns+J/TjzXauJy1pgjZMNqkh5s@postini.com; Wed, 22 Feb 2012 05:06:56 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 22 Feb 2012 05:05:32 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q1MD5V108029; Wed, 22 Feb 2012 05:05:31 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201202221305.q1MD5V108029@magenta.juniper.net> To: IJsbrand Wijnands Subject: Re: Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 In-Reply-To: <6EABF66C-AF44-49D6-AA8F-728C894ED957@cisco.com> References: <6EABF66C-AF44-49D6-AA8F-728C894ED957@cisco.com> X-MH-In-Reply-To: IJsbrand Wijnands message dated "Fri, 10 Feb 2012 12:19:25 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <90210.1329915931.1@juniper.net> Date: Wed, 22 Feb 2012 05:05:31 -0800 From: Yakov Rekhter X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: L3VPN mailing list X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 13:06:58 -0000 Ice, > Dear L3VPN, > > We presented draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 to > the MPLS WG last IETF in Taipei and received a comment that this > should be discussed in L3 VPN. As it looks there is not going to > be a L3VPN meeting in Paris, for that reason I'm sending out this > email to solicit input on this draft. > > This draft describes a solution to be used in a VPN environment, > but it is not intended to be used as a generic solution for Multicast > VPNs. It is for specific deployments where traffic is bundled in > 'service' VPNs within a Providers n twork, following similar > procedures and rationale as described in draft-ietf-m > pls-mldp-in-band-signaling-05. These VPNs are not generic customer > VPNs, but used to transport content such as IPTV or financial data > through a Providers network. > > The basic idea is that the ingress PE's VRF RD is added to the mLDP > FEC opaque encoding to make it unique and VPN specific. This follows > the same model as described in draft-ietf-mpls-mldp-recurs-fec-04 > section 3. We had a similar discussion regarding the use of the > RD in the opaque encoding and decided to accept it as WG document > in the MPLS WG. > > Some may say this solution does not follow the multicast procedures > as documented in draft-ietf-l3vpn-2547bis-mcast-10, and for that > reason should not be al lowed. > > However, > > 1. This is not any different from draft-ietf-mpls-mldp-recurs-fec-04 > section 3. > 2. This draft is driven by customer interest. > 3. This solution relies on existing IP-VPN BGP procedures without additional > extensions. > > For that reason we like to see > draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 progress as > WG document in the MPLS WG. This draft, as you said above, "describes a solution to be used in a VPN environment". Thus it is outside the scope of the MPLS WG (as VPN is outside the charter of that WG). If the authors want to progress this draft as a WG document, then they should ask L3VPN WG to progress it as an L3VPN WG document (as VPN is within the charter of that WG). Yakov. From andy.da.green@bt.com Mon Feb 27 01:05:46 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A245121F856A for ; Mon, 27 Feb 2012 01:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 j3UvQkiH675A for ; Mon, 27 Feb 2012 01:05:45 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 67DC021F8504 for ; Mon, 27 Feb 2012 01:05:45 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 27 Feb 2012 09:05:41 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.72]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Mon, 27 Feb 2012 09:05:41 +0000 From: To: Date: Mon, 27 Feb 2012 09:05:41 +0000 Subject: Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 Thread-Topic: Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 Thread-Index: AQHM5+amOkenuSI7yUWI83iVAElikJZGc2AQgAoaVpA= Message-ID: <464C9090B4F1624C9174D50D456B13EF5AE33978A7@EMV65-UKRD.domain1.systemhost.net> References: <6EABF66C-AF44-49D6-AA8F-728C894ED957@cisco.com> <1D70D757A2C9D54D83B4CBD7625FA80EA96F22@MISOUT7MSGUSR9I.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80EA96F22@MISOUT7MSGUSR9I.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 09:05:46 -0000 This fits well with several planned service implementations I am in support for progressing it in MPLS WG. Regards, Andy > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf=20 > Of IJsbrand Wijnands > Sent: Friday, February 10, 2012 6:19 AM > To: L3VPN mailing list > Subject: Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 >=20 > Dear L3VPN, >=20 > We presented draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 to the=20 > MPLS WG last IETF in Taipei and received a comment that this should be=20 > discussed in L3VPN. As it looks there is not going to be a L3VPN=20 > meeting in Paris, for that reason I'm sending out this email to=20 > solicit input on this draft. >=20 > This draft describes a solution to be used in a VPN environment, but=20 > it is not intended to be used as a generic solution for Multicast=20 > VPNs. It is for specific deployments where traffic is bundled in=20 > 'service' VPNs within a Providers network, following similar=20 > procedures and rationale as described in=20 > draft-ietf-mpls-mldp-in-band-signaling-05. These VPNs are not generic=20 > customer VPNs, but used to transport content such as IPTV or financial da= ta through a Providers network. >=20 > The basic idea is that the ingress PE's VRF RD is added to the mLDP=20 > FEC opaque encoding to make it unique and VPN specific. This follows=20 > the same model as described in draft-ietf-mpls-mldp-recurs-fec-04=20 > section 3. We had a similar discussion regarding the use of the RD in=20 > the opaque encoding and decided to accept it as WG document in the MPLS W= G. >=20 > Some may say this solution does not follow the multicast procedures as=20 > documented in draft-ietf-l3vpn-2547bis-mcast-10, and for that reason=20 > should not be allowed. > However, >=20 > 1. This is not any different from draft-ietf-mpls-mldp-recurs-fec-04 > section 3. > 2. This draft is driven by customer interest. > 3. This solution relies on existing IP-VPN BGP procedures without=20 > additional extensions. >=20 > For that reason we like to see draft-wijnands-mpls-mldp-vpn-in-band- > signaling-00 progress as WG document in the MPLS WG. >=20 > We welcome your feedback, >=20 > Thx, >=20 > The authors. From tnadeau@lucidvision.com Mon Feb 27 13:22:57 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A3B21E804F for ; Mon, 27 Feb 2012 13:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 4FXD+e7VG2nv for ; Mon, 27 Feb 2012 13:22:56 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 59B5921E804D for ; Mon, 27 Feb 2012 13:22:56 -0800 (PST) Received: from [192.168.1.53] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id C21C715371D for ; Mon, 27 Feb 2012 16:13:33 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/alternative; boundary="Apple-Mail=_BB7C59EF-6619-4F8E-8A7A-84006F0D42C0" Subject: The MPLS 2012 International Conference Call For Papers Date: Mon, 27 Feb 2012 16:13:33 -0500 Message-Id: <0F8E4349-6A48-4506-BB2E-ABC8294B75A2@lucidvision.com> To: l3vpn@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 21:22:57 -0000 --Apple-Mail=_BB7C59EF-6619-4F8E-8A7A-84006F0D42C0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii The MPLS 2012 International Conference, the 15th Annual International Conference on MPLS and Related Technologies, will be held October 28 - 31, 2012, in Washington, DC. The Technical Program Committee is soliciting abstracts summarizing a proposed presentation representing original/unpublished work covering cutting-edge topics. Presentations covering new technologies and operational experience are solicited from network equipment vendors, service/transport providers, government agencies, the research community, and enterprise users. The deadline for submission of presentation proposals is April 30, 2012. If you want further information on MPLS 2012 or want to submit a presentation abstract, please see the following URL: http://www.isocore.com/mpls2012/call_for_papers/cfp.htm Many of these topics have been of interest to members of in the past, and many people active on this list have been presenters at past events. On behalf of the Technical Planning Committee --Apple-Mail=_BB7C59EF-6619-4F8E-8A7A-84006F0D42C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The MPLS 2012 International = Conference, the 15th Annual International
31, 2012, in Washington, DC. The Technical Program = Committee is
soliciting abstracts summarizing a = proposed presentation representing
original/unpublished = work covering cutting-edge topics.

Presentations covering new technologies and = operational experience are
solicited from network = equipment vendors, service/transport providers,
government = agencies, the research community, and enterprise users.
The deadline for submission of presentation = proposals is April 30, 2012.
If you want further = information on MPLS 2012 or want to submit a
presentation = abstract, please see the following URL:

Many of these topics have = been of interest to members of <this community>

On behalf of the Technical Planning = Committee
= --Apple-Mail=_BB7C59EF-6619-4F8E-8A7A-84006F0D42C0-- From david.freedman@uk.clara.net Wed Feb 29 10:05:16 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052F521F8716 for ; Wed, 29 Feb 2012 10:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 z8zcEoE-eXtx for ; Wed, 29 Feb 2012 10:05:15 -0800 (PST) Received: from staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [IPv6:2001:a88:0:fff7::68]) by ietfa.amsl.com (Postfix) with ESMTP id 5B89621F86EE for ; Wed, 29 Feb 2012 10:05:14 -0800 (PST) Received: from [195.157.10.59] (port=33254 helo=SRVGREXCAS04.claranet.local) by staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [80.168.65.68]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1S2ntp-0000im-03 for l3vpn@ietf.org (return-path ); Wed, 29 Feb 2012 18:05:13 +0000 Received: from SRVGREXMB01.claranet.local ([10.75.5.11]) by SRVGREXCAS04.claranet.local ([fe80::95c2:9976:e52:fe51%11]) with mapi id 14.01.0339.001; Wed, 29 Feb 2012 18:05:13 +0000 From: David Freedman To: "l3vpn@ietf.org" Subject: draft-freedman-l3vpn-ospf2-4364-ce-00.txt (was Re: RFC4577 Question) Thread-Topic: draft-freedman-l3vpn-ospf2-4364-ce-00.txt (was Re: RFC4577 Question) Thread-Index: AQHM9wyu47Qu7U4z006zqZ6KwGRdxw== Date: Wed, 29 Feb 2012 18:05:11 +0000 Message-ID: In-Reply-To: <20120229161803.27036.15817.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.18.6.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <67782BBD936BA34091BB43055464777D@claranet.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 18:05:16 -0000 Dear All, After speaking with Ben, I've decided to publish a document on what changes to RFC4577 behaviour I believe should occur in order to adapt this standard for operation between CE/C routers, I am seeking feedback on this work. I am also aware of draft-ietf-l3vpn-ospfv3-pece-11 and would ask that in addition, the authors of this document also step forward and comment as to whether they feel any of this could be applicable to their efforts. Regards, David Freedman On 29/02/2012 16:18, "internet-drafts@ietf.org" wrote: >A new version of I-D, draft-freedman-l3vpn-ospf2-4364-ce-00.txt has been >successfully submitted by David Freedman and posted to the IETF >repository. > >Filename: draft-freedman-l3vpn-ospf2-4364-ce >Revision: 00 >Title: OSPF Version 2 as the Customer Edge/Customer Protocol for >BGP/MPLS IP VPNs >Creation date: 2012-02-29 >WG ID: Individual Submission >Number of pages: 11 > >Abstract: > RFC4577 (OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP > VPNs) proposes a mechanism for the use of the Open Shortest Path > First V2 ("OSPF") protocol between the Provider Edge ("PE") > and Customer Edge ("CE") routers within a BGP/MPLS IP Virtual Private > Network ("IP/VPN", RFC4364). > > The standard provides for use of such a provider VPN to join > discontiguous locations together, preserving the OSPF area and domain > behaviour. > > This document describes a technique for utilising the same, IPVPN > network infrastructure without the requirement to enable the OSPF > protocol on the PE/CE interface and thus relieve the PE router of > OSPF duties. > > =20 > =20 > > >The IETF Secretariat From wwwrun@rfc-editor.org Wed Feb 29 13:44:01 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9510421F872E for ; Wed, 29 Feb 2012 13:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 zxkYMEnuQBVf for ; Wed, 29 Feb 2012 13:44:01 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2E77621F8713 for ; Wed, 29 Feb 2012 13:44:00 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id DAA3D72E042; Wed, 29 Feb 2012 13:38:23 -0800 (PST) To: luyuanfang@att.com, jari.arkko@piuha.net, rdroms.ietf@gmail.com, danny@tcb.net, marshall.eubanks@gmail.com, ben@niven-jenkins.co.uk Subject: [Editorial Errata Reported] RFC4111 (3143) From: RFC Errata System Message-Id: <20120229213823.DAA3D72E042@rfc-editor.org> Date: Wed, 29 Feb 2012 13:38:23 -0800 (PST) Cc: adam@nostrum.com, l3vpn@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 21:44:01 -0000 The following errata report has been submitted for RFC4111, "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4111&eid=3143 -------------------------------------- Type: Editorial Reported by: Adam Roach Section: 14 Original Text ------------- [RFC3889] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 3889, October 2004. Corrected Text -------------- [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006. Notes ----- Although the cited document appears to have reached the AUTH48 stage in 2004 and was provisionally assigned an RFC number of 3889, it was withdrawn for further editing and was never actually published under that number. Its eventual publication in 2006 was under the RFC number 4593. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4111 (draft-ietf-l3vpn-security-framework-03) -------------------------------------- Title : Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs) Publication Date : July 2005 Author(s) : L. Fang, Ed. Category : INFORMATIONAL Source : Layer 3 Virtual Private Networks INT Area : Internet Stream : IETF Verifying Party : IESG From ben@niven-jenkins.co.uk Wed Feb 29 14:01:17 2012 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14D821E8026 for ; Wed, 29 Feb 2012 14:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 CK4GZ7L7PH1D for ; Wed, 29 Feb 2012 14:01:17 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 7B09521F863D for ; Wed, 29 Feb 2012 14:00:59 -0800 (PST) Received: from 52.red-80-25-156.staticip.rima-tde.net ([80.25.156.52] helo=[10.6.1.66]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1S2rZw-0005GL-Pv; Wed, 29 Feb 2012 22:00:57 +0000 Subject: Re: [Editorial Errata Reported] RFC4111 (3143) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <20120229213823.DAA3D72E042@rfc-editor.org> Date: Wed, 29 Feb 2012 22:00:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120229213823.DAA3D72E042@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: adam@nostrum.com, l3vpn@ietf.org, luyuanfang@att.com, jari.arkko@piuha.net, rdroms.ietf@gmail.com, danny@tcb.net X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 22:01:17 -0000 The reported errata is correct but as RFC4111 is informational and the = reference to RFC3889 (which should be to RFC4593) is informative I would = suggest the correct errata state is "Hold for Document Update". Ben On 29 Feb 2012, at 21:38, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC4111, > "Security Framework for Provider-Provisioned Virtual Private Networks = (PPVPNs)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4111&eid=3D3143 >=20 > -------------------------------------- > Type: Editorial > Reported by: Adam Roach >=20 > Section: 14 >=20 > Original Text > ------------- > [RFC3889] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats = to >=20 > Routing Protocols", RFC 3889, October 2004. >=20 > Corrected Text > -------------- > [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats = to >=20 > Routing Protocols", RFC 4593, October 2006. >=20 > Notes > ----- > Although the cited document appears to have reached the AUTH48 stage = in 2004 and was provisionally assigned an RFC number of 3889, it was = withdrawn for further editing and was never actually published under = that number. Its eventual publication in 2006 was under the RFC number = 4593. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC4111 (draft-ietf-l3vpn-security-framework-03) > -------------------------------------- > Title : Security Framework for Provider-Provisioned = Virtual Private Networks (PPVPNs) > Publication Date : July 2005 > Author(s) : L. Fang, Ed. > Category : INFORMATIONAL > Source : Layer 3 Virtual Private Networks INT > Area : Internet > Stream : IETF > Verifying Party : IESG