From internet-drafts@ietf.org Mon Apr 1 15:46:03 2013 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 1100421F8A0C; Mon, 1 Apr 2013 15:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, 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 Cy9gViTb9thk; Mon, 1 Apr 2013 15:46:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BFA21E80F6; Mon, 1 Apr 2013 15:46:01 -0700 (PDT) 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-end-system-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130401224601.12673.72208.idtracker@ietfa.amsl.com> Date: Mon, 01 Apr 2013 15:46:01 -0700 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, 01 Apr 2013 22:46:03 -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 Working = Group of the IETF. Title : BGP-signaled end-system IP/VPNs. Author(s) : Pedro Marques Luyuan Fang Ping Pan Amit Shukla Maria Napierala Nabil Bitar Filename : draft-ietf-l3vpn-end-system-01.txt Pages : 21 Date : 2013-04-01 Abstract: This document describes a solution in which the control plane protocol specified in BGP/MPLS IP VPNs [RFC4364] is used to provide a Virtual Network service to end-systems. These end-systems may be used to provide network services or may directly host end-to-end applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-end-system There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l3vpn-end-system-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From saku@ytti.fi Tue Apr 2 02:36:25 2013 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 E6E1321F982F for ; Tue, 2 Apr 2013 02:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-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 y5D3nBeGRblo for ; Tue, 2 Apr 2013 02:36:25 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC1121F982B for ; Tue, 2 Apr 2013 02:36:24 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id oi10so182628obb.0 for ; Tue, 02 Apr 2013 02:36:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=RzZGF/62JTswnoBt44I/CeAeB6AJr7jvu7HorwY5rU4=; b=QSD9Y6F39SvBEt9BDvpVFrBgdJUXxQyEWPAg8bv7AalSphoBEhoPaVpfkbbtDgw77x 4/Q8IA+TflR+6mxiME7pGV9cSSPowdyw4SPLKND0ioGz1/vK378GtM58lYmzKGmuAYxg mIZOdfRiwk4BC/Ys+yZ/hT00KtYQtxdyd6tG1FUhB3Q/7wDS8XJhayjv1efBOns8uKSM Kcb8+pbblszD3vGRNuTLI4Yh0iGxMIFHOFVESgce/VdSqrRhSYKv16q3madaCPzNi7nD XPjJsnfxXNtfLIEPDZpWaA6dcQfzDte1m6kMIpQvOaZhP7Lfg4hkW8twOJ1EAbuzwcRm H6Pw== MIME-Version: 1.0 X-Received: by 10.182.1.10 with SMTP id 10mr5358470obi.15.1364895384438; Tue, 02 Apr 2013 02:36:24 -0700 (PDT) Received: by 10.182.143.74 with HTTP; Tue, 2 Apr 2013 02:36:24 -0700 (PDT) In-Reply-To: <20130401224601.12673.72208.idtracker@ietfa.amsl.com> References: <20130401224601.12673.72208.idtracker@ietfa.amsl.com> Date: Tue, 2 Apr 2013 12:36:24 +0300 Message-ID: Subject: Re: I-D Action: draft-ietf-l3vpn-end-system-01.txt From: Saku Ytti To: l3vpn@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmHYWTemQ5h5FiTOuRooShM8G/kKBFfCXSv4QyGTxuU5d7DtrBe9u/gE/ueNZH49Red73Z1 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, 02 Apr 2013 09:36:26 -0000 - External VPN forwarder at page 12 appears not to support QinQ, should it? - Draft seems IPv4 centric, with static /32 often appearing, while IPv6 support is explicitly mentioned. - Draft mentions GRE and MPLS supported, but most examples speak as if it's always GRE encapsulated. It's not clear to me how VPN forwarder would connect via MPLS to a P or PE node, where would IGP label come. Or should end-system route server<->PE have OptB? (Would also give label security, so VPN forwarder would not need to be fully trusted) On 2 April 2013 01:46, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. > > Title : BGP-signaled end-system IP/VPNs. > Author(s) : Pedro Marques > Luyuan Fang > Ping Pan > Amit Shukla > Maria Napierala > Nabil Bitar > Filename : draft-ietf-l3vpn-end-system-01.txt > Pages : 21 > Date : 2013-04-01 > > Abstract: > This document describes a solution in which the control plane > protocol specified in BGP/MPLS IP VPNs [RFC4364] is used to provide a > Virtual Network service to end-systems. These end-systems may be > used to provide network services or may directly host end-to-end > applications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-l3vpn-end-system > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-l3vpn-end-system-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > -- ++ytti From rraszuk@gmail.com Tue Apr 2 03:42:07 2013 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 2D00221F980A for ; Tue, 2 Apr 2013 03:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 mgODnmXZ0gzz for ; Tue, 2 Apr 2013 03:42:06 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE4C21F9829 for ; Tue, 2 Apr 2013 03:42:05 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id r11so319158lbv.40 for ; Tue, 02 Apr 2013 03:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/MRgitUnWdhZoBItHeKz1loyqeB6P3SiPgQygs6A+Js=; b=AsM2VwH6IJ/MRsreR3tPGPGlvX9TNSmqmDLnuoLux15Aq01xD17Nlf74gvHIr/u5Km mxe/rVaYJq1WD7efVSBX5RmUlLxBVgzl2wy029aMYepnceSP6OK9CLS3TrfdIrEh1eBc tVnNNLY6MwLF0NKHiGAunObSqEzGwpuWu4VfG9GWH2qguE6l3OrGcr2cmxUf1X83HzKj VN2RvAV/yPNmAFJqE8eWzidb+i2pnwk83gbnOPRafrf5P8+fSTwq6/bN9pgCjBLcUvPo ASt/dFE9J5D3t8i8efzcMKhUXCzbc4DHyp2x/l+ZBFfpxp8loGUaBRKuY+AVF1qg/NxG qM1g== MIME-Version: 1.0 X-Received: by 10.112.151.5 with SMTP id um5mr3928755lbb.120.1364899324567; Tue, 02 Apr 2013 03:42:04 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.112.27.194 with HTTP; Tue, 2 Apr 2013 03:42:04 -0700 (PDT) In-Reply-To: References: <20130401224601.12673.72208.idtracker@ietfa.amsl.com> Date: Tue, 2 Apr 2013 12:42:04 +0200 X-Google-Sender-Auth: f-0ASkoU_HD_TpH0pCpHibOcpHc Message-ID: Subject: Re: I-D Action: draft-ietf-l3vpn-end-system-01.txt From: Robert Raszuk To: Saku Ytti Content-Type: multipart/alternative; boundary=047d7b3a80e46529cd04d95e634b Cc: L3VPN 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, 02 Apr 2013 10:42:07 -0000 --047d7b3a80e46529cd04d95e634b Content-Type: text/plain; charset=ISO-8859-1 Hi Saku, Let me provide some of my comments ... - External VPN forwarder at page 12 appears not to support QinQ, should it? > Do you have in mind sort of CSC analogy that tenants internally have their own demux based on bottom 802.1Q tag while top one would be used just like a single VLAN tag as described ? - Draft seems IPv4 centric, with static /32 often appearing, while > IPv6 support is explicitly mentioned. > I think you can build IPv6 DC virtualization services while still using IPv4 only DC core. > - Draft mentions GRE and MPLS supported, but most examples speak as if > it's always GRE encapsulated. > It's not clear to me how VPN forwarder would connect via MPLS to a > P or PE node, where would IGP label come. > Or should end-system route server<->PE have OptB? (Would also give > label security, so VPN forwarder would not need to be fully trusted) > The translation happens at the option B ASBR. I would not really run MPLS LDP + IGP or IGP with extension to carry labels or other form of tags in the DC. In fact having high speed IP core which is non blocking should be basic principle of the design. Personally I like Petr's draft: http://tools.ietf.org/html/draft-lapukhov-bgp-routing-large-dc-03 Best, R. --047d7b3a80e46529cd04d95e634b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Saku,

Let me provide some of my comments ...
<= div class=3D"gmail_default" style=3D"font-family:'courier new',mono= space;font-size:small">
- External VPN forwarder at page 12 appears not to support QinQ, should it?=

Do you have in= mind sort of CSC analogy that tenants internally have their own demux base= d on bottom 802.1Q tag =A0while top one would be used just like a single VL= AN tag as described ?


- Draft seems IPv4 centric, with static /32 often appearing, while
IPv6 support is explicitly mentioned.

<= br>
I think you can build IPv6 DC virtual= ization services while still using IPv4 only DC core.


=A0
- Draft mentions GRE and MPLS supported, but most examples speak as if
it's always GRE encapsulated.
=A0 =A0It's not clear to me how VPN forwarder would connect via MPLS to= a
P or PE node, where would IGP label come.
=A0 =A0Or should =A0end-system route server<->PE have OptB? (Would al= so give
label security, so VPN forwarder would not need to be fully trusted)


The tr= anslation happens at the option B ASBR. I would not really run MPLS LDP + I= GP or IGP with extension to carry labels or other form of tags in the DC.= =A0

In fact having hi= gh speed IP core which is non blocking should be basic principle of the des= ign.=A0

Personally I like= Petr's draft:

Best,
R.=





= =A0
--047d7b3a80e46529cd04d95e634b-- From saku@ytti.fi Tue Apr 2 04:48:46 2013 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 DB8EA21F97E1 for ; Tue, 2 Apr 2013 04:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, NO_RELAYS=-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 TbUTG5GVrcgm for ; Tue, 2 Apr 2013 04:48:46 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id DEC1821F97E0 for ; Tue, 2 Apr 2013 04:48:45 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id fs12so291885lab.25 for ; Tue, 02 Apr 2013 04:48:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :x-gm-message-state; bh=0ahpYsIo5kI4jnFM7fXGTuAN5ZUkGegq7HMLiwHCnvc=; b=de5x8X1wfKD3FaBbrSNHBi5ncQMJ64eVjrZyQXnXKH0/Eq8irHaDS41dmIG6/xFDyN E/ZtDZeLI+bdyRnpQLgZajlzofxo/BiSB9RKKRm+aV/ZSfQUCeLyotnYUUDU/E8++Yqz 17Z82SgvyG5ShDWeYju60UmBFYHeALdfjDxRqPd8snyYet7zdCbSxjB/TiFm/lV58t9p d5T7TTRvP/J/hSLxaABWcydJ3mQjzhcPO5VabOiyykE7NdHMvaQ1gg30oHvPuUV4GN4s akSg6tF7FmPohDs7Rpvgm+zIf3wDhBn6JCLb7iE401NfBSn/+WthlukCjo5alKE7Dw/l 4PBw== X-Received: by 10.112.139.7 with SMTP id qu7mr1534719lbb.13.1364903324148; Tue, 02 Apr 2013 04:48:44 -0700 (PDT) Received: from pob.ytti.fi (z.ip.fi. [2001:6e8:288::c]) by mx.google.com with ESMTPS id v7sm651492lbg.13.2013.04.02.04.48.42 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 02 Apr 2013 04:48:43 -0700 (PDT) Date: Tue, 2 Apr 2013 14:48:40 +0300 From: Saku Ytti To: L3VPN Subject: Re: I-D Action: draft-ietf-l3vpn-end-system-01.txt Message-ID: <20130402114840.GA11966@pob.ytti.fi> References: <20130401224601.12673.72208.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQlo+F9Y1oUWROo+REtavf0agkFFUx0hrUVqQT0Zq+KR5NwaYQ6ZJZ97WJ3Mo2aO6Oml4hWv 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, 02 Apr 2013 11:48:47 -0000 On (2013-04-02 12:42 +0200), Robert Raszuk wrote: Hi Robert, > Do you have in mind sort of CSC analogy that tenants internally have their > own demux based on bottom 802.1Q tag while top one would be used just like > a single VLAN tag as described ? I'm thinking if 'VPN forwarder' is catering to many hosts, I might want in L2 to have top tag for host and bottom tag for guest. If XMPP just allows single tag, it may exclude external VPN forwarder or at least limit its scale. But maybe that is intentional, to steer away from external VPN forwarder in large-scale deployments. > I think you can build IPv6 DC virtualization services while still using > IPv4 only DC core. I was just worried as draft specifically allows for IPv6, yet XMPP messages seem to be trailed with /32. I'm personally not interested much in dual-stack control-plane. I'm happy to run 6PE now, and maybe in future go IPv6 only control-plane and 4PE for legacy. But I understand it might not be popular position. > The translation happens at the option B ASBR. I would not really run MPLS > LDP + IGP or IGP with extension to carry labels or other form of tags in > the DC. Fully agreed. I could see myself running this draft, but I would not want to trust 'VPN forwarder' fully, so OptB with appropriate implementation which actually does implement label checking would be requirement for me. > Personally I like Petr's draft: > http://tools.ietf.org/html/draft-lapukhov-bgp-routing-large-dc-03 I'll have to read it, thanks. -- ++ytti From rraszuk@gmail.com Tue Apr 2 05:47:15 2013 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 E518A21F9798 for ; Tue, 2 Apr 2013 05:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 wOrCqLIVLy2z for ; Tue, 2 Apr 2013 05:47:15 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id BDC6A21F9797 for ; Tue, 2 Apr 2013 05:47:14 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id fo13so342861lab.24 for ; Tue, 02 Apr 2013 05:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=iu67QZcQeEBM1bR1CQwGRsXoMo487if0goNVjvWkQtU=; b=w/RCHAzcgHTv4+bBZ1ToPN5ZObdtS9kHD1BFhewkR4dZvY7bmpeUySs7ZG+hnkNYcH 8omz/Xc3R3Nun0YeyHnzukNXGuMREjfHZJ46/XSN+I65Ocz9kFRQ3vWMI9Pz8LRXGg0h Sgwm1+uUVWcr4s9xZZQigahT2MvREe8uiaf1zUMCJmCS2x6/gb4KqN7XNtwSGtjDwfVy NrRqLgtLAbwB9/yfUhCp1ZCFifPe3/YmAlh4YwDase3n4TLLavtF4Qy7ZgeX2HHCMur4 YqFoXpNRJ+dmIQfqFR8mb7O+ydl+SnQfo3LpqlxRhL/zBQ/53SF8BfhJeCji4wrKs70y 2Yiw== MIME-Version: 1.0 X-Received: by 10.152.125.239 with SMTP id mt15mr7741203lab.26.1364906833536; Tue, 02 Apr 2013 05:47:13 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.112.27.194 with HTTP; Tue, 2 Apr 2013 05:47:13 -0700 (PDT) In-Reply-To: <20130402114840.GA11966@pob.ytti.fi> References: <20130401224601.12673.72208.idtracker@ietfa.amsl.com> <20130402114840.GA11966@pob.ytti.fi> Date: Tue, 2 Apr 2013 14:47:13 +0200 X-Google-Sender-Auth: nB6mFcbBBKwA_TF2qHLhhutPFHk Message-ID: Subject: Re: I-D Action: draft-ietf-l3vpn-end-system-01.txt From: Robert Raszuk To: Saku Ytti Content-Type: multipart/alternative; boundary=f46d04426b66f6f0bf04d96022bb Cc: L3VPN 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, 02 Apr 2013 12:47:16 -0000 --f46d04426b66f6f0bf04d96022bb Content-Type: text/plain; charset=ISO-8859-1 Hi Saku, > I'm thinking if 'VPN forwarder' is catering to many hosts, I might want in > L2 to have top tag for host and bottom tag for guest. If XMPP just allows > single tag, it may exclude external VPN forwarder or at least limit its > scale. Oh I see ... it could be a valid case. But I am not sure why in this case we could not just have flat single VLAN tagging for guests between hosts and external VPN forwarder. Would you expect more then 4K (VLAN limit) to be exceeded ? If not I guess there is no good reason for QinQ. In fact if you have QinQ there the semantics of VPN label used by such VPN forwarder would need to include direct demux for both VLAN tags wouldn't it ? Cheers, R. On Tue, Apr 2, 2013 at 1:48 PM, Saku Ytti wrote: > On (2013-04-02 12:42 +0200), Robert Raszuk wrote: > > Hi Robert, > > > Do you have in mind sort of CSC analogy that tenants internally have > their > > own demux based on bottom 802.1Q tag while top one would be used just > like > > a single VLAN tag as described ? > > I'm thinking if 'VPN forwarder' is catering to many hosts, I might want in > L2 to have top tag for host and bottom tag for guest. If XMPP just allows > single tag, it may exclude external VPN forwarder or at least limit its > scale. > But maybe that is intentional, to steer away from external VPN forwarder in > large-scale deployments. > > > I think you can build IPv6 DC virtualization services while still using > > IPv4 only DC core. > > I was just worried as draft specifically allows for IPv6, yet XMPP messages > seem to be trailed with /32. I'm personally not interested much in > dual-stack control-plane. I'm happy to run 6PE now, and maybe in future go > IPv6 only control-plane and 4PE for legacy. But I understand it might not > be popular position. > > > The translation happens at the option B ASBR. I would not really run MPLS > > LDP + IGP or IGP with extension to carry labels or other form of tags in > > the DC. > > Fully agreed. I could see myself running this draft, but I would not want > to trust 'VPN forwarder' fully, so OptB with appropriate implementation > which actually does implement label checking would be requirement for me. > > > Personally I like Petr's draft: > > http://tools.ietf.org/html/draft-lapukhov-bgp-routing-large-dc-03 > > I'll have to read it, thanks. > > -- > ++ytti > --f46d04426b66f6f0bf04d96022bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Saku,

