From michaellundberg.ietf@gmail.com  Fri Apr  8 12:42:16 2011
Return-Path: <michaellundberg.ietf@gmail.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3118E3A69CF for <l3vpn@core3.amsl.com>; Fri,  8 Apr 2011 12:42:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luANmphJbfNU for <l3vpn@core3.amsl.com>; Fri,  8 Apr 2011 12:42:15 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 2A9AF3A69C2 for <l3vpn@ietf.org>; Fri,  8 Apr 2011 12:42:15 -0700 (PDT)
Received: by iye19 with SMTP id 19so4635751iye.31 for <multiple recipients>; Fri, 08 Apr 2011 12:44:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WXIpLC1oRcB+Eu6TSkWaVcS3bEcMpdgHAJwYvjCC3BQ=; b=hZHjZAd4Hgqupw1WEtb8gfUmQPkuP3cOkXHBcu3PcqvXAK7QED3doKXW1MN5XrehT7 UxIAOdsECRNZ+zlkqZ3qehjIGtbbWlvTTY+cKWv7sgUHh88Yk8y8EStZoGvijZN3Pyyn iDbd6RLzf+h5YwfQNEtrXkdqLgiTExh+7dVR0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jfQsT5nohgeaWH5HRIH7kwEQo8icuuLPElhlXDgTYdHFgfQZqxW+K3LLvfhkcYvllq 5YlrAlaIlDuFzZRyfPUNmxJ4qEqS7DhNAVVP0sF104BzUoCX3RiJIZ0fuZAysk3T69ri 6tGFR3kkrsOJcMSY0knnXH5V6ivxjazP6cC5o=
MIME-Version: 1.0
Received: by 10.231.113.86 with SMTP id z22mr2611628ibp.93.1302291840460; Fri, 08 Apr 2011 12:44:00 -0700 (PDT)
Received: by 10.231.183.129 with HTTP; Fri, 8 Apr 2011 12:44:00 -0700 (PDT)
In-Reply-To: <44EE1E31095AE349AC6C3C0B69FFBF02A684BC09A4@ENFIMBOX1.ad.datcon.co.uk>
References: <AcvjrgW8CKrDGuGTSpWIaLyp8f9P2AAzE/vwAjRLTTAAAO2YcAAG3Ka7AGDDy+AAKMj/wA==> <44EE1E31095AE349AC6C3C0B69FFBF02A684BC09A4@ENFIMBOX1.ad.datcon.co.uk>
Date: Fri, 8 Apr 2011 15:44:00 -0400
Message-ID: <BANLkTikvQPaZgZHmWQu0cy_ukj4HWPqYHQ@mail.gmail.com>
Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
From: Michael Lundberg <michaellundberg.ietf@gmail.com>
To: Nick Weeds <nick.weeds@metaswitch.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "draft-ietf-l3vpn-ospfv3-pece@ietf.org" <draft-ietf-l3vpn-ospfv3-pece@ietf.org>, "l3vpn@ietf.org" <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 19:42:16 -0000

Hi Nick,

Thanks for your review and comments. Please see below for my comments.

On Thu, Mar 31, 2011 at 6:47 AM, Nick Weeds <nick.weeds@metaswitch.com> wro=
te:
> Hi,
>
> The changes in the new draft-ietf-l3vpn-ospfv3-07.txt draft look good, bu=
t I
> do have a couple of specific comments.
>
>
>
> Section 4.3.2 / top of p10
>
> The text says that a PE advertises the IPv6 route learned from MP-BGP to
> attached CEs via OSPFv3 if various conditions hold, including:
>
> =A0=A0=A0=A0=A0=A0=A0 "No OSPFv3 route to the same prefix exists in the V=
RF."
>
> I think this is too restrictive.=A0 The aim is to allow a choice between
> routing over the VPN and routing over an OSPF backdoor link.=A0 The condi=
tion
> above would prevent routing over the VPN if there was already a route ove=
r
> an OSPF backdoor link.
>
> I believe the correct condition would be that the OSPFv3 decision process
> selects the VPN route as the preferred route.

I believe our text is consistent with 4577, which says "If a VRF
contains both an OSPF-distributed route and a VPN-IPv4 route for the
same IPv4 prefix, then the OSPF-distributed route is preferred."
Therefore, as described in the text above, if an OSPFv3 route is
installed in the VRF for the same prefix as the IPv6 route learned via
MP-BGP, the OSPFv3 route will be preferred, and the MP-BGP route will
not be redistributed into OSPF.

To get the behavior you are describing, where you want the OSPF
decision process to prefer either the backbone or the backdoor link,
requires sham links.  In this case, the OSPF routes from one PE are
'tunneled' via MPLS to the other PE and do not appear in the VRF as
MP-BGP routes.  Therefore, the rules above do not hold as you are only
comparing OSPF routes, not MP-BGP to OSPF.

> Section 4.3.2.3 / p11
>
> The rules 1 and 2 for comparing OSPFv3 Domain IDs state how to compare th=
e 6
> value bytes but not how to compare the 2 type bytes.=A0 I believe the rul=
es
> should match RFC 4577 section 4.2.8.1 rules 1 and 3.=A0 In other words, e=
ither
> (1) all 8 (not 6) bytes match, or (2) the 6 byte value fields of both
> attributes are all zeroes and the type bytes are ignored.=A0 Note that in=
 the
> first case the 2 type bytes must match and in the latter case they are
> ignored.

This is a good point.  We will update the text. This text should have
been updated when we removed the use of the single BGP extended
community and reverted back to the OSPF Domain ID extended community
attribute.

Thanks,
Michael

>
> =A0=A0=A0=A0=A0=A0=A0 Nick.
>
> Nick Weeds
> Software Engineer, Network Technologies Division
> Metaswitch Networks
>
> nick.weeds@metaswitch.com
> +44 (0) 20 8366 1177
> www.metaswitch.com

From xuxh@huawei.com  Mon Apr 11 02:46:50 2011
Return-Path: <xuxh@huawei.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7783A6A13 for <l3vpn@core3.amsl.com>; Mon, 11 Apr 2011 02:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level: 
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=0.607,  BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3z9eCvgvttm for <l3vpn@core3.amsl.com>; Mon, 11 Apr 2011 02:46:48 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1C3D93A6A75 for <l3vpn@ietf.org>; Mon, 11 Apr 2011 02:46:48 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJH00JNHF52WZ@szxga04-in.huawei.com> for l3vpn@ietf.org; Mon, 11 Apr 2011 17:46:15 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJH00GU3F52WV@szxga04-in.huawei.com> for l3vpn@ietf.org; Mon, 11 Apr 2011 17:46:14 +0800 (CST)
Received: from x41208c ([10.110.98.96]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJH002NXF524F@szxml04-in.huawei.com> for l3vpn@ietf.org; Mon, 11 Apr 2011 17:46:14 +0800 (CST)
Date: Mon, 11 Apr 2011 17:54:40 +0800
From: Xu Xiaohu <xuxh@huawei.com>
Subject: fwd: New Version Notification for draft-xu-virtual-subnet-05
To: l3vpn@ietf.org
Message-id: <003a01cbf82e$79e3afe0$60626e0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable
Thread-index: Acv4I98O1jTLCaGRSVCIR71fn7m3GwACVAmA
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2011 09:46:50 -0000

Hi all,

An updated version of Virtual Subnet (draft-xu-virtual-subnet) has been
submitted.

Major technical changes are: 1) add a description about active-active CE
multi-homing; 2) add a description about gateway redundancy in the
inter-subnet unicast scenario; 3) modification to the CE host discovery
mechanism.
=20
Any comments are welcome.

Best wishes,
Xiaohu

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: IETF I-D Submission Tool =
[mailto:idsubmission@ietf.org]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C211=C8=D5 16:36
=CA=D5=BC=FE=C8=CB: xuxh@huawei.com
=D6=F7=CC=E2: New Version Notification for draft-xu-virtual-subnet-05


A new version of I-D, draft-xu-virtual-subnet-05.txt has been =
successfully
submitted by Xiaohu Xu and posted to the IETF repository.

Filename:	 draft-xu-virtual-subnet
Revision:	 05
Title:		 Virtual Subnet: A Scalable Data Center Interconnection
Solution
Creation_date:	 2011-04-11
WG ID:		 Independent Submission
Number_of_pages: 10

Abstract:
This document proposes a scalable IP-only L2VPN solution called=20
Virtual Subnet, which reuses BGP/MPLS IP VPN [RFC4364] and ARP proxy=20
[RFC925][RFC1027] technologies. Virtual Subnet could be used to=20
interconnect geographically distributed data centers in a much=20
scalable way.
=20



The IETF Secretariat.



From nick.weeds@metaswitch.com  Mon Apr 11 05:50:31 2011
Return-Path: <nick.weeds@metaswitch.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39A063A6B05 for <l3vpn@core3.amsl.com>; Mon, 11 Apr 2011 05:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lt6Xgqz6OPni for <l3vpn@core3.amsl.com>; Mon, 11 Apr 2011 05:50:28 -0700 (PDT)
Received: from enfiets2.dataconnection.com (enfiets2.dataconnection.com [192.91.191.39]) by core3.amsl.com (Postfix) with ESMTP id 41D6C3A6A10 for <l3vpn@ietf.org>; Mon, 11 Apr 2011 05:50:28 -0700 (PDT)
Received: from ENFIMBOX1.ad.datcon.co.uk (172.18.10.27) by enfiets2.dataconnection.com (172.18.4.22) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 11 Apr 2011 13:50:58 +0100
Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) with mapi; Mon, 11 Apr 2011 13:50:27 +0100
From: Nick Weeds <nick.weeds@metaswitch.com>
To: Michael Lundberg <michaellundberg.ietf@gmail.com>
Date: Mon, 11 Apr 2011 13:50:26 +0100
Subject: RE: Comments on draft-ietf-l3vpn-ospfv3-pece-07
Thread-Topic: Comments on draft-ietf-l3vpn-ospfv3-pece-07
Thread-Index: Acv2JVCHvhccX4w5QjqaaenWC5ZflgCIXUFQ
Message-ID: <44EE1E31095AE349AC6C3C0B69FFBF02A68512484B@ENFIMBOX1.ad.datcon.co.uk>
References: <AcvjrgW8CKrDGuGTSpWIaLyp8f9P2AAzE/vwAjRLTTAAAO2YcAAG3Ka7AGDDy+AAKMj/wA==> <44EE1E31095AE349AC6C3C0B69FFBF02A684BC09A4@ENFIMBOX1.ad.datcon.co.uk> <BANLkTikvQPaZgZHmWQu0cy_ukj4HWPqYHQ@mail.gmail.com>
In-Reply-To: <BANLkTikvQPaZgZHmWQu0cy_ukj4HWPqYHQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-l3vpn-ospfv3-pece@ietf.org" <draft-ietf-l3vpn-ospfv3-pece@ietf.org>, "l3vpn@ietf.org" <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2011 12:50:31 -0000

Hi Michael,

Thanks for your reply - please see further comments below.

> -----Original Message-----
> From: Michael Lundberg [mailto:michaellundberg.ietf@gmail.com]
> Sent: 08 April 2011 20:44
> To: Nick Weeds
> Cc: draft-ietf-l3vpn-ospfv3-pece@ietf.org; l3vpn@ietf.org
> Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
>=20
> Hi Nick,
>=20
> Thanks for your review and comments. Please see below for my comments.
>=20
> On Thu, Mar 31, 2011 at 6:47 AM, Nick Weeds <nick.weeds@metaswitch.com>
> wrote:
> > Hi,
> >
> > The changes in the new draft-ietf-l3vpn-ospfv3-07.txt draft look
> good, but I
> > do have a couple of specific comments.
> >
> >
> >
> > Section 4.3.2 / top of p10
> >
> > The text says that a PE advertises the IPv6 route learned from MP-BGP
> to
> > attached CEs via OSPFv3 if various conditions hold, including:
> >
> > =A0=A0=A0=A0=A0=A0=A0 "No OSPFv3 route to the same prefix exists in the=
 VRF."
> >
> > I think this is too restrictive.=A0 The aim is to allow a choice
> between
> > routing over the VPN and routing over an OSPF backdoor link.=A0 The
> condition
> > above would prevent routing over the VPN if there was already a route
> over
> > an OSPF backdoor link.
> >
> > I believe the correct condition would be that the OSPFv3 decision
> process
> > selects the VPN route as the preferred route.
>=20
> I believe our text is consistent with 4577, which says "If a VRF
> contains both an OSPF-distributed route and a VPN-IPv4 route for the
> same IPv4 prefix, then the OSPF-distributed route is preferred."
> Therefore, as described in the text above, if an OSPFv3 route is
> installed in the VRF for the same prefix as the IPv6 route learned via
> MP-BGP, the OSPFv3 route will be preferred, and the MP-BGP route will
> not be redistributed into OSPF.
>=20
> To get the behavior you are describing, where you want the OSPF
> decision process to prefer either the backbone or the backdoor link,
> requires sham links.  In this case, the OSPF routes from one PE are
> 'tunneled' via MPLS to the other PE and do not appear in the VRF as
> MP-BGP routes.  Therefore, the rules above do not hold as you are only
> comparing OSPF routes, not MP-BGP to OSPF.
>=20


Unfortunately the text you refer to in RFC 4577 also seems to gloss over th=
e complexities involved...

Stepping back, the main function of RFC 4577 and draft-ietf-l3vpn-ospfv3-pe=
ce is to allow a choice between VPN routes and OSPF backdoor routes rather =
than force traffic onto OSPF backdoor routes.

There are two cases: (1) when the backdoor route is an inter-area route (2)=
 when the backdoor route is an intra-area route.

In the inter-area case (1) the solution is to map VPN routes to OSPF inter-=
area prefix LSAs rather than AS-external LSAs according to the OSPF Domain =
ID configuration (as described in RFC 4577 section 4.2.8).  This allows the=
 OSPF decision process to choose between the VPN route (viewed as an OSPF i=
nter-area route) and any inter-area OSPF backdoor route.  If the OSPF decis=
ion process selects the mapped VPN route then the intent is for the VRF to =
use the VPN route (complete with BGP/MPLS VPN labels) rather than the OSPF =
backdoor route.  As they stand the statements in RFC 4577 and draft-ietf-l3=
vpn-ospfv3-pece both seem to contradict this - taken at face value they bot=
h seem to say that the PE router should always use the OSPF (backdoor) rout=
e rather than BGP (VPN) route.

In the intra-area case (2) the solution is to use a sham link.  This is mor=
e complicated but less subject to ambiguity about VPN routes mapped to OSPF=
 inter-area prefix routes.

If OSPF (backdoor) routes are always preferred to BGP (VPN) routes except i=
n the sham link case, how can the inter-area case possibly allow a choice b=
etween the two on the PE router?
(And if it doesn't allow a choice, what is the point of specifying OSPF Dom=
ain ID configuration and mapping of VPN routes to OSPF inter-area prefix LS=
As?)

Hopefully if we can answer that then we'll understand how to make the draft=
-ietf-l3vpn-ospfv3-pece text clearer.

	Nick.

> > Section 4.3.2.3 / p11
> >
> > The rules 1 and 2 for comparing OSPFv3 Domain IDs state how to
> compare the 6
> > value bytes but not how to compare the 2 type bytes.=A0 I believe the
> rules
> > should match RFC 4577 section 4.2.8.1 rules 1 and 3.=A0 In other words,
> either
> > (1) all 8 (not 6) bytes match, or (2) the 6 byte value fields of both
> > attributes are all zeroes and the type bytes are ignored.=A0 Note that
> in the
> > first case the 2 type bytes must match and in the latter case they
> are
> > ignored.
>=20
> This is a good point.  We will update the text. This text should have
> been updated when we removed the use of the single BGP extended
> community and reverted back to the OSPF Domain ID extended community
> attribute.
>=20
> Thanks,
> Michael
>=20
> >
> > =A0=A0=A0=A0=A0=A0=A0 Nick.
> >
> > Nick Weeds
> > Software Engineer, Network Technologies Division
> > Metaswitch Networks
> >
> > nick.weeds@metaswitch.com
> > +44 (0) 20 8366 1177
> > www.metaswitch.com

From Internet-Drafts@ietf.org  Tue Apr 12 17:00:03 2011
Return-Path: <Internet-Drafts@ietf.org>
X-Original-To: l3vpn@ietfc.amsl.com
Delivered-To: l3vpn@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 205A9E0879; Tue, 12 Apr 2011 17:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.103
X-Spam-Level: 
X-Spam-Status: No, score=-102.103 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4CSyyP+54mz; Tue, 12 Apr 2011 17:00:02 -0700 (PDT)
Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A062FE076C; Tue, 12 Apr 2011 17:00:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action:draft-ietf-l3vpn-ibgp-02.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 3.50
Message-ID: <20110413000002.782.58409.idtracker@ietfc.amsl.com>
Date: Tue, 12 Apr 2011 17:00:02 -0700
Cc: l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 00:00:03 -0000

--NextPart

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           : Internal BGP as PE-CE protocol
	Author(s)       : P. Marques, et al.
	Filename        : draft-ietf-l3vpn-ibgp-02.txt
	Pages           : 17
	Date            : 2011-04-12

This document defines protocol extensions and procedures for BGP
PE-CE router iteration in BGP/MPLS IP VPN [RFC4364] networks.  These
have the objective of making the usage of the BGP/MPLS IP VPN
transparent to the customer network, as far as routing information is
concerned.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ibgp-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-l3vpn-ibgp-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2011-04-12165436.I-D@ietf.org>


--NextPart--

