Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04

[Jeffrey Haas <[e-mail]>]

I have a concern with regards to the MP-BGP nexthops for this draft:

This draft ties the MP-BGP nexthop associated with VPN-IPv6 reachability
to the BGP Speaker's transport session type.  I.e. an IPv6 transport session
will require IPv6 VPN-IPv6 nexthops and an IPv4 transport session will
require IPv4 VPN-IPv4 nexthops.

Why is this a SHALL?

MP-BGP allows for different address families to be carried across
the same BGP session regardless of the form of the transport session.
When carrying information for a different address family (e.g.
an ipv4 transport session carrying ipv6 reachability) it is necessary
to configure additional information about the endpoints of the session
for reachability calculations.  This draft appears to try to preclude
this option in some capacities for VPN-IPv6.

I would suspect that regardless of the transport session type, as
long as it was clear if the nexthop was v4 or v6 that as long as
a label-switched path could be established between the two BGP speakers
it shouldn't matter what kind of transport session is being used.

On Mon, Jan 17, 2005 at 07:52:37AM -0800, Yakov Rekhter wrote:
> Folks,
> 
> This message begins a last call on draft-ietf-l3vpn-bgp-ipv6-04. Last
> call ends on Feb 1 at midnight UTC.
> 
> Yakov.
> 
> P.S. this is a combined last call with the L3VPN WG.
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr



Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA04307 for <[e-mail]>; Mon, 31 Jan 2005 18:19:13 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvknv-0007Cf-GU; Mon, 31 Jan 2005 18:17:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvkg1-0000zb-O7 for [e-mail]; Mon, 31 Jan 2005 18:09:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19806 for <[e-mail]>; Mon, 31 Jan 2005 18:09:47 -0500 (EST)
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvky3-0006OV-4H for [e-mail]; Mon, 31 Jan 2005 18:28:28 -0500
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 75DD12D49DD; Mon, 31 Jan 2005 18:03:39 -0500 (EST)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 79631-01-28; Mon, 31 Jan 2005 18:03:37 -0500 (EST)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 716EE2D4870; Mon, 31 Jan 2005 18:03:37 -0500 (EST)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0VN3bu06598; Mon, 31 Jan 2005 18:03:37 -0500 (EST)
Date: Mon, 31 Jan 2005 18:03:37 -0500
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: Ross Callon <[e-mail]>, [e-mail], [e-mail], [e-mail], Ronald Bonica <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

I have a concern with regards to the MP-BGP nexthops for this draft:

This draft ties the MP-BGP nexthop associated with VPN-IPv6 reachability
to the BGP Speaker's transport session type.  I.e. an IPv6 transport session
will require IPv6 VPN-IPv6 nexthops and an IPv4 transport session will
require IPv4 VPN-IPv4 nexthops.

Why is this a SHALL?

MP-BGP allows for different address families to be carried across
the same BGP session regardless of the form of the transport session.
When carrying information for a different address family (e.g.
an ipv4 transport session carrying ipv6 reachability) it is necessary
to configure additional information about the endpoints of the session
for reachability calculations.  This draft appears to try to preclude
this option in some capacities for VPN-IPv6.

I would suspect that regardless of the transport session type, as
long as it was clear if the nexthop was v4 or v6 that as long as
a label-switched path could be established between the two BGP speakers
it shouldn't matter what kind of transport session is being used.

On Mon, Jan 17, 2005 at 07:52:37AM -0800, Yakov Rekhter wrote:
> Folks,
> 
> This message begins a last call on draft-ietf-l3vpn-bgp-ipv6-04. Last
> call ends on Feb 1 at midnight UTC.
> 
> Yakov.
> 
> P.S. this is a combined last call with the L3VPN WG.
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA13705 for <[e-mail]>; Mon, 31 Jan 2005 12:19:09 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvf2b-0003QF-V8; Mon, 31 Jan 2005 12:08:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CveqT-0000J9-77 for [e-mail]; Mon, 31 Jan 2005 11:56:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22857 for <[e-mail]>; Mon, 31 Jan 2005 11:56:10 -0500 (EST)
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvf8R-0008Rf-G5 for [e-mail]; Mon, 31 Jan 2005 12:14:48 -0500
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id DD4B62D4834; Mon, 31 Jan 2005 11:55:40 -0500 (EST)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 47428-02-32; Mon, 31 Jan 2005 11:55:39 -0500 (EST)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 017802D4815; Mon, 31 Jan 2005 11:55:39 -0500 (EST)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0VGtcB04375; Mon, 31 Jan 2005 11:55:38 -0500 (EST)
Date: Mon, 31 Jan 2005 11:55:38 -0500
From: Jeffrey Haas <[e-mail]>
To: "Francois Le Faucheur (flefauch)" <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: [e-mail], Yakov Rekhter <[e-mail]>, "Eric Rosen \(erosen\)" <[e-mail]>, [e-mail], [e-mail]
Subject: [Idr] Re: comment on draft-ietf-l3vpn-bgp-ipv6-04
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Fracois,

On Mon, Jan 31, 2005 at 05:48:34PM +0100, Francois Le Faucheur (flefauch) wrote:
> But I guess your comment is more addressed at newer SAFI values being
> defined more recently than the "MPLS-labeled VPN address" SAFI.

Exactly.

While we are unlikely to be able to get things changed at this late
stage, we should correct our procedure as quickly as possible. 

> Francois

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA12176 for <[e-mail]>; Mon, 31 Jan 2005 11:53:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvelo-0007I4-Kc; Mon, 31 Jan 2005 11:51:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvek3-0006pk-1r for [e-mail]; Mon, 31 Jan 2005 11:49:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22218 for <[e-mail]>; Mon, 31 Jan 2005 11:49:32 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvf21-0008Jb-53 for [e-mail]; Mon, 31 Jan 2005 12:08:10 -0500
Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Jan 2005 17:58:40 +0100
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0VGltQO028714; Mon, 31 Jan 2005 17:48:58 +0100 (MET)
Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211);  Mon, 31 Jan 2005 17:48:41 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 31 Jan 2005 17:48:34 +0100
Message-ID: <[e-mail]>
Thread-Topic: comment on draft-ietf-l3vpn-bgp-ipv6-04
Thread-Index: AcUHrIJ1mlhJWw0GSWq02MFTrJ/QmgABF+Tw
From: "Francois Le Faucheur \(flefauch\)" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 31 Jan 2005 16:48:41.0892 (UTC) FILETIME=[B862D640:01C507B4]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: [e-mail], [e-mail], "Francois Le Faucheur \(flefauch\)" <[e-mail]>, [e-mail], Yakov Rekhter <[e-mail]>, "Eric Rosen \(erosen\)" <[e-mail]>
Subject: [Idr] RE: comment on draft-ietf-l3vpn-bgp-ipv6-04
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id LAA12176

Hello Jeffrey,

Thanks for your comment.

As far as <draft-ietf-l3vpn-bgp-ipv6-04> is concerned, the natural thing
to do is of course just to use the same "MPLS-labeled VPN address" SAFI
value as defined in 2547bis.

As far as 2547bis is concerned, authors of that document are in a better
position than me to comment, but considering the huge implementation and
deployment base using SAFI=128 today, changing the private range from
128+ to 129+ seems to me like the right thing to do.

But I guess your comment is more addressed at newer SAFI values being
defined more recently than the "MPLS-labeled VPN address" SAFI.

Thanks

Francois

>> Date:    Thu, 27 Jan 2005 13:24:55 -0500
>> From:    Jeffrey Haas <[e-mail]>
>> To:      Yakov Rekhter <[e-mail]>, Alex Zinin 
>> <[e-mail]>
>> cc:      [e-mail], Ross Callon <[e-mail]>,
>> 	 Ronald Bonica <[e-mail]>, [e-mail],
>> 	 [e-mail]
>> Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
>> 
>> Yakov,
>> 
>> I'll try to find a bit of time to review this in detail, but the
>> IANA considerations of both this and the 2547bis section caught
>> my attention.
>> 
>> I understand the reasoning as to why they'd want their SAFI values to
>> not move, but this begs a broader question:
>> 
>> a) IDR has requested IANA to leave SAFIs 128+ as private use.
>>    A non-IDR group is requesting holes get poked in that policy.
>> b) Some quick googling shows a number of SAFI values being used that
>>    are going to be having the same problems.
>> 
>> Why exactly are they using private SAFI's (which were known to have
>> possible collision issues) instead of either requesting a first-come,
>> first-server allocation or requesting a value in the WG consensus
>> space?
>> 
>> 
>> On Mon, Jan 17, 2005 at 07:52:37AM -0800, Yakov Rekhter wrote:
>> > Folks,
>> > 
>> > This message begins a last call on 
>> draft-ietf-l3vpn-bgp-ipv6-04. Last
>> > call ends on Feb 1 at midnight UTC.
>> > 
>> > Yakov.
>> > 
>> > P.S. this is a combined last call with the L3VPN WG.
>> > 
>> > _______________________________________________
>> > Idr mailing list
>> > [e-mail]
>> > https://www1.ietf.org/mailman/listinfo/idr
>> 
>> - -- 
>> Jeff Haas 
>> NextHop Technologies
>> 
>> ------- End of Forwarded Message
>> 

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA10351 for <[e-mail]>; Mon, 31 Jan 2005 11:21:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cve2E-0005xW-SV; Mon, 31 Jan 2005 11:04:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvdyl-0005GE-Ap for [e-mail]; Mon, 31 Jan 2005 11:00:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15763 for <[e-mail]>; Mon, 31 Jan 2005 11:00:41 -0500 (EST)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CveGi-0006pL-Vd for [e-mail]; Mon, 31 Jan 2005 11:19:18 -0500
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j0VG09Bm077447; Mon, 31 Jan 2005 08:00:09 -0800 (PST) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j0VG09e80162; Mon, 31 Jan 2005 08:00:09 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 31 Jan 2005 08:00:09 -0800
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Cc: [e-mail]
Subject: [Idr] IDR WG agenda
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Folks,
 