&g= t;=A0I&#= 39;m thinking if 'VPN forwarder' is catering to many hosts, I might= want in
>=A0L2 to have top tag for host and bottom tag for guest. If= XMPP just allows
>=A0single tag, it may exclude external VPN forwarder or at least = limit its
>=A0scale.

Oh I see ..= . it could be a valid case. But I am not sure why in this case we could not= just have flat single VLAN tagging for guests between hosts and external V= PN forwarder. Would you expect more then 4K (VLAN limit) to be exceeded ? I= f not I guess there is no good reason for QinQ.=A0

In fact i= f you have QinQ there the semantics of VPN label used by such VPN forwarder= would need to include direct demux for both VLAN tags wouldn't it ?=A0=

Che= ers,
R.

=



On Tue, Apr 2, 2013 at 1:48 PM, Saku Ytti <saku@ytti.fi> wr= ote:
On (2013-04-02 12:42 +0200), Robert Raszuk w= rote:

Hi Robert,

> Do you have in mind sort of CSC analogy that tenants internally have t= heir
> own demux based on bottom 802.1Q tag =A0while top one would be used ju= st like
> a single VLAN tag as described ?

I'm thinking if 'VPN forwarder' is catering to many hosts= , I might want in
L2 to have top tag for host and bottom tag for guest. If XMPP just allows single tag, it may exclude external VPN forwarder or at least limit its
scale.
But maybe that is intentional, to steer away from external VPN forwarder in=
large-scale deployments.

> I think you can build IPv6 DC virtualization services while still usin= g
> IPv4 only DC core.

I was just worried as draft specifically allows for IPv6, yet XMPP me= ssages
seem to be trailed with /32. I'm personally not interested much in
dual-stack control-plane. I'm happy to run 6PE now, and maybe in future= go
IPv6 only control-plane and 4PE for legacy. But I understand it might not be popular position.

> The translation happens at the option B ASBR. I would not really run M= PLS
> LDP + IGP or IGP with extension to carry labels or other form of tags = in
> the DC.

Fully agreed. I could see myself running this draft, but I would not = want
to trust 'VPN forwarder' fully, so OptB with appropriate implementa= tion
which actually does implement label checking would be requirement for me.

> Personally I like Petr's draft:
> http://tools.ietf.org/html/draft-lapukhov-bgp-rou= ting-large-dc-03

I'll have to read it, thanks.

--
=A0 ++ytti

--f46d04426b66f6f0bf04d96022bb-- From saku@ytti.fi Tue Apr 2 06:12:10 2013 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 3199221F8EC2 for ; Tue, 2 Apr 2013 06:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, NO_RELAYS=-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 Li1fyO2JB7xr for ; Tue, 2 Apr 2013 06:12:09 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6336D21F8EBE for ; Tue, 2 Apr 2013 06:12:09 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id eb20so376632lab.17 for ; Tue, 02 Apr 2013 06:12:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :x-gm-message-state; bh=xXK3V5VzmoL+Zlo+a8rEE1/DsdeyGCsD2jo8tFn0vXI=; b=pljRi0gmD4IFJeDAkSt3LGmmaou4gCVaEax96x9TFp+1fNsLrp69CE9DjhMsLQfSsE YFLKN8pVFFgnxHKSKMJsaRlLwLNge6Y19nNA3YjhDTmB1v/4NVXcLwIELKzWw3Ru/ifC BL6Csk1yauRpeBloYr476LTAurHJH/7dm11xDouH60OW+NMbv6GK+TYE3N/7XfYAXC7s W8ph9ZjYq1nBpGxiGSNWqGxhDcYimjMQQMFKvHLLRcW508G7pABqPkjH4xpoQNYKW2GL dqeLZiJ9AoZAIQHfYtRmtBfLxH8YTkl/E10x4Gv0GwNIFSjUtGFJpIKMiMQkB+8Czf9n 3edw== X-Received: by 10.112.137.74 with SMTP id qg10mr3951086lbb.72.1364908328260; Tue, 02 Apr 2013 06:12:08 -0700 (PDT) Received: from pob.ytti.fi (z.ip.fi. [2001:6e8:288::c]) by mx.google.com with ESMTPS id q9sm775432lbz.3.2013.04.02.06.12.06 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 02 Apr 2013 06:12:07 -0700 (PDT) Date: Tue, 2 Apr 2013 16:12:04 +0300 From: Saku Ytti To: L3VPN Subject: Re: I-D Action: draft-ietf-l3vpn-end-system-01.txt Message-ID: <20130402131204.GA515@pob.ytti.fi> References: <20130401224601.12673.72208.idtracker@ietfa.amsl.com> <20130402114840.GA11966@pob.ytti.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQmknO62RrLQBkmkNaKEak7/elP877J1Ac9DLQRMXo3Ho4MlRdUcj2rbqxbJ6EKk19zoAp1A 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, 02 Apr 2013 13:12:10 -0000 On (2013-04-02 14:47 +0200), Robert Raszuk wrote: > Oh I see ... it could be a valid case. But I am not sure why in this case > we could not just have flat single VLAN tagging for guests between hosts > and external VPN forwarder. Would you expect more then 4K (VLAN limit) to > be exceeded ? If not I guess there is no good reason for QinQ. 4k guests doesn't sounds like particularly large number of guests in external VPN forwarder scenario. Maybe I have 50 hosts with 100 guests each in my L2? > In fact if you have QinQ there the semantics of VPN label used by such VPN > forwarder would need to include direct demux for both VLAN tags wouldn't it Yes. Your server->network lookup key would be two VLANs, result would be label + oif. network->server lookup key would be label, result would be two VLANs + oif. -- ++ytti From rraszuk@gmail.com Tue Apr 2 06:21:26 2013 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 4989721F84F6 for ; Tue, 2 Apr 2013 06:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.726 X-Spam-Level: X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 AlbsqnmxzHgB for ; Tue, 2 Apr 2013 06:21:25 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB3121F84EF for ; Tue, 2 Apr 2013 06:21:25 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id z13so463395lbh.27 for ; Tue, 02 Apr 2013 06:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=v+35oMqX/DYeAVFWwIwgcKmY7ResuOLBueh0NKd+k+k=; b=ehwFpEP6xOCI34IoTXGzTvXCB+nA2r3iOUefiH3/NAd3qIcB6KOqk+6Rvbvc4C/r6C 9mi3GiqFt8mEii/DFTWJDJVNTyWMXvFsECjDFCpWekuX4tKcTnYwFMZEefQf0cG2c1uR AIgL4BZkgtdXKKlzc+XPblx23/Pn6zWtOG6hlm85Z5w4X0sTKxWeDU8LJ204WKLhQtrV Stq4IBy3Vw7P9C2oCVi70vH6UsJxARuKDepUSUuFOwPAH41xvnHOmCu7M2FEahrQOe7N nl/qO9aAbNABQlDvp9hiu9TNhAhn7HMj3qPu4bfhpoRV1m8dsEy00I/+FbVFnVD41xpV RZaA== MIME-Version: 1.0 X-Received: by 10.112.148.196 with SMTP id tu4mr7910600lbb.35.1364908884192; Tue, 02 Apr 2013 06:21:24 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.112.27.194 with HTTP; Tue, 2 Apr 2013 06:21:23 -0700 (PDT) In-Reply-To: <20130402131204.GA515@pob.ytti.fi> References: <20130401224601.12673.72208.idtracker@ietfa.amsl.com> <20130402114840.GA11966@pob.ytti.fi> <20130402131204.GA515@pob.ytti.fi> Date: Tue, 2 Apr 2013 15:21:23 +0200 X-Google-Sender-Auth: LeQlDNewWi49c5i8EWAVf6pcGSc Message-ID: Subject: Re: I-D Action: draft-ietf-l3vpn-end-system-01.txt From: Robert Raszuk To: Saku Ytti Content-Type: multipart/alternative; boundary=047d7b3a8e6231769204d9609d8e Cc: L3VPN 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, 02 Apr 2013 13:21:26 -0000 --047d7b3a8e6231769204d9609d8e Content-Type: text/plain; charset=ISO-8859-1 > > > 4k guests doesn't sounds like particularly large number of guests in > external VPN forwarder scenario. Maybe I have 50 hosts with 100 guests each > in my L2? > > Sure, but my question was would all of them go via single external VPN forwarder ? If you isolate L2 domains between hosts and VPN forwarders you can have obviously much larger DC ... Cheers, R. --047d7b3a8e6231769204d9609d8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

4k guests doesn't sounds like particularly large number of guests= in
external VPN forwarder scenario. Maybe I have 50 hosts with 100 guests each=
in my L2?


Sure, but my question was would all of them go via single externa= l VPN forwarder ? If you isolate L2 domains between hosts and VPN forwarder= s you can have obviously much larger DC ...=A0

Cheers,
R.