From ben@niven-jenkins.co.uk  Wed Apr 13 10:37:06 2011
Return-Path: <ben@niven-jenkins.co.uk>
X-Original-To: l3vpn@ietfc.amsl.com
Delivered-To: l3vpn@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BFF34E0845; Wed, 13 Apr 2011 10:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.227
X-Spam-Level: 
X-Spam-Status: No, score=-103.227 tagged_above=-999 required=5 tests=[AWL=-1.027, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTB2fn0HVM8T; Wed, 13 Apr 2011 10:37:06 -0700 (PDT)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfc.amsl.com (Postfix) with ESMTP id 415D3E083C; Wed, 13 Apr 2011 10:37:06 -0700 (PDT)
Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-108-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1QA403-0008Qd-8g; Wed, 13 Apr 2011 18:37:07 +0100
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02
Date: Wed, 13 Apr 2011 18:37:04 +0100
Message-Id: <FC6A9836-7B63-44C1-BFC5-3903CED4788A@niven-jenkins.co.uk>
To: l3vpn@ietf.org, idr@ietf.org
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 17:37:06 -0000

L3VPNers & IDRers,

This e-mail is the start of a joint L3VPN & IDR WG Last Call for =
draft-ietf-l3vpn-ibgp-02.

Feedback should be provided to the mailing list(s) and/or the authors.

The Last Call ends midnight PDT 27th April 2011.

You can view the draft here:
http://tools.ietf.org/id/draft-ietf-l3vpn-ibgp-02.txt

Thanks
Ben (on behalf of the L3VPN & IDR chairs)=

From ben@niven-jenkins.co.uk  Thu Apr 14 12:11:14 2011
Return-Path: <ben@niven-jenkins.co.uk>
X-Original-To: l3vpn@ietfc.amsl.com
Delivered-To: l3vpn@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7DFB6E07FD; Thu, 14 Apr 2011 12:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.307
X-Spam-Level: 
X-Spam-Status: No, score=-102.307 tagged_above=-999 required=5 tests=[AWL=-1.304, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uw0QkGpul2We; Thu, 14 Apr 2011 12:11:13 -0700 (PDT)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfc.amsl.com (Postfix) with ESMTP id D208FE0791; Thu, 14 Apr 2011 12:11:13 -0700 (PDT)
Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-108-devlan.cachelogic.com) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1QARwg-0007GI-Gn; Thu, 14 Apr 2011 20:11:14 +0100
Subject: Re: Joint L3VPN & OSPF WG LC for draft-ietf-l3vpn-ospfv3-pece-07
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
In-Reply-To: <0636D1EB-942D-4416-858E-E698863B141C@niven-jenkins.co.uk>
Date: Thu, 14 Apr 2011 20:11:12 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B258B9EF-8B78-4B44-AB74-4AB7A36E60A9@niven-jenkins.co.uk>
References: <0636D1EB-942D-4416-858E-E698863B141C@niven-jenkins.co.uk>
To: Benjamin Niven-Jenkins <ben@niven-jenkins.co.uk>
X-Mailer: Apple Mail (2.1084)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Cc: ospf@ietf.org, L3VPN WG mailing list <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 19:11:14 -0000

L3VPNers & OSPFers,

This joint WG LC has now ended. One person commented on the L3VPN =
mailing list:

http://www.ietf.org/mail-archive/web/l3vpn/current/msg02903.html

Can the authors continue to work to resolve the comments and produce an =
updated draft.

Thanks
Ben
=20
On 16 Mar 2011, at 07:44, Benjamin Niven-Jenkins wrote:

> L3VPNers & OSPFers,
>=20
> You may recall that back in January 2010 we pulled =
draft-ietf-l3vpn-ospfv3-pece-04 out of the RFC Editor's queue because we =
had forgotten to solicit a review from the OSPF WG. See =
http://www.ietf.org/mail-archive/web/ospf/current/msg05658.htm for more =
info on that.
>=20
> The OSPF WG raised some comments on the draft, which has gone through =
a few revisions and draft-ietf-l3vpn-ospfv3-pece-07 is thought to =
address all the previous comments raised.
>=20
> This e-mail is therefore the start of a joint L3VPN & OSPF WG Last =
Call for the updated draft. It is restricted to changes made since the =
last review (i.e. changes between -04 and -07).
>=20
> Due to the proximity of IETF80 we are allowing 4 weeks for the LC. =
Please provide any further comments on the changes by midnight PDT on =
the 13th April 2011.
>=20
> You can view -07 of the draft here:
> http://tools.ietf.org/id/draft-ietf-l3vpn-ospfv3-pece-07.txt
>=20
> You can view a diff between -04 and -07 here:
> =
http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-l3vpn-ospfv3-pece-04&url2=3D=
draft-ietf-l3vpn-ospfv3-pece-07
>=20
> Thanks
> Ben (on behalf of the L3VPN & OSPF chairs)
>=20


From acee.lindem@ericsson.com  Fri Apr 15 08:51:21 2011
Return-Path: <acee.lindem@ericsson.com>
X-Original-To: l3vpn@ietfc.amsl.com
Delivered-To: l3vpn@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 74521E0745 for <l3vpn@ietfc.amsl.com>; Fri, 15 Apr 2011 08:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.489
X-Spam-Level: 
X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=1.110,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBzla9tAlO8y for <l3vpn@ietfc.amsl.com>; Fri, 15 Apr 2011 08:51:17 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 4C192E06A9 for <l3vpn@ietf.org>; Fri, 15 Apr 2011 08:51:17 -0700 (PDT)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3FFpBa0007956; Fri, 15 Apr 2011 10:51:12 -0500
Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.195]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 15 Apr 2011 11:51:05 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: Nick Weeds <nick.weeds@metaswitch.com>
Date: Fri, 15 Apr 2011 11:51:02 -0400
Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
Thread-Topic: Comments on draft-ietf-l3vpn-ospfv3-pece-07
Thread-Index: Acv7hO1t8srXrbrHS8mqgHaj1yxZyA==
Message-ID: <E7FD343F-E00C-41AC-A09D-20B58BBD4CC9@ericsson.com>
References: <AcvjrgW8CKrDGuGTSpWIaLyp8f9P2AAzE/vwAjRLTTAAAO2YcAAG3Ka7AGDDy+AAKMj/wA==> <44EE1E31095AE349AC6C3C0B69FFBF02A684BC09A4@ENFIMBOX1.ad.datcon.co.uk> <BANLkTikvQPaZgZHmWQu0cy_ukj4HWPqYHQ@mail.gmail.com> <44EE1E31095AE349AC6C3C0B69FFBF02A68512484B@ENFIMBOX1.ad.datcon.co.uk>
In-Reply-To: <44EE1E31095AE349AC6C3C0B69FFBF02A68512484B@ENFIMBOX1.ad.datcon.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "l3vpn@ietf.org" <l3vpn@ietf.org>, "draft-ietf-l3vpn-ospfv3-pece@ietf.org" <draft-ietf-l3vpn-ospfv3-pece@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 15:51:21 -0000

Hi Nick,
See inline.=20
On Apr 11, 2011, at 8:50 AM, Nick Weeds wrote:

> Hi Michael,
>=20
> Thanks for your reply - please see further comments below.
>=20
>> -----Original Message-----
>> From: Michael Lundberg [mailto:michaellundberg.ietf@gmail.com]
>> Sent: 08 April 2011 20:44
>> To: Nick Weeds
>> Cc: draft-ietf-l3vpn-ospfv3-pece@ietf.org; l3vpn@ietf.org
>> Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
>>=20
>> Hi Nick,
>>=20
>> Thanks for your review and comments. Please see below for my comments.
>>=20
>> On Thu, Mar 31, 2011 at 6:47 AM, Nick Weeds <nick.weeds@metaswitch.com>
>> wrote:
>>> Hi,
>>>=20
>>> The changes in the new draft-ietf-l3vpn-ospfv3-07.txt draft look
>> good, but I
>>> do have a couple of specific comments.
>>>=20
>>>=20
>>>=20
>>> Section 4.3.2 / top of p10
>>>=20
>>> The text says that a PE advertises the IPv6 route learned from MP-BGP
>> to
>>> attached CEs via OSPFv3 if various conditions hold, including:
>>>=20
>>>         "No OSPFv3 route to the same prefix exists in the VRF."
>>>=20
>>> I think this is too restrictive.  The aim is to allow a choice
>> between
>>> routing over the VPN and routing over an OSPF backdoor link.  The
>> condition
>>> above would prevent routing over the VPN if there was already a route
>> over
>>> an OSPF backdoor link.
>>>=20
>>> I believe the correct condition would be that the OSPFv3 decision
>> process
>>> selects the VPN route as the preferred route.
>>=20
>> I believe our text is consistent with 4577, which says "If a VRF
>> contains both an OSPF-distributed route and a VPN-IPv4 route for the
>> same IPv4 prefix, then the OSPF-distributed route is preferred."
>> Therefore, as described in the text above, if an OSPFv3 route is
>> installed in the VRF for the same prefix as the IPv6 route learned via
>> MP-BGP, the OSPFv3 route will be preferred, and the MP-BGP route will
>> not be redistributed into OSPF.
>>=20
>> To get the behavior you are describing, where you want the OSPF
>> decision process to prefer either the backbone or the backdoor link,
>> requires sham links.  In this case, the OSPF routes from one PE are
>> 'tunneled' via MPLS to the other PE and do not appear in the VRF as
>> MP-BGP routes.  Therefore, the rules above do not hold as you are only
>> comparing OSPF routes, not MP-BGP to OSPF.
>>=20
>=20
>=20
> Unfortunately the text you refer to in RFC 4577 also seems to gloss over =
the complexities involved...
>=20
> Stepping back, the main function of RFC 4577 and draft-ietf-l3vpn-ospfv3-=
pece is to allow a choice between VPN routes and OSPF backdoor routes rathe=
r than force traffic onto OSPF backdoor routes.
>=20
> There are two cases: (1) when the backdoor route is an inter-area route (=
2) when the backdoor route is an intra-area route.
>=20
> In the inter-area case (1) the solution is to map VPN routes to OSPF inte=
r-area prefix LSAs rather than AS-external LSAs according to the OSPF Domai=
n ID configuration (as described in RFC 4577 section 4.2.8).  This allows t=
he OSPF decision process to choose between the VPN route (viewed as an OSPF=
 inter-area route) and any inter-area OSPF backdoor route.  If the OSPF dec=
ision process selects the mapped VPN route then the intent is for the VRF t=
o use the VPN route (complete with BGP/MPLS VPN labels) rather than the OSP=
F backdoor route.  As they stand the statements in RFC 4577 and draft-ietf-=
l3vpn-ospfv3-pece both seem to contradict this - taken at face value they b=
oth seem to say that the PE router should always use the OSPF (backdoor) ro=
ute rather than BGP (VPN) route.
>=20
> In the intra-area case (2) the solution is to use a sham link.  This is m=
ore complicated but less subject to ambiguity about VPN routes mapped to OS=
PF inter-area prefix routes.
>=20
> If OSPF (backdoor) routes are always preferred to BGP (VPN) routes except=
 in the sham link case, how can the inter-area case possibly allow a choice=
 between the two on the PE router?
> (And if it doesn't allow a choice, what is the point of specifying OSPF D=
omain ID configuration and mapping of VPN routes to OSPF inter-area prefix =
LSAs?)

I agree that this is possible but it would be strange area topology indeed.=
 Since the metric is not carried in BGP, it is a matter of local policy in =
the PE and one could have some subset of the site using the inter-area path=
 over the backdoor link and another using the VPN path. But again, I don't =
believe this is a common use case.=20

Thanks,
Acee



>=20
> Hopefully if we can answer that then we'll understand how to make the dra=
ft-ietf-l3vpn-ospfv3-pece text clearer.
>=20
> 	Nick.
>=20
>>> Section 4.3.2.3 / p11
>>>=20
>>> The rules 1 and 2 for comparing OSPFv3 Domain IDs state how to
>> compare the 6
>>> value bytes but not how to compare the 2 type bytes.  I believe the
>> rules
>>> should match RFC 4577 section 4.2.8.1 rules 1 and 3.  In other words,
>> either
>>> (1) all 8 (not 6) bytes match, or (2) the 6 byte value fields of both
>>> attributes are all zeroes and the type bytes are ignored.  Note that
>> in the
>>> first case the 2 type bytes must match and in the latter case they
>> are
>>> ignored.
>>=20
>> This is a good point.  We will update the text. This text should have
>> been updated when we removed the use of the single BGP extended
>> community and reverted back to the OSPF Domain ID extended community
>> attribute.
>>=20
>> Thanks,
>> Michael
>>=20
>>>=20
>>>         Nick.
>>>=20
>>> Nick Weeds
>>> Software Engineer, Network Technologies Division
>>> Metaswitch Networks
>>>=20
>>> nick.weeds@metaswitch.com
>>> +44 (0) 20 8366 1177
>>> www.metaswitch.com


From nick.weeds@metaswitch.com  Fri Apr 15 09:19:45 2011
Return-Path: <nick.weeds@metaswitch.com>
X-Original-To: l3vpn@ietfc.amsl.com
Delivered-To: l3vpn@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 55588E0699 for <l3vpn@ietfc.amsl.com>; Fri, 15 Apr 2011 09:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTp7W4OwdgGw for <l3vpn@ietfc.amsl.com>; Fri, 15 Apr 2011 09:19:41 -0700 (PDT)
Received: from enfiets1.dataconnection.com (enfiets1.dataconnection.com [192.91.191.38]) by ietfc.amsl.com (Postfix) with ESMTP id BE0BAE075C for <l3vpn@ietf.org>; Fri, 15 Apr 2011 09:19:40 -0700 (PDT)
Received: from enficas1.datcon.co.uk (172.18.4.14) by enfiets1.dataconnection.com (172.18.4.21) with Microsoft SMTP Server (TLS) id 8.3.137.0; Fri, 15 Apr 2011 17:21:25 +0100
Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by enficas1.datcon.co.uk ([172.18.4.14]) with mapi; Fri, 15 Apr 2011 17:19:39 +0100
From: Nick Weeds <nick.weeds@metaswitch.com>
To: Acee Lindem <acee.lindem@ericsson.com>
Date: Fri, 15 Apr 2011 17:19:37 +0100
Subject: RE: Comments on draft-ietf-l3vpn-ospfv3-pece-07
Thread-Topic: Comments on draft-ietf-l3vpn-ospfv3-pece-07
Thread-Index: Acv7hO1t8srXrbrHS8mqgHaj1yxZyAAAjr6Q
Message-ID: <44EE1E31095AE349AC6C3C0B69FFBF02A6866D8B74@ENFIMBOX1.ad.datcon.co.uk>
References: <AcvjrgW8CKrDGuGTSpWIaLyp8f9P2AAzE/vwAjRLTTAAAO2YcAAG3Ka7AGDDy+AAKMj/wA==> <44EE1E31095AE349AC6C3C0B69FFBF02A684BC09A4@ENFIMBOX1.ad.datcon.co.uk> <BANLkTikvQPaZgZHmWQu0cy_ukj4HWPqYHQ@mail.gmail.com> <44EE1E31095AE349AC6C3C0B69FFBF02A68512484B@ENFIMBOX1.ad.datcon.co.uk> <E7FD343F-E00C-41AC-A09D-20B58BBD4CC9@ericsson.com>
In-Reply-To: <E7FD343F-E00C-41AC-A09D-20B58BBD4CC9@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-l3vpn-ospfv3-pece@tools.ietf.org" <draft-ietf-l3vpn-ospfv3-pece@tools.ietf.org>, "l3vpn@ietf.org" <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 16:19:45 -0000

Hi Acee,

We don't seem to be thinking of the same use case - please see below ...

> -----Original Message-----
> From: Acee Lindem [mailto:acee.lindem@ericsson.com]
> Sent: 15 April 2011 16:51
> To: Nick Weeds
> Cc: Michael Lundberg; draft-ietf-l3vpn-ospfv3-pece@ietf.org;
> l3vpn@ietf.org
> Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
>=20
> Hi Nick,
> See inline.
> On Apr 11, 2011, at 8:50 AM, Nick Weeds wrote:
>=20
> > Hi Michael,
> >
> > Thanks for your reply - please see further comments below.
> >
> >> -----Original Message-----
> >> From: Michael Lundberg [mailto:michaellundberg.ietf@gmail.com]
> >> Sent: 08 April 2011 20:44
> >> To: Nick Weeds
> >> Cc: draft-ietf-l3vpn-ospfv3-pece@ietf.org; l3vpn@ietf.org
> >> Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
> >>
> >> Hi Nick,
> >>
> >> Thanks for your review and comments. Please see below for my
> comments.
> >>
> >> On Thu, Mar 31, 2011 at 6:47 AM, Nick Weeds
> <nick.weeds@metaswitch.com>
> >> wrote:
> >>> Hi,
> >>>
> >>> The changes in the new draft-ietf-l3vpn-ospfv3-07.txt draft look
> >> good, but I
> >>> do have a couple of specific comments.
> >>>
> >>>
> >>>
> >>> Section 4.3.2 / top of p10
> >>>
> >>> The text says that a PE advertises the IPv6 route learned from MP-
> BGP
> >> to
> >>> attached CEs via OSPFv3 if various conditions hold, including:
> >>>
> >>>         "No OSPFv3 route to the same prefix exists in the VRF."
> >>>
> >>> I think this is too restrictive.  The aim is to allow a choice
> >> between
> >>> routing over the VPN and routing over an OSPF backdoor link.  The
> >> condition
> >>> above would prevent routing over the VPN if there was already a
> route
> >> over
> >>> an OSPF backdoor link.
> >>>
> >>> I believe the correct condition would be that the OSPFv3 decision
> >> process
> >>> selects the VPN route as the preferred route.
> >>
> >> I believe our text is consistent with 4577, which says "If a VRF
> >> contains both an OSPF-distributed route and a VPN-IPv4 route for the
> >> same IPv4 prefix, then the OSPF-distributed route is preferred."
> >> Therefore, as described in the text above, if an OSPFv3 route is
> >> installed in the VRF for the same prefix as the IPv6 route learned
> via
> >> MP-BGP, the OSPFv3 route will be preferred, and the MP-BGP route
> will
> >> not be redistributed into OSPF.
> >>
> >> To get the behavior you are describing, where you want the OSPF
> >> decision process to prefer either the backbone or the backdoor link,
> >> requires sham links.  In this case, the OSPF routes from one PE are
> >> 'tunneled' via MPLS to the other PE and do not appear in the VRF as
> >> MP-BGP routes.  Therefore, the rules above do not hold as you are
> only
> >> comparing OSPF routes, not MP-BGP to OSPF.
> >>
> >
> >
> > Unfortunately the text you refer to in RFC 4577 also seems to gloss
> over the complexities involved...
> >
> > Stepping back, the main function of RFC 4577 and draft-ietf-l3vpn-
> ospfv3-pece is to allow a choice between VPN routes and OSPF backdoor
> routes rather than force traffic onto OSPF backdoor routes.
> >
> > There are two cases: (1) when the backdoor route is an inter-area
> route (2) when the backdoor route is an intra-area route.
> >
> > In the inter-area case (1) the solution is to map VPN routes to OSPF
> inter-area prefix LSAs rather than AS-external LSAs according to the
> OSPF Domain ID configuration (as described in RFC 4577 section 4.2.8).
> This allows the OSPF decision process to choose between the VPN route
> (viewed as an OSPF inter-area route) and any inter-area OSPF backdoor
> route.  If the OSPF decision process selects the mapped VPN route then
> the intent is for the VRF to use the VPN route (complete with BGP/MPLS
> VPN labels) rather than the OSPF backdoor route.  As they stand the
> statements in RFC 4577 and draft-ietf-l3vpn-ospfv3-pece both seem to
> contradict this - taken at face value they both seem to say that the PE
> router should always use the OSPF (backdoor) route rather than BGP
> (VPN) route.
> >
> > In the intra-area case (2) the solution is to use a sham link.  This
> is more complicated but less subject to ambiguity about VPN routes
> mapped to OSPF inter-area prefix routes.
> >
> > If OSPF (backdoor) routes are always preferred to BGP (VPN) routes
> except in the sham link case, how can the inter-area case possibly
> allow a choice between the two on the PE router?
> > (And if it doesn't allow a choice, what is the point of specifying
> OSPF Domain ID configuration and mapping of VPN routes to OSPF inter-
> area prefix LSAs?)
>=20
> I agree that this is possible but it would be strange area topology
> indeed. Since the metric is not carried in BGP, it is a matter of local
> policy in the PE and one could have some subset of the site using the
> inter-area path over the backdoor link and another using the VPN path.
> But again, I don't believe this is a common use case.
>=20
> Thanks,
> Acee

A couple of points:

(1) The metric is carried in the BGP Multi-Exit Descriminator, as specified=
 at the end of draft section 4.3.1 (and also in RFC 4577).  I believe the p=
oint of RFC 4577 and of the draft is that extra information carried on the =
VPN route allows the BGP (VPN) route to be mapped to an OSPF route, so that=
 the VPN route can be preferred to the OSPF backdoor route.  This function =
would be broken if the OSPF backdoor route is always preferred to the BGP (=
VPN) route.

(2) I don't understand why you say the area topology is strange.  As far as=
 I can see it's the only area topology where mapping of BGP routes to OSPF =
inter-area routes has any effect on routing, and therefore it is the mainli=
ne case for much of the draft.

	Nick.

>=20
>=20
>=20
> >
> > Hopefully if we can answer that then we'll understand how to make the
> draft-ietf-l3vpn-ospfv3-pece text clearer.
> >
> > 	Nick.
> >
> >>> Section 4.3.2.3 / p11
> >>>
> >>> The rules 1 and 2 for comparing OSPFv3 Domain IDs state how to
> >> compare the 6
> >>> value bytes but not how to compare the 2 type bytes.  I believe the
> >> rules
> >>> should match RFC 4577 section 4.2.8.1 rules 1 and 3.  In other
> words,
> >> either
> >>> (1) all 8 (not 6) bytes match, or (2) the 6 byte value fields of
> both
> >>> attributes are all zeroes and the type bytes are ignored.  Note
> that
> >> in the
> >>> first case the 2 type bytes must match and in the latter case they
> >> are
> >>> ignored.
> >>
> >> This is a good point.  We will update the text. This text should
> have
> >> been updated when we removed the use of the single BGP extended
> >> community and reverted back to the OSPF Domain ID extended community
> >> attribute.
> >>
> >> Thanks,
> >> Michael
> >>
> >>>
> >>>         Nick.
> >>>
> >>> Nick Weeds
> >>> Software Engineer, Network Technologies Division
> >>> Metaswitch Networks
> >>>
> >>> nick.weeds@metaswitch.com
> >>> +44 (0) 20 8366 1177
> >>> www.metaswitch.com


