[Idr] BGP 1771 follow-on draft : Scalability,etc

[Erblichs <[e-mail]>]

	Group, here are a few suggestions to this document
	that deal with scalability and minimizing convergence
	timeframes.

	6.5 Hold Timer Expired error Handling
	--------------------------------------

	A) If a situation occurs that prevents the
	reception of a KEEPALIVE at Router-B from
	Router-A, delayed or retransmitted by IP/TCP
	for UPDATES will keep the connection open...

		AND

	B) With the current situation to decrease bandwidth
	the non-transmiting of KEEPALIVES will have no
	effect as long as UPDATES are sent within the HOLD
	Timer interval

		AND
	
	C) KEEPALIVES that are incorrectly configured will
	seem to keep a connection alive as long as UPDATES
	are recieved from the same neighbor

		AND

	D) If a NOTIFICATION is recieved, since the connection
	is closed after sending it, the reciept of this forces
	the connection to stay open HOLD TIME interval longer
	without the connection being 2-way.

	Thus with the proper handling of KEEPALIVES specified
	lower in this set of suggestions, only the KEEPALIVE
	is needed to be processed to keep the connection open.
	

	TCP / BGP Interactions
	----------------------
	Even though BGP uses TCP as its transport protocol,
	the formation of large BGP protocol packets that are
	multiple MTU sizes will force IP to fragment it into
	multiple MTU sized packets. The loss of just one
	fragment will cause the entire original large packet
	to be resent. Each fragment will be handled and
	routed independently. The over-head of fragmenting
	and then re-assembling of the packet will also
	delay reception of the packet at the BGP destination,
	due to the fact that all the fragments must be
	recieved before being handed to BGP.

	Default TCP behaviour is to initially probe for bandwidth
	availablity, during what is known as slow start. This
	initial slow-start is normally set at 4 MTUs/segments.If a
	burst of TCP data is required that is greater than what
	is the current window transmit capability, the transmitter
	will wait for acknowledgements or a large timeout
	before transmitting additional data. These acknowledgements
	will come in approximate 1 round-trip time frame. 

	This situation also
	occurs after idle times, which prevents burst of data.

	Lastly, current TCP implimentations will back-off window
	sizes, if the current applications are not using the max
	size of the transmit window. Thus is known as application
	versus network bandwidth limited.

	Thus, in some/many environments, the limiting of the size of
	a packet to within the MTU size and sending multiple full
	 header packets versus sending 1 large packet os preferable.
	This almost gurantees that packets are recieved within
	1 round trip time verus 5 or more RTTs for large fragmentated
	packets.


	Neighbor Scalability
	--------------------
	(ex:Update message storm)
	Under some environments,  KEEPALIVE messages can be recieved
	and not processed within Hold Timer intervals. If these
	messages are not handled in such a way that they are
	guranteed to be processed before the timer expires,
	the neighbor adjacency will normally be dropped. One possible
	suggestion is to mark the input control packet queue
	as to the current end of the queue when the timer expires,
	and to process to that mark before processing the
	functions that deal with this timer.

	If the queue is being filled and KEEPALIVES are being dropped
	due tail-drops, then their is a small chance that a UPDATE
	from the same BGP-router as the KEEPALIVE would be present.


	Neighbor Flapping
	------------------
	Under some circumstances including short Hold Timers,
	neighbors may be repeatedly dropped. Any updates/routes/etc
	could/SHOULD be placed on a delay queue. A interval
	timer should be set to X and to not exceeed 2x the max
	time frame between past flaps of the neighbor. After
	this timer / time interval has passed, it is less likely 
	to flap in the near time frame.

Mitchell Erblich

_______________________________________________
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 XAA25435 for <[e-mail]>; Mon, 28 Feb 2005 23:07:57 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5yfJ-00022w-JH; Mon, 28 Feb 2005 23:07:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5yfF-00022r-NS for [e-mail]; Mon, 28 Feb 2005 23:07:17 -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 XAA11923 for <[e-mail]>; Mon, 28 Feb 2005 23:07:15 -0500 (EST)
Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5yg7-0000be-Fy for [e-mail]; Mon, 28 Feb 2005 23:08:12 -0500
Received: from h-68-164-89-21.snvacaid.dynamic.covad.net ([68.164.89.21] helo=earthlink.net) by pop-a065b10.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1D5yfD-0002Lt-00 for [e-mail]; Mon, 28 Feb 2005 20:07:15 -0800
Message-ID: <[e-mail]>
Date: Mon, 28 Feb 2005 19:53:00 -0800
From: Erblichs <[e-mail]>
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Content-Transfer-Encoding: 7bit
Subject: [Idr] BGP 1771 follow-on draft : Scalability,etc
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]

	Group, here are a few suggestions to this document
	that deal with scalability and minimizing convergence
	timeframes.

	6.5 Hold Timer Expired error Handling
	--------------------------------------

	A) If a situation occurs that prevents the
	reception of a KEEPALIVE at Router-B from
	Router-A, delayed or retransmitted by IP/TCP
	for UPDATES will keep the connection open...

		AND

	B) With the current situation to decrease bandwidth
	the non-transmiting of KEEPALIVES will have no
	effect as long as UPDATES are sent within the HOLD
	Timer interval

		AND
	
	C) KEEPALIVES that are incorrectly configured will
	seem to keep a connection alive as long as UPDATES
	are recieved from the same neighbor

		AND

	D) If a NOTIFICATION is recieved, since the connection
	is closed after sending it, the reciept of this forces
	the connection to stay open HOLD TIME interval longer
	without the connection being 2-way.

	Thus with the proper handling of KEEPALIVES specified
	lower in this set of suggestions, only the KEEPALIVE
	is needed to be processed to keep the connection open.
	

	TCP / BGP Interactions
	----------------------
	Even though BGP uses TCP as its transport protocol,
	the formation of large BGP protocol packets that are
	multiple MTU sizes will force IP to fragment it into
	multiple MTU sized packets. The loss of just one
	fragment will cause the entire original large packet
	to be resent. Each fragment will be handled and
	routed independently. The over-head of fragmenting
	and then re-assembling of the packet will also
	delay reception of the packet at the BGP destination,
	due to the fact that all the fragments must be
	recieved before being handed to BGP.

	Default TCP behaviour is to initially probe for bandwidth
	availablity, during what is known as slow start. This
	initial slow-start is normally set at 4 MTUs/segments.If a
	burst of TCP data is required that is greater than what
	is the current window transmit capability, the transmitter
	will wait for acknowledgements or a large timeout
	before transmitting additional data. These acknowledgements
	will come in approximate 1 round-trip time frame. 

	This situation also
	occurs after idle times, which prevents burst of data.

	Lastly, current TCP implimentations will back-off window
	sizes, if the current applications are not using the max
	size of the transmit window. Thus is known as application
	versus network bandwidth limited.

	Thus, in some/many environments, the limiting of the size of
	a packet to within the MTU size and sending multiple full
	 header packets versus sending 1 large packet os preferable.
	This almost gurantees that packets are recieved within
	1 round trip time verus 5 or more RTTs for large fragmentated
	packets.


	Neighbor Scalability
	--------------------
	(ex:Update message storm)
	Under some environments,  KEEPALIVE messages can be recieved
	and not processed within Hold Timer intervals. If these
	messages are not handled in such a way that they are
	guranteed to be processed before the timer expires,
	the neighbor adjacency will normally be dropped. One possible
	suggestion is to mark the input control packet queue
	as to the current end of the queue when the timer expires,
	and to process to that mark before processing the
	functions that deal with this timer.

	If the queue is being filled and KEEPALIVES are being dropped
	due tail-drops, then their is a small chance that a UPDATE
	from the same BGP-router as the KEEPALIVE would be present.


	Neighbor Flapping
	------------------
	Under some circumstances including short Hold Timers,
	neighbors may be repeatedly dropped. Any updates/routes/etc
	could/SHOULD be placed on a delay queue. A interval
	timer should be set to X and to not exceeed 2x the max
	time frame between past flaps of the neighbor. After
	this timer / time interval has passed, it is less likely 
	to flap in the near time frame.

Mitchell Erblich

_______________________________________________
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 NAA28754 for <[e-mail]>; Mon, 28 Feb 2005 13:46:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5ppq-0007Ac-Aj; Mon, 28 Feb 2005 13:41:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5ppp-0007AX-B6 for [e-mail]; Mon, 28 Feb 2005 13:41: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 NAA20607 for <[e-mail]>; Mon, 28 Feb 2005 13:41:34 -0500 (EST)
Received: from smtp-out.hotpop.com ([38.113.3.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5pqa-0005gd-Q1 for [e-mail]; Mon, 28 Feb 2005 13:42:27 -0500
Received: from hotpop.com (kubrick.hotpop.com [38.113.3.103]) by smtp-out.hotpop.com (Postfix) with SMTP id B0FA2F21A6F for <[e-mail]>; Mon, 28 Feb 2005 18:41:20 +0000 (UTC)
Received: from ALOKLXP (generic.riverstonenet.com [66.17.149.13]) by smtp-3.hotpop.com (Postfix) with ESMTP id BDFA0147AA59 for <[e-mail]>; Mon, 28 Feb 2005 18:41:16 +0000 (UTC)
Message-ID: <008101c51dc5$1d195750$[e-mail]>
From: "Alok" <[e-mail]>
To: <[e-mail]>
References: <011c01c51d99$9ac746c0$[e-mail]> <[e-mail]>
Subject: Re: [Idr] BGP as an IGP
Date: Tue, 1 Mar 2005 00:11:22 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-HotPOP: ----------------------------------------------- Sent By HotPOP.com FREE Email Get your FREE POP email at www.HotPOP.com -----------------------------------------------
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Content-Transfer-Encoding: 7bit
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]

Thank you all for your responses and the references.

I am not talking about recursive resolution.

However, I am still at loss to comprehend what is wrong with static to
"adjacent" loopbacks (topology being physical full mesh or not)

Perhaps I should clarify this offlist.

-thanks
Alok


----- Original Message ----- 
From: "Robert Raszuk" <[e-mail]>
To: "Alok" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, February 28, 2005 10:04 PM
Subject: Re: [Idr] BGP as an IGP


> Alok,
>
> Using BGP as an IGP works well when the number of routers involved is
> less or equal then two. When you have real network you are much better
> using real IGP to resolve bgp next hops as opposed to multi level BGP
> recursion or whole bunch of static routes.
>
> Once we get on the same page there then we can move to selecting bgp
> route distribution scheme :). Either one listed below has pros & cons.
>
> Cheers,
> R.
>
> PS. Btw that sounds more like a question to isp-bgp list then to idr.
>
>  > Alok wrote:
>  >
> > Hi,
> >
> >
> > Are there any good references to using BGP as an IGP in the following
> > scenarios:
> >
> > a. using RRs. (topology being a ring)
> > b. using Full mesh. (topology being full mesh)
> > c. using confederations (topology being triangles joined together)
> >
> > In terms of scalability, what is the most recommended?
> >
> > -thanks
> > Alok
> >
> > _______________________________________________
> > 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 LAA16531 for <[e-mail]>; Mon, 28 Feb 2005 11:45:15 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5nrA-0003vs-Ft; Mon, 28 Feb 2005 11:34:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5nr5-0003vj-Ma for [e-mail]; Mon, 28 Feb 2005 11:34: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 LAA06528 for <[e-mail]>; Mon, 28 Feb 2005 11:34:45 -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 1D5nrq-0002Ub-Vm for [e-mail]; Mon, 28 Feb 2005 11:35:36 -0500
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2005 09:50:04 +0000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.90,123,1107734400";  d="scan'208"; a="229992692:sNHT24533296"
Received: from mira-sjc5-b.cisco.com (IDENT:[e-mail] [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1SGYVq8008730; Mon, 28 Feb 2005 08:34:31 -0800 (PST)
Received: from [10.10.10.53] (ams-rraszuk-3002-1.cisco.com [10.61.160.138]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCG10816; Mon, 28 Feb 2005 08:34:31 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 28 Feb 2005 08:34:30 -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: Alok <[e-mail]>
Subject: Re: [Idr] BGP as an IGP
References: <011c01c51d99$9ac746c0$[e-mail]>
In-Reply-To: <011c01c51d99$9ac746c0$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
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]

Alok,

Using BGP as an IGP works well when the number of routers involved is 
less or equal then two. When you have real network you are much better 
using real IGP to resolve bgp next hops as opposed to multi level BGP 
recursion or whole bunch of static routes.

Once we get on the same page there then we can move to selecting bgp 
route distribution scheme :). Either one listed below has pros & cons.

Cheers,
R.

PS. Btw that sounds more like a question to isp-bgp list then to idr.

 > Alok wrote:
 >
> Hi,
> 
> 
> Are there any good references to using BGP as an IGP in the following
> scenarios:
> 
> a. using RRs. (topology being a ring)
> b. using Full mesh. (topology being full mesh)
> c. using confederations (topology being triangles joined together)
> 
> In terms of scalability, what is the most recommended?
> 
> -thanks
> Alok
> 
> _______________________________________________
> 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 JAA01342 for <[e-mail]>; Mon, 28 Feb 2005 09:17:59 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5lhP-0005fl-4T; Mon, 28 Feb 2005 09:16:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5lhN-0005ff-3a for [e-mail]; Mon, 28 Feb 2005 09:16: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 JAA22990 for <[e-mail]>; Mon, 28 Feb 2005 09:16:35 -0500 (EST)
Received: from [216.33.203.198] (helo=reel.nullroute.net ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5li7-00081A-7o for [e-mail]; Mon, 28 Feb 2005 09:17:24 -0500
Received: from airport.nullroute.net ([e-mail] [216.33.203.195] (may be forged)) by reel.nullroute.net (8.13.1/8.13.1) with ESMTP id j1SE97pC004675; Mon, 28 Feb 2005 09:09:07 -0500
Date: Mon, 28 Feb 2005 09:09:07 -0500 (EST)
From: Rich Fulton <[e-mail]>
To: Alok <[e-mail]>
Subject: Re: [Idr] BGP as an IGP
In-Reply-To: <011c01c51d99$9ac746c0$[e-mail]>
Message-ID: <[e-mail]>
References: <011c01c51d99$9ac746c0$[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
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]

> Are there any good references to using BGP as an IGP in the following
> scenarios:
> a. using RRs. (topology being a ring)
> b. using Full mesh. (topology being full mesh)
> c. using confederations (topology being triangles joined together)

http://www.amazon.com/exec/obidos/ASIN/1562056522/002-8674552-3904820

> In terms of scalability, what is the most recommended?

that is a loaded question.  typically RRs will 
win the scalability debate.  but it really 
depends on your topology.



   /rf

_______________________________________________
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 IAA26688 for <[e-mail]>; Mon, 28 Feb 2005 08:31:06 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5kyK-0001Gn-V0; Mon, 28 Feb 2005 08:30:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5kyJ-0001Gf-Hv for [e-mail]; Mon, 28 Feb 2005 08:30:03 -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 IAA18891 for <[e-mail]>; Mon, 28 Feb 2005 08:30:02 -0500 (EST)
Received: from smtp-out.hotpop.com ([38.113.3.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5kz1-000744-RU for [e-mail]; Mon, 28 Feb 2005 08:30:50 -0500
Received: from hotpop.com (kubrick.hotpop.com [38.113.3.103]) by smtp-out.hotpop.com (Postfix) with SMTP id BD63AF2F088 for <[e-mail]>; Mon, 28 Feb 2005 13:29:45 +0000 (UTC)
Received: from ALOKLXP (unknown [202.144.106.188]) by smtp-3.hotpop.com (Postfix) with ESMTP id C0E1F14791CD for <[e-mail]>; Mon, 28 Feb 2005 13:29:43 +0000 (UTC)
Message-ID: <011c01c51d99$9ac746c0$[e-mail]>
From: "Alok" <[e-mail]>
To: <[e-mail]>
Date: Mon, 28 Feb 2005 18:59:58 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-HotPOP: ----------------------------------------------- Sent By HotPOP.com FREE Email Get your FREE POP email at www.HotPOP.com -----------------------------------------------
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Subject: [Idr] BGP as an IGP
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]

Hi,


Are there any good references to using BGP as an IGP in the following
scenarios:

a. using RRs. (topology being a ring)
b. using Full mesh. (topology being full mesh)
c. using confederations (topology being triangles joined together)

In terms of scalability, what is the most recommended?

-thanks
Alok



_______________________________________________
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 VAA22897 for <[e-mail]>; Sun, 27 Feb 2005 21:50:53 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5axU-0007ME-Dy; Sun, 27 Feb 2005 21:48:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5axS-0007I9-73 for [e-mail]; Sun, 27 Feb 2005 21:48: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 VAA29270 for <[e-mail]>; Sun, 27 Feb 2005 21:48:28 -0500 (EST)
Received: from web86910.mail.ukl.yahoo.com ([217.12.13.62]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5ay7-00035h-17 for [e-mail]; Sun, 27 Feb 2005 21:49:11 -0500
Received: (qmail 718 invoked by uid 60001); 28 Feb 2005 02:48:20 -0000
Message-ID: <[e-mail]>
Received: from [67.169.99.99] by web86910.mail.ukl.yahoo.com via HTTP; Mon, 28 Feb 2005 02:48:20 GMT
Date: Mon, 28 Feb 2005 02:48:20 +0000 (GMT)
From: Acharya <[e-mail]>
Subject: Re: [Idr] BGP nexthop calculation question
To: Jeffrey Haas <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Content-Transfer-Encoding: 8bit
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]

Jeff,

Infact, since the latest versions of BSD, and Linux
since the start, allow IF-address configuration as in:
eth1 = 10.10.10.1/24 and eth2 = 10.10.10.2/24, its
next to imppossible to actually detect, on the RUT,
whether two Nbrs have direct connectivity or not.
Infact, this change in behaviour, in BSD, is to allow
for IPv6-LinkLocal addresses, which by default reside
in the same subnet.

So, Id like to suggest that, in the latest BGP-draft,
we add a sentence saying:

"The default behaviour for directly connected subnets
is that the NextHop goes unchanged (whether
advertisement is to an EBGP or IBGP neighbor), but it
is the administrators responsibility to ensure that
the router specified as the Nexthop is infact directly
reachable to the advertised neighbor. If the Nexthop
is not directly reachable to the advertised neighbor,
it MUST be configurable to set the Nexthop to the
address of the interface that is used to reach the
neighbor".

The above statement makes the provision of a command
akin to "nexthop-self" mandatory.

This would become a requirement if both TR2 and TR1,
in Cleary's example, are IPv6-Link-local neighbors
which donot have direct reachability to each other.
Then its impossible for the RUT to check whether "the
router" is reachable for the neighbor!

I feel that the NextHop related statements in MP-BGP
RFC 2858 (which just reflected the statements in the
then BGP-draft) are far more messed up than the ones
we have here in draft-26 and need to be re-worked as
well.

Acharya.

 --- Jeffrey Haas <[e-mail]> wrote: 
> Mike,
> 
> On Fri, Feb 25, 2005 at 08:10:54AM -0500,
> [e-mail] wrote:
> > Should RUT advertise this route to the iBGP peer
> with the nexthop set 
> > to itself
> > also?
> 
> In general:
> 
> If the nexthop on a router is being sent to a BGP
> peer (internal or
> external) and it shares a logical subnet with that
> nexthop, it MAY
> send the BGP update with the original nexthop.
> 
> If the nexthop on a router is being sent to an eBGP
> peer and
> the nexthop is not on the same logical subnet, it
> will in almost
> every case announce the route as a first party
> nexthop and thus
> use the IP address of the local end of the peering
> session with the eBGP
> peer as the nexthop.  (An exception is multihop eBGP
> peering and the
> behavior is somewhat out of spec.)
> 
> If the nexthop on a router is being sent to an iBGP
> peer, then the
> nexthop is typically sent unaltered.  This behavior
> may be modified
> via a "next-hop-self" feature.  
> 
> Confederation behavior is slightly different.  It is
> permissable
> for nexthops to be sent unaltered (like iBGP) in a
> confederation.
> This means if the implementation chooses to enforce
> nexthop on subnet
> on a confederation eBGP peering session, it is
> conformant.  However,
> this is atypical behavior.
> 
> 
> -- 
> Jeff Haas 
> NextHop Technologies
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
>  

Send instant messages to your online friends http://uk.messenger.yahoo.com 

_______________________________________________
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 UAA15670 for <[e-mail]>; Sun, 27 Feb 2005 20:40:05 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5ZsH-0000zG-2V; Sun, 27 Feb 2005 20:39:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5ZsE-0000w5-Rw for [e-mail]; Sun, 27 Feb 2005 20:39:03 -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 UAA23294 for <[e-mail]>; Sun, 27 Feb 2005 20:38:56 -0500 (EST)
Received: from web86903.mail.ukl.yahoo.com ([217.12.13.55]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5Zsh-0001nq-1c for [e-mail]; Sun, 27 Feb 2005 20:39:38 -0500
Received: (qmail 37428 invoked by uid 60001); 28 Feb 2005 01:38:37 -0000
Message-ID: <[e-mail]>
Received: from [67.169.99.99] by web86903.mail.ukl.yahoo.com via HTTP; Mon, 28 Feb 2005 01:38:37 GMT
Date: Mon, 28 Feb 2005 01:38:37 +0000 (GMT)
From: Acharya <[e-mail]>
Subject: Re: [Idr] BGP nexthop calculation question
To: Mike Cleary <[e-mail]>, Nader Salehi <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Content-Transfer-Encoding: 8bit
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]

"the router" is TR3 in your topology. And your right
in saying that the NH should be 10.10.10.X in
advertisements to both TR1 and TR2. If NHSelf is
configured on RUT for Nbr TR2&/TR1, the NH will be
changed to RUT's IF-addresses accordingly.

Acharya

 --- Mike Cleary <[e-mail]> wrote: 
> Nader,
> What is the case when this route is being advertised
> to an IBGP peer? 
>  This quote from section 5.1.3 is a little
> confusing:
> 
>       When announcing a locally 
>       originated route to an internal peer, the BGP
> speaker SHOULD use
>       as the NEXT_HOP the interface address of the
> router through which
>       the announced network is reachable for the
> speaker; if the route
>       is directly connected to the speaker, or the
> interface address of
>       the router through which the announced network
> is reachable for
>       the speaker is the internal peer's address,
> then the BGP speaker
>       SHOULD use for the NEXT_HOP attribute its own
> IP address (the
>       address of the interface that is used to reach
> the peer).
> 
> Take my example where RUT is originating a static
> route with the nexthop 
> set to TR3 (10.10.10.X), is "the router" from the
> first part of the 
> sentance refering to TR3 or is it refering to RUT? 
> If this is refering 
> to TR3 than the nexthop should be 10.10.10.X right?
> Thanks,
> ~Mike
> 
> Nader Salehi wrote:
> 
> >Mike,
> >
> >Assuming that TR1, RUT, and TR3 are not on a
> multi-access media
> >(Ethernet, Frame Relay), this is a correct
> behavior.  RUT advertises
> >2.2.2/24 to an eBGP peer, so the next hop will be
> the IP address of
> >the RUT.
> >
> >As for your other question, if you source a route
> into BGP --via
> >either the 'network' or the 'redistribute'
> commands-- the route is
> >considered local and is advertised to peers as
> such.  The only
> >difference between 'network' and 'redistribute'
> commands is in the
> >ORIGIN attribute.  The former sets the origin to
> IGP whereas the
> >latter sets the origin to Unknown.
> >
> >Hope this helps.
> >
> >Nader
> >
> >
> >Mike Cleary writes:
> >
> >>Hello,
> >>I have a question with regards to the nexthop of
> BGP updates.  See the 
> >>attached diagram.  As noted in the Diagram TR1 is
> connected to RUT via 
> >>external BGP on network 10.10.10.0/24, TR2 is
> connected to RUT via 
> >>Internal BGP.  RUT has a static route to network
> 2.2.2.0/24 with the 
> >>nexthop set to TR3's network 0 ip address
> (10.10.10.36).  RUT is 
> >>configured to redistribute static routes to BGP. 
> RUT uses itself on 
> >>network 0 (10.10.10.Y) as the nexthop when
> advertising this route to TR1 
> >>and TR2 even though nexthop self is not set to
> enabled.  I was 
> >>wondering, is this behavior is correct?  I looked
> at section 5.1.3 of 
> >>draft-ietf-bgp4-26 for this information and found
> the wording to be a 
> >>little confusing.  Are static routes considered
> locally originated?
> >>Thanks,
> >>~Mike
> >>
> >>-- 
> >>*********************************************
> >>Michael Cleary     Email: [e-mail]
> >>IPv4 Consortium      UNH InterOperability Lab
> >>121 Technology Dr., Suite 2, Durham, NH 03824
> >>Phone: [phone]    http://www.iol.unh.edu
> >>*********************************************
> >>
> >>
> >>_______________________________________________
> >>Idr mailing list
> >>[e-mail]
> >>https://www1.ietf.org/mailman/listinfo/idr
> >>
> >
> 
> 
> -- 
> *********************************************
> Michael Cleary     Email: [e-mail]
> IPv4 Consortium      UNH InterOperability Lab
> 121 Technology Dr., Suite 2, Durham, NH 03824
> Phone: [phone]    http://www.iol.unh.edu
> *********************************************
> 
> 
> 
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
>  

Send instant messages to your online friends http://uk.messenger.yahoo.com 

_______________________________________________
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 IAA29111 for <[e-mail]>; Sun, 27 Feb 2005 08:11: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 1D5OBT-0000QL-Sz; Sun, 27 Feb 2005 08:10:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvdy8-0004y1-AO; Mon, 31 Jan 2005 11:00:06 -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 LAA15714; Mon, 31 Jan 2005 11:00:02 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CveG6-0006oz-Eu; Mon, 31 Jan 2005 11:18:38 -0500
Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CvdtM-0003Qg-Ii; Mon, 31 Jan 2005 10:55:08 -0500
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 31 Jan 2005 10:55:08 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
X-Mailman-Approved-At: Sun, 27 Feb 2005 08:10:04 -0500
Cc: idr chair <[e-mail]>, idr mailing list <[e-mail]>, idr chair <[e-mail]>, Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>
Subject: [Idr] Protocol Action: 'A Border Gateway Protocol 4 (BGP-4)' to  Draft Standard 
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]

The IESG has approved the following documents:

- 'Definitions of Managed Objects for the Fourth Version of Border Gateway 
   Protocol (BGP-4) '
   <draft-ietf-idr-bgp4-mib-15.txt> as a Proposed Standard
- 'BGP Security Vulnerabilities Analysis '
   <draft-ietf-idr-bgp-vuln-01.txt> as an Informational RFC
- 'BGP-4 Protocol Analysis '
   <draft-ietf-idr-bgp-analysis-07.txt> as an Informational RFC
- 'Experience with the BGP-4 Protocol '
   <draft-ietf-idr-bgp4-experience-protocol-05.txt> as an Informational RFC
- 'BGP MIB V1 implementation survey '
   <draft-ietf-idr-bgp-mibagent-survey-02.txt> as an Informational RFC
- 'Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 
   2385) and the BGP-4 Specification '
   <draft-iesg-tcpmd5app-01.txt> as an Informational RFC
- 'BGP 4 Implementation Report '
   <draft-ietf-idr-bgp-implementation-02.txt> as an Informational RFC
- 'A Border Gateway Protocol 4 (BGP-4) '
   <draft-ietf-idr-bgp4-26.txt> as a Draft Standard

These documents are products of the Inter-Domain Routing Working Group. 

The IESG contact persons are Alex Zinin and Bill Fenner.

Technical Summary
 
 The documents included in this package provide the technical specification,
 the MIB module description and the supporting documentation for the revision
 of the BGPv4 protocol. BGPv4 is a path-vector routing protocol currently used
 in the Internet for classless IPv4 inter-domain routing. The protocol allows 
 a certain degree of policy routing among the domains.
 
Working Group Summary
 
 The WG has been working on the revised version of the protocol specification
 for the last few years. Discussions on specific issues and related consensus
 assessment have been documented. Documents in the package have passed the WG
 LC, and are now ready for the IESG review.
 
Protocol Quality
 
 BGPv4 is widely implemented and deployed. The implementations are tested for
 interoperability between different vendors on a regular basis. The
 specification has been reviewed thoroughly my numerous WG participants,
 members of the Routing Area directorate, and Area Directors.

RFC Editor Note

draft-ietf-idr-bgp-analysis-06.txt:

Abstract:

OLD:
   The purpose of this report is to document how the requirements for
   advancing a routing protocol from Draft Standard to full Standard
   have been satisfied by Border Gateway Protocol version 4 (BGP-4).

NEW:
   The purpose of this report is to document how the requirements for
   publication of a routing protocol as an Internet Draft Standard
   have been satisfied by Border Gateway Protocol version 4 (BGP-4).

Section 1 "Introduction"

OLD:
    BGP-4 is an inter-autonomous system routing protocol designed for
    TCP/IP internets. Version 1 of the BGP-4 protocol was published in
    [RFC1105]. Since then BGP versions 2, 3, and 4 have been developed.
    Version 2 was documented in [RFC1163]. Version 3 is documented in

NEW:
    BGP-4 is an inter-autonomous system routing protocol designed for
    TCP/IP internets. Version 1 of the BGP protocol was published in
    [RFC1105]. Since then BGP versions 2, 3, and 4 have been developed.
    Version 2 was documented in [RFC1163]. Version 3 is documented in

draft-ietf-idr-bgp4-experience-protocol:

Abstract:

OLD:
   The purpose of this memo is to document how the requirements for
   advancing a routing protocol from Draft Standard to full Standard
   have been satisfied by Border Gateway Protocol version 4 (BGP-4).

NEW:
   The purpose of this memo is to document how the requirements for
   publication of a routing protocol as an Internet Draft Standard
   have been satisfied by Border Gateway Protocol version 4 (BGP-4).

Change all instances of "Potatoe" to "potato"

draft-iesg-tcpmd5app-01.txt:

Section 6 "Security Considerations"

OLD:
    The IESG believes that the variance described here will not affect
    the security of the Internet.

NEW:
    The IESG believes that the variance described here will not adversely
    affect the security of the Internet.

draft-ietf-idr-bgp4-26.txt:

Move the following reference--

   [RFC2474] Nichols, K., et al.,"Definition of the Differentiated
   Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474,
   December 1998

--to the non-normative part.


_______________________________________________
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 KAA14897 for <[e-mail]>; Fri, 25 Feb 2005 10:44:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4hcO-0002nA-Kx; Fri, 25 Feb 2005 10:43:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4hcM-0002mW-Bt for [e-mail]; Fri, 25 Feb 2005 10:43:02 -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 KAA00635 for <[e-mail]>; Fri, 25 Feb 2005 10:42:59 -0500 (EST)
Received: from io.iol.unh.edu ([132.177.123.82]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hcS-0004PC-2x for [e-mail]; Fri, 25 Feb 2005 10:43:11 -0500
Received: from iol.unh.edu (scrappy.iol.unh.edu [132.177.118.198]) by io.iol.unh.edu (8.13.3/8.13.3) with ESMTP id j1PFgkc2002631; Fri, 25 Feb 2005 10:42:46 -0500
Message-ID: <[e-mail]>
Date: Fri, 25 Feb 2005 10:46:55 -0500
From: Mike Cleary <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux alpha; en-US; rv:0.9.9) Gecko/20020503
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jeffrey Haas <[e-mail]>
Subject: Re: [Idr] BGP nexthop calculation question
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-UNH-IOL-MailScanner-Information: Please contact [e-mail] for more information
X-UNH-IOL-MailScanner: Found to be clean
X-UNH-IOL-MailScanner-From: [e-mail]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
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,
So if the nexthop self feature is not enabled than it should send the 
original nexthop to an iBGP peer right?
~Mike

Jeffrey Haas wrote:

>Mike,
>
>On Fri, Feb 25, 2005 at 08:10:54AM -0500, [e-mail] wrote:
>
>>Should RUT advertise this route to the iBGP peer with the nexthop set 
>>to itself
>>also?
>>
>
>In general:
>
>If the nexthop on a router is being sent to a BGP peer (internal or
>external) and it shares a logical subnet with that nexthop, it MAY
>send the BGP update with the original nexthop.
>
>If the nexthop on a router is being sent to an eBGP peer and
>the nexthop is not on the same logical subnet, it will in almost
>every case announce the route as a first party nexthop and thus
>use the IP address of the local end of the peering session with the eBGP
>peer as the nexthop.  (An exception is multihop eBGP peering and the
>behavior is somewhat out of spec.)
>
>If the nexthop on a router is being sent to an iBGP peer, then the
>nexthop is typically sent unaltered.  This behavior may be modified
>via a "next-hop-self" feature.  
>
>Confederation behavior is slightly different.  It is permissable
>for nexthops to be sent unaltered (like iBGP) in a confederation.
>This means if the implementation chooses to enforce nexthop on subnet
>on a confederation eBGP peering session, it is conformant.  However,
>this is atypical behavior.
>
>


-- 
*********************************************
Michael Cleary     Email: [e-mail]
IPv4 Consortium      UNH InterOperability Lab
121 Technology Dr., Suite 2, Durham, NH 03824
Phone: [phone]    http://www.iol.unh.edu
*********************************************




_______________________________________________
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 KAA11130 for <[e-mail]>; Fri, 25 Feb 2005 10:09:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4h3w-0001tB-Qq; Fri, 25 Feb 2005 10:07:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4h3w-0001rJ-3O for [e-mail]; Fri, 25 Feb 2005 10:07:28 -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 KAA24599 for <[e-mail]>; Fri, 25 Feb 2005 10:07:25 -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 1D4h41-00032L-L7 for [e-mail]; Fri, 25 Feb 2005 10:07:37 -0500
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 87A2A2D4FEE; Fri, 25 Feb 2005 10:07:10 -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 10949-01-72; Fri, 25 Feb 2005 10:07:05 -0500 (EST)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 313042D4E45; Fri, 25 Feb 2005 09:40:37 -0500 (EST)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j1PEebA03799; Fri, 25 Feb 2005 09:40:37 -0500 (EST)
Date: Fri, 25 Feb 2005 09:40:37 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Re: [Idr] BGP nexthop calculation question
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: 97adf591118a232206bdb5a27b217034
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]