Its about time to start thinking about agenda items for the next
IETF. Please forward any IDR agenda items you might have to me and Sue.

Sue & Yakov.

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA08368 for <[e-mail]>; Mon, 31 Jan 2005 10:46:52 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvdgv-00017M-Nq; Mon, 31 Jan 2005 10:42:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvdgf-00011K-5v for [e-mail]; Mon, 31 Jan 2005 10:42:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13670 for <[e-mail]>; Mon, 31 Jan 2005 10:41:58 -0500 (EST)
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvdyb-0006RX-UW for [e-mail]; Mon, 31 Jan 2005 11:00:35 -0500
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 533912D4FDF for <[e-mail]>; Mon, 31 Jan 2005 10:40:24 -0500 (EST)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 41401-02 for <[e-mail]>; Mon, 31 Jan 2005 10:40:19 -0500 (EST)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 4DAA42D4DA8 for <[e-mail]>; Mon, 31 Jan 2005 10:40:08 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 31 Jan 2005 10:40:08 -0500
Message-ID: <[e-mail]>
Thread-Topic: Last call on draft-ooms-v6ops-bgp-tunnel-04.txt 
Thread-Index: AcUHqySzetynr//TQb2tcNC2mxRXWg==
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235
Cc: Bill Fenner <[e-mail]>, [e-mail], "Francois Le Faucheur \(flefauch\)" <[e-mail]>, [e-mail]
Subject: [Idr] Last call on draft-ooms-v6ops-bgp-tunnel-04.txt 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0619640591=="
Sender: [e-mail]
Errors-To: [e-mail]

This is a multi-part message in MIME format.

--===============0619640591==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C507AB.245A1976"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C507AB.245A1976
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

=20

The last call is for moving the following document to

Proposed Standard:=20

=20

draft-ooms-v6ops-bgp-tunnel-04.txt
<http://www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp-tunnel-04.txt>




=20

 "Connecting IPv6 Islands over IPv4 MPLS

  using IPv6 Provider Edge Routers (6PE)"

=20

By J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur

=20

draft-ooms-v6ops-bgp-tunnel-04.txt
<http://www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp-tunnel-04.txt>




This last call will start today 1/31, and go for

2 weeks ending on 2/14.=20

=20

This document was created in another working group,

and forwarded by the Routing ADs for review by the

IDR working group.=20

=20

This Last call is not for the document to become an=20

IDR document.

=20

Please send comments to the list.

=20

Sue Hares and Yakov Rekhter

=20

=20


------_=_NextPart_001_01C507AB.245A1976
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>The last call is =
for moving the
following document to<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Proposed Standard: =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><a
href=3D"http://www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp-tunnel-0=
4.txt">draft-ooms-v6ops-bgp-tunnel-04.txt</a><br>
<br>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&#8220;</span></font><font =
face=3D"Courier New"><span
style=3D'font-family:"Courier New"'>Connecting IPv6 <st1:place =
w:st=3D"on">Islands</st1:place>
over IPv4 MPLS<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:12.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;using IPv6 Provider Edge Routers =
(6PE)&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Courier New"><span =
style=3D'font-size:12.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<pre><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>By J. De Clercq, D. Ooms, S. Prevost, F. Le =
Faucheur<o:p></o:p></span></font></pre>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><a
href=3D"http://www.ietf.org/internet-drafts/draft-ooms-v6ops-bgp-tunnel-0=
4.txt">draft-ooms-v6ops-bgp-tunnel-04.txt</a><br>
<br>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>This last call will start today 1/31, and go =
for<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>2 weeks ending on 2/14. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>This document was created in another working =
group,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>and forwarded by the Routing ADs for review =
by the<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>IDR working group. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>This Last call is not for the document to =
become an <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>IDR document.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Please send comments to the =
list.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Sue Hares and Yakov =
Rekhter<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C507AB.245A1976--


--===============0619640591==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr

--===============0619640591==--



Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA28170 for <[e-mail]>; Fri, 28 Jan 2005 11:55:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuZKl-0002lL-Um; Fri, 28 Jan 2005 11:50:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuZJG-0002R5-N3 for [e-mail]; Fri, 28 Jan 2005 11:49:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17691 for <[e-mail]>; Fri, 28 Jan 2005 11:49:23 -0500 (EST)
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuZad-0001V5-56 for [e-mail]; Fri, 28 Jan 2005 12:07:23 -0500
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9D8132D4BEF for <[e-mail]>; Fri, 28 Jan 2005 11:48:50 -0500 (EST)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 39332-01-75 for <[e-mail]>; Fri, 28 Jan 2005 11:48:46 -0500 (EST)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 111342D49DB for <[e-mail]>; Fri, 28 Jan 2005 11:48:46 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] MInutes for IDR
Date: Fri, 28 Jan 2005 11:48:45 -0500
Message-ID: <[e-mail]>
Thread-Topic: [Idr] MInutes for IDR
Thread-Index: AcTe1M1W6rWg0MNgQM+kkJPUpeMTcwCKb+IABur4V/ACKcgaAAAB5cBg
From: "Susan Hares" <[e-mail]>
To: "Francois Le Faucheur (flefauch)" <[e-mail]>, <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
Cc: [e-mail], [e-mail], Bill Fenner <[e-mail]>, Pekka Savola <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id LAA28170

Francis:

Did you create an implementation report on this document? 

Sue

-----Original Message-----
From: Francois Le Faucheur (flefauch) [mailto:[e-mail]] 
Sent: Friday, January 28, 2005 11:02 AM
To: Susan Hares; [e-mail]
Cc: [e-mail]; [e-mail]; Bill Fenner; Francois Le Faucheur (flefauch); Pekka Savola
Subject: RE: [Idr] MInutes for IDR

Hello Susan and Yakov,

If I am mistaken and we did not agree to issue Last Call on draft-ooms-v6ops-bgp-tunnel-04.txt, could you let me know and remind me of the reasons and what needs to be done for that to happen?
If I am not mistaken and we did agree to that, could we do that Last Call?

Thank you

Francois