From acee.lindem@ericsson.com  Fri Apr 15 09:44:02 2011
Return-Path: <acee.lindem@ericsson.com>
X-Original-To: l3vpn@ietfc.amsl.com
Delivered-To: l3vpn@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3383C13002B for <l3vpn@ietfc.amsl.com>; Fri, 15 Apr 2011 09:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.559
X-Spam-Level: 
X-Spam-Status: No, score=-5.559 tagged_above=-999 required=5 tests=[AWL=1.040,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3IG3pkT7Zi5 for <l3vpn@ietfc.amsl.com>; Fri, 15 Apr 2011 09:43:58 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id F1A6E130025 for <l3vpn@ietf.org>; Fri, 15 Apr 2011 09:43:57 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3FGhtHs031572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Apr 2011 11:43:55 -0500
Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.195]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 15 Apr 2011 12:43:54 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: Nick Weeds <nick.weeds@metaswitch.com>
Date: Fri, 15 Apr 2011 12:43:52 -0400
Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
Thread-Topic: Comments on draft-ietf-l3vpn-ospfv3-pece-07
Thread-Index: Acv7jE55XEbB0ZbuRiajTNEwAnSTxw==
Message-ID: <3C066AF7-4E6C-4FD7-AB9B-E77722494ACC@ericsson.com>
References: <AcvjrgW8CKrDGuGTSpWIaLyp8f9P2AAzE/vwAjRLTTAAAO2YcAAG3Ka7AGDDy+AAKMj/wA==> <44EE1E31095AE349AC6C3C0B69FFBF02A684BC09A4@ENFIMBOX1.ad.datcon.co.uk> <BANLkTikvQPaZgZHmWQu0cy_ukj4HWPqYHQ@mail.gmail.com> <44EE1E31095AE349AC6C3C0B69FFBF02A68512484B@ENFIMBOX1.ad.datcon.co.uk> <E7FD343F-E00C-41AC-A09D-20B58BBD4CC9@ericsson.com> <44EE1E31095AE349AC6C3C0B69FFBF02A6866D8B74@ENFIMBOX1.ad.datcon.co.uk>
In-Reply-To: <44EE1E31095AE349AC6C3C0B69FFBF02A6866D8B74@ENFIMBOX1.ad.datcon.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-l3vpn-ospfv3-pece@tools.ietf.org" <draft-ietf-l3vpn-ospfv3-pece@tools.ietf.org>, "l3vpn@ietf.org" <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 16:44:02 -0000

Hi Nick,

See inline.=20

Michael and other draft Authors,=20

PLease see one WG last call comment inline.=20


On Apr 15, 2011, at 12:19 PM, Nick Weeds wrote:

> Hi Acee,
>=20
> We don't seem to be thinking of the same use case - please see below ...
>=20
>> -----Original Message-----
>> From: Acee Lindem [mailto:acee.lindem@ericsson.com]
>> Sent: 15 April 2011 16:51
>> To: Nick Weeds
>> Cc: Michael Lundberg; draft-ietf-l3vpn-ospfv3-pece@ietf.org;
>> l3vpn@ietf.org
>> Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
>>=20
>> Hi Nick,
>> See inline.
>> On Apr 11, 2011, at 8:50 AM, Nick Weeds wrote:
>>=20
>>> Hi Michael,
>>>=20
>>> Thanks for your reply - please see further comments below.
>>>=20
>>>> -----Original Message-----
>>>> From: Michael Lundberg [mailto:michaellundberg.ietf@gmail.com]
>>>> Sent: 08 April 2011 20:44
>>>> To: Nick Weeds
>>>> Cc: draft-ietf-l3vpn-ospfv3-pece@ietf.org; l3vpn@ietf.org
>>>> Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
>>>>=20
>>>> Hi Nick,
>>>>=20
>>>> Thanks for your review and comments. Please see below for my
>> comments.
>>>>=20
>>>> On Thu, Mar 31, 2011 at 6:47 AM, Nick Weeds
>> <nick.weeds@metaswitch.com>
>>>> wrote:
>>>>> Hi,
>>>>>=20
>>>>> The changes in the new draft-ietf-l3vpn-ospfv3-07.txt draft look
>>>> good, but I
>>>>> do have a couple of specific comments.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Section 4.3.2 / top of p10
>>>>>=20
>>>>> The text says that a PE advertises the IPv6 route learned from MP-
>> BGP
>>>> to
>>>>> attached CEs via OSPFv3 if various conditions hold, including:
>>>>>=20
>>>>>        "No OSPFv3 route to the same prefix exists in the VRF."
>>>>>=20
>>>>> I think this is too restrictive.  The aim is to allow a choice
>>>> between
>>>>> routing over the VPN and routing over an OSPF backdoor link.  The
>>>> condition
>>>>> above would prevent routing over the VPN if there was already a
>> route
>>>> over
>>>>> an OSPF backdoor link.
>>>>>=20
>>>>> I believe the correct condition would be that the OSPFv3 decision
>>>> process
>>>>> selects the VPN route as the preferred route.
>>>>=20
>>>> I believe our text is consistent with 4577, which says "If a VRF
>>>> contains both an OSPF-distributed route and a VPN-IPv4 route for the
>>>> same IPv4 prefix, then the OSPF-distributed route is preferred."
>>>> Therefore, as described in the text above, if an OSPFv3 route is
>>>> installed in the VRF for the same prefix as the IPv6 route learned
>> via
>>>> MP-BGP, the OSPFv3 route will be preferred, and the MP-BGP route
>> will
>>>> not be redistributed into OSPF.
>>>>=20
>>>> To get the behavior you are describing, where you want the OSPF
>>>> decision process to prefer either the backbone or the backdoor link,
>>>> requires sham links.  In this case, the OSPF routes from one PE are
>>>> 'tunneled' via MPLS to the other PE and do not appear in the VRF as
>>>> MP-BGP routes.  Therefore, the rules above do not hold as you are
>> only
>>>> comparing OSPF routes, not MP-BGP to OSPF.
>>>>=20
>>>=20
>>>=20
>>> Unfortunately the text you refer to in RFC 4577 also seems to gloss
>> over the complexities involved...
>>>=20
>>> Stepping back, the main function of RFC 4577 and draft-ietf-l3vpn-
>> ospfv3-pece is to allow a choice between VPN routes and OSPF backdoor
>> routes rather than force traffic onto OSPF backdoor routes.
>>>=20
>>> There are two cases: (1) when the backdoor route is an inter-area
>> route (2) when the backdoor route is an intra-area route.
>>>=20
>>> In the inter-area case (1) the solution is to map VPN routes to OSPF
>> inter-area prefix LSAs rather than AS-external LSAs according to the
>> OSPF Domain ID configuration (as described in RFC 4577 section 4.2.8).
>> This allows the OSPF decision process to choose between the VPN route
>> (viewed as an OSPF inter-area route) and any inter-area OSPF backdoor
>> route.  If the OSPF decision process selects the mapped VPN route then
>> the intent is for the VRF to use the VPN route (complete with BGP/MPLS
>> VPN labels) rather than the OSPF backdoor route.  As they stand the
>> statements in RFC 4577 and draft-ietf-l3vpn-ospfv3-pece both seem to
>> contradict this - taken at face value they both seem to say that the PE
>> router should always use the OSPF (backdoor) route rather than BGP
>> (VPN) route.
>>>=20
>>> In the intra-area case (2) the solution is to use a sham link.  This
>> is more complicated but less subject to ambiguity about VPN routes
>> mapped to OSPF inter-area prefix routes.
>>>=20
>>> If OSPF (backdoor) routes are always preferred to BGP (VPN) routes
>> except in the sham link case, how can the inter-area case possibly
>> allow a choice between the two on the PE router?
>>> (And if it doesn't allow a choice, what is the point of specifying
>> OSPF Domain ID configuration and mapping of VPN routes to OSPF inter-
>> area prefix LSAs?)
>>=20
>> I agree that this is possible but it would be strange area topology
>> indeed. Since the metric is not carried in BGP, it is a matter of local
>> policy in the PE and one could have some subset of the site using the
>> inter-area path over the backdoor link and another using the VPN path.
>> But again, I don't believe this is a common use case.
>>=20
>> Thanks,
>> Acee
>=20
> A couple of points:
>=20
> (1) The metric is carried in the BGP Multi-Exit Descriminator, as specifi=
ed at the end of draft section 4.3.1 (and also in RFC 4577).  I believe the=
 point of RFC 4577 and of the draft is that extra information carried on th=
e VPN route allows the BGP (VPN) route to be mapped to an OSPF route, so th=
at the VPN route can be preferred to the OSPF backdoor route.  This functio=
n would be broken if the OSPF backdoor route is always preferred to the BGP=
 (VPN) route.

You're right and I'd forgotten the BGP portion of RFC 4577. Even though it =
is different than RFC 4577, I suggest using the term "metric" rather than "=
distance". I'd searched for the former in the draft. So the metric is set b=
y the advertising PE.

Authors, please consider this a WG last call comment.=20

   A Multi-Exit-Discriminator (MED) attribute SHOULD also be set to the
   value of the OSPFv3 metric associated with the route plus 1, when
   the OSPFv3 route is redistributed into the MP-BGP.


>=20
> (2) I don't understand why you say the area topology is strange.  As far =
as I can see it's the only area topology where mapping of BGP routes to OSP=
F inter-area routes has any effect on routing, and therefore it is the main=
line case for much of the draft.

By strange, I mean having a non-PE ABR connecting the backdoor link. I say =
ABR since if it were not, you'd need to use a sham link to influence the in=
tra-area routes. But I agree that there is nothing that precludes it.=20

Thanks,
Acee=20


>=20
> 	Nick.
>=20
>>=20
>>=20
>>=20
>>>=20
>>> Hopefully if we can answer that then we'll understand how to make the
>> draft-ietf-l3vpn-ospfv3-pece text clearer.
>>>=20
>>> 	Nick.
>>>=20
>>>>> Section 4.3.2.3 / p11
>>>>>=20
>>>>> The rules 1 and 2 for comparing OSPFv3 Domain IDs state how to
>>>> compare the 6
>>>>> value bytes but not how to compare the 2 type bytes.  I believe the
>>>> rules
>>>>> should match RFC 4577 section 4.2.8.1 rules 1 and 3.  In other
>> words,
>>>> either
>>>>> (1) all 8 (not 6) bytes match, or (2) the 6 byte value fields of
>> both
>>>>> attributes are all zeroes and the type bytes are ignored.  Note
>> that
>>>> in the
>>>>> first case the 2 type bytes must match and in the latter case they
>>>> are
>>>>> ignored.
>>>>=20
>>>> This is a good point.  We will update the text. This text should
>> have
>>>> been updated when we removed the use of the single BGP extended
>>>> community and reverted back to the OSPF Domain ID extended community
>>>> attribute.
>>>>=20
>>>> Thanks,
>>>> Michael
>>>>=20
>>>>>=20
>>>>>        Nick.
>>>>>=20
>>>>> Nick Weeds
>>>>> Software Engineer, Network Technologies Division
>>>>> Metaswitch Networks
>>>>>=20
>>>>> nick.weeds@metaswitch.com
>>>>> +44 (0) 20 8366 1177
>>>>> www.metaswitch.com
>=20


From ben@niven-jenkins.co.uk  Tue Apr 19 07:01:10 2011
Return-Path: <ben@niven-jenkins.co.uk>
X-Original-To: l3vpn@ietfc.amsl.com
Delivered-To: l3vpn@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 08EE7E070F for <l3vpn@ietfc.amsl.com>; Tue, 19 Apr 2011 07:01:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.187
X-Spam-Level: 
X-Spam-Status: No, score=-103.187 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8N7lZgpIdQua for <l3vpn@ietfc.amsl.com>; Tue, 19 Apr 2011 07:01:09 -0700 (PDT)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfc.amsl.com (Postfix) with ESMTP id 30A28E06F8 for <l3vpn@ietf.org>; Tue, 19 Apr 2011 07:01:09 -0700 (PDT)
Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-108-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1QCBUK-0002r2-CX for l3vpn@ietf.org; Tue, 19 Apr 2011 15:01:08 +0100
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: L3VPN WG status
Date: Tue, 19 Apr 2011 15:01:08 +0100
Message-Id: <60C377D7-62F3-4704-8DA7-ADE977E63A09@niven-jenkins.co.uk>
To: L3VPN WG mailing list <l3vpn@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2011 14:01:10 -0000

Colleagues,

As we did not meet face to face in Prague I promised to send a WG status =
update to the mailing list. I have been a little remiss in doing so, but =
better late than never please see below for the current status of work =
within L3VPN

Ben


1. DRAFTS PUBLISHED

None.

2. DRAFTS IN THE RFC EDITOR QUEUE

	A. draft-ietf-l3vpn-2547bis-mcast

This draft is still held up by MISSREFs to two MPLS WG drafts: (1) P2MP =
& MP2MP LDP (draft-ietf-mpls-ldp-p2mp), and (2) OOB mapping for RSVP-TE =
(draft-ietf-mpls-rsvp-te-no-php-oob-mapping).=20

draft-ietf-mpls-ldp-p2mp was in MPLS WG LC until 23 March.

draft-ietf-mpls-rsvp-te-no-php-oob-mapping is still with the MPLS WG.

	B. draft-ietf-l3vpn-2547bis-mcast-bgp

This draft is held up by an EDIT REF to draft-ietf-l3vpn-2547bis-mcast.

	C. draft-ietf-l3vpn-mvpn-considerations

This draft is held up by EDIT REFs to draft-ietf-l3vpn-2547bis-mcast & =
draft-ietf-l3vpn-2547bis-mcast-bgp.

	D. draft-ietf-l3vpn-mvpn-spmsi-joins

This draft was approved just after IETF79 (19th Nov) and is currently =
held up by an EDIT REF	to draft-ietf-l3vpn-2547bis-mcast.

3. DRAFT IN OR PAST WG LAST CALL

	A. draft-ietf-l3vpn-mvpn-infra-addrs

This draft is currently under IESG evaluation with two outstanding =
DISCUSSes. A new version has been produced and I will work with the =
authors and IESG to clear the DISCUSSes.

	B. draft-ietf-l3vpn-ospfv3-pece

The joint L3VPN & OSPF WG LC ended on 13th April. One person commented =
and comment resolution is still ongoing between the authors and the =
commenter.

	C. draft-ietf-l3vpn-ibgp

A joint L3VPN & IDR WG LC was initiated for this draft on 13th April and =
will end at midnight PDT on 27th April 2011.

4. ACTIVE WG DRAFTS

	draft-ietf-l3vpn-acceptown-community

No change since IETF79. The authors believe the draft is complete but =
would prefer to wait for an implementation to be produced before =
proceeding to WG LC.

5. EXPIRED DRAFTS

None.

6. OTHER WG WORK / ISSUES / ETC.

The new WG charter and milestones were approved by the IESG and =
published in March.

	draft-rekhter-mvpn-wildcard-spmsi & =
draft-rosen-l3vpn-mvpn-wildcards

The authors have agreed to merge these two drafts into a single combined =
draft and following the merge we will poll the WG to judge consensus to =
adopt the merged draft as a WG draft.

	draft-rosen-l3vpn-mvpn-extranet & =
draft-raggarwa-l3vpn-bgp-mvpn-extranet

The authors have agreed to merge these two drafts into a single combined =
draft and following the merge we will poll the WG to judge consensus to =
adopt the merged draft as a WG draft.



From pedro.r.marques@gmail.com  Tue Apr 19 10:14:55 2011
Return-Path: <pedro.r.marques@gmail.com>
X-Original-To: l3vpn@ietfc.amsl.com
Delivered-To: l3vpn@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B80A8E0821; Tue, 19 Apr 2011 10:14:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.779
X-Spam-Level: 
X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_INTEREST=3.579, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n++tAMRCPIj0; Tue, 19 Apr 2011 10:14:55 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id DD4E4E079D; Tue, 19 Apr 2011 10:14:54 -0700 (PDT)
Received: by iwn39 with SMTP id 39so6535500iwn.31 for <multiple recipients>; Tue, 19 Apr 2011 10:14:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Bc+elWflTtq7k9lgfJQpKgcJThwIFhlaMX8vJOuqdTk=; b=usR6L04yoO0ejGGaFkpJVh7b4G0TOK8jhMwcWYNcFkmXj1SE5qU3r70Gs0cNONXO/R I8RlAUgphB3XOesCM3DWDwXi9C2Mja7TRo6ROGpVeS3+CPjpYkk3u/5LgDl/uLYXx+2o aBHDpudJ7TsGpUCTzRNPWszfEQhnfOhQ2RF9Y=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tiCrcQNOyaf++z9/KP+mpYRy5d20gr+GiZq6XNUcUkeGlt2Rh6UNJ7K82q0jgA1Rj7 2x4nWZFKk3gULpLOWaYeJuMmK4fBwE94FHCrWOFl99SaAHF8GrrbUKvE2QrO9nj58mdj cZNNYBWPoV9A8VjusNo02Ig61z5kxE3+F7PiM=
MIME-Version: 1.0
Received: by 10.42.230.67 with SMTP id jl3mr2869958icb.512.1303233294476; Tue, 19 Apr 2011 10:14:54 -0700 (PDT)
Received: by 10.42.164.137 with HTTP; Tue, 19 Apr 2011 10:14:54 -0700 (PDT)
In-Reply-To: <5813_1303131845_4DAC36C5_5813_694222_1_4FC3556A36EE3646A09DAA60429F5335063AEF4B@PUEXCBL0.nanterre.francetelecom.fr>
References: <5813_1303131845_4DAC36C5_5813_694222_1_4FC3556A36EE3646A09DAA60429F5335063AEF4B@PUEXCBL0.nanterre.francetelecom.fr>
Date: Tue, 19 Apr 2011 10:14:54 -0700
Message-ID: <BANLkTin0oa1=XKc2AWqN_iTbGZbZk=HDYg@mail.gmail.com>
Subject: Re: [Idr] Comments on draft-ietf-l3vpn-ibgp-02.txt
From: Pedro Marques <pedro.r.marques@gmail.com>
To: stephane.litkowski@orange-ftgroup.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: idr@ietf.org, l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2011 17:14:55 -0000

Stephane,
Thank you for your comments. Answers inline.

On Mon, Apr 18, 2011 at 6:04 AM,  <stephane.litkowski@orange-ftgroup.com> w=
rote:
> Hi all,
>
>
> * Regarding $7 :
>
> If you consider a VPN that spans=A0across multiple service provider ASes,=
 when
> the egress PE is advertising the VPN route (coming from iBGP CE peer at
> ingress PE) towards an eBGP CE,=A0does the PE prepends only his own AS af=
ter
> prepending customer origin AS (as it seems to be mentionned in the statem=
ent
> below), or=A0do you think there is an interrest to prepend the all "backb=
one"
> ASPATH ?=A0:
>
> "When advertising the VRF route to an Exterior BGP peer, a PE
> =A0=A0=A0=A0=A0 router shall apply steps 1 to 3 defined above and subsequ=
ently
> =A0=A0=A0=A0=A0 prepend its own autonomous-system number to the AS_PATH a=
ttribute."
>
> I'm wondering=A0 in some tricky scenarios , when a customer=A0has multipl=
e MPLS
> VPN providers (for backup purpose), if there is a need (like for eBGP PE-=
CE)
> to reflect the backbone ASPATH to prefer the provider with the shortest
> ASPATH length.

That is a good point. In order to be consistent with the eBGP behavior
it is best to
prepend both the AS_PATH of the VPN route and its own autonomous-system
number, in case the AS_PATH is not empty.

>
> * Regarding ATTR_SET attribute and BGP update storage/generation,=A0 I do=
n't
> think that there is an impact on update generation (mainly packing) by
> Service Provider route-reflectors, but I would be interrested if someone =
see
> something bad in this area.

This mechanism has been deployed in production for over 5 years. I'm
not aware of
"something bad" happening. The ATTR_SET attribute doesn't
significantly change the
packing of updates.

> But even if there is no impact (TBC) on
> generating updates by the Service Provider route-reflectors, I think ther=
e
> could be an impact :
> =A0=A0=A0=A0- on memory usage : mainly depending on how much informations=
 are stored
> in ATTR_SET, moreover=A0it would be hard to share datastructures=A0betwee=
n
> different customer routes=A0(as attributes are "customer dependent")

In the worst case scenario, each customer route has its own unique set
of attributes. That
worst case scenario can occur today via the use of communities. The
common case is for
different sets of CE route attributes to be providing useful
information and be advertised through
the VPN network, either with the current ebgp PE-CE interaction or
with the method that is
proposed in this document.