Mike,

On Fri, Feb 25, 2005 at 08:10:54AM -0500, [e-mail] wrote:
> Should RUT advertise this route to the iBGP peer with the nexthop set 
> to itself
> also?

In general:

If the nexthop on a router is being sent to a BGP peer (internal or
external) and it shares a logical subnet with that nexthop, it MAY
send the BGP update with the original nexthop.

If the nexthop on a router is being sent to an eBGP peer and
the nexthop is not on the same logical subnet, it will in almost
every case announce the route as a first party nexthop and thus
use the IP address of the local end of the peering session with the eBGP
peer as the nexthop.  (An exception is multihop eBGP peering and the
behavior is somewhat out of spec.)

If the nexthop on a router is being sent to an iBGP peer, then the
nexthop is typically sent unaltered.  This behavior may be modified
via a "next-hop-self" feature.  

Confederation behavior is slightly different.  It is permissable
for nexthops to be sent unaltered (like iBGP) in a confederation.
This means if the implementation chooses to enforce nexthop on subnet
on a confederation eBGP peering session, it is conformant.  However,
this is atypical behavior.


-- 
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 KAA10163 for <[e-mail]>; Fri, 25 Feb 2005 10:00:11 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4guo-0001as-MY; Fri, 25 Feb 2005 09:58:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gun-0001af-Di for [e-mail]; Fri, 25 Feb 2005 09:58: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 JAA22959 for <[e-mail]>; Fri, 25 Feb 2005 09:57:59 -0500 (EST)
Received: from io.iol.unh.edu ([132.177.123.82]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4guw-0002kE-2x for [e-mail]; Fri, 25 Feb 2005 09:58:10 -0500
Received: from iol.unh.edu (scrappy.iol.unh.edu [132.177.118.198]) by io.iol.unh.edu (8.13.3/8.13.3) with ESMTP id j1PEvjrq029800; Fri, 25 Feb 2005 09:57:46 -0500
Message-ID: <[e-mail]>
Date: Fri, 25 Feb 2005 10:01:54 -0500
From: Mike Cleary <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux alpha; en-US; rv:0.9.9) Gecko/20020503
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Nader Salehi <[e-mail]>
Subject: Re: [Idr] BGP nexthop calculation question
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-UNH-IOL-MailScanner-Information: Please contact [e-mail] for more information
X-UNH-IOL-MailScanner: Found to be clean
X-UNH-IOL-MailScanner-From: [e-mail]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
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]

Nader,
What is the case when this route is being advertised to an IBGP peer? 
 This quote from section 5.1.3 is a little confusing:

      When announcing a locally 
      originated route to an internal peer, the BGP speaker SHOULD use
      as the NEXT_HOP the interface address of the router through which
      the announced network is reachable for the speaker; if the route
      is directly connected to the speaker, or the interface address of
      the router through which the announced network is reachable for
      the speaker is the internal peer's address, then the BGP speaker
      SHOULD use for the NEXT_HOP attribute its own IP address (the
      address of the interface that is used to reach the peer).

Take my example where RUT is originating a static route with the nexthop 
set to TR3 (10.10.10.X), is "the router" from the first part of the 
sentance refering to TR3 or is it refering to RUT?  If this is refering 
to TR3 than the nexthop should be 10.10.10.X right?
Thanks,
~Mike

Nader Salehi wrote:

>Mike,
>
>Assuming that TR1, RUT, and TR3 are not on a multi-access media
>(Ethernet, Frame Relay), this is a correct behavior.  RUT advertises
>2.2.2/24 to an eBGP peer, so the next hop will be the IP address of
>the RUT.
>
>As for your other question, if you source a route into BGP --via
>either the 'network' or the 'redistribute' commands-- the route is
>considered local and is advertised to peers as such.  The only
>difference between 'network' and 'redistribute' commands is in the
>ORIGIN attribute.  The former sets the origin to IGP whereas the
>latter sets the origin to Unknown.
>
>Hope this helps.
>
>Nader
>
>
>Mike Cleary writes:
>
>>Hello,
>>I have a question with regards to the nexthop of BGP updates.  See the 
>>attached diagram.  As noted in the Diagram TR1 is connected to RUT via 
>>external BGP on network 10.10.10.0/24, TR2 is connected to RUT via 
>>Internal BGP.  RUT has a static route to network 2.2.2.0/24 with the 
>>nexthop set to TR3's network 0 ip address (10.10.10.36).  RUT is 
>>configured to redistribute static routes to BGP.  RUT uses itself on 
>>network 0 (10.10.10.Y) as the nexthop when advertising this route to TR1 
>>and TR2 even though nexthop self is not set to enabled.  I was 
>>wondering, is this behavior is correct?  I looked at section 5.1.3 of 
>>draft-ietf-bgp4-26 for this information and found the wording to be a 
>>little confusing.  Are static routes considered locally originated?
>>Thanks,
>>~Mike
>>
>>-- 
>>*********************************************
>>Michael Cleary     Email: [e-mail]
>>IPv4 Consortium      UNH InterOperability Lab
>>121 Technology Dr., Suite 2, Durham, NH 03824
>>Phone: [phone]    http://www.iol.unh.edu
>>*********************************************
>>
>>
>>_______________________________________________
>>Idr mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/idr
>>
>


-- 
*********************************************
Michael Cleary     Email: [e-mail]
IPv4 Consortium      UNH InterOperability Lab
121 Technology Dr., Suite 2, Durham, NH 03824
Phone: [phone]    http://www.iol.unh.edu
*********************************************




_______________________________________________
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 IAA28946 for <[e-mail]>; Fri, 25 Feb 2005 08:11:53 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4fFO-0004wp-Lf; Fri, 25 Feb 2005 08:11:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4fFN-0004wi-AY for [e-mail]; Fri, 25 Feb 2005 08:11: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 IAA11790 for <[e-mail]>; Fri, 25 Feb 2005 08:11:07 -0500 (EST)
From: [e-mail]
Received: from io.iol.unh.edu ([132.177.123.82]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4fFU-0000E8-Ae for [e-mail]; Fri, 25 Feb 2005 08:11:17 -0500
Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by io.iol.unh.edu (8.13.3/8.13.3) with ESMTP id j1PDAtMV018480; Fri, 25 Feb 2005 08:10:55 -0500
Received: (from apache@localhost) by io.iol.unh.edu (8.13.3/8.13.3/Submit) id j1PDAsNp018479; Fri, 25 Feb 2005 08:10:54 -0500
X-Authentication-Warning: io.iol.unh.edu: apache set sender to [e-mail] using -f
Received: from clustr1-cis367.unh.edu (clustr1-cis367.unh.edu [132.177.82.67]) by webmail.iol.unh.edu (Horde) with HTTP for <[e-mail]>; Fri, 25 Feb 2005 08:10:54 -0500
Message-ID: <[e-mail]>
Date: Fri, 25 Feb 2005 08:10:54 -0500
To: Nader Salehi <[e-mail]>
Subject: Re: [Idr] BGP nexthop calculation question
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.0.2)
X-UNH-IOL-MailScanner-Information: Please contact [e-mail] for more information
X-UNH-IOL-MailScanner: Found to be clean
X-UNH-IOL-MailScanner-From: [e-mail]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
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]

Should RUT advertise this route to the iBGP peer with the nexthop set 
to itself
also?

Quoting Nader Salehi <[e-mail]>:

> Mike,
>
> Assuming that TR1, RUT, and TR3 are not on a multi-access media
> (Ethernet, Frame Relay), this is a correct behavior.  RUT advertises
> 2.2.2/24 to an eBGP peer, so the next hop will be the IP address of
> the RUT.
>
> As for your other question, if you source a route into BGP --via
> either the 'network' or the 'redistribute' commands-- the route is
> considered local and is advertised to peers as such.  The only
> difference between 'network' and 'redistribute' commands is in the
> ORIGIN attribute.  The former sets the origin to IGP whereas the
> latter sets the origin to Unknown.
>
> Hope this helps.
>
> Nader
>
>
> Mike Cleary writes:
>> Hello,
>> I have a question with regards to the nexthop of BGP updates.  See the
>> attached diagram.  As noted in the Diagram TR1 is connected to RUT via
>> external BGP on network 10.10.10.0/24, TR2 is connected to RUT via
>> Internal BGP.  RUT has a static route to network 2.2.2.0/24 with the
>> nexthop set to TR3's network 0 ip address (10.10.10.36).  RUT is
>> configured to redistribute static routes to BGP.  RUT uses itself on
>> network 0 (10.10.10.Y) as the nexthop when advertising this route to TR1
>> and TR2 even though nexthop self is not set to enabled.  I was
>> wondering, is this behavior is correct?  I looked at section 5.1.3 of
>> draft-ietf-bgp4-26 for this information and found the wording to be a
>> little confusing.  Are static routes considered locally originated?
>> Thanks,
>> ~Mike
>>
>> --
>> *********************************************
>> Michael Cleary     Email: [e-mail]
>> IPv4 Consortium      UNH InterOperability Lab
>> 121 Technology Dr., Suite 2, Durham, NH 03824
>> Phone: [phone]    http://www.iol.unh.edu
>> *********************************************
>>
>>
>> _______________________________________________
>> 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 UAA15643 for <[e-mail]>; Thu, 24 Feb 2005 20:10:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4TqO-0008Qt-SC; Thu, 24 Feb 2005 20:00:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4TqN-0008Ql-SW for [e-mail]; Thu, 24 Feb 2005 20:00: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 UAA14285 for <[e-mail]>; Thu, 24 Feb 2005 20:00:32 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4TqO-0001F2-Rj for [e-mail]; Thu, 24 Feb 2005 20:00:38 -0500
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 24 Feb 2005 17:12:09 -0800
Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1P10Fq8029219; Thu, 24 Feb 2005 17:00:20 -0800 (PST)
Received: from localhost.localdomain.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id UAA08830; Thu, 24 Feb 2005 20:00:17 -0500 (EST)
From: Nader Salehi <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 24 Feb 2005 17:00:16 -0800
To: Mike Cleary <[e-mail]>
Subject: Re: [Idr] BGP nexthop calculation question
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 7.14 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-URL: http://www.cisco.com
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
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]

Mike,

Assuming that TR1, RUT, and TR3 are not on a multi-access media
(Ethernet, Frame Relay), this is a correct behavior.  RUT advertises
2.2.2/24 to an eBGP peer, so the next hop will be the IP address of
the RUT.

As for your other question, if you source a route into BGP --via
either the 'network' or the 'redistribute' commands-- the route is
considered local and is advertised to peers as such.  The only
difference between 'network' and 'redistribute' commands is in the
ORIGIN attribute.  The former sets the origin to IGP whereas the
latter sets the origin to Unknown.

Hope this helps.

Nader


Mike Cleary writes:
> Hello,
> I have a question with regards to the nexthop of BGP updates.  See the 
> attached diagram.  As noted in the Diagram TR1 is connected to RUT via 
> external BGP on network 10.10.10.0/24, TR2 is connected to RUT via 
> Internal BGP.  RUT has a static route to network 2.2.2.0/24 with the 
> nexthop set to TR3's network 0 ip address (10.10.10.36).  RUT is 
> configured to redistribute static routes to BGP.  RUT uses itself on 
> network 0 (10.10.10.Y) as the nexthop when advertising this route to TR1 
> and TR2 even though nexthop self is not set to enabled.  I was 
> wondering, is this behavior is correct?  I looked at section 5.1.3 of 
> draft-ietf-bgp4-26 for this information and found the wording to be a 
> little confusing.  Are static routes considered locally originated?
> Thanks,
> ~Mike
> 
> -- 
> *********************************************
> Michael Cleary     Email: [e-mail]
> IPv4 Consortium      UNH InterOperability Lab
> 121 Technology Dr., Suite 2, Durham, NH 03824
> Phone: [phone]    http://www.iol.unh.edu
> *********************************************
> 
> 
> _______________________________________________
> 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 PAA14849 for <[e-mail]>; Thu, 24 Feb 2005 15:17:16 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4POy-0007yM-M3; Thu, 24 Feb 2005 15:16:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4POx-0007y0-9I for [e-mail]; Thu, 24 Feb 2005 15:15: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 PAA11556 for <[e-mail]>; Thu, 24 Feb 2005 15:15:57 -0500 (EST)
Received: from io.iol.unh.edu ([132.177.123.82]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Plt-0001WM-MV for [e-mail]; Thu, 24 Feb 2005 15:39:43 -0500
Received: from iol.unh.edu (scrappy.iol.unh.edu [132.177.118.198]) by io.iol.unh.edu (8.13.3/8.13.3) with ESMTP id j1OKFgHX021512 for <[e-mail]>; Thu, 24 Feb 2005 15:15:43 -0500
Message-ID: <[e-mail]>
Date: Thu, 24 Feb 2005 15:19:51 -0500
From: Mike Cleary <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux alpha; en-US; rv:0.9.9) Gecko/20020503
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Content-Type: multipart/mixed; boundary="------------010406010708020803050906"
X-UNH-IOL-MailScanner-Information: Please contact [e-mail] for more information
X-UNH-IOL-MailScanner: Found to be clean
X-UNH-IOL-MailScanner-From: [e-mail]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b6435b1bfa5977f2eb96dc7e52434b6d
Subject: [Idr] BGP nexthop calculation question
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]

This is a multi-part message in MIME format.
--------------010406010708020803050906
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello,
I have a question with regards to the nexthop of BGP updates.  See the 
attached diagram.  As noted in the Diagram TR1 is connected to RUT via 
external BGP on network 10.10.10.0/24, TR2 is connected to RUT via 
Internal BGP.  RUT has a static route to network 2.2.2.0/24 with the 
nexthop set to TR3's network 0 ip address (10.10.10.36).  RUT is 
configured to redistribute static routes to BGP.  RUT uses itself on 
network 0 (10.10.10.Y) as the nexthop when advertising this route to TR1 
and TR2 even though nexthop self is not set to enabled.  I was 
wondering, is this behavior is correct?  I looked at section 5.1.3 of 
draft-ietf-bgp4-26 for this information and found the wording to be a 
little confusing.  Are static routes considered locally originated?
Thanks,
~Mike

-- 
*********************************************
Michael Cleary     Email: [e-mail]
IPv4 Consortium      UNH InterOperability Lab
121 Technology Dr., Suite 2, Durham, NH 03824
Phone: [phone]    http://www.iol.unh.edu
*********************************************



--------------010406010708020803050906
Content-Type: image/jpeg;
 name="diagram.jpg"