--047d7b3a8e6231769204d9609d8e-- From saku@ytti.fi Tue Apr 2 06:49:58 2013 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 B640021F8707 for ; Tue, 2 Apr 2013 06:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, NO_RELAYS=-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 sIBbz6v5LEfF for ; Tue, 2 Apr 2013 06:49:58 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id DE32D21F8700 for ; Tue, 2 Apr 2013 06:49:57 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ec20so403391lab.23 for ; Tue, 02 Apr 2013 06:49:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :x-gm-message-state; bh=HP106kNVkkZCWfMK6826qD43coToyL9rqATF4Bz3itc=; b=SuKbcYF2sPhTPwM+Y6jgXeE/KxeOVQeGOqSaUv/Ncteh4sqc0IpjlNpJEdn2+rhRQf /siczXs5eft1hfW+POHy0jalZKOc6223DVLtDnGIpvCo3HcTpjQs7mbVaIcy9P2UhYCN r0eLljholdJFoaxbPQ1TaZBGfd8JYa/7xPG+XtMcgw0NnlFnzP9uhjKlhyFOl20gK2md s4dlsEfF/d6c1JhE86QFA5Y1krESEaZNpP1K2jpXJgVFyGmM2Wqx6hd0oIhZkAQyqXlW oY67VR8P9mxmUjR6BgvEIThQOCnFvJJcuN/yWdsOqVbWls0mNPrUyapM4zQna16sIJKZ aUuA== X-Received: by 10.112.47.41 with SMTP id a9mr7752494lbn.134.1364910596608; Tue, 02 Apr 2013 06:49:56 -0700 (PDT) Received: from pob.ytti.fi (z.ip.fi. [2001:6e8:288::c]) by mx.google.com with ESMTPS id c7sm822020lbe.6.2013.04.02.06.49.54 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 02 Apr 2013 06:49:55 -0700 (PDT) Date: Tue, 2 Apr 2013 16:49:52 +0300 From: Saku Ytti To: L3VPN Subject: Re: I-D Action: draft-ietf-l3vpn-end-system-01.txt Message-ID: <20130402134952.GA10143@pob.ytti.fi> References: <20130401224601.12673.72208.idtracker@ietfa.amsl.com> <20130402114840.GA11966@pob.ytti.fi> <20130402131204.GA515@pob.ytti.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQlmgw0ZmstbRpE6ILTmHgVimynR8NP7ld8XqI1q+bXzPnpX7yx5FXWUBUFwkVjhoOVX+NmH 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, 02 Apr 2013 13:49:58 -0000 On (2013-04-02 15:21 +0200), Robert Raszuk wrote: > Sure, but my question was would all of them go via single external VPN > forwarder ? If you isolate L2 domains between hosts and VPN forwarders you > can have obviously much larger DC ... I don't know if anyone would wish to cater more than 4k guests via single external VPN forwarder, it just sounds like quite low number to me. But maybe it is sufficient in practical deployments. And I guess green-field would have local VPN forwarder anyhow. -- ++ytti From pedro.r.marques@gmail.com Tue Apr 2 10:57:47 2013 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 1C2E521F8D05 for ; Tue, 2 Apr 2013 10:57:47 -0700 (PDT) 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 wOo5ZigsaKni for ; Tue, 2 Apr 2013 10:57:46 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 9565A21F8D02 for ; Tue, 2 Apr 2013 10:57:46 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id y10so375428pdj.12 for ; Tue, 02 Apr 2013 10:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=KKSAWrluL9UkbMvbjg+i6athCezt2PFPtAhM3dRuZ4o=; b=qEUDg9qi77QLD7Rf2KRsQXXbbjf5N5cvlCbPCaHOBBs6PGJYSKtenV8KUbVyfTIH/c iJaPo5EZq36n2XOrBC0Eyx5e3BxJQODYf8UpOSaOtEkQmOjWtcezkZo5W9FUxJi1PPMp eW/WU3JLmcVaHIQjxz0r/aiis0fBT/2U4FRcBYZX1xcL+nBFSThJFMJ7PBL2orLwqbxX pupIVzOXDf9KqxHyBoDUs53nX6F8y0CpL1tdmLz+WG8LwYisoyzXt1TagpPBkHIXYOoK KSeTgYX5zmOBnCDAYTCcFo7kCBbNjLwecFRIwaie1nUdTD8zrJKn2DS+FGNAEJcu5gko wFeg== X-Received: by 10.68.237.100 with SMTP id vb4mr26043011pbc.202.1364925466219; Tue, 02 Apr 2013 10:57:46 -0700 (PDT) Received: from sa-nc-spg-23.static.jnpr.net (natint3.juniper.net. [66.129.224.36]) by mx.google.com with ESMTPS id gj2sm2548279pbc.25.2013.04.02.10.57.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 10:57:45 -0700 (PDT) Subject: Re: I-D Action: draft-ietf-l3vpn-end-system-01.txt Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Pedro Roque Marques In-Reply-To: Date: Tue, 2 Apr 2013 10:57:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130401224601.12673.72208.idtracker@ietfa.amsl.com> To: Saku Ytti X-Mailer: Apple Mail (2.1283) 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: Tue, 02 Apr 2013 17:57:47 -0000 On Apr 2, 2013, at 2:36 AM, Saku Ytti wrote: > - External VPN forwarder at page 12 appears not to support QinQ, = should it? The document describes the behavior of the end-system and the external = Forwarder. In my mind, the scenario where Q-in-Q (or other L2 encap) is = used between the end-system and the Forwarder because of additional L2 = hops should not need to be explicitly described. >=20 > - Draft seems IPv4 centric, with static /32 often appearing, while > IPv6 support is explicitly mentioned. Searching thought the document /32 seems to appear in examples. If you = don't mind pointing out explicitly where you believe the text should be = corrected, i would appreciated (private email is ok). >=20 > - Draft mentions GRE and MPLS supported, but most examples speak as if > it's always GRE encapsulated. MPLS over GRE or MPLS over UDP are used currently. MPLS over ethernet = directly would require the end-system to participate in the IGP and have = LDP enabled which is not to my knowledge a practical scenario. > It's not clear to me how VPN forwarder would connect via MPLS to a > P or PE node, where would IGP label come. > Or should end-system route server<->PE have OptB? (Would also give > label security, so VPN forwarder would not need to be fully trusted) The route-server is not on the forwarding path. The data-center gateway typically implements option B (or IBGP plus = next-hop self) and stitches the MPLS-over-GRE LSP segment (internal to = the DC) with an MPLS over L2 LSP segment outside the data-center, in = scenarios where the service is delivered to a WAN L3VPN. >=20 >=20 >=20 > On 2 April 2013 01:46, wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Layer 3 Virtual Private Networks = Working Group of the IETF. >>=20 >> Title : BGP-signaled end-system IP/VPNs. >> Author(s) : Pedro Marques >> Luyuan Fang >> Ping Pan >> Amit Shukla >> Maria Napierala >> Nabil Bitar >> Filename : draft-ietf-l3vpn-end-system-01.txt >> Pages : 21 >> Date : 2013-04-01 >>=20 >> Abstract: >> This document describes a solution in which the control plane >> protocol specified in BGP/MPLS IP VPNs [RFC4364] is used to provide = a >> Virtual Network service to end-systems. These end-systems may be >> used to provide network services or may directly host end-to-end >> applications. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-l3vpn-end-system >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-01 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l3vpn-end-system-01 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >=20 >=20 >=20 > --=20 > ++ytti From saku@ytti.fi Tue Apr 2 23:10:55 2013 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 71B2321F86BA for ; Tue, 2 Apr 2013 23:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-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 r6W+TuhudQdq for ; Tue, 2 Apr 2013 23:10:55 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A835221F85CB for ; Tue, 2 Apr 2013 23:10:54 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ek20so1102338lab.30 for ; Tue, 02 Apr 2013 23:10:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :x-gm-message-state; bh=jKnI99IVaOzHu2WecDHx0rM4bQMWIu9wNiyLqjUanN8=; b=DWC0XZ35XpQLvkScKrQE7YuOBGReLEe/G9OxrqCek32Kd57NaxasrXyj7GYJ2N9XXk GQefFEpr7hbIsVTqQ6pcEAYZxh523NNS528Tnm7Csv9pzC0xAlDD4NK3O+bk9iZgLTcI IXAe+iYYHmzaBqe69+QTg4C2quWUcP6S3ZndykcSuH2wUKm8X4WESpb7PEHTw52deySA rWTEQduiWogTQ44jc435B64B72L7l1Mzk7+rN/FhPyD0ZOQ70NVvBRMigBCqphdB61wM fdzufksNRqHVLxRmD9BTZPx52z3Vu/DM781tSGkN9MrrPkimQoYQTtkTINjPAC8VY4iD WVlQ== X-Received: by 10.152.46.17 with SMTP id r17mr168491lam.47.1364969453242; Tue, 02 Apr 2013 23:10:53 -0700 (PDT) Received: from pob.ytti.fi (z.ip.fi. [2001:6e8:288::c]) by mx.google.com with ESMTPS id p1sm337174lbp.8.2013.04.02.23.10.51 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 02 Apr 2013 23:10:52 -0700 (PDT) Date: Wed, 3 Apr 2013 09:10:49 +0300 From: Saku Ytti To: l3vpn@ietf.org Subject: Re: I-D Action: draft-ietf-l3vpn-end-system-01.txt Message-ID: <20130403061049.GA22991@pob.ytti.fi> References: <20130401224601.12673.72208.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQl3TZU0s7ThxENKm0YxnsV/LdeqoXuJIiNQhwgmwZfPiZ8L9yEdAkaVbhfZ/QdGwILqdpoT 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, 03 Apr 2013 06:10:55 -0000 On (2013-04-02 10:57 -0700), Pedro Roque Marques wrote: > The document describes the behavior of the end-system and the external > Forwarder. In my mind, the scenario where Q-in-Q (or other L2 encap) is > used between the end-system and the Forwarder because of additional L2 > hops should not need to be explicitly described. I don't understand. Are you saying even if host would double tag, that would not be relevant to Forwarder? Looking at page 12 I don't know how to signal two tags to Forwarder. > Searching thought the document /32 seems to appear in examples. If you > don't mind pointing out explicitly where you believe the text should be I'm probably reading it wrong, page 13, request 2, associate node is one that caught my eye. > The route-server is not on the forwarding path. I was thinking native MPLS-to-the-edge in DC, where I only have VPN Forwarder between my host and core MPLS PE (preferably right in the host as 'virtual router'). Then if I'd use OptB, I'd need to collapse route-server and VPN forwarder into same box? > The data-center gateway typically implements option B (or IBGP plus > next-hop self) and stitches the MPLS-over-GRE LSP segment (internal to > the DC) with an MPLS over L2 LSP segment outside the data-center, in > scenarios where the service is delivered to a WAN L3VPN. Would this be true for green-field as well? I'd really love to see solution where I can plug host anywhere in MPLS network. -- ++ytti From internet-drafts@ietf.org Fri Apr 5 07:41:39 2013 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 18BCB21F97F3; Fri, 5 Apr 2013 07:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.145, 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 NlpV4Pp+1q1s; Fri, 5 Apr 2013 07:41:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 860EC21F97E0; Fri, 5 Apr 2013 07:41:38 -0700 (PDT) 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-virtual-hub-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p3 Message-ID: <20130405144138.6327.20888.idtracker@ietfa.amsl.com> Date: Fri, 05 Apr 2013 07:41:38 -0700 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: Fri, 05 Apr 2013 14:41:39 -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 Working = Group of the IETF. Title : Virtual Hub-and-Spoke in BGP/MPLS VPNs Author(s) : Huajin Jeng James Uttaro Luay Jalil Bruno Decraene Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-l3vpn-virtual-hub-05.txt Pages : 26 Date : 2013-04-05 Abstract: With BGP/MPLS VPNs any-to-any connectivity among sites of a given Virtual Private Network would require each Provider Edge router that has one or more of these sites connected to it to hold all the routes of that Virtual Private Network. The approach described in this document allows to reduce the number of Provider Edge routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes. Furthermore, when Provider Edge routers use ingress replication to carry multicast traffic of VPN customers, the approach described in this document may under certain circumstances allow to reduce bandwidth inefficiency associated with ingress replication, and to redistribute the replication load among Provider Edge routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-virtual-hub There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-virtual-hub-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l3vpn-virtual-hub-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From thomas.morin@orange.com Mon Apr 8 07:38:07 2013 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 AC3F021F97EB; Mon, 8 Apr 2013 07:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.569 X-Spam-Level: **** X-Spam-Status: No, score=4.569 tagged_above=-999 required=5 tests=[AWL=6.567, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=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 thaiPfprBVr1; Mon, 8 Apr 2013 07:38:06 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3C221F97EF; Mon, 8 Apr 2013 07:38:06 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 7761D3B4110; Mon, 8 Apr 2013 16:38:05 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 5412135C055; Mon, 8 Apr 2013 16:38:05 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Mon, 8 Apr 2013 16:38:05 +0200 From: To: "iesg-secretary@ietf.org" Subject: Request for publication of draft-ietf-l3vpn-virtual-hub Thread-Topic: Request for publication of draft-ietf-l3vpn-virtual-hub Thread-Index: AQHONGatZpTRTcxHpUOPe9ovrbYRUg== Date: Mon, 8 Apr 2013 14:38:04 +0000 Message-ID: <13538_1365431885_5162D64D_13538_3744_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D07326127@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 x-originating-ip: [10.197.38.5] Content-Type: multipart/mixed; boundary="_002_AC1ADC68A92CF94FA8CFCB406C1CBE3D07326127PEXCVZYM13corpo_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.8.120326 Cc: "draft-ietf-l3vpn-virtual-hub@tools.ietf.org" , L3VPN Chairs , L3VPN , Stewart Bryant 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, 08 Apr 2013 14:38:07 -0000 --_002_AC1ADC68A92CF94FA8CFCB406C1CBE3D07326127PEXCVZYM13corpo_ Content-Type: text/plain; charset="utf-8" Content-ID: <9A9209EAC46946488E6A784F1F86E944@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 SUVTRywNCg0KVGhlIEwzVlBOIFdHIHJlcXVlc3RzIHRoYXQgZHJhZnQtaWV0Zi1sM3Zwbi12aXJ0 dWFsLWh1Yi0wNSBiZSBwdWJsaXNoZWQgDQphcyBhbiBSRkMgb24gdGhlIFN0YW5kYXJkIHRyYWNr Lg0KDQpUaGUgc2hlcGhlcmQgd3JpdGUtdXAgaXMgaW4gdGhlIGRhdGF0YWNrZXIsIGFuZCAgaW5j bHVkZWQgaGVyZSBhcyB3ZWxsLg0KDQpUaGFuayB5b3UsDQoNCi1UaG9tYXMgTW9yaW4gZm9yIHRo ZSBMM1ZQTiBXRw0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApGcmFuY2UgVGVsZWNvbSAtIE9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRo YW5rIHlvdS4KCg== --_002_AC1ADC68A92CF94FA8CFCB406C1CBE3D07326127PEXCVZYM13corpo_ Content-Type: text/plain; name="draft-ietf-l3vpn-virtual-hub-writeup.txt" Content-Description: draft-ietf-l3vpn-virtual-hub-writeup.txt Content-Disposition: attachment; filename="draft-ietf-l3vpn-virtual-hub-writeup.txt"; size=8243; creation-date="Mon, 08 Apr 2013 14:38:04 GMT"; modification-date="Mon, 08 Apr 2013 14:38:04 GMT" Content-ID: Content-Transfer-Encoding: base64 KDEpIFdoYXQgdHlwZSBvZiBSRkMgaXMgYmVpbmcgcmVxdWVzdGVkIChCQ1AsIFByb3Bvc2VkIFN0 YW5kYXJkLCBJbnRlcm5ldCBTdGFuZGFyZCwgSW5mb3JtYXRpb25hbCwgRXhwZXJpbWVudGFsLCBv ciBIaXN0b3JpYyk/IFdoeSBpcyB0aGlzIHRoZSBwcm9wZXIgdHlwZSBvZiBSRkM/IElzIHRoaXMg dHlwZSBvZiBSRkMgaW5kaWNhdGVkIGluIHRoZSB0aXRsZSBwYWdlIGhlYWRlcj8KClN0YW5kYXJk IHRyYWNrIGlzIHJlcXVlc3RlZCBpbiB0aGUgZG9jdW1lbnQgaGVhZGVyLCBhbmQgaXMgdGhlIHBy b3BlciB0eXBlIG9mIFJGQyBzaW5jZSB0aGUgZG9jdW1lbnQgZGVmaW5lcyBzcGVjaWZpYyBiZWhh dmlvciB0aGF0IG11c3QgYmUgaW1wbGVtZW50ZWQgYnkgcm91dGVycyBpbiBhIGNvbnNpc3RlbnQg bWFubmVyIHRvIGFjaGlldmUgdGhlIGdvYWwuCgooMikgVGhlIElFU0cgYXBwcm92YWwgYW5ub3Vu Y2VtZW50IGluY2x1ZGVzIGEgRG9jdW1lbnQgQW5ub3VuY2VtZW50IFdyaXRlLVVwLiBQbGVhc2Ug cHJvdmlkZSBzdWNoIGEgRG9jdW1lbnQgQW5ub3VuY2VtZW50IFdyaXRlLVVwLiBSZWNlbnQgZXhh bXBsZXMgY2FuIGJlIGZvdW5kIGluIHRoZSAiQWN0aW9uIiBhbm5vdW5jZW1lbnRzIGZvciBhcHBy b3ZlZCBkb2N1bWVudHMuIFRoZSBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgY29udGFpbnMgdGhlIGZv bGxvd2luZyBzZWN0aW9uczoKCi0gVGVjaG5pY2FsIFN1bW1hcnk6CgpXaXRoIEJHUC9NUExTIFZQ TnMgYW55LXRvLWFueSBjb25uZWN0aXZpdHkgYW1vbmcgc2l0ZXMgb2YgYSBnaXZlbiBWaXJ0dWFs IFByaXZhdGUgTmV0d29yayB3b3VsZCByZXF1aXJlIGVhY2ggUHJvdmlkZXIgRWRnZSByb3V0ZXIg dGhhdCBoYXMgb25lIG9yIG1vcmUgb2YgdGhlc2Ugc2l0ZXMgY29ubmVjdGVkIHRvIGl0IHRvIGhv bGQgYWxsIHRoZSByb3V0ZXMgb2YgdGhhdCBWaXJ0dWFsIFByaXZhdGUgTmV0d29yay4gVGhlIGFw cHJvYWNoIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGFsbG93cyB0byByZWR1Y2UgdGhlIG51 bWJlciBvZiBQcm92aWRlciBFZGdlIHJvdXRlcnMgdGhhdCBoYXZlIHRvIG1haW50YWluIGFsbCB0 aGVzZSByb3V0ZXMgYnkgcmVxdWlyaW5nIG9ubHkgYSBzdWJzZXQgb2YgdGhlc2Ugcm91dGVycyB0 byBtYWludGFpbiBhbGwgdGhlc2Ugcm91dGVzLgpGdXJ0aGVybW9yZSwgd2hlbiBQcm92aWRlciBF ZGdlIHJvdXRlcnMgdXNlIGluZ3Jlc3MgcmVwbGljYXRpb24gdG8gY2FycnkgbXVsdGljYXN0IHRy YWZmaWMgb2YgVlBOIGN1c3RvbWVycywgdGhlIGFwcHJvYWNoIGRlc2NyaWJlZCBpbiB0aGlzIGRv Y3VtZW50IG1heSB1bmRlciBjZXJ0YWluIGNpcmN1bXN0YW5jZXMgYWxsb3cgdG8gcmVkdWNlIGJh bmR3aWR0aCBpbmVmZmljaWVuY3kgYXNzb2NpYXRlZCB3aXRoIGluZ3Jlc3MgcmVwbGljYXRpb24s IGFuZCB0byByZWRpc3RyaWJ1dGUgdGhlIHJlcGxpY2F0aW9uIGxvYWQgYW1vbmcgUHJvdmlkZXIg RWRnZSByb3V0ZXJzLgoKLSBXb3JraW5nIEdyb3VwIFN1bW1hcnk6CgpOb3RoaW5nIHBhcnRpY3Vs YXIgKG5vIG9iamVjdGlvbiBmcm9tIHdvcmtpbmcgZ3JvdXAgY29udHJpYnV0b3JzIGR1cmluZyBh ZG9wdGlvbiwgbm90IHJlYWwgb2JqZWN0aW9uIGR1cmluZyBXR0xDLCBleGNlcHQgZm9yIG9uZSBj b21tZW50IGNoYWxsZW5naW5nIHRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQgYnV0IHdpdGhvdXQg YSBmb2xsb3ctdXAgZnJvbSB0aGUgY29tbWVudGVyKS4KCi0gRG9jdW1lbnQgUXVhbGl0eToKClRo ZXJlIGFyZSBubyBjb25jZXJucyBhYm91dCB0aGUgZG9jdW1lbnQgcXVhbGl0eS4gQW4gZXh0ZW5z aXZlIHJldmlldyB3YXMgZG9uZSBvbiBXR0xDIGJ5IEVyaWMgUm9zZW4gKGNvLWF1dGhvciBvZiBC R1AvTVBMUyBzcGVjaWZpY2F0aW9ucyB0byB3aGljaCB0aGVzZSBzcGVjaWZpY2F0aW9ucyByZWxh dGUpLCB3aGljaCB3ZXJlIHJlc29sdmVkIGFmdGVyIHN1YnN0YW50aXZlIGNoYW5nZXMgdG8gdGhl IGRvY3VtZW50LgpObyBpbmZvcm1hdGlvbiBoYXMgYmVlbiBwcm92aWRlZCByZWxhdGVkIHRvIGN1 cnJlbnQgaW1wbGVtZW50YXRpb25zIG9yIHBsYW5zIGZvciBpbXBsZW1lbnRhdGlvbnMuCgotIFBl cnNvbm5lbDoKCkRvY3VtZW50IFNoZXBoZXJkIGlzIFRob21hcyBNb3JpbiBhcyBsM3ZwbiBXRyBj by1jaGFpciwgYW5kIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IgaXMgU3Rld2FydCBCcnlhbnQu CgooMykgQnJpZWZseSBkZXNjcmliZSB0aGUgcmV2aWV3IG9mIHRoaXMgZG9jdW1lbnQgdGhhdCB3 YXMgcGVyZm9ybWVkIGJ5IHRoZSBEb2N1bWVudCBTaGVwaGVyZC4gSWYgdGhpcyB2ZXJzaW9uIG9m IHRoZSBkb2N1bWVudCBpcyBub3QgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBwbGVhc2UgZXhwbGFp biB3aHkgdGhlIGRvY3VtZW50IGlzIGJlaW5nIGZvcndhcmRlZCB0byB0aGUgSUVTRy4KClRoZSBk b2N1bWVudCBTaGVwaGVyZCBkaWQgYSBjb21wbGV0ZSByZXZpZXcgb2YgdGhlIGRvY3VtZW50LCBi b3RoIGVkaXRvcmlhbCBhbmQgdGVjaG5pY2FsIGNvbmNsdWRpbmcgdGhhdCB0aGUgZG9jdW1lbnQg cXVhbGl0eSBpcyB2ZXJ5IGdvb2QgZnJvbSBhbmQgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkg Zm9yIHB1YmxpY2F0aW9uLiBBIGZldyBwb2ludHMgcHJvYmFibHkgZGVzZXJ2aW5nIGVkaXRvcmlh bCBjbGFyaWZpY2F0aW9ucyB3ZXJlIG5vdGVkLCB3aGljaCBjYW4gYmUgYWRkcmVzc2VkIGR1cmlu ZyBuZXh0IHN0ZXBzIGluIHRoZSBwdWJsaWNhdGlvbiBwcm9jZXNzLgoKKDQpIERvZXMgdGhlIGRv Y3VtZW50IFNoZXBoZXJkIGhhdmUgYW55IGNvbmNlcm5zIGFib3V0IHRoZSBkZXB0aCBvciBicmVh ZHRoIG9mIHRoZSByZXZpZXdzIHRoYXQgaGF2ZSBiZWVuIHBlcmZvcm1lZD8KCk5vIGNvbmNlcm5z LgoKKDUpIERvIHBvcnRpb25zIG9mIHRoZSBkb2N1bWVudCBuZWVkIHJldmlldyBmcm9tIGEgcGFy dGljdWxhciBvciBmcm9tIGJyb2FkZXIgcGVyc3BlY3RpdmUsIGUuZy4sIHNlY3VyaXR5LCBvcGVy YXRpb25hbCBjb21wbGV4aXR5LCBBQUEsIEROUywgREhDUCwgWE1MLCBvciBpbnRlcm5hdGlvbmFs aXphdGlvbj8gSWYgc28sIGRlc2NyaWJlIHRoZSByZXZpZXcgdGhhdCB0b29rIHBsYWNlLgoKTm9u ZSBvZiB0aGUgYWJvdmUgYXBwbGllcywgQUZBSUNULgoKKDYpIERlc2NyaWJlIGFueSBzcGVjaWZp YyBjb25jZXJucyBvciBpc3N1ZXMgdGhhdCB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgaGFzIHdpdGgg dGhpcyBkb2N1bWVudCB0aGF0IHRoZSBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yIGFuZC9vciB0 aGUgSUVTRyBzaG91bGQgYmUgYXdhcmUgb2Y/IEZvciBleGFtcGxlLCBwZXJoYXBzIGhlIG9yIHNo ZSBpcyB1bmNvbWZvcnRhYmxlIHdpdGggY2VydGFpbiBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQsIG9y IGhhcyBjb25jZXJucyB3aGV0aGVyIHRoZXJlIHJlYWxseSBpcyBhIG5lZWQgZm9yIGl0LiBJbiBh bnkgZXZlbnQsIGlmIHRoZSBXRyBoYXMgZGlzY3Vzc2VkIHRob3NlIGlzc3VlcyBhbmQgaGFzIGlu ZGljYXRlZCB0aGF0IGl0IHN0aWxsIHdpc2hlcyB0byBhZHZhbmNlIHRoZSBkb2N1bWVudCwgZGV0 YWlsIHRob3NlIGNvbmNlcm5zIGhlcmUuCgpUaGVyZSB3YXMgb25lIGNvbW1lbnQgYnkgUm9iZXJ0 IFJhc3p1ayBkdXJpbmcgV0dMQyBjbGFpbWluZyB0aGF0IHRoZXNlIHNwZWNpZmljYXRpb25zIHNo b3VsZCBiZSBleHRlbmRlZCAidG8gYWNjb21vZGF0ZSBldmVuIGZ1cnRoZXIgc2NhbGluZyBlbmhh bmNlbWVudHMgbm90IGp1c3QgZm9yIFNQIFBFcyBidXQgYWxzbyBmb3IgYWN0dWFsIGN1c3RvbWVy IFZQTiBzaXRlcy4iLiBIb3dldmVyLCB0aGUgY29tbWVudGVyIGRpZCBub3QgYWR2ZXJ0aXNlIGFu IGludGVudCB0byBhY3R1YWxseSBjb250cmlidXRlIHN1Y2ggYW4gZXh0ZW5zaW9uLCBhbmQgZWl0 aGVyIHdheSB0aGUgcHVibGljYXRpb24gb2YgdGhlIGRvY3VtZW50IGFzLWlzIHdvdWxkIG5vdCBw cmV2ZW50IHN1Y2ggYSBwcm9wb3NhbCB0byBiZSBwdXJzdWVkIGxhdGVyLgoKKDcpIEhhcyBlYWNo IGF1dGhvciBjb25maXJtZWQgdGhhdCBhbnkgYW5kIGFsbCBhcHByb3ByaWF0ZSBJUFIgZGlzY2xv c3VyZXMgcmVxdWlyZWQgZm9yIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUgcHJvdmlzaW9ucyBv ZiBCQ1AgNzggYW5kIEJDUCA3OSBoYXZlIGFscmVhZHkgYmVlbiBmaWxlZC4gSWYgbm90LCBleHBs YWluIHdoeT8KClllcywgYWxsIGF1dGhvcnMgaGF2ZSBjb25maXJtZWQgc28uCgooOCkgSGFzIGFu IElQUiBkaXNjbG9zdXJlIGJlZW4gZmlsZWQgdGhhdCByZWZlcmVuY2VzIHRoaXMgZG9jdW1lbnQ/ IElmIHNvLCBzdW1tYXJpemUgYW55IFdHIGRpc2N1c3Npb24gYW5kIGNvbmNsdXNpb24gcmVnYXJk aW5nIHRoZSBJUFIgZGlzY2xvc3VyZXMuCgpObyBJUFIgZGlzY2xvc3VyZSB3YXMgZmlsZWQgcmVs YXRpbmcgdG8gdGhpcyBkb2N1bWVudC4KCig5KSBIb3cgc29saWQgaXMgdGhlIFdHIGNvbnNlbnN1 cyBiZWhpbmQgdGhpcyBkb2N1bWVudD8gRG9lcyBpdCByZXByZXNlbnQgdGhlIHN0cm9uZyBjb25j dXJyZW5jZSBvZiBhIGZldyBpbmRpdmlkdWFscywgd2l0aCBvdGhlcnMgYmVpbmcgc2lsZW50LCBv ciBkb2VzIHRoZSBXRyBhcyBhIHdob2xlIHVuZGVyc3RhbmQgYW5kIGFncmVlIHdpdGggaXQ/CgpC ZXlvbmQgY28tYXV0aG9ycywgYSBzaWduaWZpY2FudCBudW1iZXIgb2YgcGVvcGxlIGV4cHJlc3Nl ZCBpbnRlcmVzdCBvbiB0aGUgcHJvcG9zYWwsIGluY2x1ZGluZyBib3RoIHZlbmRvcnMgYW5kIG9w ZXJhdG9ycy4KCigxMCkgSGFzIGFueW9uZSB0aHJlYXRlbmVkIGFuIGFwcGVhbCBvciBvdGhlcndp c2UgaW5kaWNhdGVkIGV4dHJlbWUgZGlzY29udGVudD8gSWYgc28sIHBsZWFzZSBzdW1tYXJpc2Ug dGhlIGFyZWFzIG9mIGNvbmZsaWN0IGluIHNlcGFyYXRlIGVtYWlsIG1lc3NhZ2VzIHRvIHRoZSBS ZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yLiAoSXQgc2hvdWxkIGJlIGluIGEgc2VwYXJhdGUgZW1h aWwgYmVjYXVzZSB0aGlzIHF1ZXN0aW9ubmFpcmUgaXMgcHVibGljbHkgYXZhaWxhYmxlLikKCk5v LgoKKDExKSBJZGVudGlmeSBhbnkgSUQgbml0cyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgaGFzIGZv dW5kIGluIHRoaXMgZG9jdW1lbnQuIChTZWUgaHR0cDovL3d3dy5pZXRmLm9yZy90b29scy9pZG5p dHMvIGFuZCB0aGUgSW50ZXJuZXQtRHJhZnRzIENoZWNrbGlzdCkuIEJvaWxlcnBsYXRlIGNoZWNr cyBhcmUgbm90IGVub3VnaDsgdGhpcyBjaGVjayBuZWVkcyB0byBiZSB0aG9yb3VnaC4KCgpTb21l IGlzc3VlcyBmb3VuZCB3aXRoIGlkbml0cyAyLjEyLjE1IDoKLSB1c2Ugb2YgUkZDMTkxOCBhZGRy ZXNzZXM6IGFzIGV4YW1wbGVzIGluIHRoaXMgZG9jdW1lbnQsIHRoZXkgc2VlbSBsZWdpdGltYXRl IHNpbmNlIG5ldHdvcmtzIHJlcHJlc2VudGVkIGFyZSBWaXJ0dWFsIFByaXZhdGUgTmV0d29ya3MK LSB0aGUgY29weXJpZ2h0IHllYXIgaW4gdGhlIElFVEYgVHJ1c3QgYW5kIGF1dGhvcnMgQ29weXJp Z2h0IExpbmUgZG9lcyBub3QgbWF0Y2ggdGhlIGN1cnJlbnQgeWVhciA9PiBmaXggbmVlZGVkCi0g aWRuaXRzIHRoaW5rcyB0aGF0ICInaGUgZG9jdW1lbnQgZGF0ZSAoTWF5IDIwMTIpIGlzIDMxMCBk YXlzIGluIHRoZSBwYXN0IiwgYnV0IHRoaXMgaXMgYSBwYXJzaW5nIGVycm9yLCB0aGUgZG9jdW1l bnQgZGF0ZSAoRGVjIDEyIDIwMTIpIGlzIGxlc3MgdGhhbiA0IG1vbnRoIGFnby4KLSBpZG5pdHMg ZmluZHMgdHdvIG1pc3NpbmcgcmVmZXJlbmNlczogJ1JGQzIxMTknIG9uIGxpbmUgMTEyLCBhbmQg J0lBTkEtU0FGSScgb24gbGluZSA2NDIgKG9mIC0wNCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCkgPT4g Zml4IG5lZWRlZAoKKDEyKSBEZXNjcmliZSBob3cgdGhlIGRvY3VtZW50IG1lZXRzIGFueSByZXF1 aXJlZCBmb3JtYWwgcmV2aWV3IGNyaXRlcmlhLCBzdWNoIGFzIHRoZSBNSUIgRG9jdG9yLCBtZWRp YSB0eXBlLCBhbmQgVVJJIHR5cGUgcmV2aWV3cy4KCk4vQQoKKDEzKSBIYXZlIGFsbCByZWZlcmVu Y2VzIHdpdGhpbiB0aGlzIGRvY3VtZW50IGJlZW4gaWRlbnRpZmllZCBhcyBlaXRoZXIgbm9ybWF0 aXZlIG9yIGluZm9ybWF0aXZlPwoKWWVzLgoKKDE0KSBBcmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVy ZW5jZXMgdG8gZG9jdW1lbnRzIHRoYXQgYXJlIG5vdCByZWFkeSBmb3IgYWR2YW5jZW1lbnQgb3Ig YXJlIG90aGVyd2lzZSBpbiBhbiB1bmNsZWFyIHN0YXRlPyBJZiBzdWNoIG5vcm1hdGl2ZSByZWZl cmVuY2VzIGV4aXN0LCB3aGF0IGlzIHRoZSBwbGFuIGZvciB0aGVpciBjb21wbGV0aW9uPwoKTm8s IGFsbCBub3JtYXRpdmUgcmVmZXJlbmNlcyBhcmUgYWxyZWFkeSBwdWJsaXNoZWQgYXMgUkZDcy4K CigxNSkgQXJlIHRoZXJlIGRvd253YXJkIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHJlZmVyZW5jZXMg KHNlZSBSRkMgMzk2Nyk/IElmIHNvLCBsaXN0IHRoZXNlIGRvd253YXJkIHJlZmVyZW5jZXMgdG8g c3VwcG9ydCB0aGUgQXJlYSBEaXJlY3RvciBpbiB0aGUgTGFzdCBDYWxsIHByb2NlZHVyZS4KCk5v LCBhbGwgbm9ybWF0aXZlIHJlZmVyZW5jZXMgb2YgdGhpcyBkb2N1bWVudCBhcmUgUFJPUE9TRUQg U1RBTkRBUkQgb3IgQkNQIFJGQ3MuCgooMTYpIFdpbGwgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1 bWVudCBjaGFuZ2UgdGhlIHN0YXR1cyBvZiBhbnkgZXhpc3RpbmcgUkZDcz8gQXJlIHRob3NlIFJG Q3MgbGlzdGVkIG9uIHRoZSB0aXRsZSBwYWdlIGhlYWRlciwgbGlzdGVkIGluIHRoZSBhYnN0cmFj dCwgYW5kIGRpc2N1c3NlZCBpbiB0aGUgaW50cm9kdWN0aW9uPyBJZiB0aGUgUkZDcyBhcmUgbm90 IGxpc3RlZCBpbiB0aGUgQWJzdHJhY3QgYW5kIEludHJvZHVjdGlvbiwgZXhwbGFpbiB3aHksIGFu ZCBwb2ludCB0byB0aGUgcGFydCBvZiB0aGUgZG9jdW1lbnQgd2hlcmUgdGhlIHJlbGF0aW9uc2hp cCBvZiB0aGlzIGRvY3VtZW50IHRvIHRoZSBvdGhlciBSRkNzIGlzIGRpc2N1c3NlZC4gSWYgdGhp cyBpbmZvcm1hdGlvbiBpcyBub3QgaW4gdGhlIGRvY3VtZW50LCBleHBsYWluIHdoeSB0aGUgV0cg Y29uc2lkZXJzIGl0IHVubmVjZXNzYXJ5LgoKTm8uCgooMTcpIERlc2NyaWJlIHRoZSBEb2N1bWVu dCBTaGVwaGVyZCdzIHJldmlldyBvZiB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBl c3BlY2lhbGx5IHdpdGggcmVnYXJkIHRvIGl0cyBjb25zaXN0ZW5jeSB3aXRoIHRoZSBib2R5IG9m IHRoZSBkb2N1bWVudC4gQ29uZmlybSB0aGF0IGFsbCBwcm90b2NvbCBleHRlbnNpb25zIHRoYXQg dGhlIGRvY3VtZW50IG1ha2VzIGFyZSBhc3NvY2lhdGVkIHdpdGggdGhlIGFwcHJvcHJpYXRlIHJl c2VydmF0aW9ucyBpbiBJQU5BIHJlZ2lzdHJpZXMuIENvbmZpcm0gdGhhdCBhbnkgcmVmZXJlbmNl ZCBJQU5BIHJlZ2lzdHJpZXMgaGF2ZSBiZWVuIGNsZWFybHkgaWRlbnRpZmllZC4gQ29uZmlybSB0 aGF0IG5ld2x5IGNyZWF0ZWQgSUFOQSByZWdpc3RyaWVzIGluY2x1ZGUgYSBkZXRhaWxlZCBzcGVj aWZpY2F0aW9uIG9mIHRoZSBpbml0aWFsIGNvbnRlbnRzIGZvciB0aGUgcmVnaXN0cnksIHRoYXQg YWxsb2NhdGlvbnMgcHJvY2VkdXJlcyBmb3IgZnV0dXJlIHJlZ2lzdHJhdGlvbnMgYXJlIGRlZmlu ZWQsIGFuZCBhIHJlYXNvbmFibGUgbmFtZSBmb3IgdGhlIG5ldyByZWdpc3RyeSBoYXMgYmVlbiBz dWdnZXN0ZWQgKHNlZSBSRkMgNTIyNikuCgpOL0EgKFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyBu byBuZXcgSUFOQSBDb25zaWRlcmF0aW9ucykKCigxOCkgTGlzdCBhbnkgbmV3IElBTkEgcmVnaXN0 cmllcyB0aGF0IHJlcXVpcmUgRXhwZXJ0IFJldmlldyBmb3IgZnV0dXJlIGFsbG9jYXRpb25zLiBQ cm92aWRlIGFueSBwdWJsaWMgZ3VpZGFuY2UgdGhhdCB0aGUgSUVTRyB3b3VsZCBmaW5kIHVzZWZ1 bCBpbiBzZWxlY3RpbmcgdGhlIElBTkEgRXhwZXJ0cyBmb3IgdGhlc2UgbmV3IHJlZ2lzdHJpZXMu CgpOL0EgKHRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyBubyBuZXcgSUFOQSBDb25zaWRlcmF0aW9u cykKCigxOSkgRGVzY3JpYmUgcmV2aWV3cyBhbmQgYXV0b21hdGVkIGNoZWNrcyBwZXJmb3JtZWQg YnkgdGhlIERvY3VtZW50IFNoZXBoZXJkIHRvIHZhbGlkYXRlIHNlY3Rpb25zIG9mIHRoZSBkb2N1 bWVudCB3cml0dGVuIGluIGEgZm9ybWFsIGxhbmd1YWdlLCBzdWNoIGFzIFhNTCBjb2RlLCBCTkYg cnVsZXMsIE1JQiBkZWZpbml0aW9ucywgZXRjLgoKTi9BIAo= --_002_AC1ADC68A92CF94FA8CFCB406C1CBE3D07326127PEXCVZYM13corpo_-- From wesley.george@twcable.com Mon Apr 8 11:38:19 2013 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 6B81021F9410 for ; Mon, 8 Apr 2013 11:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.329 X-Spam-Level: X-Spam-Status: No, score=-0.329 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 paK2440eqQ9z for ; Mon, 8 Apr 2013 11:38:19 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id D997021F93C4 for ; Mon, 8 Apr 2013 11:38:18 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.87,432,1363147200"; d="scan'208";a="53886415" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 08 Apr 2013 14:37:29 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Mon, 8 Apr 2013 14:38:18 -0400 From: "George, Wes" To: Saku Ytti , L3VPN Date: Mon, 8 Apr 2013 14:38:16 -0400 Subject: RE: I-D Action: draft-ietf-l3vpn-end-system-01.txt Thread-Topic: I-D Action: draft-ietf-l3vpn-end-system-01.txt Thread-Index: Ac4vmA46vFpmxPVxQ4WutPsxGID1wgE70AVw Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923042D2FA475@PRVPEXVS15.corp.twcable.com> References: <20130401224601.12673.72208.idtracker@ietfa.amsl.com> <20130402114840.GA11966@pob.ytti.fi> In-Reply-To: <20130402114840.GA11966@pob.ytti.fi> 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 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, 08 Apr 2013 18:38:19 -0000 > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf > Of Saku Ytti > Sent: Tuesday, April 02, 2013 7:49 AM > To: L3VPN > Subject: Re: I-D Action: draft-ietf-l3vpn-end-system-01.txt > > On (2013-04-02 12:42 +0200), Robert Raszuk wrote: > > > > I think you can build IPv6 DC virtualization services while still > > using > > IPv4 only DC core. > > I was just worried as draft specifically allows for IPv6, yet XMPP > messages seem to be trailed with /32. I'm personally not interested much > in dual-stack control-plane. I'm happy to run 6PE now, and maybe in > future go > IPv6 only control-plane and 4PE for legacy. But I understand it might > not be popular position. > [WEG] +1 in fact, at the Orlando IETF meeting, I and a few others kicked off a discu= ssion in MPLS WG regarding a gap analysis for IPv6-only operation of MPLS f= eatures, because we believe that this will be necessary within the time hor= izon for IETF work. So the authors would do well to consider and document o= r resolve any IPv4 dependencies. While obviously, MPLS control plane depend= encies must be solved first, anything specific to this implementation that = relies on IPv4 to function should be noted. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From internet-drafts@ietf.org Wed Apr 10 11:47:23 2013 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 EF6A721F8F6F; Wed, 10 Apr 2013 11:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=0.225, 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 3sAJGSyJsPXE; Wed, 10 Apr 2013 11:47:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CF721F8F29; Wed, 10 Apr 2013 11:47:22 -0700 (PDT) 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-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130410184722.15257.71544.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2013 11:47:22 -0700 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: Wed, 10 Apr 2013 18:47:23 -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 Working = Group of the IETF. Title : MVPN: Using Bidirectional P-Tunnels Author(s) : Eric C. Rosen IJsbrand Wijnands Yiqun Cai Arjen Boers Filename : draft-ietf-l3vpn-mvpn-bidir-05.txt Pages : 32 Date : 2013-04-10 Abstract: A set of prior RFCs specify procedures for supporting multicast in BGP/MPLS IP VPNs. These procedures allow customer multicast data to travel across a service provider's backbone network through a set of multicast tunnels. The tunnels are advertised in certain BGP "auto- discovery" routes, by means of a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel attribute". Encodings have been defined that allow the PMSI Tunnel attribute to identify bidirectional (multipoint-to-multipoint) multicast distribution trees. However, the prior RFCs do not provide all the necessary procedures for using bidirectional tunnels to support multicast VPNs. This document updates RFCs 6513 and 6625 by specifying those procedures. In particular, it specifies the procedures for assigning customer multicast flows (unidirectional or bidirectional) to specific bidirectional tunnels in the provider backbone, for advertising such assignments, and for determining which flows have been assigned to which tunnels. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-mvpn-bidir There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-mvpn-bidir-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l3vpn-mvpn-bidir-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From thomas.morin@orange.com Thu Apr 11 08:08:01 2013 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 8CDAE21F8E63 for ; Thu, 11 Apr 2013 08:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=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 BKp3q369W45D for ; Thu, 11 Apr 2013 08:08:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFD221F8D86 for ; Thu, 11 Apr 2013 08:08:00 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 99EE92DC576 for ; Thu, 11 Apr 2013 17:07:59 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 7A28423806C for ; Thu, 11 Apr 2013 17:07:59 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Thu, 11 Apr 2013 17:07:59 +0200 From: To: L3VPN Subject: IETF 86 L3VPN minutes: please read Thread-Topic: IETF 86 L3VPN minutes: please read Thread-Index: AQHONsZaGyp0UDaMokuUVx5UlGsyrQ== Date: Thu, 11 Apr 2013 15:07:58 +0000 Message-ID: <11866_1365692879_5166D1CF_11866_219_2_AC1ADC68A92CF94FA8CFCB406C1CBE3D07338C64@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 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, 11 Apr 2013 15:08:01 -0000 SGkgd29ya2luZyBncm91cCwNCg0KV2UgaGF2ZSBwb3N0ZWQgdGhlIG1pbnV0ZXMgb2Ygb3VyIGxh c3QgbWVldGluZy4NClRoZXkgY2FuIGJlIHNlZSBhdDoNCiAgICBodHRwOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzLzg2L21pbnV0ZXMvbWludXRlcy04Ni1sM3Zwbg0KDQpQbGVhc2UgcmVhZCAg YW5kIGNvbW1lbnQvY29ycmVjdCBhcyByZWxldmFudC4NCg0KVGhhbmtzLA0KDQotVGhvbWFzDQoN ClBTOiB0aGFua3MgdG8gTDNWUE4gc2VjcmV0YXJ5IERhbiBLaW5nIHdobyB0b29rIHRoZW0hCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91 IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBv ciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBG cmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From internet-drafts@ietf.org Sun Apr 14 06:22:40 2013 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 A436021F85D9; Sun, 14 Apr 2013 06:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.128 X-Spam-Level: X-Spam-Status: No, score=-98.128 tagged_above=-999 required=5 tests=[AWL=-3.771, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HELO_MISMATCH_COM=0.553, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, 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 Rxch0kjulHtt; Sun, 14 Apr 2013 06:22:40 -0700 (PDT) Received: from jlonline.com (pip46.ptt.js.cn [61.155.13.222]) by ietfa.amsl.com (Postfix) with SMTP id 5BB7F21F8550; Sun, 14 Apr 2013 06:22:39 -0700 (PDT) Received: from jlonline.com([10.100.0.22]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm15516abcdb; Sun, 14 Apr 2013 21:28:24 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm7351660025; Thu, 11 Apr 2013 03:27:51 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id AISP action; Thu, 11 Apr 2013 03:27:51 +0800 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E17B21F8F4D; Wed, 10 Apr 2013 11:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1365619645; bh=xw3z/DeE/AjNNnj4orZpwPqxM/V59NAPhyNu/4XLIEI=; h=MIME-Version:From:To:Subject:Message-ID:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=V3pGKV7QUeqtavq2nE0cXXwtCYpg1gCU2mFFVW55NGM8a+/bTFgt5s1/9x97cWan8 kAUrJRAvhazar5mXiKJR/vhcD8Q/F1AxAtRmO2b0c34de3UQnfMDAQj6NR9hSFUq0q hK6TtQY+EQVbTJ+aqP85k3wkVAehNkTe/edXeEJo= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6A721F8F6F; Wed, 10 Apr 2013 11:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 3sAJGSyJsPXE; Wed, 10 Apr 2013 11:47:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CF721F8F29; Wed, 10 Apr 2013 11:47:22 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-mvpn-bidir-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130410184722.15257.71544.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2013 11:47:22 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-Msg-ID: WR1gA04B X-AIMC-AUTH: (null) X-AIMC-MAILFROM: internet-drafts@ietf.org Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org Reply-To: internet-drafts@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 13:22:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 3 Virtual Private Networks Working Group of the IETF. Title : MVPN: Using Bidirectional P-Tunnels Author(s) : Eric C. Rosen IJsbrand Wijnands Yiqun Cai Arjen Boers Filename : draft-ietf-l3vpn-mvpn-bidir-05.txt Pages : 32 Date : 2013-04-10 Abstract: A set of prior RFCs specify procedures for supporting multicast in BGP/MPLS IP VPNs. These procedures allow customer multicast data to travel across a service provider's backbone network through a set of multicast tunnels. The tunnels are advertised in certain BGP "auto- discovery" routes, by means of a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel attribute". Encodings have been defined that allow the PMSI Tunnel attribute to identify bidirectional (multipoint-to-multipoint) multicast distribution trees. However, the prior RFCs do not provide all the necessary procedures for using bidirectional tunnels to support multicast VPNs. This document updates RFCs 6513 and 6625 by specifying those procedures. In particular, it specifies the procedures for assigning customer multicast flows (unidirectional or bidirectional) to specific bidirectional tunnels in the provider backbone, for advertising such assignments, and for determining which flows have been assigned to which tunnels. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-mvpn-bidir There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-mvpn-bidir-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-l3vpn-mvpn-bidir-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From SPaul@ixiacom.com Wed Apr 17 05:19:36 2013 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 E60AE21F8E3C for ; Wed, 17 Apr 2013 05:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_SORBS_WEB=0.619] 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 tNR3A9DsJ-X3 for ; Wed, 17 Apr 2013 05:19:36 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id B707221F8E34 for ; Wed, 17 Apr 2013 05:19:35 -0700 (PDT) Received: from mail92-db8-R.bigfish.com (10.174.8.233) by DB8EHSOBE029.bigfish.com (10.174.4.92) with Microsoft SMTP Server id 14.1.225.23; Wed, 17 Apr 2013 12:19:34 +0000 Received: from mail92-db8 (localhost [127.0.0.1]) by mail92-db8-R.bigfish.com (Postfix) with ESMTP id 6B67E40128 for ; Wed, 17 Apr 2013 12:19:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.117; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0610HT004.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zzc85fhzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL17326ah18c673h8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1155h) Received-SPF: pass (mail92-db8: domain of ixiacom.com designates 157.56.240.117 as permitted sender) client-ip=157.56.240.117; envelope-from=SPaul@ixiacom.com; helo=BL2PRD0610HT004.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail92-db8 (localhost.localdomain [127.0.0.1]) by mail92-db8 (MessageSwitch) id 1366201171780974_17479; Wed, 17 Apr 2013 12:19:31 +0000 (UTC) Received: from DB8EHSMHS016.bigfish.com (unknown [10.174.8.252]) by mail92-db8.bigfish.com (Postfix) with ESMTP id BB35D24004B for ; Wed, 17 Apr 2013 12:19:31 +0000 (UTC) Received: from BL2PRD0610HT004.namprd06.prod.outlook.com (157.56.240.117) by DB8EHSMHS016.bigfish.com (10.174.4.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 17 Apr 2013 12:19:31 +0000 Received: from BL2PRD0610MB386.namprd06.prod.outlook.com ([169.254.12.237]) by BL2PRD0610HT004.namprd06.prod.outlook.com ([10.255.101.39]) with mapi id 14.16.0293.003; Wed, 17 Apr 2013 12:19:31 +0000 From: Santanu Paul To: "l3vpn@ietf.org" Subject: Query regarding rfc4684 Constrained Route Distribution Thread-Topic: Query regarding rfc4684 Constrained Route Distribution Thread-Index: Ac47ZCL+++vnk9ccSNSowGlSa2pjrw== Date: Wed, 17 Apr 2013 12:19:30 +0000 Message-ID: <256A9296DD49E84C9922E22B04A65BC17FA279C9@BL2PRD0610MB386.namprd06.prod.outlook.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.14.67] Content-Type: multipart/alternative; boundary="_000_256A9296DD49E84C9922E22B04A65BC17FA279C9BL2PRD0610MB386_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BL2PRD0610HT004.namprd06.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BL2PRD0610HT004.namprd06.prod.outlook.com X-OriginatorOrg: ixiacom.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: Wed, 17 Apr 2013 12:19:37 -0000 --_000_256A9296DD49E84C9922E22B04A65BC17FA279C9BL2PRD0610MB386_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This spec says "This mechanism is applicable to any BGP NLR= I that controls the distribution of routing information by using Route Targ= ets, such as VPLS [9]." I have a = question regarding this. If same RT is used for some L3VPN routes (AFI/SAFI= =3D /128) and some L2VPN routes (AFI/SAFI=3D25/65) and a PE is providing bo= th IP VPN and VPLS service, how it will distinguish which VPN service these= RTs are meant for? Should not there be a AFI/SAFI element for the RTs in "= Route Target Membership NLRI"? Regards, Santanu. --_000_256A9296DD49E84C9922E22B04A65BC17FA279C9BL2PRD0610MB386_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

        &nbs= p;       This spec says “This mechanism= is applicable to any BGP NLRI that controls the distribution of routing in= formation by using Route Targets, such as VPLS [9].”= ; I have a question regarding this. If same RT is used for some L3VPN routes= (AFI/SAFI=3D /128) and some L2VPN routes (AFI/SAFI=3D25/65) and a PE is pr= oviding both IP VPN and VPLS service, how it will distinguish which VPN ser= vice these RTs are meant for? Should not there be a AFI/SAFI element for the RTs in “Route Target Membership NLRI”?

&n= bsp;

Regards,

Santanu.

--_000_256A9296DD49E84C9922E22B04A65BC17FA279C9BL2PRD0610MB386_-- From rraszuk@gmail.com Wed Apr 17 07:32:01 2013 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 77DD421E804B for ; Wed, 17 Apr 2013 07:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-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 D7ur08wXaaHJ for ; Wed, 17 Apr 2013 07:32:01 -0700 (PDT) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id DEA4E21E8043 for ; Wed, 17 Apr 2013 07:32:00 -0700 (PDT) Received: by mail-ia0-f169.google.com with SMTP id l29so248276iag.0 for ; Wed, 17 Apr 2013 07:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CtmhS7+rCOz5GhcfzhG9SwMWVfYSSdT3FeFIS/DumEw=; b=wmn7t/73sGc5ilDlJb9QFOzH1eGG3z6QMP6yVUulwa8FbX2LOQ88S7Bduw2rsK00AL vIs4TQFLpQOrM2xyig3i0EZR65ogvTfPHfbLyThqzcXn0Q7YjYFKJ1Z7IWPNXnIHBqwJ 3bQ7Hq9BWcSCIDn2rwztwmVRY6Q9L7f8b/GcCb1IMcte+nNKk4Sto9m0s1fRFrQNtL3y KQt1v9jfnm1JT4Vzdi3QdxSlYhFW7gV3KWjsOcMUv7PtKgTpOo9SbAbQgWQZBQb5fnju rlWamCrfl2RyBiWdYykDf2oUrTS/0WN9Cbf/E9XCMsAPVYoafXbT3HLPMqPxbien2zqb UvNw== MIME-Version: 1.0 X-Received: by 10.50.178.36 with SMTP id cv4mr4367445igc.98.1366209120463; Wed, 17 Apr 2013 07:32:00 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.91.105 with HTTP; Wed, 17 Apr 2013 07:32:00 -0700 (PDT) In-Reply-To: <256A9296DD49E84C9922E22B04A65BC17FA279C9@BL2PRD0610MB386.namprd06.prod.outlook.com> References: <256A9296DD49E84C9922E22B04A65BC17FA279C9@BL2PRD0610MB386.namprd06.prod.outlook.com> Date: Wed, 17 Apr 2013 16:32:00 +0200 X-Google-Sender-Auth: X90ZOdp5otdSy5hvqhnlgXy5SkM Message-ID: Subject: Re: Query regarding rfc4684 Constrained Route Distribution From: Robert Raszuk To: Santanu Paul Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: Wed, 17 Apr 2013 14:32:01 -0000 Hi Paul, We think of RT as characteristic of a VPN not a service within VPN. So why would you want to break a VPN services apart for a given customer site/vrf ? Said this there was proposal http://tools.ietf.org/html/draft-dong-idr-vpn-route-constrain-02 which did not got much traction and sort of expired on it's own. Besides if you really want to have separated services you can always allocate new RT per service and not per VPN/vrf. Best regards, R. On Wed, Apr 17, 2013 at 2:19 PM, Santanu Paul wrote: > Hi, > > > > This spec says =93This mechanism is applicable to any BGP= NLRI > that controls the distribution of routing information by using Route > Targets, such as VPLS [9].=94 I have a question regarding this. If same R= T is > used for some L3VPN routes (AFI/SAFI=3D /128) and some L2VPN routes > (AFI/SAFI=3D25/65) and a PE is providing both IP VPN and VPLS service, ho= w it > will distinguish which VPN service these RTs are meant for? Should not th= ere > be a AFI/SAFI element for the RTs in =93Route Target Membership NLRI=94? > > > > Regards, > > Santanu. From internet-drafts@ietf.org Fri Apr 19 06:31:03 2013 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 5895421F95E9; Fri, 19 Apr 2013 06:31:03 -0700 (PDT) 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 XVcEEf3uYF0Z; Fri, 19 Apr 2013 06:31:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E038A21F95D0; Fri, 19 Apr 2013 06:31:02 -0700 (PDT) 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-virtual-hub-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p3 Message-ID: <20130419133102.11014.24161.idtracker@ietfa.amsl.com> Date: Fri, 19 Apr 2013 06:31:02 -0700 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: Fri, 19 Apr 2013 13:31:03 -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 Working = Group of the IETF. Title : Virtual Hub-and-Spoke in BGP/MPLS VPNs Author(s) : Huajin Jeng James Uttaro Luay Jalil Bruno Decraene Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-l3vpn-virtual-hub-06.txt Pages : 26 Date : 2013-04-19 Abstract: With BGP/MPLS VPNs, providing any-to-any connectivity among sites of a given Virtual Private Network would require each Provider Edge router that has one or more of these sites connected to it to hold all the routes of that Virtual Private Network. The approach described in this document allows to reduce the number of Provider Edge routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes. Furthermore, when Provider Edge routers use ingress replication to carry multicast traffic of VPN customers, the approach described in this document may under certain circumstances allow to reduce bandwidth inefficiency associated with ingress replication, and to redistribute the replication load among Provider Edge routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-virtual-hub There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-virtual-hub-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l3vpn-virtual-hub-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From SPaul@ixiacom.com Mon Apr 22 22:07:15 2013 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 0E2D821F9604 for ; Mon, 22 Apr 2013 22:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.379 X-Spam-Level: X-Spam-Status: No, score=-5.379 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] 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 fd7RHndkZWOP for ; Mon, 22 Apr 2013 22:07:10 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5230421F95DA for ; Mon, 22 Apr 2013 22:07:09 -0700 (PDT) Received: from mail100-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Tue, 23 Apr 2013 05:07:08 +0000 Received: from mail100-tx2 (localhost [127.0.0.1]) by mail100-tx2-R.bigfish.com (Postfix) with ESMTP id 8154F420071; Tue, 23 Apr 2013 05:07:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.117; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0610HT003.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zzc85fhzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz17326ah18c673h8275bh8275dh1033ILz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1155h) Received-SPF: pass (mail100-tx2: domain of ixiacom.com designates 157.56.240.117 as permitted sender) client-ip=157.56.240.117; envelope-from=SPaul@ixiacom.com; helo=BL2PRD0610HT003.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail100-tx2 (localhost.localdomain [127.0.0.1]) by mail100-tx2 (MessageSwitch) id 136669362629820_5011; Tue, 23 Apr 2013 05:07:06 +0000 (UTC) Received: from TX2EHSMHS011.bigfish.com (unknown [10.9.14.243]) by mail100-tx2.bigfish.com (Postfix) with ESMTP id ED2B2220058; Tue, 23 Apr 2013 05:07:05 +0000 (UTC) Received: from BL2PRD0610HT003.namprd06.prod.outlook.com (157.56.240.117) by TX2EHSMHS011.bigfish.com (10.9.99.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 23 Apr 2013 05:07:04 +0000 Received: from BL2PRD0610MB386.namprd06.prod.outlook.com ([169.254.12.184]) by BL2PRD0610HT003.namprd06.prod.outlook.com ([10.255.101.38]) with mapi id 14.16.0299.002; Tue, 23 Apr 2013 05:07:04 +0000 From: Santanu Paul To: "l3vpn@ietf.org" Subject: RE: Query regarding rfc4684 Constrained Route Distribution Thread-Topic: Query regarding rfc4684 Constrained Route Distribution Thread-Index: Ac47ZCL+++vnk9ccSNSowGlSa2pjrwEfAhag Date: Tue, 23 Apr 2013 05:07:03 +0000 Message-ID: <256A9296DD49E84C9922E22B04A65BC17FA4745E@BL2PRD0610MB386.namprd06.prod.outlook.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.14.67] Content-Type: multipart/alternative; boundary="_000_256A9296DD49E84C9922E22B04A65BC17FA4745EBL2PRD0610MB386_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BL2PRD0610HT003.namprd06.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BL2PRD0610HT003.namprd06.prod.outlook.com X-FOPE-CRA-Verdict: 157.56.240.117$juniper.net%12218%4%ixiacom.com%False%False%0$ X-OriginatorOrg: ixiacom.com Cc: "roque@juniper.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: Tue, 23 Apr 2013 05:07:15 -0000 --_000_256A9296DD49E84C9922E22B04A65BC17FA4745EBL2PRD0610MB386_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 2nd Try From: Santanu Paul Sent: 17 April 2013 17:50 To: l3vpn@ietf.org Subject: Query regarding rfc4684 Constrained Route Distribution Hi, This spec says "This mechanism is applicable to any BGP NLR= I that controls the distribution of routing information by using Route Targ= ets, such as VPLS [9]." I have a = question regarding this. If same RT is used for some L3VPN routes (AFI/SAFI= =3D /128) and some L2VPN routes (AFI/SAFI=3D25/65) and a PE is providing bo= th IP VPN and VPLS service, how it will distinguish which VPN service these= RTs are meant for? Should not there be a AFI/SAFI element for the RTs in "= Route Target Membership NLRI"? Regards, Santanu. --_000_256A9296DD49E84C9922E22B04A65BC17FA4745EBL2PRD0610MB386_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

2nd Try

 

From:= Santanu Paul
Sent: 17 April 2013 17:50
To: l3vpn@ietf.org
Subject: Query regarding rfc4684 Constrained Route Distribution

 

Hi,

 

        &nbs= p;       This spec says “This mechanism= is applicable to any BGP NLRI that controls the distribution of routing in= formation by using Route Targets, such as VPLS [9].”= ; I have a question regarding this. If same RT is used for some L3VPN routes= (AFI/SAFI=3D /128) and some L2VPN routes (AFI/SAFI=3D25/65) and a PE is pr= oviding both IP VPN and VPLS service, how it will distinguish which VPN ser= vice these RTs are meant for? Should not there be a AFI/SAFI element for the RTs in “Route Target Membership NLRI”?

&n= bsp;

Regards,

Santanu.

--_000_256A9296DD49E84C9922E22B04A65BC17FA4745EBL2PRD0610MB386_-- From rraszuk@gmail.com Mon Apr 22 22:10:32 2013 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 B68FC21F9630 for ; Mon, 22 Apr 2013 22:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-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 hG+0SB7om1em for ; Mon, 22 Apr 2013 22:10:32 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAB021F962F for ; Mon, 22 Apr 2013 22:10:32 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id e11so258442iej.16 for ; Mon, 22 Apr 2013 22:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ELLhKVcxZceLri0MsRjqFwi6NmlewFUQrqxIrA+vZHc=; b=DLUSGTDmlHyzrJ8khR8yw/PriaExaAyL9/kjF3jp4XUqTvZUOU4Lyg6bE2bGHsPW3P E6NQP1XFTNMJokq8p5cNBFJLgJyGKbNMABUATZNq5lvQc7Tr5c3OOSf1qKA3LvGeXc4Z dPNxMd1ZINVj62BCFHByIe4zyWX9Xe72/4JTSzMb0ecaxj/5ZAIra0IQT53RnhLRkDJr UtApML5AuK/KqH+K6PUUm+62j9v8bC0m66PX2hNkp0SV0Q2EgRzAkunGDXvuWHJS1M2+ pnsJttjBAD6fUqlzp0aKpt3e8ULZdv4mJz17R41V7gI8K2efVRVSVXKtgnRWr0UVNmwd C7bA== MIME-Version: 1.0 X-Received: by 10.50.11.18 with SMTP id m18mr5756476igb.98.1366693831887; Mon, 22 Apr 2013 22:10:31 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.91.105 with HTTP; Mon, 22 Apr 2013 22:10:31 -0700 (PDT) In-Reply-To: <256A9296DD49E84C9922E22B04A65BC17FA4745E@BL2PRD0610MB386.namprd06.prod.outlook.com> References: <256A9296DD49E84C9922E22B04A65BC17FA4745E@BL2PRD0610MB386.namprd06.prod.outlook.com> Date: Tue, 23 Apr 2013 07:10:31 +0200 X-Google-Sender-Auth: uk2dp_BKrQG1a-4_OBrtAM7GxMY Message-ID: Subject: Re: Query regarding rfc4684 Constrained Route Distribution From: Robert Raszuk To: Santanu Paul Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "roque@juniper.net" , "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: Tue, 23 Apr 2013 05:10:32 -0000 2nd reply .. Hi Paul, We think of RT as characteristic of a VPN not a service within VPN. So why would you want to break a VPN services apart for a given customer site/vrf ? Said this there was proposal http://tools.ietf.org/html/draft-dong-idr-vpn-route-constrain-02 which did not got much traction and sort of expired on it's own. Besides if you really want to have separated services you can always allocate new RT per service and not per VPN/vrf. Best regards, R. On Tue, Apr 23, 2013 at 7:07 AM, Santanu Paul wrote: > 2nd Try > > > > From: Santanu Paul > Sent: 17 April 2013 17:50 > To: l3vpn@ietf.org > Subject: Query regarding rfc4684 Constrained Route Distribution > > > > Hi, > > > > This spec says =93This mechanism is applicable to any BGP= NLRI > that controls the distribution of routing information by using Route > Targets, such as VPLS [9].=94 I have a question regarding this. If same R= T is > used for some L3VPN routes (AFI/SAFI=3D /128) and some L2VPN routes > (AFI/SAFI=3D25/65) and a PE is providing both IP VPN and VPLS service, ho= w it > will distinguish which VPN service these RTs are meant for? Should not th= ere > be a AFI/SAFI element for the RTs in =93Route Target Membership NLRI=94? > > > > Regards, > > Santanu. From kireeti.kompella@gmail.com Tue Apr 23 05:53:33 2013 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 8613021F9676 for ; Tue, 23 Apr 2013 05:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] 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 djBxmoAnX3H4 for ; Tue, 23 Apr 2013 05:53:32 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id 71B3C21F9648 for ; Tue, 23 Apr 2013 05:53:24 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id x11so419430pdj.10 for ; Tue, 23 Apr 2013 05:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=xX3oA1FrNOONJ67lBpymKS4unMK0lMLeOO/ISoHPYdw=; b=mlLEnXclzr1eLq59ZLh3czV383sUC3MDk73/rmkfdMbkVKn5wmpMts1J25ss03gto/ kD4yl8YUx/Q/thleX0guUNqMzhR+gyQVeH7/YqjyQjxjkaSFNM4+gv1QHFjfASaLQVV1 8doEzNSvIzlmq0ILVqD9wLq9csZWkvUrWQBW5Y/FaYzLlQ6lust1+6pT5SGCWfIZc/oT OkQiHDyyAkYkJxZtgo39dBa9LwvuQBx+1iKVcrPUkgoGwjZYKL4pZvtL/7OuPtzdCRsj jrYsmHZorUOGf5wCCYvkBYzctTRAZb3Lgs8m7aIvJGCkiedj+2x7T71pstU68ydDlK3J 9S2w== X-Received: by 10.68.26.6 with SMTP id h6mr11521703pbg.149.1366721604760; Tue, 23 Apr 2013 05:53:24 -0700 (PDT) Received: from [10.170.172.163] (mobile-166-137-187-252.mycingular.net. [166.137.187.252]) by mx.google.com with ESMTPS id cp1sm29425900pbc.42.2013.04.23.05.53.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Apr 2013 05:53:23 -0700 (PDT) References: <256A9296DD49E84C9922E22B04A65BC17FA4745E@BL2PRD0610MB386.namprd06.prod.outlook.com> In-Reply-To: <256A9296DD49E84C9922E22B04A65BC17FA4745E@BL2PRD0610MB386.namprd06.prod.outlook.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (10A551) From: Kireeti Kompella Subject: Re: Query regarding rfc4684 Constrained Route Distribution Date: Tue, 23 Apr 2013 05:53:23 -0700 To: Santanu Paul Cc: "roque@juniper.net" , "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: Tue, 23 Apr 2013 12:53:33 -0000 Hi Santanu, On Apr 22, 2013, at 22:07, Santanu Paul wrote: > If same RT is used for some L3VPN routes (AFI/SAFI=3D /128) and some L2VPN= routes (AFI/SAFI=3D25/65) and a PE is providing both IP VPN and VPLS servic= e, how it will distinguish which VPN service these RTs are meant for? The answer should be obvious, using the "if it hurts, don't do it" principle= : don't use the same RT for two different VPN services. Kireeti= From SPaul@ixiacom.com Tue Apr 23 22:00:44 2013 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 036BD21F9356 for ; Tue, 23 Apr 2013 22:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.879 X-Spam-Level: X-Spam-Status: No, score=-3.879 tagged_above=-999 required=5 tests=[AWL=-1.499, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 fxaip78w4SfS for ; Tue, 23 Apr 2013 22:00:43 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id CFBB121F9354 for ; Tue, 23 Apr 2013 22:00:42 -0700 (PDT) Received: from mail17-am1-R.bigfish.com (10.3.201.243) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 24 Apr 2013 05:00:41 +0000 Received: from mail17-am1 (localhost [127.0.0.1]) by mail17-am1-R.bigfish.com (Postfix) with ESMTP id 8740540020D; Wed, 24 Apr 2013 05:00:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.117; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0610HT005.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371I542I1432Idb82hzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz17326ah8275bh8275dh1033ILz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1155h) Received-SPF: pass (mail17-am1: domain of ixiacom.com designates 157.56.240.117 as permitted sender) client-ip=157.56.240.117; envelope-from=SPaul@ixiacom.com; helo=BL2PRD0610HT005.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail17-am1 (localhost.localdomain [127.0.0.1]) by mail17-am1 (MessageSwitch) id 1366779639570640_15619; Wed, 24 Apr 2013 05:00:39 +0000 (UTC) Received: from AM1EHSMHS021.bigfish.com (unknown [10.3.201.241]) by mail17-am1.bigfish.com (Postfix) with ESMTP id 7F66E360246; Wed, 24 Apr 2013 05:00:39 +0000 (UTC) Received: from BL2PRD0610HT005.namprd06.prod.outlook.com (157.56.240.117) by AM1EHSMHS021.bigfish.com (10.3.207.150) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 24 Apr 2013 05:00:39 +0000 Received: from BL2PRD0610MB386.namprd06.prod.outlook.com ([169.254.12.184]) by BL2PRD0610HT005.namprd06.prod.outlook.com ([10.255.101.40]) with mapi id 14.16.0299.002; Wed, 24 Apr 2013 05:00:28 +0000 From: Santanu Paul To: Robert Raszuk Subject: RE: Query regarding rfc4684 Constrained Route Distribution Thread-Topic: Query regarding rfc4684 Constrained Route Distribution Thread-Index: AQHOP+DkQyQw9JzDwkmtL5keovlzWJjk0YMQ Date: Wed, 24 Apr 2013 05:00:27 +0000 Message-ID: <256A9296DD49E84C9922E22B04A65BC17FA49864@BL2PRD0610MB386.namprd06.prod.outlook.com> References: <256A9296DD49E84C9922E22B04A65BC17FA4745E@BL2PRD0610MB386.namprd06.prod.outlook.com> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.14.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BL2PRD0610HT005.namprd06.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BL2PRD0610HT005.namprd06.prod.outlook.com X-FOPE-CRA-Verdict: 157.56.240.117$juniper.net%12218%4%ixiacom.com%False%False%0$ X-OriginatorOrg: ixiacom.com Cc: "roque@juniper.net" , "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: Wed, 24 Apr 2013 05:00:44 -0000 Hi, Thanks for your reply. So does this mean, to support this spec, different = VPNs even if service type is different (e.g. L2/L3) have to have different = RT though from L2VPN and L3VPN specs two VPNs one providing L2 service othe= r L3 service can share same RT without any problem and if such configured, = the configuration need to be changed in all PEs/RRs. I am trying to underst= and VPN technologies, and don't know if there are general practise/guidelin= es to use them unless it is spelled out in spec. Santanu. -----Original Message----- From: Robert Raszuk [mailto:robert@raszuk.net]=20 Sent: 23 April 2013 10:41 To: Santanu Paul Cc: roque@juniper.net; l3vpn@ietf.org Subject: Re: Query regarding rfc4684 Constrained Route Distribution 2nd reply .. Hi Paul, We think of RT as characteristic of a VPN not a service within VPN. So why = would you want to break a VPN services apart for a given customer site/vrf = ? Said this there was proposal http://tools.ietf.org/html/draft-dong-idr-vpn-route-constrain-02 which did = not got much traction and sort of expired on it's own. Besides if you really want to have separated services you can always alloca= te new RT per service and not per VPN/vrf. Best regards, R. On Tue, Apr 23, 2013 at 7:07 AM, Santanu Paul wrote: > 2nd Try > > > > From: Santanu Paul > Sent: 17 April 2013 17:50 > To: l3vpn@ietf.org > Subject: Query regarding rfc4684 Constrained Route Distribution > > > > Hi, > > > > This spec says "This mechanism is applicable to any=20 > BGP NLRI that controls the distribution of routing information by=20 > using Route Targets, such as VPLS [9]." I have a question regarding=20 > this. If same RT is used for some L3VPN routes (AFI/SAFI=3D /128) and=20 > some L2VPN routes > (AFI/SAFI=3D25/65) and a PE is providing both IP VPN and VPLS service,=20 > how it will distinguish which VPN service these RTs are meant for?=20 > Should not there be a AFI/SAFI element for the RTs in "Route Target Membe= rship NLRI"? > > > > Regards, > > Santanu. From rraszuk@gmail.com Tue Apr 23 22:16:44 2013 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 0F7BC21F936C for ; Tue, 23 Apr 2013 22:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, NO_RELAYS=-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 FzDS09PccC7b for ; Tue, 23 Apr 2013 22:16:43 -0700 (PDT) Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 65AE621F9354 for ; Tue, 23 Apr 2013 22:16:43 -0700 (PDT) Received: by mail-ia0-f182.google.com with SMTP id a5so1251153iah.41 for ; Tue, 23 Apr 2013 22:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6Jv2OHiyY3C8wZw6QeOJbkSZdYw7qakI/9J6Eb8314A=; b=lbJTym0xLBbzPlw3LFv9OHTpXmQolviVmpIb40/4lk72+3rZBbdPPTYOVDa0Ik2zq2 FmjVRW7D/SVCmCaShdFNlxVJ/XbJ6dj/fMopNs/0ktGbiOtDKv6OdMmYdOjbAMoPlHfD ne8rTOAkgszSBzWcYG4m+OEuvF0wll6lXh15fgKavdAgAwqn2EzyVQm4thNQ1+mgn2nT W2Rv+xjQAPfFq8s6enIEdXvaoKo9wTDiv0unIVlwSl9u0VKMnbHwLC0UKzr0lMKBN9Gx ngs4PmVW7dhpyr1/JemlGnNfuIboi7aq2xm66SmDwesekkEkejbTgQ2f/dTbft63mymP 8yhA== MIME-Version: 1.0 X-Received: by 10.43.103.195 with SMTP id dj3mr17486757icc.3.1366780602793; Tue, 23 Apr 2013 22:16:42 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.91.105 with HTTP; Tue, 23 Apr 2013 22:16:42 -0700 (PDT) In-Reply-To: <256A9296DD49E84C9922E22B04A65BC17FA49864@BL2PRD0610MB386.namprd06.prod.outlook.com> References: <256A9296DD49E84C9922E22B04A65BC17FA4745E@BL2PRD0610MB386.namprd06.prod.outlook.com> <256A9296DD49E84C9922E22B04A65BC17FA49864@BL2PRD0610MB386.namprd06.prod.outlook.com> Date: Wed, 24 Apr 2013 07:16:42 +0200 X-Google-Sender-Auth: OrkDu406CU4Ol-rzTAHGFRxRNg4 Message-ID: Subject: Re: Query regarding rfc4684 Constrained Route Distribution From: Robert Raszuk To: Santanu Paul Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "roque@juniper.net" , "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: Wed, 24 Apr 2013 05:16:44 -0000 Hi, It is ok to use same RT. And usually for a given VPN which requires L2 and L3 same RT makes sense. Likewise you need both L2 and L3 VPN routes so RTC will request routes for both of those services in the same time. Best regards, R. On Wed, Apr 24, 2013 at 7:00 AM, Santanu Paul wrote: > Hi, > > Thanks for your reply. So does this mean, to support this spec, d= ifferent VPNs even if service type is different (e.g. L2/L3) have to have d= ifferent RT though from L2VPN and L3VPN specs two VPNs one providing L2 ser= vice other L3 service can share same RT without any problem and if such con= figured, the configuration need to be changed in all PEs/RRs. I am trying t= o understand VPN technologies, and don't know if there are general practise= /guidelines to use them unless it is spelled out in spec. > > Santanu. > > -----Original Message----- > From: Robert Raszuk [mailto:robert@raszuk.net] > Sent: 23 April 2013 10:41 > To: Santanu Paul > Cc: roque@juniper.net; l3vpn@ietf.org > Subject: Re: Query regarding rfc4684 Constrained Route Distribution > > 2nd reply .. > > Hi Paul, > > We think of RT as characteristic of a VPN not a service within VPN. So wh= y would you want to break a VPN services apart for a given customer site/vr= f ? > > Said this there was proposal > http://tools.ietf.org/html/draft-dong-idr-vpn-route-constrain-02 which di= d not got much traction and sort of expired on it's own. > > Besides if you really want to have separated services you can always allo= cate new RT per service and not per VPN/vrf. > > Best regards, > R. > > On Tue, Apr 23, 2013 at 7:07 AM, Santanu Paul wrote: >> 2nd Try >> >> >> >> From: Santanu Paul >> Sent: 17 April 2013 17:50 >> To: l3vpn@ietf.org >> Subject: Query regarding rfc4684 Constrained Route Distribution >> >> >> >> Hi, >> >> >> >> This spec says "This mechanism is applicable to any >> BGP NLRI that controls the distribution of routing information by >> using Route Targets, such as VPLS [9]." I have a question regarding >> this. If same RT is used for some L3VPN routes (AFI/SAFI=3D /128) and >> some L2VPN routes >> (AFI/SAFI=3D25/65) and a PE is providing both IP VPN and VPLS service, >> how it will distinguish which VPN service these RTs are meant for? >> Should not there be a AFI/SAFI element for the RTs in "Route Target Memb= ership NLRI"? >> >> >> >> Regards, >> >> Santanu. > > From johnsonhammond1@hushmail.com Sat Apr 27 15:47:09 2013 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 CE73121F98DC for ; Sat, 27 Apr 2013 15:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] 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 vwht308YnhN7 for ; Sat, 27 Apr 2013 15:47:08 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7F021F98B3 for ; Sat, 27 Apr 2013 15:47:08 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id EB67030AED for ; Sat, 27 Apr 2013 17:44:39 +0000 (UTC) X-hush-relay-time: 214 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:44:39 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id B3FBEE6736; Sat, 27 Apr 2013 17:44:39 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:44:39 -0400 To: l3vpn@ietf.org Subject: Biggest Fake Conference in Computer Science From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427174439.B3FBEE6736@smtp.hushmail.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: Sat, 27 Apr 2013 22:47:09 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.