>
> =A0=A0=A0 - on size of BGP datas transmitted on the TCP session and so im=
pact on
> time to transfer it

The added size to updates is statistically insignificant considering
link bandwidth.

>
>
> *=A0It is sometime useful that=A0VPN CEs=A0 advertise special "Backbone"
> communities to the service provider to permit for example for a remote PE=
 to
> select=A0his own=A0prefered egress PE (loadsharing scenario). With ATTR_S=
ET,
> attributes from CE are tunneled and are no more visible from the service
> provider. Due to this, the previous scenario is no more achievable and
> customer can't anymore use Backbone communities to influence service
> provider backbone behavior.

There is no reason to believe that the VPN export policies that
compute the VPN network
attributes cannot impose communities depending on the attributes of
the CE routes. I also
note that this document is not ment to replace but to complement the
existing EBGP based
PE-CE iteration. But contrary to the current mechanism, the default is
to segregate attributes
between the two networks. As the document explains there are several
scenarios in which this
proposal enables a simpler behavior.

regards,
  Pedro.

From stephane.litkowski@orange-ftgroup.com  Wed Apr 20 07:41:56 2011
Return-Path: <stephane.litkowski@orange-ftgroup.com>
X-Original-To: l3vpn@ietfc.amsl.com
Delivered-To: l3vpn@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2256DE0711; Wed, 20 Apr 2011 07:41:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.056
X-Spam-Level: 
X-Spam-Status: No, score=0.056 tagged_above=-999 required=5 tests=[AWL=1.505,  BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_RAND_LETTRS4=0.799,  UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je+7KVJqLhoL; Wed, 20 Apr 2011 07:41:55 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfc.amsl.com (Postfix) with ESMTP id 2FE51E0705; Wed, 20 Apr 2011 07:41:55 -0700 (PDT)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id F0C58C03E5; Wed, 20 Apr 2011 16:41:53 +0200 (CEST)
Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id D69F218003E; Wed, 20 Apr 2011 16:41:53 +0200 (CEST)
Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Apr 2011 16:41:54 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: TR: [Idr] Comments on draft-ietf-l3vpn-ibgp-02.txt
Date: Wed, 20 Apr 2011 16:41:51 +0200
Message-ID: <5813_1303310513_4DAEF0B1_5813_884147_1_4FC3556A36EE3646A09DAA60429F53350640FA2C@PUEXCBL0.nanterre.francetelecom.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] Comments on draft-ietf-l3vpn-ibgp-02.txt
Thread-Index: Acv+tU5slNA8wZESQ5mk1WBbJ1u77gArY8EAAAGJTjA=
From: <stephane.litkowski@orange-ftgroup.com>
To: <pedro.r.marques@gmail.com>
X-OriginalArrivalTime: 20 Apr 2011 14:41:54.0021 (UTC) FILETIME=[17725950:01CBFF69]
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.20.140023
Cc: idr@ietf.org, l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2011 14:41:56 -0000

=20

Hi Pedro,

Thanks for the feedback. Some addings ...


>That is a good point. In order to be consistent with the eBGP behavior
it is best to prepend both the AS_PATH of the VPN route and its own
autonomous-system number, in case the AS_PATH is not empty.

[SLI] ok

>This mechanism has been deployed in production for over 5 years. I'm
not aware of "something bad" happening. The ATTR_SET attribute doesn't
significantly change the packing of updates.

[SLI] I was not aware that this attribute was already used, seems that
JUNOS implements it already.

>In the worst case scenario, each customer route has its own unique set=20
>of attributes. That worst case scenario can occur today via the use of=20
>communities. The common case is for different sets of CE route
attributes to be providing useful information and be advertised through
the VPN network, either with the current ebgp PE-CE interaction or with
the method that is proposed in this document.

> The added size to updates is statistically insignificant considering
link bandwidth.

[SLI] Yes it could be compared to community combinations coming from
CEs. If we do a quick comparison between eBGP and iBGP PE-CE in terms of
size of BGP VPN update , we have the following (not detailled) :
iBGP adds to the VPN route :
	- ATTR_SET attribute overhead (6-7 bytes)
	- iBGP specific attributes within the ATTR_SET :
		OID : 7 bytes (if any)
		ClusterList : from 7 bytes up to ... (if any)
		ASPATH : in fact the overhead is just the "header"
because in case of eBGP AS numbers are transported in ASPATH attribute
of VPN update : 3 bytes (we don't count the AS numbers size)
		Local preference : 7 bytes
		Origin : 4 bytes
	MED,Communities will be present also for eBGP in the VPN update
path attributes (so there is no bug overhead in storing them in
ATTR_SET).=20

So iBGP PE-CE adds (in case of OID/CL present) about 34 bytes to the VPN
BGP update, I took a look at some BGP updates we have, and path
attributes size (MP_(UN)REACH_NLRI removed) is about 100 bytes, so it
adds 30% more overhead.
If we talk only of "link bandwidth" clearly it's insignificant as you
mentionned (but in fact due to TCP windows and potential RTDs between RR
and PE, we are never using all the link BW for a specific session). But
my concerns are ,today, time to transfer the RIB-OUT from the RR to the
PE within is quite slow when the number of VPN routes is huge (PE CPU
and BGP/TCP socket interactions are the bottlenecks -> mainly vendor
implementation dependent :) ) and we need to take care to not introduce
more unneeded overhead in this area.
In case of limited deployment, no big deal, but in case of
generalization of iBGP, maybe (some tests are needed to be sure) this
overhead can reduce the scaling compared to eBGP.

>There is no reason to believe that the VPN export policies that compute

>the VPN network attributes cannot impose communities depending on the=20
>attributes >of the CE routes. I also note that this document is not
ment to replace but to complement the existing EBGP based PE-CE
iteration. But contrary to the current mechanism, the default is to
segregate attributes between the two networks. As the document explains
there are several scenarios in which this proposal enables a simpler
behavior.

[SLI] You are right, we could proceed in this way


Best Regards,

Stephane


***************************************************************************=
*****
IMPORTANT.Les informations contenues dans ce message electronique y compris=
 les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) men=
tionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve=
uillez immediatement le signaler  a l expediteur et effacer ce message=20
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans=
 ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment=
 s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout vi=
rus.

IMPORTANT.This e-mail message and any attachments are strictly confidential=
 and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(=
s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not b=
e liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
***************************************************************************=
*****


From bruno.decraene@orange-ftgroup.com  Tue Apr 26 09:37:04 2011
Return-Path: <bruno.decraene@orange-ftgroup.com>
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 818F6E07EC; Tue, 26 Apr 2011 09:37:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.116
X-Spam-Level: 
X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[AWL=-0.866, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXGqFRqXEol8; Tue, 26 Apr 2011 09:37:03 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 98710E06A6; Tue, 26 Apr 2011 09:37:03 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0B9F0FC4002; Tue, 26 Apr 2011 18:37:10 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id F3AB4FC4001; Tue, 26 Apr 2011 18:37:09 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 26 Apr 2011 18:37:01 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02
Date: Tue, 26 Apr 2011 18:37:00 +0200
Message-ID: <FE8F6A65A433A744964C65B6EDFDC2400223F066@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <FC6A9836-7B63-44C1-BFC5-3903CED4788A@niven-jenkins.co.uk>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02
Thread-Index: Acv6AX72XFF5uHuUTU2mJkhlfrngIgJ+4uaA
References: <FC6A9836-7B63-44C1-BFC5-3903CED4788A@niven-jenkins.co.uk>
From: <bruno.decraene@orange-ftgroup.com>
To: <pedro.r.marques@gmail.com>
X-OriginalArrivalTime: 26 Apr 2011 16:37:01.0359 (UTC) FILETIME=[2B04FBF0:01CC0430]
Cc: l3vpn@ietf.org, idr@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Apr 2011 16:37:04 -0000

Hi Pedro, all,

1) May be some additional text discussing the interaction with inter-AS
option A could be useful. E.g.:
	- I guess both VPN SP should now configure the customer AS on
their ASBR (instead of their own AS number). Or maybe this depend on
whether both ASes support this extension.
	- how SP load balancing between multiple ASBRs is affected
(given that SP LOCAL_PREF is not used anymore by ingress PE)

2) "In all cases where a route containing the ATTR_SET attribute is
   imported, attributes present on the VPN route other than the NEXT_HOP
   attribute are ignored, both from the point of view of route selection
   in the VRF Adj-RIB-in and route advertisement to a CE router. "

The document mostly talks about PE. Could the document explicitly define
how the ATTR_SET attribute is handled by VPN Route Reflector and ASBR
option B? e.g. ATTR_SET is not to be considered by VPN RR and ASBR
option B ?

3) In section 8 "Deployment considerations", IMHO it could be helpful
for SP readers to indicate that in a given VPN, some sites can use iBGP
while other sites can use eBGP.=20

Thanks,
Best regards,
Bruno

> -----Original Message-----
> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of
Ben Niven-Jenkins
> Sent: Wednesday, April 13, 2011 7:37 PM
> To: l3vpn@ietf.org; idr@ietf.org
> Subject: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02
>=20
> L3VPNers & IDRers,
>=20
> This e-mail is the start of a joint L3VPN & IDR WG Last Call for
draft-ietf-l3vpn-ibgp-02.
>=20
> Feedback should be provided to the mailing list(s) and/or the authors.
>=20
> The Last Call ends midnight PDT 27th April 2011.
>=20
> You can view the draft here:
> http://tools.ietf.org/id/draft-ietf-l3vpn-ibgp-02.txt
>=20
> Thanks
> Ben (on behalf of the L3VPN & IDR chairs)
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

From pedro.r.marques@gmail.com  Tue Apr 26 10:25:21 2011
Return-Path: <pedro.r.marques@gmail.com>
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 641F6E0811; Tue, 26 Apr 2011 10:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QH0PfI37Pb9; Tue, 26 Apr 2011 10:25:20 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2313CE07D9; Tue, 26 Apr 2011 10:25:20 -0700 (PDT)
Received: by iyn15 with SMTP id 15so896480iyn.31 for <multiple recipients>; Tue, 26 Apr 2011 10:25:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FYKxJN6xuxebWHqaEBGidRrBTqhErUNw1cjtQBmHXgY=; b=lN6ojCeHVo+QhjrOL2MbdSDik7bus50t8wnd46IXqiGnyFuPzZayCWf2W4Z/j6SCvL avsJxARdmbOK172TzdLx4HdQPKmXKItSuMK9qBrpUCcglxI/nYnM6rr98/AI9N80PSZb fTdxm1cYs911yeKJzqlYGbygg2ZLAvVIoLJrM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=i7IaTVGCT251rckUd0Tf2rZii4eKVfGg9zPgXuTvTMCCsCx9o9LbYINWlez7noPeLl frWvQzrFKmUksDTmOFj2R4LCPePgri50Am29ZJr/v3G8amJApu7dOKJvudC1EL0FbkOy uuHThREATFGwk9ZTrRysAXxfqAzl37nk24/OA=
MIME-Version: 1.0
Received: by 10.43.48.130 with SMTP id uw2mr1193668icb.312.1303838719395; Tue, 26 Apr 2011 10:25:19 -0700 (PDT)
Received: by 10.42.170.6 with HTTP; Tue, 26 Apr 2011 10:25:19 -0700 (PDT)
In-Reply-To: <FE8F6A65A433A744964C65B6EDFDC2400223F066@ftrdmel0.rd.francetelecom.fr>
References: <FC6A9836-7B63-44C1-BFC5-3903CED4788A@niven-jenkins.co.uk> <FE8F6A65A433A744964C65B6EDFDC2400223F066@ftrdmel0.rd.francetelecom.fr>
Date: Tue, 26 Apr 2011 10:25:19 -0700
Message-ID: <BANLkTikY-beZA0VCUsXKDmWM+++Gud658w@mail.gmail.com>
Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02
From: Pedro Marques <pedro.r.marques@gmail.com>
To: bruno.decraene@orange-ftgroup.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: l3vpn@ietf.org, idr@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Apr 2011 17:25:21 -0000

Bruno,
Answers inline.

On Tue, Apr 26, 2011 at 9:37 AM,  <bruno.decraene@orange-ftgroup.com> wrote=
:
> Hi Pedro, all,
>
> 1) May be some additional text discussing the interaction with inter-AS
> option A could be useful. E.g.:
> =A0 =A0 =A0 =A0- I guess both VPN SP should now configure the customer AS=
 on
> their ASBR (instead of their own AS number). Or maybe this depend on
> whether both ASes support this extension.

I'm not sure Inter-AS option A is relevant to this document. By
definition option The document doesn't propose any modification in
operation of option A.
It does define procedures of how routes from a VRF in the customer AS
interops with a VRF in the SP AS, such as the ones used in option A.

> =A0 =A0 =A0 =A0- how SP load balancing between multiple ASBRs is affected
> (given that SP LOCAL_PREF is not used anymore by ingress PE)

The ATTR_SET attribute allows a solution to preserve the customer
LOCAL_PREF; it doesn't and shouldn't (imho) prescribe policy
mechanisms that may overwrite that LOCAL_PREF.

The ATTR_SET attribute along with the ability of running VRFs on
different ASes (e.g. the customer AS) are intended to address a
particular set of scenarios which tend to be disjoint, as far as i
know, from the scenarios where option A is used.

The first is intended to allow customer managed inter-as route
exchanges, while the later is a provider managed solution. They should
inter-operate but not necessarily overlap for the same customer.

Unless you do have a scenario in mind where it would be helpful to use
ATTR_SET for SP managed inter-as with option A.... If so please
describe the issue you are trying to address. I'd be more than happy
to try to make the mechanism more useful but at the moment i'm not
aware of an application.

The only scenario i can think of is one where a provider is internally
using multiple ASes and would like to make that irrelevant to the
customer; but in that scenario option A has a significant number of
issues which are beyond the scope of what we can address with this
document, imho. By the time one addresses these you get option B, for
which this document is relevant.

>
> 2) "In all cases where a route containing the ATTR_SET attribute is
> =A0 imported, attributes present on the VPN route other than the NEXT_HOP
> =A0 attribute are ignored, both from the point of view of route selection
> =A0 in the VRF Adj-RIB-in and route advertisement to a CE router. "
>
> The document mostly talks about PE. Could the document explicitly define
> how the ATTR_SET attribute is handled by VPN Route Reflector and ASBR
> option B? e.g. ATTR_SET is not to be considered by VPN RR and ASBR
> option B ?

The ATTR_SET attribute is transparent to VPN Route Reflectors and ASBRs.

>
> 3) In section 8 "Deployment considerations", IMHO it could be helpful
> for SP readers to indicate that in a given VPN, some sites can use iBGP
> while other sites can use eBGP.

They could as a transition mechanism, specially. Section 7 describes
how this would work from a protocol standpoint.

If you have concrete applications, i'd be happy to highlight them. In
abstract i'm not sure that we would be adding value just by stating
that one could have both iBGP (in customer-as VRFs) and eBGP (in
provider-as VRFs) without the context of "why would that be a good
idea ?"...


>
> Thanks,
> Best regards,
> Bruno
>
>> -----Original Message-----
>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of
> Ben Niven-Jenkins
>> Sent: Wednesday, April 13, 2011 7:37 PM
>> To: l3vpn@ietf.org; idr@ietf.org
>> Subject: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02
>>
>> L3VPNers & IDRers,
>>
>> This e-mail is the start of a joint L3VPN & IDR WG Last Call for
> draft-ietf-l3vpn-ibgp-02.
>>
>> Feedback should be provided to the mailing list(s) and/or the authors.
>>
>> The Last Call ends midnight PDT 27th April 2011.
>>
>> You can view the draft here:
>> http://tools.ietf.org/id/draft-ietf-l3vpn-ibgp-02.txt
>>
>> Thanks
>> Ben (on behalf of the L3VPN & IDR chairs)
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>

From bruno.decraene@orange-ftgroup.com  Wed Apr 27 02:21:54 2011
Return-Path: <bruno.decraene@orange-ftgroup.com>
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 A10D2E068F; Wed, 27 Apr 2011 02:21:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=-0.650,  BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJVQpw+zHUnn; Wed, 27 Apr 2011 02:21:50 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 26FF0E0717; Wed, 27 Apr 2011 02:21:49 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0E0376C8002; Wed, 27 Apr 2011 11:22:24 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 00D326C0006; Wed, 27 Apr 2011 11:22:23 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 27 Apr 2011 11:21:48 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02
Date: Wed, 27 Apr 2011 11:21:47 +0200
Message-ID: <FE8F6A65A433A744964C65B6EDFDC2400223F177@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <BANLkTikY-beZA0VCUsXKDmWM+++Gud658w@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02
Thread-Index: AcwENuxRvjUetwiVTjyTbIowFE5H6AAdOqIA
References: <FC6A9836-7B63-44C1-BFC5-3903CED4788A@niven-jenkins.co.uk><FE8F6A65A433A744964C65B6EDFDC2400223F066@ftrdmel0.rd.francetelecom.fr> <BANLkTikY-beZA0VCUsXKDmWM+++Gud658w@mail.gmail.com>
From: <bruno.decraene@orange-ftgroup.com>
To: <pedro.r.marques@gmail.com>
X-OriginalArrivalTime: 27 Apr 2011 09:21:48.0597 (UTC) FILETIME=[89037650:01CC04BC]
Cc: idr@ietf.org, l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Apr 2011 09:21:54 -0000

Pedro,

Thanks for your answer. Comments inline.

> > 1) May be some additional text discussing the interaction with =
inter-AS
> > option A could be useful. E.g.:
> > =A0 =A0 =A0 =A0- I guess both VPN SP should now configure the =
customer AS on
> > their ASBR (instead of their own AS number). Or maybe this depend on
> > whether both ASes support this extension.
>=20
> I'm not sure Inter-AS option A is relevant to this document. By
> definition option The document doesn't propose any modification in
> operation of option A.

How do you handle the following topology: ?

AS1 |    AS10     |    AS11     | AS1
CE1---PE1---ASBR1---ASBR2---PE2---CE2=09

CE1-PE1 and CE2-PE2 are iBGP sessions.
ASBR1 use inter AS option A. Should they use an iBGP session compliant =
with this document or a regular eBGP session? In the latter case, the =
ATTR_SET attribute will be dropped by ASBR and hence will not be =
propagated from PE1 to PE2.

> It does define procedures of how routes from a VRF in the customer AS
> interops with a VRF in the SP AS, such as the ones used in option A.
>=20
> > =A0 =A0 =A0 =A0- how SP load balancing between multiple ASBRs is =
affected
> > (given that SP LOCAL_PREF is not used anymore by ingress PE)
>=20
> The ATTR_SET attribute allows a solution to preserve the customer
> LOCAL_PREF;

Ok for the preservation. But in my understanding it goes beyond =
preservation:
=20
" In all cases where a route containing the ATTR_SET attribute is
   imported, attributes present on the VPN route other than the NEXT_HOP
   attribute are ignored, both from the point of view of route selection
   in the VRF Adj-RIB-in and route advertisement to a CE router.  In
   order words, the information contained in ATTR_SET attribute
   overrides the VPN route attributes on "vrf-import". "

I read that the PE does not use the VPN/SP LOCAL_PREF but the customer =
one. Hence a SP could not influence the load balancing across its ASBR =
option B.

> it doesn't and shouldn't (imho) prescribe policy
> mechanisms that may overwrite that LOCAL_PREF.
>=20
> The ATTR_SET attribute along with the ability of running VRFs on
> different ASes (e.g. the customer AS) are intended to address a
> particular set of scenarios which tend to be disjoint, as far as i
> know, from the scenarios where option A is used.
>=20
> The first is intended to allow customer managed inter-as route
> exchanges, while the later is a provider managed solution. They should
> inter-operate but not necessarily overlap for the same customer.
>=20
> Unless you do have a scenario in mind where it would be helpful to use
> ATTR_SET for SP managed inter-as with option A.... If so please
> describe the issue you are trying to address. I'd be more than happy
> to try to make the mechanism more useful but at the moment i'm not
> aware of an application.

Let's take a SP A that cooperates with SP B to increase the geographic =
coverage of its VPN service (in a cost effective way given that the low =
demand in this location does not justify extending the VPN network of SP =
A). SPs uses inter AS option A.

Now a customer VPN having sites connected in both SP ask for iBGP =
session between PE and CE.