Content-Disposition: inline;
 filename="diagram.jpg"
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAAR
CAD9AWkDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk
NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk
5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+/iiiigAooooAKKKKACiiigAooooAKKKK
APhL/gl5rOr+Iv8Agm/+wlrviDVdS1zXNX/ZM+Amo6trOsX11qeq6pqF38NPDk11fajqN7LP
d3t5cys0txc3M0s00jM8jsxJP3bXwB/wSk/5RlfsA/8AZoH7Pn/qsPDVff8AQAUUUUAFFFFA
BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAFFFFABRWNb+IvD93puoazaa7o1zpGk3Ot2eq6rb6pZTabpl34Zvr3TPEdrqF9HO1rZ3Ph
/UtO1DT9bguZY5dKvrC9tL9bee1njSl4c8a+DfGPh6Pxb4R8W+GfFPhSVbxovE3hzXtK1zw9
KunSywag0etaZd3WmutjPbzw3hW5ItZYZY5yjxuFAOmopFZXVXRldGUMrKQysrDKsrDIKkEE
EEgg5HFLQAUUUUAFFFFABRRRQB8Af8EpP+UZX7AP/ZoH7Pn/AKrDw1X3/XwB/wAEpP8AlGV+
wD/2aB+z5/6rDw1X3/QAUUUUAFFFFABRRRQAUUVm3utaPpt5o+najq2m2GoeIby407QLC9v7
W1vNc1C002+1m6sdHtZ5Y59TvLbR9M1LVri1sknnh03T76+kRbW0nljANKiuXvPHHgvT/FWk
+BL/AMX+F7Hxvr1lcanofg288QaTbeKtZ020S7ku9Q0nw9Ndpq+o2VrHYX0lxd2dnNBClndt
JIq28xS9aeJPDuoazq/hyw1/Rb3xDoCWUmu6DaarY3Os6JHqUC3WnSavpcM732mpf2zpcWT3
kEK3UDLNAZI2DEA2qKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igArwT9qH4sa78EP2f8A4p/Ezwj4YvvG3jrQfDUll8N/BenWlxe3PjD4o+KL2z8I/C/wq0Vq
ryxWniL4ga74b0fUL4jydMsLy51K5K29pKw97ooA/mh0f4I/ED9mf4R/Hf8AY3/ad8D+JbL4
YfFfwV8A/wBpnw/8Rv2al1n9rOOP4sfCP4ifAPwL+1F8Sfij4Y+IPwi+Hs3ijwv4h+INt8IP
2jPjd8HF8A+NE+IPw98V/tHXtlJ4kkudf0vStq68AeH/AIn/ALIf/BWTw94a0T4e+LNCP7Nh
8V6R8e/2MPCXxy/Zf+Gvx/8AiRoHwP8AjTp0Pw71H4TWXxM8WaHqfxA+GEnhzwSPiZffDjxf
rHhD4u6D41+Hvgbx/ozDwfqHgPTP6RKKAOR+H8E1t4D8E21zDLb3Fv4R8NwXFvPG8U0E0WjW
UcsM0UgWSKWJ1ZJI3VXR1KsAQRXXUUUAFFFFABRRRQAUUUUAfAH/AASk/wCUZX7AP/ZoH7Pn
/qsPDVff9fAH/BKT/lGV+wD/ANmgfs+f+qw8NV9/0AFFFFABRRRQAUUUUAFfhF+3D4N/ab+P
X7R/jX4r/AL4W+HPGP8Aw7k0HwFqXwnl8Y/EDxj8PtV139oK/wBY+HX7SHxq0P4c+G9C+Fnj
LTviqfH/AOz34f8Aht+zvFfar4u8B2Ghn4wfFnwxp2vW+oXmvXekfu7RQB/Mn8cdb+E3iP4u
fFH4zfD/AMIab8QfGXxp+Iv7M3xt0H9ln9pP9lrx5pn7QHxs1Gz8EfA+8+F/jf8AYf8A2t/h
j4x0nxZ8N/C50Pwf4auGbxXpHxD8PfBT4s6L490v4m2/wj0GXWdL0/6X/Y68R/sufFP9t2/1
z4H+H9J+DOm/CCX9pPw74Z0t/C/j0fG79qbxp8S/G+neIfjP8Z/i7488RaNJI3wth8T6HqGr
/DXw/wCL/Gnirxl8SdZ1i3+JOqW3gPS/C3gzQ/En7q0UAFFFFABRRRQAUUUUAFFFFABRRRQA
UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB8Af8EpP+
UZX7AP8A2aB+z5/6rDw1X3/XwB/wSk/5RlfsA/8AZoH7Pn/qsPDVff8AQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAfAH/BKT/lGV+wD/2aB+z5/wCqw8NV9/18Af8ABKT/
AJRlfsA/9mgfs+f+qw8NV9/0AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHw
B/wSk/5RlfsA/wDZoH7Pn/qsPDVff9fAH/BKT/lGV+wD/wBmgfs+f+qw8NV9/wBABRRRQAUU
UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA
BRRRQB8Gah/wVS/4Jg6Tf32lar/wUe/YM0zVNMvLnT9S03UP2v8A9nuyv9Pv7KZ7a8sb6zuf
iHFcWl5aXEUkFzbTxxzQTRvFKiOjKKf/AA9i/wCCWX/SSz9gD/xMj9nX/wCeNX4pfsH/APJn
H7OP/ZK/DX/pMa+ptQ1TTNJhW51XUbHTLd5VgSfULu3soXmZHkWFZbmSNGlZI5HWMMXKRuwG
EYgA/Qf/AIexf8Esv+kln7AH/iZH7Ov/AM8aj/h7F/wSy/6SWfsAf+Jkfs6//PGr8518V+Fn
t5LxPEugNaQyxQTXS6xpzW8U0yyNDDJOLkxRyyrFK0UbMHkWOQoCEYjWs72z1G2jvNPu7W+s
5t/k3VncRXVtL5cjRSeXPA7xPslR432sdsiMjYZSAAfoF/w9i/4JZf8ASSz9gD/xMj9nX/54
1H/D2L/gll/0ks/YA/8AEyP2df8A541fn7Z3lpqNpa6hp91bX1hfW0F5ZXtnPFc2l5aXMSz2
11a3MDPDcW1xC6TQTwu8UsTrJGzIwJs0Aful4M8a+DfiP4S8N+Pvh54t8M+PPAnjLRdO8SeE
PGvgzXtK8UeEvFXh3V7aO90nXvDfiPQ7u+0fXNF1Szmiu9O1TTLy6sb22ljntp5YnVz01fnp
/wAEmv8AlGn+xF/2bp8OP/TLDX6F0AFFFFABRRRQB8Af8EpP+UZX7AP/AGaB+z5/6rDw1X3/
AF8Af8EpP+UZX7AP/ZoH7Pn/AKrDw1X3/QAUUUUAFFFFABXg/wAcv2pv2Yv2YrXw5fftKftG
/Af9nqy8YXGpWnhK8+OXxe+H3wmtfFN1o0dnNrFt4cuPHviHQItbuNKi1HT5dSh0x7qSxjv7
N7pYluoC/vFfiR/wUk/5Pi/YN/7N0/b8/wDU5/YMoA+uP+HsX/BLL/pJZ+wB/wCJkfs6/wDz
xqP+HsX/AASy/wCkln7AH/iZH7Ov/wA8avgKWWKCKSeeSOGGGN5ZppXWOKKKNS8kkkjkIkaI
CzuxCqoLMQATWfp+uaLqyztpWsaXqS2oRrptP1C0vFtlkEhjM5tppBCJBFKUMm0OI5CudjYA
P0N/4exf8Esv+kln7AH/AImR+zr/APPGo/4exf8ABLL/AKSWfsAf+Jkfs6//ADxq/PGPXtDm
sJdVi1nSZdLgcxz6lHqNm9hC4KKUlvFmNvG4MsYKvIpBkQYy65q3PivwvZzNb3niTQLWdVid
oLnWNOgmVJ4knhdopblHCzQyRzRMVxJFIkiEoykgH6Mf8PYv+CWX/SSz9gD/AMTI/Z1/+eNX
sHwV/bd/Yv8A2k/FF94H/Z1/a8/Zf+PnjXS9DufE+p+EPgr8ffhT8U/FGneGrO+0/TLvxDfe
H/A3izXdWtNDtdS1fStPudWuLSOwgvtT0+0luFnvbaOX8oopYp4o54JI5oZo0lhmidZIpYpF
DxyRyISjxuhDI6kqykMpIINR/s5/8pO/2cP+zO/23/8A1aX7C1AH9AFFFFABRRRQAUUUUAFF
FFABRRRQAUUUUAFfAT/8FX/+CWkbsj/8FKv2AkdGZHR/2x/2dldHUkMrKfiMCrKQQykAgggj
Nfftfyj/APBPX/kwT9h3/sz/APZo/wDVL+CqAP25/wCHsX/BLL/pJZ+wB/4mR+zr/wDPGo/4
exf8Esv+kln7AH/iZH7Ov/zxq/PfUNV0vSIkn1XUrDTIZJPKjm1C8t7KKSXaz+WklzJEjybF
ZtikttVmxgEjP/4Svwv9l+2/8JJoH2Pz/sv2v+2NO+y/avL877N9o+0+V5/lfvfJ3+Z5fz7d
vNAH6Mf8PYv+CWX/AEks/YA/8TI/Z1/+eNR/w9i/4JZf9JLP2AP/ABMj9nX/AOeNX54XGv6F
aaNceIrrWtJtvD9naz313rtxqVnDo1rZWoc3N5canJMtlBa24jkM9xLOsMIRzI6hWxY0zU9N
1rT7LV9G1Cx1bStStob3TtT0y7t7/T7+zuEElvd2V7ayS211bTxsskM8EskUqMHR2Ug0AfoP
/wAPYv8Agll/0ks/YA/8TI/Z1/8AnjV13/DyL/gnd/0ft+xd/wCJSfA7/wCbqvzA8Q/8gDXP
+wPqf/pFPX+X/QB/oyfsH/8AJnH7OP8A2Svw1/6TGu//AGlNB0DVfgf8W9Q1rSdK1G40L4T/
ABPu9KutTs7a7bSbibwRrMU97ZPdRyCzuTApha7h8udLd5ohKsU0yv8ADX7Gf7WfhLwz+yt8
B/D9z8I/2ptUuNH+HOg2E2o+HP2Xvjb4i0G9kt4WRrjSdc0nwddaZqtjIRut76xuJradCHik
ZTmvpS4/bH8B3cEtrdfA79rq5tp42int7j9kD49TQTROCrxyxSeBWjkjcEhkdWVgSCCKAPjP
xf4e8Jaf/wAEvf2cPEml6X4Vs9f8W+Ff+CYGl3uqXENrDb+IF0b43fAbVNMttVkh2nULazfX
vE17cFRJcG1vtVldmj3lPoH9i/RdJk1X9r3Q/iDaeHNF+KPiX416hqXxj+Aul6bbWvwz8HaT
P4P0Pwp4M8Q+D9Bvpbj/AISnwt8ZPAPh7S/GeufES9sNKHjnxNeeIdN1fw34c1zwzrPh7Te6
l/aw+Fs9jBpc/wCz1+1TNplrJ5ttp0v7GfxxksbeX96PMgtH8AG3ikxPMN8cat++l5/ePmzJ
+138OJZnuZfgJ+1lJcSWLaXJPJ+xz8dnmk0x3Mj6c8reAi7WLOS7WjMbdnJYxknNAHUfsMuk
n7E/7H7RurqP2XfgChZGDAPF8KfCkciEqSA0ciPG69UdWVgGUgfU1fG9p+2H4AsLeK0sfgX+
1xZWkIKw2tp+x98eba3iVmZ2EUMPgRI4wzszkIoBZmY8kmrH/DZ/gv8A6Ir+2B/4iJ8fv/mG
oA/a3/gk1/yjT/Yi/wCzdPhx/wCmWGv0Lr8Fv+CY/wDwTl/YM+J//BPj9j34ieOP2Tfgz4m8
YeNfgL4B8S+JPEHiLwLZSa9rGsavpEV5e6hrD3UaXJ1G4mlZ7sXCrMsxdZFVwQPur/h1X/wT
j/6Mw+AH/hBaX/8AE0Ad/wDt+ftKax+x5+xz8fv2mfD+i+HfEOsfB3wSfFVlpHi3ULrSvDN2
41jS9NkOualZMl1Zabbw38l1c3MLKYkgLMwQMa8G+Bf7fXhPVPCvxD8ffF/9pr9hb4m+A/Bv
iH4UeGdT8V/sb/ErVPipovwuvPij4g1fwxous/HXUU1nxBa/D3wfq+s29ha6b4u1htK8PaZB
ZeJdW8Q6jZaLo99qFhmfGn/gjx+w18SPhH8Rfh38Ovgj8NfgH4t8deFb/wAL6f8AFr4eeA9E
/wCEw8Hxam0Md/d6Ol0Y7aZ7ywW4026gndYp7K8uInOGxXqOu/sjfG/4qeBvFvwo/aI/a61r
4r/Cn4gjRtH8e+EtA+Dvgr4UX3irwBFfm48bfDi78UeEtVl1e08NfFHSFHgvxtJYG31WXwVq
PiHStGv9I1HV4da00Az9L/4KT/AjUfFHi6GTTfiDb/DLR/hT8BviV4L+Kkfw5+JF5p/xUvv2
hPjh8UPgR8OvCHgHw9b+CTqviTUvHfijwN4Z1D4TXXh+XWz8VdD8crrXh+yttD8OXmr33Qyf
8FHP2WYr210Y678SpfE6n4lt4o8IWXwK+NOp+K/hna/B5vDI+JGp/FvRNL8CXt38L9G8MxeN
vBF/LrPjUaNpmp6P418I67ot1qWieI9J1C68N8Zf8ErPB/j7wBcfCvxp8X9e8b/D6H4WfA74
Z6N4a+IXw6+HXjuxSL9lH9oHxd8cv2Xr7xdZ+ItKutJ+Iem+BdM8YX3wn+I3h3xXpd3bfGLw
Xbw6tq154f8AHLzeKH2/hR/wS8+GHwoHia68Pa74Z8NXvjb4MftJfCLxNo/wl+B3wm+B3w5h
/wCGjbv4Lfb/ABD4Y+H3wz0TRrHTrjwho3wP8M6LpzeJNS8Y+JdeiuJ7jxH4wv2tLCGAA8O/
4Jbftp/BXS/+CeX7GvgSW0+Lt14/8Efsrfsj6Zd+BdN+BHxi1LxT4gtfiN8LfFUvgnxP4M0+
z8FSp4s8E+IIvgr8WpYPGWjXFz4cso/AOuSapqNgkmlNqP258B/2yfDH7RHxx8S+BPh5afbv
hzp37Pnw7+Lul+J9T0vxF4Z8WReLNd+N/wC0Z8E/H3gTxL4S8SafpuoaJfeCPEXwJm0u9tby
ztb+111dctJ0uLeOzmX81/2Pf2C9A/aP/wCCeX/BPvxXf+Ok04x/sefsEQaj4I8V+BdG+I/w
o8b6f8DfhT8eYdK0D4ofD7V9R0yx8f8AhbVrz9pq/wDEzeHdSvrax0zxp8Nvh94ki+1vpk9n
N+gX7G/7AXgv9jbVb7UfCnjnWvFMM/w6n+GVhp994Z8I+FdP0zQG/aU/aU/aOtDa6V4M0zRt
AsmsL79o6+8HWmn6Fouh6Fa6N4R024sdJsjfSWVkAfIf7OH/AAVY1b4j+NvhBpHxE139kW/0
b4v+I/j1p+r+F/hL8Y9b1D41/s+eFvgZ4L+K3jXVvHXxl+Ht/pOt2ieGAPhhbeFNcv217wrc
6P4j8feD/sem6xby6hHae4fCL9tH9oLx3P8As4fErxX8Pv2afCnwY/aqsvA2v/D/AOHMn7RE
GnftM+E/h78TdKt9S8C/ELVtJ8YaF4Z8DfEbULk3ugQ+MPhd8Pr06z4auPE89h4S8V/E/U/C
aWfjGb4af8E4dZ8Lt8GvCnxF/aV8T/FH4H/AH4m658Wvhr8HH+F/w98JWh8W6lB8QbXTIvGn
jWyg1XxX4o8P6LB8S/EkraJbXOgxa9cpp9t4gn1Hw8NT8P6rlaR/wTAtoLr4CeEfE3x+1/xp
8Cf2XPHHwp8a/AnwXrvwo+Fcnxf8L2PwR8TaD4x+Fnwx1f8AaIOiy+KdY+Ffg3XvCvhpbPTt
N8OeHPH2vaLpX9j+OviP4wS9vLmYA8a/Yh/4KoeLv2kr/wDZE0/xTqH7Hni3VP2q7PWLnV/A
n7P3xy1PxB8af2eXtPgh4v8AjJZzfFr4T6jpet3Ft4ftbjwFqnw88S+IrnxN4cOkeNvGPgDS
4tIvH1K4Fft5XyD8GP2KPgp8K/2Tvh/+yHr/AIa0H4o/D7wj8KfB3wo8SXHizwzo0UvxG0vw
jZafBHfeKrGyiEE7319p0OpvaPNcRwXAQCaZ4/Ofz7/h1X/wTj/6Mw+AH/hBaX/8TQB9/wBf
iR/wUk/5Pi/YN/7N0/b8/wDU5/YMr64/4dV/8E4/+jMPgB/4QWl//E1+P3/BQD4Qfst/sI/t
j/sV+I/gp+zdP4Ni8ffAT9t7SfFNj+zv8GvEvjHX9afRPGX7FN1oVxruieA9I1bVP7L0galr
KQajc26WdpcaqYGlWW9jVgD6HZlVSzEKqgszMQFVQMkkngADkk8Acmv5/v8AgnlYWiax+wP4
o8fzaR4D0mD9nj4raL8AvEfhDZDD8cvFnirxRIPiL8Oviz4jmmgA1PwVonhzSPGXw3+H0WnX
lv4rk/tzxlp/if7d4C1bwzD+n0v7ZXgaeKSCf4IfteTQzRvFNDL+yF8fJIpYpFKSRyRv4FKP
G6Eq6MCrKSrAgkVnR/tY/C+G1hsov2fP2q4rK3ukvbe0j/Y0+OSWsF7GSyXcNuvgARRXSMSy
XCIsqkkhwaAPEfg7f+GdD/Yq+Onwz1W90Sw8YR/Gb9sv4TyeEbmW0g1OT4jfE79oX4w3nwu8
JppsuySXVfGukeMfBWr+Eo1jaPVNA1vR9ZspG0mSO7Xrv2i/DHg+0/bM/wCCfq/2D4ehm8Tf
ET9pa81fzNO08Ta/fj9nPxRIJ9RaSIy6pcRGG38prkztbxwW0cXlxwQqnbN+1J8In8RR+Ln/
AGcP2oX8WQ2badD4nb9iz42t4ii09wQ9jHrR+Hx1KOzcEhrZbkQMCQUIJrRuf2u/hxe3FreX
nwE/ayu7uwcyWN1c/sc/Hae4s3LKxe1nl8BPLbuWRGLQsh3IpzlQQAfXOhaJpPhnRNH8N6Bp
9tpOheH9K0/RNF0uzTy7TTdJ0m0hsNN0+1jyfLtrOzt4beBMnZFGq5OKu/s5/wDKTv8AZw/7
M7/bf/8AVpfsLV8j/wDDZ/gv/oiv7YH/AIiJ8fv/AJhqg+Amnfs+/t0f8FFPgD4D+Lv7PvjT
xL4R8Jfsp/tieJ4vD37RXwJ8c+BNHn12X4j/ALGenafqnh2D4gaDo8Os6hptnLqlteyaYbiT
TINUgF2Il1C3MgB/V/RXwB/w6r/4Jx/9GYfAD/wgtL/+Jo/4dV/8E4/+jMPgB/4QWl//ABNA
HdftOftaaJ+zD4y+F6+N7e0tPhbrvgT9pP4lfE/xg1vq+o6r4N8H/s8fCpvihq2paRoujW93
d61LLpttf/aLC3tLq/njt0i023mu5Ujbjrn/AIKE/CW58e/DD4f+GPCXxa1PV/Gvx50z4I+L
7XxP8JPiv8N9Y+Glv4h+AfxL+PHhj4ja3oPjfwFpV9P4M1nR/h/FZy6henQrTRrC78UazrF/
Z3Xw98SaCPOfij/wSg/Zg8U+D9Z8E/CPwzoX7Oei+Ivhd+0l8Nddtvhf4S0i2t9Xb9o34M6h
8F9R8TahbSyQpcap4Q0bUH1HR4iwivLiMWt08cDFh738Uv2R7D4i/FjRfi7ZfEHWfDGt6Z45
+GXiy80pNE0rWNH1rR/BHw8+PPwl8S+Ebxbh7W/tbHx18Pf2hPGOnSatpt7Z6z4b1qy0bXNL
upvIm0+cA4df+Cl/7JbeE5fGh8TfEVNDu/DHwz8c+C0f4HfGUa58WfAnxh+Jvg74PfDrxp8G
PC3/AAgx8TfFnw94j+IfxD8BaDDceBdI1u6s/wDhN/B2oahaWmm+KvD93qW94Y/4KFfszeKv
Emn+F7XVfiho99qGv+LvBX27xb8A/jj4P0Gx+I/gL4Ya98aPGPwv1TXvEnw/03StP+Ivh74W
+FvE/jDUfCtxdLfRW/h7V9HG7xLZyaLXyh8Ff+CNnwM+Bum6Do/gy/8AAXh+08D337OFn4K1
nwJ+zR8Avhj4/wBQ8H/s4/tK/Bb9pDSbL4w/EnwN4R0nxn8WvGXjHUvgR4H8LeKfFE+q+GPD
d1DHfeKz8PZfF9x/aq/UGsfsM+H9W0fxVpVv8UvH3hqfxR+0P8eP2h08R+EXstC8V+GvEHx2
+AHxT+AV9Z+FdbRbh9IvfB+m/FK88W+F/EIgmvYPEWiaWZrd4DKKAOcvv+Cg3gTWviT8Cvhr
8PvDnjVPEPxH+M3w58E+NvD/AMWfhj8T/hB4m8PfDX4ufBb9p/4kfDr4l+H9L8eeF/D8msWX
iTxF+zV4n8NwQhJZrGTRvE1hrlno2qW9iH+ev2yv+Cl/i79l341/HfwfbXP7KFp4Y+An7PHw
2+NUPgf41fGfWPhX8YPj9r/j68+M0CfDz4Km20PxRY3muLN8MNG0LTLceEvEdxe+JfGWjWM0
dtHewOnU/BP/AIJP+Bfg78WfCPxdtfiBpMOqeF/E/wADvFM/hr4c/BX4ffCXwpr2pfAj4a/t
VfDTQNR1u28OG81jW/EviWw/ao1/VvGXjLxPrXiLxPrOoeGNJtBqVvov9m6ZoXsPxv8A2JPH
nxP+Lfxh+IvgP9pzxF8HtB/aD+DXgD4IfF/wbp/wn+Gvj59Z8L+ApvizFa3/AIb13x5Z6rb+
HtYvdJ+MPiWxb7d4e8R6SlzBp95d6VqUEcunSAHC+N/20vjjrmu/HTU/gT4P/ZssPhh+zR4+
sfhR411v9pD45aj8MNY+KPxfb4aeBfihr3wt8G32k+FNd8I/DOXw9a+PNG8CzeNfGeseKRe+
Pj4itl8EWmgeEYda8W/L/wATv+Cunir4feN/2qG879jm10D9njRvhlrfhb4FePP2iLbwn+01
8boPGv7NXwZ/aJ1DT/hNF4aX4h+D/iHrt8PiNrnw6+Hlp4P0/VdB8beMtO0a3sfFP2C9lvn+
mNX/AOCZdloOieIvAHwL+N+p/DT4PfEDQ/Ael/EH4W+PfhP8NPj/AKM+v/Dj4V+Cfgx4e+KX
w9vviNp7Xfg/4r3vw/8Ah34P0nxNrniVPiL4S12+0j/hJ/8AhBbLxhqWs+IdS91/ZP8A2F/h
N+yIPGtv4Fnv/Edl4j/4UjY+HZPF9jo1/rvg/wAPfAf9mX4Mfsx+EtKt/EEFjb3Wo3V74b+D
Wn+ItX1PydPWbWtc1CK2sLa2hjMoB9q0V8Iat/wTA/4J669qup65rP7HvwI1LV9Z1C91XVdR
u/A2mS3d/qWo3Ml5fXtzKy7pbi6uppZ5pG5eSRmPJrP/AOHVf/BOP/ozD4Af+EFpf/xNAH3/
AF/KP/wT1/5ME/Yd/wCzP/2aP/VL+Cq/bn/h1X/wTj/6Mw+AH/hBaX/8TX8z37C37WvhHw3+
xJ+xz4dufhF+1RqVzoP7K/7Pei3Go+Hv2XPjd4g0DUJ9L+EnhGxlvdD17SfBt1pWt6PdSQNP
pmr6bc3Gn6lZSQXtnPNbTRyMAfW/7bnhfw7q37K/7SniDVNF03Uda8O/sz/tCQ6FqN7axXNz
pC6r8NdVuNQbT2mVxaz3MujaYzXMSrcILRFjlRHlWT5N+MfhvwhZ/sg/sl694f0fwdBrvjL4
tf8ABNi1S+uILWLTvE01h8Yvhje6OuotaI39o2y22r63NcXFvHPeS6Rc35LTW0aqn05c/ti+
Ar23ltbz4Gftc3drOpSe2uf2P/j1PbzISCUlhl8CPHIpIBKupGQOOKoy/tY/C+e0trCf9nz9
quaxsmV7Oyl/Y0+OUlpaOoYK9tbP4AaGBlDsFaJEIDMAcMcgHzn+zpqvwT+Hvwm/ao1X9pu7
+H/hHXU/aU1Xxt+0J8G/Ew0uw+GHwz8da1a+EdN+HOn+EdB8S3Z0nxD4T+IunaD4R+Jfgnxl
e2tpb+PfG+v3vi06V4c8Y6fqejeHPqn9irR/hronwav4vhZ4v8D+KvD+s/FH4qeNr2x+Gvin
w74t8CeANY+I/jTVPiHL8MfDd/4SuLjw3BZeBtO8U6Zo00Gji2sry+ju9bhsbIav9miwr/8A
ax+F+qSedqf7Pf7Veoy+UkHm3/7GnxyvJPJjkeWOHfceAJG8qOWWWRI87Ekkd1AZ2JtWX7YH
w9023S0074Efta2FpGXaO1sv2PPjxa26NIxdykMHgOONS7sXcqoLMSxySTQB9Z+If+QBrn/Y
H1P/ANIp6/y/6/0Q9d/bM8GS6JrMY+C37XqmTStRQNJ+yP8AHyONS9pMoaSR/A4SNATlnYhV
XLMQATX+dT/asP8Az66n/wCCu+/+MUAf6F37J+heONV/Y3/ZmvPCfxQi+HNlp3wi0eXWGn8J
aF4kgvEFskqXU1zrVzbrp0VjDFOZCh8t0lMkzKIlNfQXw6vdXi15Trf7RPhb4mWt5oct5Y+H
tO0PwVo1w8Mt9BbweIILrQtUur25sYpYbrTwViNlLcTsrS+fAqH9DrH/AIIv/sa6ToS+E9G1
n9qPSPBkNpcaXa+CLD9rn9oNPBtpolz5qSeHoPDU3jyfSj4f+zzSWR0ae2msJLFmtJoZYGZG
5Lwr/wAEHf8Agnj4EuYL7wN4O+KvgnUbTwivgCx1Pwf8aviD4X1XTfAqajJrKeDdL1TQtWsN
Q0zwsmsyy6ymgafc22lLrEkmqLai/drg82MeLWGrPAQw08Yo/uIYypVpYaU7rStUo0q1WEeW
/vQpTadvdaucmPePjhK7yyGEqY9QTw1PH1a1HCSnzK6r1cPRxFanDl5rSp0ajUre61c+Zv8A
hY3gD/hO4/hf/wAJr4W/4WRL4dfxfF4C/t7TP+Evl8KRXx0uTxJH4d+0/wBqvocepA6e+qra
myS9BtmmEw2V8j/E741/tKeGdSvbf4TeDPgv8RbaLUvHkGoP8Svi5B8JzoB0TT2n8JWlikPh
nXG1231TUA9t4iu5JLeTw/YQC/Uag8v2YfrnD/wRS/Ywt/Eg8Ywa1+1NB4vXS5tDXxVD+1z8
f4vEi6Jc3i6jcaONcTxyupjS59QVb6bTxdfZJbxVuXhaYBx8X/A//gkB+xb+0pY/Fb4XftWe
H/iN8WPi7+yf8b/ix8HL7XfFvxP8U3l7rfw++IOm6T8QvhT4yk8y5/07UfiB+zn8QPhtpHxE
1xfNi1/x5onjnTppd+m3VjZ/KZtlHEmO4l4GzXCZlTwOVZLVz6pxPldLMMwp0s1jmGTVMHll
OGHpUI4bMY4HMZQxSWYqgsOo+3w6ddKL+IzzIeLsy4v8Ns7wOcUstyTh2vxPV4yyahmmaUqO
dwzTh6tl+T0qeEo4eGDzaGW5tOnjYrNlh1hVH6zhFLFRjB/DV7+0X+3ZCNR+y/s/fspySQPr
gsobn9rcW5mjs5fDS6TLdyD4dSfZftC6hrg1SMRy/wBnSWmiBJLj+1pBae/6X+0befD34H+K
PjP+1TYeD/hhpvhjxhqGjXT/AAx1vxL8bdLGg3XiWy8OeEb+QeD/AAjN4gfXNTudRtINb0Ww
0K/TQbozPPevYwy3cX2rcf8ABuR/wSju0u47n4F69cR30moy3qTfELxPIt1JrDaQ2qvOGuSJ
W1FtA0Q3pfJuTpOnGXd9kg2eueDv+CJP7Enw60u50P4c3P7SXw50K81bVNfu9C+Hv7Unxv8A
A2h3Wva3dNe6zrdxo3hXxfpGmzaxq125uNS1OS1a+vpQr3M8pRNv2h+hHt//AAShhkt/+CbP
7FFvMuyaD9nn4eQyplW2SRaPGki7kLK21lIyrFTjIJGDX6DV5h8FPg94D/Z8+Efw5+B/wv02
90j4efCrwfofgfwdpupazqviHUbXQfD9jFYWCX+ua5d3+r6tetFEJLq/1C8nubmd5JHf5gB6
fQAUUUUAFFFFAHwB/wAEpP8AlGV+wD/2aB+z5/6rDw1X3/XwB/wSk/5RlfsA/wDZoH7Pn/qs
PDVff9ABRRRQAUUUUAFfiF/wUtSaT9tr9hWO3n+zTyfs3f8ABQFILny1m+zzP42/YNWOfyXI
SXynKyeW5Cvt2sQCa/b2vkL9p79iH4Hftb658NfFPxTl+J+k+KfhLp/jzR/BPib4VfF/4jfC
LXLDRviZN4KufGuj3uofD7xDoMur6brV18O/Bt29rqn2pLa40O3ktPIMtz5wB+EWraV8StBu
TZ67+1n4d0W8XT5dWa11b4e/DzTrldKgkMU2pmC81eGUafDKrRy3hX7NHICjyBgRXtUvjLwx
4U8Ct4s8X+PPDa+H/Dvh+LUvE3j7UdR0jRvDwtbCxE2peI767F0NI0nT5VguNQlb7ULKzg8z
bL5EO8fUfi3/AIITf8E/fiDfy6t8Q/D/AMafiJrE3hnU/BU2s/EH4/8AxR8c61L4L1maO51f
wbJq/ivX9X1JvCOp3USXd94Ya6Oh3V3vuprB55ZJH3b3/gih+xRf6IfDE91+0hH4XOjQeHf+
EVsv2ofjXpvhYaDbWEulwaMPDeneLbXQ10yPTZ57AWIsBbtaTTW7RtFLIrceJlmCrYT6nTwd
TDucljnia1elWhT9zklhI0sPWhVn8fNCtKjH4LT1dvPxks1jiMCsBSy+rhZVJrMpYzEYmhiK
dH3PZywMaOFxFOtUv7TnhXnQjpDlqayt8G+N/iHLJ4V8FeLPh14g0DV9H8Wz6Zf6PrNve2F9
ofiTQtV08ahpl1pmrIt3azWGq28tvc2mpWbSRSWkq3EMrxspb46tP2jP27JRpv2r9n/9lGKS
4k0Nb2C3/a3Fw0Ud4/iZdWkspD8O4vtTW66dof8AZcZij/tFrnXA7239kx/avffEf7GPwb8J
f8FBPhr8GvCXiL9oGb9jrwprHhz9jr4kafrv7Rnxc8U6fpn7Snxd+AvxI/aP8JWmlxeJPEuq
2PhGz+G3w7+GvwN8G6NJ4eisrm91X9qiDSZoYYdKtbhPtm3/AODcj/glHaJaR23wL163jsZN
Olskh+IXieNbWTR21dtKeALcgRNpza/rZsimDbHVtRMW37XPv+ayXJuIMFxdxrm+Y5q8XkWd
rhv/AFdyz67jq/8AZH9m5bWw2b2wdenHBYFY/GTp4j/YZ1HinF1cU41IwifI8PZBxRl3HXiH
nua528dw1xEuEf8AVTJnmOY4n+wnlGUYjB57bL8TThl+WrM8fUpYq+W1Krxjg62NcKsIRPzW
+Gfx4/bG8R+NfBWj+OPgz+zPonhPWdX8O2nibW/CX7TH/CV65Y6ff+EbjVdbn8OeHf8AhCbI
65fWfiCOODSLNr+3/tXw4J9YZ7WVBbj6v/Y/+L/w++IP/BWvwB4C8Ja1dal4q+DP7KP7X2h/
EfTp/D3ibSIdB1TxV4+/Yh1nQba31XWtH07R/EIvdMsri6e48MahrNrZKIo7+a1mubaOX6Q8
Pf8ABvN/wTB8I6zpHiPwj8KfHXhPxH4fuNLvNA8ReFvi1448O+INBvdE0V/DmjXuia3o2pWW
qaRe6VoEsmjadd6dd21zZaa7WdvLHASlfZnwC/4Jz/s7/s5/Fu0+OHgvUfjh4n+I2m+BPFvw
40bVvi1+0B8Xfi1Z6H4U8d614K1/xZZ6NovjzxZrWkafda1qXw88ISXeoQWYvfK0iKCOZIpJ
Vf7E++Pu+iiigAooooAKKKKACiiigAooooAKKKKACv49/wBjfQ/HF/8AsC/sMap4Z+K9v8Nt
I0v9i/8AZyn1k3fhHw/4gtZUh+C/gy4k1K51DW7q2XTreztUfzsMIFjVp5XUKSP7CK/IvSv+
CJf7FGieCNN+GWlan+1Fa/DTSPCtn4E074eSftc/tBX/AIIt/A1hpEfh+z8Fv4Y1Px3e6Re+
FYtAij0NtB1C1u9OudIU6fd289s8kbgHwT8OL3VIdZuI9d/aA8M/E9LvSILmw0TT9G8G6Jc2
8d0yXVrrUcug6ndXd3aXFnDcLBuj+yTRO9xHI3kg139r8Rvh/feOdR+GNl418K3fxG0jQofF
Gq+BLfXtMm8Xad4buLuGxg1+98PR3LarbaPNezw2cepTWqWj3UqQLKZWCV9O+F/+CEf/AAT3
8D3U1/4I8K/FzwXqc/hfR/BD6v4Q+OPxG8Mayng3w8znQfCtvrGh6zYanaeHtFSWa30rR7W7
hsLCznuLK1gis7iaB/n39rH/AIJc/srfArwFqPjL4S6j+0rP+1F8ZtT8O/s8/Ai6u/2tP2hP
7Q8R/E3x/qF8/hhfE99Y+PbbXdW+HXwzgTxP8bfiPpcOoK1p8O/APjrWLJUvrcO3FTlmP1zE
RrU8EsvSi8JUp1q8sZKXs6XOsRQlh40IJVXXUZU8RNumqTcVKU1Hz6Ms1eYYqNell6ytRg8F
Wo4jEyzCcvZUPaRxWHnhoYenFVniVCVHFVW6UaDlBSlUUPhz4gfHL9qHQLy4h+FXgT4HfEqy
VPFr3d18RfjNB8JrrSr7S59Ij0OxtbKDwpr/APamkzxXd62r6q0kcumzfYYlW6+0HbyU37RP
7cyTzpD8A/2VZIEvb+G0kk/ayEUt5BD4y0zSLMNCPh84tbqXw5cahc3cQkuhbeJbey0VfNiv
Wurf9ePE3/BA7/gn58StG8H2fxp8PfE/4z6/4T8HxeEG8X+PPib4gvda1uK4tdPi8R6nqSWz
W1iL/wAW3unQap4hNvbRx312kIdTDbW0cXNy/wDBud/wSonluZ5vgh4ilmvJrq4u5ZPiJ4oa
S5nvdcsvE13NM5ui0klz4i06w1ud2JaXVLK2vnJuIY5F+c4ByfP8g4QyXKOKM1/tvPsFRxEM
xzR43HZi8XUqY3E16U3jMyhTxtfkw9WjSvXhFx9n7OC9nCB8l4YZBxPwvwJw9kPGedPiLibL
sPiqea508wzHNXjqtXMMZiKFR5hm1OlmOJdPCVqFDmxNODh7L2VNexhTPhOf9oq48Dfs9zfE
z9qKx8KfDHUdT8Ral4HWx+Ger+J/jXoH27XNbvfD/giCHVfCnhA6m99rZNlFqSyaJHp+i6pP
JZXOobFSZ/8AOnr/AFmPCP8AwRG/Yh+H3h7/AIRD4fXP7Snw+8I/aNTux4U8BftT/HHwV4YW
71q6nvtYu08P+GPGOlaRHdare3Nxd6lcpZrPfXM0s9zJLK7OfDP+IZ3/AII6f9G1+J//AA/n
x3/+eHX2B96fvXRRRQAV8AeP/wDix/7fnwc+JK/6J4I/bH+Hep/sx+OZB8lrF8bvgvZ+Mvjf
+zxqdwP+Pe1/4SD4cXP7TfhLVNWn8mbUtX0/4VeGBNdzyaLZxff9fJ37b3wm8V/F/wDZr8f6
V8NYYZPjN4Fk8N/Gz4CvM/kRj46/A3xNpPxX+FGn3d2MSW2h+JvGPhLS/B3i9ULJqPgvxF4j
0a8hu9O1K8s7gA+saK8x+CvxZ8KfHn4P/C742+BZpp/B3xa+H/hH4i+Gmuk8m9i0bxjoVjr1
ja6jbHElnqllDfLZ6pYzKlxYahBc2dzHHPBJGvp1ABRRRQAUUUUAFFFFAHwB/wAEpP8AlGV+
wD/2aB+z5/6rDw1X3/XwB/wSk/5RlfsA/wDZoH7Pn/qsPDVff9ABRRRQAUUUUAFFFFABXDfE
/wCI3hL4PfDb4g/Frx9qaaL4F+F/gjxX8Q/GesSBSmleFfBehX/iPxDqLB3jVhZ6Tpt3cbWk
QN5e3cucjua+AP24P+Lq6/8As1fsdWn+kRftD/Fqz8a/Fq0T5jH+zN+zVd6J8Vviol/HyJ/D
vxB8cx/Bn9nzxNbFM3Gh/HC+WOW3kUXEQB8m+N/g/wDEPwZ/wSl8Y/FzxT4du4/2mtJ12w/4
Kh+PfD8CtLr0Px18CfFjQv2xL74Q2U7rDJeReGPDvg+x/Zh0OOYW66h4C0HTtDv9tpcXQb9n
dD1vSfEui6P4j0G/t9V0PX9L0/W9G1O0fzLXUdJ1W0hvtOv7aTA3295Zzw3EL4G6ORTgZxVj
UdPsdX0++0rVLS31DTNTs7nT9RsLuJJ7W9sb2B7a7tLmCQNHNb3NvLJDNE6lJI3ZGBUkV8Mf
8E0NQvoP2N/hh8MNau7i88Sfs0al8Qv2RvEM19K8+pXNz+yp8RPFHwF0fWdRmlLT3M3i7wp4
C8O+Nba/uCZ9V03xJYatKS18SQD7zooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC
vgD4c/8AGSf7Yvjz4zzf6Z8JP2QP+Eo/Z4+C2f3mneI/j/rsdj/w078TrPrBef8ACurC38P/
ALN3hfUkWPUPD3iqx/ad8OyM9nrQ3euftgfGXxP8G/g1dP8ADSHT9Q+OfxU8SeH/AIJfs9aP
qkJutNvvjP8AEqebSfDGsa1ZKVkvPB/w50+LW/i38RoYHW5j+Gvw/wDGN1alri3iR/R/gN8G
vDH7Pfwd+HnwY8HzahfaJ8P/AA3aaL/beszC68Q+KtYZpL/xN438VX4AbVPGHjnxNeav4w8X
6xKDPrHibW9V1S4Zp7uRiAeuUUUUAFFFFABRRRQAUUUUAfAH7G3/ABaT4oftW/shXX+j2Hww
+JzftBfB22b5Q/wE/a31nxf8Q7WztEbCxWPgv9oPRv2ivh7o2mWm+z0LwT4Y8EWUQtYJrWzg
+/6+AP2p/wDizn7RP7JH7VkH+i+Hz4wvP2Pfjfcr+7gX4c/tQav4bsfhL4h1AD93eXnhn9qf
wt8GPB+kTXXlDQPDvxi+It/bXcMd3qFjqv3/AEAFFcT8RPiV8OfhF4Q1f4gfFfx94L+GPgPw
/CLjXfGvxB8UaJ4N8J6NAzBFm1XxF4ivtO0jT43chEe6vIg7kIpLEA/G3/DekfxB/d/ssfsw
/tL/ALT1tN8lt4/0rwTpfwJ+CJLcpqNr8Vf2mNd+Edv488Nn7h8QfA3w/wDGG2actbwQzy21
8tmAff8ARXwBs/4KhfEL94Lr9h79lWwl6Wb6d8bv22fE4s5OAWv01b9h7w3oGvCE7mRdP8f6
HpeoMYll8VWFqJtSP+GRv2kvFnzfFT/gpD+0tNby/wDH34Y+Bnw7/Zi+B3hK5V+JUTUrr4K/
Ev4zacojzHbvpPxnsZ4RLPNJNcXS2E9gAff9FfAH/DuH4Nap83jn4y/t0/ERzzLFrv8AwUE/
bL8MaPdvJzejUfCXwr+NXw78F6ra37LCZNK1Tw5eaNZiHy9I07TYri9juj/h1v8AsJTHOq/A
pfFHmf8AH6PHHxL+MHjwayT/AKxvEY8Z/EDXh4ma4PzXjeIBqTXjkvdmZyWIAf8ABKT/AJRl
fsA/9mgfs+f+qw8NV9/1+fVv/wAEov8Agm3aQQ2tp+xT+z1a2tvEkNvbW/w90iGCCGNQkcUM
McaxxRRoAqRoqqqgKoAAFTf8Orf+CdafNafsgfBbSrleYdR0LwyfD+sWcn8M+na1olzp+raZ
dJ1ju9Pvba5iPMcqmgD7/or4AH/BMH9jS1+fw74K+K3gC5PJ1L4UftVftY/CHWGkX/UTvrXw
v+N/hHVnurLMp027e9a50w3N4dPltje3fnH/AA760HSOfh9+1r+3/wDDx04tn/4a8+JPxk+z
LHxaL5X7T0vx3gvfscbzx79Vh1CXUfP87W5NVubTTp7IA+/6K+AP+GfP28PCH/JO/wDgodZ+
Olj5iT9rL9kX4UfEqSfPyyJeXH7LXiX9iKP/AFYVraW0srf7PdtLcXEOoWpj06M/4Wj/AMFF
fhr/AMj/APsr/BP9o3Q7XiXX/wBlr47t4A+JerbfvNZ/A39pjQvB3w60jcoDQLd/tfalvkd4
Znto4UurkA+/6K+IvCX/AAUF/Z11PxJo/gH4o3njj9l34m69eJpeifD79qvwLrfwQvPEutOr
OND+H3jvxLG3wc+L+rBI5He1+DfxL+IOxIpWdwI3I+3aACvgD9nP/i9H7WH7Vv7S8/8ApPhf
4fahp/7E3wVmPz2r6b8HdSuvEv7R/izS25MVx4j/AGgfEN78H/EsLMQ9x+zFos0cUO6SS697
/au+Ns37On7Onxb+MenaOnibxP4S8KTxfDzwczmN/HvxZ8T3dp4Q+EHw5tpBJFtv/iL8UNf8
I+B9OJlhH2/X7bdLEuZFtfsu/BKH9nL9nv4SfBX+2H8Tar4E8HafZeL/ABjOgjvPH3xF1Npd
e+JnxG1NFjiX+2fiL8QtV8TeONaZIYI31bX7x44IUZYkAPeq+AP2ev8Ai2/7bX7dXwZf9xpn
xI/4UN+2b4PhPy23/FzvA99+zz8SNK0peB/xLPF/7Lth428QQID5Oq/FmDUJWL62Av3/AF8A
ftBf8W5/bg/YS+L8f+j6f8TI/wBoH9jXxXN921dviJ4AtP2kPh5qGqOOFk0zxH+yvrPhPw7c
T7Yo9R+J15pUT/bNftoZwD7/AKKK8G+N37UH7P37OUGjt8afiv4T8D6n4mklg8H+Ebq7m1f4
h+PLyEM0um/Dv4aeHrfV/iD8QtWREkkbSfBXhnXtTEccsn2Ty4pGUA95or4A/wCGtf2iviT8
v7OH7B/xc1jTZ/m034iftZeMPD/7Hfw41GNv9WW8M6lpHxb/AGr9EkQYkuYvE/7KWhtHFJGL
c3l0t1aWp/wgX/BTHxv++8Q/tG/slfAfT5/nfw38Kf2bviN8ZvFensekUHxc+J/xz8D+F9Sh
jVmVmn/ZxsJp5khuA9tEs1jMAff9FfAH/DEPxG8RfvPil/wUK/bl8es/EmneHfEvwF+AuiwQ
n5ZLTTz+zx8Afhb4sjhlie4VrvVPGOsa3DLdPPaavbSWejHSj/h2j+zRqHzeMvEH7WvxNkk/
4+ofid+31+3J430K7U/JLE/gnWf2hpvANra3luFstTsdN8K2NjrFmpg1e2vlluDMAff9FfAH
/DrH/gn7Lxqv7MXgXxQg5hh8cX3i3x7b2jH70mn23jTxHr0GnTSjCzz2MdvNOipHM8iIiqf8
Oq/+Ccf/AEZh8AP/AAgtL/8AiaAPv+ivgA/8EsP+CfEXOlfssfDjwvIeJZ/BA8QeA7q6Qfdh
vrvwZreg3V/bo3zx217NcQRSZljjWQlqP+HZf7Ktj83hCT9pn4YPH81snwh/bn/bd+FOm2si
/PER4c8A/tC6B4XvbWO5zfPpOq6JqGiXl889zqOmXj3d59oAPv8Aor4A/wCGFfFWgfvfhd+3
v+3n8OLiLm2TUfid8L/j1p5C/MltfWv7UnwY+ON3d2cjvcC6eHUbLWHhu3jtNZsZbLRp9KP+
FWf8FIfBXz+EP2u/2dPjDp0HTRfj3+yhr/hzxZqaR/6hW+J/wO+PHgzwtotxMGcajdL8ANeg
nf7NLYabpaQXFvfgH3/RXwB/w0x+178NePj1+wb4i8Q6VD/x+eO/2MfjN4P/AGifD9hap11T
V/AnxV0b9mH43M0qbWk8P/Dj4Z/FrVbS7kNnbSazZQNrcvtXwV/bA/Zx/aB1nUfCXw1+Junz
fEbQ7Mah4k+DvjbR/Evwq+OnhSxL+UL3xb8Dfinovg34t+F7E3AktUv9d8G2FjLdQXNtDcST
W86RgH0rRRXzJ+1z8afEHwR+DGp6p8PrDT9d+NXxA1zQPg/+z74W1PzH0/xH8bviVef2B4GX
WIoP9KPg/wAKzy3nxD+JN5aK82h/DDwb408RMvkaPMwAPG/BH/GSn7Z3i74oy/6Z8IP2K/7f
+Cvwqz+807xN+074z0a0/wCGgPiJZ5zDdf8ACoPAOoaL8AfC+s2jmTT/ABV4x/ad8I6hGs+n
pt+/68b/AGfPgt4f/Z4+DHw++DXhu/1DW7PwTof2XVPFOs+W3iHx14v1W8u9f8efEbxVLFiK
68YfEjxvq3iHx34vvUAW+8TeItVvAq+ftHslABRRRQAUUUUAFFFFABRRRQB4v+0X8F9F/aL+
BHxa+Buv391o9h8UPAfiLwjD4h08Y1bwnrGpafKvh3xnoUgZGt/EXgvxAumeKvDt5HJHLZa3
o9hdwyJLAjj4k+FX7avxQ+OPwl+CngH4WeG/CN1+2V4w+H99L8drHxP/AGhP8Lf2X/E3w48Y
eIfgp8aPFnxGstGuNM13xHa6f8dvAPxG8E/CP4Z6PqHhrXvjFqvhHXFh8R+BvB/hjxz488H/
AKh1+ZvwC8A+F/2cP2/f2xdDvtNj0A/tqTfDT9oL4Ta3KscWk+KNT8B+Bn8C/Gv4W6JdtGjR
eJfCPiawb476l4bmmZ9Yt/jt4p8WeHI75NG+IJ8PAHtPw7/Yj+FWg+L9I+Lvxhvdc/ag/aB0
mY3+mfGX47jTPFF74I1GZSLhfgj4AhsbT4Z/ALSwrNZpF8KPCnhzXtW0+O3/AOE28S+MtZW5
1u7+yaKKACiivzZ/bN+BGq/Gj47fBYa18NdY+JfwWg/Zr/bT8H/EjRo3F34WufFvi+3+Auq/
CnTfEvhyTVbKLXbjUZPBfjgeGZHsNTg0jxBb2VzJJpd/PpF5QB+k1Y+heIdD8TWU+peHtWsN
ZsLbWPEXh64vNOuY7q3h1zwl4g1Pwp4n0mSWJmVb/QfEui6toeq2xIks9T068tJlWaB1H8/f
wf8A2dP2oNU+LP7NA/ab8HftXa9r3hv4e/sL+M/h38Vvhxrf7Oc+gfCjxX8J/hd4E8M/tKfD
b42+OfiNpl/8aPD82s/EjTPH3ifx9afDLX9U8O/tEeAfiFd+FLe51HULC9Q9x4E/Y0+K3wy/
Z++GA+F37P3hbwX8Wvg5+2n+1Ppeo+B9Wh8LaR4A+K37Pf7Vnxm+MHgH/hKL2P4e3Wtm+8De
Bvh58UvhT8Yo7bV7HQvGVjoXwPvPBFhp2mW9zHY6gAfvJRX4X6V+y3+2F4J/Zl8PeFb/AEd/
FviD4L/Hr9nH4I3WkaZrXhTUPGH7RX/BOb9mv9oQ6vqOu622o3Ntpn/C0fjh8MdZvdd+M/gO
61/Tbb4oaV4VHgzUrW8vvFN7omtQP+xx4u8X/ED4PeF/F3wr8Uav+ybqX7cv7R/jvw78Mxda
v4d0L4Ufsq+PP2LtY+HWjeF/E3g6DWdF1Twt4R8X/tM32s+NfDXwzgtJ7jwbonjfS/7U8MeC
bTQ9b8PeFQD9aPgb8f8AwP8AtBWPxN1DwNbeILaD4T/G34nfALxQPENhZ2Ekvjn4Sa5/wjvi
yXSVs9S1JbvQv7UEkWmahO1pcXscTzPY26GMyc78XP2q/hJ8FPEt54X8Z3mtNc+HfAlv8Vvi
NqWkaWt9ovwl+FF54jm8JWPxK+JF/Ld2o0bwre+ILPWLW2bT4tX1h9P8M+MvEh0hfC3gnxdr
ei/mX+w78E/2kPg/+1h8etV+Mvwdu/EfwS+MH7UH7Y/xD+CniL7Fon9o/ALVfE3xfl8aWnjn
xBYyapJcax4b/aU8E6r4Ts/DfiGytpfGHww1z4ZXfhzUtA0zRPHvifWNM9V/bA/Z2+MfirxP
+39Y+BPCN/4ytf27P2BvAH7KvgPVrfUbSDSfh78TfDN9+1D4T1Ofx41yyzaF4JHhf9pmx+Is
WvW8V5FcwfDvx54chifxrrXw+8P+MAD9cKKytC0tdD0TR9FS4luk0fStP0tLqfAmuV0+0htF
uJsEjzZhCJJMEjexwSK1aAOd8W+EPCfj7w3rHg3x14X8O+NfCHiGzfTtf8K+LdE03xH4b1zT
5GV5LHWND1i2vNM1Ozd0Rntr21nhZkVmQlQR8Qn9l7x9+zGD4k/Yh1ye28F6cDPqv7FnxA8T
6hd/AvXNMiGZNM+AniDWf7a1n9lrxHbQADwz4d8Jtd/s7zyRyaTqnwm8N32uTfEnw5+gFVr2
9s9Os7vUNQu7awsLC2nvb6+vZ4rWzsrO1iee5u7u5neOG3treFHmnnmdIoYkeSR1RSQAfltr
Pxh8Hftv/tAfsi/DrwG+pyeBPhdd+MP2u/2gfDOv2P8AZniLwb43+DXiXXPgn8Gvgr8TtCM1
0dD8Y6P+0gfH/jp9PjnuIbTxp+yTemz1W90xbeXVv1Sr82f+Cfvw28P3PjD9tL9sTR/Dh0Wz
/bX/AGiNP8a/D2+uILi0vdb+A/wi+Fngb4OfDjxHHZzhfs/h34n+L/DPxY/aD8HyiOKbVPDn
xusdbvYbe+1S4tLf9JqACvgz/gpbp99a/sf/ABD+K2i2lxeeJP2YNc+HP7XugwWMTz6neD9l
n4h+Gfjh4p8P6bDEGmuLjxz4B8FeLvh/PZwKbnUNO8V32n2xS4uonX7zrL1zRNJ8S6LrHhzX
rC31XQ9f0vUNE1nTLtPMtdR0nVbSax1GwuY8jfb3lnPNbzJkbo5GGRnNAHwzefEr4nftf6vr
3hf9mj4gD4V/s9eGNd1fwh49/al8O2eieI/HPxB8WeHdQuNG8YfDv9max8RabrXgzTLbwhrd
rfeGfiD8dvFuj+K9O0XxVpOvfDz4f+BtY8UWWtePvhz7r8Ef2VfgL+z1PrGsfDL4f2Np448U
xxL45+LXii/1fx98bPiNJEVeO4+I/wAZvHN/4h+JnjqSJ0X7HH4l8UajaaZCkVnpNtY2MFva
xfOn/BL3SrP4Y/sjfDv9ljUozpnxO/Y8sF/Z3+KmhXmI9Xudc8ESz2ug/FCWIrHJd6F8evCn
9j/GnwvrojCavpfjbZdraa/Ya7pOmfohQAUUUUAFZGv6/onhXQ9X8S+JNUsdE8P6Dp13q2s6
xqVxHa2GmabYQPc3l7eXEpWOGC3gjeSR2PCqcZJAP4+eLf2dviWv7SfjT4saL8MPFsmswf8A
BUf4J/E/wP42trpXn0j9m7Uv2LPgT8I/jfq3h2eXWvM0Lwj4i8f+GfiJoXxD8OWEFlqPjSO0
0fUNT0TXdIt/C93b/FB/Yt+Pnjz4HftD2PxO+CH7R3jX9p3Svhnd+DfiNceKrr9k2P4AftO+
KvCfx/8Ah/8AFHw746+GsujWXhXx58SvFmt+HfD2u6z8LPEfxq1PTdS+EeneIfE3wp1PVNPv
dZaOQA/pxor8Of2n/wBk/wDaBtfH3iXxl+zH8MND07w0nhz4F/tf+B/AGo3HhrSk0L9o79ka
S/0+/wD2Z7ay8PR3mg+HND/ae8Eap8K/CD3mg+Irrwl4ZvPhv8VddtZptS8Zadrlr3vxY/Zy
+KKeOfhtZ/ET4ZSfGH4E6/8Asr/tI2fjvwR4BtbDWbTw1+3j8WviL8OPiNp3xG0/TL660LXt
MXVWHxB8I/CD4tWtzHL8C4RcLqniX4c6J4p1LxLcgH6b/HD4ueGvgD8Gvir8c/Glnrd94M+D
vw98X/E7xhb+G7S01DXj4V8C6DfeJfEc+lWF9f6Xa3t5aaNpt7dx2kl/bNceQYYnaZ40f0HR
9Uttc0jStashKLPWNNsdUtBOgjmFtqFtFdwCZFZ1SURTIJEV3CvkBmAyf589a/Yo+PviX4Hf
t3af8avAnin4uftOal/wT0+Hvwk+EnxIk8SXOr6T8RP2g/EX7C3jD4FfGmfwPNd67Y6bYS+K
viJ4gNn4l1XxPoXhnTr+LVLDW5ZHg0Ga60P9Jv2C/CXxb8B+E/iH4Q+PngWKD4s6P4vsn1D4
7adY2thoX7Q/hHUvDOi6h4E8SWOkG+vdW8D6t8PPDc9j8IvF3w8viuk6P4p8DaprvhO61XQP
EsF5QB9PeFfjZ4C8Z/Fj4p/BXQrnXG8e/BrQ/h14h8dWWp+FvEWh6dbab8VJPG8fg+40TWNa
02w0/wAVW95/wr/xH9p1Hw1Pquk2k1utjJqH9pR3tnZ+s18X/DDwV4z0r9uv9rn4g6r4W1jT
vAnjb4H/ALIHhbwb4tuY7b+x/E2vfDnWP2mdS8c6dpzQ3M13FJ4dtviV4L+0Saja2EF9Lq0s
Wjy6k+ka2NN+0KACvFfjV+zn8Df2itG07RPjX8MPCfxBh0K8OqeFtV1jT/J8WeB9b2bI/Enw
88b6ZJYeMvh54qtl/wCPLxV4I17QPEVifms9TgbmvaqKAPz1vtX+KH7C9rJrnj/4h+I/jf8A
sZ6cYx4g8d/Ee/n1z47fsuaS8qQDxN468cybrr44/APSPNjbxV438WRR/GD4RaPbXfjb4geL
fi54QfxH4h+G1rwYR+0j+2v4z+I0xF98Jf2JLa/+D3wwKkS6V4g/ae+I3huw1L46ePLZz+5v
J/hJ8LdZ8KfBTwzrNg8i6dr/AMRf2kPB+oMNQ0+e3s/aP2wviH4Z+HP7OHxWvPEOinxje+LP
CGvfDjwT8MrWOK61v4w/ETx9o+oeG/Bfwl8NabLJEupa3491q+g0SOOWWDT9OsJ7/XddvtL8
O6Tq+rWMH7Ff7PFp+yh+yj8BP2fIpILzVfhr8N/D+l+Nddgnmum8YfE/ULc678VvH17eXEcM
99qvxA+JOq+KvGmr300MD3mp67d3Bt7cSCGMA+n6KKKACiiigAooooAKKKKACiiigAry34wf
Bn4dfHbwdJ4H+JegtrGkx6lY6/omo6fqeqeHfFfg3xZpBlfQfG/gDxn4evNM8VeA/HXh2aaW
48P+MfCer6R4h0eaSU2OoQrNMknqVFAHwB9t/bg/Zt/0ObQIf29fhDZfLYaromqeBfhJ+2J4
e02PiK013RvEd34L/Z2+Pd1FHvefxRpvij9mzWYrWG0s/wDhCPHGuTXmuXPT+D/+Ch37JXiP
xBY+B/FfxOHwF+KGov5Nl8JP2ofDviP9mn4larcoQsyeE/DXxp0zwY/xFsoXYJ/wkHwzufGX
hi5yJLDW7uFllb7YrmPGHgnwZ8Q/D994T8f+EfDHjnwtqieXqXhrxhoGleJvD+ox4YbL7Rta
tL3TrtMMw23FtIuGYYwTQB0qOkiLJGyujqro6MGR0YBlZWUkMrAgqwJBBBBwadXwE/8AwTK/
ZG0V2m+D/hb4ifsvTBmeC1/ZJ+Ofxp/Zl8JQSOSXM3wt+Dnjvwl8ItXjbLsLXxB4A1eyjmb7
XFbR3iRXEbf+GR/2lfCfz/Cv/gpD+0lHBF/x5+Gfjt8N/wBmP44eErYR/LbxSajp/wAGPhd8
ZdShMREN42rfGa+vboQW1xHe2t6+p3WpgH3/AEV8Af8ACB/8FQdB/wCQf+09+xB8RbSPmGx8
U/sX/Gz4e69Nj99It94v8M/tu+L9El86UvZWrWXwx0/+zbNre5uU1y7tbgakf23/AMFTbT/R
/wDhWf7AGveXx/a3/C8v2ivCX2zd8+7/AIR7/hnjxr/Z3k7vs+3/AISfVftHlfa99r9o+xWw
B9/0V+RXwU/a/wD+CmXx5/Zv+GP7SXw9/YR/Yx1jw/8AFj4S+F/i34P8JXn/AAUf+MHh7x3q
mmeLPDNp4m0bQ7jTr7/gmpd+DNF8S3kF5BZvZ3fxDufD9hfyeTP4tlsYm1RsL4Jftx/t9fH/
AFnWPANl+zD+xJ8DPjV4R0+HVvHPwG+Lv7av7Q138aPC9hNObJNRuvBD/wDBPbwHp2veC5r4
SWml/F34Z+L/AIl/CfxJe29xZeGfFurtFNcQAH7JUV8Aed/wVO1r91/Z37AHw0z8n23+2v2i
vjht2/vftH9mf2D+z3u87b9h+x/2un2bzf7V+3Xfkf2PcH/Cnf8AgpBr/wAvin9uT9nbwnbT
fLInwT/YU13w/q9nAf3oS11r4yfte/HfSrnUopCbd9UufCEenXdmilPDVhdubhQD7/rjPHvx
G+Hvwq8NXnjP4oePPBnw38H6cQNQ8V+PfFGh+D/DViWSSRRea74hvtO0u1LRwzSAT3SEpFI4
+VGI+M/+GFvFPib5vjF+3l+3b8U0m5udN0b4o/Dz9mzSUD/NLaabcfsg/Cb9n/xhZ2KvhbWS
88Y6nrsMKIk+vXcpnnn7PwF/wTz/AGLPh34ls/HWmfs8eBPFfxJ04FbD4tfGJdY+Pvxls1d4
5ZUtvjH8ctV+InxQhS5mhguLtI/Fqrd3MEFzdCWeGKRADjP+Hgngn4kf6B+x98LPix+2VqFz
8ll4z+F3h8eE/wBm+IScR6pdftTfE5/CXwZ8TaHASk2pw/BjXvjD42trGWG7sfA2qC6sorqz
Zfs1fGT4/Xlprf7bvjbwlqvgqG5g1HT/ANkD4LjWB8BBPBKtxaw/G7x54ns9K8c/tQvp08av
Do2r+GfhN8FtRV1PiX4GeJNV0zSPEFp97UUAIAFAVQFVQAqgAAADAAA4AA4AHAFLRRQAUUUU
AfNXxt/Zo0H4ra5pHxK8JeLvFHwS+PvhTS20fwl8cPhx/ZaeIxoQupdRHgP4haBrVlqPhb4t
fCm71OaW9vvh7460zUbHT725uvEXgjUPBPjpdO8Yab4r/wANDftT/An/AIl/7Tf7NusfFnwt
Z/If2g/2KtF1f4iabdWsfXVPGn7Kup6nqX7QngrULnkW/hr4OzftVQARtPd+JtPM8Vkn3/RQ
B80/Bv8AbI/ZZ/aA1S48N/CP47/DjxZ43sAw1r4ZN4gt/D/xe8MSxxGeS18YfB/xQNF+J/g2
/igBnm0/xV4S0e+ihBlkt1Qbq+lq8W+Mn7N/7Pn7ROl2+i/Hv4HfCT4z6XZlX0+0+KPw88J+
OV0qeOUXEF3o8niTStRm0e/tLpUvLLUNMktL2xvY4ry0uILqKOZfmn/h3N8I/DvzfBn4wftf
/s+bP+PXTfhf+1j8adW8EaZt+aBdD+EXxh8UfFb4MaBbwyhZTZaJ8O9PsLth5Wo2t7bvJA4B
9/0V8Af8M2/tteFv3XgD/go74m8VWy/LGP2mv2XPgF8TL2OM/vNn239nzT/2QlmaKQCC3mub
aeb+zwYr6S/1NjrBP+Ef/wCCpuh/81b/AGAPijt4/wCTd/2ivgN5m/8Aeb8/8NQftH+R9n2/
ZfKxcfbfP+3+dYfZf7NvAD7/AKK+AP8AhKv+Cptt+/8A+FD/ALAGt+X839lf8NaftFeF/tvb
yv7f/wCGK/F/9mYz5nn/APCNatu2eV9nXzPOiP8AhY3/AAVN/wCjN/2AP/Fln7RX/wBKdoA+
/wCivgD/AIS7/gqbe/v/APhnz9gDw1n5f7L/AOGxP2ivHGzbx539vf8ADC/w98zzuv2b/hHI
vs2Nv2u63b1P7L/4Km6//wAz1+wB8J/N5x/wqj9or9oT7D53z7d3/C5v2Y/7V/s/H2fft0f+
2PM+2bND8n7DOAff9FfAH/DPn7efif8AdeO/+CiGm+EYJebib9mX9j74XfDrU4Wm/wCPhdLu
f2jvGX7YunW0MBLDSU1PR9altQEGqXGuFXaQ/wCHefgvxH83xm/aU/bh+Oxf5ru18UftWfEf
4TeHtTf7pGseBv2U7n9nf4f6vYvDiCbQtS8KXXh25A8+50ia9JuiAfQ3xo/al/Zs/Z0hspPj
v8ePhL8JJ9V2roelePfHvhvw54g8SXEjGOCw8K+G9Q1GHX/FWqXco8ix0nw7pup6nf3JW2s7
SedljPzz/wANZfG340/6B+yL+y9481LSbv8AdJ8e/wBq7SvE/wCzJ8HdPjfh9Q0T4deLdBH7
T3xJuLeFl1DSrW0+Dvgj4feL4Gt4LH4zaPDdPqln718F/wBkr9l/9nSa9vPgX+z98H/hTq+q
7m1vxJ4J+H/hrRPF3iOV1CSXXijxha6cvijxRfSxhY5r/wAQavqV7NGiRyzuiIo+haAPk34R
/swXHhzxpafGv47/ABH1H9oX9oO2stQsdG8Z6roNt4Q+HXwo0/WYDa61oP7PnwitdS13Tvhf
pWsWhay1zxHq/iPx78XvFWmsui+Mvip4k0Cz0jR9M+sqKKACiiigAooooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKAPgD/glJ/yjK/YB/7NA/Z8/wDVYeGq+k/jb+zv8H/2htH0fSvi
p4Rj1i+8K6hNrfgPxpo2qax4P+Jnwx8RzQC1bxV8LPif4Rv9E8f/AA18UG2H2WTXvBXiLRNS
ubFpdNvJ7jTri5tJvmz/AIJSf8oyv2Af+zQP2fP/AFWHhqvv+gD4A/tj9rv9ln5PE9nrn7b/
AMBrL/mb/DGk+H9C/bE+H2kpwX8U+AtIt/D3w5/aU0vTIVkubvW/hra/DD4s/wBnQ2ulaT8I
fjF4tmuNX1H6p+D3xx+E3x/8Jf8ACb/B7xzovjjw/FqF3ouqPpzXNprHhnxFpxVNW8JeNfC+
rW+n+J/A3jTRJmFtr/gzxjo+h+KtAvA1nrOkWN0jwr6tXyt8Yf2R/h78TvFv/C2/CWs+KvgP
+0Pbafa6bYftA/Bq603QPHd/p2mhhpnh34j6Tqmmaz4F+NngexDypZ+B/jF4U8beH9Ha4n1L
wtb+HPES2eu2YB9U0V8Af8NNfF79m3/iWftueDNLb4f2n7qD9sf4IaJr158F1tY+BqPx2+GN
ze+JviD+zTIyB7jUfE1xq3xR+BWj2VtNqvin4zeCZLyy8Op906Dr2heKdF0rxL4Y1rSfEfh3
XtPtNW0PX9B1Gz1fRdZ0q/hS5sdT0rVdPmuLHUdPvbeSOe0vbOea2uIXSWGR0ZWIBrUUV+Kn
/BTTxd8W7j9qX9jz4M+B/jp8Xvgx4J8Z/AH9tT4neMI/g94lsfCOseJvFPwq+In7DXhXwI+r
azNo2q3z6boek/Gb4hKml20ltaXd1rMV3epcTadYNbgH7V0V/NL/AMK++Mf/AEfD+3B/4fGH
/wCZKj/hX3xj/wCj4f24P/D4w/8AzJUAf0tUV/NL/wAK++Mf/R8P7cH/AIfGH/5kqP8AhX3x
j/6Ph/bg/wDD4w//ADJUAf0tUV/NL/wr74x/9Hw/twf+Hxh/+ZKvZP2JvE3xn8Hf8FB/APwk
179pD49fF34c/EH9jb9q34ja14W+MfjOw8a2Vp42+E3xt/Ye8M+C/EGhz/2Bpt/pN1ZaF8Z/
iDp15Fb3ZtNSi1eF723lm02wltwD99qKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig
AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPgD/glJ/yjK/YB/7NA/Z8/wDVYeGq
+/6+AP8AglJ/yjK/YB/7NA/Z8/8AVYeGq+/6ACiiigAr4W179jm9+G2tar8Qf2KfHVr+zd4t
1XULvXPE/wAJ7nQpfFP7KXxT1a8me71K68W/Be01LRB8O/FmuXMlxcah8UfgZrPw88V6lrFz
FrnxGs/itaabB4auPumigD4q8EftjWWl+LdB+EX7VHgS6/Zd+MviPUItD8IJ4i12LxN8CvjF
rUgYw2fwK+PkWm6F4d8VaxfeXM+n/DPx5o/wx+OU8Fre6inwpk0C3j126+GP+CjP/J/f7DH/
AGZ//wAFF/8A1dH/AATHr9kvG/gXwV8TPCWveAfiN4R8M+PfA3irT5dJ8TeDvGWhaZ4m8L+I
NMmKtLp+taDrNteaZqdm7ojtb3lrNF5kaPt3orD+e79qb4AWXwA/b7/ZA0Hwl8R/ih4h+GGp
/sf/ALfkngb4X/EPxOfHmmfCBrH40f8ABN4a1pngDxn4itb34nTeE9dW80kWXg/xn418WaJ4
Gi0K30r4ew+F/DU/9g24B6HX5/WviH47TftYa38BH+NesCw039l7wt8a4LpfCHw0Fs/j7W/i
b4w8G3ejy58CnUG8AR2nh+ya309LuPxWnm3UkniyWV4vJ/QGvF4/ghoEX7QV3+0bH4i8WL4s
vvhNp/wbuvDXneHD4Ll8MaV4r1PxlYX32ZvDR8TJr0GsaxqX+lR+KU0+W1ufIm0uQwwSRAHw
BeftSfGS2+Pnib4T+E/GNz4w+IFj+2b4c+FHhb4Ua/4K0mx8Ja/+zrafDH4J+PPjV4xu/H2k
+FdGk07xh8L9I+JviLxPaXEHirUJXj0vwboF78P9al8SR39/9SfEb4h+K/Av7Uf7P/hWb4r3
ll4Z+Lmp+ONBu/hzrXwyeLwHf6fovw48ReItGHhn4sWfh2eW0+NB8WaHBdJ4X1/xvFofiP4d
DxO2neD7DxBouk6nr13VP2OvAeqr8QrqTxt8SrTxL45+PmjftKaR410+88EWvin4X/FDQ/C/
hPwPaXnw5uR4EbTbfRrrwV4PsfCGt6J4w0vxlZ+I/DeqeI9H18alZa/qUU3pc/wZ/tnxVo3i
Pxv8Q/Gfj7T/AAp4vtPHXgvwl4h074dWWg+GPEll4b1Hw3a3sEvhbwJ4d13VhZR6xquq6dHr
msaiLLWLxb0GRtO0ddNAPa6Z+zD/AMpTfgP/ANmAft7f+tFf8Ey6fTP2Yf8AlKb8B/8AswD9
vb/1or/gmXQB+/dFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ
AUUUUAFFFFABRRRQAUUUUAFFFFAGP4e8PaB4S0HRvC3hTQ9H8M+GPDml2Oh+HvDnh7TLLRdB
0HRdLtorLTNI0bSNNgttP0vS9Os4YbSx0+xt4LS0toooLeGOKNUGxRRQAUUUUAFFFFABX8+f
/BXX4TfDD4xfto/sLeHviv8AD3QfiX4e0f8AZP8A+Ci3iew8OeINMg1a3Gu6f8V/+CbNja3l
la3GIxqQsdT1GwtpMg7L+aPIWRq/oMr+TL/g5X/b3/4dv/Gr/gnr+0H/AMKo/wCFy/8ACQfC
79uf4Nf8Ij/wnX/Cu/sn/CWeLP2HPG//AAkf9v8A/CHeOftH9n/8Ky/sz+x/7Fh+1f239t/t
S2/s37JfgHin/DN37I3/AEjw/wDMZaH/APJte5aZ+wX+xZqOm6dqEv7K3wp06S+sbS8k0+/8
G6dFfWD3VvHO9leRruWO7tWcwXCKzBJo3UMQMn+UT4tf8HOf7Qfi3xDc6j8KPg3ZfCDQJPh3
q3h628N3Xjvwt8RjbfES51NbrR/iM+saz8E9JvLiy0vTjJpd34IMcdhqv7m+XV9OnjlW47fx
N/wc0+PL34cX3gG8/Z18T2Hi/WPBNhYS/FLwn+0D4Y8P69p2s6x4eE8vibRNIu/2adc0nT9R
trzUYry0tpVvdOhlsIIham1lnt5OHE4yrQxODw9PAYvFxxTq+0r4eeBjSwUKUqMXVxMcVjMN
WnTl7bRYOli6q5JXpK8ebzsXj62GxeAwtLLMdjo4x1vbYnC1MuhRy6nRlh4utjI43H4PETpS
df3VgKGNrr2c70VeHN/S/wCNP2Ov2DfAdpYX2vfsxfCpbS+vPsn2i18GaVJHaBY2mlursyzQ
FLWGJWeRoRNLtB2QuRivje3+JX/BCG7S2kt9R/ZMliuxpRgmXw/IIW/tuz1zUNKVpm0kRRPe
2XhvW7iKOV0cR6fKZFQvCJfy9+GX/Bw34g+K/gk+F4v2btd0zW/gv8No/FNz43179oK18Sa5
4/1LwjpNpp73viO20v4F+D9Ng1LXrtW1fVbizt/7PN3PcR2+kRQPHHF8A2//AAckf8FCI0tv
tD/Cy4liGlCcr4H0yCG6+y2euRaqzRLC8sT6re3uiXkRiuFTTo9DltY47gatNNbfJ5BmufYz
jTj/ACzMVBZJlE+Flw9y0cNCbjj8mlic1dSrSxNXEV/9uVovFUMK6aXJRhVpr20/h+F874mx
/iF4oZPmqprh3IanBi4V5cPhKdRwzPIJ4vOnVrUcXXxWJ/4UVaDxuGwTpRTp4enWpL6xU/pt
+H9//wAEUfin4w8K/D/4faf+y74p8aeN7/T9M8KeG9O8MuNU1u+1XwwPGenW9nBc6XB8134Z
ZdWieVoozCyRM4uXWA/pX+wV+z/8FPgX/wAFTfhL/wAKe+GPg/4cf8JT+wB+3F/wkX/CJ6Rb
6V/bP9iftFf8E3P7I+3+QB5/9nf2vqf2Xd/qvt1zt/1hr+JP4f8A/By3+2xoXjDwrqvxB8L/
AA9+IHgvTL/T5/FfhDTtP0zwTqniqxg8MDTNRsLPxZbeHtd/4RxtQ8TbvFEV3FoOpyWMJTQF
juLZWvJP6C/+Dcv9vjSP+Cg3/BW34u/Eqw+GPxG+FV/4b/Yl+PF1qvh/xf8AtHeJfjr4SMnj
344/sVWsFt8OfDWseCvBGj/CXS9NHw1mu9Y03w7ZXsPirUdfS8vGsjodpHc/dH6Sf3eUUUUA
FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf//Z
--------------010406010708020803050906
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