>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On 
>> Behalf Of Francois Le Faucheur (flefauch)
>> Sent: lundi 17 janvier 2005 16:39
>> To: Susan Hares
>> Cc: [e-mail]
>> Subject: RE: [Idr] MInutes for IDR
>> 
>> Hello Susan,
>> 
>> Did I miss the updated IDR Minutes?
>> Could we go ahead with the Last Call on 
>> draft-ooms-v6ops-bgp-tunnel-04.txt?
>> 
>> Thanks
>> 
>> Francois
>> 
>> >> -----Original Message-----
>> >> From: Francois Le Faucheur (flefauch) 
>> >> Sent: lundi 13 décembre 2004 12:39
>> >> To: Susan Hares
>> >> Cc: [e-mail]; Francois Le Faucheur (flefauch); 
>> [e-mail]
>> >> Subject: RE: [Idr] MInutes for IDR
>> >> 
>> >> Hi Sue,
>> >>  
>> >> Comments on the minutes re bgp-tunnel:
>> >> 
>> >> 
>> >> 	IPv6 over IPv4 MPLS (Francis LeFaucheur, presenter)
>> >> 	---------------------------------------------------
>> >> Right spelling for my name is "Francois Le Faucheur"
>> >> I suggest listing the draft being discussed 
>> >> (draft-ooms-v6ops-bgp-tunnel-04.txt)
>> >> 
>> >> 	The draft presents a technique, which will be 
>> >> coordinated with V6OPS 
>> >> 
>> >> s/which will be/which has been/
>> >> 
>> >> 	through the ADs, for providing IPv6 service over an 
>> >> existing IPv4 MPLS 
>> >> 	cloud, without the cloud needing to be V6-aware. The 
>> >> proposed solution 
>> >> 	is intended to require no protocll extensions (see 
>> >> 
>> >> s/is intented to require no/does not require any/
>> >> 
>> >> 	draft-ietf-l3vpn-bgp-ipv6). It carris labels in MP-BGP.  The 
>> >> 
>> >> Please remove the reference to draft-ietf-l3vpn-bgp-ipv6 
>> >> above. The stamement about not requiring protocol extensions 
>> >> in bgp-tunnel has nothing to do with l3vpn-bgp-ipv6.
>> >> 
>> >> 	requiriemens are stated in 
>> >> 	 
>> >> 	  draft-ietf-v6ops-isp-scenarios-analysis-03.txt.
>> >> 	 
>> >> 	Draft 04 is underway, and will clarify some MUST/SHOULD 
>> >> terminology, 
>> >> 	expand on the inter-AS cases, and add additional detail 
>> >> on security.
>> >> 
>> >> There is some confusion here. The 03-->04 changes related to 
>> >> the bgp-tunnel draft (not to isp-scenario). These changes 
>> >> have already been done in bgp-tunnel-04. 
>> >> So the above should read:
>> >> "bgp-tunnel-04 includes the following changes over the 
>> >> previous version: clarify some MUST/SHOULD terminology, 
>> >> expand on the inter-AS cases, and add additional detail 
>> on security."
>> >> 
>> >> 	Publication of this specification will involve 
>> >> coordinated documents 
>> >> 	between V6OPS and IDR, consistent where possible and 
>> >> different where 
>> >> 	necessary. For example, the V6OPS document will carry 
>> >> label SAFI/AFI 
>> >> 	while the IDR document will carry VPN SAFI/AFI.
>> >> 
>> >> This paragraph mixes everything up. It should read:
>> >> "draft-ooms-v6ops-bgp-tunnel-04.txt specifies support for 
>> >> global IPv6 reachability services while 
>> >> draft-ietf-l3vpn-bgp-ipv6-03.txt specifies support for IPv6 
>> >> VPN services. The two documents are consistent wherever they 
>> >> can be and are only different where needed (eg bgp-tunnel 
>> >> uses "labeled IPv6" AFI/SAFI while l3vpn-bgp-ipv6 uses 
>> >> "VPN-IPv6" AFI/SAFI).
>> >> 	 
>> >> 	After the editorial changes are complete, the document 
>> >> will go out for 
>> >> 	last call and implementation survey.
>> >> 	 
>> >> I believe what was agreed was that the document was ready 
>> >> for Last Call and the Last Call was going to be issued right 
>> >> after Wash IETF. So I suggest replacing previous paragraph 
>> >> with something like:
>> >> "The document will go out for Last Call after this meeting".
>> >> 
>> >> Thank you
>> >> 
>> >> Francois
>> >> 
>> >> 
>> 
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/idr
>> 


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA25630 for <[e-mail]>; Fri, 28 Jan 2005 11:23:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuYoA-00010a-Uk; Fri, 28 Jan 2005 11:17:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuYZv-00053D-KN for [e-mail]; Fri, 28 Jan 2005 11:02:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12516 for <[e-mail]>; Fri, 28 Jan 2005 11:02:33 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuYrH-0008QG-Mt for [e-mail]; Fri, 28 Jan 2005 11:20:32 -0500
Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 28 Jan 2005 17:13:22 +0100
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0SG1YWY007757;  Fri, 28 Jan 2005 17:02:00 +0100 (MET)
Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0);  Fri, 28 Jan 2005 17:01:57 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] MInutes for IDR
Date: Fri, 28 Jan 2005 17:01:52 +0100
Message-ID: <[e-mail]>
Thread-Topic: [Idr] MInutes for IDR
Thread-Index: AcTe1M1W6rWg0MNgQM+kkJPUpeMTcwCKb+IABur4V/ACKcgaAA==
From: "Francois Le Faucheur \(flefauch\)" <[e-mail]>
To: "Susan Hares" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 28 Jan 2005 16:01:57.0563 (UTC) FILETIME=[B1A2F0B0:01C50552]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Cc: [e-mail], [e-mail], "Francois Le Faucheur \(flefauch\)" <[e-mail]>, Bill Fenner <[e-mail]>, Pekka Savola <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id LAA25630

Hello Susan and Yakov,

If I am mistaken and we did not agree to issue Last Call on draft-ooms-v6ops-bgp-tunnel-04.txt, could you let me know and remind me of the reasons and what needs to be done for that to happen?
If I am not mistaken and we did agree to that, could we do that Last Call?

Thank you

Francois

>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On 
>> Behalf Of Francois Le Faucheur (flefauch)
>> Sent: lundi 17 janvier 2005 16:39
>> To: Susan Hares
>> Cc: [e-mail]
>> Subject: RE: [Idr] MInutes for IDR
>> 
>> Hello Susan,
>> 
>> Did I miss the updated IDR Minutes?
>> Could we go ahead with the Last Call on 
>> draft-ooms-v6ops-bgp-tunnel-04.txt?
>> 
>> Thanks
>> 
>> Francois
>> 
>> >> -----Original Message-----
>> >> From: Francois Le Faucheur (flefauch) 
>> >> Sent: lundi 13 décembre 2004 12:39
>> >> To: Susan Hares
>> >> Cc: [e-mail]; Francois Le Faucheur (flefauch); 
>> [e-mail]
>> >> Subject: RE: [Idr] MInutes for IDR
>> >> 
>> >> Hi Sue,
>> >>  
>> >> Comments on the minutes re bgp-tunnel:
>> >> 
>> >> 
>> >> 	IPv6 over IPv4 MPLS (Francis LeFaucheur, presenter)
>> >> 	---------------------------------------------------
>> >> Right spelling for my name is "Francois Le Faucheur"
>> >> I suggest listing the draft being discussed 
>> >> (draft-ooms-v6ops-bgp-tunnel-04.txt)
>> >> 
>> >> 	The draft presents a technique, which will be 
>> >> coordinated with V6OPS 
>> >> 
>> >> s/which will be/which has been/
>> >> 
>> >> 	through the ADs, for providing IPv6 service over an 
>> >> existing IPv4 MPLS 
>> >> 	cloud, without the cloud needing to be V6-aware. The 
>> >> proposed solution 
>> >> 	is intended to require no protocll extensions (see 
>> >> 
>> >> s/is intented to require no/does not require any/
>> >> 
>> >> 	draft-ietf-l3vpn-bgp-ipv6). It carris labels in MP-BGP.  The 
>> >> 
>> >> Please remove the reference to draft-ietf-l3vpn-bgp-ipv6 
>> >> above. The stamement about not requiring protocol extensions 
>> >> in bgp-tunnel has nothing to do with l3vpn-bgp-ipv6.
>> >> 
>> >> 	requiriemens are stated in 
>> >> 	 
>> >> 	  draft-ietf-v6ops-isp-scenarios-analysis-03.txt.
>> >> 	 
>> >> 	Draft 04 is underway, and will clarify some MUST/SHOULD 
>> >> terminology, 
>> >> 	expand on the inter-AS cases, and add additional detail 
>> >> on security.
>> >> 
>> >> There is some confusion here. The 03-->04 changes related to 
>> >> the bgp-tunnel draft (not to isp-scenario). These changes 
>> >> have already been done in bgp-tunnel-04. 
>> >> So the above should read:
>> >> "bgp-tunnel-04 includes the following changes over the 
>> >> previous version: clarify some MUST/SHOULD terminology, 
>> >> expand on the inter-AS cases, and add additional detail 
>> on security."
>> >> 
>> >> 	Publication of this specification will involve 
>> >> coordinated documents 
>> >> 	between V6OPS and IDR, consistent where possible and 
>> >> different where 
>> >> 	necessary. For example, the V6OPS document will carry 
>> >> label SAFI/AFI 
>> >> 	while the IDR document will carry VPN SAFI/AFI.
>> >> 
>> >> This paragraph mixes everything up. It should read:
>> >> "draft-ooms-v6ops-bgp-tunnel-04.txt specifies support for 
>> >> global IPv6 reachability services while 
>> >> draft-ietf-l3vpn-bgp-ipv6-03.txt specifies support for IPv6 
>> >> VPN services. The two documents are consistent wherever they 
>> >> can be and are only different where needed (eg bgp-tunnel 
>> >> uses "labeled IPv6" AFI/SAFI while l3vpn-bgp-ipv6 uses 
>> >> "VPN-IPv6" AFI/SAFI).
>> >> 	 
>> >> 	After the editorial changes are complete, the document 
>> >> will go out for 
>> >> 	last call and implementation survey.
>> >> 	 
>> >> I believe what was agreed was that the document was ready 
>> >> for Last Call and the Last Call was going to be issued right 
>> >> after Wash IETF. So I suggest replacing previous paragraph 
>> >> with something like:
>> >> "The document will go out for Last Call after this meeting".
>> >> 
>> >> Thank you
>> >> 
>> >> Francois
>> >> 
>> >> 
>> 
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/idr
>> 

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA05974 for <[e-mail]>; Thu, 27 Jan 2005 14:12:44 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuF21-0001Xk-48; Thu, 27 Jan 2005 14:10:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuF0m-000133-QA for [e-mail]; Thu, 27 Jan 2005 14:09:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13647 for <[e-mail]>; Thu, 27 Jan 2005 14:08:58 -0500 (EST)
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuFHv-0003uI-LM for [e-mail]; Thu, 27 Jan 2005 14:26:45 -0500
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 78CB92D51DB; Thu, 27 Jan 2005 14:08:27 -0500 (EST)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 53684-01-13; Thu, 27 Jan 2005 14:08:23 -0500 (EST)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 527F42D51AF; Thu, 27 Jan 2005 14:08:22 -0500 (EST)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0RJ8Mj14565; Thu, 27 Jan 2005 14:08:22 -0500 (EST)
Date: Thu, 27 Jan 2005 14:08:22 -0500
From: Jeffrey Haas <[e-mail]>
To: Rajesh Potti <[e-mail]>
Subject: Re: [Idr] ORF
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Rajesh,