=20
> The only scenario i can think of is one where a provider is internally
> using multiple ASes and would like to make that irrelevant to the
> customer; but in that scenario option A has a significant number of
> issues which are beyond the scope of what we can address with this
> document, imho. By the time one addresses these you get option B, for
> which this document is relevant.
>=20
> >
> > 2) "In all cases where a route containing the ATTR_SET attribute is
> > =A0 imported, attributes present on the VPN route other than the =
NEXT_HOP
> > =A0 attribute are ignored, both from the point of view of route =
selection
> > =A0 in the VRF Adj-RIB-in and route advertisement to a CE router. "
> >
> > The document mostly talks about PE. Could the document explicitly =
define
> > how the ATTR_SET attribute is handled by VPN Route Reflector and =
ASBR
> > option B? e.g. ATTR_SET is not to be considered by VPN RR and ASBR
> > option B ?
>=20
> The ATTR_SET attribute is transparent to VPN Route Reflectors and =
ASBRs.
>=20
> >
> > 3) In section 8 "Deployment considerations", IMHO it could be =
helpful
> > for SP readers to indicate that in a given VPN, some sites can use =
iBGP
> > while other sites can use eBGP.
>=20
> They could as a transition mechanism, specially.=20

If you restrict this to a transition mechanism, should I understand that =
you do not recommend that a VPN has both a set of sites in one AS using =
iBGP and some other sites (in a different AS) using eBGP?

> If you have concrete applications, i'd be happy to highlight them. In
> abstract i'm not sure that we would be adding value just by stating
> that one could have both iBGP (in customer-as VRFs) and eBGP (in
> provider-as VRFs) without the context of "why would that be a good
> idea ?"...

As for the concrete application, I guess we could have a VPN customer =
with multiple CE/site in one AS numbers but yet some other sites in a =
different AS number. E.g. sites A1...Ai in AS A and sites B1...Bj in AS =
B. Can a SP put all these VPN sites in the same VPN and the VPN network =
will transparently handle this case? (i.e. interconnect Ai & Aj using =
iBGP, interconnect Bi & Bj using iBGP, while interconnect Ai & Bi using =
eBGP). Or should this be avoided? Or do we need anything special (config =
/ additional gateway) to handle this?
Any answer (yes/ no / yes with X) is fine. The goal of the text is =
simply to make it clear for SP whether such topology is in scope of the =
document or not. (currently I believe it is not in scope)

> Section 7 describes
> how this would work from a protocol standpoint.

"The desired result, in such a scenario is to present the internal
   peer (CE3) with a BGP advertisement that contains the same BGP Path
   Attributes received from CE1 and to the external peer (CE 2) a BGP
   advertisement that would correspond to a situation where AS 1 and 2
   have an external BGP session between them."

I agree that this is the desired result. The question is does this =
document achieve this?

"      When importing a route without the ATTR_SET attribute to a VRF
      that support Interior BGP mode, a PE router MUST prepend its own
      as number to the AS_PATH."