--------------010406010708020803050906--




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 QAA13674 for <[e-mail]>; Wed, 9 Feb 2005 16:25:46 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyyof-0001ed-LN; Wed, 09 Feb 2005 15:52:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyyUH-0004LD-2C for [e-mail]; Wed, 09 Feb 2005 15:31: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 PAA10350 for <[e-mail]>; Wed, 9 Feb 2005 15:30:59 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyyo6-0001SP-KV for [e-mail]; Wed, 09 Feb 2005 15:51:33 -0500
Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 09 Feb 2005 21:42:54 +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 j19KUHlu015920;  Wed, 9 Feb 2005 21:30:18 +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);  Wed, 9 Feb 2005 21:30:17 +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] Implementation Report on draft-ooms-v6ops-bgp-tunnel-04.txt
Date: Wed, 9 Feb 2005 21:30:10 +0100
Message-ID: <[e-mail]>
Thread-Topic: [Idr] Implementation Report on draft-ooms-v6ops-bgp-tunnel-04.txt 
Thread-Index: AcUHqySzetynr//TQb2tcNC2mxRXWgFgPI/wAG5WxGA=
From: "Francois Le Faucheur \(flefauch\)" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 09 Feb 2005 20:30:17.0479 (UTC) FILETIME=[2AE42970:01C50EE6]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae
Cc: [e-mail], [e-mail], "Francois Le Faucheur \(flefauch\)" <[e-mail]>, Bill Fenner <[e-mail]>, [e-mail], Susan Hares <[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 QAA13674

Hello,

For information, below is the statement of compliance for Cisco IOS implementation of draft-ooms-v6ops-bgp-tunnel-04.txt.

Francois


STATEMENT OF COMPLIANCE TO draft-ooms-v6ops-bgp-tunnel-04.txt
=============================================================

2. Protocol Overview

"
The 6PE router MUST be dual stack IPv4 and IPv6.
"
==> Does your implementation comply?: Y

"
The 6PE router MUST be configurable with at least one IPv4 address on
the IPv4 side and at least one IPv6 address on the IPv6 side.
"
==> Does your implementation comply?: Y

"
The 6PE routers MUST exchange the IPv6 prefixes over MP-BGP sessions as
per [MP-BGP-v6] running over IPv4.
"
==> Does your implementation comply?: Y

"
The MP-BGP AFI used MUST be IPv6 (value 2). 
"
==> Does your implementation comply?: Y

"
Therefore, the IPv4 address of the egress 6PE router MUST be encoded as
an IPv4-mapped IPv6 address in the BGP Next Hop field.
"
==> Does your implementation comply?: Y

"
In addition, the 6PE MUST bind a label to the IPv6 prefix as per
[LABEL]. 
"
==> Does your implementation comply?: Y

"
The SAFI used in MP-BGP MUST be the "label" SAFI (value 4) as defined in
[LABEL]. 
"
==> Does your implementation comply?: Y

"
The Ingress 6PE router MUST forward IPv6 data over the IPv4-signaled LSP
towards the Egress 6PE router identified by the IPv4 address advertised
in the IPv4-mapped IPv6 address of the BGP Next Hop for the
corresponding IPv6 prefix.
"
==> Does your implementation comply?: Y
 

3. Transport over IPv4-signaled LSPs and IPv6 label binding

"
When tunneling IPv6 packets over the IPv4 MPLS backbone, rather than
successively prepend an IPv4 header and then perform label imposition
based on the IPv4 header, the ingress 6PE Router MUST directly perform
label imposition of the IPv6 header without prepending any IPv4 header. 
"
==> Does your implementation comply?: Y

"
The (outer) label imposed MUST correspond to the IPv4-signaled LSP
starting on the ingress 6PE Router and ending on the egress 6PE Router.
"
==> Does your implementation comply?: Y

"
This label advertised by the Egress 6PE Router with MP-BGP MAY be an
arbitrary label value which identifies an IPv6 routing context or
outgoing interface to send the packet to, or MAY be the IPv6 Explicit
Null Label. 
"
==> Does your implementation comply and advertise an "arbitrary label
value"?: Y
==> Does your implementation comply and advertise "IPv6 Explicit Null
Label"?: N


"
An Ingress 6PE Router MUST be able to accept any such advertised label.
"
==> Does your implementation comply and accept an "arbitrary label
value"?: Y
==> Does your implementation comply and accept "IPv6 Explicit Null
Label"?: Y


4. Crossing Multiple IPv4 Autonomous Systems

"
(a) EBGP redistribution of IPv6 routes from AS to neighboring AS
The exchange of IPv6 routes MUST be carried out as per [MP-BGP-v6].
"
==> Does your implementation support (a)?: Y
==> If yes, does it comply?: Y

"
(b) EBGP redistribution of labeled IPv6 routes from AS to neighboring AS
When peering over IPv6, the exchange of labeled IPv6 routes MUST be
carried out as per [MP-BGP-v6] and [LABEL]. 
"
==> Does your implementation support (b)?: Y
==> If yes, does it comply?: Y

"
When peering over IPv4, the exchange of labeled IPv6 routes MUST be
carried out as per [MP-BGP-v6] and [LABEL] with encoding of the IPv4
address of the ASBR as an IPv4-mapped IPv6 address in the BGP Next Hop
field.
"
==> Does your implementation comply?: Y
 

5. Security Considerations

"
To this end an ASBR 6PE SHOULD only accept labeled packets from its peer
ASBR 6PE if the topmost label is a label that it has explicitly signaled
to that peer ASBR 6PE.
"
==> Does your implementation comply?: N (under development)

 

>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On 
>> Behalf Of Francois Le Faucheur (flefauch)
>> Sent: lundi 7 février 2005 17:11
>> To: [e-mail]
>> Cc: Bill Fenner; [e-mail]; [e-mail]; 
>> [e-mail]; Susan Hares
>> Subject: [Idr] Implementation Report on 
>> draft-ooms-v6ops-bgp-tunnel-04.txt 
>> 
>> Hello,
>> 
>> A Last Call has been issued on Jan 31 in IDR for
>> draft-ooms-v6ops-bgp-tunnel-04.txt.
>> 
>> In line with the requirements for progressing a Routing document
>> (RFC1264), an implementation report needs to be submitted to 
>> the IESG on
>> draft-ooms-v6ops-bgp-tunnel-04.txt.
>> 
>> As an input to this report, we would like to gather information on
>> existing implementations of 
>> draft-ooms-v6ops-bgp-tunnel-04.txt. Hence,
>> could those who have implemented these extensions provide:
>> 	-1- identification of the implementation
>> 	-2- statement of compliance (provide all the Yes/No answers in
>> statement below which is based on all the MUST/SHOULD/MAY of
>> draft-ooms-v6ops-bgp-tunnel-04.txt)
>> 	-3- statement as to whether you allow that information to be
>> made public or want it to be kept confidential.
>> 
>> You can either respond onto the list (assuming you are happy 
>> to have the
>> info public) or respond in private to myself or to the WG chairs.
>> 
>> Thank you 
>> 
>> Francois
>> 
>> 
>> 
>> STATEMENT OF COMPLIANCE TO draft-ooms-v6ops-bgp-tunnel-04.txt
>> =============================================================
>> 
>> 2. Protocol Overview
>> 
>> "
>> The 6PE router MUST be dual stack IPv4 and IPv6.
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> The 6PE router MUST be configurable with at least one IPv4 address on
>> the IPv4 side and at least one IPv6 address on the IPv6 side.
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> The 6PE routers MUST exchange the IPv6 prefixes over MP-BGP 
>> sessions as
>> per [MP-BGP-v6] running over IPv4.
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> The MP-BGP AFI used MUST be IPv6 (value 2). 
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> Therefore, the IPv4 address of the egress 6PE router MUST be 
>> encoded as
>> an IPv4-mapped IPv6 address in the BGP Next Hop field.
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> In addition, the 6PE MUST bind a label to the IPv6 prefix as per
>> [LABEL]. 
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> The SAFI used in MP-BGP MUST be the "label" SAFI (value 4) 
>> as defined in
>> [LABEL]. 
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> The Ingress 6PE router MUST forward IPv6 data over the 
>> IPv4-signaled LSP
>> towards the Egress 6PE router identified by the IPv4 address 
>> advertised
>> in the IPv4-mapped IPv6 address of the BGP Next Hop for the
>> corresponding IPv6 prefix.
>> "
>> ==> Does your implementation comply?: Y/N
>>  
>> 
>> 3. Transport over IPv4-signaled LSPs and IPv6 label binding
>> 
>> "
>> When tunneling IPv6 packets over the IPv4 MPLS backbone, rather than
>> successively prepend an IPv4 header and then perform label imposition
>> based on the IPv4 header, the ingress 6PE Router MUST 
>> directly perform
>> label imposition of the IPv6 header without prepending any 
>> IPv4 header. 
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> The (outer) label imposed MUST correspond to the IPv4-signaled LSP
>> starting on the ingress 6PE Router and ending on the egress 
>> 6PE Router.
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> "
>> This label advertised by the Egress 6PE Router with MP-BGP MAY be an
>> arbitrary label value which identifies an IPv6 routing context or
>> outgoing interface to send the packet to, or MAY be the IPv6 Explicit
>> Null Label. 
>> "
>> ==> Does your implementation comply and advertise an "arbitrary label
>> value"?: Y/N
>> ==> Does your implementation comply and advertise "IPv6 Explicit Null
>> Label"?: Y/N
>> 
>> 
>> "
>> An Ingress 6PE Router MUST be able to accept any such 
>> advertised label.
>> "
>> ==> Does your implementation comply and accept an "arbitrary label
>> value"?: Y/N
>> ==> Does your implementation comply and accept "IPv6 Explicit Null
>> Label"?: Y/N
>> 
>> 
>> 4. Crossing Multiple IPv4 Autonomous Systems
>> 
>> "
>> (a) EBGP redistribution of IPv6 routes from AS to neighboring AS
>> The exchange of IPv6 routes MUST be carried out as per [MP-BGP-v6].
>> "
>> ==> Does your implementation support (a)?: Y/N
>> ==> If yes, does it comply?: Y/N
>> 
>> "
>> (b) EBGP redistribution of labeled IPv6 routes from AS to 
>> neighboring AS
>> When peering over IPv6, the exchange of labeled IPv6 routes MUST be
>> carried out as per [MP-BGP-v6] and [LABEL]. 
>> "
>> ==> Does your implementation support (b)?: Y/N
>> ==> If yes, does it comply?: Y/N
>> 
>> "
>> When peering over IPv4, the exchange of labeled IPv6 routes MUST be
>> carried out as per [MP-BGP-v6] and [LABEL] with encoding of the IPv4
>> address of the ASBR as an IPv4-mapped IPv6 address in the 
>> BGP Next Hop
>> field.
>> "
>> ==> Does your implementation comply?: Y/N
>>  
>> 
>> 5. Security Considerations
>> 
>> "
>> To this end an ASBR 6PE SHOULD only accept labeled packets 
>> from its peer
>> ASBR 6PE if the topmost label is a label that it has 
>> explicitly signaled
>> to that peer ASBR 6PE.
>> "
>> ==> Does your implementation comply?: Y/N
>> 
>> _______________________________________________
>> 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 OAA08375 for <[e-mail]>; Wed, 9 Feb 2005 14:56:58 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyxsB-0005EI-El; Wed, 09 Feb 2005 14:51:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyxh4-0000ed-NV for [e-mail]; Wed, 09 Feb 2005 14:40: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 OAA04607 for <[e-mail]>; Wed, 9 Feb 2005 14:40:08 -0500 (EST)
Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyy0v-0008RU-Sn for [e-mail]; Wed, 09 Feb 2005 15:00:42 -0500
Received: from zbl6c004.us.nortel.com (zbl6c004.corpeast.baynetworks.com [132.245.205.54]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j19JbYl04992; Wed, 9 Feb 2005 14:37:34 -0500 (EST)
Received: by zbl6c004.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id <1JMBWH1J>; Wed, 9 Feb 2005 14:37:33 -0500
Message-ID: <[e-mail]>
From: "Vivian Lu" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Wed, 9 Feb 2005 14:37:32 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.8 (/)
X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f
Cc: [e-mail]
Subject: [Idr] RE: Prefix-list ORF sequence number question
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="===============0168393085=="
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.

--===============0168393085==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C50EDE.CC802B4C"

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_01C50EDE.CC802B4C
Content-Type: text/plain

Thanks for the clarification.

Vivian.

> -----Original Message-----
> From: Enke Chen (enkechen) [mailto:[e-mail]] 
> Sent: Wednesday, February 09, 2005 1:38 PM
> To: Lu, Vivian [BL60:SF21:EXCH]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Prefix-list ORF sequence number question
> 
> 
> Hi, Vivian:
> 
> Please see my comments inlined.
> 
> > -----Original Message-----
> > From: Vivian Lu [mailto:[e-mail]]
> > Sent: Wednesday, February 09, 2005 6:12 AM
> > To: Vivian Lu; '[e-mail]'; '[e-mail]'
> > Cc: '[e-mail]'
> > Subject: Prefix-list ORF sequence number question
> > 
> > Hi,
> > 
> > I have a question regarding prefix-list ORF draft,
> > draft-ietf-idr-bgp-prefix-orf-00.txt. 
> > 
> > The "sequence" field as specified in the draft is the following, 
> >         "The 'Sequence' field is a number that specifies the
> > relative ordering of the entry." 
> > 
> > What is the scope to which the statement is referring that
> > makes the ordering significant? 
> 
> The "Sequence" field is used in Sect 6. Address Prefix ORF 
> Matching when multiple ORF entries match a particular NLRI.
> 
> We can add some text to the definition in the next revision.
> 
> > 
> > Is the scope
> > 
> > 	*	per bgp peer session? 
> > 
> > 		-- That is, sequence number is continuously
> > incremented for each orf entry through out the peer session. 
> > 		-- Sequence number gets reset when the peer 
> > session is reset. 
> > 	*	per ORF message? 
> > 
> > 		-- That is, sequence number is continuously
> > incremented for each orf entry within an ORF message. 
> > 		-- Sequence number gets reset when a new ORF 
> > message is created. 
> > 	*	per ORF type block in the orf message ?
> > 
> > 		-- That is, sequence number is continuously
> > incremented for each orf entry within an ORF type block 
> > inside an ORF message.
> > 
> > 		-- Sequence number gets reset when a new ORF
> > type block is written. 
> > 
> > We are wondering which one is what you intended and the
> > industry may agree with. 
> 
> Per the base ORF spec., ORFs are exchanged on a per peer
> basis, and the life time of an ORF is the duration of the session.
> 
> The scope of the sequence number is within the prefix-ORF
> type exchanged over the session.  It is a local matter
> (on the sender) how the sequenece number is assigned for
> the intended semantics "relative ordering").
> 
> -- Enke
> 

------_=_NextPart_001_01C50EDE.CC802B4C
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: Prefix-list ORF sequence number question</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Thanks for the clarification.</FONT>
</P>

<P><FONT SIZE=3D2>Vivian.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Enke Chen (enkechen) [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>] =
</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, February 09, 2005 1:38 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Lu, Vivian [BL60:SF21:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [e-mail]; [e-mail]; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: Prefix-list ORF sequence number =
question</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi, Vivian:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Please see my comments inlined.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Vivian Lu [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Wednesday, February 09, 2005 6:12 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Vivian Lu; '[e-mail]'; =
'[e-mail]'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: '[e-mail]'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Prefix-list ORF sequence number =
question</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I have a question regarding prefix-list =
ORF draft,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; draft-ietf-idr-bgp-prefix-orf-00.txt. =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The &quot;sequence&quot; field as =
specified in the draft is the following, </FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;The =
'Sequence' field is a number that specifies the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; relative ordering of the entry.&quot; =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; What is the scope to which the statement =
is referring that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; makes the ordering significant? </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The &quot;Sequence&quot; field is used in Sect =
6. Address Prefix ORF </FONT>
<BR><FONT SIZE=3D2>&gt; Matching when multiple ORF entries match a =
particular NLRI.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; We can add some text to the definition in the =
next revision.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Is the scope</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; per bgp peer session? </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- That is, sequence number =
is continuously</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; incremented for each orf entry through out =
the peer session. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- Sequence number gets =
reset when the peer </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; session is reset. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; per ORF message? </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- That is, sequence number =
is continuously</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; incremented for each orf entry within an =
ORF message. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- Sequence number gets =
reset when a new ORF </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; message is created. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; per ORF type block in the orf =
message ?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- That is, sequence number =
is continuously</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; incremented for each orf entry within an =
ORF type block </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; inside an ORF message.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- Sequence number gets =
reset when a new ORF</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; type block is written. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; We are wondering which one is what you =
intended and the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; industry may agree with. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Per the base ORF spec., ORFs are exchanged on a =
per peer</FONT>
<BR><FONT SIZE=3D2>&gt; basis, and the life time of an ORF is the =
duration of the session.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The scope of the sequence number is within the =
prefix-ORF</FONT>
<BR><FONT SIZE=3D2>&gt; type exchanged over the session.&nbsp; It is a =
local matter</FONT>
<BR><FONT SIZE=3D2>&gt; (on the sender) how the sequenece number is =
assigned for</FONT>
<BR><FONT SIZE=3D2>&gt; the intended semantics &quot;relative =
ordering&quot;).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -- Enke</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C50EDE.CC802B4C--


--===============0168393085==
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

--===============0168393085==--



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 NAA04256 for <[e-mail]>; Wed, 9 Feb 2005 13:45: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 1CywlN-00007h-Gs; Wed, 09 Feb 2005 13:40:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cywja-00086a-Uq for [e-mail]; Wed, 09 Feb 2005 13:38:44 -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 NAA25364 for <[e-mail]>; Wed, 9 Feb 2005 13:38:40 -0500 (EST)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyx3R-0005r9-CL for [e-mail]; Wed, 09 Feb 2005 13:59:14 -0500
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 09 Feb 2005 10:48:37 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.88,190,1102320000";  d="scan'208"; a="613342807:sNHT447927426"
Received: from enkechenw2k (dhcp-128-107-134-98.cisco.com [128.107.134.98]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j19Ic6uC018758; Wed, 9 Feb 2005 10:38:07 -0800 (PST)
Message-Id: <[e-mail]>
From: "Enke Chen \(enkechen\)" <[e-mail]>
To: "'Vivian Lu'" <[e-mail]>
Date: Wed, 9 Feb 2005 10:38:06 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400
Thread-Index: AcUOsWGjLS4KPseYQdujevTg40r16gAI5FvQ
In-Reply-To: <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: 7bit
Cc: [e-mail], [e-mail]
Subject: [Idr] RE: Prefix-list ORF sequence number question
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]

Hi, Vivian:

Please see my comments inlined.

> -----Original Message-----
> From: Vivian Lu [mailto:[e-mail]] 
> Sent: Wednesday, February 09, 2005 6:12 AM
> To: Vivian Lu; '[e-mail]'; '[e-mail]'
> Cc: '[e-mail]'
> Subject: Prefix-list ORF sequence number question
> 
> Hi, 
> 
> I have a question regarding prefix-list ORF draft, 
> draft-ietf-idr-bgp-prefix-orf-00.txt. 
> 
> The "sequence" field as specified in the draft is the following, 
>         "The 'Sequence' field is a number that specifies the 
> relative ordering of the entry." 
> 
> What is the scope to which the statement is referring that 
> makes the ordering significant? 

The "Sequence" field is used in Sect 6. Address Prefix ORF Matching
when multiple ORF entries match a particular NLRI.

We can add some text to the definition in the next revision.

> 
> Is the scope 
> 
> 	*	per bgp peer session? 
> 
> 		-- That is, sequence number is continuously 
> incremented for each orf entry through out the peer session. 
> 		-- Sequence number gets reset when the peer 
> session is reset. 
> 	*	per ORF message? 
> 
> 		-- That is, sequence number is continuously 
> incremented for each orf entry within an ORF message. 
> 		-- Sequence number gets reset when a new ORF 
> message is created. 
> 	*	per ORF type block in the orf message ?
> 
> 		-- That is, sequence number is continuously 
> incremented for each orf entry within an ORF type block 
> inside an ORF message.
> 
> 		-- Sequence number gets reset when a new ORF 
> type block is written. 
> 
> We are wondering which one is what you intended and the 
> industry may agree with. 

Per the base ORF spec., ORFs are exchanged on a per peer
basis, and the life time of an ORF is the duration of the
session.

The scope of the sequence number is within the prefix-ORF
type exchanged over the session.  It is a local matter
(on the sender) how the sequenece number is assigned for
the intended semantics "relative ordering").

-- Enke

_______________________________________________
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 JAA19543 for <[e-mail]>; Wed, 9 Feb 2005 09:27:10 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyshl-0003y3-Sy; Wed, 09 Feb 2005 09:20:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cysa5-0001yS-R3 for [e-mail]; Wed, 09 Feb 2005 09:12: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 JAA04313 for <[e-mail]>; Wed, 9 Feb 2005 09:12:36 -0500 (EST)
Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cystu-0008Ag-Nk for [e-mail]; Wed, 09 Feb 2005 09:33:07 -0500
Received: from zbl6c004.us.nortel.com (zbl6c004.corpeast.baynetworks.com [132.245.205.54]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j19EC3V24037; Wed, 9 Feb 2005 09:12:03 -0500 (EST)
Received: by zbl6c004.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id <1JMBWFMD>; Wed, 9 Feb 2005 09:12:03 -0500
Message-ID: <[e-mail]>
From: "Vivian Lu" <[e-mail]>
To: "Vivian Lu" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Date: Wed, 9 Feb 2005 09:12:02 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc: "'[e-mail]'" <[e-mail]>
Subject: [Idr] Prefix-list ORF sequence number question
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="===============0594236792=="
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.

--===============0594236792==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C50EB1.53748E78"

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_01C50EB1.53748E78
Content-Type: text/plain

Hi, 

I have a question regarding prefix-list ORF draft,
draft-ietf-idr-bgp-prefix-orf-00.txt. 

The "sequence" field as specified in the draft is the following, 
	"The 'Sequence' field is a number that specifies the relative
ordering of the entry." 

What is the scope to which the statement is referring that makes the
ordering significant? 

Is the scope 
*	per bgp peer session? 
		-- That is, sequence number is continuously incremented for
each orf entry through out the peer session. 
		-- Sequence number gets reset when the peer session is
reset. 
*	per ORF message? 
		-- That is, sequence number is continuously incremented for
each orf entry within an ORF message. 
		-- Sequence number gets reset when a new ORF message is
created. 
*	per ORF type block in the orf message ?
		-- That is, sequence number is continuously incremented for
each orf entry within an ORF type block inside an ORF message.
		-- Sequence number gets reset when a new ORF type block is
written. 

We are wondering which one is what you intended and the industry may agree
with. 

Thanks. 
Vivian. 



------_=_NextPart_001_01C50EB1.53748E78
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>Prefix-list ORF sequence number question</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">I have a question regarding =
prefix-list ORF</FONT><FONT SIZE=3D2 FACE=3D"Arial"> draft, =
draft-ietf-idr-bgp-prefix-orf-00.txt</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The &quot;sequence&quot; field as =
specified in the draft is the following, </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">&quot;The 'Sequence' field is a number that specifies =
the relative ordering of the entry.&quot; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">What is the scope to which the =
statement is referring that makes the ordering significant? </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Is the scope </FONT>
<UL>
<UL><LI><FONT SIZE=3D2 FACE=3D"Arial">per bgp peer session? =
</FONT></LI>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- That is, sequence number is =
continuously incremented for each orf entry through out the peer =
session. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">-- Sequence number gets reset when =
the peer session is reset. </FONT>
<LI><FONT SIZE=3D2 FACE=3D"Arial">per ORF message? </FONT></LI>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- That is, sequence number is =
continuously incremented for each orf entry within an ORF message. =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">-- Sequence number gets reset when a =
new ORF message is created. </FONT>
<LI><FONT SIZE=3D2 FACE=3D"Arial">p</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">er ORF type block in the orf message ?</FONT></LI>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- That is, sequence number is =
continuously incremented for each orf entry within an ORF type block =
inside an ORF message.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- Sequence number gets reset when a =
new ORF type block is written. </FONT>
</P>
</UL></UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">We are wondering which one is</FONT> =
<FONT SIZE=3D2 FACE=3D"Arial">what</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">you intended and the industry may agree with. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Vivian. </FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C50EB1.53748E78--


--===============0594236792==
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

--===============0594236792==--



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 JAA19500 for <[e-mail]>; Wed, 9 Feb 2005 09:25:45 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cysgz-0003fl-3C; Wed, 09 Feb 2005 09:19:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CysYn-0001mj-Nu for [e-mail]; Wed, 09 Feb 2005 09:11: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 JAA04265 for <[e-mail]>; Wed, 9 Feb 2005 09:11:15 -0500 (EST)
Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyssb-00089U-N1 for [e-mail]; Wed, 09 Feb 2005 09:31:46 -0500
Received: from zbl6c004.us.nortel.com (zbl6c004.corpeast.baynetworks.com [132.245.205.54]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j19EAfV23936; Wed, 9 Feb 2005 09:10:41 -0500 (EST)
Received: by zbl6c004.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id <1JMBWFLW>; Wed, 9 Feb 2005 09:10:41 -0500
Message-ID: <[e-mail]>
From: "Vivian Lu" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Date: Wed, 9 Feb 2005 09:10:40 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 1.4 (+)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc: "'[e-mail]'" <[e-mail]>
Subject: [Idr] (no subject)
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="===============0282134737=="
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.

--===============0282134737==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C50EB1.024A609A"

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_01C50EB1.024A609A
Content-Type: text/plain

Hi, 

I have a question regarding prefix-list ORF draft,
draft-ietf-idr-bgp-prefix-orf-00.txt. 

The "sequence" field as specified in the draft is the following, 
	"The 'Sequence' field is a number that specifies the relative
ordering of the entry." 

What is the scope to which the statement is referring that makes the
ordering significant? 

Is the scope 
*	per bgp peer session? 
		-- That is, sequence number is continuously incremented for
each orf entry through out the peer session. 
		-- Sequence number gets reset when the peer session is
reset. 
*	per ORF message? 
		-- That is, sequence number is continuously incremented for
each orf entry within an ORF message. 
		-- Sequence number gets reset when a new ORF message is
created. 
*	per ORF type block in the orf message ?
		-- That is, sequence number is continuously incremented for
each orf entry within an ORF type block inside an ORF message.
		-- Sequence number gets reset when a new ORF type block is
written. 

We are wondering which one is what you intended and the industry may agree
with. 

Thanks. 
Vivian. 



------_=_NextPart_001_01C50EB1.024A609A
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></TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">I have a question regarding =
prefix-list ORF</FONT><FONT SIZE=3D2 FACE=3D"Arial"> draft, =
draft-ietf-idr-bgp-prefix-orf-00.txt</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The &quot;sequence&quot; field as =
specified in the draft is the following, </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">&quot;The 'Sequence' field is a number that specifies =
the relative ordering of the entry.&quot; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">What is the scope to which the =
statement is referring that makes the ordering significant? </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Is the scope </FONT>
<UL>
<UL><LI><FONT SIZE=3D2 FACE=3D"Arial">per bgp peer session? =
</FONT></LI>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- That is, sequence number is =
continuously incremented for each orf entry through out the peer =
session. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">-- Sequence number gets reset when =
the peer session is reset. </FONT>
<LI><FONT SIZE=3D2 FACE=3D"Arial">per ORF message? </FONT></LI>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- That is, sequence number is =
continuously incremented for each orf entry within an ORF message. =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">-- Sequence number gets reset when a =
new ORF message is created. </FONT>
<LI><FONT SIZE=3D2 FACE=3D"Arial">p</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">er ORF type block in the orf message ?</FONT></LI>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- That is, sequence number is =
continuously incremented for each orf entry within an ORF type block =
inside an ORF message.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- Sequence number gets reset when a =
new ORF type block is written. </FONT>
</P>
</UL></UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">We are wondering which one is</FONT> =
<FONT SIZE=3D2 FACE=3D"Arial">what</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">you intended and the industry may agree with. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Vivian. </FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C50EB1.024A609A--


--===============0282134737==
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

--===============0282134737==--



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 LAA06088 for <[e-mail]>; Mon, 7 Feb 2005 11:25: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 1CyBed-0007QW-CX; Mon, 07 Feb 2005 11:22:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyBYE-0006e3-25 for [e-mail]; Mon, 07 Feb 2005 11:15: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 LAA13290 for <[e-mail]>; Mon, 7 Feb 2005 11:15:47 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyBrd-00045G-PZ for [e-mail]; Mon, 07 Feb 2005 11:35:54 -0500
Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 07 Feb 2005 17:27:03 +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 j17GF2m6012906;  Mon, 7 Feb 2005 17:15:13 +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);  Mon, 7 Feb 2005 17:15:09 +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, 7 Feb 2005 17:10:42 +0100
Message-ID: <[e-mail]>
Thread-Topic: Implementation Report on draft-ooms-v6ops-bgp-tunnel-04.txt 
Thread-Index: AcUHqySzetynr//TQb2tcNC2mxRXWgFgPI/w
From: "Francois Le Faucheur \(flefauch\)" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 07 Feb 2005 16:15:09.0263 (UTC) FILETIME=[31A845F0:01C50D30]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407
Cc: Bill Fenner <[e-mail]>, [e-mail], [e-mail], [e-mail], Susan Hares <[e-mail]>
Subject: [Idr] Implementation Report 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>
Sender: [e-mail]
Errors-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id LAA06088

Hello,

A Last Call has been issued on Jan 31 in IDR for
draft-ooms-v6ops-bgp-tunnel-04.txt.

In line with the requirements for progressing a Routing document
(RFC1264), an implementation report needs to be submitted to the IESG on
draft-ooms-v6ops-bgp-tunnel-04.txt.

As an input to this report, we would like to gather information on
existing implementations of draft-ooms-v6ops-bgp-tunnel-04.txt. Hence,
could those who have implemented these extensions provide:
	-1- identification of the implementation
	-2- statement of compliance (provide all the Yes/No answers in
statement below which is based on all the MUST/SHOULD/MAY of
draft-ooms-v6ops-bgp-tunnel-04.txt)
	-3- statement as to whether you allow that information to be
made public or want it to be kept confidential.

You can either respond onto the list (assuming you are happy to have the
info public) or respond in private to myself or to the WG chairs.

Thank you 

Francois



STATEMENT OF COMPLIANCE TO draft-ooms-v6ops-bgp-tunnel-04.txt
=============================================================

2. Protocol Overview

"
The 6PE router MUST be dual stack IPv4 and IPv6.
"
==> Does your implementation comply?: Y/N

"
The 6PE router MUST be configurable with at least one IPv4 address on
the IPv4 side and at least one IPv6 address on the IPv6 side.
"
==> Does your implementation comply?: Y/N

"
The 6PE routers MUST exchange the IPv6 prefixes over MP-BGP sessions as
per [MP-BGP-v6] running over IPv4.
"
==> Does your implementation comply?: Y/N

"
The MP-BGP AFI used MUST be IPv6 (value 2). 
"
==> Does your implementation comply?: Y/N

"
Therefore, the IPv4 address of the egress 6PE router MUST be encoded as
an IPv4-mapped IPv6 address in the BGP Next Hop field.
"
==> Does your implementation comply?: Y/N

"
In addition, the 6PE MUST bind a label to the IPv6 prefix as per
[LABEL]. 
"
==> Does your implementation comply?: Y/N

"
The SAFI used in MP-BGP MUST be the "label" SAFI (value 4) as defined in
[LABEL]. 
"
==> Does your implementation comply?: Y/N

"
The Ingress 6PE router MUST forward IPv6 data over the IPv4-signaled LSP
towards the Egress 6PE router identified by the IPv4 address advertised
in the IPv4-mapped IPv6 address of the BGP Next Hop for the
corresponding IPv6 prefix.
"
==> Does your implementation comply?: Y/N
 

3. Transport over IPv4-signaled LSPs and IPv6 label binding

"
When tunneling IPv6 packets over the IPv4 MPLS backbone, rather than
successively prepend an IPv4 header and then perform label imposition
based on the IPv4 header, the ingress 6PE Router MUST directly perform
label imposition of the IPv6 header without prepending any IPv4 header. 
"
==> Does your implementation comply?: Y/N

"
The (outer) label imposed MUST correspond to the IPv4-signaled LSP
starting on the ingress 6PE Router and ending on the egress 6PE Router.
"
==> Does your implementation comply?: Y/N

"
This label advertised by the Egress 6PE Router with MP-BGP MAY be an
arbitrary label value which identifies an IPv6 routing context or
outgoing interface to send the packet to, or MAY be the IPv6 Explicit
Null Label. 
"
==> Does your implementation comply and advertise an "arbitrary label
value"?: Y/N
==> Does your implementation comply and advertise "IPv6 Explicit Null
Label"?: Y/N


"
An Ingress 6PE Router MUST be able to accept any such advertised label.
"
==> Does your implementation comply and accept an "arbitrary label
value"?: Y/N
==> Does your implementation comply and accept "IPv6 Explicit Null
Label"?: Y/N


4. Crossing Multiple IPv4 Autonomous Systems

"
(a) EBGP redistribution of IPv6 routes from AS to neighboring AS
The exchange of IPv6 routes MUST be carried out as per [MP-BGP-v6].
"
==> Does your implementation support (a)?: Y/N
==> If yes, does it comply?: Y/N

"
(b) EBGP redistribution of labeled IPv6 routes from AS to neighboring AS
When peering over IPv6, the exchange of labeled IPv6 routes MUST be
carried out as per [MP-BGP-v6] and [LABEL]. 
"
==> Does your implementation support (b)?: Y/N
==> If yes, does it comply?: Y/N

"
When peering over IPv4, the exchange of labeled IPv6 routes MUST be
carried out as per [MP-BGP-v6] and [LABEL] with encoding of the IPv4
address of the ASBR as an IPv4-mapped IPv6 address in the BGP Next Hop
field.
"
==> Does your implementation comply?: Y/N
 

5. Security Considerations

"
To this end an ASBR 6PE SHOULD only accept labeled packets from its peer
ASBR 6PE if the topmost label is a label that it has explicitly signaled
to that peer ASBR 6PE.
"
==> Does your implementation comply?: Y/N

_______________________________________________
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 LAA04332 for <[e-mail]>; Fri, 4 Feb 2005 11:18:03 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx62P-00063c-8d; Fri, 04 Feb 2005 11:10:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx60b-0005eK-7j for [e-mail]; Fri, 04 Feb 2005 11:08: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 LAA10200 for <[e-mail]>; Fri, 4 Feb 2005 11:08: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 1Cx6JP-0005HU-22 for [e-mail]; Fri, 04 Feb 2005 11:28:03 -0500
Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 04 Feb 2005 17:18:57 +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 j14G7viR010161;  Fri, 4 Feb 2005 17:08:02 +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, 4 Feb 2005 17:07:22 +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] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Date: Fri, 4 Feb 2005 17:06:51 +0100
Message-ID: <[e-mail]>
Thread-Topic: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Thread-Index: AcUKx4TxEvy1n4dzRaa5HWHl0Xg6mAACSryw
From: "Francois Le Faucheur \(flefauch\)" <[e-mail]>
To: "Jeffrey Haas" <[e-mail]>, "Pedro Roque Marques" <[e-mail]>
X-OriginalArrivalTime: 04 Feb 2005 16:07:22.0412 (UTC) FILETIME=[9C2736C0:01C50AD3]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: [e-mail], "Francois Le Faucheur \(flefauch\)" <[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 LAA04332

Jeffrey, Pedro,

The proposed updated text actually stays away from discussing what is the right "policy" to decide whether IPv6 VPN traffic should be transported over v4 or v6. It basically just says, "if IPv6 VPN traffic is to be transported over vN, then you shall include a next-hop that looks like vN"; For example:
"
3.2.1.1 BGP speaker requesting IPv6 transport
When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv6 tunneling (e.g. IPv6 MPLS LSPs, IPsec-protected IPv6 tunnels), the BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address:
...blablabla 
"

Personally, I think it is probably beyond the scope of this particular IPv6 VPN document to prescribe what policies may/should/must be used by operators for selection of transport vs BGP stack. So, my proposal would be to :
	- keep the proposed updated text that we discussed
	- add a couple of sentences that point out potential operational issues involved in transporting traffic over vN when the corresponding BGP advertisements are carried themselves over vM (instead of vN).

Would that be acceptable?
Pedro, would you be willing to craft the couple of additional sentences?

Cheers

Francois

>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On 
>> Behalf Of Jeffrey Haas
>> Sent: jeudi 3 février 2005 11:41
>> To: Pedro Roque Marques
>> Cc: [e-mail]
>> Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
>> 
>> On Mon, Mar 24, 1975 at 10:06:56AM -0800, Pedro Roque Marques wrote:
>> > The point is that it does. If ibgp transport between PE1 
>> and PE2 uses
>> > the forwarding LSP between PE1 and PE2 then a silent (in control
>> > plane) forwarding failure will cause the BGP transport 
>> session to come
>> > down.
>> 
>> Right.  But this is a generic MP-BGP issue rather than one specific
>> to this particular protocol extention.
>> 
>> > > I will agree with you 100% that there are operational 
>> practices that
>> > > will provide better survivability in certain failure 
>> scenarios.  Do
>> > > these belong in this protocol extention?  Probably not.
>> > 
>> > I thought so... but i conceed that it is a matter of opinion.
>> 
>> I objected to the SHALL.  It sounds like you believe a SHOULD is the
>> solution.  Propose new text - that's what last call is all about. :-)
>> 
>> I wouldn't object to a SHOULD.
>> 
>> >   Pedro.
>> 
>> -- 
>> Jeff Haas 
>> NextHop Technologies
>> 
>> _______________________________________________
>> 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 KAA01946 for <[e-mail]>; Fri, 4 Feb 2005 10:10:51 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx4tL-0002GI-Lv; Fri, 04 Feb 2005 09:57:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx4sJ-00023J-0X for [e-mail]; Fri, 04 Feb 2005 09:55: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 JAA02927 for <[e-mail]>; Fri, 4 Feb 2005 09:55: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 1Cx5B4-0003cM-Rq for [e-mail]; Fri, 04 Feb 2005 10:15:24 -0500
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 662CE2D4E1B for <[e-mail]>; Fri,  4 Feb 2005 09:55:26 -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 66755-02-16 for <[e-mail]>; Fri,  4 Feb 2005 09:55:22 -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 796D62D4CC5 for <[e-mail]>; Fri,  4 Feb 2005 09:55:22 -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="us-ascii"
Subject: RE: [Idr] RFC 2858 erratum
Date: Fri, 4 Feb 2005 09:55:22 -0500
Message-ID: <[e-mail]>
Thread-Topic: [Idr] RFC 2858 erratum
Thread-Index: AcUKqcWH216Cr8gsSyGlF9FXK9rkggAH7Z8g
From: "Susan Hares" <[e-mail]>
To: "Tom Petch" <[e-mail]>, "idr" <[e-mail]>
X-Virus-Scanned: by amavisd-new at nexthop.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: 
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 KAA01946

Please do.  

Sue

-----Original Message-----
From: Tom Petch [mailto:[e-mail]] 
Sent: Friday, February 04, 2005 4:45 AM
To: idr
Subject: [Idr] RFC 2858 erratum

In RFC 2858, Multiprotocol Extensions for BGP-4, it says in

8. IANA Considerations

 "...  The SAFI name space is defined in Section 9...."

In fact, Section 9 is

9. Comparison with RFC 2283

I suspect this reference should be to Section 5 ie

5. Subsequent Address Family Identifier

The RFC editor pages list no errata for this RFC.  Are you ok if I
report this
to the
RFC Editor?

Tom Petch


_______________________________________________
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 JAA00772 for <[e-mail]>; Fri, 4 Feb 2005 09:37:45 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx4S0-0005FE-Ln; Fri, 04 Feb 2005 09:28:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx4Or-0004GL-JY for [e-mail]; Fri, 04 Feb 2005 09:25:33 -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 JAA00649 for <[e-mail]>; Fri, 4 Feb 2005 09:25:30 -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 1Cx4hc-0002uY-N6 for [e-mail]; Fri, 04 Feb 2005 09:44:58 -0500
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A17602D4C7E; Fri,  4 Feb 2005 09:24:59 -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 65024-01-69; Fri,  4 Feb 2005 09:24:57 -0500 (EST)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D83022D4BB6; Fri,  4 Feb 2005 09:24:57 -0500 (EST)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j14EOvv21740; Fri, 4 Feb 2005 09:24:57 -0500 (EST)
Date: Fri, 4 Feb 2005 09:24:57 +2244
From: Jeffrey Haas <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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: 1.7 (+)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
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]

On Mon, Mar 24, 1975 at 10:06:56AM -0800, Pedro Roque Marques wrote:
> The point is that it does. If ibgp transport between PE1 and PE2 uses
> the forwarding LSP between PE1 and PE2 then a silent (in control
> plane) forwarding failure will cause the BGP transport session to come
> down.

Right.  But this is a generic MP-BGP issue rather than one specific
to this particular protocol extention.

> > I will agree with you 100% that there are operational practices that
> > will provide better survivability in certain failure scenarios.  Do
> > these belong in this protocol extention?  Probably not.
> 
> I thought so... but i conceed that it is a matter of opinion.

I objected to the SHALL.  It sounds like you believe a SHOULD is the
solution.  Propose new text - that's what last call is all about. :-)

I wouldn't object to a SHOULD.

>   Pedro.

-- 
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 GAA23875 for <[e-mail]>; Fri, 4 Feb 2005 06:06: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 1Cx1Fc-000810-31; Fri, 04 Feb 2005 06:03:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx16B-00068b-OD for [e-mail]; Fri, 04 Feb 2005 05:54:03 -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 FAA12226 for <[e-mail]>; Fri, 4 Feb 2005 05:53:58 -0500 (EST)
Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx1Ot-0005KN-Ai for [e-mail]; Fri, 04 Feb 2005 06:13:24 -0500
Received: from pc6 (1Cust246.tnt28.lnd4.gbr.da.uu.net [62.188.156.246]) by astro.systems.pipex.net (Postfix) with SMTP id BA692E0000FF for <[e-mail]>; Fri,  4 Feb 2005 10:53:25 +0000 (GMT)
Message-ID: <025601c50a9f$1d4276a0$0601a8c0@pc6>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>
Date: Fri, 4 Feb 2005 10:45:18 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Subject: [Idr] RFC 2858 erratum
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tom Petch <[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 RFC 2858, Multiprotocol Extensions for BGP-4, it says in

8. IANA Considerations

 "...  The SAFI name space is defined in Section 9...."

In fact, Section 9 is

9. Comparison with RFC 2283

I suspect this reference should be to Section 5 ie

5. Subsequent Address Family Identifier

The RFC editor pages list no errata for this RFC.  Are you ok if I report this
to the
RFC Editor?

Tom Petch


_______________________________________________
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 RAA00516 for <[e-mail]>; Thu, 3 Feb 2005 17:36:12 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwpHY-00084y-M8; Thu, 03 Feb 2005 17:17:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwotn-0000qo-JT for [e-mail]; Thu, 03 Feb 2005 16:52:27 -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 QAA19392 for <[e-mail]>; Thu, 3 Feb 2005 16:52:25 -0500 (EST)
Received: from natint3.juniper.net ([66.129.224.36] helo=roque-bsd.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwpCQ-0007od-FQ for [e-mail]; Thu, 03 Feb 2005 17:11:43 -0500
Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id j13LpsX8037852; Thu, 3 Feb 2005 13:51:55 -0800 (PST) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id j13LpoLf037849; Thu, 3 Feb 2005 13:51:50 -0800 (PST)
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 3 Feb 2005 13:51:50 -0800
To: Jeffrey Haas <[e-mail]>
Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
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 writes:

> In at least one of the scenarios you have proposed - a label change
> fails to propagate - even running the same nexthop AF as your
> peering session wont protect you.

The point is that it does. If ibgp transport between PE1 and PE2 uses
the forwarding LSP between PE1 and PE2 then a silent (in control
plane) forwarding failure will cause the BGP transport session to come
down.

> I will agree with you 100% that there are operational practices that
> will provide better survivability in certain failure scenarios.  Do
> these belong in this protocol extention?  Probably not.

I thought so... but i conceed that it is a matter of opinion.

  Pedro.

_______________________________________________
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 RAA29790 for <[e-mail]>; Thu, 3 Feb 2005 17:16: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 1Cwoka-0003jM-Mx; Thu, 03 Feb 2005 16:42:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwoSt-0005wO-4R for [e-mail]; Thu, 03 Feb 2005 16:24:39 -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 QAA13450 for <[e-mail]>; Thu, 3 Feb 2005 16:24:36 -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 1CwolV-0005lw-Gq for [e-mail]; Thu, 03 Feb 2005 16:43:54 -0500
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id B887C2D4A11; Thu,  3 Feb 2005 16:24:01 -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 11793-02-87; Thu,  3 Feb 2005 16:24:00 -0500 (EST)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 8E38F2D4A10; Thu,  3 Feb 2005 16:24:00 -0500 (EST)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j13LO0a18851; Thu, 3 Feb 2005 16:24:00 -0500 (EST)
Date: Thu, 3 Feb 2005 16:24:00 -0500
From: Jeffrey Haas <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[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: 9ed51c9d1356100bce94f1ae4ec616a9
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]

Pedro,

On Thu, Feb 03, 2005 at 10:32:28AM -0800, Pedro Roque Marques wrote:
> But by using a next-hop that matches the transport, if there is a
> silent forwarding failure on the path (no control info), the BGP
> session will come down due to keepalive failure.

In at least one of the scenarios you have proposed - a label change
fails to propagate - even running the same nexthop AF as your
peering session wont protect you.

> As i mentioned, some networks have as a requirement that, iBGP VPN
> sessions are carried over the LSPs so that forwarding failures will
> also affect the control plane.

I will agree with you 100% that there are operational practices
that will provide better survivability in certain failure scenarios.
Do these belong in this protocol extention?  Probably not.

Did it belong in the base protocol specification?  Perhaps.
(And it might be there.  I haven't read 2547bis in some time.)

> If i remember correctly, you objected to the spec including a SHOULD
> "use next-hops in this way"... there is a reason to prefer one method
> of doing things. i.e. a justification.

No, my original objection was to the SHALL use them this way.
The response of the authors was essentially, "no, we didn't mean it
quite this way".

> Example: LDP LSP between 2 PEs; control plane is fine; some label
> change didn't get propagated down to the forwarding engines; traffic
> gets dropped sillently.

If this is a common event, it sounds like the implementation isn't very
robust.   Then again, one could simply run BFD across your LSP/tunnel
of choice and stop worrying about it. :-)

>   Pedro.

-- 
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 NAA22667 for <[e-mail]>; Thu, 3 Feb 2005 13: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 1CwlrR-00074L-57; Thu, 03 Feb 2005 13:37:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwlmq-00068P-TP for [e-mail]; Thu, 03 Feb 2005 13:33:05 -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 NAA24105 for <[e-mail]>; Thu, 3 Feb 2005 13:33:01 -0500 (EST)
Received: from natint3.juniper.net ([66.129.224.36] helo=roque-bsd.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwm5S-0007wt-3o for [e-mail]; Thu, 03 Feb 2005 13:52:19 -0500
Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id j13IWWX8037426; Thu, 3 Feb 2005 10:32:32 -0800 (PST) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id j13IWS5m037421; Thu, 3 Feb 2005 10:32:28 -0800 (PST)
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 3 Feb 2005 10:32:28 -0800
To: Jeffrey Haas <[e-mail]>
Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
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 writes:

> In this particular case, the MP-BGP nexthop is meant to serve as a
> way to select an LSP that will allow the each end of the VPN to
> reach the tunneled reachability.  The nexthop will select whether we
> try to use/create an LSP that is an IPv4 or an IPv6 LSP.

> If BGP was being used as the label distribution protocol for the LSP
> endpoints, I can see making a strong association between the BGP
> transport session and the MP-BGP reachability.  However, it is as
> likely (or more likely?) that a second protocol such as LDP or RSVP
> will be used to signal the LSP.

Jeff,
I don't agree with that line of reasoning. On ibgp, BGP is not used to
determine interior routing... some other protocol is.

But by using a next-hop that matches the transport, if there is a
silent forwarding failure on the path (no control info), the BGP
session will come down due to keepalive failure.

As i mentioned, some networks have as a requirement that, iBGP VPN
sessions are carried over the LSPs so that forwarding failures will
also affect the control plane.

> If implementors want to force the AF to match the transport session,
> nothing stops them from implementing it this way.  I believe that
> many implementations will do exactly that.

> I don't find a need to enforce this in the protocol given that some
> people will want to be able to do what I had commented on.

If i remember correctly, you objected to the spec including a SHOULD
"use next-hops in this way"... there is a reason to prefer one method
of doing things. i.e. a justification.

Then there is the question of should a standard allow as much freedom
as possible or nail down the most common option that implementations
should support and let vendors expand on top of this minimum common
set. There is no perfect answer to that.

>> It matters. If the type matches, i can forward the transport
>> session on top of the LSP and have it drop if the LSP goes
>> dead. Not everyone runs their BGP sessions this way, but some
>> network operators choose to do so... usually after past negative
>> experiences with sillent mpls forwarding failures.

> That's an interesting comment.  A labeled BGP route (or VPN route)
> is supposed to become unresolvable if there is no LSP to the
> end-point.  Perhaps I misunderstand you.

Example: LDP LSP between 2 PEs; control plane is fine; some label
change didn't get propagated down to the forwarding engines; traffic
gets dropped sillently.

Also, if LDP is used in "black-hole creation mode"
(a.k.a. independent-control) this kind of mismatch between control and
forwarding plane can occur quite easily.

  Pedro.

_______________________________________________
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 LAA17568 for <[e-mail]>; Thu, 3 Feb 2005 11:00:59 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwjEI-0006z9-OG; Thu, 03 Feb 2005 10:49:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwj0Y-0000QP-42 for [e-mail]; Thu, 03 Feb 2005 10:35:02 -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 KAA05129 for <[e-mail]>; Thu, 3 Feb 2005 10:34:59 -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 1CwjJ7-0001im-9M for [e-mail]; Thu, 03 Feb 2005 10:54:14 -0500
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7A25D2D53BE; Thu,  3 Feb 2005 10:29: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 73074-01-27; Thu,  3 Feb 2005 10:29:11 -0500 (EST)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 586282D4BCB; Thu,  3 Feb 2005 10:09:10 -0500 (EST)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j13F9A617761; Thu, 3 Feb 2005 10:09:10 -0500 (EST)
Date: Thu, 3 Feb 2005 10:09:10 -0500
From: Jeffrey Haas <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
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: b4a0a5f5992e2a4954405484e7717d8c
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]

Pedro,

On Wed, Feb 02, 2005 at 05:12:13PM -0800, Pedro Roque Marques wrote:
> imho transport and forwarding to next-hop should be tied together
> whenever possible.

I generally agree.

I specifically disagree in this case.

In this particular case, the MP-BGP nexthop is meant to serve as
a way to select an LSP that will allow the each end of the VPN to
reach the tunneled reachability.  The nexthop will select whether
we try to use/create an LSP that is an IPv4 or an IPv6 LSP.

If BGP was being used as the label distribution protocol for the LSP
endpoints, I can see making a strong association between the BGP
transport session and the MP-BGP reachability.  However, it is as likely
(or more likely?) that a second protocol such as LDP or RSVP will
be used to signal the LSP.  

> The standard example being a network with v4 and v6 forwarding /
> transport capabilities. Forwarding can break independently by AF. Using
> v4 transport for v6 next-hops can lead to undetected blackholes...

True.  This is why we will still have a IPv6-based IGP running along-side
our IPv6 label distribution protocol in most cases.  Normal BGP
nexthop resolution will continue to work.

> AF of NLRI has nothing to do w/ nexthop or transport. af of next-hop
> should correspond to transport.

But then you immediately say:

> >  When carrying information for a different address family
> > (e.g.  an ipv4 transport session carrying ipv6 reachability)
> 
> You really shouldn't do that. :-) It is allowed but frowned upon. The
> entire reason it is allowed is because some implementations wanted
> this "transition" mode as a way to ramp up... 

And the wording that I commented on precluded this sort of mechanism.

If implementors want to force the AF to match the transport session,
nothing stops them from implementing it this way.  I believe that 
many implementations will do exactly that.

I don't find a need to enforce this in the protocol given that some people
will want to be able to do what I had commented on.


> It matters. If the type matches, i can forward the transport session
> on top of the LSP and have it drop if the LSP goes dead. Not everyone
> runs their BGP sessions this way, but some network operators choose to
> do so... usually after past negative experiences with sillent mpls
> forwarding failures.

That's an interesting comment.  A labeled BGP route (or VPN route)
is supposed to become unresolvable if there is no LSP to the end-point.
Perhaps I misunderstand you.

>   Pedro.

-- 
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 UAA20122 for <[e-mail]>; Wed, 2 Feb 2005 20:16:00 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwVZi-0006FG-1S; Wed, 02 Feb 2005 20:14:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwVYA-0005mu-RI for [e-mail]; Wed, 02 Feb 2005 20:12: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 UAA04807 for <[e-mail]>; Wed, 2 Feb 2005 20:12:47 -0500 (EST)
Received: from natint3.juniper.net ([66.129.224.36] helo=roque-bsd.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwVqd-0001Ez-2g for [e-mail]; Wed, 02 Feb 2005 20:31:56 -0500
Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id j131CIX8035305; Wed, 2 Feb 2005 17:12:18 -0800 (PST) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id j131CEE3035302; Wed, 2 Feb 2005 17:12:14 -0800 (PST)
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 2 Feb 2005 17:12:13 -0800
To: Jeffrey Haas <[e-mail]>
Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid
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 writes:

> 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.

Sounds like a feature. :-)

imho transport and forwarding to next-hop should be tied together
whenever possible.

The standard example being a network with v4 and v6 forwarding /
transport capabilities. Forwarding can break independently by AF. Using
v4 transport for v6 next-hops can lead to undetected blackholes...

>  I.e. an
> IPv6 transport session will require IPv6 VPN-IPv6 nexthops and an
> IPv4 transport session will require IPv4 VPN-IPv4 nexthops.

I guess you mean an LSP identified by a IPvX address...
That would be desirable. yes.

> MP-BGP allows for different address families to be carried across
> the same BGP session regardless of the form of the transport
> session.

AF of NLRI has nothing to do w/ nexthop or transport. af of next-hop
should correspond to transport.

>  When carrying information for a different address family
> (e.g.  an ipv4 transport session carrying ipv6 reachability)

You really shouldn't do that. :-) It is allowed but frowned upon. The
entire reason it is allowed is because some implementations wanted
this "transition" mode as a way to ramp up... 

> it is
> necessary to configure additional information about the endpoints of
> the session for reachability calculations.

And necessary to keep in mind that forwarding may break silently.

>  This draft appears to
> try to preclude this option in some capacities for VPN-IPv6.

Good.

> 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.

It matters. If the type matches, i can forward the transport session
on top of the LSP and have it drop if the LSP goes dead. Not everyone
runs their BGP sessions this way, but some network operators choose to
do so... usually after past negative experiences with sillent mpls
forwarding failures.

cheers,
  Pedro.

_______________________________________________
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 QAA08302 for <[e-mail]>; Wed, 2 Feb 2005 16:09: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 1CwRKw-0000OX-9o; Wed, 02 Feb 2005 15:42:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwREt-0005SX-PE; Wed, 02 Feb 2005 15:36:39 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26251; Wed, 2 Feb 2005 15:36:35 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
From: [e-mail]
Date: Wed, 02 Feb 2005 15:36:35 -0500
Cc: [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-aspath-orf-07.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>
Sender: [e-mail]
Errors-To: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: Aspath Based Outbound Route Filter for BGP-4
	Author(s)	: K. Patel, S. Hares
	Filename	: draft-ietf-idr-aspath-orf-07.txt
	Pages		: 4
	Date		: 2005-2-2
	
This document defines a new Outbound Router Filter type for BGP,
termed 'Aspath Outbound Route Filter', that can be used to perform 
aspath based route filtering. This ORF-type supports aspath based 
route filtering as well as regular expression based matching, for 
address groups.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-aspath-orf-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-aspath-orf-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-aspath-orf-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-aspath-orf-07.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-idr-aspath-orf-07.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart
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

--NextPart--





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 RAA22132 for <[e-mail]>; Tue, 1 Feb 2005 17:29:25 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw6NW-00076V-D5; Tue, 01 Feb 2005 17:20:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw6GQ-0001pn-NG for [e-mail]; Tue, 01 Feb 2005 17:12:51 -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 RAA06801 for <[e-mail]>; Tue, 1 Feb 2005 17:12:48 -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 1Cw6Yf-0001yo-6l for [e-mail]; Tue, 01 Feb 2005 17:31:41 -0500
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id B2ED62D4A25; Tue,  1 Feb 2005 17:12:14 -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 70437-01-16; Tue,  1 Feb 2005 17:12:10 -0500 (EST)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 57EDC2D4873; Tue,  1 Feb 2005 17:12:10 -0500 (EST)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j11MC9Y11181; Tue, 1 Feb 2005 17:12:09 -0500 (EST)
Date: Tue, 1 Feb 2005 17:12:09 -0500
From: Jeffrey Haas <[e-mail]>
To: "Francois Le Faucheur (flefauch)" <[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: 769a46790fb42fbb0b0cc700c82f7081
Cc: [e-mail], [e-mail], Ronald Bonica <[e-mail]>, Ross Callon <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail], [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]

Francois,

On Tue, Feb 01, 2005 at 11:13:49AM +0100, Francois Le Faucheur (flefauch) wrote:
> 1) The following text:
> "
> 3.2.1 BGP Next Hop encoding
> The encoding of the BGP Next Hop depends on whether the IPv6 VPN reachability is advertised between BGP speakers using IPv6 connectivity (''BGP speakers with IPv6 connectivity'') or using IPv4 connectivity (''BGP speakers with IPv4 connectivity'').
> "
> be replaced by something like:
> "
> 3.2.1 BGP Next Hop encoding
> The encoding of the BGP Next Hop depends on whether the policy of the BGP Speaker is to request that IPv6 VPN traffic be transported to that BGP Next Hop using IPv6 tunneling (''BGP speaker requesting IPv6 transport'') or using IPv4 tunneling (''BGP speakers requesting IPv4 transport'').
> "

This seems reasonable.

> 2) The following text:
> "
> 3.2.1.1 BGP speakers with IPv6 connectivity
> When using IPv6 connectivity to the other BGP speaker for advertisement of the IPv6 VPN reachability, a BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address:
> "
> be replaced by something like:
> "
> 3.2.1.1 BGP speaker requesting IPv6 transport
> When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv6 tunneling (e.g. IPv6 MPLS LSPs, IPsec-protected IPv6 tunnels), the BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address:

Also reasonable.

> 3) The following text:
> "
> 3.2.1.2 BGP Speakers with IPv4 connectivity
> When using IPv4 connectivity to the other BGP speaker for advertisement of the IPv6 VPN reachability, a BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:
> "
> be replaced by something like:
> "
> 3.2.1.2 BGP Speakers requesting IPv4 transport
> When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv4 tunneling (e.g. IPv4 MPLS LSPs, IPsec-protected IPv4 tunnels), the BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:

Also good.

> Would those sort of changes address the problem?

I think that does it.


-- 
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 QAA18944 for <[e-mail]>; Tue, 1 Feb 2005 16:34:05 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw5C5-0002HZ-28; Tue, 01 Feb 2005 16:04:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw4xs-0004AX-9I; Tue, 01 Feb 2005 15:49:36 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18198; Tue, 1 Feb 2005 15:49:33 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
From: [e-mail]
Date: Tue, 01 Feb 2005 15:49:33 -0500
Cc: [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-ext-communities-08.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>
Sender: [e-mail]
Errors-To: [e-mail]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: BGP Extended Communities Attribute
	Author(s)	: S. Sangli, et al.
	Filename	: draft-ietf-idr-bgp-ext-communities-08.txt
	Pages		: 14
	Date		: 2005-2-1
	
This document describes an extension to BGP [BGP-4] which may be used
to provide flexible control over the distribution of routing
information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ext-communities-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp-ext-communities-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp-ext-communities-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp-ext-communities-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp-ext-communities-08.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--OtherAccess--

--NextPart
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

--NextPart--





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 MAA04398 for <[e-mail]>; Tue, 1 Feb 2005 12:20:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw1P1-0003Gv-6S; Tue, 01 Feb 2005 12:01:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw1JQ-0007U0-UB for [e-mail]; Tue, 01 Feb 2005 11:55: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 LAA24294 for <[e-mail]>; Tue, 1 Feb 2005 11:55:35 -0500 (EST)
Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw1bZ-0007Df-M7 for [e-mail]; Tue, 01 Feb 2005 12:14:25 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Date: Tue, 1 Feb 2005 16:54:41 -0000
Message-ID: <[e-mail]>
Thread-Topic: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Thread-Index: AcUH626fLuT9Fg5LQ5GCUuj9Tv0D/wAVe9qgAAS4A3AACRULQAABez0w
From: "Michael Dell" <[e-mail]>
To: "Francois Le Faucheur \(flefauch\)" <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6907f330301e69261fa73bed91449a20
Cc: NextHop - Susan Hares <[e-mail]>, [e-mail], Jeffrey Haas <[e-mail]>, Yakov Rekhter <[e-mail]>, Ross Callon <[e-mail]>, Ronald Bonica <[e-mail]>, [e-mail], [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 MAA04398

Francois

Thanks for the reply.  Yes, I think that it would be helpful to make it clear that it is up to the user/implementation to configure policy to define what the BGP next-hop should be.

On reflection, I would agree that defining how this should be configured is probably an implementation matter.

Mike Dell
Data Connection Ltd.

-----Original Message-----
From: Francois Le Faucheur (flefauch) [mailto:[e-mail]]
Sent: 01 February 2005 16:22
To: Michael Dell
Cc: NextHop - Susan Hares; [e-mail]; Yakov Rekhter; Ross Callon;
Ronald Bonica; [e-mail]; [e-mail]; Jeffrey
Haas; Francois Le Faucheur (flefauch)
Subject: RE: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04


Hello Michael,

>> -----Original Message-----
>> From: Michael Dell [mailto:[e-mail]] 
>> Sent: mardi 1 février 2005 13:14
>> To: Francois Le Faucheur (flefauch); Jeffrey Haas
>> Cc: NextHop - Susan Hares; [e-mail]; Yakov Rekhter; Ross 
>> Callon; Ronald Bonica; [e-mail]; [e-mail]
>> Subject: RE: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
>> 
>> Francois
>> 
>> I have a question about your proposed change to the BGP next 
>> hop encoding.
>> 
>> If I understand you correctly, you say that the way the BGP 
>> next hop of an IPv6-VPN route is constructed should not 
>> depend on the transport type of the BGP session between the 
>> speakers, but rather on the transport type of the tunnel 
>> over which data will be passed. 
>> 
>> For example, if the two speakers share an IPv6 BGP session, 
>> but will transport data over an IPv4 MPLS LSP, then the BGP 
>> next hop of an IPv6-VPN NLRI should be constructed from the 
>> IPv6-mapped IPv4 version of the advertising speaker's IPv4 
>> address (the egress address of the LSP), rather than its 
>> IPv6 address (the session's local address).

yes.
 
>> This sounds sensible, and probably what was originally 
>> intended.  However, I am uncertain how the BGP speaker is 
>> supposed to select which BGP next hop to use.  If two 
>> speakers with an IPv6 session are to forward data over an 
>> IPv4 tunnel, is it up to the user to configure policy so 
>> that the correct next hops are used when advertising routes 
>> to each other?  

Yes. That is the intent.
Should we add a clarifying sentence to that effect?

>> This could be achieved by some 
>> implementation specific policy to set the next-hop of VPNv6 
>> routes,

Right.

>> but should there perhaps be a more standardised way 
>> of defining how this should work, such as within the 
>> mplsL3VpnVrfTable MIB table?  (This is probably more a 
>> question for the L3VPN WG I guess).
 
I think this would be beyond the scope of draft-ietf-l3vpn-bgp-ipv6.
With respect to a specific MIB knob, I don't have the right expertise to follow it up, but it is not clear to me this would naturally map into as a single binary MIB knob since using IPv4 or IPv6 type Next Hop could be the resultant of several configuration knobs (eg "route map" forcing the nexthop).

Thanks

Francois

>> Regards
>> 
>> Mike Dell
>> Data Connection Ltd
>> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: 01 February 2005 10:14
>> To: Jeffrey Haas
>> Cc: NextHop - Susan Hares; [e-mail]; Francois Le Faucheur
>> (flefauch); Yakov Rekhter; Ross Callon; Ronald Bonica;
>> [e-mail]; [e-mail]
>> Subject: RE: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
>> 
>> 
>> Hello Jeffrey,
>> 
>> >> This draft ties the MP-BGP nexthop associated with VPN-IPv6 
>> >> reachability to the BGP Speaker's transport session type.
>> 
>> This was not the intent, but I looked back at the current 
>> text and I have to agree it precisely (and incorrectly) does that.
>> This needs to be fixed. How about the following sort of changes:
>> 
>> 
>> 1) The following text:
>> "
>> 3.2.1 BGP Next Hop encoding
>> The encoding of the BGP Next Hop depends on whether the IPv6 
>> VPN reachability is advertised between BGP speakers using 
>> IPv6 connectivity (''BGP speakers with IPv6 connectivity'') 
>> or using IPv4 connectivity (''BGP speakers with IPv4 connectivity'').
>> "
>> be replaced by something like:
>> "
>> 3.2.1 BGP Next Hop encoding
>> The encoding of the BGP Next Hop depends on whether the 
>> policy of the BGP Speaker is to request that IPv6 VPN 
>> traffic be transported to that BGP Next Hop using IPv6 
>> tunneling (''BGP speaker requesting IPv6 transport'') or 
>> using IPv4 tunneling (''BGP speakers requesting IPv4 transport'').
>> "
>> 
>> 
>> 2) The following text:
>> "
>> 3.2.1.1 BGP speakers with IPv6 connectivity
>> When using IPv6 connectivity to the other BGP speaker for 
>> advertisement of the IPv6 VPN reachability, a BGP speaker 
>> SHALL advertise a Next Hop Network Address field containing 
>> a VPN-IPv6 address:
>> "
>> be replaced by something like:
>> "
>> 3.2.1.1 BGP speaker requesting IPv6 transport
>> When the IPv6 VPN traffic is to be transported to the BGP 
>> speaker using IPv6 tunneling (e.g. IPv6 MPLS LSPs, 
>> IPsec-protected IPv6 tunnels), the BGP speaker SHALL 
>> advertise a Next Hop Network Address field containing a 
>> VPN-IPv6 address:
>> "
>> 
>> 
>> 3) The following text:
>> "
>> 3.2.1.2 BGP Speakers with IPv4 connectivity
>> When using IPv4 connectivity to the other BGP speaker for 
>> advertisement of the IPv6 VPN reachability, a BGP speaker 
>> SHALL advertise to its peer a Next Hop Network Address field 
>> containing a VPN-IPv6 address:
>> "
>> be replaced by something like:
>> "
>> 3.2.1.2 BGP Speakers requesting IPv4 transport
>> When the IPv6 VPN traffic is to be transported to the BGP 
>> speaker using IPv4 tunneling (e.g. IPv4 MPLS LSPs, 
>> IPsec-protected IPv4 tunnels), the BGP speaker SHALL 
>> advertise to its peer a Next Hop Network Address field 
>> containing a VPN-IPv6 address:
>> "
>> 
>> Would those sort of changes address the problem?
>> 
>> I will also re-read all the relevant text to try determine 
>> if additional changes are needed in other places. Please, 
>> let us know if you've already identified other text needing 
>> correction.
>> 
>> 
>> Thanks a lot for this comment.
>> 
>> Francois
>> 
>> 
>> >> -----Original Message-----
>> >> From: [e-mail] [mailto:[e-mail]] On 
>> >> Behalf Of Jeffrey Haas
>> >> Sent: mardi 1 février 2005 00:04
>> >> To: Yakov Rekhter
>> >> Cc: Ross Callon; [e-mail]; [e-mail]; 
>> >> [e-mail]; Ronald Bonica
>> >> Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
>> >> 
>> >> 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
>> >> 
>> 
>> _______________________________________________
>> 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 HAA17848 for <[e-mail]>; Tue, 1 Feb 2005 07:29:15 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvwzT-0005yM-He; Tue, 01 Feb 2005 07:18:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvwvh-0005IN-3A for [e-mail]; Tue, 01 Feb 2005 07:14:51 -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 HAA22199 for <[e-mail]>; Tue, 1 Feb 2005 07:14:47 -0500 (EST)
Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvxDp-0007um-Dw for [e-mail]; Tue, 01 Feb 2005 07:33:34 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Date: Tue, 1 Feb 2005 12:13:56 -0000
Message-ID: <[e-mail]>
Thread-Topic: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Thread-Index: AcUH626fLuT9Fg5LQ5GCUuj9Tv0D/wAVe9qgAAS4A3A=
From: "Michael Dell" <[e-mail]>
To: "[e-mail]" <[e-mail]>, "Jeffrey Haas" <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7
Cc: NextHop - Susan Hares <[e-mail]>, [e-mail], Yakov Rekhter <[e-mail]>, Ross Callon <[e-mail]>, Ronald Bonica <[e-mail]>, [e-mail], [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 HAA17848

Francois

I have a question about your proposed change to the BGP next hop encoding.

If I understand you correctly, you say that the way the BGP next hop of an IPv6-VPN route is constructed should not depend on the transport type of the BGP session between the speakers, but rather on the transport type of the tunnel over which data will be passed. 

For example, if the two speakers share an IPv6 BGP session, but will transport data over an IPv4 MPLS LSP, then the BGP next hop of an IPv6-VPN NLRI should be constructed from the IPv6-mapped IPv4 version of the advertising speaker's IPv4 address (the egress address of the LSP), rather than its IPv6 address (the session's local address).

This sounds sensible, and probably what was originally intended.  However, I am uncertain how the BGP speaker is supposed to select which BGP next hop to use.  If two speakers with an IPv6 session are to forward data over an IPv4 tunnel, is it up to the user to configure policy so that the correct next hops are used when advertising routes to each other?  This could be achieved by some implementation specific policy to set the next-hop of VPNv6 routes, but should there perhaps be a more standardised way of defining how this should work, such as within the mplsL3VpnVrfTable MIB table?  (This is probably more a question for the L3VPN WG I guess).

Regards

Mike Dell
Data Connection Ltd

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: 01 February 2005 10:14
To: Jeffrey Haas
Cc: NextHop - Susan Hares; [e-mail]; Francois Le Faucheur
(flefauch); Yakov Rekhter; Ross Callon; Ronald Bonica;
[e-mail]; [e-mail]
Subject: RE: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04


Hello Jeffrey,

>> This draft ties the MP-BGP nexthop associated with VPN-IPv6 
>> reachability to the BGP Speaker's transport session type.

This was not the intent, but I looked back at the current text and I have to agree it precisely (and incorrectly) does that.
This needs to be fixed. How about the following sort of changes:


1) The following text:
"
3.2.1 BGP Next Hop encoding
The encoding of the BGP Next Hop depends on whether the IPv6 VPN reachability is advertised between BGP speakers using IPv6 connectivity (''BGP speakers with IPv6 connectivity'') or using IPv4 connectivity (''BGP speakers with IPv4 connectivity'').
"
be replaced by something like:
"
3.2.1 BGP Next Hop encoding
The encoding of the BGP Next Hop depends on whether the policy of the BGP Speaker is to request that IPv6 VPN traffic be transported to that BGP Next Hop using IPv6 tunneling (''BGP speaker requesting IPv6 transport'') or using IPv4 tunneling (''BGP speakers requesting IPv4 transport'').
"