On Thu, Jan 27, 2005 at 01:50:28PM -0500, Rajesh Potti wrote:
> With community ORF,  if i need to deny just one community, say 1:1, and 
> accept everything else, including those routes with no communities, is 
> it possible? A wildcard is not specified in the  route-filter draft.

Once upon a draft (specifically -07 and before), the mechanism was
"this set of communities" with a scope of "normal" or "exact".

The type of policy you desire (forbid this, allow everything else) is no
longer possible.

> Rajesh

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA05462 for <[e-mail]>; Thu, 27 Jan 2005 14:00:47 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuEn9-0004rP-17; Thu, 27 Jan 2005 13:54:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuEjV-0003Q3-9d for [e-mail]; Thu, 27 Jan 2005 13:51:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12130 for <[e-mail]>; Thu, 27 Jan 2005 13:51:07 -0500 (EST)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuF0f-0003RC-1x for [e-mail]; Thu, 27 Jan 2005 14:08:54 -0500
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j0RIoTN29105; Thu, 27 Jan 2005 13:50:29 -0500 (EST)
Received: from nortelnetworks.com (wbl6y4n15.us.nortel.com [47.16.75.12]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZAVFHK8X; Thu, 27 Jan 2005 13:50:28 -0500
Message-ID: <[e-mail]>
Date: Thu, 27 Jan 2005 13:50:28 -0500
From: Rajesh Potti <[e-mail]>
Organization: Nortel Networks
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jeffrey Haas <[e-mail]>
Subject: Re: [Idr] ORF
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Jeffrey Haas wrote:

>Rajesh,
>
>On Thu, Jan 27, 2005 at 01:04:58PM -0500, Rajesh Potti wrote:
>  
>
>>If the intersection is not empty, it is either denied or permitted,
>>according to the Match component. If the resulting set is empty, is the
>>route filtered.
>>    
>>
>
>And therefore an implicit deny.
>

 With community ORF,  if i need to deny just one community, say 1:1, and 
accept everything else, including those routes with no communities, is 
it possible? A wildcard is not specified in the  route-filter draft.

Rajesh

>
>  
>
>>If ORF capability for community ORF was not negotiated, the
>>route would not have been filtered.
>>    
>>
>
>And therefore an implicit permit.
>
>  
>
>>If the route is
>>Filtered on the intersection being empty, would it try to look at other ORFs
>>such as prefix list ORF or ASPATH ORF, which were negotiated.
>>    
>>
>
>:    If a BGP speaker maintains multiple ORFs of different ORF-Types for a
>:    particular peer, then the decision by the speaker to advertise a
>:    route to the peer is determined by passing the route through each
>:    such ORF, and and-ing the results (and-ing of PERMIT and DENY results
>:    in DENY).
>
>  
>
>>Rajesh
>>    
>>
>
>  
>


-- 
Rajesh Potti.




_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA04394 for <[e-mail]>; Thu, 27 Jan 2005 13:40:13 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuESS-0005oq-Et; Thu, 27 Jan 2005 13:33:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuELB-0003bN-GS for [e-mail]; Thu, 27 Jan 2005 13:26:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08987 for <[e-mail]>; Thu, 27 Jan 2005 13:25:57 -0500 (EST)
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuEcL-0002fg-VH for [e-mail]; Thu, 27 Jan 2005 13:43:46 -0500
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 248392D4D72; Thu, 27 Jan 2005 13:25:30 -0500 (EST)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 48734-01-65; Thu, 27 Jan 2005 13:25:22 -0500 (EST)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id B23BE2D51DB; Thu, 27 Jan 2005 13:25:00 -0500 (EST)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0RIOt514460; Thu, 27 Jan 2005 13:24:55 -0500 (EST)
Date: Thu, 27 Jan 2005 13:24:55 -0500
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>, Alex Zinin <[e-mail]>
Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: Ross Callon <[e-mail]>, [e-mail], [e-mail], [e-mail], Ronald Bonica <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Yakov,

I'll try to find a bit of time to review this in detail, but the
IANA considerations of both this and the 2547bis section caught
my attention.

I understand the reasoning as to why they'd want their SAFI values to
not move, but this begs a broader question:

a) IDR has requested IANA to leave SAFIs 128+ as private use.
   A non-IDR group is requesting holes get poked in that policy.
b) Some quick googling shows a number of SAFI values being used that
   are going to be having the same problems.

Why exactly are they using private SAFI's (which were known to have
possible collision issues) instead of either requesting a first-come,
first-server allocation or requesting a value in the WG consensus
space?


On Mon, Jan 17, 2005 at 07:52:37AM -0800, Yakov Rekhter wrote:
> Folks,
> 
> This message begins a last call on draft-ietf-l3vpn-bgp-ipv6-04. Last
> call ends on Feb 1 at midnight UTC.
> 
> Yakov.
> 
> P.S. this is a combined last call with the L3VPN WG.
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA04252 for <[e-mail]>; Thu, 27 Jan 2005 13:37:40 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuER1-00054R-6n; Thu, 27 Jan 2005 13:32:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuEI3-0002iJ-Mn for [e-mail]; Thu, 27 Jan 2005 13:22:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08877 for <[e-mail]>; Thu, 27 Jan 2005 13:22:44 -0500 (EST)
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuEZD-0002cQ-BS for [e-mail]; Thu, 27 Jan 2005 13:40:32 -0500
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5CDBE2D5234; Thu, 27 Jan 2005 13:16:16 -0500 (EST)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 47894-02-74; Thu, 27 Jan 2005 13:16:12 -0500 (EST)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id ABFA22D51BE; Thu, 27 Jan 2005 13:16:04 -0500 (EST)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0RIG4s14428; Thu, 27 Jan 2005 13:16:04 -0500 (EST)
Date: Thu, 27 Jan 2005 13:16:04 -0500
From: Jeffrey Haas <[e-mail]>
To: Rajesh Potti <[e-mail]>
Subject: Re: [Idr] ORF
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Rajesh,

On Thu, Jan 27, 2005 at 01:04:58PM -0500, Rajesh Potti wrote:
> If the intersection is not empty, it is either denied or permitted,
> according to the Match component. If the resulting set is empty, is the
> route filtered.

And therefore an implicit deny.

> If ORF capability for community ORF was not negotiated, the
> route would not have been filtered.

And therefore an implicit permit.

> If the route is
> Filtered on the intersection being empty, would it try to look at other ORFs
> such as prefix list ORF or ASPATH ORF, which were negotiated.

:    If a BGP speaker maintains multiple ORFs of different ORF-Types for a
:    particular peer, then the decision by the speaker to advertise a
:    route to the peer is determined by passing the route through each
:    such ORF, and and-ing the results (and-ing of PERMIT and DENY results
:    in DENY).