How such route is re-advertised in iBGP to the CE? Is a LOCAL_PREF =
attribute sent? A priori yes as per RFC 4271 ("LOCAL_PREF is a =
well-known attribute that SHALL be included in all UPDATE messages that =
a given BGP speaker sends to other internal peers.") With which value?=20

Same question when the AS number in ATTR_SET does not match the local AS =
configured in the VRF of the iBGP PE-CE session.

Thanks,
Regards,
Bruno
=20
> >
> > Thanks,
> > Best regards,
> > Bruno
> >
> >> -----Original Message-----
> >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf =
Of
> > Ben Niven-Jenkins
> >> Sent: Wednesday, April 13, 2011 7:37 PM
> >> To: l3vpn@ietf.org; idr@ietf.org
> >> Subject: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02
> >>
> >> L3VPNers & IDRers,
> >>
> >> This e-mail is the start of a joint L3VPN & IDR WG Last Call for
> > draft-ietf-l3vpn-ibgp-02.
> >>
> >> Feedback should be provided to the mailing list(s) and/or the =
authors.
> >>
> >> The Last Call ends midnight PDT 27th April 2011.
> >>
> >> You can view the draft here:
> >> http://tools.ietf.org/id/draft-ietf-l3vpn-ibgp-02.txt
> >>
> >> Thanks
> >> Ben (on behalf of the L3VPN & IDR chairs)
> >> _______________________________________________
> >> Idr mailing list
> >> Idr@ietf.org
> >> https://www.ietf.org/mailman/listinfo/idr
> >

From michaellundberg.ietf@gmail.com  Wed Apr 27 09:16:02 2011
Return-Path: <michaellundberg.ietf@gmail.com>
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 523ECE0803 for <l3vpn@ietfa.amsl.com>; Wed, 27 Apr 2011 09:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsSbhV+d2vbK for <l3vpn@ietfa.amsl.com>; Wed, 27 Apr 2011 09:16:01 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C92A6E084A for <l3vpn@ietf.org>; Wed, 27 Apr 2011 09:16:00 -0700 (PDT)
Received: by iwn39 with SMTP id 39so1936079iwn.31 for <l3vpn@ietf.org>; Wed, 27 Apr 2011 09:16:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tWAUI7iXznMg9xlVjRMZg/P+hVCc21NJdCVtanLIeZs=; b=na2oolLzHQbIy6vdYs0+VQTOWroJDUy6MTT9T2x2/u/CYhJRsc1qVkOOzsgOEj2/Yk vlx3j+RDeiQp5f8eiXsHj1tV3//fdz8t6FTxHdOccduCVwtXBnrrBXsc6CLVMx+sA8Ho hWDNJBAGZTcYUKcDiT75TYNk4gIC76EVz4/HU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jOb4f0DMcg2lGO3Z7TvzS6+ARsZYZXqccW60P2b1y00cpDxeJ4cCFQ+hg5LnJx4E2n io/7iutCnjjGaYkFzfQffQ9KwL/hwitcp+BLlLOwh8mBMVvq0MTlSoVvwi20uUU1sFSO zNcHF3Uz5uvnKi6XuDoJ0C9ESTndWvtBgiAlo=
MIME-Version: 1.0
Received: by 10.42.108.137 with SMTP id h9mr3023867icp.112.1303920959785; Wed, 27 Apr 2011 09:15:59 -0700 (PDT)
Received: by 10.231.180.198 with HTTP; Wed, 27 Apr 2011 09:15:59 -0700 (PDT)
In-Reply-To: <44EE1E31095AE349AC6C3C0B69FFBF02A6866D8B74@ENFIMBOX1.ad.datcon.co.uk>
References: <44EE1E31095AE349AC6C3C0B69FFBF02A684BC09A4@ENFIMBOX1.ad.datcon.co.uk> <BANLkTikvQPaZgZHmWQu0cy_ukj4HWPqYHQ@mail.gmail.com> <44EE1E31095AE349AC6C3C0B69FFBF02A68512484B@ENFIMBOX1.ad.datcon.co.uk> <E7FD343F-E00C-41AC-A09D-20B58BBD4CC9@ericsson.com> <44EE1E31095AE349AC6C3C0B69FFBF02A6866D8B74@ENFIMBOX1.ad.datcon.co.uk>
Date: Wed, 27 Apr 2011 12:15:59 -0400
Message-ID: <BANLkTi=fuDZpsr=uw=v7pPxqJ1RwvV1cPg@mail.gmail.com>
Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
From: Michael Lundberg <michaellundberg.ietf@gmail.com>
To: Nick Weeds <nick.weeds@metaswitch.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "draft-ietf-l3vpn-ospfv3-pece@tools.ietf.org" <draft-ietf-l3vpn-ospfv3-pece@tools.ietf.org>, "l3vpn@ietf.org" <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Apr 2011 16:16:02 -0000

Hi Nick,

Sorry i didn't get to your comment earlier. I agree with the behavior
you are describing and the problem with saying the OSPF route will
always be preferred. Given the routes within the VRF are from
different protocols, I believe the only way to chose the route you
want is through local policy (e.g., admin distance, route preference).

We can remove the  "No OSPFv3 route to the same prefix exists in the
VRF," and specify that the route will be redistributed into OSPF based
on local policy.  Will this address your concerns?

Acee - we can also update the word "distance" and change it to
"metric", good comment.

Regards,
Michael

On Fri, Apr 15, 2011 at 12:19 PM, Nick Weeds <nick.weeds@metaswitch.com> wr=
ote:
> Hi Acee,
>
> We don't seem to be thinking of the same use case - please see below ...
>
>> -----Original Message-----
>> From: Acee Lindem [mailto:acee.lindem@ericsson.com]
>> Sent: 15 April 2011 16:51
>> To: Nick Weeds
>> Cc: Michael Lundberg; draft-ietf-l3vpn-ospfv3-pece@ietf.org;
>> l3vpn@ietf.org
>> Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
>>
>> Hi Nick,
>> See inline.
>> On Apr 11, 2011, at 8:50 AM, Nick Weeds wrote:
>>
>> > Hi Michael,
>> >
>> > Thanks for your reply - please see further comments below.
>> >
>> >> -----Original Message-----
>> >> From: Michael Lundberg [mailto:michaellundberg.ietf@gmail.com]
>> >> Sent: 08 April 2011 20:44
>> >> To: Nick Weeds
>> >> Cc: draft-ietf-l3vpn-ospfv3-pece@ietf.org; l3vpn@ietf.org
>> >> Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
>> >>
>> >> Hi Nick,
>> >>
>> >> Thanks for your review and comments. Please see below for my
>> comments.
>> >>
>> >> On Thu, Mar 31, 2011 at 6:47 AM, Nick Weeds
>> <nick.weeds@metaswitch.com>
>> >> wrote:
>> >>> Hi,
>> >>>
>> >>> The changes in the new draft-ietf-l3vpn-ospfv3-07.txt draft look
>> >> good, but I
>> >>> do have a couple of specific comments.
>> >>>
>> >>>
>> >>>
>> >>> Section 4.3.2 / top of p10
>> >>>
>> >>> The text says that a PE advertises the IPv6 route learned from MP-
>> BGP
>> >> to
>> >>> attached CEs via OSPFv3 if various conditions hold, including:
>> >>>
>> >>> =A0 =A0 =A0 =A0 "No OSPFv3 route to the same prefix exists in the VR=
F."
>> >>>
>> >>> I think this is too restrictive. =A0The aim is to allow a choice
>> >> between
>> >>> routing over the VPN and routing over an OSPF backdoor link. =A0The
>> >> condition
>> >>> above would prevent routing over the VPN if there was already a
>> route
>> >> over
>> >>> an OSPF backdoor link.
>> >>>
>> >>> I believe the correct condition would be that the OSPFv3 decision
>> >> process
>> >>> selects the VPN route as the preferred route.
>> >>
>> >> I believe our text is consistent with 4577, which says "If a VRF
>> >> contains both an OSPF-distributed route and a VPN-IPv4 route for the
>> >> same IPv4 prefix, then the OSPF-distributed route is preferred."
>> >> Therefore, as described in the text above, if an OSPFv3 route is
>> >> installed in the VRF for the same prefix as the IPv6 route learned
>> via
>> >> MP-BGP, the OSPFv3 route will be preferred, and the MP-BGP route
>> will
>> >> not be redistributed into OSPF.
>> >>
>> >> To get the behavior you are describing, where you want the OSPF
>> >> decision process to prefer either the backbone or the backdoor link,
>> >> requires sham links. =A0In this case, the OSPF routes from one PE are
>> >> 'tunneled' via MPLS to the other PE and do not appear in the VRF as
>> >> MP-BGP routes. =A0Therefore, the rules above do not hold as you are
>> only
>> >> comparing OSPF routes, not MP-BGP to OSPF.
>> >>
>> >
>> >
>> > Unfortunately the text you refer to in RFC 4577 also seems to gloss
>> over the complexities involved...
>> >
>> > Stepping back, the main function of RFC 4577 and draft-ietf-l3vpn-
>> ospfv3-pece is to allow a choice between VPN routes and OSPF backdoor
>> routes rather than force traffic onto OSPF backdoor routes.
>> >
>> > There are two cases: (1) when the backdoor route is an inter-area
>> route (2) when the backdoor route is an intra-area route.
>> >
>> > In the inter-area case (1) the solution is to map VPN routes to OSPF
>> inter-area prefix LSAs rather than AS-external LSAs according to the
>> OSPF Domain ID configuration (as described in RFC 4577 section 4.2.8).
>> This allows the OSPF decision process to choose between the VPN route
>> (viewed as an OSPF inter-area route) and any inter-area OSPF backdoor
>> route. =A0If the OSPF decision process selects the mapped VPN route then
>> the intent is for the VRF to use the VPN route (complete with BGP/MPLS
>> VPN labels) rather than the OSPF backdoor route. =A0As they stand the
>> statements in RFC 4577 and draft-ietf-l3vpn-ospfv3-pece both seem to
>> contradict this - taken at face value they both seem to say that the PE
>> router should always use the OSPF (backdoor) route rather than BGP
>> (VPN) route.
>> >
>> > In the intra-area case (2) the solution is to use a sham link. =A0This
>> is more complicated but less subject to ambiguity about VPN routes
>> mapped to OSPF inter-area prefix routes.
>> >
>> > If OSPF (backdoor) routes are always preferred to BGP (VPN) routes
>> except in the sham link case, how can the inter-area case possibly
>> allow a choice between the two on the PE router?
>> > (And if it doesn't allow a choice, what is the point of specifying
>> OSPF Domain ID configuration and mapping of VPN routes to OSPF inter-
>> area prefix LSAs?)
>>
>> I agree that this is possible but it would be strange area topology
>> indeed. Since the metric is not carried in BGP, it is a matter of local
>> policy in the PE and one could have some subset of the site using the
>> inter-area path over the backdoor link and another using the VPN path.
>> But again, I don't believe this is a common use case.
>>
>> Thanks,
>> Acee
>
> A couple of points:
>
> (1) The metric is carried in the BGP Multi-Exit Descriminator, as specifi=
ed at the end of draft section 4.3.1 (and also in RFC 4577). =A0I believe t=
he point of RFC 4577 and of the draft is that extra information carried on =
the VPN route allows the BGP (VPN) route to be mapped to an OSPF route, so =
that the VPN route can be preferred to the OSPF backdoor route. =A0This fun=
ction would be broken if the OSPF backdoor route is always preferred to the=
 BGP (VPN) route.
>
> (2) I don't understand why you say the area topology is strange. =A0As fa=
r as I can see it's the only area topology where mapping of BGP routes to O=
SPF inter-area routes has any effect on routing, and therefore it is the ma=
inline case for much of the draft.
>
> =A0 =A0 =A0 =A0Nick.
>
>>
>>
>>
>> >
>> > Hopefully if we can answer that then we'll understand how to make the
>> draft-ietf-l3vpn-ospfv3-pece text clearer.
>> >
>> > =A0 =A0 Nick.
>> >
>> >>> Section 4.3.2.3 / p11
>> >>>
>> >>> The rules 1 and 2 for comparing OSPFv3 Domain IDs state how to
>> >> compare the 6
>> >>> value bytes but not how to compare the 2 type bytes. =A0I believe th=
e
>> >> rules
>> >>> should match RFC 4577 section 4.2.8.1 rules 1 and 3. =A0In other
>> words,
>> >> either
>> >>> (1) all 8 (not 6) bytes match, or (2) the 6 byte value fields of
>> both
>> >>> attributes are all zeroes and the type bytes are ignored. =A0Note
>> that
>> >> in the
>> >>> first case the 2 type bytes must match and in the latter case they
>> >> are
>> >>> ignored.
>> >>
>> >> This is a good point. =A0We will update the text. This text should
>> have
>> >> been updated when we removed the use of the single BGP extended
>> >> community and reverted back to the OSPF Domain ID extended community
>> >> attribute.
>> >>
>> >> Thanks,
>> >> Michael
>> >>
>> >>>
>> >>> =A0 =A0 =A0 =A0 Nick.
>> >>>
>> >>> Nick Weeds
>> >>> Software Engineer, Network Technologies Division
>> >>> Metaswitch Networks
>> >>>
>> >>> nick.weeds@metaswitch.com
>> >>> +44 (0) 20 8366 1177
>> >>> www.metaswitch.com
>
>

From pedro.r.marques@gmail.com  Wed Apr 27 09:19:17 2011
Return-Path: <pedro.r.marques@gmail.com>
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 E7CE4E07DD; Wed, 27 Apr 2011 09:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bnl7H39+YFQ; Wed, 27 Apr 2011 09:19:17 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8222CE0795; Wed, 27 Apr 2011 09:19:16 -0700 (PDT)
Received: by iyn15 with SMTP id 15so1928624iyn.31 for <multiple recipients>; Wed, 27 Apr 2011 09:19:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+U+gSp5agHOxhvtGr3yJBN2jv+H8tUF/LAoxYNSR3VU=; b=af32vAX6T/eptd39g4JgMsQlqh8VNw6gLBdA3P3MiFDGLq4Rn5gPrGYqKefMTCZ8MR KUQUiI4bo0KBdHY0LtB5iVuObj3OE97xUJSQ9E7IhYteAzIfjybn8fL629NDjiI94RK/ o8Sl6v9ILaC8FbWTKlmQl3w7OCT4tOV9cBq9M=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JueNH8RgXbqPpqr7Aq5NTfoUm5R+kxXpOVcXA0NLVX5lXtyFKVLcu/0KNYCKvTrkqq 0PPSDjmr7GIghD1a/nu2DSQj9EIAXq/rsVd7i23G/czNlkztuQuPfd1D3GrhItSZ/qnx Oo/Bol8ZRqKYtl2owfUI53tx1huamMNgi87YQ=
MIME-Version: 1.0
Received: by 10.42.247.200 with SMTP id md8mr3160107icb.111.1303921156058; Wed, 27 Apr 2011 09:19:16 -0700 (PDT)
Received: by 10.42.172.199 with HTTP; Wed, 27 Apr 2011 09:19:16 -0700 (PDT)
In-Reply-To: <FE8F6A65A433A744964C65B6EDFDC2400223F177@ftrdmel0.rd.francetelecom.fr>
References: <FC6A9836-7B63-44C1-BFC5-3903CED4788A@niven-jenkins.co.uk> <FE8F6A65A433A744964C65B6EDFDC2400223F066@ftrdmel0.rd.francetelecom.fr> <BANLkTikY-beZA0VCUsXKDmWM+++Gud658w@mail.gmail.com> <FE8F6A65A433A744964C65B6EDFDC2400223F177@ftrdmel0.rd.francetelecom.fr>
Date: Wed, 27 Apr 2011 09:19:16 -0700
Message-ID: <BANLkTin-w8cvjAnrBne01F21XQGjm+JTbw@mail.gmail.com>
Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02
From: Pedro Marques <pedro.r.marques@gmail.com>
To: bruno.decraene@orange-ftgroup.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: idr@ietf.org, l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Apr 2011 16:19:18 -0000

Please see inline.

On Wed, Apr 27, 2011 at 2:21 AM,  <bruno.decraene@orange-ftgroup.com> wrote=
:
> Pedro,
>
> How do you handle the following topology: ?
>
> AS1 | =A0 =A0AS10 =A0 =A0 | =A0 =A0AS11 =A0 =A0 | AS1
> CE1---PE1---ASBR1---ASBR2---PE2---CE2
>
> CE1-PE1 and CE2-PE2 are iBGP sessions.
> ASBR1 use inter AS option A. Should they use an iBGP session compliant wi=
th this document or a regular eBGP session?

They should use an eBGP session.

> In the latter case, the ATTR_SET attribute will be dropped by ASBR and he=
nce will not be propagated from PE1 to PE2.

In both cases the ATTR_SET attribute will be "poped". The ATTR_SET
attribute is only propagated as long as the route is an "inet-vpn"
route... once imported into a VRF it disappears.

> " In all cases where a route containing the ATTR_SET attribute is
> =A0 imported, attributes present on the VPN route other than the NEXT_HOP
> =A0 attribute are ignored, both from the point of view of route selection
> =A0 in the VRF Adj-RIB-in and route advertisement to a CE router. =A0In
> =A0 order words, the information contained in ATTR_SET attribute
> =A0 overrides the VPN route attributes on "vrf-import". "
>
> I read that the PE does not use the VPN/SP LOCAL_PREF but the customer on=
e. Hence a SP could not influence the load balancing across its ASBR option=
 B.

An SP can influence load balancing across option B by using local pref
in the inet-vpn space.

                             ASBR1  <=3D=3D=3D=3D> ASBR3
    PE1 -- [ AS 1 ]                                          [ AS 2 ]
-- PE2 -- VRF
                             ASBR2  <=3D=3D=3D=3D> ASBR4

A RD1:IP-prefix "inet-vpn" route that originates in PE1 will appear in
PE2 from both ASBR3 and 4 (assuming no reflection). Local-pref on the
SP network can be used to influence the routing decision as to which
of the paths to RD1:IP-prefix is preferable.

If there is another route injected from a PE3 with prefix
RD3:IP-prefix, it is the customer route local-pref that would
influence the decision after the inet-vpn route is imported into the
VRF and becomes an inet route.

Also note that nothing prevents a vendors from adding extra policy
mechanisms. What changes is that the customer local-pref used to
always get squashed by protocol definition (not policy).

> Let's take a SP A that cooperates with SP B to increase the geographic co=
verage of its VPN service (in a cost effective way given that the low deman=
d in this location does not justify extending the VPN network of SP A). SPs=
 uses inter AS option A.
>
> Now a customer VPN having sites connected in both SP ask for iBGP session=
 between PE and CE.
>

I don't think the question is put correctly. I believe the question
should be: what it takes for cooperating providers to be able to
provide a completely transparent service to the customer such that the
VPN network appears as a core.

My answer would be that you can achieve that with a combination of
option B and this document. Note that with option B, ASBRs can as a
matter of local policy look at the contents of the IP packets
traversing the link if they so choose.


>
> If you restrict this to a transition mechanism, should I understand that =
you do not recommend that a VPN has both a set of sites in one AS using iBG=
P and some other sites (in a different AS) using eBGP?

A "virtual private network" can consist of multiple ASes. I would
recommend that one customer AS (AS 1) interconnects with iBGP with a
given VPN provider in order to receive routes from both AS 1 and other
ASes that could be ebgp interconnected.

I would not recommend that an AS, AS 1, interconnects with a VPN
provider both as iBGP and as eBGP (as AS1).

There are some assumptions of connectivity in an AS. I would recommend
that one would stick to these assumptions whenever possible. But
extranets often use a VPN provider to exchange routes between multiple
ASes with no known problems.


> As for the concrete application, I guess we could have a VPN customer wit=
h multiple CE/site in one AS numbers but yet some other sites in a differen=
t AS number. E.g. sites A1...Ai in AS A and sites B1...Bj in AS B. Can a SP=
 put all these VPN sites in the same VPN and the VPN network will transpare=
ntly handle this case?

Yes.

> (i.e. interconnect Ai & Aj using iBGP, interconnect Bi & Bj using iBGP, w=
hile interconnect Ai & Bi using eBGP). Or should this be avoided? Or do we =
need anything special (config / additional gateway) to handle this?
> Any answer (yes/ no / yes with X) is fine. The goal of the text is simply=
 to make it clear for SP whether such topology is in scope of the document =
or not. (currently I believe it is not in scope)

Then the text should be modified to clarify this.

>
>> Section 7 describes
>> how this would work from a protocol standpoint.
>
> "The desired result, in such a scenario is to present the internal
> =A0 peer (CE3) with a BGP advertisement that contains the same BGP Path
> =A0 Attributes received from CE1 and to the external peer (CE 2) a BGP
> =A0 advertisement that would correspond to a situation where AS 1 and 2
> =A0 have an external BGP session between them."
>
> I agree that this is the desired result. The question is does this docume=
nt achieve this?

By the rules specified regarding how the vrf-import stage modifies BGP
attributes.

The AS of the importing VRF is compared to the Origin AS of the
ATTR_SET attribute. CE1 and CE3 have the same "VRF AS" so the route is
imported as-is (using the original attributes preserved in ATTR_SET).
When a route from CE1 is imported into the VRF containing CE2 the VRF
ASes do not match. This results in an implicit eBGP peering between AS
1 and AS 2.

>
> " =A0 =A0 =A0When importing a route without the ATTR_SET attribute to a V=
RF
> =A0 =A0 =A0that support Interior BGP mode, a PE router MUST prepend its o=
wn
> =A0 =A0 =A0as number to the AS_PATH."
>
> How such route is re-advertised in iBGP to the CE?

The exact same behavior as if you had a CE that speaks to the PE using
the current mechanisms (without this document) and that CE is then
speaking iBGP to another CE (and using reflection to propagate
routes).

> Is a LOCAL_PREF attribute sent? A priori yes as per RFC 4271 ("LOCAL_PREF=
 is a well-known attribute that SHALL be included in all UPDATE messages th=
at a given BGP speaker sends to other internal peers.") With which value?

The default value. LOCAL_PREF is always initialized to the default
value for an eBGP received route.

>
> Same question when the AS number in ATTR_SET does not match the local AS =
configured in the VRF of the iBGP PE-CE session.
>

Same answer. There is an implicit eBGP peering between the Origin AS
and the VRF AS of the importing VRF.

  Pedro.

From bruno.decraene@orange-ftgroup.com  Thu Apr 28 05:41:39 2011
Return-Path: <bruno.decraene@orange-ftgroup.com>
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 74434E06A7; Thu, 28 Apr 2011 05:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=-0.700,  BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHGq7zJe9m-Q; Thu, 28 Apr 2011 05:41:38 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 40D5EE0674; Thu, 28 Apr 2011 05:41:37 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 51DE0858004; Thu, 28 Apr 2011 14:48:11 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 4943D858003; Thu, 28 Apr 2011 14:48:11 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 28 Apr 2011 14:41:36 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02
Date: Thu, 28 Apr 2011 14:41:36 +0200
Message-ID: <FE8F6A65A433A744964C65B6EDFDC2400223F637@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <BANLkTin-w8cvjAnrBne01F21XQGjm+JTbw@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02
Thread-Index: AcwE9ttGZhPFk0o6RO2lBoGkBg54WwAepAgQ
References: <FC6A9836-7B63-44C1-BFC5-3903CED4788A@niven-jenkins.co.uk><FE8F6A65A433A744964C65B6EDFDC2400223F066@ftrdmel0.rd.francetelecom.fr><BANLkTikY-beZA0VCUsXKDmWM+++Gud658w@mail.gmail.com><FE8F6A65A433A744964C65B6EDFDC2400223F177@ftrdmel0.rd.francetelecom.fr> <BANLkTin-w8cvjAnrBne01F21XQGjm+JTbw@mail.gmail.com>
From: <bruno.decraene@orange-ftgroup.com>
To: <pedro.r.marques@gmail.com>
X-OriginalArrivalTime: 28 Apr 2011 12:41:36.0631 (UTC) FILETIME=[9CDA0870:01CC05A1]
Cc: idr@ietf.org, l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2011 12:41:39 -0000

Please see inline.

> > How do you handle the following topology: ?
> >
> > AS1 | =A0 =A0AS10 =A0 =A0 | =A0 =A0AS11 =A0 =A0 | AS1
> > CE1---PE1---ASBR1---ASBR2---PE2---CE2
> >
> > CE1-PE1 and CE2-PE2 are iBGP sessions.
> > ASBR1 use inter AS option A. Should they use an iBGP session =
compliant with this document or a
> regular eBGP session?
>=20
> They should use an eBGP session.
>=20
> > In the latter case, the ATTR_SET attribute will be dropped by ASBR =
and hence will not be propagated
> from PE1 to PE2.
>=20
> In both cases the ATTR_SET attribute will be "poped". The ATTR_SET
> attribute is only propagated as long as the route is an "inet-vpn"
> route... once imported into a VRF it disappears.

Yes. With iBGP, the ATTR_SET attribute will be "poped" but only after =
copying the BGP attributes of the customer route (e.g. LOCAL_PREF) on =
the regular iBGP attributes. Then the next ASBR would "push" them back =
in a new ATTR_SET attribute. Hence BGP attributes of the customer are =
propagated end to end.
=20
> > " In all cases where a route containing the ATTR_SET attribute is
> > =A0 imported, attributes present on the VPN route other than the =
NEXT_HOP
> > =A0 attribute are ignored, both from the point of view of route =
selection
> > =A0 in the VRF Adj-RIB-in and route advertisement to a CE router. =
=A0In
> > =A0 order words, the information contained in ATTR_SET attribute
> > =A0 overrides the VPN route attributes on "vrf-import". "
> >
> > I read that the PE does not use the VPN/SP LOCAL_PREF but the =
customer one. Hence a SP could not
> influence the load balancing across its ASBR option B.
>=20
> An SP can influence load balancing across option B by using local pref
> in the inet-vpn space.
>=20
>                              ASBR1  <=3D=3D=3D=3D> ASBR3
>     PE1 -- [ AS 1 ]                                          [ AS 2 ]
> -- PE2 -- VRF
>                              ASBR2  <=3D=3D=3D=3D> ASBR4
>=20
> A RD1:IP-prefix "inet-vpn" route that originates in PE1 will appear in
> PE2 from both ASBR3 and 4 (assuming no reflection). Local-pref on the
> SP network can be used to influence the routing decision as to which
> of the paths to RD1:IP-prefix is preferable.
>=20
> If there is another route injected from a PE3 with prefix
> RD3:IP-prefix, it is the customer route local-pref that would
> influence the decision after the inet-vpn route is imported into the
> VRF and becomes an inet route.

Ok. Thanks for the additional explanation.
=20
> Also note that nothing prevents a vendors from adding extra policy
> mechanisms. What changes is that the customer local-pref used to
> always get squashed by protocol definition (not policy).
>=20
> > Let's take a SP A that cooperates with SP B to increase the =
geographic coverage of its VPN service
> (in a cost effective way given that the low demand in this location =
does not justify extending the VPN
> network of SP A). SPs uses inter AS option A.
> >
> > Now a customer VPN having sites connected in both SP ask for iBGP =
session between PE and CE.
> >
>=20
> I don't think the question is put correctly. I believe the question
> should be: what it takes for cooperating providers to be able to
> provide a completely transparent service to the customer such that the
> VPN network appears as a core.
>=20
> My answer would be that you can achieve that with a combination of
> option B and this document. Note that with option B, ASBRs can as a
> matter of local policy look at the contents of the IP packets
> traversing the link if they so choose.

Given that l3vpn-ibgp comes after inter AS, I would assume that inter AS =
interconnection pre-exist when the first iBGP PE-CE customer comes. So =
if the deployed VPN ASBR use option A, l3vpn-ibgp have to face it. =
That's fine for me if l3vpn-ibgp does not work with inter AS option A, =
but I still believe this should be indicated in the "deployment =
considerations" section of the document. You can also add that to be =
able to provide iBGP PE-CE, SP should favor inter AS option B (over A).

=20
> > If you restrict this to a transition mechanism, should I understand =
that you do not recommend that a
> VPN has both a set of sites in one AS using iBGP and some other sites =
(in a different AS) using eBGP?
>=20
> A "virtual private network" can consist of multiple ASes. I would
> recommend that one customer AS (AS 1) interconnects with iBGP with a
> given VPN provider in order to receive routes from both AS 1 and other
> ASes that could be ebgp interconnected.
>=20
> I would not recommend that an AS, AS 1, interconnects with a VPN
> provider both as iBGP and as eBGP (as AS1).
>=20
> There are some assumptions of connectivity in an AS. I would recommend
> that one would stick to these assumptions whenever possible. But
> extranets often use a VPN provider to exchange routes between multiple
> ASes with no known problems.
>=20
>=20
> > As for the concrete application, I guess we could have a VPN =
customer with multiple CE/site in one
> AS numbers but yet some other sites in a different AS number. E.g. =
sites A1...Ai in AS A and sites
> B1...Bj in AS B. Can a SP put all these VPN sites in the same VPN and =
the VPN network will
> transparently handle this case?
>=20
> Yes.
>=20
> > (i.e. interconnect Ai & Aj using iBGP, interconnect Bi & Bj using =
iBGP, while interconnect Ai & Bi
> using eBGP). Or should this be avoided? Or do we need anything special =
(config / additional gateway)
> to handle this?
> > Any answer (yes/ no / yes with X) is fine. The goal of the text is =
simply to make it clear for SP
> whether such topology is in scope of the document or not. (currently I =
believe it is not in scope)
>=20
> Then the text should be modified to clarify this.
>=20
> >
> >> Section 7 describes
> >> how this would work from a protocol standpoint.
> >
> > "The desired result, in such a scenario is to present the internal
> > =A0 peer (CE3) with a BGP advertisement that contains the same BGP =
Path
> > =A0 Attributes received from CE1 and to the external peer (CE 2) a =
BGP
> > =A0 advertisement that would correspond to a situation where AS 1 =
and 2
> > =A0 have an external BGP session between them."
> >
> > I agree that this is the desired result. The question is does this =
document achieve this?
>=20
> By the rules specified regarding how the vrf-import stage modifies BGP
> attributes.
>=20
> The AS of the importing VRF is compared to the Origin AS of the
> ATTR_SET attribute. CE1 and CE3 have the same "VRF AS" so the route is
> imported as-is (using the original attributes preserved in ATTR_SET).
> When a route from CE1 is imported into the VRF containing CE2 the VRF
> ASes do not match. This results in an implicit eBGP peering between AS
> 1 and AS 2.
>=20
> >
> > " =A0 =A0 =A0When importing a route without the ATTR_SET attribute =
to a VRF
> > =A0 =A0 =A0that support Interior BGP mode, a PE router MUST prepend =
its own
> > =A0 =A0 =A0as number to the AS_PATH."
> >
> > How such route is re-advertised in iBGP to the CE?
>=20
> The exact same behavior as if you had a CE that speaks to the PE using
> the current mechanisms (without this document) and that CE is then
> speaking iBGP to another CE (and using reflection to propagate
> routes).

Ok. IMHO for some readers that would be a useful precision to add in the =
document. In particular, this means that the CE will receive over an =
iBGP session both "valid"/AS policy compliant BGP attributes, and =
default BGP attributes (ala eBGP) that may need to be policed by a =
routemap.
=20
> > Is a LOCAL_PREF attribute sent? A priori yes as per RFC 4271 =
("LOCAL_PREF is a well-known attribute
> that SHALL be included in all UPDATE messages that a given BGP speaker =
sends to other internal
> peers.") With which value?
>=20
> The default value. LOCAL_PREF is always initialized to the default
> value for an eBGP received route.
>=20
> >
> > Same question when the AS number in ATTR_SET does not match the =
local AS configured in the VRF of
> the iBGP PE-CE session.
> >
>=20
> Same answer. There is an implicit eBGP peering between the Origin AS
> and the VRF AS of the importing VRF.
>=20
>   Pedro.

From nick.weeds@metaswitch.com  Thu Apr 28 06:15:44 2011
Return-Path: <nick.weeds@metaswitch.com>
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 B6BC0E0685 for <l3vpn@ietfa.amsl.com>; Thu, 28 Apr 2011 06:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4td3eeDkr5Yc for <l3vpn@ietfa.amsl.com>; Thu, 28 Apr 2011 06:15:42 -0700 (PDT)
Received: from enfiets1.dataconnection.com (enfiets1.dataconnection.com [192.91.191.38]) by ietfa.amsl.com (Postfix) with ESMTP id 44C77E0669 for <l3vpn@ietf.org>; Thu, 28 Apr 2011 06:15:42 -0700 (PDT)
Received: from ENFIMBOX2.ad.datcon.co.uk (172.18.74.17) by enfiets1.dataconnection.com (172.18.4.21) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 28 Apr 2011 14:17:33 +0100
Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX2.ad.datcon.co.uk ([172.18.74.17]) with mapi; Thu, 28 Apr 2011 14:15:41 +0100
From: Nick Weeds <nick.weeds@metaswitch.com>
To: Michael Lundberg <michaellundberg.ietf@gmail.com>
Date: Thu, 28 Apr 2011 14:15:40 +0100
Subject: RE: Comments on draft-ietf-l3vpn-ospfv3-pece-07
Thread-Topic: Comments on draft-ietf-l3vpn-ospfv3-pece-07
Thread-Index: AcwE9nLKOLZPLwd0TtKE6YfjF66O1wArXGoA
Message-ID: <44EE1E31095AE349AC6C3C0B69FFBF02A68694905C@ENFIMBOX1.ad.datcon.co.uk>
References: <44EE1E31095AE349AC6C3C0B69FFBF02A684BC09A4@ENFIMBOX1.ad.datcon.co.uk> <BANLkTikvQPaZgZHmWQu0cy_ukj4HWPqYHQ@mail.gmail.com> <44EE1E31095AE349AC6C3C0B69FFBF02A68512484B@ENFIMBOX1.ad.datcon.co.uk> <E7FD343F-E00C-41AC-A09D-20B58BBD4CC9@ericsson.com> <44EE1E31095AE349AC6C3C0B69FFBF02A6866D8B74@ENFIMBOX1.ad.datcon.co.uk> <BANLkTi=fuDZpsr=uw=v7pPxqJ1RwvV1cPg@mail.gmail.com>
In-Reply-To: <BANLkTi=fuDZpsr=uw=v7pPxqJ1RwvV1cPg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-l3vpn-ospfv3-pece@tools.ietf.org" <draft-ietf-l3vpn-ospfv3-pece@tools.ietf.org>, "l3vpn@ietf.org" <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2011 13:15:44 -0000

Hi Michael,

Thanks for getting back to me. =20

You suggest removing the  "No OSPFv3 route to the same prefix exists in the=
 VRF" and specifying that the route will be redistributed into OSPF based o=
n local policy.  Yes, that would address my concerns.  Obviously for the VP=
N function to work we need routes to be redistributed to OSPF, but network =
administrators might want greater control to restrict VPN routing in some c=
ases.

My email of 31st March also raised a separate point about section 4.3.2.3 t=
ext on comparing OSPFv3 Domain Ids, and your reply of 8th April said you'd =
update the text.  If you're batching up the updates then please remember th=
is earlier point.

	Nick.

> -----Original Message-----
> From: Michael Lundberg [mailto:michaellundberg.ietf@gmail.com]
> Sent: 27 April 2011 17:16
> To: Nick Weeds
> Cc: Acee Lindem; draft-ietf-l3vpn-ospfv3-pece@tools.ietf.org;
> l3vpn@ietf.org
> Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
>=20
> Hi Nick,
>=20
> Sorry i didn't get to your comment earlier. I agree with the behavior
> you are describing and the problem with saying the OSPF route will
> always be preferred. Given the routes within the VRF are from
> different protocols, I believe the only way to chose the route you
> want is through local policy (e.g., admin distance, route preference).
>=20
> We can remove the  "No OSPFv3 route to the same prefix exists in the
> VRF," and specify that the route will be redistributed into OSPF based
> on local policy.  Will this address your concerns?
>=20
> Acee - we can also update the word "distance" and change it to
> "metric", good comment.
>=20
> Regards,
> Michael
>=20
> On Fri, Apr 15, 2011 at 12:19 PM, Nick Weeds
> <nick.weeds@metaswitch.com> wrote:
> > Hi Acee,
> >
> > We don't seem to be thinking of the same use case - please see below
> ...
> >
> >> -----Original Message-----
> >> From: Acee Lindem [mailto:acee.lindem@ericsson.com]
> >> Sent: 15 April 2011 16:51
> >> To: Nick Weeds
> >> Cc: Michael Lundberg; draft-ietf-l3vpn-ospfv3-pece@ietf.org;
> >> l3vpn@ietf.org
> >> Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
> >>
> >> Hi Nick,
> >> See inline.
> >> On Apr 11, 2011, at 8:50 AM, Nick Weeds wrote:
> >>
> >> > Hi Michael,
> >> >
> >> > Thanks for your reply - please see further comments below.
> >> >
> >> >> -----Original Message-----
> >> >> From: Michael Lundberg [mailto:michaellundberg.ietf@gmail.com]
> >> >> Sent: 08 April 2011 20:44
> >> >> To: Nick Weeds
> >> >> Cc: draft-ietf-l3vpn-ospfv3-pece@ietf.org; l3vpn@ietf.org
> >> >> Subject: Re: Comments on draft-ietf-l3vpn-ospfv3-pece-07
> >> >>
> >> >> Hi Nick,
> >> >>
> >> >> Thanks for your review and comments. Please see below for my
> >> comments.
> >> >>
> >> >> On Thu, Mar 31, 2011 at 6:47 AM, Nick Weeds
> >> <nick.weeds@metaswitch.com>
> >> >> wrote:
> >> >>> Hi,
> >> >>>
> >> >>> The changes in the new draft-ietf-l3vpn-ospfv3-07.txt draft look
> >> >> good, but I
> >> >>> do have a couple of specific comments.
> >> >>>
> >> >>>
> >> >>>
> >> >>> Section 4.3.2 / top of p10
> >> >>>
> >> >>> The text says that a PE advertises the IPv6 route learned from
> MP-
> >> BGP
> >> >> to
> >> >>> attached CEs via OSPFv3 if various conditions hold, including:
> >> >>>
> >> >>> =A0 =A0 =A0 =A0 "No OSPFv3 route to the same prefix exists in the =
VRF."
> >> >>>
> >> >>> I think this is too restrictive. =A0The aim is to allow a choice
> >> >> between
> >> >>> routing over the VPN and routing over an OSPF backdoor link.
> =A0The
> >> >> condition
> >> >>> above would prevent routing over the VPN if there was already a
> >> route
> >> >> over
> >> >>> an OSPF backdoor link.
> >> >>>
> >> >>> I believe the correct condition would be that the OSPFv3
> decision
> >> >> process
> >> >>> selects the VPN route as the preferred route.
> >> >>
> >> >> I believe our text is consistent with 4577, which says "If a VRF
> >> >> contains both an OSPF-distributed route and a VPN-IPv4 route for
> the
> >> >> same IPv4 prefix, then the OSPF-distributed route is preferred."
> >> >> Therefore, as described in the text above, if an OSPFv3 route is
> >> >> installed in the VRF for the same prefix as the IPv6 route
> learned
> >> via
> >> >> MP-BGP, the OSPFv3 route will be preferred, and the MP-BGP route
> >> will
> >> >> not be redistributed into OSPF.
> >> >>
> >> >> To get the behavior you are describing, where you want the OSPF
> >> >> decision process to prefer either the backbone or the backdoor
> link,
> >> >> requires sham links. =A0In this case, the OSPF routes from one PE
> are
> >> >> 'tunneled' via MPLS to the other PE and do not appear in the VRF
> as
> >> >> MP-BGP routes. =A0Therefore, the rules above do not hold as you are
> >> only
> >> >> comparing OSPF routes, not MP-BGP to OSPF.
> >> >>
> >> >
> >> >
> >> > Unfortunately the text you refer to in RFC 4577 also seems to
> gloss
> >> over the complexities involved...
> >> >
> >> > Stepping back, the main function of RFC 4577 and draft-ietf-l3vpn-
> >> ospfv3-pece is to allow a choice between VPN routes and OSPF
> backdoor
> >> routes rather than force traffic onto OSPF backdoor routes.
> >> >
> >> > There are two cases: (1) when the backdoor route is an inter-area
> >> route (2) when the backdoor route is an intra-area route.
> >> >
> >> > In the inter-area case (1) the solution is to map VPN routes to
> OSPF
> >> inter-area prefix LSAs rather than AS-external LSAs according to the
> >> OSPF Domain ID configuration (as described in RFC 4577 section
> 4.2.8).
> >> This allows the OSPF decision process to choose between the VPN
> route
> >> (viewed as an OSPF inter-area route) and any inter-area OSPF
> backdoor
> >> route. =A0If the OSPF decision process selects the mapped VPN route
> then
> >> the intent is for the VRF to use the VPN route (complete with
> BGP/MPLS
> >> VPN labels) rather than the OSPF backdoor route. =A0As they stand the
> >> statements in RFC 4577 and draft-ietf-l3vpn-ospfv3-pece both seem to
> >> contradict this - taken at face value they both seem to say that the
> PE
> >> router should always use the OSPF (backdoor) route rather than BGP
> >> (VPN) route.
> >> >
> >> > In the intra-area case (2) the solution is to use a sham link.
> =A0This
> >> is more complicated but less subject to ambiguity about VPN routes
> >> mapped to OSPF inter-area prefix routes.
> >> >
> >> > If OSPF (backdoor) routes are always preferred to BGP (VPN) routes
> >> except in the sham link case, how can the inter-area case possibly
> >> allow a choice between the two on the PE router?
> >> > (And if it doesn't allow a choice, what is the point of specifying
> >> OSPF Domain ID configuration and mapping of VPN routes to OSPF
> inter-
> >> area prefix LSAs?)
> >>
> >> I agree that this is possible but it would be strange area topology
> >> indeed. Since the metric is not carried in BGP, it is a matter of
> local
> >> policy in the PE and one could have some subset of the site using
> the
> >> inter-area path over the backdoor link and another using the VPN
> path.
> >> But again, I don't believe this is a common use case.
> >>
> >> Thanks,
> >> Acee
> >
> > A couple of points:
> >
> > (1) The metric is carried in the BGP Multi-Exit Descriminator, as
> specified at the end of draft section 4.3.1 (and also in RFC 4577). =A0I
> believe the point of RFC 4577 and of the draft is that extra
> information carried on the VPN route allows the BGP (VPN) route to be
> mapped to an OSPF route, so that the VPN route can be preferred to the
> OSPF backdoor route. =A0This function would be broken if the OSPF
> backdoor route is always preferred to the BGP (VPN) route.
> >
> > (2) I don't understand why you say the area topology is strange. =A0As
> far as I can see it's the only area topology where mapping of BGP
> routes to OSPF inter-area routes has any effect on routing, and
> therefore it is the mainline case for much of the draft.
> >
> > =A0 =A0 =A0 =A0Nick.
> >
> >>
> >>
> >>
> >> >
> >> > Hopefully if we can answer that then we'll understand how to make
> the
> >> draft-ietf-l3vpn-ospfv3-pece text clearer.
> >> >
> >> > =A0 =A0 Nick.
> >> >
> >> >>> Section 4.3.2.3 / p11
> >> >>>
> >> >>> The rules 1 and 2 for comparing OSPFv3 Domain IDs state how to
> >> >> compare the 6
> >> >>> value bytes but not how to compare the 2 type bytes. =A0I believe
> the
> >> >> rules
> >> >>> should match RFC 4577 section 4.2.8.1 rules 1 and 3. =A0In other
> >> words,
> >> >> either
> >> >>> (1) all 8 (not 6) bytes match, or (2) the 6 byte value fields of
> >> both
> >> >>> attributes are all zeroes and the type bytes are ignored. =A0Note
> >> that
> >> >> in the
> >> >>> first case the 2 type bytes must match and in the latter case
> they
> >> >> are
> >> >>> ignored.
> >> >>
> >> >> This is a good point. =A0We will update the text. This text should
> >> have
> >> >> been updated when we removed the use of the single BGP extended
> >> >> community and reverted back to the OSPF Domain ID extended
> community
> >> >> attribute.
> >> >>
> >> >> Thanks,
> >> >> Michael
> >> >>
> >> >>>
> >> >>> =A0 =A0 =A0 =A0 Nick.
> >> >>>
> >> >>> Nick Weeds
> >> >>> Software Engineer, Network Technologies Division
> >> >>> Metaswitch Networks
> >> >>>
> >> >>> nick.weeds@metaswitch.com
> >> >>> +44 (0) 20 8366 1177
> >> >>> www.metaswitch.com
> >
> >

From pedro.r.marques@gmail.com  Thu Apr 28 13:29:40 2011
Return-Path: <pedro.r.marques@gmail.com>
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 9547FE06D7; Thu, 28 Apr 2011 13:29:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.05
X-Spam-Level: 
X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SXr4uRnYFRz; Thu, 28 Apr 2011 13:29:39 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE72E06D2; Thu, 28 Apr 2011 13:29:39 -0700 (PDT)
Received: by iyn15 with SMTP id 15so3260494iyn.31 for <multiple recipients>; Thu, 28 Apr 2011 13:29:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JVsJPpF9sw+N4RbDt/u20emkku04E87pO65R+5VMd74=; b=TfD4JqGJJskqBgGg3mdDo6GQLWp0Ug1WwXJew0a75c0sraLuuvi3dcrGt6d5A5Rexx u5QVK15X/m4ZRjPtINdzOP4AIgmpoycfz8DgDyn2mxVKgK8aKWlO2MPF6eO0aowCi3co Ai3vYGYxjPkRqUu0sgW56OzZyVtowOKjqEXy4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QxK+IxRzC3k9V3odNpc6mYl88oKFMrPjLYt3zXlwEMVAFzpaQgECNt3j1myQqIAKyo Y6OgQSoU6yBVBWKPB3Zls74wlpM30igPy6nBTStkShRVuwbZ8JchwW1bKg7kCFp+tVc2 xyetbxVisaA5NZY1lEfoAP+NT/OlyKz2FWbeA=
MIME-Version: 1.0
Received: by 10.42.146.74 with SMTP id i10mr3148094icv.379.1304022578974; Thu, 28 Apr 2011 13:29:38 -0700 (PDT)
Received: by 10.42.172.199 with HTTP; Thu, 28 Apr 2011 13:29:38 -0700 (PDT)
In-Reply-To: <FE8F6A65A433A744964C65B6EDFDC2400223F637@ftrdmel0.rd.francetelecom.fr>
References: <FC6A9836-7B63-44C1-BFC5-3903CED4788A@niven-jenkins.co.uk> <FE8F6A65A433A744964C65B6EDFDC2400223F066@ftrdmel0.rd.francetelecom.fr> <BANLkTikY-beZA0VCUsXKDmWM+++Gud658w@mail.gmail.com> <FE8F6A65A433A744964C65B6EDFDC2400223F177@ftrdmel0.rd.francetelecom.fr> <BANLkTin-w8cvjAnrBne01F21XQGjm+JTbw@mail.gmail.com> <FE8F6A65A433A744964C65B6EDFDC2400223F637@ftrdmel0.rd.francetelecom.fr>
Date: Thu, 28 Apr 2011 13:29:38 -0700
Message-ID: <BANLkTikeF+K_js3AFO+kBpJPs2YWcpMVkg@mail.gmail.com>
Subject: Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02
From: Pedro Marques <pedro.r.marques@gmail.com>
To: bruno.decraene@orange-ftgroup.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: idr@ietf.org, l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2011 20:29:40 -0000

Bruno,

On Thu, Apr 28, 2011 at 5:41 AM,  <bruno.decraene@orange-ftgroup.com> wrote=
:

>> In both cases the ATTR_SET attribute will be "poped". The ATTR_SET
>> attribute is only propagated as long as the route is an "inet-vpn"
>> route... once imported into a VRF it disappears.
>
> Yes. With iBGP, the ATTR_SET attribute will be "poped" but only after cop=
ying the BGP attributes of the customer route (e.g. LOCAL_PREF) on the regu=
lar iBGP attributes. Then the next ASBR would "push" them back in a new ATT=
R_SET attribute. Hence BGP attributes of the customer are propagated end to=
 end.

But that wouldn't be inter-as option A, would it ? Option A is defined
as using eBGP on a per VRF basis.

I believe that one needs to consider what is the design of the
"customer" AS... while their may be topologies where you can get away
with the scenario you suggest, i'm now aware of a generic scenario
where this would work correctly.


>
> Given that l3vpn-ibgp comes after inter AS, I would assume that inter AS =
interconnection pre-exist when the first iBGP PE-CE customer comes.


> So if the deployed VPN ASBR use option A, l3vpn-ibgp have to face it. Tha=
t's fine for me if l3vpn-ibgp does not work with inter AS option A

There is no way i'm aware off to achieve VPN network transparency when
the provider interconnect is based on converting VPN routes to IP
route passing it through an eBGP peering and back.

The motivation to do iBGP is to provide VPN network transparency. In
inter-as cases to achieve transparency iBGP is not the only
requirement. You also need to exchange this customer routes via option
B (or C).

>, but I still believe this should be indicated in the "deployment consider=
ations" section of the document. You can also add that to be able to provid=
e iBGP PE-CE, SP should favor inter AS option B (over A).
>

Will do.

  Pedro.

From ben@niven-jenkins.co.uk  Fri Apr 29 02:19:22 2011
Return-Path: <ben@niven-jenkins.co.uk>
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 AFC23E0678 for <l3vpn@ietfa.amsl.com>; Fri, 29 Apr 2011 02:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.999
X-Spam-Level: 
X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7dIq7i+4N0f for <l3vpn@ietfa.amsl.com>; Fri, 29 Apr 2011 02:19:22 -0700 (PDT)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by ietfa.amsl.com (Postfix) with ESMTP id 02E6EE064B for <l3vpn@ietf.org>; Fri, 29 Apr 2011 02:19:22 -0700 (PDT)
Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.3]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1QFjr8-0003NA-C9; Fri, 29 Apr 2011 10:19:22 +0100
Subject: Does L3VPN need a Face to face meeting at IETF81?
Content-Transfer-Encoding: quoted-printable
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Content-Type: text/plain; charset=us-ascii
Message-Id: <57C36680-2EF4-4DF8-8A55-1958C7539ED6@niven-jenkins.co.uk>
Date: Fri, 29 Apr 2011 10:19:18 +0100
To: L3VPN WG mailing list <l3vpn@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1078)
X-Mailer: Apple Mail (2.1078)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Cc: l3vpn-chairs@tools.ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2011 09:19:22 -0000

Colleagues,

It is approaching the time when Marshall and I have to decide whether or =
not to submit a request for a time slot at IETF81 for L3VPN.

Given the low amount of mailing list traffic before and since IETF80 and =
that we appear to be reasonably on track against our milestones I am =
suggesting that we do not need a face to face session in Quebec and do =
not plan to request a time slot for L3VPN.

If you feel strongly that a face to face session should in fact be =
requested can you please e-mail the chairs (and the WG if you wish) =
expressing the reasons why you think a face to face session would be =
beneficial.

Thanks
Ben


From Internet-Drafts@ietf.org  Fri Apr 29 09:45:08 2011
Return-Path: <Internet-Drafts@ietf.org>
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 223D8E06A1; Fri, 29 Apr 2011 09:45:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.033
X-Spam-Level: 
X-Spam-Status: No, score=-102.033 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWPZS2Lp0GxW; Fri, 29 Apr 2011 09:45:03 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43B4E06AD; Fri, 29 Apr 2011 09:45:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action:draft-ietf-l3vpn-ibgp-04.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 3.52
Message-ID: <20110429164503.2552.67642.idtracker@ietfa.amsl.com>
Date: Fri, 29 Apr 2011 09:45:03 -0700
Cc: l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2011 16:45:08 -0000

--NextPart

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           : Internal BGP as PE-CE protocol
	Author(s)       : P. Marques, et al.
	Filename        : draft-ietf-l3vpn-ibgp-04.txt
	Pages           : 19
	Date            : 2011-04-29

This document defines protocol extensions and procedures for BGP
PE-CE router iteration in BGP/MPLS IP VPN [RFC4364] networks.  These
have the objective of making the usage of the BGP/MPLS IP VPN
transparent to the customer network, as far as routing information is
concerned.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ibgp-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-l3vpn-ibgp-04.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2011-04-29094012.I-D@ietf.org>


--NextPart--

From bruno.decraene@orange-ftgroup.com  Fri Apr 29 10:14:12 2011
Return-Path: <bruno.decraene@orange-ftgroup.com>
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 38432E06A1; Fri, 29 Apr 2011 10:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.07
X-Spam-Level: 
X-Spam-Status: No, score=-1.07 tagged_above=-999 required=5 tests=[AWL=-0.220,  BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+BLOwFP1VLe; Fri, 29 Apr 2011 10:14:11 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 728F8E06AD; Fri, 29 Apr 2011 10:14:11 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2BD6AFC400C; Fri, 29 Apr 2011 19:14:19 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 171E7FC4007; Fri, 29 Apr 2011 19:14:19 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 29 Apr 2011 19:14:10 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02
Date: Fri, 29 Apr 2011 19:14:08 +0200
Message-ID: <FE8F6A65A433A744964C65B6EDFDC2400223FB38@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <BANLkTikeF+K_js3AFO+kBpJPs2YWcpMVkg@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02
Thread-Index: AcwF4xMNaOSs+Mi2QQqHLdJ4+RW5JAArQrpg
References: <FC6A9836-7B63-44C1-BFC5-3903CED4788A@niven-jenkins.co.uk><FE8F6A65A433A744964C65B6EDFDC2400223F066@ftrdmel0.rd.francetelecom.fr><BANLkTikY-beZA0VCUsXKDmWM+++Gud658w@mail.gmail.com><FE8F6A65A433A744964C65B6EDFDC2400223F177@ftrdmel0.rd.francetelecom.fr><BANLkTin-w8cvjAnrBne01F21XQGjm+JTbw@mail.gmail.com><FE8F6A65A433A744964C65B6EDFDC2400223F637@ftrdmel0.rd.francetelecom.fr> <BANLkTikeF+K_js3AFO+kBpJPs2YWcpMVkg@mail.gmail.com>
From: <bruno.decraene@orange-ftgroup.com>
To: <pedro.r.marques@gmail.com>
X-OriginalArrivalTime: 29 Apr 2011 17:14:10.0376 (UTC) FILETIME=[DADB3C80:01CC0690]
Cc: idr@ietf.org, l3vpn@ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2011 17:14:12 -0000

Pedro,

Thanks for the clarification text that you have added on inter AS VPN.
New draft (-04) addresses all my comments.

Thanks,
Regards,
Bruno



> From: Pedro Marques [mailto:pedro.r.marques@gmail.com]
>=20
> Bruno,
>=20
> On Thu, Apr 28, 2011 at 5:41 AM,  <bruno.decraene@orange-ftgroup.com>
wrote:
>=20
> >> In both cases the ATTR_SET attribute will be "poped". The ATTR_SET
> >> attribute is only propagated as long as the route is an "inet-vpn"
> >> route... once imported into a VRF it disappears.
> >
> > Yes. With iBGP, the ATTR_SET attribute will be "poped" but only
after copying the BGP attributes of
> the customer route (e.g. LOCAL_PREF) on the regular iBGP attributes.
Then the next ASBR would "push"
> them back in a new ATTR_SET attribute. Hence BGP attributes of the
customer are propagated end to end.
>=20
> But that wouldn't be inter-as option A, would it ? Option A is defined
> as using eBGP on a per VRF basis.
>=20
> I believe that one needs to consider what is the design of the
> "customer" AS... while their may be topologies where you can get away
> with the scenario you suggest, i'm now aware of a generic scenario
> where this would work correctly.
>=20
>=20
> >
> > Given that l3vpn-ibgp comes after inter AS, I would assume that
inter AS interconnection pre-exist
> when the first iBGP PE-CE customer comes.
>=20
>=20
> > So if the deployed VPN ASBR use option A, l3vpn-ibgp have to face
it. That's fine for me if l3vpn-
> ibgp does not work with inter AS option A
>=20
> There is no way i'm aware off to achieve VPN network transparency when
> the provider interconnect is based on converting VPN routes to IP
> route passing it through an eBGP peering and back.
>=20
> The motivation to do iBGP is to provide VPN network transparency. In
> inter-as cases to achieve transparency iBGP is not the only
> requirement. You also need to exchange this customer routes via option
> B (or C).
>=20
> >, but I still believe this should be indicated in the "deployment
considerations" section of the
> document. You can also add that to be able to provide iBGP PE-CE, SP
should favor inter AS option B
> (over A).
> >
>=20
> Will do.
>=20
>   Pedro.

From ben@niven-jenkins.co.uk  Sat Apr 30 02:01:56 2011
Return-Path: <ben@niven-jenkins.co.uk>
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 514EAE068B for <l3vpn@ietfa.amsl.com>; Sat, 30 Apr 2011 02:01:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.123
X-Spam-Level: 
X-Spam-Status: No, score=-103.123 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+q+hMP3gxuT for <l3vpn@ietfa.amsl.com>; Sat, 30 Apr 2011 02:01:55 -0700 (PDT)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by ietfa.amsl.com (Postfix) with ESMTP id C1671E065B for <l3vpn@ietf.org>; Sat, 30 Apr 2011 02:01:54 -0700 (PDT)
Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.2]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1QG63n-0004rp-UH; Sat, 30 Apr 2011 10:01:56 +0100
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG document
Date: Sat, 30 Apr 2011 10:01:52 +0100
Message-Id: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk>
To: L3VPN WG mailing list <l3vpn@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Cc: l3vpn-chairs@tools.ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Apr 2011 09:01:56 -0000

Colleagues,
=20
This e-mail is to start a poll on whether the L3VPN WG should adopt =
draft-rosen-l3vpn-mvpn-bidir-03.txt as a L3VPN WG document.
=20
Please indicate your support or otherwise by responding to this message =
(with yes/support or no/do not support) or e-mailing the WG chairs =
privately.

If you do not support the adoption of the document it would be useful if =
you could also state the reason for your objection.
=20
Please send your responses by midnight August 15th May PDT.

FYI Eric has outlined his view on the need for this document on the =
mailing list previously which you can read here:
http://www.ietf.org/mail-archive/web/l3vpn/current/msg02901.html

Thanks
Ben


From raszuk@cisco.com  Sat Apr 30 03:29:57 2011
Return-Path: <raszuk@cisco.com>
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 B592FE06F3 for <l3vpn@ietfa.amsl.com>; Sat, 30 Apr 2011 03:29:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNvG4Uy97g91 for <l3vpn@ietfa.amsl.com>; Sat, 30 Apr 2011 03:29:57 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 304CCE06FA for <l3vpn@ietf.org>; Sat, 30 Apr 2011 03:29:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=819; q=dns/txt; s=iport; t=1304159397; x=1305368997; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jjDfs6N1QzgamUwr1KZU/TqBBvAy5VwEFxr/27Oh0LU=; b=WL/u3lGPHnd2Y4dVMhz0yQpX963OvDrSvBNvGpBuhgTRj+L+XZcKcP4Z dCjNe8KSfpSmxgPc9HDE1FAcmlid4KQz55YUVGSRxhx+8+Naf32ely7/x /4YMb0bKrFjcalD6XRPBohHdJmsjuyS0zWevyu20RwbQhid3FjmDEPCQ+ M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAJPju02rRDoH/2dsb2JhbACmGHeIcZ1qgngPAZkKhgAEjnmEGYoL
X-IronPort-AV: E=Sophos;i="4.64,292,1301875200"; d="scan'208";a="305466968"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 30 Apr 2011 10:29:56 +0000
Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3UATtgg001199; Sat, 30 Apr 2011 10:29:55 GMT
Message-ID: <4DBBE4A7.5050206@cisco.com>
Date: Sat, 30 Apr 2011 12:29:59 +0200
From: Robert Raszuk <raszuk@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Subject: Re: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG document
References: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk>
In-Reply-To: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: l3vpn-chairs@tools.ietf.org, L3VPN WG mailing list <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: raszuk@cisco.com
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Apr 2011 10:29:57 -0000

Support.

Thx,
R.

PS.  "August 15th May" - May I ask what calendar system is this ;-).