2) The following text:
"
3.2.1.1 BGP speakers with IPv6 connectivity
When using IPv6 connectivity to the other BGP speaker for advertisement of the IPv6 VPN reachability, a BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address:
"
be replaced by something like:
"
3.2.1.1 BGP speaker requesting IPv6 transport
When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv6 tunneling (e.g. IPv6 MPLS LSPs, IPsec-protected IPv6 tunnels), the BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address:
"


3) The following text:
"
3.2.1.2 BGP Speakers with IPv4 connectivity
When using IPv4 connectivity to the other BGP speaker for advertisement of the IPv6 VPN reachability, a BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:
"
be replaced by something like:
"
3.2.1.2 BGP Speakers requesting IPv4 transport
When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv4 tunneling (e.g. IPv4 MPLS LSPs, IPsec-protected IPv4 tunnels), the BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:
"

Would those sort of changes address the problem?

I will also re-read all the relevant text to try determine if additional changes are needed in other places. Please, let us know if you've already identified other text needing correction.


Thanks a lot for this comment.

Francois


>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On 
>> Behalf Of Jeffrey Haas
>> Sent: mardi 1 février 2005 00:04
>> To: Yakov Rekhter
>> Cc: Ross Callon; [e-mail]; [e-mail]; 
>> [e-mail]; Ronald Bonica
>> Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
>> 
>> 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
>> 