> Rajesh

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA03728 for <[e-mail]>; Thu, 27 Jan 2005 13:27:02 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuEFd-0001kC-AU; Thu, 27 Jan 2005 13:20:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuE1S-0004pn-Ff for [e-mail]; Thu, 27 Jan 2005 13:05:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07476 for <[e-mail]>; Thu, 27 Jan 2005 13:05:35 -0500 (EST)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuEIb-0002Do-Bc for [e-mail]; Thu, 27 Jan 2005 13:23:23 -0500
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j0RI50318594; Thu, 27 Jan 2005 13:05:00 -0500 (EST)
Received: by zbl6c002.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id <ZAVFHJM6>; Thu, 27 Jan 2005 13:05:00 -0500
Message-ID: <[e-mail]>
From: "Rajesh Potti" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>
Subject: RE: [Idr] ORF
Date: Thu, 27 Jan 2005 13:04:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1090139849=="
Sender: [e-mail]
Errors-To: [e-mail]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1090139849==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5049A.B6C47E14"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C5049A.B6C47E14
Content-Type: text/plain

Hi Jefrrey,

 My comments inline.

-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail] <mailto:[e-mail]> ] 
Sent: Thursday, January 27, 2005 11:45 AM
To: Potti, Rajesh [BL60:SF21:EXCH]
Cc: [e-mail]
Subject: Re: [Idr] ORF


Rajesh,

>From the draft:
:   The remote peer should consider only those routes whose Communities
:   attribute has at least one Community in common with the Communities
:   list specified in the ORF.

Thus, if the route has no communities, it can not have any communities in
common (at least one) with the ORF.

Put a different way, this is an set intersection operation.  If the
resulting set of the route's communities intersected with the community orf
is the empty set, it doesn't match.


If the intersection is not empty, it is either denied or permitted,
according to the Match component. If the resulting set is empty, is the
route filtered. If ORF capability for community ORF was not negotiated, the
route would not have been filtered. If the route is
Filtered on the intersection being empty, would it try to look at other ORFs
such as prefix list ORF or ASPATH ORF, which were negotiated. I mean, it
does not match any community ORF entry, but it matches a prefix-list ORF
entry from the neighbor.

Rajesh


On Mon, Jan 24, 2005 at 05:27:07PM -0500, Rajesh Potti wrote:
> 
> The draft "cooperative Route Filtering Capability for BGP-4"
> 
> (draft-ietf-idr-route-filter-11.txt) does not specify the action - 
> PERMIT or DENY, if the to be
> Advertised route  Does not have a community, or if the route has a
community
> which 
> does not match any Of the community ORF entries received. The prefix-list
> ORF filter draft 
> specifies a wildcard Match, which is not the case with the community orf.

> 
> Rajesh

> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
<https://www1.ietf.org/mailman/listinfo/idr> 


-- 
Jeff Haas 
NextHop Technologies

------_=_NextPart_001_01C5049A.B6C47E14
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Idr] ORF</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Jefrrey,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;My comments inline.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Jeffrey Haas [</FONT><A =
HREF=3D"mailto:[e-mail]"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">mailto:[e-mail]</FONT></U></A><FONT SIZE=3D2 =
FACE=3D"Arial">] </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Thursday, January 27, 2005 =
11:45 AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: Potti, Rajesh =
[BL60:SF21:EXCH]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: Re: [Idr] ORF</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Rajesh,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">From the draft:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">:&nbsp;&nbsp; The remote peer should =
consider only those routes whose Communities</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">:&nbsp;&nbsp; attribute has at least =
one Community in common with the Communities</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">:&nbsp;&nbsp; list specified in the =
ORF.</FONT>
</P>

<P><I><FONT SIZE=3D2 FACE=3D"Arial">Thus, if the route has no =
communities, it can not have any communities in common (at least one) =
with the ORF.</FONT></I>
</P>

<P><I><FONT SIZE=3D2 FACE=3D"Arial">Put a different way, this is an set =
intersection operation.&nbsp; If the resulting set of the route's =
communities intersected with the community orf is the empty set, it =
doesn't match.</FONT></I></P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">If the intersection is not empty, it =
is either denied or permitted, according to the Match component. If the =
resulting set is empty, is the route filtered. If ORF capability for =
community ORF was not negotiated, the route would not have been =
filtered. If the route is</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Filtered on the intersection being =
empty, would it try to look at other ORFs such as prefix list ORF or =
ASPATH ORF, which were negotiated. I mean, it does not match any =
community ORF entry, but it matches a prefix-list ORF entry from the =
neighbor.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Rajesh</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">On Mon, Jan 24, 2005 at 05:27:07PM =
-0500, Rajesh Potti wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The draft &quot;cooperative =
Route Filtering Capability for BGP-4&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; =
(draft-ietf-idr-route-filter-11.txt) does not specify the action - =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; PERMIT or DENY, if the to =
be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Advertised route&nbsp; Does not =
have a community, or if the route has a community</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; which </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; does not match any Of the =
community ORF entries received. The prefix-list</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; ORF filter draft </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; specifies a wildcard Match, =
which is not the case with the community orf.&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Rajesh</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Idr mailing list</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; [e-mail]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/idr"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">https://www1.ietf.org/mailman/=
listinfo/idr</FONT></U></A>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Jeff Haas </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">NextHop Technologies</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C5049A.B6C47E14--


--===============1090139849==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr

--===============1090139849==--



Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA28675 for <[e-mail]>; Thu, 27 Jan 2005 11:54:13 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuCrf-0004wv-Gl; Thu, 27 Jan 2005 11:51:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuCmN-0003Bt-Ma for [e-mail]; Thu, 27 Jan 2005 11:45:59 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28110 for <[e-mail]>; Thu, 27 Jan 2005 11:45:56 -0500 (EST)
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuD3W-0008Ru-GG for [e-mail]; Thu, 27 Jan 2005 12:03:43 -0500
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 4530B2D5198; Thu, 27 Jan 2005 11:45:23 -0500 (EST)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 40139-02-85; Thu, 27 Jan 2005 11:45:19 -0500 (EST)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C193C2D4D97; Thu, 27 Jan 2005 11:45:13 -0500 (EST)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0RGjD514093; Thu, 27 Jan 2005 11:45:13 -0500 (EST)
Date: Thu, 27 Jan 2005 11:45:13 -0500
From: Jeffrey Haas <[e-mail]>
To: Rajesh Potti <[e-mail]>
Subject: Re: [Idr] ORF
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Rajesh,

>From the draft:
:   The remote peer should consider only those routes whose Communities
:   attribute has at least one Community in common with the Communities
:   list specified in the ORF.

Thus, if the route has no communities, it can not have any communities
in common (at least one) with the ORF.

Put a different way, this is an set intersection operation.  If the
resulting set of the route's communities intersected with the community
orf is the empty set, it doesn't match.


On Mon, Jan 24, 2005 at 05:27:07PM -0500, Rajesh Potti wrote:
> 
> The draft "cooperative Route Filtering Capability for BGP-4" 
> 
> (draft-ietf-idr-route-filter-11.txt) does not specify the action - PERMIT or
> DENY, 
> if the to be 
> Advertised route  Does not have a community, or if the route has a community
> which 
> does not match any Of the community ORF entries received. The prefix-list
> ORF filter draft 
> specifies a wildcard Match, which is not the case with the community orf.  
> 
> Rajesh

> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr


-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA16897 for <[e-mail]>; Tue, 25 Jan 2005 11:17:49 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtTJv-0006nD-7y; Tue, 25 Jan 2005 11:13:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtTDY-0005FV-0J for [e-mail]; Tue, 25 Jan 2005 11:07:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15896 for <[e-mail]>; Tue, 25 Jan 2005 11:06:57 -0500 (EST)
Received: from relay00.pair.com ([209.68.1.20] helo=relay.pair.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CtTUH-0006UD-Ld for [e-mail]; Tue, 25 Jan 2005 11:24:17 -0500
Received: (qmail 61186 invoked from network); 25 Jan 2005 16:06:49 -0000
Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 25 Jan 2005 16:06:49 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j0PG6Qmp010148; Tue, 25 Jan 2005 11:06:26 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: [Idr] AS deletion and reording in the AS_PATH
Date: Tue, 25 Jan 2005 11:06:26 -0500
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

A clarification.  Obviously I misread Sandy's second point in her
original email.  See below.  My mistake.

Curtis


------- Forwarded Message

Message-Id: <[e-mail]>
To: Sandy Murphy <[e-mail]>
cc: [e-mail]
Reply-To: [e-mail]
Subject: Re: [Idr] AS deletion and reording in the AS_PATH 
In-reply-to: Your message of "Mon, 24 Jan 2005 17:44:04 EST."
             <[e-mail]> 
Date: Mon, 24 Jan 2005 22:57:00 -0500
From: Curtis Villamizar <[e-mail]>


In message <[e-mail]>
Sandy Murphy writes:
>  
> (Private response)
>  
> I asked:
>  
> >> Second:  would those on the list agree that any manipulation other than
> >> "prepends its own AS number" is allowed, on the basis of there being "no
> >> mention" of the alternate manipulation?
>  
> You said:
>  
> >The text says that the AS Path is updated "as follows".  It does not
> >say "as follows or in any other arbitrary way".
>  
> which would say that you did NOT AGREE that any manipulation ... is allowed

Right.  Arbitrary manipulations are not allowed.

> Then you say:
>  
> >I agree with the second point.
>  
> which says you AGREE that "any manipulation ... is allowed"

OK.  So I disagree.  Your wording got me on the first read.

> Then you say:
>  
> >The intent is to prohibit any
> >modification of the AS path, except when aggregating, other than the
> >modification specificly described above.
>  
> which would seem to imply that you do NOT AGREE that "any manipulation 
> ... is allowed

That's right.

> I'm guessing that "I agree with the second point" means "No, I would
> not agree that any manipulation ... is allowed".
>  
> But strictly speaking it doesn't say that.

That's what I meant.  Someone must have a confusing double negative in
a sentence somewhere or something but we seem to be on the same
wavelength.  Arbitrary manipulation is not intended to be allowed.

> If "I agree with the second point" means what I think it means,
> could you clarify for the list?
>  
> --Sandy

OK

Curtis


------- End of Forwarded Message


_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA18100 for <[e-mail]>; Mon, 24 Jan 2005 17:40:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCmt-0007QF-Jo; Mon, 24 Jan 2005 17:34:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCgV-0005S7-Fm for [e-mail]; Mon, 24 Jan 2005 17:27:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09550 for <[e-mail]>; Mon, 24 Jan 2005 17:27:44 -0500 (EST)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCx3-00028j-0G for [e-mail]; Mon, 24 Jan 2005 17:44:56 -0500
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j0OMR8I14428; Mon, 24 Jan 2005 17:27:09 -0500 (EST)
Received: by zbl6c002.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id <ZAVF15M3>; Mon, 24 Jan 2005 17:27:08 -0500
Message-ID: <[e-mail]>
From: "Rajesh Potti" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Date: Mon, 24 Jan 2005 17:27:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: [e-mail]
Subject: [Idr] ORF
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1377475171=="
Sender: [e-mail]
Errors-To: [e-mail]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1377475171==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C50263.2A15383E"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C50263.2A15383E
Content-Type: text/plain


The draft "cooperative Route Filtering Capability for BGP-4" 

(draft-ietf-idr-route-filter-11.txt) does not specify the action - PERMIT or
DENY, 
if the to be 
Advertised route  Does not have a community, or if the route has a community
which 
does not match any Of the community ORF entries received. The prefix-list
ORF filter draft 
specifies a wildcard Match, which is not the case with the community orf.  

Rajesh

------_=_NextPart_001_01C50263.2A15383E
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.2">
<TITLE>ORF</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>The draft &quot;cooperative Route Filtering Capability for BGP-4&quot; </FONT>
</P>

<P><FONT SIZE=2>(draft-ietf-idr-route-filter-11.txt) does not specify the action - PERMIT or DENY, </FONT>
<BR><FONT SIZE=2>if the to be </FONT>
<BR><FONT SIZE=2>Advertised route&nbsp; Does not have a community, or if the route has a community which </FONT>
<BR><FONT SIZE=2>does not match any Of the community ORF entries received. The prefix-list ORF filter draft </FONT>
<BR><FONT SIZE=2>specifies a wildcard Match, which is not the case with the community orf.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>Rajesh</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C50263.2A15383E--


--===============1377475171==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr

--===============1377475171==--



Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA17881 for <[e-mail]>; Mon, 24 Jan 2005 17:37:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCmq-0007Or-Op; Mon, 24 Jan 2005 17:34:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCfw-0005PQ-Lk for [e-mail]; Mon, 24 Jan 2005 17:27:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09508 for <[e-mail]>; Mon, 24 Jan 2005 17:27:09 -0500 (EST)
Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CtCwX-00028e-70 for [e-mail]; Mon, 24 Jan 2005 17:44:21 -0500
Received: (qmail 52616 invoked from network); 24 Jan 2005 22:27:11 -0000
Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 24 Jan 2005 22:27:11 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j0OMQvs2008063; Mon, 24 Jan 2005 17:26:57 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Sandy Murphy <[e-mail]>
Subject: Re: [Idr] prepending one's own AS on the AS_PATH 
In-reply-to: Your message of "Mon, 24 Jan 2005 13:01:50 EST." <[e-mail]> 
Date: Mon, 24 Jan 2005 17:26:56 -0500
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
Sandy Murphy writes:
>  
> On the rpsec list, Russ White has made two interesting observations.
>  
> >On searching the document for all occurances of the words: "as_path," or: 
> >"as path," I found only a few instances. The one I _believe_ is relevant is 
> >here, on page 25:
> >
> >         b) When a given BGP speaker advertises the route to an external
> >         peer, then the advertising speaker updates the AS_PATH attribute
> >         as follows:
> >
> >            1) if the first path segment of the AS_PATH is of type
> >            AS_SEQUENCE, the local system prepends its own AS number as the
> >            last element of the sequence (put it in the leftmost position
> >            with respect to the position of octets in the protocol mes-
> >            sage). If the act of prepending will cause an overflow in the
> >            AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a
> >            new segment of type AS_SEQUENCE and prepend its own AS number
> >            to this new segment.
> >
> >When I examine this text, I find two interesting things:
>  
> >...
>  
> >-- Second, when describing the operation of a BGP speaker, the draft 
> >doesn't say the speaker MUST prepend its own AS number as the last element 
> >of the sequence, it says it "will." In my experience, when a draft means 
> >"MUST," it uses "MUST," rather than "will." This implies the writers of 
> >this specification (if you refer to page 7, you'll find I'm listed as a 
> >contributor) believed there were valid situations when a BGP speaker would 
> >not follow the operational procedure described here.
>  
> Good catch, Russ!!!
>  
> This has been discussed many times in idr meetings.
>  
> I actually softenend the language in the vulnerabilities draft when
> talking about prepending your AS to the AS_PATH, because (I was told)
> the newest draft said that prepending your own AS on the AS_PATH was
> required.  I missed the absence of the "MUST" language.
>  
> So - was the MUST removed because there are circumstances in which one
> would not prepend one's own AS?  (Route reflectors I remember as being
> mentioned in this regard at times.)  Or was this an oversight and the
> MUST language was intended?
>  
> Note: if legitimate incoming AS_PATHs might not have the peer's AS
> appended, then the implementations can't check for this, and bogus
> AS_PATHs will be acceptable.  The vulnerabilities draft already speaks
> of what happens if implementations don't do the checking, so I think
> there's no additional vulnerability.  It's just that the vulnerability
> would be due to design, not implementation weakness.
>  
> --Sandy


Sandy,

I don't think that was the intent at all.  The "prepends" rather than
a "MUST prepend" is an oversight.  If what Russ stated was intended
the word "SHOULD" would appear there, not "prepends".  The word "will"
is used in the phrase "If the act of prepending will cause an
overflow".  That sentence contains a "SHOULD".

In practice, removing duplicates might be an alternative here (where
som other AS has done AS padding to affect AS path length).  Dropping
the advertisement would be another alternative.  If the "SHOULD" is
violated, as in all cases where SHOULD is specified, it may be at some
peril.  Care is advised.