> Colleagues,
>
> This e-mail is to start a poll on whether the L3VPN WG should adopt draft-rosen-l3vpn-mvpn-bidir-03.txt as a L3VPN WG document.
>
> Please indicate your support or otherwise by responding to this message (with yes/support or no/do not support) or e-mailing the WG chairs privately.
>
> If you do not support the adoption of the document it would be useful if you could also state the reason for your objection.
>
> Please send your responses by midnight August 15th May PDT.
>
> FYI Eric has outlined his view on the need for this document on the mailing list previously which you can read here:
> http://www.ietf.org/mail-archive/web/l3vpn/current/msg02901.html
>
> Thanks
> Ben
>
>


From stbryant@cisco.com  Sat Apr 30 10:13:53 2011
Return-Path: <stbryant@cisco.com>
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 230BAE0674 for <l3vpn@ietfa.amsl.com>; Sat, 30 Apr 2011 10:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.352
X-Spam-Level: 
X-Spam-Status: No, score=-110.352 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88AJEU2AQQZB for <l3vpn@ietfa.amsl.com>; Sat, 30 Apr 2011 10:13:52 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEB9E0664 for <l3vpn@ietf.org>; Sat, 30 Apr 2011 10:13:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1382; q=dns/txt; s=iport; t=1304183632; x=1305393232; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=HIAD/Nqk2ZSCpclhbN23TtvRfCFcNzLaT7YTPKaJL1U=; b=MIImJyE/w0+iOGPf44qHw5DG+whv9qVU9mNfBUtwZdPIwMEV1K02QWN0 nwqIpKM6sFESoauQpCFWHbEbhscGio6OHqBLPvjqeAPDt5RlbMTFH4EKK QZeIfLYSNhb34ULnZ0ZyzbGoG9p0MQs49XyQaa2r8nBM+xqjUBwLQ5Iw8 A=;
X-IronPort-AV: E=Sophos;i="4.64,293,1301875200"; d="scan'208,217";a="28048624"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 30 Apr 2011 17:13:51 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3UHDp7K019521; Sat, 30 Apr 2011 17:13:51 GMT
Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p3UHDmU15367; Sat, 30 Apr 2011 18:13:49 +0100 (BST)
Message-ID: <4DBC434C.2060503@cisco.com>
Date: Sat, 30 Apr 2011 18:13:48 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: raszuk@cisco.com
Subject: Re: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG	document
References: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk> <4DBBE4A7.5050206@cisco.com>
In-Reply-To: <4DBBE4A7.5050206@cisco.com>
Content-Type: multipart/alternative; boundary="------------020203060101040001010507"
Cc: l3vpn-chairs@tools.ietf.org, L3VPN WG mailing list <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Apr 2011 17:13:53 -0000