_______________________________________________
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 FAA10776 for <[e-mail]>; Tue, 1 Feb 2005 05:19:15 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvv6f-0007n8-2E; Tue, 01 Feb 2005 05:18:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvv3J-0007Mu-Rk for [e-mail]; Tue, 01 Feb 2005 05:14: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 FAA09921 for <[e-mail]>; Tue, 1 Feb 2005 05:14: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 1CvvLR-0004ln-Pf for [e-mail]; Tue, 01 Feb 2005 05:33:18 -0500
Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Feb 2005 11:23:52 +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 j11ADrPq027712;  Tue, 1 Feb 2005 11:13:58 +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);  Tue, 1 Feb 2005 11:13:46 +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] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Date: Tue, 1 Feb 2005 11:13:49 +0100
Message-ID: <[e-mail]>
Thread-Topic: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
Thread-Index: AcUH626fLuT9Fg5LQ5GCUuj9Tv0D/wAVe9qg
From: "Francois Le Faucheur \(flefauch\)" <[e-mail]>
To: "Jeffrey Haas" <[e-mail]>
X-OriginalArrivalTime: 01 Feb 2005 10:13:46.0476 (UTC) FILETIME=[B73B0AC0:01C50846]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
Cc: [e-mail], [e-mail], "Francois Le Faucheur \(flefauch\)" <[e-mail]>, Yakov Rekhter <[e-mail]>, Ross Callon <[e-mail]>, Ronald Bonica <[e-mail]>, [e-mail], [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 FAA10776

Hello Jeffrey,

>> This draft ties the MP-BGP nexthop associated with VPN-IPv6 
>> reachability to the BGP Speaker's transport session type.

This was not the intent, but I looked back at the current text and I have to agree it precisely (and incorrectly) does that.
This needs to be fixed. How about the following sort of changes:


1) The following text:
"
3.2.1 BGP Next Hop encoding
The encoding of the BGP Next Hop depends on whether the IPv6 VPN reachability is advertised between BGP speakers using IPv6 connectivity (''BGP speakers with IPv6 connectivity'') or using IPv4 connectivity (''BGP speakers with IPv4 connectivity'').
"
be replaced by something like:
"
3.2.1 BGP Next Hop encoding
The encoding of the BGP Next Hop depends on whether the policy of the BGP Speaker is to request that IPv6 VPN traffic be transported to that BGP Next Hop using IPv6 tunneling (''BGP speaker requesting IPv6 transport'') or using IPv4 tunneling (''BGP speakers requesting IPv4 transport'').
"