Curtis

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA17455 for <[e-mail]>; Mon, 24 Jan 2005 17:31:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCdg-0004Hn-Lp; Mon, 24 Jan 2005 17:24:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCXd-0002Q1-6W for [e-mail]; Mon, 24 Jan 2005 17:18:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08830 for <[e-mail]>; Mon, 24 Jan 2005 17:18:32 -0500 (EST)
Received: from relay00.pair.com ([209.68.1.20] helo=relay.pair.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CtCoA-0001li-F5 for [e-mail]; Mon, 24 Jan 2005 17:35:43 -0500
Received: (qmail 85845 invoked from network); 24 Jan 2005 22:18:28 -0000
Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 24 Jan 2005 22:18:28 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j0OMIDik008043; Mon, 24 Jan 2005 17:18:13 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Sandy Murphy <[e-mail]>
Subject: Re: [Idr] AS deletion and reording in the AS_PATH 
In-reply-to: Your message of "Mon, 24 Jan 2005 12:47:36 EST." <[e-mail]> 
Date: Mon, 24 Jan 2005 17:18:13 -0500
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
Sandy Murphy writes:
>  
> On the rpsec list, Russ White has made two interesting observations.
> The first concerns deleting or reordering the AS's in an AS_PATH when
> creating the AS_PATH for an UPDATE:
>  
> >On searching the document for all occurances of the words: "as_path," or: 
> >"as path," I found only a few instances. The one I _believe_ is relevant is 
> >here, on page 25:
> >
> >         b) When a given BGP speaker advertises the route to an external
> >         peer, then the advertising speaker updates the AS_PATH attribute
> >         as follows:
> >
> >            1) if the first path segment of the AS_PATH is of type
> >            AS_SEQUENCE, the local system prepends its own AS number as the
> >            last element of the sequence (put it in the leftmost position
> >            with respect to the position of octets in the protocol mes-
> >            sage). If the act of prepending will cause an overflow in the
> >            AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a
> >            new segment of type AS_SEQUENCE and prepend its own AS number
> >            to this new segment.
> >
> >When I examine this text, I find two interesting things:
> >
> >-- First, there is no mention of any conditions under which information may 
> >be removed from the AS Path, or the AS Path is reordered. I believe, based 
> >on reading of the specification (without outside reference to operational 
> >or implementation experience), this means the AS Path may be reordered, or 
> >information may be removed from the AS Path. Let me at least say neither of 
> >these are strictly prohibited.
>  
>  
> First: would those on the list agree that deleting or reordering the AS's
> in an AS_PATH is an OK thing to do?
>  
> Second:  would those on the list agree that any manipulation other than
> "prepends its own AS number" is allowed, on the basis of there being "no
> mention" of the alternate manipulation?
>  
> --Sandy


The text says that the AS Path is updated "as follows".  It does not
say "as follows or in any other arbitrary way".

The reality has always been that violations of the spec do occur when
someone considers it in their interest to do so and when it doesn't
mess up interoperability or cause operational problems.  The IETF
doesn't have any means of enforcement and that's probably a good thing.

Chopping the middle could create loops.  Reordering probably doesn't
have any adverse consequence unless someone else policy is based on a
sequence of AS in a particular order.  Since it has a negative
consequence and no benefit, reordering is at the very least a bad
idea.

Therefore deleting is definitely a bad thing to do.  Reordering is
also a bad thing to do.

I agree with the second point.  The intent is to prohibit any
modification of the AS path, except when aggregating, other than the
modification specificly described above.

Curtis

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA14587 for <[e-mail]>; Mon, 24 Jan 2005 16:36:55 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBgX-0000mg-DA; Mon, 24 Jan 2005 16:23:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBKo-000104-QO for [e-mail]; Mon, 24 Jan 2005 16:01:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25116 for <[e-mail]>; Mon, 24 Jan 2005 16:01:16 -0500 (EST)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtBbN-0004mP-Bp for [e-mail]; Mon, 24 Jan 2005 16:18:26 -0500
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Jan 2005 14:09:19 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mira-sjc5-b.cisco.com (IDENT:[e-mail] [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0OL0TM8021296; Mon, 24 Jan 2005 13:00:30 -0800 (PST)
Received: from [10.10.10.52] (sjc-rraszuk-vpn1.cisco.com [10.25.90.226]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BAY00255; Mon, 24 Jan 2005 13:00:37 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 24 Jan 2005 13:00:34 -0800
From: Robert Raszuk <[e-mail]>
Organization: Signature: http://www.employees.org/~raszuk/sig/
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sandy Murphy <[e-mail]>
Subject: Re: [Idr] prepending one's own AS on the AS_PATH
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

An interesting observation is that the latest draft does not prohibit 
one from also prepending someone else's AS# to the AS_PATH. In fact on 
one of the past RIPE meetings I saw a very interesting presentation from 
William Norton where he showed what kind of tricks folks do with AS_PATH 
to get a better peering agreements ;).

http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-routing-art-peering/

Cheers,
R.

 > Sandy Murphy wrote:
 >
> On the rpsec list, Russ White has made two interesting observations.
> 
> 
>>On searching the document for all occurances of the words: "as_path," or: 
>>"as path," I found only a few instances. The one I _believe_ is relevant is 
>>here, on page 25:
>>
>>        b) When a given BGP speaker advertises the route to an external
>>        peer, then the advertising speaker updates the AS_PATH attribute
>>        as follows:
>>
>>           1) if the first path segment of the AS_PATH is of type
>>           AS_SEQUENCE, the local system prepends its own AS number as the
>>           last element of the sequence (put it in the leftmost position
>>           with respect to the position of octets in the protocol mes-
>>           sage). If the act of prepending will cause an overflow in the
>>           AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a
>>           new segment of type AS_SEQUENCE and prepend its own AS number
>>           to this new segment.
>>
>>When I examine this text, I find two interesting things:
> 
> 
>>...
> 
> 
>>-- Second, when describing the operation of a BGP speaker, the draft 
>>doesn't say the speaker MUST prepend its own AS number as the last element 
>>of the sequence, it says it "will." In my experience, when a draft means 
>>"MUST," it uses "MUST," rather than "will." This implies the writers of 
>>this specification (if you refer to page 7, you'll find I'm listed as a 
>>contributor) believed there were valid situations when a BGP speaker would 
>>not follow the operational procedure described here.
> 
> 
> Good catch, Russ!!!
> 
> This has been discussed many times in idr meetings.
> 
> I actually softenend the language in the vulnerabilities draft when
> talking about prepending your AS to the AS_PATH, because (I was told)
> the newest draft said that prepending your own AS on the AS_PATH was
> required.  I missed the absence of the "MUST" language.
> 
> So - was the MUST removed because there are circumstances in which one
> would not prepend one's own AS?  (Route reflectors I remember as being
> mentioned in this regard at times.)  Or was this an oversight and the
> MUST language was intended?
> 
> Note: if legitimate incoming AS_PATHs might not have the peer's AS
> appended, then the implementations can't check for this, and bogus
> AS_PATHs will be acceptable.  The vulnerabilities draft already speaks
> of what happens if implementations don't do the checking, so I think
> there's no additional vulnerability.  It's just that the vulnerability
> would be due to design, not implementation weakness.
> 
> --Sandy
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
> 

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA03709 for <[e-mail]>; Mon, 24 Jan 2005 13:19:52 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8if-0003PK-31; Mon, 24 Jan 2005 13:13:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8Yq-0000vB-My for [e-mail]; Mon, 24 Jan 2005 13:03:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06860 for <[e-mail]>; Mon, 24 Jan 2005 13:03:33 -0500 (EST)
Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct8pN-0005ta-Sx for [e-mail]; Mon, 24 Jan 2005 13:20:43 -0500
Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OI07PS022156 for <[e-mail]>; Mon, 24 Jan 2005 13:00:07 -0500 (EST)
Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAYSa4qR; Mon, 24 Jan 05 13:00:04 -0500
Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OI1oWw020156; Mon, 24 Jan 2005 13:01:50 -0500 (EST)
Date: Mon, 24 Jan 2005 13:01:50 -0500 (EST)
From: Sandy Murphy <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: [e-mail]
Subject: [Idr] prepending one's own AS on the AS_PATH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

On the rpsec list, Russ White has made two interesting observations.

>On searching the document for all occurances of the words: "as_path," or: 
>"as path," I found only a few instances. The one I _believe_ is relevant is 
>here, on page 25:
>
>         b) When a given BGP speaker advertises the route to an external
>         peer, then the advertising speaker updates the AS_PATH attribute
>         as follows:
>
>            1) if the first path segment of the AS_PATH is of type
>            AS_SEQUENCE, the local system prepends its own AS number as the
>            last element of the sequence (put it in the leftmost position
>            with respect to the position of octets in the protocol mes-
>            sage). If the act of prepending will cause an overflow in the
>            AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a
>            new segment of type AS_SEQUENCE and prepend its own AS number
>            to this new segment.
>
>When I examine this text, I find two interesting things:

>...

>-- Second, when describing the operation of a BGP speaker, the draft 
>doesn't say the speaker MUST prepend its own AS number as the last element 
>of the sequence, it says it "will." In my experience, when a draft means 
>"MUST," it uses "MUST," rather than "will." This implies the writers of 
>this specification (if you refer to page 7, you'll find I'm listed as a 
>contributor) believed there were valid situations when a BGP speaker would 
>not follow the operational procedure described here.

Good catch, Russ!!!

This has been discussed many times in idr meetings.

I actually softenend the language in the vulnerabilities draft when
talking about prepending your AS to the AS_PATH, because (I was told)
the newest draft said that prepending your own AS on the AS_PATH was
required.  I missed the absence of the "MUST" language.

So - was the MUST removed because there are circumstances in which one
would not prepend one's own AS?  (Route reflectors I remember as being
mentioned in this regard at times.)  Or was this an oversight and the
MUST language was intended?