This is a multi-part message in MIME format.
--------------020203060101040001010507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 30/04/2011 11:29, Robert Raszuk wrote:
>
> Support.
>
> Thx,
> R.
>
> PS.  "August 15th May" - May I ask what calendar system is this ;-). 
** Robert, I am surprised at you! Surely everyone knew that 15th May
as a day that inspired  awe and admiration :)

- Stewart

--------------020203060101040001010507
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 30/04/2011 11:29, Robert Raszuk wrote:
    <blockquote cite="mid:4DBBE4A7.5050206@cisco.com" type="cite">
      <br>
      Support.
      <br>
      <br>
      Thx,
      <br>
      R.
      <br>
      <br>
      PS.&nbsp; "August 15th May" - May I ask what calendar system is this
      ;-).
    </blockquote>
    <b> </b> Robert, I am surprised at you! Surely everyone knew that
    15th May <br>
    as a day that inspired&nbsp; awe and admiration :)<br>
    <br>
    - Stewart<br>
  </body>
</html>

--------------020203060101040001010507--

From ben@niven-jenkins.co.uk  Sat Apr 30 10:59:10 2011
Return-Path: <ben@niven-jenkins.co.uk>
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 B9846E06A7 for <l3vpn@ietfa.amsl.com>; Sat, 30 Apr 2011 10:59:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.394
X-Spam-Level: 
X-Spam-Status: No, score=-102.394 tagged_above=-999 required=5 tests=[AWL=-0.791, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPWZrSlklsbK for <l3vpn@ietfa.amsl.com>; Sat, 30 Apr 2011 10:59:10 -0700 (PDT)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 37D99E0685 for <l3vpn@ietf.org>; Sat, 30 Apr 2011 10:59:10 -0700 (PDT)
Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.4]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1QGERg-000713-Tx; Sat, 30 Apr 2011 18:59:09 +0100
References: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk> <4DBBE4A7.5050206@cisco.com>
In-Reply-To: <4DBBE4A7.5050206@cisco.com>
Mime-Version: 1.0 (iPhone Mail 8C148)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <A79A62CA-17D7-4E0F-A391-A4CF454AD1CA@niven-jenkins.co.uk>
X-Mailer: iPhone Mail (8C148)
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Subject: Re: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG document
Date: Sat, 30 Apr 2011 18:58:53 +0100
To: "raszuk@cisco.com" <raszuk@cisco.com>
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Cc: L3VPN WG mailing list <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Apr 2011 17:59:10 -0000

On 30 Apr 2011, at 11:29, Robert Raszuk <raszuk@cisco.com> wrote:

> PS.  "August 15th May" - May I ask what calendar system is this ;-).
>=20

It's the copy & paste calendar system which is proven to interoperate with b=
oth the Gregorian and Julian calendars ;-)

Ben=20

>=20
>> Colleagues,
>>=20
>> This e-mail is to start a poll on whether the L3VPN WG should adopt draft=
-rosen-l3vpn-mvpn-bidir-03.txt as a L3VPN WG document.
>>=20
>> Please indicate your support or otherwise by responding to this message (=
with yes/support or no/do not support) or e-mailing the WG chairs privately.=

>>=20
>> If you do not support the adoption of the document it would be useful if y=
ou could also state the reason for your objection.
>>=20
>> Please send your responses by midnight August 15th May PDT.
>>=20
>> FYI Eric has outlined his view on the need for this document on the maili=
ng list previously which you can read here:
>> http://www.ietf.org/mail-archive/web/l3vpn/current/msg02901.html
>>=20
>> Thanks
>> Ben
>>=20
>>=20
>=20


From william.zayas@fibercrossing.net  Sat Apr 30 15:36:09 2011
Return-Path: <william.zayas@fibercrossing.net>
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 52F87E062A for <l3vpn@ietfa.amsl.com>; Sat, 30 Apr 2011 15:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLUlKnOSVaA1 for <l3vpn@ietfa.amsl.com>; Sat, 30 Apr 2011 15:36:07 -0700 (PDT)
Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE29E0593 for <l3vpn@ietf.org>; Sat, 30 Apr 2011 15:36:02 -0700 (PDT)
Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr8.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p3UMa1UU027823 for <l3vpn@ietf.org>; Sat, 30 Apr 2011 18:36:01 -0400
Authentication-Results: cm-omr9 smtp.user=william.zayas@fibercrossing.net; auth=pass (LOGIN)
X-Authenticated-UID: william.zayas@fibercrossing.net
Received: from [97.216.0.28] ([97.216.0.28:40276] helo=www.palm.com) by cm-omr9 (envelope-from <william.zayas@fibercrossing.net>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 9E/42-26839-FCE8CBD4; Sat, 30 Apr 2011 18:36:01 -0400
Date: Sat, 30 Apr 2011 18:35:57 -0400
Message-ID: <9E.42.26839.FCE8CBD4@cm-omr9>
From: "William Zayas" <william.zayas@fibercrossing.net>
To: "raszuk@cisco.com" <raszuk@cisco.com>, "Ben Niven-Jenkins" <ben@niven-jenkins.co.uk>
Subject: Re: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG	document
In-Reply-To: <4DBBE4A7.5050206@cisco.com>
X-Mailer: Palm webOS v1.0.1
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary=Alternative__boundary__1304202960502
Cc: "l3vpn-chairs@tools.ietf.org" <l3vpn-chairs@tools.ietf.org>, L3VPN WG mailing list <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Zayas <william.zayas@fibercrossing.net>
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Apr 2011 22:36:09 -0000

--Alternative__boundary__1304202960502
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Support.


William



-- Sent from my Palm Pre
On Apr 30, 2011 6:29 AM, Robert Raszuk &lt;raszuk@cisco.com&gt; wrote:=20



Support.



Thx,

R.



PS.  "August 15th May" - May I ask what calendar system is this ;-).





&gt; Colleagues,

&gt;

&gt; This e-mail is to start a poll on whether the L3VPN WG should adopt dr=
aft-rosen-l3vpn-mvpn-bidir-03.txt as a L3VPN WG document.

&gt;

&gt; Please indicate your support or otherwise by responding to this messag=
e (with yes/support or no/do not support) or e-mailing the WG chairs privat=
ely.

&gt;

&gt; If you do not support the adoption of the document it would be useful=
 if you could also state the reason for your objection.

&gt;

&gt; Please send your responses by midnight August 15th May PDT.

&gt;

&gt; FYI Eric has outlined his view on the need for this document on the ma=
iling list previously which you can read here:

&gt; http://www.ietf.org/mail-archive/web/l3vpn/current/msg02901.html

&gt;

&gt; Thanks

&gt; Ben

&gt;

&gt;







--Alternative__boundary__1304202960502
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Support.<br><br><br>William<br><br><span style=3D"font-family:Prelude, Verd=
ana, san-serif;"><br><br></span><span id=3D"signature"><div style=3D"font-f=
amily: arial, sans-serif; font-size: 12px;color: #999999;">-- Sent from my=
 Palm Pre</div><br></span><span style=3D"color:navy; font-family:Prelude,=
 Verdana, san-serif; "><hr align=3D"left" style=3D"width:75%">On Apr 30, 20=
11 6:29 AM, Robert Raszuk &lt;raszuk@cisco.com&gt; wrote: <br><br>
<br>Support.
<br>
<br>Thx,
<br>R.
<br>
<br>PS.  "August 15th May" - May I ask what calendar system is this ;-).
<br>
<br>
<br>&gt; Colleagues,
<br>&gt;
<br>&gt; This e-mail is to start a poll on whether the L3VPN WG should adop=
t draft-rosen-l3vpn-mvpn-bidir-03.txt as a L3VPN WG document.
<br>&gt;
<br>&gt; Please indicate your support or otherwise by responding to this me=
ssage (with yes/support or no/do not support) or e-mailing the WG chairs pr=
ivately.
<br>&gt;
<br>&gt; If you do not support the adoption of the document it would be use=
ful if you could also state the reason for your objection.
<br>&gt;
<br>&gt; Please send your responses by midnight August 15th May PDT.
<br>&gt;
<br>&gt; FYI Eric has outlined his view on the need for this document on th=
e mailing list previously which you can read here:
<br>&gt; http://www.ietf.org/mail-archive/web/l3vpn/current/msg02901.html
<br>&gt;
<br>&gt; Thanks
<br>&gt; Ben
<br>&gt;
<br>&gt;
<br>
<br>
<br></span>

--Alternative__boundary__1304202960502--


From keyupate@cisco.com  Sat Apr 30 15:53:35 2011
Return-Path: <keyupate@cisco.com>
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 B9704E06F0 for <l3vpn@ietfa.amsl.com>; Sat, 30 Apr 2011 15:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level: 
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[AWL=0.399,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhWGlBgnq-d9 for <l3vpn@ietfa.amsl.com>; Sat, 30 Apr 2011 15:53:35 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 2525AE0593 for <l3vpn@ietf.org>; Sat, 30 Apr 2011 15:53:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=847; q=dns/txt; s=iport; t=1304204015; x=1305413615; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=DBod49cN4E5FpeSeyKGBcw02AVAVlTgX0u2bIrweWE0=; b=BLlTyXjBhyluwmxSBi468TLsDLIgWVwiQZ0ywyV/yEjnk9ubw+RLp/Mp PvqfiXWXBosFzt2LpROkWcxE6Yk84A65PFZsd4dpV0sbxKITojxi0oW5Z Rjn97bT3pRqDAv7KhzikDZh3I+uU5VZH+fZR5+FqCQe+0MVoE4UgxDnQJ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAKCSvE2rRDoI/2dsb2JhbACmF3eIcZ86m1eGAASGDohrhCKKIA
X-IronPort-AV: E=Sophos;i="4.64,294,1301875200"; d="scan'208";a="347926034"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 30 Apr 2011 22:53:34 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3UMrYXl026036; Sat, 30 Apr 2011 22:53:34 GMT
Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 30 Apr 2011 15:53:34 -0700
Received: from 10.21.117.23 ([10.21.117.23]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([128.107.191.87]) with Microsoft Exchange Server HTTP-DAV ; Sat, 30 Apr 2011 22:53:34 +0000
User-Agent: Microsoft-Entourage/11.4.0.080122
Date: Sat, 30 Apr 2011 15:52:41 -0700
Subject: Re: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG document
From: Keyur Patel <keyupate@cisco.com>
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>, L3VPN WG mailing list <l3vpn@ietf.org>
Message-ID: <C9E1E0C9.1FB73%keyupate@cisco.com>
Thread-Topic: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG document
Thread-Index: AcwHiU9Yjgis1nN8EeCvQgAbY71bnA==
In-Reply-To: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 30 Apr 2011 22:53:34.0937 (UTC) FILETIME=[6F7E6490:01CC0789]
Cc: l3vpn-chairs@tools.ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Apr 2011 22:53:35 -0000

Support.

Regards,
Keyur


On 4/30/11 2:01 AM, "Ben Niven-Jenkins" <ben@niven-jenkins.co.uk> wrote:

> Colleagues,
>  
> This e-mail is to start a poll on whether the L3VPN WG should adopt
> draft-rosen-l3vpn-mvpn-bidir-03.txt as a L3VPN WG document.
>  
> Please indicate your support or otherwise by responding to this message (with
> yes/support or no/do not support) or e-mailing the WG chairs privately.
> 
> If you do not support the adoption of the document it would be useful if you
> could also state the reason for your objection.
>  
> Please send your responses by midnight August 15th May PDT.
> 
> FYI Eric has outlined his view on the need for this document on the mailing
> list previously which you can read here:
> http://www.ietf.org/mail-archive/web/l3vpn/current/msg02901.html
> 
> Thanks
> Ben
> 


From timwukp@cisco.com  Sat Apr 30 19:45:07 2011
Return-Path: <timwukp@cisco.com>
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 3DE06E0698 for <l3vpn@ietfa.amsl.com>; Sat, 30 Apr 2011 19:45:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level: 
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOOEg9thlG4R for <l3vpn@ietfa.amsl.com>; Sat, 30 Apr 2011 19:45:01 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B286EE0593 for <l3vpn@ietf.org>; Sat, 30 Apr 2011 19:45:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=timwukp@cisco.com; l=1033; q=dns/txt; s=iport; t=1304217900; x=1305427500; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=KblH+sOklofm5JklzU3jl/p7NZRlq0WGAldUKlNXFIQ=; b=MMyuKhitTOyuxGBEZw04fN/IpkN2kasjpnN5ikPGQN/UahbO4Q9Nu0z5 NQd259TPoL0kBpO3bn+qXsx0DmXC1eL4QJxOxsGopTHLdTIQdPmVOSCHn nhKcOkpVzHv6q0PnEyxmzkbBb8MMQuuclBuqswKBA57aZeEDdMmuN95tF w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AukAANfHvE2Q/khMgWdsb2JhbACYE44FFAEBFiYlqDSbTIYABIYMjQ+KDQ
X-IronPort-AV: E=Sophos;i="4.64,296,1301875200"; d="scan'208";a="28078399"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 01 May 2011 02:44:59 +0000
Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p412iwOb016794; Sun, 1 May 2011 02:44:59 GMT
Received: from xmb-hkg-418.apac.cisco.com ([64.104.123.90]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 1 May 2011 10:44:58 +0800
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG document
Date: Sun, 1 May 2011 10:44:54 +0800
Message-ID: <5AC9678F90B8BA4B9378EBE97DBB021A0969BA15@xmb-hkg-418.apac.cisco.com>
In-Reply-To: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG document
Thread-Index: AcwHFU10XBtiZy2SR6Gx8lJ3sTGc0gAlGVQA
References: <9DAB0E49-FC4C-486F-AAC3-9E089F586318@niven-jenkins.co.uk>
From: "Tim Wu (timwukp)" <timwukp@cisco.com>
To: "Ben Niven-Jenkins" <ben@niven-jenkins.co.uk>, "L3VPN WG mailing list" <l3vpn@ietf.org>
X-OriginalArrivalTime: 01 May 2011 02:44:58.0239 (UTC) FILETIME=[C29628F0:01CC07A9]
Cc: l3vpn-chairs@tools.ietf.org
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 May 2011 02:45:07 -0000

Support.

Rdgs,
Tim

-----Original Message-----
From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf
Of Ben Niven-Jenkins
Sent: Saturday, April 30, 2011 5:02 PM
To: L3VPN WG mailing list
Cc: l3vpn-chairs@tools.ietf.org
Subject: Poll to adopt draft-rosen-l3vpn-mvpn-bidir-03 as a L3VPN WG
document

Colleagues,
=20
This e-mail is to start a poll on whether the L3VPN WG should adopt
draft-rosen-l3vpn-mvpn-bidir-03.txt as a L3VPN WG document.
=20
Please indicate your support or otherwise by responding to this message
(with yes/support or no/do not support) or e-mailing the WG chairs
privately.

If you do not support the adoption of the document it would be useful if
you could also state the reason for your objection.
=20
Please send your responses by midnight August 15th May PDT.

FYI Eric has outlined his view on the need for this document on the
mailing list previously which you can read here:
http://www.ietf.org/mail-archive/web/l3vpn/current/msg02901.html

Thanks
Ben