2) The following text:
"
3.2.1.1 BGP speakers with IPv6 connectivity
When using IPv6 connectivity to the other BGP speaker for advertisement of the IPv6 VPN reachability, a BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address:
"
be replaced by something like:
"
3.2.1.1 BGP speaker requesting IPv6 transport
When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv6 tunneling (e.g. IPv6 MPLS LSPs, IPsec-protected IPv6 tunnels), the BGP speaker SHALL advertise a Next Hop Network Address field containing a VPN-IPv6 address:
"


3) The following text:
"
3.2.1.2 BGP Speakers with IPv4 connectivity
When using IPv4 connectivity to the other BGP speaker for advertisement of the IPv6 VPN reachability, a BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:
"
be replaced by something like:
"
3.2.1.2 BGP Speakers requesting IPv4 transport
When the IPv6 VPN traffic is to be transported to the BGP speaker using IPv4 tunneling (e.g. IPv4 MPLS LSPs, IPsec-protected IPv4 tunnels), the BGP speaker SHALL advertise to its peer a Next Hop Network Address field containing a VPN-IPv6 address:
"

Would those sort of changes address the problem?

I will also re-read all the relevant text to try determine if additional changes are needed in other places. Please, let us know if you've already identified other text needing correction.


Thanks a lot for this comment.

Francois


>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On 
>> Behalf Of Jeffrey Haas
>> Sent: mardi 1 février 2005 00:04
>> To: Yakov Rekhter
>> Cc: Ross Callon; [e-mail]; [e-mail]; 
>> [e-mail]; Ronald Bonica
>> Subject: Re: [Idr] Last Call on draft-ietf-l3vpn-bgp-ipv6-04
>> 
>> 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
>> 

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