Note: if legitimate incoming AS_PATHs might not have the peer's AS
appended, then the implementations can't check for this, and bogus
AS_PATHs will be acceptable.  The vulnerabilities draft already speaks
of what happens if implementations don't do the checking, so I think
there's no additional vulnerability.  It's just that the vulnerability
would be due to design, not implementation weakness.

--Sandy

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA03193 for <[e-mail]>; Mon, 24 Jan 2005 13:11:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8Ta-0008HQ-2y; Mon, 24 Jan 2005 12:58:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8L1-0005sO-LE for [e-mail]; Mon, 24 Jan 2005 12:49:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05727 for <[e-mail]>; Mon, 24 Jan 2005 12:49:16 -0500 (EST)
Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct8bY-0005Nh-O7 for [e-mail]; Mon, 24 Jan 2005 13:06:25 -0500
Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OHjoiJ020717 for <[e-mail]>; Mon, 24 Jan 2005 12:45:50 -0500 (EST)
Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAeJaqDO; Mon, 24 Jan 05 12:45:47 -0500
Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OHla55019676; Mon, 24 Jan 2005 12:47:36 -0500 (EST)
Date: Mon, 24 Jan 2005 12:47:36 -0500 (EST)
From: Sandy Murphy <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: [e-mail]
Subject: [Idr] AS deletion and reording in the AS_PATH
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

On the rpsec list, Russ White has made two interesting observations.
The first concerns deleting or reordering the AS's in an AS_PATH when
creating the AS_PATH for an UPDATE:

>On searching the document for all occurances of the words: "as_path," or: 
>"as path," I found only a few instances. The one I _believe_ is relevant is 
>here, on page 25:
>
>         b) When a given BGP speaker advertises the route to an external
>         peer, then the advertising speaker updates the AS_PATH attribute
>         as follows:
>
>            1) if the first path segment of the AS_PATH is of type
>            AS_SEQUENCE, the local system prepends its own AS number as the
>            last element of the sequence (put it in the leftmost position
>            with respect to the position of octets in the protocol mes-
>            sage). If the act of prepending will cause an overflow in the
>            AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a
>            new segment of type AS_SEQUENCE and prepend its own AS number
>            to this new segment.
>
>When I examine this text, I find two interesting things:
>
>-- First, there is no mention of any conditions under which information may 
>be removed from the AS Path, or the AS Path is reordered. I believe, based 
>on reading of the specification (without outside reference to operational 
>or implementation experience), this means the AS Path may be reordered, or 
>information may be removed from the AS Path. Let me at least say neither of 
>these are strictly prohibited.


First: would those on the list agree that deleting or reordering the AS's
in an AS_PATH is an OK thing to do?

Second:  would those on the list agree that any manipulation other than
"prepends its own AS number" is allowed, on the basis of there being "no
mention" of the alternate manipulation?

--Sandy

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA13170 for <[e-mail]>; Mon, 17 Jan 2005 11:06:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZJ3-00013K-8v; Mon, 17 Jan 2005 11:00:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZC4-0008FK-C3 for [e-mail]; Mon, 17 Jan 2005 10:53:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17615 for <[e-mail]>; Mon, 17 Jan 2005 10:53:25 -0500 (EST)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZR8-0007og-7y for [e-mail]; Mon, 17 Jan 2005 11:09:03 -0500
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j0HFqo987522;  Mon, 17 Jan 2005 07:52:50 -0800 (PST) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j0HFqbe42633; Mon, 17 Jan 2005 07:52:37 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 17 Jan 2005 07:52:37 -0800
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Cc: Ross Callon <[e-mail]>, Ronald Bonica <[e-mail]>, [e-mail], [e-mail]
Subject: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Folks,

This message begins a last call on draft-ietf-l3vpn-bgp-ipv6-04. Last
call ends on Feb 1 at midnight UTC.

Yakov.

P.S. this is a combined last call with the L3VPN WG.

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA12617 for <[e-mail]>; Mon, 17 Jan 2005 10:49:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZ1R-0005gv-Ty; Mon, 17 Jan 2005 10:42:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqYzc-00058A-Tx for [e-mail]; Mon, 17 Jan 2005 10:40:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16171 for <[e-mail]>; Mon, 17 Jan 2005 10:40:34 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZEd-0007SX-QJ for [e-mail]; Mon, 17 Jan 2005 10:56:11 -0500
Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 17 Jan 2005 16:58:21 +0100
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0HFdfWK004055; Mon, 17 Jan 2005 16:39:58 +0100 (MET)
Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211);  Mon, 17 Jan 2005 16:39:42 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Idr] MInutes for IDR
Date: Mon, 17 Jan 2005 16:39:14 +0100
Message-ID: <[e-mail]>
Thread-Topic: [Idr] MInutes for IDR
Thread-Index: AcTe1M1W6rWg0MNgQM+kkJPUpeMTcwCKb+IABur4V/A=
From: "Francois Le Faucheur \(flefauch\)" <[e-mail]>
To: "Susan Hares" <[e-mail]>
X-OriginalArrivalTime: 17 Jan 2005 15:39:42.0990 (UTC) FILETIME=[C3A002E0:01C4FCAA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id KAA12617

Hello Susan,

Did I miss the updated IDR Minutes?
Could we go ahead with the Last Call on draft-ooms-v6ops-bgp-tunnel-04.txt?

Thanks

Francois

>> -----Original Message-----
>> From: Francois Le Faucheur (flefauch) 
>> Sent: lundi 13 décembre 2004 12:39
>> To: Susan Hares
>> Cc: [e-mail]; Francois Le Faucheur (flefauch); [e-mail]
>> Subject: RE: [Idr] MInutes for IDR
>> 
>> Hi Sue,
>>  
>> Comments on the minutes re bgp-tunnel:
>> 
>> 
>> 	IPv6 over IPv4 MPLS (Francis LeFaucheur, presenter)
>> 	---------------------------------------------------
>> Right spelling for my name is "Francois Le Faucheur"
>> I suggest listing the draft being discussed 
>> (draft-ooms-v6ops-bgp-tunnel-04.txt)
>> 
>> 	The draft presents a technique, which will be 
>> coordinated with V6OPS 
>> 
>> s/which will be/which has been/
>> 
>> 	through the ADs, for providing IPv6 service over an 
>> existing IPv4 MPLS 
>> 	cloud, without the cloud needing to be V6-aware. The 
>> proposed solution 
>> 	is intended to require no protocll extensions (see 
>> 
>> s/is intented to require no/does not require any/
>> 
>> 	draft-ietf-l3vpn-bgp-ipv6). It carris labels in MP-BGP.  The 
>> 
>> Please remove the reference to draft-ietf-l3vpn-bgp-ipv6 
>> above. The stamement about not requiring protocol extensions 
>> in bgp-tunnel has nothing to do with l3vpn-bgp-ipv6.
>> 
>> 	requiriemens are stated in 
>> 	 
>> 	  draft-ietf-v6ops-isp-scenarios-analysis-03.txt.
>> 	 
>> 	Draft 04 is underway, and will clarify some MUST/SHOULD 
>> terminology, 
>> 	expand on the inter-AS cases, and add additional detail 
>> on security.
>> 
>> There is some confusion here. The 03-->04 changes related to 
>> the bgp-tunnel draft (not to isp-scenario). These changes 
>> have already been done in bgp-tunnel-04. 
>> So the above should read:
>> "bgp-tunnel-04 includes the following changes over the 
>> previous version: clarify some MUST/SHOULD terminology, 
>> expand on the inter-AS cases, and add additional detail on security."
>> 
>> 	Publication of this specification will involve 
>> coordinated documents 
>> 	between V6OPS and IDR, consistent where possible and 
>> different where 
>> 	necessary. For example, the V6OPS document will carry 
>> label SAFI/AFI 
>> 	while the IDR document will carry VPN SAFI/AFI.
>> 
>> This paragraph mixes everything up. It should read:
>> "draft-ooms-v6ops-bgp-tunnel-04.txt specifies support for 
>> global IPv6 reachability services while 
>> draft-ietf-l3vpn-bgp-ipv6-03.txt specifies support for IPv6 
>> VPN services. The two documents are consistent wherever they 
>> can be and are only different where needed (eg bgp-tunnel 
>> uses "labeled IPv6" AFI/SAFI while l3vpn-bgp-ipv6 uses 
>> "VPN-IPv6" AFI/SAFI).
>> 	 
>> 	After the editorial changes are complete, the document 
>> will go out for 
>> 	last call and implementation survey.
>> 	 
>> I believe what was agreed was that the document was ready 
>> for Last Call and the Last Call was going to be issued right 
>> after Wash IETF. So I suggest replacing previous paragraph 
>> with something like:
>> "The document will go out for Last Call after this meeting".
>> 
>> Thank you
>> 
>> Francois
>> 
>> 

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr