Re: [Idr] Re: 4-Byte As Number soon to come?

["Joel M. Halpern" <[e-mail]>]

Given that path prepending is the primary (arguably the only) way for an 
advertiser to express provider preference in a way visible to information 
receivers, it seems that AS Path length is still our primary knob.

This would suggest that having routers along a path change the AS Path 
length of advertisements they have (potentially shortening the length) 
would be a very bad thing.

It was precisely to avoid such misleading effects that we introduced the 
series of AS Sets.

Yours,
Joel M. Halpern

At 11:47 AM 8/31/2005, Jeffrey Haas wrote:
>On Tue, Aug 30, 2005 at 06:57:58PM +0100, Paul Jakma wrote:
> > One comment I forgot to make, I strongly would recommend against
> > considering allowing adjacent AS_SET's to be packed together.
>
>The current bgp draft has already gone past last call.  Lots of
>people implement this already:
>
>             - for each pair of adjacent tuples in the aggregated
>             AS_PATH, if both tuples have the same type, merge them
>             together, as long as doing so will not cause a segment with
>             length greater than 255 to be generated.
>
>Proposals that want to leave sets in disjoint segments don't have a lot
>of hope of having their segments unmerged in many implementations
>under conditions of another aggregation.  I'd strongly suggest that
>another path be considered for implementing the desired feature.
>
>General comment on path length:
>
>While path length was commonly implemented in many versions of BGP
>post RFC 1771, it wasn't in the spec for a very long time.  The behavior
>of having an AS_SET count as 1 towards the length per segment is
>relatively new.
>
>In general, as long as an AS consistently applies BGP tie breaking,
>you can calculate the length however you like.  You simply must follow
>the path loop detection mechanisms (check for your AS on ingress,
>prepend your AS on egress) and the rest of the Internet can construct
>a loop free topology.
>
>While path length has certainly served as a very big knob to allow
>for one form of traffic engineering, I think it's generally understood
>that this relies on the kindness of operators to let path length
>influence things as much as they do.
>
>
>--
>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 XAA20613 for <[e-mail]>; Wed, 31 Aug 2005 23:06:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAfPR-0005RD-AS; Wed, 31 Aug 2005 23:06:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAfPP-0005R5-6s for [e-mail]; Wed, 31 Aug 2005 23:06:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04553 for <[e-mail]>; Wed, 31 Aug 2005 23:06:31 -0400 (EDT)
Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAfRD-0004PC-0R for [e-mail]; Wed, 31 Aug 2005 23:08:30 -0400
Received: from [162.84.77.203] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12128379; Wed, 31 Aug 2005 23:05:55 -0400
Message-Id: <6.2.1.2.0.20050831230250.02ee26b0@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Wed, 31 Aug 2005 23:05:51 -0400
To: Jeffrey Haas <[e-mail]>, Paul Jakma <[e-mail]>
From: "Joel M. Halpern" <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
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]

Given that path prepending is the primary (arguably the only) way for an 
advertiser to express provider preference in a way visible to information 
receivers, it seems that AS Path length is still our primary knob.

This would suggest that having routers along a path change the AS Path 
length of advertisements they have (potentially shortening the length) 
would be a very bad thing.

It was precisely to avoid such misleading effects that we introduced the 
series of AS Sets.

Yours,
Joel M. Halpern

At 11:47 AM 8/31/2005, Jeffrey Haas wrote:
>On Tue, Aug 30, 2005 at 06:57:58PM +0100, Paul Jakma wrote:
> > One comment I forgot to make, I strongly would recommend against
> > considering allowing adjacent AS_SET's to be packed together.
>
>The current bgp draft has already gone past last call.  Lots of
>people implement this already:
>
>             - for each pair of adjacent tuples in the aggregated
>             AS_PATH, if both tuples have the same type, merge them
>             together, as long as doing so will not cause a segment with
>             length greater than 255 to be generated.
>
>Proposals that want to leave sets in disjoint segments don't have a lot
>of hope of having their segments unmerged in many implementations
>under conditions of another aggregation.  I'd strongly suggest that
>another path be considered for implementing the desired feature.
>
>General comment on path length:
>
>While path length was commonly implemented in many versions of BGP
>post RFC 1771, it wasn't in the spec for a very long time.  The behavior
>of having an AS_SET count as 1 towards the length per segment is
>relatively new.
>
>In general, as long as an AS consistently applies BGP tie breaking,
>you can calculate the length however you like.  You simply must follow
>the path loop detection mechanisms (check for your AS on ingress,
>prepend your AS on egress) and the rest of the Internet can construct
>a loop free topology.
>
>While path length has certainly served as a very big knob to allow
>for one form of traffic engineering, I think it's generally understood
>that this relies on the kindness of operators to let path length
>influence things as much as they do.
>
>
>--
>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 QAA17210 for <[e-mail]>; Wed, 31 Aug 2005 16:30:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAZCZ-0003Lt-3J; Wed, 31 Aug 2005 16:28:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAZCW-0003KT-Gu for [e-mail]; Wed, 31 Aug 2005 16:28:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13566 for <[e-mail]>; Wed, 31 Aug 2005 16:28:50 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/WtWC0+JQO/lbZLJEs30VGmCMRedFlBAo=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAZEG-0001QL-Vi for [e-mail]; Wed, 31 Aug 2005 16:30:45 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7VKSVJO003760; Wed, 31 Aug 2005 21:28:43 +0100
Date: Wed, 31 Aug 2005 21:28:31 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Jeffrey Haas <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
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 Wed, 31 Aug 2005, Jeffrey Haas wrote:

> I agree.  That said, I think the mechanism as proposed is fine. At 
> this point, it has implementations.  Consensus is rough, code is 
> running and the Internet runs.

Yes, that is indeed a good reason to leave the mechanism and encoding 
in as4bytes unchanged.

> Having a complete rewrite of the BGP spec for the next time we go 
> through a major document update that is clearer is certainly an 
> option.  However, I'd suggest reviewing the time frame of the 
> current update for an idea how long that sort of effort will take.

I think we're talking at cross-purposes possibly.

For case where a speaker does route-aggregation, it should merge. 
That's what the RFC says it should do, so that's what it should. I'm 
not referring to that, though I think possibly you think i am ;).

I meant the case where a speaker advertises on a route - not doing 
aggregation at all. The current draft does not specify that speakers 
in such a case may or should merge adjacent sets.

It seems there is at least differing opinion on whether this is 
allowed or not, possibly differing implementation too. It'd be nice 
to iron this out. It'll affect one of the two possible classes of 
implementations, but then it affects route-selection between them 
anyway.

> For loop prevention purposes, it's not important.

ACK.

> For path length calculation, it's locally important.

> For inter-domain behavior, it may affect route selection.  There
> are situations (aggregation) where this may Just Happen.  Counting
> on it to not happen is probably a bad idea.

ACK.

We could at least decide which way to go though and remove the scope 
for differing interpretations. You posed this very question a few 
years ago here on IDR I think.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
One Bell System - it used to work before they installed the Dimension!

_______________________________________________
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 PAA16685 for <[e-mail]>; Wed, 31 Aug 2005 15:28:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAYDv-0000Wd-1Y; Wed, 31 Aug 2005 15:26:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAYDt-0000WY-Qb for [e-mail]; Wed, 31 Aug 2005 15:26:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08180 for <[e-mail]>; Wed, 31 Aug 2005 15:26:11 -0400 (EDT)
Received: from web60712.mail.yahoo.com ([209.73.178.215]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EAYFY-0007A1-Uy for [e-mail]; Wed, 31 Aug 2005 15:28:06 -0400
Received: (qmail 15197 invoked by uid 60001); 31 Aug 2005 19:25:50 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BHyW1ZckAkaDeKmV3+vHl9e/3A4RCtE5FgS4rHlMDRZyOfE325M7xh878cVwlznThBKqHZCHeI4cCJNHNXsE0/fzfrdqTN/fMSK5fwIZOdkcPZ43jQY78ubj5/wbu9ljhvz8qsPBAIjRn/ENKm7Q8Bpc+YRkPZlfFJC3x/pa3VA= ; 
Message-ID: <[e-mail]>
Received: from [202.144.106.189] by web60712.mail.yahoo.com via HTTP; Wed, 31 Aug 2005 15:25:50 EDT
Date: Wed, 31 Aug 2005 15:25:50 -0400 (EDT)
From: Tulip Rasputin <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
To: Jeffrey Haas <[e-mail]>, Paul Jakma <[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.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
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]

> For inter-domain behavior, it may affect route selection.  There
> are situations (aggregation) where this may Just Happen.  Counting
> on it to not happen is probably a bad idea.

As long as the collapsing of SETs is done only by the speaker performing aggregation, proposals
that want to utilize disjoint SET segments have no reason to fret about. This is because the act
of aggregation is akin to generating a new route.

The authors of such proposals would be in a better position to comment though.

Tulip



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.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 PAA16426 for <[e-mail]>; Wed, 31 Aug 2005 15:00:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAXlS-0000uq-HK; Wed, 31 Aug 2005 14:56:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAXlP-0000ul-UY for [e-mail]; Wed, 31 Aug 2005 14:56:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05833 for <[e-mail]>; Wed, 31 Aug 2005 14:56:45 -0400 (EDT)
Received: from gateout01.mbox.net ([165.212.64.21] helo=gwo1.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAXnC-0006LT-H2 for [e-mail]; Wed, 31 Aug 2005 14:58:39 -0400
Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gwo1.mbox.net (Postfix) with SMTP id F140412D67B; Wed, 31 Aug 2005 18:56:08 +0000 (GMT)
Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.25R)  with ESMTP id 593JHEs5g0260Mo1; Wed, 31 Aug 2005 18:56:07 GMT
Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.25R)  with ESMTP id 592JHEs5F0237Mo1; Wed, 31 Aug 2005 18:56:05 GMT
X-USANET-Routed: 2 gwsout-vs R:localhost:1825
Received: from gw3.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.21U); Wed, 31 Aug 2005 18:56:05 GMT
X-USANET-Source: 165.212.116.254 IN   [e-mail] gw3.EXCHPROD.USA.NET
X-USANET-MsgId: XID858JHEs5F0045Xo1
Received: from localhost ([65.247.36.31]) by gw3.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211);  Wed, 31 Aug 2005 12:56:05 -0600
Date: Wed, 31 Aug 2005 14:56:04 -0400
From: Jeffrey Haas <[e-mail]>
To: Paul Jakma <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav> <[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-OriginalArrivalTime: 31 Aug 2005 18:56:05.0317 (UTC) FILETIME=[A3CBEF50:01C5AE5D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
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 Wed, Aug 31, 2005 at 07:44:33PM +0100, Paul Jakma wrote:
> It's not terribly important no though, but if we had the chance be 
> nice to reduce the sillyness of encoding 2 words of information in 
> 20.

Nice, yes.  In this case, This is the Wrong Tool.

Now, if you want to argue that this is more likely to happen in the future,
the nice researchers on GROW will be interested. :-)

> Or you could have the net simply transition to the new type. The old 
> type just dies out with the OLD speakers. No difference.
> 
> In either case, be it transitioning to new type code or transitioning 
> to a new as-path but reusing the type code, you're transitioning and 
> dropping support for the old. No difference really.

I agree.  That said, I think the mechanism as proposed is fine.
At this point, it has implementations.  Consensus is rough, code is
running and the Internet runs. 

> It'd be nice to make this part of the definition of the actual 
> AS_PATH attribute, rather than having various properties of AS_PATHs 
> be inferred from reading various other bits of a text.

Indeed.

Having a complete rewrite of the BGP spec for the next time we go
through a major document update that is clearer is certainly an
option.  However, I'd suggest reviewing the time frame of the
current update for an idea how long that sort of effort will take.

> The question is whether speakers are allowed to merge adjacent 
> AS_SET's in paths which they are /not/ aggregating but simply passing 
> along.

For loop prevention purposes, it's not important.
For path length calculation, it's locally important.
For inter-domain behavior, it may affect route selection.  There
are situations (aggregation) where this may Just Happen.  Counting
on it to not happen is probably a bad idea.


-- 
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 OAA16284 for <[e-mail]>; Wed, 31 Aug 2005 14:45:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAXa8-0005u3-M3; Wed, 31 Aug 2005 14:45:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAXa4-0005tL-RP for [e-mail]; Wed, 31 Aug 2005 14:45:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05318 for <[e-mail]>; Wed, 31 Aug 2005 14:45:02 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1++E2bRMFmkI7cMQB87WmNbdvRqiQ1uCuY=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAXbp-00060v-Ed for [e-mail]; Wed, 31 Aug 2005 14:46:56 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7VIiXfs002547; Wed, 31 Aug 2005 19:44:46 +0100
Date: Wed, 31 Aug 2005 19:44:33 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Jeffrey Haas <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
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 Wed, 31 Aug 2005, Jeffrey Haas wrote:

> My Conclusions:

> A length of 255 isn't a problem right now, except with respect to 
> implementation bugs for segment overflow. :-)

Yes, I agree actually. It's not important now.

> Prepending encoding would introduce additional overhead, not
> reduce it from an encoding standpoint.

I don't quite see how, as it can be encoded in two words of data, 
always. A prepend using a sequence takes the same for first prepend. 
A word per ASN after that.

Here's what I see from my limited corner of the world:

prepended: 2, 497
prepended: 3, 360
prepended: 4, 581
prepended: 5, 103
prepended: 6, 168
prepended: 7, 44
prepended: 8, 18
prepended: 9, 19
prepended: 10, 28
prepended: 11, 19
prepended: 12, 0
prepended: 13, 1
prepended: 14, 1
prepended: 15, 1
prepended: 16, 1

Out of ~26k prefixes I receive. 28 distinct paths which have 10-ASN 
prepends. Even *16* ASN prepends :).

It's not terribly important no though, but if we had the chance be 
nice to reduce the sillyness of encoding 2 words of information in 
20.

> I'm of mixed opinion on overloading the existing mechanism 
> depending on the behavior of the speaker as a 2-byte or 4-byte 
> speaker.  It certainly had to be accounted for in the bgp v2 mib.

> I do like the fact that after the majority of the Net transitions 
> to as4bytes that we're not carrying duplicate information.  As a 
> transitional mechanism, IMO, it's good.

Or you could have the net simply transition to the new type. The old 
type just dies out with the OLD speakers. No difference.

In either case, be it transitioning to new type code or transitioning 
to a new as-path but reusing the type code, you're transitioning and 
dropping support for the old. No difference really.

>      a) Remove from consideration all routes which are not tied for
>      having the smallest number of AS numbers present in their AS_PATH
>      attributes. Note, that when counting this number, an AS_SET counts
>      as 1, no matter how many ASs are in the set.

That's part of the text on route-selection though. It affects how 
route-selection works.

It'd be nice to make this part of the definition of the actual 
AS_PATH attribute, rather than having various properties of AS_PATHs 
be inferred from reading various other bits of a text.

>> - clarifying text on segment packing in AS_PATH
>

> I've previously posted on this.  I believe the arguments being made 
> aren't a call for clarification, it's a call to change the behavior 
> so that tuples aren't merged as a side effect of aggregation.

As a side-effect of aggregation - fine. Aggregation /specifies/ that, 
and the AS_SET introduced is created by the speaker concerned.

The question is whether speakers are allowed to merge adjacent 
AS_SET's in paths which they are /not/ aggregating but simply passing 
along.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
"Eww, Daddy, this tastes like Gramma!"

 	--Ralph Wiggum
 	  E-I-E-I-(ANNOYED GRUNT) (Episode AABF19)

_______________________________________________
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 OAA16005 for <[e-mail]>; Wed, 31 Aug 2005 14:10:53 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAWwZ-0000WH-B4; Wed, 31 Aug 2005 14:04:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAWwY-0000W1-95 for [e-mail]; Wed, 31 Aug 2005 14:04:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03458 for <[e-mail]>; Wed, 31 Aug 2005 14:04:12 -0400 (EDT)
Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EAWyK-0004oZ-Ad for [e-mail]; Wed, 31 Aug 2005 14:06:05 -0400
Received: (qmail 10420 invoked from network); 31 Aug 2005 18:03:58 -0000
Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 31 Aug 2005 18:03:58 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j7VI354Z066999; Wed, 31 Aug 2005 14:03:05 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Glen Kent <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come? 
In-reply-to: Your message of "Wed, 31 Aug 2005 23:11:34 +0530." <[e-mail]> 
Date: Wed, 31 Aug 2005 14:03:05 -0400
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: [e-mail], Jeffrey Haas <[e-mail]>, Paul Jakma <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
Glen Kent writes:
>  
> >=20
> > > The current bgp draft has already gone past last call. Lots of
> > > people implement this already:
> >=20
> > > - for each pair of adjacent tuples in the aggregated
> > > AS_PATH, if both tuples have the same type, merge them
> > > together, as long as doing so will not cause a segment with
> > > length greater than 255 to be generated.
>  
>  This is going to break a lot of implementations out there in the field. I=
> =20
> am aware of atleast 3, all widely deployed, that will get affected with=20
> this. There are then many others who have taken the stack from one of these=
> =20
> that will get affected.
>  What do we gain out of this anyways?
>  Glen.
> Glen.


Mr Glen Glen,

What exactly do you think will break?  As Jeff pointed out and you
chopped off, the AS_SET counting as 1 is new and as long as the same
thing is done in any one AS things work.  The implication for cutover
is that new software needs an option to coexist with old software.
When all new software is installed a few flag seconds (not a flag day)
is needed to disable that old behaviour.  At worst a few routes will
have inconsistent decisions for a few seconds and its a one time
transition.  Other vendors with new BGP implementations would have to
have the same option but being "bug for bug compatible" with the
incumbent has always been an aspect of this business.

Curtis

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA15981 for <[e-mail]>; Wed, 31 Aug 2005 14:06:13 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAWw0-0000JK-Hi; Wed, 31 Aug 2005 14:03:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAWvz-0000JC-Pe for [e-mail]; Wed, 31 Aug 2005 14:03:39 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03404 for <[e-mail]>; Wed, 31 Aug 2005 14:03:37 -0400 (EDT)
Received: from gateout01.mbox.net ([165.212.64.21] helo=gwo1.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAWxk-0004nk-NT for [e-mail]; Wed, 31 Aug 2005 14:05:31 -0400
Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gwo1.mbox.net (Postfix) with SMTP id 765E612D465; Wed, 31 Aug 2005 18:03:21 +0000 (GMT)
Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.25R)  with ESMTP id 175JHEsDT0073Mo1; Wed, 31 Aug 2005 18:03:19 GMT
Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.25R)  with ESMTP id 170JHEsDs0126Mo1; Wed, 31 Aug 2005 18:03:18 GMT
X-USANET-Routed: 2 gwsout-vs R:localhost:1825
Received: from gw1.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.21U); Wed, 31 Aug 2005 18:03:18 GMT
X-USANET-Source: 165.212.116.254 IN   [e-mail] gw1.EXCHPROD.USA.NET
X-USANET-MsgId: XID090JHEsDs9855Xo1
Received: from localhost ([65.247.36.31]) by gw1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211);  Wed, 31 Aug 2005 12:03:16 -0600
Date: Wed, 31 Aug 2005 14:03:15 -0400
From: Jeffrey Haas <[e-mail]>
To: Glen Kent <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav> <[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-OriginalArrivalTime: 31 Aug 2005 18:03:16.0673 (UTC) FILETIME=[43233B10:01C5AE56]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

On Wed, Aug 31, 2005 at 11:11:34PM +0530, Glen Kent wrote:
> > > The current bgp draft has already gone past last call. Lots of
> > > people implement this already:
> > 
> > > - for each pair of adjacent tuples in the aggregated
> > > AS_PATH, if both tuples have the same type, merge them
> > > together, as long as doing so will not cause a segment with
> > > length greater than 255 to be generated.
> 
>  This is going to break a lot of implementations out there in the field.

A lot of implementations of what?

-- 
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 OAA15970 for <[e-mail]>; Wed, 31 Aug 2005 14:04:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAWsl-0008FX-Hc; Wed, 31 Aug 2005 14:00:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAWsj-0008FO-SD for [e-mail]; Wed, 31 Aug 2005 14:00:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03255 for <[e-mail]>; Wed, 31 Aug 2005 14:00:16 -0400 (EDT)
Received: from gateout02.mbox.net ([165.212.64.22] helo=gwo2.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAWuU-0004gK-5T for [e-mail]; Wed, 31 Aug 2005 14:02:09 -0400
Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gwo2.mbox.net (Postfix) with SMTP id B9C3C1638A1 for <[e-mail]>; Wed, 31 Aug 2005 17:59:50 +0000 (GMT)
Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.25R)  with ESMTP id 870JHER8x0402Mo2; Wed, 31 Aug 2005 17:59:49 GMT
Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.25R)  with ESMTP id 869JHER8W0102Mo2; Wed, 31 Aug 2005 17:59:48 GMT
X-USANET-Routed: 2 gwsout-vs R:localhost:1825
Received: from gw3.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.21U); Wed, 31 Aug 2005 17:59:48 GMT
X-USANET-Source: 165.212.116.254 IN   [e-mail] gw3.EXCHPROD.USA.NET
X-USANET-MsgId: XID373JHER8W3077Xo2
Received: from localhost ([65.247.36.31]) by gw3.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211);  Wed, 31 Aug 2005 11:59:48 -0600
Date: Wed, 31 Aug 2005 13:59:47 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav> <[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-OriginalArrivalTime: 31 Aug 2005 17:59:48.0173 (UTC) FILETIME=[C6DCA7D0:01C5AE55]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
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 Tue, Aug 30, 2005 at 06:39:54PM +0100, Paul Jakma wrote:
> Of that change itself, yes, I agree. But it's one of several little 
> nits, other than sizeof(ASN), which I think ideally ought to be taken 
> care of if AS_PATH is revised, some of those nits being:
> 
> - inefficient encoding of prepends
> - 255 length limit

Your data may vary.  I encourage those with an interest in the matter
(I suspect them to be few :-) to run their own numbers.
This is from my local set:

Total distinct AS Paths in local database: 105887
Total paths containing an AS_SET: 110
Distribution of path length in local database:

   2:     11
   3:    699
   4:  25740
   5:  37612
   6:  25205
   7:   8766
   8:   3218
   9:   1628
  10:    921
  11:    664
  12:    527
  13:    301
  14:    213
  15:    172
  16:     89
  17:     52
  18:     27
  19:     16
  20:      6
  21:      9
  22:      3
  26:      3
  27:      1

I haven't done the distribution correlation against that observed by
well known researchers, but the majority is between 4-6, which is
what I'd expect considering that my feeds are not from the core.
Data from sources such as route-views may be interesting.

84% of the data set is <= 6.

Number of bytes to represent a sequence of 6 2-byte ASes: 14

Number of bytes to represent the same sequence presuming 0 prepends
and 2 byte ASes using a tuple of <1byte count, 2byte AS>: 20.

This is 30% overhead.

Of related interest, the number of distinct paths that have prepending
(represented by the occurence of a given AS more than once):
14254, representing 13.5% of the data set.

Distribution of prepended ASes:
   4:     68
   5:   1512
   6:   3125
   7:   2882
   8:   2213
   9:   1473
  10:    898
  11:    664
  12:    527
  13:    301
  14:    213
  15:    172
  16:     89
  17:     52
  18:     27
  19:     16
  20:      6
  21:      9
  22:      3
  26:      3
  27:      1

1/3 of the prepended ASes are within <= length 6.

My Conclusions:
A length of 255 isn't a problem right now, except with respect
to implementation bugs for segment overflow. :-)

Prepending encoding would introduce additional overhead, not
reduce it from an encoding standpoint.

> - using the new NEW_AS_PATH type for NEW speakers, rather than
>   overloading the existing AS_PATH type

I'm of mixed opinion on overloading the existing mechanism depending
on the behavior of the speaker as a 2-byte or 4-byte speaker.  It
certainly had to be accounted for in the bgp v2 mib.  I do like the
fact that after the majority of the Net transitions to as4bytes that
we're not carrying duplicate information.  As a transitional mechanism,
IMO, it's good.

> - clarifying effect on path-length of AS_SET and AS_SEQUENCE in the
>   definition of AS_PATH itself (currently, it's not specified in the
>   definition itself, but elsewhere in the BGP-4 draft.)

I think it's pretty clear:

      a) Remove from consideration all routes which are not tied for
      having the smallest number of AS numbers present in their AS_PATH
      attributes. Note, that when counting this number, an AS_SET counts
      as 1, no matter how many ASs are in the set.

> - clarifying text on segment packing in AS_PATH

I've previously posted on this.  I believe the arguments being made
aren't a call for clarification, it's a call to change the behavior
so that tuples aren't merged as a side effect of aggregation.

-- 
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 NAA15729 for <[e-mail]>; Wed, 31 Aug 2005 13:43:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAWaq-0002L2-Qa; Wed, 31 Aug 2005 13:41:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAWao-0002I0-Tz for [e-mail]; Wed, 31 Aug 2005 13:41:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02375 for <[e-mail]>; Wed, 31 Aug 2005 13:41:45 -0400 (EDT)
Received: from zproxy.gmail.com ([64.233.162.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAWcb-00047Z-1M for [e-mail]; Wed, 31 Aug 2005 13:43:38 -0400
Received: by zproxy.gmail.com with SMTP id i1so1018942nzh for <[e-mail]>; Wed, 31 Aug 2005 10:41:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=syMQNGC4g1qnn4MgLkQkoCIIas+iigtfpwszuQtJYlG/R9+dSKvLOK9baxlAbSUzM4z0NPYJzOra6jJZcTKyrHbJeNMtANikpswkBUQfzanWR+hUCzpXlolJSK3vznCsB09rX69JA/sjKQ4pehAnFKKYrhjNovUKPV2UI4kEFqo=
Received: by 10.36.118.18 with SMTP id q18mr621559nzc; Wed, 31 Aug 2005 10:41:34 -0700 (PDT)
Received: by 10.36.119.9 with HTTP; Wed, 31 Aug 2005 10:41:34 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 31 Aug 2005 23:11:34 +0530
From: Glen Kent <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
References: <[e-mail]> <[e-mail]> <[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: [e-mail], Paul Jakma <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1851877030=="
Sender: [e-mail]
Errors-To: [e-mail]

--===============1851877030==
Content-Type: multipart/alternative; 
	boundary="----=_Part_4398_9084944.1125510094238"

------=_Part_4398_9084944.1125510094238
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

>=20
> > The current bgp draft has already gone past last call. Lots of
> > people implement this already:
>=20
> > - for each pair of adjacent tuples in the aggregated
> > AS_PATH, if both tuples have the same type, merge them
> > together, as long as doing so will not cause a segment with
> > length greater than 255 to be generated.

 This is going to break a lot of implementations out there in the field. I=
=20
am aware of atleast 3, all widely deployed, that will get affected with=20
this. There are then many others who have taken the stack from one of these=
=20
that will get affected.
 What do we gain out of this anyways?
 Glen.
Glen.

------=_Part_4398_9084944.1125510094238
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<div>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">&gt; The current bgp draft has a=
lready gone past last call.&nbsp;&nbsp;Lots of<br>&gt; people implement thi=
s already:
<br><br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - =
for each pair of adjacent tuples in the aggregated<br>&gt;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AS_PATH, if both tuples have th=
e same type, merge them<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; together, as long as doing so will not cause a segment wit=
h
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; length=
 greater than 255 to be generated.</blockquote>
<div>&nbsp;</div>
<div>This is going to break a lot of implementations out there in the field=
. I am aware of atleast 3, all widely deployed, that will get affected with=
 this. There are then many others who have taken the stack from one of thes=
e that will&nbsp;get affected.
</div>
<div>&nbsp;</div>
<div>What do we gain out of this anyways?</div>
<div>&nbsp;</div>
<div>Glen.</div>
<div>Glen.</div>
<div>&nbsp;</div></div>

------=_Part_4398_9084944.1125510094238--


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

--===============1851877030==--



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 LAA14768 for <[e-mail]>; Wed, 31 Aug 2005 11:50:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAUot-0002U7-4a; Wed, 31 Aug 2005 11:48:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAUoq-0002U2-RA for [e-mail]; Wed, 31 Aug 2005 11:48:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27623 for <[e-mail]>; Wed, 31 Aug 2005 11:48:05 -0400 (EDT)
Received: from gateout01.mbox.net ([165.212.64.21] helo=gwo1.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAUqZ-0000zJ-6D for [e-mail]; Wed, 31 Aug 2005 11:49:58 -0400
Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gwo1.mbox.net (Postfix) with SMTP id 152C612D607; Wed, 31 Aug 2005 15:47:39 +0000 (GMT)
Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.25R)  with ESMTP id 567JHEPvM0154Mo1; Wed, 31 Aug 2005 15:47:38 GMT
Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.25R)  with ESMTP id 563JHEPvK0165Mo1; Wed, 31 Aug 2005 15:47:36 GMT
X-USANET-Routed: 2 gwsout-vs R:localhost:1825
Received: from gw4.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.21U); Wed, 31 Aug 2005 15:47:36 GMT
X-USANET-Source: 165.212.116.254 IN   [e-mail] gw4.EXCHPROD.USA.NET
X-USANET-MsgId: XID489JHEPvK9994Xo1
Received: from localhost ([65.247.36.31]) by gw4.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211);  Wed, 31 Aug 2005 09:47:35 -0600
Date: Wed, 31 Aug 2005 11:47:35 -0400
From: Jeffrey Haas <[e-mail]>
To: Paul Jakma <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav> <[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-OriginalArrivalTime: 31 Aug 2005 15:47:35.0997 (UTC) FILETIME=[4EEAA6D0:01C5AE43]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
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 Tue, Aug 30, 2005 at 06:57:58PM +0100, Paul Jakma wrote:
> One comment I forgot to make, I strongly would recommend against 
> considering allowing adjacent AS_SET's to be packed together.

The current bgp draft has already gone past last call.  Lots of
people implement this already:

            - for each pair of adjacent tuples in the aggregated
            AS_PATH, if both tuples have the same type, merge them
            together, as long as doing so will not cause a segment with
            length greater than 255 to be generated.

Proposals that want to leave sets in disjoint segments don't have a lot
of hope of having their segments unmerged in many implementations
under conditions of another aggregation.  I'd strongly suggest that
another path be considered for implementing the desired feature.

General comment on path length:

While path length was commonly implemented in many versions of BGP
post RFC 1771, it wasn't in the spec for a very long time.  The behavior
of having an AS_SET count as 1 towards the length per segment is
relatively new.

In general, as long as an AS consistently applies BGP tie breaking,
you can calculate the length however you like.  You simply must follow
the path loop detection mechanisms (check for your AS on ingress,
prepend your AS on egress) and the rest of the Internet can construct
a loop free topology.

While path length has certainly served as a very big knob to allow
for one form of traffic engineering, I think it's generally understood
that this relies on the kindness of operators to let path length
influence things as much as they do.


-- 
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 PAA03468 for <[e-mail]>; Tue, 30 Aug 2005 15:13:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EABWJ-0001YG-Rh; Tue, 30 Aug 2005 15:11:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EABWH-0001Y8-KS for [e-mail]; Tue, 30 Aug 2005 15:11:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01718 for <[e-mail]>; Tue, 30 Aug 2005 15:11:39 -0400 (EDT)
Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EABXp-0002Cq-QR for [e-mail]; Tue, 30 Aug 2005 15:13:21 -0400
Received: from [71.240.225.152] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12105784; Tue, 30 Aug 2005 15:11:15 -0400
Message-Id: <6.2.1.2.0.20050830150954.02d7aad0@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Tue, 30 Aug 2005 15:11:10 -0400
To: Jeffrey Haas <[e-mail]>, [e-mail]
From: "Joel M. Halpern" <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
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]

At least in the approach that we suggested in our ID for preserving path 
length and what path information can be preserved in multi-pathing, 
collapsing adjacent sets would break what we were doing.  There are other 
solutions, which reduce the available information, but can cope if the WG 
decides that adjacent sets should be collapsesd.

Yours,
Joel

At 01:10 PM 8/30/2005, Jeffrey Haas wrote:
>Two comments:
>
>On Fri, Aug 26, 2005 at 08:18:50PM +0100, Paul Jakma wrote:
> > AS_SET adds one to the path-length.
>
>Perhaps it would make sense to treat adjacent set segments as not
>adding to the path length.  E.g.
>
> >       AS_SET(<255 ASN's>) AS_SET(<1 ASN>)
>
>would be treated as length 1 rather than 2.
>
>(Of course the entire AS would have to use this logic.)
>
>The second comment was regarding padding vs. a "wide" AS attribute.
>While a wide AS attribute would have nice encoding properties, they
>are semantically identical.  Changing the encoding doesn't seem to
>be a big win at this point, as-4bytes not withstanding.
>
>--
>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 OAA02925 for <[e-mail]>; Tue, 30 Aug 2005 14:11:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAAXU-0005tN-9v; Tue, 30 Aug 2005 14:08:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAAXS-0005si-BP for [e-mail]; Tue, 30 Aug 2005 14:08:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27615 for <[e-mail]>; Tue, 30 Aug 2005 14:08:48 -0400 (EDT)
Received: from zproxy.gmail.com ([64.233.162.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAAZ1-0000JM-Qe for [e-mail]; Tue, 30 Aug 2005 14:10:29 -0400
Received: by zproxy.gmail.com with SMTP id i1so848873nzh for <[e-mail]>; Tue, 30 Aug 2005 11:08:36 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=soOqJSF7YiYvnqV6OyfiWpE3SJjvCV5sO0DGeBvu59UQPBqquYjA1aHFIX/zmGG3SoATYI/xP8xJfPUofuPACSwWrh1M82mCs8DnpKEhC2r9WlOo0NPIg29zoJDAN+J+K8VOcq4sGhxBqiOjuU1tZ3hJPoC1UTFMHKULc8d6ziw=
Received: by 10.36.50.10 with SMTP id x10mr1986639nzx; Tue, 30 Aug 2005 11:08:36 -0700 (PDT)
Received: by 10.36.119.9 with HTTP; Tue, 30 Aug 2005 11:08:36 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 30 Aug 2005 23:38:36 +0530
From: Glen Kent <[e-mail]>
To: Paul Jakma <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
References: <[e-mail]> <[e-mail]> <[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: [e-mail], Jeffrey Haas <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1715895151=="
Sender: [e-mail]
Errors-To: [e-mail]

--===============1715895151==
Content-Type: multipart/alternative; 
	boundary="----=_Part_5467_19477096.1125425316784"

------=_Part_5467_19477096.1125425316784
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I would tend to agree with Paul here.
 Merging the SETs together appears to me as a hacky way of fixing the the=
=20
issue of inserting more than 255 ASes in a SET. I am sure there must be=20
better and cleaner ways of doing the same.
 Glen.=20
 On 8/30/05, Paul Jakma <[e-mail]> wrote:=20
>=20
> On Tue, 30 Aug 2005, Jeffrey Haas wrote:
>=20
> > Perhaps it would make sense to treat adjacent set segments as not
> > adding to the path length. E.g.
> >
> >> AS_SET(<255 ASN's>) AS_SET(<1 ASN>)
> >
> > would be treated as length 1 rather than 2.
>=20
> One comment I forgot to make, I strongly would recommend against
> considering allowing adjacent AS_SET's to be packed together. An
> AS_SET segment has a fixed length, independent of the ASNs contained
> within, merging hence alters the path-length. There are potential
> applications of this property of AS_SETs.
>=20
> regards,
> --
> Paul Jakma [e-mail] [e-mail] Key ID: 64A2FF6A
> Fortune:
> [Washington, D.C.] is the home of... taste for the people -- the big,
> the bland and the banal.
> -- Ada Louise Huxtable
>=20
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
>

------=_Part_5467_19477096.1125425316784
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<div>I would tend to agree with Paul here.</div>
<div>&nbsp;</div>
<div>Merging the SETs together appears to me as&nbsp;a hacky way of fixing =
the the issue of inserting more than 255 ASes in&nbsp;a SET. I am sure ther=
e must be better and cleaner ways of doing the same.</div>
<div>&nbsp;</div>
<div>Glen.&nbsp;<br>&nbsp;</div>
<div><span class=3D"gmail_quote">On 8/30/05, <b class=3D"gmail_sendername">=
Paul Jakma</b> &lt;<a href=3D"mailto:[e-mail]">[e-mail]</a>&gt; w=
rote:</span>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Tue, 30 Aug 2005, Jeffrey Haa=
s wrote:<br><br>&gt; Perhaps it would make sense to treat adjacent set segm=
ents as not
<br>&gt; adding to the path length.&nbsp;&nbsp;E.g.<br>&gt;<br>&gt;&gt;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;AS_SET(&lt;255 ASN's&gt;) AS_SET(&lt;1 ASN&=
gt;)<br>&gt;<br>&gt; would be treated as length 1 rather than 2.<br><br>One=
 comment I forgot to make, I strongly would recommend against
<br>considering allowing adjacent AS_SET's to be packed together. An<br>AS_=
SET segment has a fixed length, independent of the ASNs contained<br>within=
, merging hence alters the path-length. There are potential<br>applications=
 of this property of AS_SETs.
<br><br>regards,<br>--<br>Paul Jakma&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"mailto:[e-mail]">[e-mail]</a>&nbsp;&nbsp; <a href=3D"mail=
to:[e-mail]">[e-mail]</a>&nbsp;&nbsp;Key ID: 64A2FF6A<br>Fortun=
e:<br>[Washington, D.C.] is the home of... taste for the people -- the big,
<br>the bland and the banal.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- Ada Louise Huxtable<br><br>___=
____________________________________________<br>Idr mailing list<br><a href=
=3D"mailto:[e-mail]">[e-mail]</a><br><a href=3D"https://www1.ietf.o=
rg/mailman/listinfo/idr">
https://www1.ietf.org/mailman/listinfo/idr</a><br></blockquote></div><br>

------=_Part_5467_19477096.1125425316784--


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

--===============1715895151==--



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 NAA02841 for <[e-mail]>; Tue, 30 Aug 2005 13:59:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAANG-0003SX-F3; Tue, 30 Aug 2005 13:58:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAANE-0003SP-7T for [e-mail]; Tue, 30 Aug 2005 13:58:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26741 for <[e-mail]>; Tue, 30 Aug 2005 13:58:14 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19Jq/1SRn69F+8RD9aOZ2yKTEBivjzvFE8=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAAOn-0008N5-6l for [e-mail]; Tue, 30 Aug 2005 13:59:55 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7UHvwvD020028; Tue, 30 Aug 2005 18:58:11 +0100
Date: Tue, 30 Aug 2005 18:57:58 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Jeffrey Haas <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav> <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
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 Tue, 30 Aug 2005, Jeffrey Haas wrote:

> Perhaps it would make sense to treat adjacent set segments as not
> adding to the path length.  E.g.
>
>> 	AS_SET(<255 ASN's>) AS_SET(<1 ASN>)
>
> would be treated as length 1 rather than 2.

One comment I forgot to make, I strongly would recommend against 
considering allowing adjacent AS_SET's to be packed together. An 
AS_SET segment has a fixed length, independent of the ASNs contained 
within, merging hence alters the path-length. There are potential 
applications of this property of AS_SETs.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
[Washington, D.C.] is the home of... taste for the people -- the big,
the bland and the banal.
 		-- Ada Louise Huxtable

_______________________________________________
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 NAA02713 for <[e-mail]>; Tue, 30 Aug 2005 13:44:56 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAAA7-0007Qi-IB; Tue, 30 Aug 2005 13:44:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAAA5-0007Qd-6r for [e-mail]; Tue, 30 Aug 2005 13:44:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26005 for <[e-mail]>; Tue, 30 Aug 2005 13:44:39 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/uLxSozPng0Z+qHmIAGPcAC53qVRMU2SY=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAABe-0007xm-Cj for [e-mail]; Tue, 30 Aug 2005 13:46:20 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7UHhH2q019855; Tue, 30 Aug 2005 18:43:29 +0100
Date: Tue, 30 Aug 2005 18:43:17 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: Inter-Domain Routing List <[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 Sat, 27 Aug 2005, Paul Jakma wrote:

> resolve. (Though, if you update the IANA considerations of the draft to 
> mention the "Assign 4-octets ASNs from AS_TRANS:x first" trick, I won't be 
> terribly unhappy with the draft).

Urg, oops, AS_TRANS obviously wont do as it will be used as a 
two-octet ASN.

So an additional two-octet ASN (AS_4OCTET?) ought to be reserved by 
IANA and used as the prefix for the block to assign the first 65k 
4-octet ASNs from. AS_4OCTET should /never/ encoded in two-octets on 
the wire.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
printk("you lose buddy boy...\n");
         linux-2.6.6/arch/sparc/kernel/traps.c

_______________________________________________
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 NAA02644 for <[e-mail]>; Tue, 30 Aug 2005 13:42:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAA65-0006ju-1i; Tue, 30 Aug 2005 13:40:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAA63-0006h4-BV for [e-mail]; Tue, 30 Aug 2005 13:40:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25791 for <[e-mail]>; Tue, 30 Aug 2005 13:40:27 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/kP2G4ExGQgd0AVY/NLBK827QPeS+kUTc=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAA7c-0007qg-W8 for [e-mail]; Tue, 30 Aug 2005 13:42:10 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7UHdsQL019828; Tue, 30 Aug 2005 18:40:07 +0100
Date: Tue, 30 Aug 2005 18:39:54 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Jeffrey Haas <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav> <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
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 Tue, 30 Aug 2005, Jeffrey Haas wrote:

> Perhaps it would make sense to treat adjacent set segments as not
> adding to the path length.  E.g.
>
>> 	AS_SET(<255 ASN's>) AS_SET(<1 ASN>)
>
> would be treated as length 1 rather than 2.

I think a modification of Manav's idea given earlier in this 
discussion would be nice: he proposed adding a flag to signal whether 
a segment should be treated as a continuation of the previous 
segment. I'd suggest this could be done with a new segment type, eg 
AS_CONTINUATION, so you encode a set of 256 ASNs as:

 	AS_SET(<255 ASNs>) AS_CONTINUATION(<1 ASN>)

AS_CONTINUATION would have no meaning other than extending the length 
of the last seen non-continuation segment.

> (Of course the entire AS would have to use this logic.)

The entire internet even :)

> The second comment was regarding padding vs. a "wide" AS attribute. 
> While a wide AS attribute would have nice encoding properties, they 
> are semantically identical.  Changing the encoding doesn't seem to 
> be a big win at this point, as-4bytes not withstanding.

Of that change itself, yes, I agree. But it's one of several little 
nits, other than sizeof(ASN), which I think ideally ought to be taken 
care of if AS_PATH is revised, some of those nits being:

- inefficient encoding of prepends
- 255 length limit
- using the new NEW_AS_PATH type for NEW speakers, rather than
   overloading the existing AS_PATH type
- clarifying effect on path-length of AS_SET and AS_SEQUENCE in the
   definition of AS_PATH itself (currently, it's not specified in the
   definition itself, but elsewhere in the BGP-4 draft.)
- clarifying text on segment packing in AS_PATH

The latter two points can, and should, still be taken care of in the 
draft before us today regardless, as it shouldn't affect encoding.

The first three "nits" affect syntax obviously.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
You are here:
 		***
 		***
 	     *********
 	      *******
 	       *****
 		***
 		 *

 		 But you're not all there.

_______________________________________________
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 NAA02376 for <[e-mail]>; Tue, 30 Aug 2005 13:13:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA9eB-0006Q4-3v; Tue, 30 Aug 2005 13:11:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA9e9-0006Pz-Uo for [e-mail]; Tue, 30 Aug 2005 13:11:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24399 for <[e-mail]>; Tue, 30 Aug 2005 13:11:38 -0400 (EDT)
Received: from gateout02.mbox.net ([165.212.64.22] helo=gwo2.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA9fg-00071S-Vp for [e-mail]; Tue, 30 Aug 2005 13:13:20 -0400
Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gwo2.mbox.net (Postfix) with SMTP id 1B78E163CA3 for <[e-mail]>; Tue, 30 Aug 2005 17:11:03 +0000 (GMT)
Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.25R)  with ESMTP id 812JHdRLc0299Mo2; Tue, 30 Aug 2005 17:11:02 GMT
Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.25R)  with ESMTP id 807JHdRLa0310Mo2; Tue, 30 Aug 2005 17:11:00 GMT
X-USANET-Routed: 2 gwsout-vs R:localhost:1825
Received: from gw2.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.21U); Tue, 30 Aug 2005 17:11:00 GMT
X-USANET-Source: 165.212.116.254 IN   [e-mail] gw2.EXCHPROD.USA.NET
X-USANET-MsgId: XID505JHdRLa2447Xo2
Received: from localhost ([65.247.36.31]) by gw2.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211);  Tue, 30 Aug 2005 11:10:59 -0600
Date: Tue, 30 Aug 2005 13:10:58 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav> <[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-OriginalArrivalTime: 30 Aug 2005 17:10:59.0274 (UTC) FILETIME=[CAB062A0:01C5AD85]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
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]

Two comments:

On Fri, Aug 26, 2005 at 08:18:50PM +0100, Paul Jakma wrote:
> AS_SET adds one to the path-length.

Perhaps it would make sense to treat adjacent set segments as not
adding to the path length.  E.g.

> 	AS_SET(<255 ASN's>) AS_SET(<1 ASN>)

would be treated as length 1 rather than 2.

(Of course the entire AS would have to use this logic.)

The second comment was regarding padding vs. a "wide" AS attribute.
While a wide AS attribute would have nice encoding properties, they
are semantically identical.  Changing the encoding doesn't seem to
be a big win at this point, as-4bytes not withstanding.

-- 
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 KAA00702 for <[e-mail]>; Tue, 30 Aug 2005 10:07:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA6lL-0007ZG-RW; Tue, 30 Aug 2005 10:06:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA6lJ-0007Z7-Ng for [e-mail]; Tue, 30 Aug 2005 10:06:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14210 for <[e-mail]>; Tue, 30 Aug 2005 10:06:51 -0400 (EDT)
Received: from rproxy.gmail.com ([64.233.170.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA6mr-0002DN-C8 for [e-mail]; Tue, 30 Aug 2005 10:08:30 -0400
Received: by rproxy.gmail.com with SMTP id i8so1159774rne for <[e-mail]>; Tue, 30 Aug 2005 07:06:49 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=uLaScOhdnob8fx25HGfLCt9XFIMr2BMaEFtyimMmya14amyAJo2nYElUAYNJ0RvP8jtr0z8kx4Aj7HafQ+DZwgdivjBMK1KiIgu+lkDqZnTHsycZBTU9lenDAoieHWm4WQgyyqn10F35x7HOUjpveZED4uuM3DDEZFhVbsdkdS0=
Received: by 10.38.88.80 with SMTP id l80mr115002rnb; Tue, 30 Aug 2005 07:06:49 -0700 (PDT)
Received: by 10.38.75.21 with HTTP; Tue, 30 Aug 2005 07:06:49 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 30 Aug 2005 19:36:49 +0530
From: Maneesh Chawla <[e-mail]>
To: [e-mail]
Mime-Version: 1.0
X-Spam-Score: 0.5 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Subject: [Idr] BGP Communities
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="===============0954988643=="
Sender: [e-mail]
Errors-To: [e-mail]

--===============0954988643==
Content-Type: multipart/alternative; 
	boundary="----=_Part_1007_5968081.1125410809575"

------=_Part_1007_5968081.1125410809575
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi All,
 I am pretty new to this.I have 2 questions on this :
 1. Is it possible to receive a route from the internet with "reserved=20
communities" set on the route ?
 If yes,
 2. Should an implementation have provision to configure community list wit=
h=20
"reserved communities" , though not to set the communities but atleast to=
=20
match routes that have those communities in them ?
 Thanks
Maneesh

------=_Part_1007_5968081.1125410809575
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<div>Hi All,</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I am pret=
ty new to this.I have 2 questions on this :</div>
<div>&nbsp;</div>
<div>1. Is it possible to receive a route from the internet with &quot;rese=
rved communities&quot; set on the route ?</div>
<div>&nbsp;</div>
<div>If yes,</div>
<div>&nbsp;</div>
<div>2. Should an implementation have provision to configure community list=
 with &quot;reserved communities&quot; , though not to set the communities =
but atleast to match routes that have those communities in them ?</div>

<div>&nbsp;</div>
<div>Thanks</div><span class=3D"sg">
<div>Maneesh</div></span>

------=_Part_1007_5968081.1125410809575--


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

--===============0954988643==--



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 OAA27270 for <[e-mail]>; Sun, 28 Aug 2005 14:21:17 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9RlE-0008EY-3G; Sun, 28 Aug 2005 14:20:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9RlC-0008E7-S5 for [e-mail]; Sun, 28 Aug 2005 14:20:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03298 for <[e-mail]>; Sun, 28 Aug 2005 14:20:01 -0400 (EDT)
Received: from zproxy.gmail.com ([64.233.162.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9RmN-0002ho-60 for [e-mail]; Sun, 28 Aug 2005 14:21:16 -0400
Received: by zproxy.gmail.com with SMTP id i1so535360nzh for <[e-mail]>; Sun, 28 Aug 2005 11:19:46 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=X5sIImxvSz5Px/RZkGDI9x5EWIoOSb/f9kOZ2NDiBDI/oSGfuUl/NoaZj1kseCLCwu3JhsBa2oDDA40iEsPncFS2Op2OYmhDF+dA0UAICfMa84WxuIup0GRh/fKtesageuAmvs3HfoIuDww9IWMj1UK7c9hl8Pf915JDfjQGOBE=
Received: by 10.37.14.76 with SMTP id r76mr195048nzi; Sun, 28 Aug 2005 11:19:46 -0700 (PDT)
Received: by 10.36.119.9 with HTTP; Sun, 28 Aug 2005 11:19:46 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sun, 28 Aug 2005 23:49:46 +0530
From: Glen Kent <[e-mail]>
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: Inter-Domain Routing List <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0040739514=="
Sender: [e-mail]
Errors-To: [e-mail]

--===============0040739514==
Content-Type: multipart/alternative; 
	boundary="----=_Part_4464_33088343.1125253186597"

------=_Part_4464_33088343.1125253186597
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

> My understanding is that the editor (Geoff) has received two=20
> implementation reports. So we can expect to see the report really soon.
 Is it Redback and now, Cisco? ;-)
 Glen.

------=_Part_4464_33088343.1125253186597
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<div><span class=3D"gmail_quote">&gt; My understanding is that the editor (=
Geoff) has received two <br>&gt; implementation reports. So we can expect t=
o see the report really soon.</span></div>
<div><span class=3D"gmail_quote"></span>&nbsp;</div>
<div><span class=3D"gmail_quote">Is it Redback and now, Cisco? ;-)</span></=
div>
<div><span class=3D"gmail_quote"></span>&nbsp;</div>
<div><span class=3D"gmail_quote">Glen.</span></div>
<p><span class=3D"gmail_quote">&nbsp;</span></p>
<div><br>&nbsp;</div>

------=_Part_4464_33088343.1125253186597--


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

--===============0040739514==--



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 OAA26693 for <[e-mail]>; Sun, 28 Aug 2005 14:14:12 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Rcw-0006dq-0H; Sun, 28 Aug 2005 14:11:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Rcv-0006dl-8N for [e-mail]; Sun, 28 Aug 2005 14:11:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02841 for <[e-mail]>; Sun, 28 Aug 2005 14:11:28 -0400 (EDT)
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.43) id 1E9Re5-0002T8-No for [e-mail]; Sun, 28 Aug 2005 14:12:43 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 28 Aug 2005 11:11:16 -0700
X-IronPort-AV: i="3.96,148,1122879600";  d="scan'208"; a="336562012:sNHT30525348"
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7SIB70L001797; Sun, 28 Aug 2005 11:11:12 -0700 (PDT)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 28 Aug 2005 11:11:12 -0700
Received: from [10.21.121.174] ([10.21.121.174]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);  Sun, 28 Aug 2005 11:11:12 -0700
Message-ID: <[e-mail]>
Date: Sun, 28 Aug 2005 11:11:10 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Glen Kent <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Aug 2005 18:11:12.0364 (UTC) FILETIME=[DF6EAAC0:01C5ABFB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
Cc: Inter-Domain Routing List <[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]

Hi, Glen:

Glen Kent wrote:

>Enke Chen <[e-mail]> wrote: 
>  
>
>>    
>>
>>>For folks that was involved in the IDR in 2001, you might remember that
>>>was the original design. However, it has the flaw of carrying duplicate
>>>info even after the world has transitioned to 4-byte AS, and some folks
>>>even suggested having a "second transition" to eliminate the 2-byte
>>>as-path. So the idea was dropped.
>>>      
>>>
>
> I went through the IDR mail archives (circa 2001 and early 2002) and i 
>didnt come across any active discussion regarding the 4-byte AS draft. Did i 
>miss something?
>  
>

My recollection is that there were active discussions at the IDR WG 
meeting, and a lot of discussions in the hallway (in addition to 
numerous discussions among the authors and other active participants).  
I do not remember much about the activities on the IDR mailing list at 
that time.

> BTW, which vendors have actually implemented this feature?
>  
>
My understanding is that the editor (Geoff) has received two 
implementation reports. So we can expect to see the report really soon.

-- 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 MAA16934 for <[e-mail]>; Sun, 28 Aug 2005 12:07:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Pgx-00084q-In; Sun, 28 Aug 2005 12:07:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Pgv-00082h-J0 for [e-mail]; Sun, 28 Aug 2005 12:07:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27388 for <[e-mail]>; Sun, 28 Aug 2005 12:07:27 -0400 (EDT)
Received: from zproxy.gmail.com ([64.233.162.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9Pi5-0007pT-0e for [e-mail]; Sun, 28 Aug 2005 12:08:42 -0400
Received: by zproxy.gmail.com with SMTP id i1so527410nzh for <[e-mail]>; Sun, 28 Aug 2005 09:07:17 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=AZlHkTQSmN0fTqxkW8PPFiChvvCC6w3Wg+rDV0sL8OTWmNC5MZ1l3zboZJPHJNz9PwSmVnIlpSZZ2F/ZGbVtipee4iHRpwIRizsLLxj6DriQUb7TigmEcaVpI3hGC6pgAeqI1noRh47+Pr3CYa13POBZPdH9IqFh4aF2Eej7k0s=
Received: by 10.36.129.10 with SMTP id b10mr201715nzd; Sun, 28 Aug 2005 09:07:17 -0700 (PDT)
Received: by 10.36.119.9 with HTTP; Sun, 28 Aug 2005 09:07:17 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sun, 28 Aug 2005 21:37:17 +0530
From: Glen Kent <[e-mail]>
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
References: <[e-mail]>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: Inter-Domain Routing List <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0015029558=="
Sender: [e-mail]
Errors-To: [e-mail]

--===============0015029558==
Content-Type: multipart/alternative; 
	boundary="----=_Part_4192_22723008.1125245237437"

------=_Part_4192_22723008.1125245237437
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Enke Chen <[e-mail]> wrote:=20
>=20
>=20
> > For folks that was involved in the IDR in 2001, you might remember that
> > was the original design. However, it has the flaw of carrying duplicate
> > info even after the world has transitioned to 4-byte AS, and some folks
> > even suggested having a "second transition" to eliminate the 2-byte
> > as-path. So the idea was dropped.

 I went through the IDR mail archives (circa 2001 and early 2002) and i=20
didnt come across any active discussion regarding the 4-byte AS draft. Did =
i=20
miss something?
 BTW, which vendors have actually implemented this feature?
 Glen

------=_Part_4192_22723008.1125245237437
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<div><span class=3D"gmail_quote"><b class=3D"gmail_sendername">Enke Chen</b=
> &lt;<a href=3D"mailto:[e-mail]">[e-mail]</a>&gt; wrot=
e:</span>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>&gt; For folks that was invo=
lved in the IDR in 2001, you might remember that<br>&gt; was the original d=
esign. However, it has the flaw of carrying duplicate
<br>&gt; info even after the world has transitioned to 4-byte AS, and some =
folks<br>&gt; even suggested having a &quot;second transition&quot; to elim=
inate the 2-byte<br>&gt; as-path.&nbsp;&nbsp;So the idea was dropped.</bloc=
kquote>

<div>&nbsp;</div>
<div>I went through the IDR mail archives (circa 2001 and early 2002) and i=
 didnt come across any active discussion regarding the 4-byte AS draft. Did=
 i miss something?</div>
<div>&nbsp;</div>
<div>BTW, which vendors have actually implemented this feature?</div>
<div>&nbsp;</div>
<div>Glen</div></div>

------=_Part_4192_22723008.1125245237437--


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

--===============0015029558==--



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 JAA04399 for <[e-mail]>; Sun, 28 Aug 2005 09:27:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9N8t-0000K4-1O; Sun, 28 Aug 2005 09:24:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9N8r-0000Jw-Cv for [e-mail]; Sun, 28 Aug 2005 09:24:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18027 for <[e-mail]>; Sun, 28 Aug 2005 09:24:07 -0400 (EDT)
Received: from gateout02.mbox.net ([165.212.64.22] helo=gwo2.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9N9y-0003a3-3q for [e-mail]; Sun, 28 Aug 2005 09:25:20 -0400
Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gwo2.mbox.net (Postfix) with SMTP id 53A30163A7B; Sun, 28 Aug 2005 13:23:25 +0000 (GMT)
Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.17K)  with ESMTP id 754JHbNXX0433Mo2; Sun, 28 Aug 2005 13:23:24 GMT
Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.17K)  with ESMTP id 752JHbNXV0433Mo2; Sun, 28 Aug 2005 13:23:21 GMT
X-USANET-Routed: 2 gwsout-vs R:localhost:1825
Received: from gw3.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.21U); Sun, 28 Aug 2005 13:23:21 GMT
X-USANET-Source: 165.212.116.254 IN   [e-mail] gw3.EXCHPROD.USA.NET
X-USANET-MsgId: XID497JHbNXV2947Xo2
Received: from VS4.EXCHPROD.USA.NET ([10.116.208.142]) by gw3.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.211);  Sun, 28 Aug 2005 07:23:21 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: [Idr] draft-ietf-idr-rfc2858bis-07.txt, SAFI=3 removed?
Date: Sun, 28 Aug 2005 07:23:20 -0600
Message-ID: <[e-mail]>
Thread-Topic: [Idr] draft-ietf-idr-rfc2858bis-07.txt, SAFI=3 removed?
Thread-Index: AcWob5HTRYdGdOhWQ8elWVcpf9m21QCNNRwg
From: "Susan Hares" <[e-mail]>
To: "Pekka Savola" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 28 Aug 2005 13:23:21.0235 (UTC) FILETIME=[A9098630:01C5ABD3]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id JAA04399

Pekka:

	My recollection is that Mboned discussed it.  In my early
discussion with ISPs operators during early deployments tended to put
multicast on different routers.

You are welcome to ask the chairs of mboned as well. 

Cheers, 

Sue

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Pekka Savola
Sent: Wednesday, August 24, 2005 1:48 AM
To: [e-mail]
Cc: [e-mail]
Subject: [Idr] draft-ietf-idr-rfc2858bis-07.txt, SAFI=3 removed?

Hi,

On Tue, 23 Aug 2005 [e-mail] wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-07.txt

Has the removal of "both unicast and multicast" in MP-BGP update been 
reviewed by multicast communities?

(Personally, I haven't verified what happens when I advertise all our 
BGP prefixes as identically for both unicast and multicast; does that 
result in two sets of prefixes for SAFI=1, then SAFI=2 or just 
SAFI=3..)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
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 XAA18409 for <[e-mail]>; Sat, 27 Aug 2005 23:38:54 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Dwf-00046a-64; Sat, 27 Aug 2005 23:34:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Dwd-00046V-SX for [e-mail]; Sat, 27 Aug 2005 23:34:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13034 for <[e-mail]>; Sat, 27 Aug 2005 23:34:46 -0400 (EDT)
Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9Dxa-0002cc-6j for [e-mail]; Sat, 27 Aug 2005 23:35:55 -0400
Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id UAA10667; Sat, 27 Aug 2005 20:34:26 -0700 (PDT)
Received: from manav ([10.128.16.133]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Aug 2005 20:34:25 -0700
Message-ID: <004a01c5ab81$c26cd390$6401a8c0@manav>
From: "Manav Bhatia" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]><[e-mail]><[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav><[e-mail]> <012001c5aa68$af1e0cb0$6401a8c0@manav>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Date: Sun, 28 Aug 2005 09:07:00 +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.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-OriginalArrivalTime: 28 Aug 2005 03:34:25.0899 (UTC) FILETIME=[638923B0:01C5AB81]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
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]

Okay there is another way of doing this.

Represent each AS path segment in the NEW_AS_PATH by a quadruple <flags,
path segment type, path segment length, path segment value>. If the LSB of
the flags is set then the path segment MUST be considered contiguous to the
previous segment and should not affect the path length. This bit would be
relevant only when the path segment is of type SET.

This way we dont need to increase the length field to two octets. The
remaining bits in the 'flags' field can be put to other uses in the future.

Manav

----- Original Message ----- 
From: "Manav Bhatia" <[e-mail]>
To: "Enke Chen" <[e-mail]>
Cc: "Inter-Domain Routing List" <[e-mail]>; "Paul Jakma" <[e-mail]>
Sent: Friday, August 26, 2005 11:35 PM
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?


> I used this example to state that number of ASes in as_path may NOT be
> proportional to number of hops.
>
> We could potentially have applications in future (ecmp perhaps?) , which
may
> insert more than 255 ASes in an AS_SET. There we could have scenarios
where
> one may want to preserve the as_path length and may not want it to
increase.
>
> Keeping this upper bound of 255 ASes in an AS_SET looks unreasonable to
me.
> The only reason I bring this up is because there is a discussion going on
> related to *_AS_PATH attribute, and this is one thing that can be
addressed.
>
> I would not be very comfortable with this, but if its too much of a hassle
> then we could increase the length to 2 octets for only the *_AS_SET
segment
> and not touch the *_AS_SEQUENCE.
>
> Manav
>
> ----- Original Message ----- 
> From: "Enke Chen" <[e-mail]>
> To: "Manav Bhatia" <[e-mail]>
> Cc: "Paul Jakma" <[e-mail]>; "Curtis Villamizar"
> <[e-mail]>; "Inter-Domain Routing List" <[e-mail]>;
"Enke
> Chen (enkechen)" <[e-mail]>
> Sent: Friday, August 26, 2005 11:09 PM
> Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
>
>
> > Manav Bhatia wrote:
> >
> > >Ok, so the argument is that since an IP packet will never traverse more
> than
> > >255 hops, it makes no sense to have more than 255 ASes in the path.
> > >
> > >This is not even an issue because even if we overflow the ASes in a
> sequence
> > >we can introduce another AS_SEQUENCE.segment and that would work as
well.
> > >
> > >
> > Agreed.
> >
> > >The problem is with AS_SETs. If the nos. of elements (i.e. ASes) goes
> beyond
> > >255 then we cant insert another AS_SET segment as that would increase
the
> > >path length by 1.
> > >
> > >
> >
> > As long as consistency is maitained with an AS, how is this different
> > from AS prepend (with respect to the path length)?
> >
> > -- Enke
> >
> > >Consider the following two paths:
> > >
> > >as_path {a b} nlri 10.1.1/24
> > >as_path {a1 b1} nlri 10.1.2/24
> > >as_path {a2 b2} nlri 10.1.3/24
> > >
> > >Agrregating this creates as_path [ a a1 a2 b b1 b2] nlri 10.1/16
> > >
> > >Clearly the number of ASes in as_path is NOT proportional to number of
> hops.
> > >
> > >Thanks,
> > >Manav
> > >
> > >----- Original Message ----- 
> > >From: "Enke Chen" <[e-mail]>
> > >To: "Paul Jakma" <[e-mail]>
> > >Cc: "Curtis Villamizar" <[e-mail]>; "Manav Bhatia"
> > ><[e-mail]>; "Inter-Domain Routing List" <[e-mail]>;
> "Enke
> > >Chen" <[e-mail]>
> > >Sent: Friday, August 26, 2005 8:47 PM
> > >Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
> > >
> > >
> > >
> > >
> > >>The idea indeed came up in 2001, and was dropped based on the
following
> > >>reasoning:
> > >>
> > >>     This is not a practical issue considering that the max ttl for ip
> > >>packet (ipv4/ipv6) is only 255.
> > >>
> > >>-- Enke
> > >>
> > >>Paul Jakma wrote:
> > >>
> > >>
> > >>
> > >>>On Fri, 26 Aug 2005, Curtis Villamizar wrote:
> > >>>
> > >>>
> > >>>
> > >>>>The longest legitimate AS paths (not padded) are well under 20 in
> > >>>>length, the vast majority under 10 and typically 5 or less.  The
only
> > >>>>practical purpose that allowing more than 255 would serve is to
allow
> > >>>>further abuse of AS PATH padding.
> > >>>>
> > >>>>
> > >>>If encoding can be changed beyond the current draft, that can be
fixed
> > >>>too.
> > >>>
> > >>>regards,
> > >>>
> > >>>
>
>
> _______________________________________________
> 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 RAA19249 for <[e-mail]>; Sat, 27 Aug 2005 17:34:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E98HG-0007gp-Lz; Sat, 27 Aug 2005 17:31:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E98HE-0007gh-A1 for [e-mail]; Sat, 27 Aug 2005 17:31:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00982 for <[e-mail]>; Sat, 27 Aug 2005 17:31:45 -0400 (EDT)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E98ID-0003Il-LD for [e-mail]; Sat, 27 Aug 2005 17:32:51 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7RLVHS12763; Sun, 28 Aug 2005 00:31:17 +0300
Date: Sun, 28 Aug 2005 00:31:17 +0300 (EEST)
From: Pekka Savola <[e-mail]>
To: Bill Fenner <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: [e-mail]
Subject: [Idr] Re: draft-ietf-idr-rfc2858bis-07.txt, SAFI=3 removed?
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 Fri, 26 Aug 2005, Bill Fenner wrote:
> The implementation report showed 2 implementations that implement SAFI
> 3 for receive-only (presumably they would apply the update to individual
> SAFI 2 and SAFI 1 RIBs and advertise it seperately when propogating) and
> 3 implementations that do not implement SAFI 3.  Features that have not
> been implemented need to be removed when going to Draft Standard (but the
> SAFI is reserved, so it would be possible to document SAFI 3 in a Proposed
> Standard if people thought it was important to have a document for).

Well, if what you say is correct, it'd be perfectly fine to document 
receive-only SAFI=3 processing in the draft standard -- two 
independent implementations are enough.

Whether that makes sense or not (I guess this mainly depends on 
whether there are believed to be implmentations which actually send 
out SAFI=3 and inteoperability should not be broken) is debatable.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
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 EAA16000 for <[e-mail]>; Sat, 27 Aug 2005 04:04:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8veE-0006IG-V5; Sat, 27 Aug 2005 04:02:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8veC-0006IB-SW for [e-mail]; Sat, 27 Aug 2005 04:02:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01770 for <[e-mail]>; Sat, 27 Aug 2005 04:02:38 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX18NB+HgbH8q0eLLSI/vF9e3QAUcWr3hy2E=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8vf4-00008X-W3 for [e-mail]; Sat, 27 Aug 2005 04:03:36 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7R81M62003022; Sat, 27 Aug 2005 09:01:34 +0100
Date: Sat, 27 Aug 2005 09:01:22 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: Inter-Domain Routing List <[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 Sat, 27 Aug 2005, Enke Chen wrote:

> I thought we were talking about your idea of AS_WIDE segment.

Yes, an obvious optimisation - it doesn't change anything, only 
provides a compact way to encode as-prepending, an existing practice. 
There might be other reasonably obvious and risk-free modifications 
that could be made.

But: If and only if it's considered worthwhile to change the draft.

That's a question you and I have entrenched positions on and aren't 
going to resolve. (Though, if you update the IANA considerations of 
the draft to mention the "Assign 4-octets ASNs from AS_TRANS:x first" 
trick, I won't be terribly unhappy with the draft).

> It is possible that I misunderstood something there (and sorry in 
> that case).

No worries.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Linux is alread carrier (pigeon) grade
                 -> www.blug.linux.no/rfc1149/

 	- Alan Cox on linux-kernel

_______________________________________________
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 DAA12357 for <[e-mail]>; Sat, 27 Aug 2005 03:17:36 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8uvo-0003hU-3g; Sat, 27 Aug 2005 03:16:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8uvl-0003hM-TD for [e-mail]; Sat, 27 Aug 2005 03:16:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00035 for <[e-mail]>; Sat, 27 Aug 2005 03:16:44 -0400 (EDT)
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.43) id 1E8uwc-0007MB-UV for [e-mail]; Sat, 27 Aug 2005 03:17:41 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 27 Aug 2005 00:16:34 -0700
X-IronPort-AV: i="3.96,145,1122879600";  d="scan'208"; a="657079618:sNHT28439582"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7R7GWoo018620; Sat, 27 Aug 2005 00:16:32 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 27 Aug 2005 00:16:32 -0700
Received: from [10.21.121.174] ([10.21.121.174]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);  Sat, 27 Aug 2005 00:16:31 -0700
Message-ID: <[e-mail]>
Date: Sat, 27 Aug 2005 00:16:31 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Jakma <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Aug 2005 07:16:31.0680 (UTC) FILETIME=[3FE83400:01C5AAD7]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit
Cc: Inter-Domain Routing List <[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]

Paul Jakma wrote:

> On Fri, 26 Aug 2005, Enke Chen wrote:
>
>> A network must have consistent route selection in order to avoid 
>> forwarding loops. When some routers in a network recognize a new BGP 
>> attribute that changes route selection, and some do not, forwarding 
>> loops can occur.
>
>
> Gosh really?
>
> Where exactly did I propose to either:
>
> - change anything but as-path length metric
>   - i don't remember mentioning changing the selection process
>
> - change anything incompatibly over a transition period
>
> ?

I thought we were talking about your idea of AS_WIDE segment.  It is 
possible that I misunderstood something there (and sorry in that case).

Regards,

-- 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 DAA11656 for <[e-mail]>; Sat, 27 Aug 2005 03:08:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8ulp-0001LY-Ei; Sat, 27 Aug 2005 03:06:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8ull-0001Jh-KI for [e-mail]; Sat, 27 Aug 2005 03:06:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29766 for <[e-mail]>; Sat, 27 Aug 2005 03:06:23 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX18Y+vJadT571okX9544MSDwTiSirVml8z0=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8umd-00073Z-A7 for [e-mail]; Sat, 27 Aug 2005 03:07:20 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7R76440002500; Sat, 27 Aug 2005 08:06:17 +0100
Date: Sat, 27 Aug 2005 08:06:04 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: Inter-Domain Routing List <[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 Fri, 26 Aug 2005, Enke Chen wrote:

> A network must have consistent route selection in order to avoid 
> forwarding loops. When some routers in a network recognize a new 
> BGP attribute that changes route selection, and some do not, 
> forwarding loops can occur.

Gosh really?

Where exactly did I propose to either:

- change anything but as-path length metric
   - i don't remember mentioning changing the selection process

- change anything incompatibly over a transition period

?

> Sorry - this is probably too basic, and boring for many folks on 
> this list :-)

Nice.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Space is to place as eternity is to time.
 		-- Joseph Joubert

_______________________________________________
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 CAA09608 for <[e-mail]>; Sat, 27 Aug 2005 02:44:09 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8uOw-0003Je-1L; Sat, 27 Aug 2005 02:42:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8uOt-0003Fx-Tx for [e-mail]; Sat, 27 Aug 2005 02:42:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28951 for <[e-mail]>; Sat, 27 Aug 2005 02:42:46 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8uPl-0006RY-L6 for [e-mail]; Sat, 27 Aug 2005 02:43:42 -0400
Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 26 Aug 2005 23:42:38 -0700
X-IronPort-AV: i="3.96,145,1122879600";  d="scan'208"; a="207971801:sNHT30494560"
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7R6gZ2i012683; Fri, 26 Aug 2005 23:42:35 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 23:42:35 -0700
Received: from [10.21.121.174] ([10.21.121.174]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);  Fri, 26 Aug 2005 23:42:34 -0700
Message-ID: <[e-mail]>
Date: Fri, 26 Aug 2005 23:42:33 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Aug 2005 06:42:34.0759 (UTC) FILETIME=[81CEB970:01C5AAD2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: Inter-Domain Routing List <[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]

Paul Jakma wrote:

> On Fri, 26 Aug 2005, Enke Chen wrote:
>
>> Indeed - based on what we know today and if this were 1992!
>
>
> Hehe :)
>
>> This idea seems to be similar to what was proposed 10 years ago. Take 
>> a look at Vadim Antonov's draft (1995):
>>
>> http://gato.kotovnik.com/~avg/old_page/draft-bgpmetric.txt
>
>
> Wow, that's really interesting. I was considering also proposing that 
> one could encode the ASNs as (metric,ASN) tuples, but was dissuaded.
>
> The above is far more sophisticated, though the full implications of 
> what it suggests possibly are hard to discern.
>
>> The issue then was the difficulty in transition to a new path 
>> selection algorithm.
>
>
>> Today the networks are much larger, and it is much more difficult.
>
>
> In what sense? Given there is a "must be revised" event horizon lying 
> somewhere between 2009 and 2020 for today's AS_PATH. Hence why we're 
> discussing your draft. :)

A network must have consistent route selection in order to avoid 
forwarding loops. When some routers in a network recognize a new BGP 
attribute that changes route selection, and some do not, forwarding 
loops can occur.

Sorry - this is probably too basic, and boring for many folks on this 
list :-)

Regards,

-- 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 CAA06438 for <[e-mail]>; Sat, 27 Aug 2005 02:04:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8tm8-0001i5-Lb; Sat, 27 Aug 2005 02:02:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8tm6-0001hv-Rp for [e-mail]; Sat, 27 Aug 2005 02:02:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16850 for <[e-mail]>; Sat, 27 Aug 2005 02:02:41 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX18ztSzYMAs5lrdZpLecgrtAM342mFcCw+Q=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8tmu-0005Ua-M7 for [e-mail]; Sat, 27 Aug 2005 02:03:34 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7R62I0k002100; Sat, 27 Aug 2005 07:02:33 +0100
Date: Sat, 27 Aug 2005 07:02:18 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: Inter-Domain Routing List <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail], Inter-Domain Routing List <[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]

On Fri, 26 Aug 2005, Enke Chen wrote:

> Indeed - based on what we know today and if this were 1992!

Hehe :)

> This idea seems to be similar to what was proposed 10 years ago. Take a look 
> at Vadim Antonov's draft (1995):
>
> http://gato.kotovnik.com/~avg/old_page/draft-bgpmetric.txt

Wow, that's really interesting. I was considering also proposing that 
one could encode the ASNs as (metric,ASN) tuples, but was dissuaded.

The above is far more sophisticated, though the full implications of 
what it suggests possibly are hard to discern.

> The issue then was the difficulty in transition to a new path 
> selection algorithm.

> Today the networks are much larger, and it is much more difficult.

In what sense? Given there is a "must be revised" event horizon lying 
somewhere between 2009 and 2020 for today's AS_PATH. Hence why we're 
discussing your draft. :)

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Bond reflected that good Americans were fine people and that most of them
seemed to come from Texas.
 		-- Ian Fleming, "Casino Royale"

_______________________________________________
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 RAA25928 for <[e-mail]>; Fri, 26 Aug 2005 17:27:08 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8lgM-0001H4-El; Fri, 26 Aug 2005 17:24:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8lgK-0001Gz-Kg for [e-mail]; Fri, 26 Aug 2005 17:24:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23400 for <[e-mail]>; Fri, 26 Aug 2005 17:24:10 -0400 (EDT)
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.43) id 1E8lh5-00083o-F1 for [e-mail]; Fri, 26 Aug 2005 17:25:02 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 26 Aug 2005 14:24:00 -0700
X-IronPort-AV: i="3.96,144,1122879600";  d="scan'208"; a="336214217:sNHT126880994"
Received: from [128.107.134.9] (enke-linux.cisco.com [128.107.134.9]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7QLNt0J004466; Fri, 26 Aug 2005 14:23:56 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 26 Aug 2005 14:23:57 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Jakma <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
Cc: Inter-Domain Routing List <[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]

Hi, Paul:

[snip]

> Come on, surely there must be some interesting AS_PATH ideas you have?

Indeed - based on what we know today and if this were 1992!

>
> Another idea: Get rid of as-path prepending by introducing an AS_WIDE 
> segment, it would have the property of:
>
> - only ever contains one ASN
> - length field indicates not the number of ASNs in the segment data,
> but the amount to increase the hopcount by.
>
> So, eg, a 6 ASN prepend like:
>
> 23456 23456 2345 23456 23456 23456
>
> just becomes:
>
> type: AS_WIDE, length: 6, 23456
>
> on the wire, ie 6 bytes (4-octet ASN), instead of 12.


This idea seems to be similar to what was proposed 10 years ago. Take a 
look at Vadim Antonov's draft (1995):

http://gato.kotovnik.com/~avg/old_page/draft-bgpmetric.txt

The issue then was the difficulty in transition to a new path selection 
algorithm.

Today the networks are much larger, and it is much more difficult.

Regards,

-- 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 PAA17328 for <[e-mail]>; Fri, 26 Aug 2005 15:36:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8juN-0001W4-3Q; Fri, 26 Aug 2005 15:30:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8juK-0001Vz-Sl for [e-mail]; Fri, 26 Aug 2005 15:30:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09896 for <[e-mail]>; Fri, 26 Aug 2005 15:30:31 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1+15Ybn/3WQv33g2b9M4HzgNuur+sLp6wc=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8jv7-0001Sq-BD for [e-mail]; Fri, 26 Aug 2005 15:31:21 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7QJUFDB029592; Fri, 26 Aug 2005 20:30:27 +0100
Date: Fri, 26 Aug 2005 20:30:15 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: Inter-Domain Routing List <[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 Fri, 26 Aug 2005, Enke Chen wrote:

> As you indicated in a previous email, the 1:<xx> might last for 20 
> years :-) So the 4-byte AS numbers may last for at least tens of 
> thousands of years :-)

;)

Glad there's a solution for that actually.

> They are of different semantics.

Nah, it's a pretty good path attribute.

> The hopcount can only be inserted by one AS, and is optional.

And it still could be, even in a NEW_AS_PATH

> It is also expected that only a (small) subset of the routes would 
> need/do the hopcount attribute. IMHO the hopcount attribute should 
> stay as is.

I don't know, I have a feeling AS_HOPCOUNT could be really popular. 
Good idea. But you won't see /that/ much of it, no ;).

If you're redesigning AS_PATH, then a static field for as-hopcount 
seems a grand idea. Particularly as then *everyone* will have to 
support it within 5 to 10 years (when NEW_AS_PATH support would 
become essential). And hopefully there'd be lots of advance 
deployment before the actual ASN crunch..

Come on, surely there must be some interesting AS_PATH ideas you 
have?

Another idea: Get rid of as-path prepending by introducing an AS_WIDE 
segment, it would have the property of:

- only ever contains one ASN
- length field indicates not the number of ASNs in the segment data,
   but the amount to increase the hopcount by.

So, eg, a 6 ASN prepend like:

 	23456 23456 2345 23456 23456 23456

just becomes:

 	type: AS_WIDE, length: 6, 23456

on the wire, ie 6 bytes (4-octet ASN), instead of 12.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
The most dangerous organization in America today is:
 	(a) The KKK
 	(b) The American Nazi Party
 	(c) The Delta Frequent Flyer Club

_______________________________________________
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 PAA16309 for <[e-mail]>; Fri, 26 Aug 2005 15:23:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jlb-0006OW-OJ; Fri, 26 Aug 2005 15:21:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jlZ-0006OR-MT for [e-mail]; Fri, 26 Aug 2005 15:21:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08758 for <[e-mail]>; Fri, 26 Aug 2005 15:21:28 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX18X8PqK8sEcq1OPdnYoTVO8LUoPjRga/U0=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8jmL-0000xn-1j for [e-mail]; Fri, 26 Aug 2005 15:22:18 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7QJIocE029388; Fri, 26 Aug 2005 20:19:02 +0100
Date: Fri, 26 Aug 2005 20:18:50 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: Manav Bhatia <[e-mail]>, Inter-Domain Routing List <[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 Fri, 26 Aug 2005, Enke Chen wrote:

> As long as consistency is maitained with an AS, how is this 
> different from AS prepend (with respect to the path length)?

AS_SET adds one to the path-length.

When you want to have a path-width of 256 at a certain point in your 
AS-Path then:

 	AS_SET(<255 ASN's>) AS_SET(<1 ASN>)

Simply isn't the same thing, that's a length of 2, width 255 followed 
by length 1, width 1 - not quite same thing.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
"What's a battle?"

 	--Ralph Wiggum
 	  Whacking Day (Episode 9F18)

_______________________________________________
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 PAA15927 for <[e-mail]>; Fri, 26 Aug 2005 15:18:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jgQ-0005DX-Ei; Fri, 26 Aug 2005 15:16:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jgM-0005Af-CV for [e-mail]; Fri, 26 Aug 2005 15:16:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08125 for <[e-mail]>; Fri, 26 Aug 2005 15:16:04 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX183XQ/bLNDPe0cMhzKEjNujSJLHB9SOBxs=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8jh5-0000nA-Vg for [e-mail]; Fri, 26 Aug 2005 15:16:55 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7QJEStG029349; Fri, 26 Aug 2005 20:14:40 +0100
Date: Fri, 26 Aug 2005 20:14:28 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: Manav Bhatia <[e-mail]>, Inter-Domain Routing List <[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 Fri, 26 Aug 2005, Enke Chen wrote:

> The BGP base spec actually allows one to carry more than 255 AS numbers in 
> the AS-PATH attribute using multiple segments. There is really no need to 
> optimize for this unlikely scenario.

You're still thinking in terms of length though. Yes, you can use an 
additional segment to go past a /length/ of 255. But not a width.

And no, you don't see anyone caring much about being able to express 
width /today/, primarily cause the only thing in BGP today which 
cares is aggregation.

There is a really good reason to care about width though, we don't 
have it in BGP yet, and at least one implementation which tried a 
'local' hack of this got burned by it because it ignored width..

Given that we likely have /potential/ path-widths of at least a 
hundred already *today* on paths that, eg, go through the 
several-hundred+ member-AS IXes we have today, given it's unlikely 
the internet is going to get narrower, then I think it's not 
unreasonable to consider whether to extend segment length so that it 
/definitely/ can never overflow.

I don't have hard numbers, but 255 doesn't feel like something I'd 
bet a lot of money on as 'future-proof'. So, given the very rare 
opportunity we have today to examine what changes, if any other than 
4-octets, should be made to AS_PATH to take it through another 15+ 
years of internet growth, I think it's very foolish to not at least 
*think* about it simply because the draft as stands has one early 
implementation. ;)

And yes, I am quite biased, because if some overwhelmingly good 
reason came along to change the draft, I'd get to have my nit fixed. 
:). But that's insignificant compared to carefully considering:

"We have to change AS_PATH anyway, so what will it need to 
future-proof it?"

"Nothing but ASN size" is of course a valid answer, but not without 
consideration.

> Regards,
>
> -- Enke

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
After the last of 16 mounting screws has been removed from an access
cover, it will be discovered that the wrong access cover has been removed.

_______________________________________________
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 OAA12907 for <[e-mail]>; Fri, 26 Aug 2005 14:39:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8j3q-0003xg-5O; Fri, 26 Aug 2005 14:36:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8j3p-0003x9-5v for [e-mail]; Fri, 26 Aug 2005 14:36:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05843 for <[e-mail]>; Fri, 26 Aug 2005 14:36:15 -0400 (EDT)
Received: from zproxy.gmail.com ([64.233.162.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8j4b-0008AN-A5 for [e-mail]; Fri, 26 Aug 2005 14:37:05 -0400
Received: by zproxy.gmail.com with SMTP id i1so376562nzh for <[e-mail]>; Fri, 26 Aug 2005 11:36:07 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BZZilegPQT96bR89QQi6XKJa+79ak3EhzbApQKIcGn7gdnRFJqrSFdTEDREUQqpF0tvZt7gbcIvG2Orw2gYvBIocpAn9pHsCs4j2sHtidoa63qsqTAsUamNBWCorfXRA3gbgoo9kzbdiO4SUJQtUIOP4Wb3aSg2nCXF+T9yWufA=
Received: by 10.37.13.7 with SMTP id q7mr277839nzi; Fri, 26 Aug 2005 11:36:07 -0700 (PDT)
Received: by 10.36.119.9 with HTTP; Fri, 26 Aug 2005 11:36:07 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sat, 27 Aug 2005 00:06:07 +0530
From: Glen Kent <[e-mail]>
To: Manav Bhatia <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <012001c5aa68$af1e0cb0$6401a8c0@manav>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav> <[e-mail]> <012001c5aa68$af1e0cb0$6401a8c0@manav>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac
Cc: Inter-Domain Routing List <[e-mail]>, Paul Jakma <[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 OAA12907

I think i understand his concern. However, I would be most
uncomfortable with having a different syntaxes for the sets and the
sequences. If the idea is to use two octets then we might as well do
it for both of them.

Enke, what is your concern with increasing the count of ASes (it
should btw never have been called the "length" which is extremely
confusing) to two octets?

This is assuming that the 4byte AS number draft would be reconsidered.
If thats not the case, then we are unnecessarily wasting time and
bandwidth.

Glen

On 8/26/05, Manav Bhatia <[e-mail]> wrote:
> I used this example to state that number of ASes in as_path may NOT be
> proportional to number of hops.
> 
> We could potentially have applications in future (ecmp perhaps?) , which may
> insert more than 255 ASes in an AS_SET. There we could have scenarios where
> one may want to preserve the as_path length and may not want it to increase.
> 
> Keeping this upper bound of 255 ASes in an AS_SET looks unreasonable to me.
> The only reason I bring this up is because there is a discussion going on
> related to *_AS_PATH attribute, and this is one thing that can be addressed.
> 
> I would not be very comfortable with this, but if its too much of a hassle
> then we could increase the length to 2 octets for only the *_AS_SET segment
> and not touch the *_AS_SEQUENCE.
> 
> Manav
> 
> ----- Original Message -----
> From: "Enke Chen" <[e-mail]>
> To: "Manav Bhatia" <[e-mail]>
> Cc: "Paul Jakma" <[e-mail]>; "Curtis Villamizar"
> <[e-mail]>; "Inter-Domain Routing List" <[e-mail]>; "Enke
> Chen (enkechen)" <[e-mail]>
> Sent: Friday, August 26, 2005 11:09 PM
> Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
> 
> 
> > Manav Bhatia wrote:
> >
> > >Ok, so the argument is that since an IP packet will never traverse more
> than
> > >255 hops, it makes no sense to have more than 255 ASes in the path.
> > >
> > >This is not even an issue because even if we overflow the ASes in a
> sequence
> > >we can introduce another AS_SEQUENCE.segment and that would work as well.
> > >
> > >
> > Agreed.
> >
> > >The problem is with AS_SETs. If the nos. of elements (i.e. ASes) goes
> beyond
> > >255 then we cant insert another AS_SET segment as that would increase the
> > >path length by 1.
> > >
> > >
> >
> > As long as consistency is maitained with an AS, how is this different
> > from AS prepend (with respect to the path length)?
> >
> > -- Enke
> >
> > >Consider the following two paths:
> > >
> > >as_path {a b} nlri 10.1.1/24
> > >as_path {a1 b1} nlri 10.1.2/24
> > >as_path {a2 b2} nlri 10.1.3/24
> > >
> > >Agrregating this creates as_path [ a a1 a2 b b1 b2] nlri 10.1/16
> > >
> > >Clearly the number of ASes in as_path is NOT proportional to number of
> hops.
> > >
> > >Thanks,
> > >Manav
> > >
> > >----- Original Message -----
> > >From: "Enke Chen" <[e-mail]>
> > >To: "Paul Jakma" <[e-mail]>
> > >Cc: "Curtis Villamizar" <[e-mail]>; "Manav Bhatia"
> > ><[e-mail]>; "Inter-Domain Routing List" <[e-mail]>;
> "Enke
> > >Chen" <[e-mail]>
> > >Sent: Friday, August 26, 2005 8:47 PM
> > >Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
> > >
> > >
> > >
> > >
> > >>The idea indeed came up in 2001, and was dropped based on the following
> > >>reasoning:
> > >>
> > >>     This is not a practical issue considering that the max ttl for ip
> > >>packet (ipv4/ipv6) is only 255.
> > >>
> > >>-- Enke
> > >>
> > >>Paul Jakma wrote:
> > >>
> > >>
> > >>
> > >>>On Fri, 26 Aug 2005, Curtis Villamizar wrote:
> > >>>
> > >>>
> > >>>
> > >>>>The longest legitimate AS paths (not padded) are well under 20 in
> > >>>>length, the vast majority under 10 and typically 5 or less.  The only
> > >>>>practical purpose that allowing more than 255 would serve is to allow
> > >>>>further abuse of AS PATH padding.
> > >>>>
> > >>>>
> > >>>If encoding can be changed beyond the current draft, that can be fixed
> > >>>too.
> > >>>
> > >>>regards,
> > >>>
> > >>>
> 
> 
> _______________________________________________
> 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 OAA10233 for <[e-mail]>; Fri, 26 Aug 2005 14:04:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8iYX-0003RE-2O; Fri, 26 Aug 2005 14:03:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8iYV-0003Qx-AI for [e-mail]; Fri, 26 Aug 2005 14:03:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04563 for <[e-mail]>; Fri, 26 Aug 2005 14:03:53 -0400 (EDT)
Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8iZE-0007Fb-BE for [e-mail]; Fri, 26 Aug 2005 14:04:42 -0400
Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id LAA22996; Fri, 26 Aug 2005 11:02:25 -0700 (PDT)
Received: from manav ([134.141.188.136]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Aug 2005 11:02:24 -0700
Message-ID: <012001c5aa68$af1e0cb0$6401a8c0@manav>
From: "Manav Bhatia" <[e-mail]>
To: "Enke Chen" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav> <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Date: Fri, 26 Aug 2005 23:35:00 +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.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-OriginalArrivalTime: 26 Aug 2005 18:02:24.0813 (UTC) FILETIME=[502945D0:01C5AA68]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Content-Transfer-Encoding: 7bit
Cc: Inter-Domain Routing List <[e-mail]>, Paul Jakma <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

I used this example to state that number of ASes in as_path may NOT be
proportional to number of hops.

We could potentially have applications in future (ecmp perhaps?) , which may
insert more than 255 ASes in an AS_SET. There we could have scenarios where
one may want to preserve the as_path length and may not want it to increase.

Keeping this upper bound of 255 ASes in an AS_SET looks unreasonable to me.
The only reason I bring this up is because there is a discussion going on
related to *_AS_PATH attribute, and this is one thing that can be addressed.

I would not be very comfortable with this, but if its too much of a hassle
then we could increase the length to 2 octets for only the *_AS_SET segment
and not touch the *_AS_SEQUENCE.

Manav

----- Original Message ----- 
From: "Enke Chen" <[e-mail]>
To: "Manav Bhatia" <[e-mail]>
Cc: "Paul Jakma" <[e-mail]>; "Curtis Villamizar"
<[e-mail]>; "Inter-Domain Routing List" <[e-mail]>; "Enke
Chen (enkechen)" <[e-mail]>
Sent: Friday, August 26, 2005 11:09 PM
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?


> Manav Bhatia wrote:
>
> >Ok, so the argument is that since an IP packet will never traverse more
than
> >255 hops, it makes no sense to have more than 255 ASes in the path.
> >
> >This is not even an issue because even if we overflow the ASes in a
sequence
> >we can introduce another AS_SEQUENCE.segment and that would work as well.
> >
> >
> Agreed.
>
> >The problem is with AS_SETs. If the nos. of elements (i.e. ASes) goes
beyond
> >255 then we cant insert another AS_SET segment as that would increase the
> >path length by 1.
> >
> >
>
> As long as consistency is maitained with an AS, how is this different
> from AS prepend (with respect to the path length)?
>
> -- Enke
>
> >Consider the following two paths:
> >
> >as_path {a b} nlri 10.1.1/24
> >as_path {a1 b1} nlri 10.1.2/24
> >as_path {a2 b2} nlri 10.1.3/24
> >
> >Agrregating this creates as_path [ a a1 a2 b b1 b2] nlri 10.1/16
> >
> >Clearly the number of ASes in as_path is NOT proportional to number of
hops.
> >
> >Thanks,
> >Manav
> >
> >----- Original Message ----- 
> >From: "Enke Chen" <[e-mail]>
> >To: "Paul Jakma" <[e-mail]>
> >Cc: "Curtis Villamizar" <[e-mail]>; "Manav Bhatia"
> ><[e-mail]>; "Inter-Domain Routing List" <[e-mail]>;
"Enke
> >Chen" <[e-mail]>
> >Sent: Friday, August 26, 2005 8:47 PM
> >Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
> >
> >
> >
> >
> >>The idea indeed came up in 2001, and was dropped based on the following
> >>reasoning:
> >>
> >>     This is not a practical issue considering that the max ttl for ip
> >>packet (ipv4/ipv6) is only 255.
> >>
> >>-- Enke
> >>
> >>Paul Jakma wrote:
> >>
> >>
> >>
> >>>On Fri, 26 Aug 2005, Curtis Villamizar wrote:
> >>>
> >>>
> >>>
> >>>>The longest legitimate AS paths (not padded) are well under 20 in
> >>>>length, the vast majority under 10 and typically 5 or less.  The only
> >>>>practical purpose that allowing more than 255 would serve is to allow
> >>>>further abuse of AS PATH padding.
> >>>>
> >>>>
> >>>If encoding can be changed beyond the current draft, that can be fixed
> >>>too.
> >>>
> >>>regards,
> >>>
> >>>


_______________________________________________
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 NAA08503 for <[e-mail]>; Fri, 26 Aug 2005 13:42:20 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8iBU-0004x3-3G; Fri, 26 Aug 2005 13:40:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8iBS-0004ww-BM for [e-mail]; Fri, 26 Aug 2005 13:40:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03512 for <[e-mail]>; Fri, 26 Aug 2005 13:40:05 -0400 (EDT)
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8iCD-0006Ww-5N for [e-mail]; Fri, 26 Aug 2005 13:40:54 -0400
Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 26 Aug 2005 10:39:56 -0700
Received: from [128.107.134.9] (enke-linux.cisco.com [128.107.134.9]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7QHdp2i015747; Fri, 26 Aug 2005 10:39:53 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 26 Aug 2005 10:39:51 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Manav Bhatia <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
References: <[e-mail]> <[e-mail]> <[e-mail]> <00fe01c5aa62$f62e8d10$6401a8c0@manav>
In-Reply-To: <00fe01c5aa62$f62e8d10$6401a8c0@manav>
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: 7bit
Cc: Inter-Domain Routing List <[e-mail]>, Paul Jakma <[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]

Manav Bhatia wrote:

>Ok, so the argument is that since an IP packet will never traverse more than
>255 hops, it makes no sense to have more than 255 ASes in the path.
>
>This is not even an issue because even if we overflow the ASes in a sequence
>we can introduce another AS_SEQUENCE.segment and that would work as well.
>  
>
Agreed.

>The problem is with AS_SETs. If the nos. of elements (i.e. ASes) goes beyond
>255 then we cant insert another AS_SET segment as that would increase the
>path length by 1.
>  
>

As long as consistency is maitained with an AS, how is this different 
from AS prepend (with respect to the path length)?

-- Enke

>Consider the following two paths:
>
>as_path {a b} nlri 10.1.1/24
>as_path {a1 b1} nlri 10.1.2/24
>as_path {a2 b2} nlri 10.1.3/24
>
>Agrregating this creates as_path [ a a1 a2 b b1 b2] nlri 10.1/16
>
>Clearly the number of ASes in as_path is NOT proportional to number of hops.
>
>Thanks,
>Manav
>
>----- Original Message ----- 
>From: "Enke Chen" <[e-mail]>
>To: "Paul Jakma" <[e-mail]>
>Cc: "Curtis Villamizar" <[e-mail]>; "Manav Bhatia"
><[e-mail]>; "Inter-Domain Routing List" <[e-mail]>; "Enke
>Chen" <[e-mail]>
>Sent: Friday, August 26, 2005 8:47 PM
>Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
>
>
>  
>
>>The idea indeed came up in 2001, and was dropped based on the following
>>reasoning:
>>
>>     This is not a practical issue considering that the max ttl for ip
>>packet (ipv4/ipv6) is only 255.
>>
>>-- Enke
>>
>>Paul Jakma wrote:
>>
>>    
>>
>>>On Fri, 26 Aug 2005, Curtis Villamizar wrote:
>>>
>>>      
>>>
>>>>The longest legitimate AS paths (not padded) are well under 20 in
>>>>length, the vast majority under 10 and typically 5 or less.  The only
>>>>practical purpose that allowing more than 255 would serve is to allow
>>>>further abuse of AS PATH padding.
>>>>        
>>>>
>>>If encoding can be changed beyond the current draft, that can be fixed
>>>too.
>>>
>>>regards,
>>>      
>>>

_______________________________________________
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 NAA08076 for <[e-mail]>; Fri, 26 Aug 2005 13:37:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8i8G-00044c-1R; Fri, 26 Aug 2005 13:36:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8i8D-00044P-RA for [e-mail]; Fri, 26 Aug 2005 13:36:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03326 for <[e-mail]>; Fri, 26 Aug 2005 13:36:44 -0400 (EDT)
Received: from [192.20.225.110] (helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8i8y-0006RG-NZ for [e-mail]; Fri, 26 Aug 2005 13:37:33 -0400
Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id C477C8519; Fri, 26 Aug 2005 13:36:35 -0400 (EDT)
Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j7QHaZnF029291;  Fri, 26 Aug 2005 13:36:35 -0400
From: Bill Fenner <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: Pekka Savola <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Fri, 26 Aug 2005 13:36:35 -0400
Versions: dmail (linux) 2.7/makemail 2.14
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: [e-mail], [e-mail]
Subject: [Idr] Re: draft-ietf-idr-rfc2858bis-07.txt, SAFI=3 removed?
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 implementation report showed 2 implementations that implement SAFI
3 for receive-only (presumably they would apply the update to individual
SAFI 2 and SAFI 1 RIBs and advertise it seperately when propogating) and
3 implementations that do not implement SAFI 3.  Features that have not
been implemented need to be removed when going to Draft Standard (but the
SAFI is reserved, so it would be possible to document SAFI 3 in a Proposed
Standard if people thought it was important to have a document for).

  Bill

_______________________________________________
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 NAA07124 for <[e-mail]>; Fri, 26 Aug 2005 13:25:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hwn-0007qQ-P9; Fri, 26 Aug 2005 13:24:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hwl-0007pm-Nm for [e-mail]; Fri, 26 Aug 2005 13:24:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02670 for <[e-mail]>; Fri, 26 Aug 2005 13:24:52 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8hxW-00060S-El for [e-mail]; Fri, 26 Aug 2005 13:25:43 -0400
Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 26 Aug 2005 10:24:45 -0700
X-IronPort-AV: i="3.96,144,1122879600";  d="scan'208"; a="207853560:sNHT29563584"
Received: from [128.107.134.9] (enke-linux.cisco.com [128.107.134.9]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7QHOg2i009955; Fri, 26 Aug 2005 10:24:43 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 26 Aug 2005 10:24:42 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Cc: Inter-Domain Routing List <[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]

Paul Jakma wrote:

> On Fri, 26 Aug 2005, Paul Jakma wrote:
>
[snip]

> - add some reserved space, for future proofing
> (eg, if we ever need 64bit ASNs ;), or need to signal other
> types of encoding changes.)

As you indicated in a previous email, the 1:<xx> might last for 20 years :-)
So the 4-byte AS numbers may last for at least tens of thousands of 
years :-)

>
> - add Tony Li's (et al) hopcount-TTL to the AS_PATH, rather than as a
> seperate attribute


They are of different semantics. The hopcount can only be inserted by 
one AS, and is optional. It is also expected that only a (small) subset 
of the routes would need/do the hopcount attribute. IMHO the hopcount 
attribute should stay as is.

Regards,

-- 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 NAA07035 for <[e-mail]>; Fri, 26 Aug 2005 13:24:18 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hu0-0007Ca-9R; Fri, 26 Aug 2005 13:22:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hty-0007Ap-GT for [e-mail]; Fri, 26 Aug 2005 13:22:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02529 for <[e-mail]>; Fri, 26 Aug 2005 13:21:57 -0400 (EDT)
Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8hug-0005tA-Ko for [e-mail]; Fri, 26 Aug 2005 13:22:48 -0400
Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id KAA16099; Fri, 26 Aug 2005 10:21:27 -0700 (PDT)
Received: from manav ([134.141.188.136]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Aug 2005 10:21:26 -0700
Message-ID: <00fe01c5aa62$f62e8d10$6401a8c0@manav>
From: "Manav Bhatia" <[e-mail]>
To: "Enke Chen" <[e-mail]>, "Paul Jakma" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Date: Fri, 26 Aug 2005 22:53:51 +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.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-OriginalArrivalTime: 26 Aug 2005 17:21:27.0235 (UTC) FILETIME=[9754A130:01C5AA62]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: Inter-Domain Routing List <[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]

Ok, so the argument is that since an IP packet will never traverse more than
255 hops, it makes no sense to have more than 255 ASes in the path.

This is not even an issue because even if we overflow the ASes in a sequence
we can introduce another AS_SEQUENCE.segment and that would work as well.

The problem is with AS_SETs. If the nos. of elements (i.e. ASes) goes beyond
255 then we cant insert another AS_SET segment as that would increase the
path length by 1.

Consider the following two paths:

as_path {a b} nlri 10.1.1/24
as_path {a1 b1} nlri 10.1.2/24
as_path {a2 b2} nlri 10.1.3/24

Agrregating this creates as_path [ a a1 a2 b b1 b2] nlri 10.1/16

Clearly the number of ASes in as_path is NOT proportional to number of hops.

Thanks,
Manav

----- Original Message ----- 
From: "Enke Chen" <[e-mail]>
To: "Paul Jakma" <[e-mail]>
Cc: "Curtis Villamizar" <[e-mail]>; "Manav Bhatia"
<[e-mail]>; "Inter-Domain Routing List" <[e-mail]>; "Enke
Chen" <[e-mail]>
Sent: Friday, August 26, 2005 8:47 PM
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?


> The idea indeed came up in 2001, and was dropped based on the following
> reasoning:
>
>      This is not a practical issue considering that the max ttl for ip
> packet (ipv4/ipv6) is only 255.
>
> -- Enke
>
> Paul Jakma wrote:
>
> > On Fri, 26 Aug 2005, Curtis Villamizar wrote:
> >
> >> The longest legitimate AS paths (not padded) are well under 20 in
> >> length, the vast majority under 10 and typically 5 or less.  The only
> >> practical purpose that allowing more than 255 would serve is to allow
> >> further abuse of AS PATH padding.
> >
> >
> > If encoding can be changed beyond the current draft, that can be fixed
> > too.
> >
> > regards,


_______________________________________________
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 NAA06327 for <[e-mail]>; Fri, 26 Aug 2005 13:14:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hmY-00057S-DQ; Fri, 26 Aug 2005 13:14:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hmW-00055z-7s for [e-mail]; Fri, 26 Aug 2005 13:14:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02169 for <[e-mail]>; Fri, 26 Aug 2005 13:14:17 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8hnG-0005fQ-Ss for [e-mail]; Fri, 26 Aug 2005 13:15:08 -0400
Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 26 Aug 2005 10:14:11 -0700
X-IronPort-AV: i="3.96,144,1122879600";  d="scan'208"; a="207852066:sNHT30243236"
Received: from [128.107.134.9] (enke-linux.cisco.com [128.107.134.9]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7QHDwZ1012262; Fri, 26 Aug 2005 10:13:58 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 26 Aug 2005 10:14:02 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Jakma <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Cc: Manav Bhatia <[e-mail]>, Inter-Domain Routing List <[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 BGP base spec actually allows one to carry more than 255 AS numbers 
in the AS-PATH attribute using multiple segments. There is really no 
need to optimize for this unlikely scenario.

Regards,

-- Enke

Paul Jakma wrote:

> On Fri, 26 Aug 2005, Enke Chen wrote:
>
>> This is not a practical issue considering that the max ttl for ip 
>> packet (ipv4/ipv6) is only 255.
>
>
> True yes.
>
> But, unlike IP TTL, the AS-Path can represent not just the length, but 
> also the /width/.
>
> regards,


_______________________________________________
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 MAA03239 for <[e-mail]>; Fri, 26 Aug 2005 12:35:20 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8h8V-0002Rv-GF; Fri, 26 Aug 2005 12:32:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8h8T-0002Rq-S1 for [e-mail]; Fri, 26 Aug 2005 12:32:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00532 for <[e-mail]>; Fri, 26 Aug 2005 12:32:55 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX18xwOoBbvHVOa92hGDW1hta51SRom3qqZI=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8h9B-0004S5-Nz for [e-mail]; Fri, 26 Aug 2005 12:33:45 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7QGWcY8027714; Fri, 26 Aug 2005 17:32:50 +0100
Date: Fri, 26 Aug 2005 17:32:38 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Yakov Rekhter <[e-mail]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
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 Tue, 23 Aug 2005, Paul Jakma wrote:

> If we could reclaim ASN 1 (Level-3 stopped using it I think) and 
> reserve it, and hence guarantee the byte sequences "0x00 0x01" and 
> "0x00 0x00"

Actually given AS1 isn't possible: any existing unused AS number will 
do, eg, AS_TRANS ;). Just have IANA assign 4-octets ASNs from the 
23456:x block at first.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Q:	What's a light-year?
A:	One-third less calories than a regular year.

_______________________________________________
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 LAA28407 for <[e-mail]>; Fri, 26 Aug 2005 11:29:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8g73-0006JC-J3; Fri, 26 Aug 2005 11:27:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8g72-0006J2-Bt for [e-mail]; Fri, 26 Aug 2005 11:27:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26784 for <[e-mail]>; Fri, 26 Aug 2005 11:27:22 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/W7UpppjQeg1qBGl612XK+w+qPDJizE5E=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8g7l-00023n-QI for [e-mail]; Fri, 26 Aug 2005 11:28:11 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7QFPuDi027003; Fri, 26 Aug 2005 16:26:08 +0100
Date: Fri, 26 Aug 2005 16:25:55 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: Manav Bhatia <[e-mail]>, Inter-Domain Routing List <[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 Fri, 26 Aug 2005, Enke Chen wrote:

>    This is not a practical issue considering that the max ttl for ip packet 
> (ipv4/ipv6) is only 255.

True yes.

But, unlike IP TTL, the AS-Path can represent not just the length, 
but also the /width/.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
The default Magic Word, "Abracadabra", actually is a corruption of the
Hebrew phrase "ha-Bracha dab'ra" which means "pronounce the blessing".

_______________________________________________
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 LAA27322 for <[e-mail]>; Fri, 26 Aug 2005 11:17:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fxT-00049E-4t; Fri, 26 Aug 2005 11:17:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fxR-000487-QD for [e-mail]; Fri, 26 Aug 2005 11:17:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26124 for <[e-mail]>; Fri, 26 Aug 2005 11:17:27 -0400 (EDT)
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.43) id 1E8fyB-0001h6-9z for [e-mail]; Fri, 26 Aug 2005 11:18:16 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 26 Aug 2005 08:17:20 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7QFGe0l029492; Fri, 26 Aug 2005 08:17:12 -0700 (PDT)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 08:17:06 -0700
Received: from [10.21.123.108] ([10.21.123.108]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);  Fri, 26 Aug 2005 08:17:06 -0700
Message-ID: <[e-mail]>
Date: Fri, 26 Aug 2005 08:17:04 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Jakma <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Aug 2005 15:17:06.0476 (UTC) FILETIME=[385F26C0:01C5AA51]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Cc: Manav Bhatia <[e-mail]>, Inter-Domain Routing List <[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 idea indeed came up in 2001, and was dropped based on the following 
reasoning:

     This is not a practical issue considering that the max ttl for ip 
packet (ipv4/ipv6) is only 255.

-- Enke

Paul Jakma wrote:

> On Fri, 26 Aug 2005, Curtis Villamizar wrote:
>
>> The longest legitimate AS paths (not padded) are well under 20 in
>> length, the vast majority under 10 and typically 5 or less.  The only
>> practical purpose that allowing more than 255 would serve is to allow
>> further abuse of AS PATH padding.
>
>
> If encoding can be changed beyond the current draft, that can be fixed 
> too.
>
> regards,

_______________________________________________
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 LAA26580 for <[e-mail]>; Fri, 26 Aug 2005 11:10:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fpy-0000qC-S5; Fri, 26 Aug 2005 11:09:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fpx-0000pw-BC for [e-mail]; Fri, 26 Aug 2005 11:09:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25569 for <[e-mail]>; Fri, 26 Aug 2005 11:09:43 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/SEc7qwuViWFNlQ55eL116kBgjX4+n8M4=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fqf-0001M0-TP for [e-mail]; Fri, 26 Aug 2005 11:10:32 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7QF86tc026647; Fri, 26 Aug 2005 16:08:18 +0100
Date: Fri, 26 Aug 2005 16:08:06 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Curtis Villamizar <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come? 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: Manav Bhatia <[e-mail]>, Inter-Domain Routing List <[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 Fri, 26 Aug 2005, Curtis Villamizar wrote:

> The longest legitimate AS paths (not padded) are well under 20 in
> length, the vast majority under 10 and typically 5 or less.  The only
> practical purpose that allowing more than 255 would serve is to allow
> further abuse of AS PATH padding.

If encoding can be changed beyond the current draft, that can be 
fixed too.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
You definitely intend to start living sometime soon.

_______________________________________________
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 LAA26156 for <[e-mail]>; Fri, 26 Aug 2005 11:05:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8flC-0008Rl-MQ; Fri, 26 Aug 2005 11:04:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8flB-0008Rg-Cn for [e-mail]; Fri, 26 Aug 2005 11:04:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25317 for <[e-mail]>; Fri, 26 Aug 2005 11:04:47 -0400 (EDT)
Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E8flu-0001CB-Pm for [e-mail]; Fri, 26 Aug 2005 11:05:36 -0400
Received: (qmail 75326 invoked from network); 26 Aug 2005 15:04:40 -0000
Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 26 Aug 2005 15:04:40 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j7QF4nMG050206; Fri, 26 Aug 2005 11:04:52 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Manav Bhatia" <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come? 
In-reply-to: Your message of "Fri, 26 Aug 2005 18:50:49 +0530." <007401c5aa40$fbf455d0$6401a8c0@manav> 
Date: Fri, 26 Aug 2005 11:04:49 -0400
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: Inter-Domain Routing List <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <007401c5aa40$fbf455d0$6401a8c0@manav>
"Manav Bhatia" writes:
>  
> Yes, if there is a thought to revisit the *_AS_PATH path attribute
> then i would personally want to see (i) an increase in the segment
> length field (to support more than 255 ASes) from the current one
> octet to 2 octets and (ii) perhaps a reserved field for future
> extensions.
>  
> Cheers,
> Manav


The longest legitimate AS paths (not padded) are well under 20 in
length, the vast majority under 10 and typically 5 or less.  The only
practical purpose that allowing more than 255 would serve is to allow
further abuse of AS PATH padding.

Curtis

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA17846 for <[e-mail]>; Fri, 26 Aug 2005 09:20:07 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8e6Y-0004ce-Ru; Fri, 26 Aug 2005 09:18:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8e6X-0004cZ-05 for [e-mail]; Fri, 26 Aug 2005 09:18:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18660 for <[e-mail]>; Fri, 26 Aug 2005 09:18:43 -0400 (EDT)
Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8e7E-0006Av-Cf for [e-mail]; Fri, 26 Aug 2005 09:19:30 -0400
Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id GAA10220; Fri, 26 Aug 2005 06:18:15 -0700 (PDT)
Received: from manav ([134.141.188.136]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Aug 2005 06:18:14 -0700
Message-ID: <007401c5aa40$fbf455d0$6401a8c0@manav>
From: "Manav Bhatia" <[e-mail]>
To: <[e-mail]>, "Inter-Domain Routing List" <[e-mail]>, "Enke Chen" <[e-mail]>
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
Date: Fri, 26 Aug 2005 18:50:49 +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.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-OriginalArrivalTime: 26 Aug 2005 13:18:15.0074 (UTC) FILETIME=[9DB99020:01C5AA40]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit
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]

Yes, if there is a thought to revisit the *_AS_PATH path attribute then i
would personally want to see (i) an increase in the segment length field (to
support more than 255 ASes) from the current one octet to 2 octets and (ii)
perhaps a reserved field for future extensions.

Cheers,
Manav

----- Original Message ----- 
From: "Paul Jakma" <[e-mail]>
To: "Enke Chen" <[e-mail]>
Cc: "Inter-Domain Routing List" <[e-mail]>
Sent: Friday, August 26, 2005 3:35 PM
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?


> On Fri, 26 Aug 2005, Paul Jakma wrote:
>
> > Eg, we could disassociate path-length from the actual path
> > information, and instead put an explicit path-length field in the
> > AS_PATH (or better, NEW_AS_PATH ;) ). This would remove the need
> > for AS_PATH prepending, you could instead simply increment the
> > path-length field by more than one.
>
> Other possibilities:
>
> - increase the segment length field width to two octets, for future
>    proofing.
>    (This suggestion, in private, is what got me thinking about other
>     possibilities if AS_PATH encoding is on the table)
>
> - add some reserved space, for future proofing
>    (eg, if we ever need 64bit ASNs ;), or need to signal other
>     types of encoding changes.)
>
> - add Tony Li's (et al) hopcount-TTL to the AS_PATH, rather than as a
>    seperate attribute
>
> regards,
> -- 
> Paul Jakma [e-mail] [e-mail] Key ID: 64A2FF6A
> Fortune:
> Two peanuts were walking through the New York.  One was assaulted.
>
> _______________________________________________
> 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 GAA02350 for <[e-mail]>; Fri, 26 Aug 2005 06:07:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8b5l-0003nI-J4; Fri, 26 Aug 2005 06:05:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8b5k-0003nD-2H for [e-mail]; Fri, 26 Aug 2005 06:05:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08657 for <[e-mail]>; Fri, 26 Aug 2005 06:05:41 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX182pTaDAE59cLZIxW4auj1eB3HqdXbUmWU=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8b6Q-0008Pn-EE for [e-mail]; Fri, 26 Aug 2005 06:06:28 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7QA5Nw1023354; Fri, 26 Aug 2005 11:05:35 +0100
Date: Fri, 26 Aug 2005 11:05:23 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: Inter-Domain Routing List <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail], Inter-Domain Routing List <[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]

On Fri, 26 Aug 2005, Paul Jakma wrote:

> Eg, we could disassociate path-length from the actual path 
> information, and instead put an explicit path-length field in the 
> AS_PATH (or better, NEW_AS_PATH ;) ). This would remove the need 
> for AS_PATH prepending, you could instead simply increment the 
> path-length field by more than one.

Other possibilities:

- increase the segment length field width to two octets, for future
   proofing.
   (This suggestion, in private, is what got me thinking about other
    possibilities if AS_PATH encoding is on the table)

- add some reserved space, for future proofing
   (eg, if we ever need 64bit ASNs ;), or need to signal other
    types of encoding changes.)

- add Tony Li's (et al) hopcount-TTL to the AS_PATH, rather than as a
   seperate attribute

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Two peanuts were walking through the New York.  One was assaulted.

_______________________________________________
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 EAA23647 for <[e-mail]>; Fri, 26 Aug 2005 04:17:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8ZOd-0005iz-CO; Fri, 26 Aug 2005 04:17:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8ZOb-0005ip-1P for [e-mail]; Fri, 26 Aug 2005 04:17:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04269 for <[e-mail]>; Fri, 26 Aug 2005 04:17:02 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8ZPE-0004v0-8H for [e-mail]; Fri, 26 Aug 2005 04:17:47 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7Q8GN2x022288; Fri, 26 Aug 2005 09:16:35 +0100
Date: Fri, 26 Aug 2005 09:16:23 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: Inter-Domain Routing List <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail], Inter-Domain Routing List <[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]

On Wed, 24 Aug 2005, Paul Jakma wrote:

> Further, given I'm the only person here who seems concerned enough 
> about either the "observer" issue or the more philosophical 
> "attributes should be self-standing" issue to think the draft 
> should be changed even if it invalidates existing implementations, 
> and several others have disagreed, I withdraw my objection to the 
> draft.

BTW, this is not an objection, but the thought struck me that if 
we're revisiting syntax of AS_PATH that we should, before proceeding, 
consider whether there are any /other/ issues or improvements in 
current AS_PATH which we should fix besides the ASN size.

Eg, we could disassociate path-length from the actual path 
information, and instead put an explicit path-length field in the 
AS_PATH (or better, NEW_AS_PATH ;) ). This would remove the need for 
AS_PATH prepending, you could instead simply increment the 
path-length field by more than one.

The actual path information would then be dimensionless, though it's 
order would be of great administrative interest.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
What is the sound of one hand clapping?

_______________________________________________
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 FAA06904 for <[e-mail]>; Thu, 25 Aug 2005 05:30:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8DzQ-0004NA-1e; Thu, 25 Aug 2005 05:25:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8DzO-0004N2-SX for [e-mail]; Thu, 25 Aug 2005 05:25:39 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09067 for <[e-mail]>; Thu, 25 Aug 2005 05:25:36 -0400 (EDT)
Received: from bay17-f25.bay17.hotmail.com ([64.4.43.75] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Dzq-0004rG-BJ for [e-mail]; Thu, 25 Aug 2005 05:26:10 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 25 Aug 2005 02:25:25 -0700
Message-ID: <[e-mail]>
Received: from 69.45.64.98 by by17fd.bay17.hotmail.msn.com with HTTP; Thu, 25 Aug 2005 09:25:24 GMT
X-Originating-IP: [202.144.106.188]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "john smith" <[e-mail]>
To: [e-mail]
Date: Thu, 25 Aug 2005 09:25:24 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 25 Aug 2005 09:25:25.0341 (UTC) FILETIME=[ECB3B8D0:01C5A956]
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Subject: [Idr] any AFI/SAFI for DNS
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,

Is there any SAFI/AFI for carrying DNS in BGP?

-JS

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/


_______________________________________________
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 IAA28191 for <[e-mail]>; Wed, 24 Aug 2005 08:26:20 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7uKV-0001D6-ML; Wed, 24 Aug 2005 08:26:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7uKU-0001D1-2O for [e-mail]; Wed, 24 Aug 2005 08:26:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17446 for <[e-mail]>; Wed, 24 Aug 2005 08:26:05 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/AcegohM8iRYcAYil1ZI+sVfAYcFrBKeQ=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7uKk-0006cr-PI for [e-mail]; Wed, 24 Aug 2005 08:26:25 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7OCOoCN026678; Wed, 24 Aug 2005 13:24:52 +0100
Date: Wed, 24 Aug 2005 13:24:50 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: 4-Byte As Number soon to come?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: Inter-Domain Routing List <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail], Inter-Domain Routing List <[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]

On Wed, 24 Aug 2005, Enke Chen wrote:

>> I think it makes more sense to ALWAYS send the old 16-bit AS path and the 
> new 32-bit AS path attribute
>
> For folks that was involved in the IDR in 2001, you might remember that was 
> the original design. However, it has the flaw of carrying duplicate info even 
> after the world has transitioned to 4-byte AS, and some folks even suggested 
> having a "second transition" to eliminate the 2-byte as-path.  So the idea 
> was dropped.

Above is not a good idea either way, agreed.

Further, given I'm the only person here who seems concerned enough 
about either the "observer" issue or the more philosophical 
"attributes should be self-standing" issue to think the draft should 
be changed even if it invalidates existing implementations, and 
several others have disagreed, I withdraw my objection to the draft.

I still don't think it's ideal, but then I'm the only one standing in 
way of consensus - no more. :)

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
A long-forgotten loved one will appear soon.

Buy the negatives at any price.

_______________________________________________
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 HAA25644 for <[e-mail]>; Wed, 24 Aug 2005 07:40:53 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7tb0-0003Lj-DV; Wed, 24 Aug 2005 07:39:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7tay-0003Le-KI for [e-mail]; Wed, 24 Aug 2005 07:39:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14491 for <[e-mail]>; Wed, 24 Aug 2005 07:39:03 -0400 (EDT)
Received: from gateout02.mbox.net ([165.212.64.22] helo=gwo2.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7tbE-0004mk-Kw for [e-mail]; Wed, 24 Aug 2005 07:39:24 -0400
Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gwo2.mbox.net (Postfix) with SMTP id 972DD164002; Wed, 24 Aug 2005 11:38:36 +0000 (GMT)
Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.17K)  with ESMTP id 413JHXLMI0238Mo2; Wed, 24 Aug 2005 11:38:35 GMT
Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.17K)  with ESMTP id 411JHXLMh0418Mo2; Wed, 24 Aug 2005 11:38:32 GMT
X-USANET-Routed: 2 gwsout-vs R:localhost:1825
Received: from gw4.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.21U); Wed, 24 Aug 2005 11:38:33 GMT
X-USANET-Source: 165.212.116.254 IN   [e-mail] gw4.EXCHPROD.USA.NET
X-USANET-MsgId: XID728JHXLMh2739Xo2
Received: from localhost ([65.247.36.31]) by gw4.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211);  Wed, 24 Aug 2005 05:38:32 -0600
Date: Wed, 24 Aug 2005 07:38:31 -0400
From: Jeffrey Haas <[e-mail]>
To: "Jan Novak (janovak)" <[e-mail]>
Subject: Re: [Idr] draft-ietf-idr-rfc2858bis-07.txt, SAFI=3 removed?
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-OriginalArrivalTime: 24 Aug 2005 11:38:32.0614 (UTC) FILETIME=[5B131C60:01C5A8A0]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: [e-mail], Pekka Savola <[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]

My observation during our development of 2858-related support was
that safi 3 wasn't widely supported.

Additionally, the code may become more complicated for many reasons if you
try to use safi 3.  One simple example is if your packing is such
that you first receive a safi 1, readvertise it and then shortly afterwards
receive a safi 2.  You could then advertise a safi 2 or a safi 3.
However, the implication of advertising a safi 3 was that the safi 1
component was getting a spurious update.

IMO, safi 3 gained us far more complexity than the supposed simplification
for congruent topologies.  Good riddance. :-)

On Wed, Aug 24, 2005 at 10:31:34AM +0200, Jan Novak (janovak) wrote:
> > (Personally, I haven't verified what happens when I advertise all our 
> > BGP prefixes as identically for both unicast and multicast; does that 
> > result in two sets of prefixes for SAFI=1, then SAFI=2 or just 
> > SAFI=3..)
> 
> I think is has been abandoned because nobody ever implemented SAFI=3
> most probably because of possible problems with BGP updates
> packaging/processing when depending on both sources of 
> the prefixes - like this peer can do it, this can't, uni
> prefix has gone, mcast prefix hasn't etc.
> 
> Jan

-- 
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 EAA11692 for <[e-mail]>; Wed, 24 Aug 2005 04:32:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7qfv-0004yH-RQ; Wed, 24 Aug 2005 04:31:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7qfu-0004wT-G9 for [e-mail]; Wed, 24 Aug 2005 04:31:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06865 for <[e-mail]>; Wed, 24 Aug 2005 04:31:57 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7qgB-0007cI-1v for [e-mail]; Wed, 24 Aug 2005 04:32:16 -0400
Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 24 Aug 2005 10:31:47 +0200
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7O8VAVr028532;  Wed, 24 Aug 2005 10:31:44 +0200 (MEST)
Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0);  Wed, 24 Aug 2005 10:31:37 +0200
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"
Subject: RE: [Idr] draft-ietf-idr-rfc2858bis-07.txt, SAFI=3 removed?
Date: Wed, 24 Aug 2005 10:31:34 +0200
Message-ID: <[e-mail]>
Thread-Topic: [Idr] draft-ietf-idr-rfc2858bis-07.txt, SAFI=3 removed?
Thread-Index: AcWob7s9ceMYsT84SW6qcFAweUh2AgAFhqAA
From: "Jan Novak \(janovak\)" <[e-mail]>
To: "Pekka Savola" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 24 Aug 2005 08:31:37.0234 (UTC) FILETIME=[3E2FEF20:01C5A886]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id EAA11692

Hi, 

> (Personally, I haven't verified what happens when I advertise all our 
> BGP prefixes as identically for both unicast and multicast; does that 
> result in two sets of prefixes for SAFI=1, then SAFI=2 or just 
> SAFI=3..)

I think is has been abandoned because nobody ever implemented SAFI=3
most probably because of possible problems with BGP updates
packaging/processing when depending on both sources of 
the prefixes - like this peer can do it, this can't, uni
prefix has gone, mcast prefix hasn't etc.

Jan

_______________________________________________
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 EAA10363 for <[e-mail]>; Wed, 24 Aug 2005 04:15:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7qDJ-00066O-R9; Wed, 24 Aug 2005 04:02:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7qDH-00066C-TP for [e-mail]; Wed, 24 Aug 2005 04:02:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05443 for <[e-mail]>; Wed, 24 Aug 2005 04:02:22 -0400 (EDT)
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.43) id 1E7qDX-0006aC-Ad for [e-mail]; Wed, 24 Aug 2005 04:02:41 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Aug 2005 01:02:12 -0700
X-IronPort-AV: i="3.96,137,1122879600";  d="scan'208"; a="335187750:sNHT30950962"
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7O8220P019017 for <[e-mail]>; Wed, 24 Aug 2005 01:02:08 -0700 (PDT)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 01:02:01 -0700
Received: from [10.21.99.175] ([10.21.99.175]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);  Wed, 24 Aug 2005 01:02:01 -0700
Message-ID: <[e-mail]>
Date: Wed, 24 Aug 2005 01:02:00 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Inter-Domain Routing List <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Aug 2005 08:02:01.0207 (UTC) FILETIME=[1B97B870:01C5A882]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit
Cc: "Enke Chen"@cisco.com
Subject: [Idr] Re: 4-Byte As Number soon to come?
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, folks:

My comment is regarding this suggestion on the NANOG mailing list:

 > I think it makes more sense to ALWAYS send the old 16-bit AS path and 
the new 32-bit AS path attribute

For folks that was involved in the IDR in 2001, you might remember that 
was the original design. However, it has the flaw of carrying duplicate 
info even after the world has transitioned to 4-byte AS, and some folks 
even suggested having a "second transition" to eliminate the 2-byte 
as-path.  So the idea was dropped.

-- Enke
-------------------------------------------------------------------------------------------------------------------


    Re: 4-Byte AS Number soon to come?

    * /From:/ Iljitsch van Beijnum
    * /Date:/ Wed Aug 24 02:59:08 2005

------------------------------------------------------------------------

On 24-aug-2005, at 5:50, Susan Hares wrote:


This is the first of many steps.  And to be fair to the authors, the
process got held up due to the base draft being re-written.
  

So, the key discussion points are (as Yakov has indicated as well):
    a) Are there any technical problems with the specification
    b) Does the specification cause operational problems?
    c) General concerns about the design of the additions to BGP
        (scaling, etc).
  

I find the design less robust than it could be.

What it does is define that toward a neighbor that also supports wide AS 
numbers it will send the AS path with 32-bit AS numbers, and toward a 
neighbor that doesn't support wide AS numbers it sends the AS path with 
16-bit AS numbers and a "new AS path" with 32-bit AS numbers.

I think it makes more sense to ALWAYS send the old 16-bit AS path and 
the new 32-bit AS path attribute. This makes the code path identical for 
the two types of peers, which is less likely to lead to new bugs and 
makes for easier (operational) debugging.

_______________________________________________
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 BAA28704 for <[e-mail]>; Wed, 24 Aug 2005 01:48:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7o7K-0002C0-2u; Wed, 24 Aug 2005 01:48:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7o7H-0002Bv-CV for [e-mail]; Wed, 24 Aug 2005 01:48:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02570 for <[e-mail]>; Wed, 24 Aug 2005 01:48:02 -0400 (EDT)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7o7W-0002dM-8b for [e-mail]; Wed, 24 Aug 2005 01:48:19 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7O5lkR13600; Wed, 24 Aug 2005 08:47:46 +0300
Date: Wed, 24 Aug 2005 08:47:46 +0300 (EEST)
From: Pekka Savola <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[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]
Subject: [Idr] draft-ietf-idr-rfc2858bis-07.txt, SAFI=3 removed?
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,

On Tue, 23 Aug 2005 [e-mail] wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-07.txt

Has the removal of "both unicast and multicast" in MP-BGP update been 
reviewed by multicast communities?

(Personally, I haven't verified what happens when I advertise all our 
BGP prefixes as identically for both unicast and multicast; does that 
result in two sets of prefixes for SAFI=1, then SAFI=2 or just 
SAFI=3..)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
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 BAA27074 for <[e-mail]>; Wed, 24 Aug 2005 01:26:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7nik-00018h-SR; Wed, 24 Aug 2005 01:22:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7nij-00018c-HP for [e-mail]; Wed, 24 Aug 2005 01:22:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01480 for <[e-mail]>; Wed, 24 Aug 2005 01:22:40 -0400 (EDT)
Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7niy-0001ww-Da for [e-mail]; Wed, 24 Aug 2005 01:22:57 -0400
Received: (qmail 58077 invoked from network); 24 Aug 2005 05:22:28 -0000
Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 24 Aug 2005 05:22:28 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j7O5N9iu042237; Wed, 24 Aug 2005 01:23:10 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail], Inter-Domain Routing List <[e-mail]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
In-reply-to: Your message of "Tue, 23 Aug 2005 02:25:00 BST." <[e-mail]> 
Date: Wed, 24 Aug 2005 01:23:09 -0400
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
Paul Jakma writes:
>  
> On Tue, 23 Aug 2005, Geoff Huston wrote:
>  
> > merits some form of correction I would interpret as a positive 
> > attribute of the specification and I would advocate leaving it as 
> > is.
>  
> Straw poll:
>  
> On the question of the current as4bytes IDR working document 
> specifying that the syntax an existing well-known attribute be 
> overriden by an OPEN capability:
>  
> - anyone in favour of leaving the draft as is in this respect?
>  
> (Enke, Geoff, ....?)

Yes.  Leave as is.  Geoff is right.  As a provider I only had a need
to snoop on a BGP session when the BGP implementation was broken and I
was also the one maintaining the code back when we were still running
BGP2 and BGP3 code.  And we did about as much statistics collection of
BGP and other stats collection based on traffic sampling as anyone.

> - anyone in favour of changing the draft to use the new attribute
>    (NEW_AS_PATH) which is specified by the draft?
>  
> (paul, ....?)
>  
> I've floated my balloon, if it goes nowhere, or in wrong direction 
> I'll leave it go :)
>  
> regards,
> -- 
> Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
> Fortune:
> PnPBIOS is a PC specific affliction. Other platforms have more elegantly
> designed but even buggier solutions
>  
>  	- Alan Cox on linux-kernel

Curtis

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA02077 for <[e-mail]>; Tue, 23 Aug 2005 20:05:53 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7iih-0006Yf-Pj; Tue, 23 Aug 2005 20:02:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7iif-0006WT-Uj for [e-mail]; Tue, 23 Aug 2005 20:02:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20879 for <[e-mail]>; Tue, 23 Aug 2005 20:02:16 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/ueBB/Tr9LF/azfbcmRmPsvByDrLcl3j0=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7iis-0002S6-6V for [e-mail]; Tue, 23 Aug 2005 20:02:31 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7O01ox8019771; Wed, 24 Aug 2005 01:01:53 +0100
Date: Wed, 24 Aug 2005 01:01:49 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: Yakov Rekhter <[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]

On Tue, 23 Aug 2005, Enke Chen wrote:

> The numbers 0x00 0x00 will be common even after the transition as 
> the existing 2-byte AS number will be encoded as 0:xx where the 
> first two bytes are zero.

Yep - 0x00 0x00 will be very common and an immediate indicator of '4 
byte' encoding, if found on a 2 octet boundary (it's not a valid AS 
segment header, nor is 0x00 0x01). 0 is not a valid ASN I'm 
reasonably sure (though, havn't checked), so can't be 2-octet.

Course, latching on 0x00 0x00 will not work for AS-Path's which 
contain only 'new' ASNs, Hence we'd need 0x00 0x01 to be reserved in 
2-octet space.

> I just checked Dave Meyer's route-view. AS 1 is still in the routing table.

Ah, oh dear. Who originates it and what? Level3 had deprecated it a 
good while ago I thought, and were slowly decommisioning it.

> However, one interesting stats from that route-view: it seems that 
> 99.9% of the as-path entries consists of just AS_SEQUENCE. For 
> these as-path entries, we can easily tell 2-byte vs 4-byte from the 
> attribute length and seglen (which is the number of AS numbers):

Sadly, not quite.

> attribute_len = segtype (1 byte) + seglen (1 byte) + as_count * AS_SIZE
>
> where as_count is the value in seglen field.

This assumes there is only one segment though, Eg, try:

0x02 0x03 0x00 0x19 0x01 0x56 0x00 0x0c 0x02 0x02 0x00 0x41 0xc9 0x89

Is that a single AS_SEQUENCE segment with 3 4-octet ASN's, or is it 
two 2-octet segments after each other, first with 3 ASN's, the second 
with two?

> This equation can only be true with AS_SIZE = 2, or 4, but not both.

How did you get the data from route-view? You need to look at the raw 
data to be sure that 99.9% of paths consist of /one/ AS_SEQUENCE ;). 
(I'll admit such constructions would be highly odd and unusual though 
- but I have no figures).

Also, route-views can be an odd view of the internet. The oddness may 
be hidden from it, or simply swamped by many many multiple copies of 
more 'normal' AS_PATHs.

> So there are several options for these "standalone" tools:
>
> 1) A user configurable knob: 100% accuracy.
>
> 2) Use the attribute length and seglen: >99.9% accuracy.

If you assume single segments are 99.9%, sure - and then that is (i 
/think/) 99.9*99.9 = 98.9% probability.

Each seperate corner case lowers the probability.

> 3) Use the existence of "0x00 0x00": 100% accuracy when mappable AS exists.

When, yes.

> 4) Combine #2 and #3.
>
> 5) Combine #2 and #3, and then #1 as last resort.
>
> Do we still need more options :-)

It's a lot of heuristics to put together when the draft really just 
could say:

 	If (attribute code == NEW_AS_PATH)
             || (attribute code == NEW_AGGREGATOR)
 	  sizeof (ASN): 4 octets
         else
 	  sizeof (ASN): 2 octets

And we'd be covered 100% without resorting to 99% heuristics.

But hey. ;)

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Moderation is a fatal thing.  Nothing succeeds like excess.
 		-- Oscar Wilde

_______________________________________________
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 TAA28853 for <[e-mail]>; Tue, 23 Aug 2005 19:25:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7i5v-0002Gz-6V; Tue, 23 Aug 2005 19:22:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7i5s-0002Gr-V1 for [e-mail]; Tue, 23 Aug 2005 19:22:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19016 for <[e-mail]>; Tue, 23 Aug 2005 19:22:09 -0400 (EDT)
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.43) id 1E7i65-0001Nm-P9 for [e-mail]; Tue, 23 Aug 2005 19:22:26 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Aug 2005 16:22:04 -0700
Received: from [128.107.134.9] (enke-linux.cisco.com [128.107.134.9]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7NNM1oo019717; Tue, 23 Aug 2005 16:22:01 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 23 Aug 2005 16:21:58 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Jakma <[e-mail]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Content-Transfer-Encoding: 7bit
Cc: Yakov Rekhter <[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]

Hi, Paul:

[snip]

>
>
> A hopefully fair analysis:
>
> In practice, in bulk of cases it likely would be posssible to figure 
> out which encoding is used; parsing with either 2 or 4 octet encoding 
> would quickly show one encoding to be implausible (eg a byte which 
> should be length but which claims a segment extends past end of the 
> data, or because you encounter 0x00 0x00 - which could only be valid 
> for a 4-octet encoded AS_PATH, and will be common during the 
> transition period.


The numbers 0x00 0x00 will be common even after the transition as the 
existing 2-byte AS number will be encoded as 0:xx where the first two 
bytes are zero.

> One hopes OLD speakers quickly would be deprecated once the first 
> 4-octet ASN is used. Though, you have a very long comfort 'zone', at 
> least for as long as ASN-1 is not reused by Level3 or whoever owns it 
> now.).
> However, there will be AS_PATHs which will, syntactically, seem 
> plausible for either encoding. Those will require further inspection 
> (eg by checking which ASNs actually are assigned by IANA or even RIRs).
>
> Further, you won't be able to discriminate easily between whether an 
> AS_PATH is incorrectly generated or corrupted and case of having used 
> wrong ASN octet size to parse it.
>
> (Geoff, I guess, would be quick to point out that this would not be a 
> problem for the BGP speakers concerned - they know their state.)
>
> If we could reclaim ASN 1 (Level-3 stopped using it I think) and 
> reserve it, and hence guarantee the byte sequences "0x00 0x01" and 
> "0x00 0x00" would /reliably/ indicate 4-byte encoding, then we could 
> (i think) reliably distinguish between encodings, until the first 
> "0x00 0x02 .. .." ASN is handed out - which wouldn't be for 20+ years, 
> one would imagine.


I just checked Dave Meyer's route-view. AS 1 is still in the routing table.

However, one interesting stats from that route-view: it seems that 99.9% 
of the as-path entries consists of just AS_SEQUENCE. For these as-path 
entries, we can easily tell 2-byte vs 4-byte from the attribute length 
and seglen (which is the number of AS numbers):

attribute_len = segtype (1 byte) + seglen (1 byte) + as_count * AS_SIZE

where as_count is the value in seglen field.

This equation can only be true with AS_SIZE = 2, or 4, but not both.

So there are several options for these "standalone" tools:

1) A user configurable knob: 100% accuracy.

2) Use the attribute length and seglen: >99.9% accuracy.

3) Use the existence of "0x00 0x00": 100% accuracy when mappable AS exists.

4) Combine #2 and #3.

5) Combine #2 and #3, and then #1 as last resort.

Do we still need more options :-)

Regards,

-- 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 QAA14454 for <[e-mail]>; Tue, 23 Aug 2005 16:21:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7fEO-0005Xs-71; Tue, 23 Aug 2005 16:18:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7fEN-0005WP-GR for [e-mail]; Tue, 23 Aug 2005 16:18:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03779 for <[e-mail]>; Tue, 23 Aug 2005 16:18:45 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7fEX-0002ZM-7i for [e-mail]; Tue, 23 Aug 2005 16:18:59 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j7NKISBm028301 for <[e-mail]>; Tue, 23 Aug 2005 13:18:28 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7NKISG10054 for <[e-mail]>; Tue, 23 Aug 2005 13:18:28 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2858bis-07.txt
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 23 Aug 2005 13:18:27 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Folks,

The revised draft (see attached) reflects the consensus among
those who participated in the discussion on the IANA section
of the draft.

Yakov.
------- Forwarded Message

Date:    Tue, 23 Aug 2005 15:50:01 -0400
From:    [e-mail]
To:      [e-mail]
cc:      [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2858bis-07.txt 

- --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		: Multiprotocol Extensions for BGP-4
	Author(s)	: T. Bates, et al.
	Filename	: draft-ietf-idr-rfc2858bis-07.txt
	Pages		: 12
	Date		: 2005-8-23
	
Currently BGP-4 is capable of carrying routing information only for
   IPv4. This document defines extensions to BGP-4 to enable it to carry
   routing information for multiple Network Layer protocols (e.g., IPv6,
   IPX, etc...). The extensions are backward compatible - a router that
   supports the extensions can interoperate with a router that doesn't
   support the extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-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 mess
age.  
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-rfc2858bis-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-rfc2858bis-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-rfc2858bis-07.txt

- --OtherAccess
Content-Type: Message/External-body; name="draft-ietf-idr-rfc2858bis-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--

------- End of Forwarded Message


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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA13679 for <[e-mail]>; Tue, 23 Aug 2005 16:11:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7en8-0003mD-Jr; Tue, 23 Aug 2005 15:50:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7emc-0003cT-NX; Tue, 23 Aug 2005 15:50:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26864; Tue, 23 Aug 2005 15:50:04 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7emj-00086a-Cl; Tue, 23 Aug 2005 15:50:14 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E7emX-00032y-Jf; Tue, 23 Aug 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Tue, 23 Aug 2005 15:50:01 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: [e-mail]
Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2858bis-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		: Multiprotocol Extensions for BGP-4
	Author(s)	: T. Bates, et al.
	Filename	: draft-ietf-idr-rfc2858bis-07.txt
	Pages		: 12
	Date		: 2005-8-23
	
Currently BGP-4 is capable of carrying routing information only for
   IPv4. This document defines extensions to BGP-4 to enable it to carry
   routing information for multiple Network Layer protocols (e.g., IPv6,
   IPX, etc...). The extensions are backward compatible - a router that
   supports the extensions can interoperate with a router that doesn't
   support the extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-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-rfc2858bis-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-rfc2858bis-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-rfc2858bis-07.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-idr-rfc2858bis-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 MAA25944 for <[e-mail]>; Tue, 23 Aug 2005 12:19:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bUF-0001kJ-C4; Tue, 23 Aug 2005 12:18:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bUD-0001kE-7h for [e-mail]; Tue, 23 Aug 2005 12:18:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12935 for <[e-mail]>; Tue, 23 Aug 2005 12:18:50 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19PX7s7Kpmsfg+uW2fmWrtxxetjhKtJU7Q=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7bUL-00014H-3F for [e-mail]; Tue, 23 Aug 2005 12:19:02 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7NGIhaU014262; Tue, 23 Aug 2005 17:18:49 +0100
Date: Tue, 23 Aug 2005 17:18:43 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Yakov Rekhter <[e-mail]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
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]

On Tue, 23 Aug 2005, Yakov Rekhter wrote:

> Is it "no" just for the AS_PATH attribute, or for other attributes 
> as well ? In other words, does the issue you brining up specific to 
> the AS_PATH attribute, or not ?

It is "no" only for AS_PATH. The issue is specific to the proposed 
changes to AS_PATH.

AGGREGATOR is overloaded too in the draft, but can easily be 
differentiated based on the attribute length.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Meekness is uncommon patience in planning a worthwhile revenge.

_______________________________________________
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 MAA25562 for <[e-mail]>; Tue, 23 Aug 2005 12:14:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bPA-0006un-6Y; Tue, 23 Aug 2005 12:13:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bP9-0006uR-4e for [e-mail]; Tue, 23 Aug 2005 12:13:39 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12694 for <[e-mail]>; Tue, 23 Aug 2005 12:13:36 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7bPF-0000tg-6p for [e-mail]; Tue, 23 Aug 2005 12:13:48 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j7NGDQ924515;  Tue, 23 Aug 2005 09:13:26 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7NGDLG53973; Tue, 23 Aug 2005 09:13:21 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Paul Jakma <[e-mail]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
In-Reply-To: Your message of "Tue, 23 Aug 2005 16:24:06 BST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 23 Aug 2005 09:13:21 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: [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]

Paul,

> On Tue, 23 Aug 2005, Yakov Rekhter wrote:
> 
> > On the subject of the BGP analyser/observer issue we need to
> > look at two aspects of this issue:
> >
> > 1. Is it possible to parse the BGP stream into messages/attributes
> > without capturing the OPEN message by the analyser/observer ?
> 
> Into messages and attributes, yes.
> 
> > 2. If the answer to 1 is "yes", then is it possible to understanding
> > the information of these messages/attributes without capturing the
> > OPEN message (and specifically the Capability Advertisement part
> > of it) by the analyser/observer ?
> 
> For the AS_PATH: deterministically/reliably, no.

Is it "no" just for the AS_PATH attribute, or for other attributes
as well ? In other words, does the issue you brining up specific
to the AS_PATH attribute, or not ?

Yakov.

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA23002 for <[e-mail]>; Tue, 23 Aug 2005 11:41:55 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7aoU-0007Bv-OR; Tue, 23 Aug 2005 11:35:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7aoS-0007Bl-6i for [e-mail]; Tue, 23 Aug 2005 11:35:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10281 for <[e-mail]>; Tue, 23 Aug 2005 11:35:41 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/63trcx0JG9Qv1hJotN8X2A8Y2s+NcOR8=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7aoa-0007zd-Ea for [e-mail]; Tue, 23 Aug 2005 11:35:53 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7NFZcBD013721; Tue, 23 Aug 2005 16:35:40 +0100
Date: Tue, 23 Aug 2005 16:35:38 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Yakov Rekhter <[e-mail]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
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 Tue, 23 Aug 2005, Paul Jakma wrote:

> Reclaim and reserve ASN 1.

This would allow only updated analysers to work reliably, but I'd 
settle for that.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
One way to stop a runaway horse is to bet on him.

_______________________________________________
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 LAA21868 for <[e-mail]>; Tue, 23 Aug 2005 11:27:17 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7adO-0005By-HT; Tue, 23 Aug 2005 11:24:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7adM-00054G-Gn for [e-mail]; Tue, 23 Aug 2005 11:24:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09822 for <[e-mail]>; Tue, 23 Aug 2005 11:24:12 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19UQ69OXSBdbZwZGWnbzXg/SrWsl0AB1LQ=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7adR-0007gm-VK for [e-mail]; Tue, 23 Aug 2005 11:24:22 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7NFO69X013590; Tue, 23 Aug 2005 16:24:10 +0100
Date: Tue, 23 Aug 2005 16:24:06 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Yakov Rekhter <[e-mail]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
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 Tue, 23 Aug 2005, Yakov Rekhter wrote:

> On the subject of the BGP analyser/observer issue we need to
> look at two aspects of this issue:
>
> 1. Is it possible to parse the BGP stream into messages/attributes
> without capturing the OPEN message by the analyser/observer ?

Into messages and attributes, yes.

> 2. If the answer to 1 is "yes", then is it possible to understanding
> the information of these messages/attributes without capturing the
> OPEN message (and specifically the Capability Advertisement part
> of it) by the analyser/observer ?

For the AS_PATH: deterministically/reliably, no.

A hopefully fair analysis:

In practice, in bulk of cases it likely would be posssible to figure 
out which encoding is used; parsing with either 2 or 4 octet encoding 
would quickly show one encoding to be implausible (eg a byte which 
should be length but which claims a segment extends past end of the 
data, or because you encounter 0x00 0x00 - which could only be valid 
for a 4-octet encoded AS_PATH, and will be common during the 
transition period. One hopes OLD speakers quickly would be deprecated 
once the first 4-octet ASN is used. Though, you have a very long 
comfort 'zone', at least for as long as ASN-1 is not reused by Level3 
or whoever owns it now.).

However, there will be AS_PATHs which will, syntactically, seem 
plausible for either encoding. Those will require further inspection 
(eg by checking which ASNs actually are assigned by IANA or even 
RIRs).

Further, you won't be able to discriminate easily between whether an 
AS_PATH is incorrectly generated or corrupted and case of having used 
wrong ASN octet size to parse it.

(Geoff, I guess, would be quick to point out that this would not be a 
problem for the BGP speakers concerned - they know their state.)

If we could reclaim ASN 1 (Level-3 stopped using it I think) and 
reserve it, and hence guarantee the byte sequences "0x00 0x01" and 
"0x00 0x00" would /reliably/ indicate 4-byte encoding, then we could 
(i think) reliably distinguish between encodings, until the first 
"0x00 0x02 .. .." ASN is handed out - which wouldn't be for 20+ 
years, one would imagine.

So there's another possible solution if you really don't want to 
change the draft, but do want to preserve ability to parse AS_PATH 
without additional context:

Reclaim and reserve ASN 1.

> Yakov.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Somewhere, just out of sight, the unicorns are gathering.

_______________________________________________
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 KAA18801 for <[e-mail]>; Tue, 23 Aug 2005 10:48:20 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7a4L-0006Hr-QP; Tue, 23 Aug 2005 10:48:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7a4K-0006Hm-Hw for [e-mail]; Tue, 23 Aug 2005 10:48:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08366 for <[e-mail]>; Tue, 23 Aug 2005 10:48:02 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7a4O-0006k8-Vw for [e-mail]; Tue, 23 Aug 2005 10:48:10 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j7NEloBm022960; Tue, 23 Aug 2005 07:47:50 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7NEloG27970; Tue, 23 Aug 2005 07:47:50 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Paul Jakma <[e-mail]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
In-Reply-To: Your message of "Tue, 23 Aug 2005 03:35:56 BST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 23 Aug 2005 07:47:50 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
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]

Paul,

[clipped...]

> Which leaves the BGP analyser/observer issue as only significant 
> practical issue against the draft (I think even the drafts authors 
> have conceded btw that it's a minus point. Not a plus point: 
> ambiguity != security ;). However the authors obviously do not agree 
> with me that the extent of this issue is worth worrying about.).

On the subject of the BGP analyser/observer issue we need to
look at two aspects of this issue:

1. Is it possible to parse the BGP stream into messages/attributes
without capturing the OPEN message by the analyser/observer ?

2. If the answer to 1 is "yes", then is it possible to understanding
the information of these messages/attributes without capturing the
OPEN message (and specifically the Capability Advertisement part
of it) by the analyser/observer ?

Yakov.

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA06545 for <[e-mail]>; Tue, 23 Aug 2005 01:44:53 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7RZk-0005oL-FW; Tue, 23 Aug 2005 01:43:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7RZj-0005oF-Mv for [e-mail]; Tue, 23 Aug 2005 01:43:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01340 for <[e-mail]>; Tue, 23 Aug 2005 01:43:54 -0400 (EDT)
Received: from web60724.mail.yahoo.com ([209.73.178.212]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7RZj-0008Pb-6K for [e-mail]; Tue, 23 Aug 2005 01:43:59 -0400
Received: (qmail 58812 invoked by uid 60001); 23 Aug 2005 05:43:42 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=crjUwv9R83j2h7mjwaELWlILpT2NYqusjWCtUvIXm1LQkbGXISUOROgTIr0IYoxz/rRzqN5DD5yHO001zQa2Z/6+uBxsGi7siCwQ68PlGhDO7psuQdGjxM6VxeEYvPwU+XCCsHvp39a14HXO5QX+jH6yZf+Rx90ybRYRTjhRSWg= ; 
Message-ID: <[e-mail]>
Received: from [66.17.149.13] by web60724.mail.yahoo.com via HTTP; Tue, 23 Aug 2005 01:43:42 EDT
Date: Tue, 23 Aug 2005 01:43:42 -0400 (EDT)
From: Tulip Rasputin <[e-mail]>
Subject: RE: [Idr] comment on draft-ietf-idr-as4bytes-10.txt  - errata
To: Inter-Domain Routing List <[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: 2.9 (++)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 8bit
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]

> 
> With this proposal, such proposals 
                           ^^^^^^^^^
I meant "applications"

> would atleast parse the AS_PATH attribute. This would not
> yield
> correct results but would atleast give some meaningful result.
> 
> - Tulip
> 
> 
> 
> 	
> 
> 	
> 		
> __________________________________________________________ 
> Find your next car at http://autos.yahoo.ca
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
> 



	

	
		
__________________________________________________________ 
Find your next car at http://autos.yahoo.ca

_______________________________________________
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 BAA03812 for <[e-mail]>; Tue, 23 Aug 2005 01:09:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7QyZ-0006qV-8j; Tue, 23 Aug 2005 01:05:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7QyX-0006qQ-C2 for [e-mail]; Tue, 23 Aug 2005 01:05:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29932 for <[e-mail]>; Tue, 23 Aug 2005 01:05:28 -0400 (EDT)
Received: from web60720.mail.yahoo.com ([209.73.178.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7QyX-0007V8-FD for [e-mail]; Tue, 23 Aug 2005 01:05:32 -0400
Received: (qmail 53098 invoked by uid 60001); 23 Aug 2005 05:05:15 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CheV8YaMwZob7urQCTFwfsCaXt+TX3yIiwCe00kBP1LJG2Oic9fx43nEZ3M+0995+3RWRg5MfRVFv4VRO3yXB6cvupUNBPhKt/E/svHL0ZNC5VzJYBMiYXCH3ZzrY2Mtnpmbt5Hn3wTT4gJH++Zh5wjK2paNMV7XOumwJNXT5c0= ; 
Message-ID: <[e-mail]>
Received: from [59.92.137.128] by web60720.mail.yahoo.com via HTTP; Tue, 23 Aug 2005 01:05:15 EDT
Date: Tue, 23 Aug 2005 01:05:15 -0400 (EDT)
From: Tulip Rasputin <[e-mail]>
Subject: RE: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
To: Inter-Domain Routing List <[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.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 8bit
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

I am concerned for the applications that are asked to observe a BGP stream mid flow.

It would suffice if there are ways with which such applications could, by looking at the update
messages determine, the kind of ASN(s) used in the sessions or carried in the path attributes
without having parsed the OPEN message.

> 
> - anyone in favour of leaving the draft as is in this respect?
> 
> (Enke, Geoff, ....?)

The above point leaves me a little uncomfortable.

> 
> - anyone in favour of changing the draft to use the new attribute
>    (NEW_AS_PATH) which is specified by the draft?
> 
> (paul, ....?)

With this proposal, such proposals would atleast parse the AS_PATH attribute. This would not yield
correct results but would atleast give some meaningful result.

- Tulip



	

	
		
__________________________________________________________ 
Find your next car at http://autos.yahoo.ca

_______________________________________________
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 WAA22240 for <[e-mail]>; Mon, 22 Aug 2005 22:38:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Odz-0003IS-Hm; Mon, 22 Aug 2005 22:36:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Ody-0003HO-FK for [e-mail]; Mon, 22 Aug 2005 22:36:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24347 for <[e-mail]>; Mon, 22 Aug 2005 22:36:04 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX186PmS5LhdhfmLj+eBzfEAphHcx9zLZGl4=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Oe0-0003pk-0k for [e-mail]; Mon, 22 Aug 2005 22:36:08 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7N2ZvOP005172; Tue, 23 Aug 2005 03:36:00 +0100
Date: Tue, 23 Aug 2005 03:35:56 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Geoff Huston <[e-mail]>
Subject: re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
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 Tue, 23 Aug 2005, Geoff Huston wrote:

>> - A NEW speaker passes a route with an OLD path to a NEW speaker

> But section 5.1 of the draft says that the NEW speaker MUST pass 
> AS_PATH to the NEW peer as 4-bytes - I'm not sure I understand the 
> reference to "OLD path" in this context, so I may need some help 
> here in picking up your point.

The draft provides for AS_PATH being rewritten. In the above, the 
'OLD' path would come from an OLD speaker with a 2-octet AS_PATH. 
That would, when sent to a NEW peer, be rewritten into a 4-octet 
AS_PATH.

That potentially could invalidate any signatures made directly of 
information in the AS_PATH.

> As I've noted above, I'm not precisely sure what point you are 
> driving at here (that may be my fault - sorry)

Probably mine. ;) Hopefully above makes it clearer.

> - if your point is that singing the AS Path is a topic that is 
> being actively studied now and this is one more addition to their 
> agenda for consideration, then I'd agree, as would the RPSEC 
> working group I guess.

Right.

However, thinking again, An obvious way to deal with it would be for 
any such solution to not sign segment data directly, but sign an 
abstracted version of path-derived data that could be reconstructed 
from AS_PATH.

> If you are saying that there is a solution out there for signing AS 
> paths and this disrupts such a solution then I'm not sure I follow 
> you, as I'm not sure that I see such AS Path signing solutions in 
> place as yet.

Ah, no. I wasn't trying to suggest a solution existed yet ;). Sorry. 
:)

> If you are addressing the actual resource certificates then its my 
> (crude) understanding that the mappable AS would be described as 2 
> octet values and the remainder of the 4-byte AS set would be 
> described as 4 octet values.

Ok, that'd work fine likely. And my concern is withdrawn.

> Again I'm pretty sure that I'm not of the same page as you here, 
> and I don't understand your point - sorry.

Given your paragraph immediately previous, it's therefore likely not 
a problem at all - never mind.

Which leaves the BGP analyser/observer issue as only significant 
practical issue against the draft (I think even the drafts authors 
have conceded btw that it's a minus point. Not a plus point: 
ambiguity != security ;). However the authors obviously do not agree 
with me that the extent of this issue is worth worrying about.).

I'd like to have the draft changed. IMHO, there isn't really that 
much of an installed base or even implementation to justify leaving 
this nit in the draft.

But that's my opinion, I'll rest my case.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Hate the sin and love the sinner.
 		-- Mahatma Gandhi

_______________________________________________
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 WAA19853 for <[e-mail]>; Mon, 22 Aug 2005 22:08:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7OAJ-00040v-43; Mon, 22 Aug 2005 22:05:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7OAH-0003zo-HB for [e-mail]; Mon, 22 Aug 2005 22:05:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11032 for <[e-mail]>; Mon, 22 Aug 2005 22:05:23 -0400 (EDT)
Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7OAI-0002hq-Fy for [e-mail]; Mon, 22 Aug 2005 22:05:27 -0400
Received: from gihm3.apnic.net (rsdhcp28.telstra.net [203.50.0.220]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id j7N24uXt005972; Tue, 23 Aug 2005 12:04:57 +1000 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Tue, 23 Aug 2005 12:04:52 +1000
To: Paul Jakma <[e-mail]>
From: Geoff Huston <[e-mail]>
Subject: re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
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]

>However, with the current draft, it may defeat any kind of mechanism that 
>attempts to provide signatures of an AS_PATH. The current draft provides 
>for the AS_PATH to be rewritten when:
>
>- A NEW speaker passes a route with an OLD path to a NEW speaker

But section 5.1 of the draft says that the NEW speaker MUST pass AS_PATH to 
the NEW peer as
4-bytes - I'm not sure I understand the reference to "OLD path" in this 
context, so I may need some help here in picking up your point.


>- A NEW speaker must send a route with a 4-octet AS_PATH to an OLD
>   speaker


As the draft points out there are two cases here - "mappable" AS numbers, 
where the
4-byte AS value can be converted to a 2-byte by stripping off the high 
order 16 butes and
the "un-mappable" AS numbers - where the transition 2-Byte AS value is 
placed in the AS-PATH and the original 4-byte value is used in NEW_AS_PATH. 
Again I'm not sure I follow your line of argument here.


>This affects the transition period, even if no ASN's are using 4-octet 
>numbers yet.
>
>So any mechanisms that want to get involved in signing AS_PATH's are going 
>to have learn about when an AS_PATH is not what an AS_PATH used to be (and 
>when an AS_PATH that isn't then becomes what it was, and so on).


As I've noted above, I'm not precisely sure what point you are driving at 
here (that may be my fault - sorry) - if your point is that singing the AS 
Path is a topic that is being actively studied now and this is one more 
addition to their agenda for consideration, then I'd agree, as would the 
RPSEC working group I guess. If you are saying that there is a solution out 
there for signing AS paths and this disrupts such a solution then I'm not 
sure I follow you, as I'm not sure that I see such AS Path signing 
solutions in place as yet.

If you are addressing the actual resource certificates then its my (crude) 
understanding that the mappable AS would be described as 2 octet values and 
the remainder of the 4-byte AS set would be described as 4 octet values. 
Again I'm pretty sure that I'm not of the same page as you here, and I 
don't understand your point - sorry.


regards,

    Geoff



_______________________________________________
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 VAA16720 for <[e-mail]>; Mon, 22 Aug 2005 21:28:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7NXM-0004Yt-1n; Mon, 22 Aug 2005 21:25:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7NXL-0004Yd-Ek for [e-mail]; Mon, 22 Aug 2005 21:25:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09277 for <[e-mail]>; Mon, 22 Aug 2005 21:25:09 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19yzTjsfcsTJ/DxoGj/aOLJnc5EFNZ48ak=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7NXM-0001gt-Dx for [e-mail]; Mon, 22 Aug 2005 21:25:13 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7N1P0OT004331; Tue, 23 Aug 2005 02:25:03 +0100
Date: Tue, 23 Aug 2005 02:25:00 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Inter-Domain Routing List <[e-mail]>
Subject: re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail], Inter-Domain Routing List <[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]

On Tue, 23 Aug 2005, Geoff Huston wrote:

> merits some form of correction I would interpret as a positive 
> attribute of the specification and I would advocate leaving it as 
> is.

Straw poll:

On the question of the current as4bytes IDR working document 
specifying that the syntax an existing well-known attribute be 
overriden by an OPEN capability:

- anyone in favour of leaving the draft as is in this respect?

(Enke, Geoff, ....?)

- anyone in favour of changing the draft to use the new attribute
   (NEW_AS_PATH) which is specified by the draft?

(paul, ....?)

I've floated my balloon, if it goes nowhere, or in wrong direction 
I'll leave it go :)

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
PnPBIOS is a PC specific affliction. Other platforms have more elegantly
designed but even buggier solutions

 	- Alan Cox on linux-kernel

_______________________________________________
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 VAA14954 for <[e-mail]>; Mon, 22 Aug 2005 21:05:07 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7NBm-0008Qd-Ls; Mon, 22 Aug 2005 21:02:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7NBl-0008QY-TC for [e-mail]; Mon, 22 Aug 2005 21:02:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08323 for <[e-mail]>; Mon, 22 Aug 2005 21:02:52 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19RNLgt5q7hbGelMfPbLbBeoSqeQycpn8s=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7NBj-00016d-Tw for [e-mail]; Mon, 22 Aug 2005 21:02:55 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7N12Xu5004111; Tue, 23 Aug 2005 02:02:36 +0100
Date: Tue, 23 Aug 2005 02:02:33 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Geoff Huston <[e-mail]>
Subject: re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
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 Tue, 23 Aug 2005, Geoff Huston wrote:

> / 4byte world.  The question in my mind in thinking about this 
> motivation is why would I necessarily want to make eavesdropping on 
> the wire by third parties easier to undertake?

First let me note that most BGP speakers which secure their sessions 
do so to /authenticate/ the sessions, they typically do not 
additionally encrypt the data for confidentiality (ie a 'secured' BGP 
session is still monitorable, nearly always).

Reasons to want to observe a BGP stream:

- unintrusive collection of statistics
- IDS
- operational debugging

I might be strange, but fact that many switches offer 'port mirror' 
capabilities makes me think I might not be /that/ strange in this 
respect generally, don't know about BGP though.

> In other words what Paul interprets as a problem in the 
> specification that merits some form of correction I would interpret 
> as a positive attribute of the specification and I would advocate 
> leaving it as is.

There is no positive attribute though. BGP sessions typically want 
authentication, not confidentiality - your point doesn't apply.

Also, you gave a presentation at GRO on need for BGP security 
(path/prefix attestation of some kind particularly).

However, with the current draft, it may defeat any kind of mechanism 
that attempts to provide signatures of an AS_PATH. The current draft 
provides for the AS_PATH to be rewritten when:

- A NEW speaker passes a route with an OLD path to a NEW speaker

- A NEW speaker must send a route with a 4-octet AS_PATH to an OLD
   speaker

This affects the transition period, even if no ASN's are using 
4-octet numbers yet.

So any mechanisms that want to get involved in signing AS_PATH's are 
going to have learn about when an AS_PATH is not what an AS_PATH used 
to be (and when an AS_PATH that isn't then becomes what it was, and 
so on).

> By the way I am _really_ pleased to learn of work on an 
> implementation of this spec in another BGP implementation - this is 
> very heartening to hear!

I intend to complete implementation of 4bytes-ASN, however I think 
it's a shame we have to leave this nit in the draft.

Note that I also think the way this draft is currently is not 
conducive to implementation. Eg, our (Quagga) current aspath 
constructing/deconstructing/updating/checking code has 0 notion of 
what a peer is:

 	$ grep 'struct peer' bgp_aspath.c
 	$

Sadly, that nice modularity (ok, it's not the cleanest code, but at 
least it /was/ modular), may have to disappear to some extent.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
It is the wisdom of crocodiles, that shed tears when they would devour.
 		-- Francis Bacon

_______________________________________________
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 UAA11034 for <[e-mail]>; Mon, 22 Aug 2005 20:14:55 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7MPk-0005kx-6X; Mon, 22 Aug 2005 20:13:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7MPi-0005jC-JR for [e-mail]; Mon, 22 Aug 2005 20:13:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06110 for <[e-mail]>; Mon, 22 Aug 2005 20:13:13 -0400 (EDT)
Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7MPi-0008Ee-PS for [e-mail]; Mon, 22 Aug 2005 20:13:15 -0400
Received: from gihm3.apnic.net (rsdhcp28.telstra.net [203.50.0.220]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id j7N0CwXt004385; Tue, 23 Aug 2005 10:12:58 +1000 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Tue, 23 Aug 2005 10:12:58 +1000
To: [e-mail]
From: Geoff Huston <[e-mail]>
Subject: re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
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]

Paul wrote

 > I am curious why you chose to overload the syntax of the
 > existing AS_PATH attribute according to whether two peers are or > are 
not 4byte ASN capable?
 >
 > My primary concern of this aspect of the draft is that it will
 > become impossible to parse AS_PATH without external reference.
 > This would have implications for protocol analysers which are
 > asked to observe a BGP session in mid-flow (they'll have no way
 > of parsing AS_PATH) and also for 'old' analysers which are asked
 > to observe a session between new peers (at best, such an
 > analyser would produce syntactically incorrect results), as well
 > as implications for modularity of code in BGP implementations.
 >
 > Would it maybe be better to leave the syntax of AS_PATH alone
 > and simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH
 > for 2byte (you could even make AS_PATH optional and NEW_AS_PATH > 
well-known between new speakers, so that AS_PATH slowly dies out
 > during the transition period)?

So lets understand precisely what is going on here:

1 - there is no problem identified in this posting when looking at the 
situation of a BGP peering session. The BGP speaker knows its own state 
(NEW or OLD) and establishes the state of its peer at the time of the OPEN, 
and this information is used to guide what the BGP speaker will place in 
the AS_PATH and how it will interpret what is in the received AS_PATH. So 
if you are implementing the 4 byte draft as a BGP speaker than this posting 
does not identify any issues associated with the specification itself. At 
all times the BGP speaker can deterministically interpret the AS-PATH 
attribute.

2 - If a BGP speaker outputs an update log or a dump, then there is still 
no problem here - the BGP speaker presumably has an internal representation 
of AS's that are either 2-byte (OLD) or 4-byte) NEW (although thats an 
implementation detail beyond the scope of the specification) and presumably 
will consistently report according to the internal format. Again as far as 
I can see this posting does not identify any issues associated with the 
specification itself.

3 - So what I see is that a) if you chose NOT to encrypt your BGP session 
and b) if you allow eavesdroppers into the BGP session and c) the 
eavesdropper is not able to capture the entire BGP session, then Paul is 
observing that there is  the potential for confusion on the part of the 
eavesdropper when interpreting the BGP update conversation as the update 
does not contain enough information to decode the AS PATH as either a 
sequence of 2 byte or a sequence of 4 byte values. Paul has then proposed 
changes to the draft in the light of this

I would question the underlying premises of this motivation for this change 
- under what circumstances would I be deploying BGP eavesdroppers, as 
distinct from getting the BGP speakers themselves to provide the session 
information I'm after? And if its my eavesdropper then surely I can 
configure the eavesdropper to let it know how to interpret what its seeing. 
Or maybe set up a common community attribute to trigger my eavesdropper to 
interpret the AS_PATH a certain way? So as I see it what Paul is advocating 
is making interpretation of BGP sessions on the wire easier for third party 
eaverdroppers to perform in a 2byte / 4byte world.  The question in my mind 
in thinking about this motivation is why would I necessarily want to make 
eavesdropping on the wire by third parties easier to undertake?

In other words what Paul interprets as a problem in the specification that 
merits some form of correction I would interpret as a positive attribute of 
the specification and I would advocate leaving it as is.

By the way I am _really_ pleased to learn of work on an implementation of 
this spec in another BGP implementation - this is very heartening to hear!

regards,

    Geoff  Huston




_______________________________________________
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 SAA00587 for <[e-mail]>; Mon, 22 Aug 2005 18:01:13 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7KJ1-0008Ah-Ht; Mon, 22 Aug 2005 17:58:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7KJ0-0008Ac-B9 for [e-mail]; Mon, 22 Aug 2005 17:58:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22928 for <[e-mail]>; Mon, 22 Aug 2005 17:58:07 -0400 (EDT)
Received: from smtp-out.hotpop.com ([38.113.3.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7KIw-0002Tx-Rk for [e-mail]; Mon, 22 Aug 2005 17:58:10 -0400
Received: from hotpop.com (kubrick.hotpop.com [38.113.3.103]) by smtp-out.hotpop.com (Postfix) with SMTP id 6CB691635298 for <[e-mail]>; Mon, 22 Aug 2005 21:57:48 +0000 (UTC)
Received: from ALOKLXP (unknown [202.144.106.188]) by smtp-3.hotpop.com (Postfix) with ESMTP id BD74E181AD54 for <[e-mail]>; Mon, 22 Aug 2005 12:23:31 +0000 (UTC)
Message-ID: <007d01c5a714$417442d0$[e-mail]>
From: "Alok" <[e-mail]>
To: "Inter-Domain Routing List" <[e-mail]>
References: <[e-mail]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Date: Mon, 22 Aug 2005 17:52:24 +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: 8abaac9e10c826e8252866cbe6766464
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]

I wonder why too :-)

Wonder why they have an open WG at all when they do not want to take things
forward


>
> Strange.
>
> If this is the case, then why do we still have such 'drafts' for which
we're too late to comment
> on still in the "draft" stage and hanging off the IDR WG shelf for review?
>
> Why dont we take them off and publish 'em as RFCs and standards?
>
> Tulip
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> _______________________________________________
> 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 RAA27723 for <[e-mail]>; Mon, 22 Aug 2005 17:25:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Jj5-0000eu-00; Mon, 22 Aug 2005 17:21:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Jj3-0000eo-86 for [e-mail]; Mon, 22 Aug 2005 17:21:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21791 for <[e-mail]>; Mon, 22 Aug 2005 17:20:58 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1+4xofWPQ9LIXLmS0kPI9I1gltOBdxThwQ=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7KJf-0001c7-EF for [e-mail]; Mon, 22 Aug 2005 17:58:53 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7MLJY5o000834; Mon, 22 Aug 2005 22:19:37 +0100
Date: Mon, 22 Aug 2005 22:19:34 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: Inter-Domain Routing List <[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]

On Mon, 22 Aug 2005, Enke Chen wrote:

> Just FYI - There are at least two implementations, and the 
> implementation report is being worked on (see the IDR WG minutes).

Ok, I didn't remember that. But it was there in the doc status 
update.

FWIW, my comments arise directly of out of attempting to implement 
this draft.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Married men should forget their mistakes; there's no use in two people
remembering the same thing!

_______________________________________________
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 QAA22183 for <[e-mail]>; Mon, 22 Aug 2005 16:06:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7IIl-00004w-LW; Mon, 22 Aug 2005 15:49:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7IIj-00004r-W9 for [e-mail]; Mon, 22 Aug 2005 15:49:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08424 for <[e-mail]>; Mon, 22 Aug 2005 15:49:44 -0400 (EDT)
Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7ItM-0004Ct-3T for [e-mail]; Mon, 22 Aug 2005 16:27:37 -0400
Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id 4FCA0197397 for <[e-mail]>; Mon, 22 Aug 2005 15:39:23 -0400 (EDT)
Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j7MJnZIB015149;  Mon, 22 Aug 2005 15:49:35 -0400
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: [e-mail]
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 22 Aug 2005 15:49:35 -0400
From: Bill Fenner <[e-mail]>
Versions: dmail (linux) 2.6d/makemail 2.10
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
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]

>...Particularly one marked still with intended status of experimental:
>
>https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=6498

Paul,

  Looks like you found a bug in the I-D Database interface -- as4bytes
doesn't have any intended status recorded, so it seems to have defaulted
to Experimental, but it's indeed intended to be Standards track.

  Bill

_______________________________________________
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 QAA22130 for <[e-mail]>; Mon, 22 Aug 2005 16:05:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7IIG-0008Sd-6R; Mon, 22 Aug 2005 15:49:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7IIF-0008SY-Kj for [e-mail]; Mon, 22 Aug 2005 15:49:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08406 for <[e-mail]>; Mon, 22 Aug 2005 15:49:13 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX18FHZqYO2+tGUoS9l4942//3Ct80xsxRd8=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Isr-0004CI-CT for [e-mail]; Mon, 22 Aug 2005 16:27:06 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7MJn56N032022; Mon, 22 Aug 2005 20:49:07 +0100
Date: Mon, 22 Aug 2005 20:49:04 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: Inter-Domain Routing List <[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]

On Mon, 22 Aug 2005, Enke Chen wrote:

> You will be surprised. AFAIK there are at least hundreds of routers 
> in the field that supports the 4-byte AS.

Ah, by far more than I would have thought. However, still 
insignificant to the number of routers which still need to be 
upgraded to support this draft. ;)

> Just FYI - There are at least two implementations, and the implementation 
> report is being worked on (see the IDR WG minutes).

Ok, well, if you have a look at the changes I suggested (some of 
which apply to either 'method') there is another consideration, see 
security consideration:

Overloading AS_PATH very likely will be, during a transition period, 
incompatible with any future BGP security specification which 
attempts to attest AS_PATH.

However, if you do not overload AS_PATH, you do still have the 
possibility of having AS_PATH attestation working. (NEW speakers can 
originate and attest to authenticity of both).

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
I always turn to the sports pages first, which record people's accomplishments.
The front page has nothing but man's failures.
 		-- Chief Justice Earl Warren

_______________________________________________
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 PAA19759 for <[e-mail]>; Mon, 22 Aug 2005 15:35:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7I3q-0006Iz-W9; Mon, 22 Aug 2005 15:34:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7I3p-0006It-HO for [e-mail]; Mon, 22 Aug 2005 15:34:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07864 for <[e-mail]>; Mon, 22 Aug 2005 15:34:19 -0400 (EDT)
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.43) id 1E7IeR-0003qq-Ds for [e-mail]; Mon, 22 Aug 2005 16:12:12 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 22 Aug 2005 12:34:11 -0700
X-IronPort-AV: i="3.96,131,1122879600";  d="scan'208"; a="334555976:sNHT31149732"
Received: from [128.107.134.9] (enke-linux.cisco.com [128.107.134.9]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7MJY9oo024554; Mon, 22 Aug 2005 12:34:09 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 22 Aug 2005 12:34:09 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], Inter-Domain Routing List <[e-mail]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
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]

Paul Jakma wrote:

> On Mon, 22 Aug 2005, Enke Chen wrote:
>
>> To change the encoding and mandating the NEW_AS_PATH, we would have 
>> to deprecate and re-allocate all the code points, including 4-byte AS 
>> Capability, NEW_AS_PATH, and NEW_AGGREGATOR in order to not break 
>> existing deployments.
>
>
> Exactly how many existing non-laboratory deployments are there? :) Do 
> I need one or two hands to count them on, if any at all? :)


You will be surprised. AFAIK there are at least hundreds of routers in 
the field that supports the 4-byte AS.

Just FYI - There are at least two implementations, and the 
implementation report is being worked on (see the IDR WG minutes).

Regards,

-- 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 PAA18531 for <[e-mail]>; Mon, 22 Aug 2005 15:20:14 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7HpR-0002Ob-CI; Mon, 22 Aug 2005 15:19:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7HpP-0002OR-W8 for [e-mail]; Mon, 22 Aug 2005 15:19:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05990 for <[e-mail]>; Mon, 22 Aug 2005 15:19:26 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/LBKlC8qej5sWTL9n4OW8bnzlu5USFwYg=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7IQ0-0002zw-OH for [e-mail]; Mon, 22 Aug 2005 15:57:18 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7MJJ3dV031755; Mon, 22 Aug 2005 20:19:08 +0100
Date: Mon, 22 Aug 2005 20:19:03 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: Inter-Domain Routing List <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail], Inter-Domain Routing List <[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]

On Mon, 22 Aug 2005, Enke Chen wrote:

> To change the encoding and mandating the NEW_AS_PATH, we would have 
> to deprecate and re-allocate all the code points, including 4-byte 
> AS Capability, NEW_AS_PATH, and NEW_AGGREGATOR in order to not 
> break existing deployments.

Exactly how many existing non-laboratory deployments are there? :) Do 
I need one or two hands to count them on, if any at all? :)

Breaking drafts, if for a good reason, is quite possible. 
Particularly one marked still with intended status of experimental:

 	https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=6498

or not?

> Based on our discussion it seems to me that the differences between 
> re-using the AS_PATH attribute or the NEW_AS_PATH attribute for new 
> peers are mainly the following:  (Let us call the proposals P1 and 
> P2 respectively)

>   1) "standalone" tools:
>        P1:  would require a new parameter to parse UPDATES for a new 
> session.
>                old tool works for old peers.
>                old tool would generate error in parsing UPDATES for a new 
> session.

That is the "at best" result. Much worse could occur, particularly in 
tools which are not well-designed, from crashes to vulnerabilities 
(far fetched in this case, granted but not impossible).

>                P2:  no new parameter is needed to parse an UPDATE for a new 
> session.
>                old tool works for old peers.
>                old tool flags new update as "fatal error - missing AS_PATH", 
> and no useful AS_PATH info.

Or just continues on parsing the other attributes. The tool need not 
be attempting to validate the UPDATE.

>  2) At the end of transition:
>
>        P1:  possibly reclaim NEW_AS_PATH, NEW_AGGREGATOR.
>        P2:  possibly reclaim AS_PATH,  AGGREGATOR.

I'm not sure how you could reclaim either, least not any time soon. 
But no difference either way, no.

> These differences seem to be minor, and I do not think they are compelling 
> enough for us to change the encoding at this late stage.

Conceptually, it's not minor. Overloading is simply quite ugly. It is 
going to be a stain on the BGP protocol for as long as the version == 
4. As a matter of practicality, it's likely not going to make any 
difference to common BGP speakers, agreed, but it is going to have an 
effect on tools and their users ("So, exactly what am I supposed to 
do with that ASN-size knob again?").

So I'd say this depends on existing implementation and deployment. 
And a month ago at GRO there was only one known /implementation/. ;)

If there are no deployments, it is quite possible to address this 
matter. It's A very small nit in a way yes, but it's still easy to 
polish out at this stage, so why not?

> Regards,

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
"Bye, witches! Thanks for not eating me!"

 	--Ralph Wiggum
 	  Treehouse of Horror VIII (Episode 5F02)

_______________________________________________
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 OAA14483 for <[e-mail]>; Mon, 22 Aug 2005 14:28:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7H1r-0001tz-N0; Mon, 22 Aug 2005 14:28:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7H1p-0001tW-VX for [e-mail]; Mon, 22 Aug 2005 14:28:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02938 for <[e-mail]>; Mon, 22 Aug 2005 14:28:12 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7HcR-0001dN-0P for [e-mail]; Mon, 22 Aug 2005 15:06:04 -0400
Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 22 Aug 2005 11:28:03 -0700
X-IronPort-AV: i="3.96,131,1122879600";  d="scan'208"; a="206743283:sNHT32667888"
Received: from [128.107.134.9] (enke-linux.cisco.com [128.107.134.9]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7MIRqZ1029209; Mon, 22 Aug 2005 11:27:53 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 22 Aug 2005 11:28:00 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], Inter-Domain Routing List <[e-mail]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
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]

Hi, Paul:

Thanks - but I hope it will not be needed :-)

To change the encoding and mandating the NEW_AS_PATH, we would have to 
deprecate and re-allocate all the code points, including 4-byte AS 
Capability, NEW_AS_PATH, and NEW_AGGREGATOR in order to not break 
existing deployments.

Based on our discussion it seems to me that the differences between 
re-using the AS_PATH attribute or the NEW_AS_PATH attribute for new 
peers are mainly the following:  (Let us call the proposals P1 and P2 
respectively)

    1) "standalone" tools:
         P1:  would require a new parameter to parse UPDATES for a new 
session.
                 old tool works for old peers.
                 old tool would generate error in parsing UPDATES for a 
new session.
         
         P2:  no new parameter is needed to parse an UPDATE for a new 
session.
                 old tool works for old peers.
                 old tool flags new update as "fatal error - missing 
AS_PATH", and no useful AS_PATH info.

   2) At the end of transition:

         P1:  possibly reclaim NEW_AS_PATH, NEW_AGGREGATOR.
         P2:  possibly reclaim AS_PATH,  AGGREGATOR.

These differences seem to be minor, and I do not think they are 
compelling enough for us to change the encoding at this late stage.

Regards,

-- Enke
 
Paul Jakma wrote:

> Hi Enke,
>
> See:
>
>     http://hibernia.jakma.org/~paul/as4bytes.diff
>
> for the changes I would like to see made to the draft.
>
> (For full version see: 
> http://hibernia.jakma.org/~paul/draft-ietf-idr-as4bytes-11.txt)
>
> regards,


_______________________________________________
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 OAA12248 for <[e-mail]>; Mon, 22 Aug 2005 14:00:07 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7GYX-0004FM-54; Mon, 22 Aug 2005 13:57:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7GYV-0004F9-Ny for [e-mail]; Mon, 22 Aug 2005 13:57:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01204 for <[e-mail]>; Mon, 22 Aug 2005 13:57:54 -0400 (EDT)
Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7H96-0000l0-Na for [e-mail]; Mon, 22 Aug 2005 14:35:46 -0400
Received: (qmail 66185 invoked from network); 22 Aug 2005 17:57:47 -0000
Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 22 Aug 2005 17:57:47 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j7MHwk7s038559; Mon, 22 Aug 2005 13:58:47 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Tulip Rasputin <[e-mail]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt 
In-reply-to: Your message of "Mon, 22 Aug 2005 01:22:07 EDT." <[e-mail]> 
Date: Mon, 22 Aug 2005 13:58:46 -0400
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: Inter-Domain Routing List <[e-mail]>, Paul Jakma <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
Tulip Rasputin writes:
>  
> > One general comment first: The 4-byte AS scheme was spec'ed in 2001 
> > after several design iterations (particular on transition). The spec has 
> > been stable for more than four years.  As I understand, there have been 
> > more than one implementations, and some have been deployed for years.  
> > As of last IETF, the implementation report is already under way.  At 
> > this stage the issue you pointed out on using old  tools over  4-byte  
> > peers does not seem to be significant enough for us to consider a change 
> > on the attribute to carry the AS_PATH info. You are 4-5 years too late :-)
>  
> Strange. 
>  
> If this is the case, then why do we still have such 'drafts' for which
> we're too late to comment on still in the "draft" stage and hanging
> off the IDR WG shelf for review?
>  
> Why dont we take them off and publish 'em as RFCs and standards?
>  
> Tulip


We got here because IESG refused to advance anything until RFC1771 got
updated.  What we are doing is dusting them drafts off and advancing
them now that the bottleneck (rfc1771 update) has cleared.

Curtis
 

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA03728 for <[e-mail]>; Mon, 22 Aug 2005 12:11:12 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Esc-0006ID-Vi; Mon, 22 Aug 2005 12:10:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EsX-0006Gl-3a; Mon, 22 Aug 2005 12:10:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24780; Mon, 22 Aug 2005 12:10:26 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7FT8-0005eb-Bl; Mon, 22 Aug 2005 12:48:18 -0400
Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1E7EsW-000244-In; Mon, 22 Aug 2005 12:10:28 -0400
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 22 Aug 2005 12:10:28 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: [e-mail]
Subject: [Idr] Last Call: 'BGP Route Reflection - An Alternative to Full Mesh IBGP' to Draft Standard 
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]

The IESG has received a request from the Inter-Domain Routing WG to consider 
the following document:

- 'BGP Route Reflection - An Alternative to Full Mesh IBGP '
   <draft-ietf-idr-rfc2796bis-01.txt> as a Draft Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2005-09-05.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2796bis-01.txt

Implementation Report can be accessed at
http://www.ietf.org/IESG/Implementations/RFC2796-implementations.txt


_______________________________________________
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 KAA27656 for <[e-mail]>; Mon, 22 Aug 2005 10:55:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DgF-00085f-IS; Mon, 22 Aug 2005 10:53:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DgE-00085a-Mt for [e-mail]; Mon, 22 Aug 2005 10:53:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20753 for <[e-mail]>; Mon, 22 Aug 2005 10:53:40 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19+BaY/4L4dC8elOlwL+jVVZFciZ5JHRfA=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7EGn-0003LI-Rk for [e-mail]; Mon, 22 Aug 2005 11:31:31 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7MErSrc029344; Mon, 22 Aug 2005 15:53:31 +0100
Date: Mon, 22 Aug 2005 15:53:28 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: Inter-Domain Routing List <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail], Inter-Domain Routing List <[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 Enke,

See:

 	http://hibernia.jakma.org/~paul/as4bytes.diff

for the changes I would like to see made to the draft.

(For full version see: 
http://hibernia.jakma.org/~paul/draft-ietf-idr-as4bytes-11.txt)

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Everything can be filed under "miscellaneous".

_______________________________________________
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 JAA20546 for <[e-mail]>; Mon, 22 Aug 2005 09:23:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7CEJ-0008Az-Vl; Mon, 22 Aug 2005 09:20:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7CEI-0008Au-Gy for [e-mail]; Mon, 22 Aug 2005 09:20:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14951 for <[e-mail]>; Mon, 22 Aug 2005 09:20:44 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/FzBuwU6BInOCv577IosP5QkWt5Fvc+F4=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Coq-0000dM-O1 for [e-mail]; Mon, 22 Aug 2005 09:58:34 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7MDJWJ2028644; Mon, 22 Aug 2005 14:19:34 +0100
Date: Mon, 22 Aug 2005 14:19:31 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: Inter-Domain Routing List <[e-mail]>, [e-mail]
Subject: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.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]

On Mon, 22 Aug 2005, Paul Jakma wrote:

> There will always be two transitions, you can't avoid it.
>
> NEW -> OLD: You'll have to check AS_PATH isn't 4byte, and rewrite it
> OLD -> NEW:
> 	- NEW_AS_PATH present: Cross-check with AS_PATH and 'merge'
> 		               to get full path information

To clarify: The above is how the current draft specifies things.

I would propose:

NEW -> OLD: synthesise AS_PATH if required (or add your ASN as
             normal)
NEW <- OLD: 'merge' NEW_AS_PATH if present, as current draft
 	    specifies

NEW -> NEW:
 	Originate:
 		- NEW_AS_PATH contains canonical path information
 		- AS_PATH is optional, prefered to not include it
 	  	  implementation /MAY/ originate it (eg because some
 		  kind of secure BGP may be deployed which requires
 	          AS_PATH to be maintained, while OLD world still
 	          exists)
 	Pass on:
 		- NEW_AS_PATH -> add yourself to path
 		- AS_PATH (if present only) -> add your mapped ASN to path

NEW <- NEW: NEW_AS_PATH mandatory, AS_PATH discretionary
 	- NEW_AS_PATH is loop checked, it is the canonical
 	  information
 	- AS_PATH is checked for consistency with NEW_AS_PATH
 	  (taking mapping into account)
 	  if not consistent: Invalid UPDATE, ignore

So during the transition period we would see both attributes, and 
we'd have to do extra work at the boundaries between OLD and NEW.

Eventually, when everyone is NEW, the only thing we should see is 
NEW_AS_PATH (and NEW_AGGREGATOR).

Ancillary BGP tools continue to work during transition, whether they 
know of NEW_AS_PATH or not. None will produce garbage, none will need 
user-specified knobs in order to decide how to parse *_PATH 
information, they can use the attribute type code as is normal in 
parsing attributes.

> software will simply continue to work. It may not give you a full picture 
> anymore, becase BGP has been extended, but it will still give you 
> semantically correct results.

Syntactically even. And the semantics also stand a chance of coming 
across (eg AS_PATH between NEW->OLD or OLD-OLD would have full 
hop-count information, even if NEW_AS_PATH is present. The path 
itself may be semantically correct, particularly if there are no 
AS_TRANS numbers in it, and even then a human can still recognise 
AS_TRANS for what it is).

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
A citizen of America will cross the ocean to fight for democracy, but
won't cross the street to vote in a national election.
 		-- Bill Vaughan

_______________________________________________
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 JAA20053 for <[e-mail]>; Mon, 22 Aug 2005 09:17:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7C9p-0007UP-HI; Mon, 22 Aug 2005 09:16:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7C9n-0007UK-CT for [e-mail]; Mon, 22 Aug 2005 09:16:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14710 for <[e-mail]>; Mon, 22 Aug 2005 09:16:05 -0400 (EDT)
Received: from gateout02.mbox.net ([165.212.64.22] helo=gwo2.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7CkM-0000TL-D7 for [e-mail]; Mon, 22 Aug 2005 09:53:54 -0400
Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gwo2.mbox.net (Postfix) with SMTP id 90E43163BF1; Mon, 22 Aug 2005 13:15:37 +0000 (GMT)
Received: from gateout02.mbox.net [165.212.64.22] by gateout02.mbox.net via mtad (C8.MAIN.3.17K)  with ESMTP id 600JHVNPK0322Mo2; Mon, 22 Aug 2005 13:15:36 GMT
Received: from gw1.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.21U); Mon, 22 Aug 2005 13:15:36 GMT
X-USANET-Source: 165.212.116.254 IN   [e-mail] gw1.EXCHPROD.USA.NET
X-USANET-MsgId: XID901JHVNPK3878Xo2
Received: from VS4.EXCHPROD.USA.NET ([10.116.208.142]) by gw1.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.211);  Mon, 22 Aug 2005 07:15:35 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Date: Mon, 22 Aug 2005 07:15:34 -0600
Message-ID: <[e-mail]>
Thread-Topic: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Thread-Index: AcWm2qI8n5OeiQPiRT6CmBmBVGl4TQAPhrHg
From: "Susan Hares" <[e-mail]>
To: "Enke Chen" <[e-mail]>
X-OriginalArrivalTime: 22 Aug 2005 13:15:35.0709 (UTC) FILETIME=[951564D0:01C5A71B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
Cc: Inter-Domain Routing List <[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 JAA20053

Enke:

Thanks for your note.  My understanding is given the implementation
experience you feel that the benefits of the current draft outweigh any 
Encoding issues.

Sue


-----Original Message-----
From: Enke Chen [mailto:[e-mail]] 
Sent: Monday, August 22, 2005 1:31 AM
To: Susan Hares
Cc: [e-mail]; Inter-Domain Routing List; [e-mail]; Enke Chen
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt

Hi, Sue:

Please see my reply to Paul on some of the considerations (after digging

out some old notes).

In terms of implementation and customer experience, a couple things come

to my mind:

Using the AS_PATH attribute across has the advantage of being able to 
continue using the "as-path" list policy and displaying the "as-path", 
etc, and avoid supporting "new-as-path" in addition to "as-path" in the 
configuation.

As the NEW_AS_PATH is optional, the check for the required attribute 
portion remains unchanged. (As I mentioned earlier, one of the 
considerations was to avoid introducing another "mandatory" attribute. 
This follows the trandition that new attributes have all been "optional"

after RFC 1771).

-- Enke

Susan Hares wrote:

>Enke:
>
>After implementing the 4-Byte AS specification, do you think the
>avoidance of the new attribute justifies the confusion in the AS PATH
>syntax?
>
>Sue
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Enke Chen
>Sent: Friday, August 19, 2005 1:34 PM
>To: [e-mail]; Inter-Domain Routing List
>Cc: [e-mail]
>Subject: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
>
>Hi, Paul:
>
>Thanks for your comments. My comments are inlined.
>
>Paul Jakma wrote:
>
>  
>
>>Hi,
>>
>>Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:
>>
>>I am curious why you chose to overload the syntax of the existing 
>>AS_PATH attribute according to whether two peers are or are not 4byte 
>>ASN capable?
>>
>>My primary concern of this aspect of the draft is that it will become 
>>impossible to parse AS_PATH without external reference. This would 
>>have implications for protocol analysers which are asked to observe a 
>>BGP session in mid-flow (they'll have no way of parsing AS_PATH) and 
>>also for 'old' analysers which are asked to observe a session between 
>>new peers (at best, such an analyser would produce syntactically 
>>incorrect results), as well as implications for modularity of code in 
>>BGP implementations.
>>    
>>
>
>
>These protocol analysis tools need to be augmented to support the
4-byte
>
>AS numbers regardless. Without the knowledge of whether the 4-byte AS 
>capability is supported over a session,  there are a couple of options 
>for the tools:
>
>     o introduce a button/knob to allow a user to specify whether the 
>session is doing 4-byte or 2-byte.
>     o or parse the AS_PATH using 2-byte encoding first, if there is an

>error, parse it using the 4-byte encoding (this may not be as robust as

>the previous one).
>
>  
>
>>Would it maybe be better to leave the syntax of AS_PATH alone and 
>>simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 2byte
>>    
>>
>
>  
>
>>(you could even make AS_PATH optional and NEW_AS_PATH well-known 
>>between new speakers, so that AS_PATH slowly dies out during the 
>>transition period)?
>>    
>>
>
>
>One of the consideration was to avoid mandating another attribute.
Also
>
>it seems to be more consistent to use the AS_PATH attribute across the 
>board.
>
>Regards,
>
>-- Enke
> 
>
>_______________________________________________
>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 IAA17559 for <[e-mail]>; Mon, 22 Aug 2005 08:45:20 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Bfx-000275-4h; Mon, 22 Aug 2005 08:45:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Bfr-00024l-F9 for [e-mail]; Mon, 22 Aug 2005 08:45:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12965 for <[e-mail]>; Mon, 22 Aug 2005 08:45:09 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19SLC0E66Egxcjp/cALoMDQ/bpzgBPpGkM=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7CGQ-0007ux-91 for [e-mail]; Mon, 22 Aug 2005 09:22:58 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7MCfs20028204; Mon, 22 Aug 2005 13:41:57 +0100
Date: Mon, 22 Aug 2005 13:41:54 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: Susan Hares <[e-mail]>, Inter-Domain Routing List <[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]

On Sun, 21 Aug 2005, Enke Chen wrote:

> Using the AS_PATH attribute across has the advantage of being able 
> to continue using the "as-path" list policy and displaying the 
> "as-path", etc, and avoid supporting "new-as-path" in addition to 
> "as-path" in the configuation.

Using NEW_AS_PATH instead does /not/ imply you have to change the 
user interface.

The user continues to work with 'as-path', all that changes is a 
behind-the-curtain implementation detail of how that information is 
represented on the wire. (with a new attr code, so what ;) ).

> As the NEW_AS_PATH is optional, the check for the required 
> attribute portion remains unchanged. (As I mentioned earlier, one 
> of the considerations was to avoid introducing another "mandatory" 
> attribute. This follows the trandition that new attributes have all 
> been "optional" after RFC 1771).

You *are* introducing a new well-known and mandatory attribute 
though. Worse, it has the same type code as an existing attribute, 
but with a different and incompatible syntax. And similar with 
AGGREGATOR.

You're also introducing two additional 'temporary' attributes, 
NEW_AS_PATH and NEW_AGGREGATOR, which after the transition period 
will simply no longer be used anywhere on the internet.

The sensible thing to do is to /not/ overload existing attributes and 
make full use of the new attributes you introduce.

I disagree this makes life more difficult for NEW<->OLD scenarios, 
issues are same really.

> -- Enke

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
All phone calls are obscene.
 		-- Karen Elizabeth Gordon

_______________________________________________
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 IAA16910 for <[e-mail]>; Mon, 22 Aug 2005 08:36:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7BVq-0000FI-Hv; Mon, 22 Aug 2005 08:34:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7BVl-0000Dw-6H for [e-mail]; Mon, 22 Aug 2005 08:34:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12504 for <[e-mail]>; Mon, 22 Aug 2005 08:34:43 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/iWwaKusiWE//7HClw82ejVqd/ouLMwbk=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7C6J-0007cX-NO for [e-mail]; Mon, 22 Aug 2005 09:12:32 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7MCXSlu028112; Mon, 22 Aug 2005 13:33:32 +0100
Date: Mon, 22 Aug 2005 13:33:28 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
Cc: Inter-Domain Routing List <[e-mail]>, [e-mail]
Subject: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.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]

On Sun, 21 Aug 2005, Enke Chen wrote:

> Hi, Paul:
>
> One general comment first: The 4-byte AS scheme was spec'ed in 2001 
> after several design iterations (particular on transition). The 
> spec has been stable for more than four years.  As I understand, 
> there have been more than one implementations, and some have been 
> deployed for years.

As I understand it, there's one implementation I've heard mentioned 
by name (at the GRO WG), and there's a possible second 
implementation, which I've not heard anyone mention by name. Indeed, 
at GRO (i think), Bill Fenner was only aware of one implementation. 
But by time of IDR WG, people seemed to know of two.

I am intending to add a 3rd implementation (Quagga), but it was in 
starting to do so that I ran into the 'external reference' problem: 
You have to push knowledge of peer capabilities all the way down into 
your AS_PATH parsing code (which is slightly icky).

Now, /my/ as-path parsing is icky too, so i have to go clean it up. 
And I'd really much much rather key the decision whether to parse 
with 2 or 4 byte ASNs with information local to the attribute (ie the 
attribute type).

> As of last IETF, the implementation report is already under way.

I must have missed that. What I heard at the last IETF was "we need 
implementations".

> At this stage the issue you pointed out on using old tools over 
> 4-byte peers does not seem to be significant enough for us to 
> consider a change on the attribute to carry the AS_PATH info. You 
> are 4-5 years too late :-)

That's a shame.

> On the technical details, I dig up some old notes, and found out 
> that we actually discussed the idea of using the AS_PATH attribute 
> between old peers, and using of the NEW_AS_PATH attribute between 
> new peers.  The scheme would work - however the idea was dropped, 
> and primarily because of the following considerations based on my 
> recollection (Yakov, Qv and other - please correct me for any 
> inaccuracies):
>
>    o Only one transition. If both the AS_PATH attribute and the NEW_AS_PATH 
> were carried, a second transition would be necessary to get rid of one of 
> them.

There will always be two transitions, you can't avoid it.

NEW -> OLD: You'll have to check AS_PATH isn't 4byte, and rewrite it
OLD -> NEW:
 	- NEW_AS_PATH present: Cross-check with AS_PATH and 'merge'
 		               to get full path information

>    o Minimize/eliminate duplicate and inconsistent info.  Between the new 
> peers if the NEW_AS_PATH were made mandatory, and the AS_PATH optional, then 
> we would have to deal with the scenario that both attributes are present, and 
> possibly inconsistent.

You already have this scenario with OLD->NEW peers in the current 
draft though. For OLD->NEW you must deal with it. For NEW->NEW (if 
NEW is mandatory and AS_PATH is discretionary) you can simply 
cross-check and it can be an error condition (for that UPDATE anyway) 
for them to not be consistent.

However, the only reason I can think of for NEW peers to originate 
AS_PATH (if the draft specified NEW_AS_PATH between NEW always) would 
be if some kind of per-peer AS_PATH signature solution were deployed. 
Hence they should be capable of it, but it should not be the default 
imho.

Essentially, yes: there's extra work to do - during the transition 
period. And within the NEW world there'd simply be /no/ need for 
AS_PATH. The only reason to originate it to NEW peers would be to 
allow, eg, S-BGP to be deployed in an OLD and NEW world.

> More comments are inlined.

> Even if we mandated the use of the NEW_AS_PATH attribute, the old 
> tool would still not work for new peers (that is, would not produce 
> correct result) as the AS_PATH attribute would not exist and would 
> be flagged as a fatal error. (Assuming that AS_PATH and NEW_AS_PATH 
> would not be carried at the same time for the purpose of avoiding a 
> second transition.)

The old tool will still produce syntactically correct results if 
AS_PATH is present though between NEW peers and not overloaded. If it 
isn't present, the tool won't try parse it.

However, if AS_PATH syntax is overloaded as in the current draft, the 
tool will, in the best case, produce an error or pure garbage.

> It is not clear to me if there is an issue here: old tools would 
> continue to work for old sessions, and the tools need to be updated 
> to analyze new peers anyway.

Yes, they need to be updated anyway. If you overload AS_PATH they 
*definitely* need to be updated. Even if updated, the tool will have 
no way to reliably tell whether AS_PATH is 2 or 4 bytes, unless it 
captured the OPEN.

And this isn't just about tools, it's about modularity too. It simply 
will be impossible to decode an AS_PATH attribute without having the 
context of a peer (and its capabilities particularly).

>>>    o introduce a button/knob to allow a user to specify whether the 
>>> session is doing 4-byte or 2-byte.

> The first approach seems to be very reasonable, and should be 
> simple to do.

It still causes 'OLD' analysers to either produce utter gibberish or 
worse, crash - that could be an issue for IDS' btw, though one hopes 
an IDS would be robust. If you don't overload AS_PATH, then all 
existing BGP decoding software will simply continue to work. It may 
not give you a full picture anymore, becase BGP has been extended, 
but it will still give you semantically correct results.

> Another consideration was to minimize changes to the protocol.

And redefining the syntax of an existing and well-known attribute 
constitutes a 'minimal change'? As opposed to extending BGP with a 
new attribute (which you must introduce anyway for the transition 
period) and deprecating the existing attribute.

> BTW, Geoff Huston has recently written a nice article on the AS number, which 
> includes some discussions on various alternatives. Here is a pointer:
>
>    http://www.potaroo.net/ispcol/2005-08/as.html

Aye, saw it. Very interesting and good article.

So it's impossible to change this draft then?

A real shame, as I don't really see any difference between 
overloading AS_PATH or using NEW_AS_PATH other than that latter 
doesn't have the unfortunate property of making AS_PATH unparseable 
without external reference.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Whistler's Law:
 	You never know who is right, but you always know who is in charge.

_______________________________________________
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 BAA13419 for <[e-mail]>; Mon, 22 Aug 2005 01:31:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E74tW-0006wd-Id; Mon, 22 Aug 2005 01:30:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E74tU-0006wQ-8Q for [e-mail]; Mon, 22 Aug 2005 01:30:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09612 for <[e-mail]>; Mon, 22 Aug 2005 01:30:47 -0400 (EDT)
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.43) id 1E75Tz-0003rE-L6 for [e-mail]; Mon, 22 Aug 2005 02:08:32 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 Aug 2005 22:30:39 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7M5UZ0J001115; Sun, 21 Aug 2005 22:30:36 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 21 Aug 2005 22:30:36 -0700
Received: from [10.21.90.195] ([10.21.90.195]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);  Sun, 21 Aug 2005 22:30:35 -0700
Message-ID: <[e-mail]>
Date: Sun, 21 Aug 2005 22:30:35 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Susan Hares <[e-mail]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Aug 2005 05:30:35.0572 (UTC) FILETIME=[9F4E5740:01C5A6DA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
Content-Transfer-Encoding: 7bit
Cc: Inter-Domain Routing List <[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]

Hi, Sue:

Please see my reply to Paul on some of the considerations (after digging 
out some old notes).

In terms of implementation and customer experience, a couple things come 
to my mind:

Using the AS_PATH attribute across has the advantage of being able to 
continue using the "as-path" list policy and displaying the "as-path", 
etc, and avoid supporting "new-as-path" in addition to "as-path" in the 
configuation.

As the NEW_AS_PATH is optional, the check for the required attribute 
portion remains unchanged. (As I mentioned earlier, one of the 
considerations was to avoid introducing another "mandatory" attribute. 
This follows the trandition that new attributes have all been "optional" 
after RFC 1771).

-- Enke

Susan Hares wrote:

>Enke:
>
>After implementing the 4-Byte AS specification, do you think the
>avoidance of the new attribute justifies the confusion in the AS PATH
>syntax?
>
>Sue
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Enke Chen
>Sent: Friday, August 19, 2005 1:34 PM
>To: [e-mail]; Inter-Domain Routing List
>Cc: [e-mail]
>Subject: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
>
>Hi, Paul:
>
>Thanks for your comments. My comments are inlined.
>
>Paul Jakma wrote:
>
>  
>
>>Hi,
>>
>>Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:
>>
>>I am curious why you chose to overload the syntax of the existing 
>>AS_PATH attribute according to whether two peers are or are not 4byte 
>>ASN capable?
>>
>>My primary concern of this aspect of the draft is that it will become 
>>impossible to parse AS_PATH without external reference. This would 
>>have implications for protocol analysers which are asked to observe a 
>>BGP session in mid-flow (they'll have no way of parsing AS_PATH) and 
>>also for 'old' analysers which are asked to observe a session between 
>>new peers (at best, such an analyser would produce syntactically 
>>incorrect results), as well as implications for modularity of code in 
>>BGP implementations.
>>    
>>
>
>
>These protocol analysis tools need to be augmented to support the 4-byte
>
>AS numbers regardless. Without the knowledge of whether the 4-byte AS 
>capability is supported over a session,  there are a couple of options 
>for the tools:
>
>     o introduce a button/knob to allow a user to specify whether the 
>session is doing 4-byte or 2-byte.
>     o or parse the AS_PATH using 2-byte encoding first, if there is an 
>error, parse it using the 4-byte encoding (this may not be as robust as 
>the previous one).
>
>  
>
>>Would it maybe be better to leave the syntax of AS_PATH alone and 
>>simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 2byte
>>    
>>
>
>  
>
>>(you could even make AS_PATH optional and NEW_AS_PATH well-known 
>>between new speakers, so that AS_PATH slowly dies out during the 
>>transition period)?
>>    
>>
>
>
>One of the consideration was to avoid mandating another attribute.  Also
>
>it seems to be more consistent to use the AS_PATH attribute across the 
>board.
>
>Regards,
>
>-- Enke
> 
>
>_______________________________________________
>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 BAA13310 for <[e-mail]>; Mon, 22 Aug 2005 01:30:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E74pV-0006Qy-2P; Mon, 22 Aug 2005 01:26:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E74pT-0006Qt-8B for [e-mail]; Mon, 22 Aug 2005 01:26:39 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09467 for <[e-mail]>; Mon, 22 Aug 2005 01:26:38 -0400 (EDT)
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.43) id 1E75Px-0003lR-Le for [e-mail]; Mon, 22 Aug 2005 02:04:23 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Aug 2005 22:26:29 -0700
X-IronPort-AV: i="3.96,129,1122879600";  d="scan'208"; a="334373377:sNHT30477340"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7M5Q7QU004431; Sun, 21 Aug 2005 22:26:20 -0700 (PDT)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 21 Aug 2005 22:26:19 -0700
Received: from [10.21.90.195] ([10.21.90.195]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);  Sun, 21 Aug 2005 22:26:19 -0700
Message-ID: <[e-mail]>
Date: Sun, 21 Aug 2005 22:26:18 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tulip Rasputin <[e-mail]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Aug 2005 05:26:19.0112 (UTC) FILETIME=[0671A680:01C5A6DA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit
Cc: Inter-Domain Routing List <[e-mail]>, Paul Jakma <[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]

Tulip Rasputin wrote:

>>One general comment first: The 4-byte AS scheme was spec'ed in 2001 
>>after several design iterations (particular on transition). The spec has 
>>been stable for more than four years.  As I understand, there have been 
>>more than one implementations, and some have been deployed for years.  
>>As of last IETF, the implementation report is already under way.  At 
>>this stage the issue you pointed out on using old  tools over  4-byte  
>>peers does not seem to be significant enough for us to consider a change 
>>on the attribute to carry the AS_PATH info. You are 4-5 years too late :-)
>>    
>>
>
>Strange. 
>
>If this is the case, then why do we still have such 'drafts' for which we're too late to comment
>on still in the "draft" stage and hanging off the IDR WG shelf for review?
>  
>

I did not say "too late for comment".  It is just too late to change 
encoding.

>Why dont we take them off and publish 'em as RFCs and standards?
>  
>

That was the plan, and should happen soon.

-- 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 BAA12707 for <[e-mail]>; Mon, 22 Aug 2005 01:23:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E74lN-0005g1-CC; Mon, 22 Aug 2005 01:22:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E74lL-0005ft-GH for [e-mail]; Mon, 22 Aug 2005 01:22:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09314 for <[e-mail]>; Mon, 22 Aug 2005 01:22:22 -0400 (EDT)
Received: from web60712.mail.yahoo.com ([209.73.178.215]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E75Lj-0003eZ-Js for [e-mail]; Mon, 22 Aug 2005 02:00:07 -0400
Received: (qmail 70021 invoked by uid 60001); 22 Aug 2005 05:22:07 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Hyezb98R5eSyHvbFjOu8gaLP7ZmTJIlELK0NeNVOjlqae9n54xfg61xC9lw7zHQudN8y2Ti15e0AZqbMgPABRyvT8hmvRx/oAS1DglS/l2n+l+lPB1G6xyVXs1u3Cuv5rOcBHEpWoYxZXvlG+V0a8WvpWAVguTOPQ6TgZh7fobo= ; 
Message-ID: <[e-mail]>
Received: from [202.144.106.188] by web60712.mail.yahoo.com via HTTP; Mon, 22 Aug 2005 01:22:07 EDT
Date: Mon, 22 Aug 2005 01:22:07 -0400 (EDT)
From: Tulip Rasputin <[e-mail]>
Subject: Re: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
To: Enke Chen <[e-mail]>, Paul Jakma <[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.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 8bit
Cc: Inter-Domain Routing List <[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]

> One general comment first: The 4-byte AS scheme was spec'ed in 2001 
> after several design iterations (particular on transition). The spec has 
> been stable for more than four years.  As I understand, there have been 
> more than one implementations, and some have been deployed for years.  
> As of last IETF, the implementation report is already under way.  At 
> this stage the issue you pointed out on using old  tools over  4-byte  
> peers does not seem to be significant enough for us to consider a change 
> on the attribute to carry the AS_PATH info. You are 4-5 years too late :-)

Strange. 

If this is the case, then why do we still have such 'drafts' for which we're too late to comment
on still in the "draft" stage and hanging off the IDR WG shelf for review?

Why dont we take them off and publish 'em as RFCs and standards?

Tulip


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.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 BAA11006 for <[e-mail]>; Mon, 22 Aug 2005 01:01:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E74Q1-0002Os-OW; Mon, 22 Aug 2005 01:00:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E74Q0-0002On-B3 for [e-mail]; Mon, 22 Aug 2005 01:00:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08494 for <[e-mail]>; Mon, 22 Aug 2005 01:00:19 -0400 (EDT)
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.43) id 1E750V-00038O-9N for [e-mail]; Mon, 22 Aug 2005 01:38:03 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 21 Aug 2005 22:00:09 -0700
X-IronPort-AV: i="3.96,129,1122879600";  d="scan'208"; a="655933514:sNHT33016332"
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7M505oo024927; Sun, 21 Aug 2005 22:00:06 -0700 (PDT)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 21 Aug 2005 22:00:05 -0700
Received: from [10.21.90.195] ([10.21.90.195]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);  Sun, 21 Aug 2005 22:00:05 -0700
Message-ID: <[e-mail]>
Date: Sun, 21 Aug 2005 22:00:03 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Jakma <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Aug 2005 05:00:05.0159 (UTC) FILETIME=[5C4B7B70:01C5A6D6]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Content-Transfer-Encoding: 7bit
Cc: Inter-Domain Routing List <[e-mail]>, [e-mail]
Subject: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.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]

Hi, Paul:

One general comment first: The 4-byte AS scheme was spec'ed in 2001 
after several design iterations (particular on transition). The spec has 
been stable for more than four years.  As I understand, there have been 
more than one implementations, and some have been deployed for years.  
As of last IETF, the implementation report is already under way.  At 
this stage the issue you pointed out on using old  tools over  4-byte  
peers does not seem to be significant enough for us to consider a change 
on the attribute to carry the AS_PATH info. You are 4-5 years too late :-)

On the technical details, I dig up some old notes, and found out that we 
actually discussed the idea of using the AS_PATH attribute between old 
peers, and using of the NEW_AS_PATH attribute between new peers.  The 
scheme would work - however the idea was dropped, and primarily because 
of the following considerations based on my recollection (Yakov, Qv and 
other - please correct me for any inaccuracies):

     o Only one transition. If both the AS_PATH attribute and the 
NEW_AS_PATH were carried, a second transition would be necessary to get 
rid of one of them.
     o Minimize/eliminate duplicate and inconsistent info.  Between the 
new peers if the NEW_AS_PATH were made mandatory, and the AS_PATH 
optional, then we would have to deal with the scenario that both 
attributes are present, and possibly inconsistent.

More comments are inlined.

Paul Jakma wrote:

> On Fri, 19 Aug 2005, Enke Chen wrote:
>
>> These protocol analysis tools need to be augmented to support the 
>> 4-byte AS numbers regardless.
>
>
> Yes they would indeed. But by overloading AS_PATH you turn the case of 
> an old analyser showing syntactically correct values, eg:
>
>     AS_PATH <AS_TRANS>
>
> or simply not finding an AS_PATH at all if it isn't there, into it 
> showing complete gibberish.


Even if we mandated the use of the NEW_AS_PATH attribute, the old tool 
would still not work for new peers (that is, would not produce correct 
result) as the AS_PATH attribute would not exist and would be flagged as 
a fatal error.  (Assuming that AS_PATH and NEW_AS_PATH would not be 
carried at the same time for the purpose of avoiding a second transition.)

>
> Then there is the second issue, which would affect both 'new' and 
> 'old' analysers, which is that it will be impossible to analyse a BGP 
> stream and be able to reliably interpret AS_PATH without having 
> observed the OPEN. Because the only time the information as to which 
> kind of overloaded AS_PATH is being sent is present on the wire will 
> be at OPEN.
>
> This would be an issue during the transition period particularly, 
> where there would be no safe default assumption one could make of what 
> size ASN's are used in an AS_PATH.


It is not clear to me if there is an issue here: old tools would 
continue to work for old sessions, and the tools need to be updated to 
analyze new peers anyway.

>
>> Without the knowledge of whether the 4-byte AS capability is 
>> supported over a session, there are a couple of options for the tools:
>
>
>>    o introduce a button/knob to allow a user to specify whether the 
>> session is doing 4-byte or 2-byte.
>>    o or parse the AS_PATH using 2-byte encoding first, if there is an 
>> error, parse it using the 4-byte encoding (this may not be as robust 
>> as the previous one).
>
>
> Not sure either of these are ideal. I'd concur that latter could not 
> be done reliably: I'm reasonably sure you could construct a byte 
> stream which, syntactically, would be both a valid 2 and 4 byte AS_PATH.


The first approach seems to be very reasonable, and should be simple to do.

>
>> One of the consideration was to avoid mandating another attribute.
>
>
> But the draft must anyway, NEW_AS_PATH. So given it can not be 
> avoided, let's use it properly :).
>
>> Also it seems to be more consistent to use the AS_PATH attribute 
>> across the board.
>
>
> I'd say it's more consistent to *not* overload the on-wire syntax of 
> an existing attribute (particularly not according to a once-off 
> capability negotation), and just use the old for 2byte and the new for 
> 4byte.
>
> Indeed, add a 'ASN bytes' field to the NEW_AS_PATH so we never, ever, 
> ever, have to worry about sizeof (ASN) again ;).


Another consideration was to minimize changes to the protocol.

BTW, Geoff Huston has recently written a nice article on the AS number, 
which includes some discussions on various alternatives. Here is a pointer:

     http://www.potaroo.net/ispcol/2005-08/as.html

Regards,

-- 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 NAA15884 for <[e-mail]>; Sun, 21 Aug 2005 13:12:55 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6tN9-0008RM-Iy; Sun, 21 Aug 2005 13:12:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6tN7-0008RE-AM for [e-mail]; Sun, 21 Aug 2005 13:12:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08674 for <[e-mail]>; Sun, 21 Aug 2005 13:12:34 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX182/j/JDrlzPUElfrsSrfu2OHiVGXsjtqY=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6txU-0003ex-QF for [e-mail]; Sun, 21 Aug 2005 13:50:14 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7LHAqFP016630; Sun, 21 Aug 2005 18:10:55 +0100
Date: Sun, 21 Aug 2005 18:10:51 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Susan Hares <[e-mail]>
Subject: RE: [Idr] comment on draft-ietf-idr-as4bytes-10.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: Inter-Domain Routing List <[e-mail]>, Russ White <[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 Sun, 21 Aug 2005, Susan Hares wrote:

> Did you ever answer his original concept - that we should create a "new
> AS path" attribute?

Well, the draft as it stands /does/ create a NEW_AS_PATH, but only 
for purpose of propogating 4byte ASNs across OLD speakers. Between 
NEW speakers the existing AS_PATH type is used, but overloaded to 
4byte format.

I'd rather simply see AS_PATH stay 2 byte and NEW_AS_PATH always used 
for 4byte. I'm hacking on the draft at moment to reflect this opinion 
of mine ;).

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Someone thought The Big Red Button was a light switch.

_______________________________________________
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 NAA15367 for <[e-mail]>; Sun, 21 Aug 2005 13:05:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6tFw-000727-Hx; Sun, 21 Aug 2005 13:05:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6tFu-000722-Tf for [e-mail]; Sun, 21 Aug 2005 13:05:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08374 for <[e-mail]>; Sun, 21 Aug 2005 13:05:07 -0400 (EDT)
Received: from gateout01.mbox.net ([165.212.64.21] helo=gwo1.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6tqJ-0003UV-MZ for [e-mail]; Sun, 21 Aug 2005 13:42:48 -0400
Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gwo1.mbox.net (Postfix) with SMTP id 8546912D41D; Sun, 21 Aug 2005 17:04:56 +0000 (GMT)
Received: from gateout01.mbox.net [165.212.64.21] by gateout01.mbox.net via mtad (C8.MAIN.3.17K)  with ESMTP id 712JHuRe40418Mo1; Sun, 21 Aug 2005 17:04:55 GMT
Received: from gw3.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.21U); Sun, 21 Aug 2005 17:04:55 GMT
X-USANET-Source: 165.212.116.254 IN   [e-mail] gw3.EXCHPROD.USA.NET
X-USANET-MsgId: XID639JHuRe44068Xo1
Received: from VS4.EXCHPROD.USA.NET ([10.116.208.142]) by gw3.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.211);  Sun, 21 Aug 2005 11:04:54 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Date: Sun, 21 Aug 2005 11:04:53 -0600
Message-ID: <[e-mail]>
Thread-Topic: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt
Thread-Index: AcWk5ErkT/6dJB7iQlC6PGJlMcOYfABjfI+Q
From: "Susan Hares" <[e-mail]>
To: "Enke Chen" <[e-mail]>, <[e-mail]>, "Inter-Domain Routing List" <[e-mail]>
X-OriginalArrivalTime: 21 Aug 2005 17:04:54.0833 (UTC) FILETIME=[73BF5A10:01C5A672]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id NAA15367

Enke:

After implementing the 4-Byte AS specification, do you think the
avoidance of the new attribute justifies the confusion in the AS PATH
syntax?

Sue

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Enke Chen
Sent: Friday, August 19, 2005 1:34 PM
To: [e-mail]; Inter-Domain Routing List
Cc: [e-mail]
Subject: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.txt

Hi, Paul:

Thanks for your comments. My comments are inlined.

Paul Jakma wrote:

> Hi,
>
> Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:
>
> I am curious why you chose to overload the syntax of the existing 
> AS_PATH attribute according to whether two peers are or are not 4byte 
> ASN capable?
>
> My primary concern of this aspect of the draft is that it will become 
> impossible to parse AS_PATH without external reference. This would 
> have implications for protocol analysers which are asked to observe a 
> BGP session in mid-flow (they'll have no way of parsing AS_PATH) and 
> also for 'old' analysers which are asked to observe a session between 
> new peers (at best, such an analyser would produce syntactically 
> incorrect results), as well as implications for modularity of code in 
> BGP implementations.


These protocol analysis tools need to be augmented to support the 4-byte

AS numbers regardless. Without the knowledge of whether the 4-byte AS 
capability is supported over a session,  there are a couple of options 
for the tools:

     o introduce a button/knob to allow a user to specify whether the 
session is doing 4-byte or 2-byte.
     o or parse the AS_PATH using 2-byte encoding first, if there is an 
error, parse it using the 4-byte encoding (this may not be as robust as 
the previous one).

>
> Would it maybe be better to leave the syntax of AS_PATH alone and 
> simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 2byte

> (you could even make AS_PATH optional and NEW_AS_PATH well-known 
> between new speakers, so that AS_PATH slowly dies out during the 
> transition period)?


One of the consideration was to avoid mandating another attribute.  Also

it seems to be more consistent to use the AS_PATH attribute across the 
board.

Regards,

-- Enke
 

_______________________________________________
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 NAA15349 for <[e-mail]>; Sun, 21 Aug 2005 13:05:06 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6tDC-0006jE-SY; Sun, 21 Aug 2005 13:02:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6tDA-0006j9-Oi for [e-mail]; Sun, 21 Aug 2005 13:02:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08260 for <[e-mail]>; Sun, 21 Aug 2005 13:02:17 -0400 (EDT)
Received: from gateout01.mbox.net ([165.212.64.21] helo=gwo1.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6tnZ-0003QN-Bv for [e-mail]; Sun, 21 Aug 2005 13:39:57 -0400
Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gwo1.mbox.net (Postfix) with SMTP id A6E2212D425; Sun, 21 Aug 2005 17:01:55 +0000 (GMT)
Received: from gateout01.mbox.net [165.212.64.21] by gateout01.mbox.net via mtad (C8.MAIN.3.17K)  with ESMTP id 593JHuRB20002Mo1; Sun, 21 Aug 2005 17:01:53 GMT
Received: from gw1.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.21U); Sun, 21 Aug 2005 17:01:53 GMT
X-USANET-Source: 165.212.116.254 IN   [e-mail] gw1.EXCHPROD.USA.NET
X-USANET-MsgId: XID538JHuRB33912Xo1
Received: from VS4.EXCHPROD.USA.NET ([10.116.208.142]) by gw1.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.211);  Sun, 21 Aug 2005 11:01:53 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: [Idr] comment on draft-ietf-idr-as4bytes-10.txt
Date: Sun, 21 Aug 2005 11:01:52 -0600
Message-ID: <[e-mail]>
Thread-Topic: [Idr] comment on draft-ietf-idr-as4bytes-10.txt
Thread-Index: AcWk0giI8RF/EnDwTROcadNXUHnsogBn8KRA
From: "Susan Hares" <[e-mail]>
To: "Russ White" <[e-mail]>, <[e-mail]>, "Inter-Domain Routing List" <[e-mail]>
X-OriginalArrivalTime: 21 Aug 2005 17:01:53.0499 (UTC) FILETIME=[07A9FAB0:01C5A672]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
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 NAA15349

Russ:

Ok - that option requires extended communities - another overloading of
syntax. 

Did you ever answer his original concept - that we should create a "new
AS path" attribute?

Sue


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Russ White
Sent: Friday, August 19, 2005 11:23 AM
To: [e-mail]; Inter-Domain Routing List
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Another option is to store the path in extended communities, as in 
draft-ward...

:-)

Russ

Paul Jakma wrote:
> Hi,
> 
> Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:
> 
> I am curious why you chose to overload the syntax of the existing 
> AS_PATH attribute according to whether two peers are or are not 4byte 
> ASN capable?
> 
> My primary concern of this aspect of the draft is that it will become 
> impossible to parse AS_PATH without external reference. This would
have 
> implications for protocol analysers which are asked to observe a BGP 
> session in mid-flow (they'll have no way of parsing AS_PATH) and also 
> for 'old' analysers which are asked to observe a session between new 
> peers (at best, such an analyser would produce syntactically incorrect

> results), as well as implications for modularity of code in BGP 
> implementations.
> 
> Would it maybe be better to leave the syntax of AS_PATH alone and
simply 
> mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 2byte (you 
> could even make AS_PATH optional and NEW_AS_PATH well-known between
new 
> speakers, so that AS_PATH slowly dies out during the transition
period)?
> 
> regards,

- -- 
[e-mail] CCIE <>< Grace Alone


-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.2 (Build 2424)

iQA/AwUBQwX5VxEdu7FIVPTkEQKbOgCeKpp/QND7pBkD0cju67Zz7AdKikwAoIke
pctAoG77Ng0iqeoqwW5y/Kmz
=c1aj
-----END PGP SIGNATURE-----

_______________________________________________
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 NAA08191 for <[e-mail]>; Fri, 19 Aug 2005 13:49:51 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Azg-00086i-G3; Fri, 19 Aug 2005 13:49:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Aze-00086H-IV for [e-mail]; Fri, 19 Aug 2005 13:49:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19131 for <[e-mail]>; Fri, 19 Aug 2005 13:49:24 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/L0h08siZ35QLHMINOivXiqHGDJix99Jw=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6BZc-0000zX-N0 for [e-mail]; Fri, 19 Aug 2005 14:26:38 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7JHlAdS017759; Fri, 19 Aug 2005 18:47:14 +0100
Date: Fri, 19 Aug 2005 18:47:10 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Enke Chen <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: Inter-Domain Routing List <[e-mail]>, [e-mail]
Subject: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.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]

On Fri, 19 Aug 2005, Enke Chen wrote:

> These protocol analysis tools need to be augmented to support the 
> 4-byte AS numbers regardless.

Yes they would indeed. But by overloading AS_PATH you turn the case 
of an old analyser showing syntactically correct values, eg:

 	AS_PATH <AS_TRANS>

or simply not finding an AS_PATH at all if it isn't there, into it 
showing complete gibberish.

Then there is the second issue, which would affect both 'new' and 
'old' analysers, which is that it will be impossible to analyse a BGP 
stream and be able to reliably interpret AS_PATH without having 
observed the OPEN. Because the only time the information as to which 
kind of overloaded AS_PATH is being sent is present on the wire will 
be at OPEN.

This would be an issue during the transition period particularly, 
where there would be no safe default assumption one could make of 
what size ASN's are used in an AS_PATH.

> Without the knowledge of whether the 4-byte AS capability is 
> supported over a session, there are a couple of options for the 
> tools:

>    o introduce a button/knob to allow a user to specify whether the session 
> is doing 4-byte or 2-byte.
>    o or parse the AS_PATH using 2-byte encoding first, if there is an error, 
> parse it using the 4-byte encoding (this may not be as robust as the previous 
> one).

Not sure either of these are ideal. I'd concur that latter could not 
be done reliably: I'm reasonably sure you could construct a byte 
stream which, syntactically, would be both a valid 2 and 4 byte 
AS_PATH.

> One of the consideration was to avoid mandating another attribute.

But the draft must anyway, NEW_AS_PATH. So given it can not be 
avoided, let's use it properly :).

> Also it seems to be more consistent to use the AS_PATH attribute 
> across the board.

I'd say it's more consistent to *not* overload the on-wire syntax of 
an existing attribute (particularly not according to a once-off 
capability negotation), and just use the old for 2byte and the new 
for 4byte.

Indeed, add a 'ASN bytes' field to the NEW_AS_PATH so we never, ever, 
ever, have to worry about sizeof (ASN) again ;).

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
You've been telling me to relax all the way here, and now you're telling
me just to be myself?
 		-- The Return of the Secaucus Seven

_______________________________________________
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 NAA07039 for <[e-mail]>; Fri, 19 Aug 2005 13:35:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Al6-0003Ry-Ch; Fri, 19 Aug 2005 13:34:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Al4-0003Rb-Rh for [e-mail]; Fri, 19 Aug 2005 13:34:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18501 for <[e-mail]>; Fri, 19 Aug 2005 13:34:19 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6BL3-0000YB-Ke for [e-mail]; Fri, 19 Aug 2005 14:11:34 -0400
Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 19 Aug 2005 10:33:54 -0700
X-IronPort-AV: i="3.96,126,1122879600";  d="scan'208"; a="206273776:sNHT1602115288"
Received: from [128.107.134.9] (enke-linux.cisco.com [128.107.134.9]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7JHXqZ1019557; Fri, 19 Aug 2005 10:33:52 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 19 Aug 2005 10:33:52 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], Inter-Domain Routing List <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
Subject: [Idr] Re: comment on draft-ietf-idr-as4bytes-10.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]

Hi, Paul:

Thanks for your comments. My comments are inlined.

Paul Jakma wrote:

> Hi,
>
> Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:
>
> I am curious why you chose to overload the syntax of the existing 
> AS_PATH attribute according to whether two peers are or are not 4byte 
> ASN capable?
>
> My primary concern of this aspect of the draft is that it will become 
> impossible to parse AS_PATH without external reference. This would 
> have implications for protocol analysers which are asked to observe a 
> BGP session in mid-flow (they'll have no way of parsing AS_PATH) and 
> also for 'old' analysers which are asked to observe a session between 
> new peers (at best, such an analyser would produce syntactically 
> incorrect results), as well as implications for modularity of code in 
> BGP implementations.


These protocol analysis tools need to be augmented to support the 4-byte 
AS numbers regardless. Without the knowledge of whether the 4-byte AS 
capability is supported over a session,  there are a couple of options 
for the tools:

     o introduce a button/knob to allow a user to specify whether the 
session is doing 4-byte or 2-byte.
     o or parse the AS_PATH using 2-byte encoding first, if there is an 
error, parse it using the 4-byte encoding (this may not be as robust as 
the previous one).

>
> Would it maybe be better to leave the syntax of AS_PATH alone and 
> simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 2byte 
> (you could even make AS_PATH optional and NEW_AS_PATH well-known 
> between new speakers, so that AS_PATH slowly dies out during the 
> transition period)?


One of the consideration was to avoid mandating another attribute.  Also 
it seems to be more consistent to use the AS_PATH attribute across the 
board.

Regards,

-- 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 LAA29315 for <[e-mail]>; Fri, 19 Aug 2005 11:56:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E69Cw-0008LT-Ng; Fri, 19 Aug 2005 11:55:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E69Cu-0008LC-Pe for [e-mail]; Fri, 19 Aug 2005 11:55:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10946 for <[e-mail]>; Fri, 19 Aug 2005 11:54:57 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E69ms-0005K5-J8 for [e-mail]; Fri, 19 Aug 2005 12:32:11 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 19 Aug 2005 11:54:51 -0400
X-IronPort-AV: i="3.96,126,1122868800";  d="scan'208"; a="67144396:sNHT43573822"
Received: from russpc (rtp-vpn2-559.cisco.com [10.82.242.47]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7JFslQm003452;  Fri, 19 Aug 2005 11:54:48 -0400 (EDT)
Received: from [10.82.242.47] by russpc (PGP Universal service); Fri, 19 Aug 2005 11:54:48 -0500
X-PGP-Universal: processed; by russpc on Fri, 19 Aug 2005 11:54:48 -0500
Message-ID: <[e-mail]>
Date: Fri, 19 Aug 2005 11:54:41 -0400
From: Russ White <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Type: text/plain; charset="ISO-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: Inter-Domain Routing List <[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]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Never mind, that draft didn't ever get published....

:-)

Russ

Russ White wrote:
> 
> Another option is to store the path in extended communities, as in 
> draft-ward...
> 
> :-)
> 
> Russ
> 
> Paul Jakma wrote:
> 
>> Hi,
>>
>> Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:
>>
>> I am curious why you chose to overload the syntax of the existing 
>> AS_PATH attribute according to whether two peers are or are not 4byte 
>> ASN capable?
>>
>> My primary concern of this aspect of the draft is that it will become 
>> impossible to parse AS_PATH without external reference. This would 
>> have implications for protocol analysers which are asked to observe a 
>> BGP session in mid-flow (they'll have no way of parsing AS_PATH) and 
>> also for 'old' analysers which are asked to observe a session between 
>> new peers (at best, such an analyser would produce syntactically 
>> incorrect results), as well as implications for modularity of code in 
>> BGP implementations.
>>
>> Would it maybe be better to leave the syntax of AS_PATH alone and 
>> simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 2byte 
>> (you could even make AS_PATH optional and NEW_AS_PATH well-known 
>> between new speakers, so that AS_PATH slowly dies out during the 
>> transition period)?
>>
>> regards,
> 
> 

- -- 
[e-mail] CCIE <>< Grace Alone


-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.2 (Build 2424)

iQA/AwUBQwYAyBEdu7FIVPTkEQK12ACZAZV77AzBlgebQmzhYyaTqUvZWyMAoMTQ
gy4A3TjP5ze03Vp4DgS+ZmA8
=baxd
-----END PGP SIGNATURE-----

_______________________________________________
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 LAA26785 for <[e-mail]>; Fri, 19 Aug 2005 11:23:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E68iD-0000fO-VY; Fri, 19 Aug 2005 11:23:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E68iB-0000fI-Hl for [e-mail]; Fri, 19 Aug 2005 11:23:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09333 for <[e-mail]>; Fri, 19 Aug 2005 11:23:12 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E69I9-0004J0-8y for [e-mail]; Fri, 19 Aug 2005 12:00:26 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 19 Aug 2005 11:23:06 -0400
X-IronPort-AV: i="3.96,126,1122868800";  d="scan'208"; a="67140062:sNHT30732904"
Received: from russpc (rtp-vpn2-559.cisco.com [10.82.242.47]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7JFN2Qm025501;  Fri, 19 Aug 2005 11:23:03 -0400 (EDT)
Received: from [10.82.242.47] by russpc (PGP Universal service); Fri, 19 Aug 2005 11:23:03 -0500
X-PGP-Universal: processed; by russpc on Fri, 19 Aug 2005 11:23:03 -0500
Message-ID: <[e-mail]>
Date: Fri, 19 Aug 2005 11:22:56 -0400
From: Russ White <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], Inter-Domain Routing List <[e-mail]>
Subject: Re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Type: text/plain; charset="ISO-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
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]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Another option is to store the path in extended communities, as in 
draft-ward...

:-)

Russ

Paul Jakma wrote:
> Hi,
> 
> Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:
> 
> I am curious why you chose to overload the syntax of the existing 
> AS_PATH attribute according to whether two peers are or are not 4byte 
> ASN capable?
> 
> My primary concern of this aspect of the draft is that it will become 
> impossible to parse AS_PATH without external reference. This would have 
> implications for protocol analysers which are asked to observe a BGP 
> session in mid-flow (they'll have no way of parsing AS_PATH) and also 
> for 'old' analysers which are asked to observe a session between new 
> peers (at best, such an analyser would produce syntactically incorrect 
> results), as well as implications for modularity of code in BGP 
> implementations.
> 
> Would it maybe be better to leave the syntax of AS_PATH alone and simply 
> mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 2byte (you 
> could even make AS_PATH optional and NEW_AS_PATH well-known between new 
> speakers, so that AS_PATH slowly dies out during the transition period)?
> 
> regards,

- -- 
[e-mail] CCIE <>< Grace Alone


-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.2 (Build 2424)

iQA/AwUBQwX5VxEdu7FIVPTkEQKbOgCeKpp/QND7pBkD0cju67Zz7AdKikwAoIke
pctAoG77Ng0iqeoqwW5y/Kmz
=c1aj
-----END PGP SIGNATURE-----

_______________________________________________
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 JAA19151 for <[e-mail]>; Fri, 19 Aug 2005 09:47:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E67B4-0000Nd-4V; Fri, 19 Aug 2005 09:44:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E67B1-0000NU-3N for [e-mail]; Fri, 19 Aug 2005 09:44:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03333 for <[e-mail]>; Fri, 19 Aug 2005 09:44:52 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/nwcGe6QhCadNuLERzn3fe8N+zgJy6aA0=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E67kv-0001Kh-Fq for [e-mail]; Fri, 19 Aug 2005 10:22:05 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7JDig6c014864; Fri, 19 Aug 2005 14:44:45 +0100
Date: Fri, 19 Aug 2005 14:44:42 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Mail-Copies-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: Inter-Domain Routing List <[e-mail]>
Subject: [Idr] comment on draft-ietf-idr-as4bytes-10.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail], Inter-Domain Routing List <[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,

Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:

I am curious why you chose to overload the syntax of the existing 
AS_PATH attribute according to whether two peers are or are not 4byte 
ASN capable?

My primary concern of this aspect of the draft is that it will become 
impossible to parse AS_PATH without external reference. This would 
have implications for protocol analysers which are asked to observe a 
BGP session in mid-flow (they'll have no way of parsing AS_PATH) and 
also for 'old' analysers which are asked to observe a session between 
new peers (at best, such an analyser would produce syntactically 
incorrect results), as well as implications for modularity of code in 
BGP implementations.

Would it maybe be better to leave the syntax of AS_PATH alone and 
simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 
2byte (you could even make AS_PATH optional and NEW_AS_PATH 
well-known between new speakers, so that AS_PATH slowly dies out 
during the transition period)?

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Nearly every complex solution to a programming problem that I
have looked at carefully has turned out to be wrong.
 		-- Brent Welch

_______________________________________________
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 DAA19104 for <[e-mail]>; Fri, 19 Aug 2005 03:34:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E61MQ-0004kM-28; Fri, 19 Aug 2005 03:32:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E61MO-0004kF-QG for [e-mail]; Fri, 19 Aug 2005 03:32:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18092 for <[e-mail]>; Fri, 19 Aug 2005 03:32:14 -0400 (EDT)
Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E61wI-000808-Qt for [e-mail]; Fri, 19 Aug 2005 04:09:23 -0400
X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited]
Content-Class: urn:content-classes:message
Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Aug 2005 13:01:56 +0530
Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id <R1JXNBDR>; Fri, 19 Aug 2005 13:01:57 +0530
Message-ID: <[e-mail]>
From: "Vijayanand C - CTD, Chennai." <[e-mail]>
To: <[e-mail]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc 
Date: Fri, 19 Aug 2005 13:01:56 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Type: text/plain; charset="iso-8859-1"
X-OriginalArrivalTime: 19 Aug 2005 07:31:56.0992 (UTC) FILETIME=[14219C00:01C5A490]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
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 DAA19104

Using community, local pref or MED would entail carrying prefixes/NLRIs,
whereas using some form of CEASE would be a simple way which would apply for
the entire session.

 I would vote for a single draft discussing the pros and cons of all
approaches along with the recommended approach as a good start.

Regards,
Vijay
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of
> DECRAENE Bruno RD-CORE-ISS
> Sent: Wednesday, August 17, 2005 3:30 PM
> To: [e-mail]
> Cc: [e-mail]; FONDEVIOLE Benoit RD-CORE-ISS; DUBOIS Nicolas
> ROSI-DAS-ARI
> Subject: RE: [idr] BGP planned maintenance requirements as an 
> IDR WG doc
> 
> 
> 
> Hi Curtis, 
> 
> > From: Curtis Villamizar [mailto:[e-mail]] 
> 
> > For the benefit of your peer router some indication that its 
> > time for them to "cost out" your routes (or poison your 
> > peering in the above
> > terminology) might help.  The advantage of using a CEASE 
> > subcode is that any router that doesn't understand will just 
> > treat it as any other CEASE.  Backwards compatibility is 
> > always nice.  If both routers understand, they'd just 
> > LOCAL_PREF poison each side of the peering and then after 
> > some delay (probably best to specify a default and 
> > "configured on the local router") send MP_UNREACH for all 
> the routes.
> > A disadvantage of a CEASE subcode is that if a specific 
> > prefix went unreachable there is no longer a way to send an 
> > MP_UNREACH across the peering, unless this is made a 
> > non-fatal CEASE to be followed by another CEASE very shortly.
> > 
> > If I'm not mistaken, then all that is needed is an 
> > internet-draft with a CEASE subcode and some wording to 
> > indicate that it should be treated as non-fatal and result in 
> > both sides setting a very high LOCAL_PREF for all routes on 
> > the peering regardless of local policy.  I suggest that each 
> > router should enforce a maximum time to keep the peering 
> > after getting one of these CEASE, making sure that it is only 
> > used as a temporarily non-fatal policy override.
> 
> Thank you for you proposition which seems reasonnable to me.
> 
> There are multiple solutions to advertise the planned maintenance to
> eBGP peers. Using the "CEASE" message is one. To name a few, one could
> also use a dynamic capability, a well-known community, a specific MED
> value "MAX METRIC"... Each solution has its advantage and 
> disadvantage.
> We "just" have to agree on one; and I'm not sure to know how we should
> proceed for this. (one solution draft proposing one solution, one
> solution draft listing all reasonable solution and their pro & con, N
> solution drafts each proposition a solution, one requirement 
> draft ...)
> 
> I'd be pleased if you could contribute to this by writing an
> internet-draft describing your solution and addressing the 
> requirements.
> 
> > Lets see what other on the IDR list have to say about this as 
> > a potential solution.
> 
> 
> 
> 
>  
> > Curtis
> 
> Thanks,
> Best regards,
> Bruno 
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
> 
DISCLAIMER 
This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies 
and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the 
individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to 
read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, 
please notify the sender immediately by return e-mail and delete it from your computer


_______________________________________________
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 GAA21029 for <[e-mail]>; Wed, 17 Aug 2005 06:01:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Kil-0001Ge-UU; Wed, 17 Aug 2005 06:00:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Kik-0001GV-9C for [e-mail]; Wed, 17 Aug 2005 06:00:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18525 for <[e-mail]>; Wed, 17 Aug 2005 06:00:27 -0400 (EDT)
Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5LIF-0001g5-Bz for [e-mail]; Wed, 17 Aug 2005 06:37:12 -0400
Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211);  Wed, 17 Aug 2005 12:00:17 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc 
Date: Wed, 17 Aug 2005 12:00:15 +0200
Message-ID: <[e-mail]>
Thread-Topic: [idr] BGP planned maintenance requirements as an IDR WG doc 
Thread-Index: AcWhLzo7E1EXCgqlQ764dMLGdv3C/QB3RehA
From: "DECRAENE Bruno RD-CORE-ISS" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 17 Aug 2005 10:00:17.0958 (UTC) FILETIME=[78B1BC60:01C5A312]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: [e-mail], FONDEVIOLE Benoit RD-CORE-ISS <[e-mail]>, DUBOIS Nicolas ROSI-DAS-ARI <[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 GAA21029

Hi Curtis, 

> From: Curtis Villamizar [mailto:[e-mail]] 

> For the benefit of your peer router some indication that its 
> time for them to "cost out" your routes (or poison your 
> peering in the above
> terminology) might help.  The advantage of using a CEASE 
> subcode is that any router that doesn't understand will just 
> treat it as any other CEASE.  Backwards compatibility is 
> always nice.  If both routers understand, they'd just 
> LOCAL_PREF poison each side of the peering and then after 
> some delay (probably best to specify a default and 
> "configured on the local router") send MP_UNREACH for all the routes.
> A disadvantage of a CEASE subcode is that if a specific 
> prefix went unreachable there is no longer a way to send an 
> MP_UNREACH across the peering, unless this is made a 
> non-fatal CEASE to be followed by another CEASE very shortly.
> 
> If I'm not mistaken, then all that is needed is an 
> internet-draft with a CEASE subcode and some wording to 
> indicate that it should be treated as non-fatal and result in 
> both sides setting a very high LOCAL_PREF for all routes on 
> the peering regardless of local policy.  I suggest that each 
> router should enforce a maximum time to keep the peering 
> after getting one of these CEASE, making sure that it is only 
> used as a temporarily non-fatal policy override.

Thank you for you proposition which seems reasonnable to me.

There are multiple solutions to advertise the planned maintenance to
eBGP peers. Using the "CEASE" message is one. To name a few, one could
also use a dynamic capability, a well-known community, a specific MED
value "MAX METRIC"... Each solution has its advantage and disadvantage.
We "just" have to agree on one; and I'm not sure to know how we should
proceed for this. (one solution draft proposing one solution, one
solution draft listing all reasonable solution and their pro & con, N
solution drafts each proposition a solution, one requirement draft ...)

I'd be pleased if you could contribute to this by writing an
internet-draft describing your solution and addressing the requirements.

> Lets see what other on the IDR list have to say about this as 
> a potential solution.




 
> Curtis

Thanks,
Best regards,
Bruno 

_______________________________________________
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 UAA05871 for <[e-mail]>; Tue, 16 Aug 2005 20:33:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5BqD-0007Ti-9A; Tue, 16 Aug 2005 20:31:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5BqB-0007Ta-Uq for [e-mail]; Tue, 16 Aug 2005 20:31:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26698 for <[e-mail]>; Tue, 16 Aug 2005 20:31:34 -0400 (EDT)
Received: from [192.20.225.112] (helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5CPc-00046U-Ea for [e-mail]; Tue, 16 Aug 2005 21:08:13 -0400
Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id F2A86197397; Tue, 16 Aug 2005 20:21:38 -0400 (EDT)
Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j7H0VPP5017284;  Tue, 16 Aug 2005 20:31:25 -0400
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: [e-mail]
Subject: Re: [Idr] WG Last Call on IANA Considerations for 2858bis
References: <[e-mail]> <[e-mail]>
Date: Tue, 16 Aug 2005 20:31:25 -0400
From: Bill Fenner <[e-mail]>
Versions: dmail (linux) 2.6d/makemail 2.10
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]

>On Tue, 2005-08-16 at 14:52 -0700, Yakov Rekhter wrote:
>> Would it be sufficient if IANA documents these (current) allocations, 
>> and then manages the rest of [128-140] on FCFS basis ?
>
>No objection from my part. Is IANA ok with this ?

In my conversations with IANA, I believe they would be amenable to
this - we say that 128-140 is FCFS but document the existing
allocations (after all, if it's FCFS you can just get a number
by asking).  We can even mark the others you mention such as
130 and 131 as reserved by IANA, to put off problems with
collisions with undeployed stuff that uses them.

What about the apparent 129 conflict in your list?

  Bill

_______________________________________________
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 SAA23833 for <[e-mail]>; Tue, 16 Aug 2005 18:04:08 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59Wj-0007AR-Nh; Tue, 16 Aug 2005 18:03:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59Wh-00077o-73 for [e-mail]; Tue, 16 Aug 2005 18:03:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15126 for <[e-mail]>; Tue, 16 Aug 2005 18:03:16 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5A66-00009J-8v for [e-mail]; Tue, 16 Aug 2005 18:39:55 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j7GM38940046;  Tue, 16 Aug 2005 15:03:08 -0700 (PDT) (envelope-from [e-mail])
Received: from roque-lnx.juniper.net (roque-lnx.juniper.net [172.17.12.76]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7GM2vG67398; Tue, 16 Aug 2005 15:02:57 -0700 (PDT) (envelope-from [e-mail])
Subject: Re: [Idr] WG Last Call on IANA Considerations for 2858bis
From: Pedro Roque Marques <[e-mail]>
To: Yakov Rekhter <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Tue, 16 Aug 2005 15:02:56 -0700
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Content-Transfer-Encoding: 7bit
Cc: Bill Fenner <[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]

On Tue, 2005-08-16 at 14:52 -0700, Yakov Rekhter wrote:

> 
> Would it be sufficient if IANA documents these (current) allocations, 
> and then manages the rest of [128-140] on FCFS basis ?

No objection from my part. Is IANA ok with this ?

  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 SAA23556 for <[e-mail]>; Tue, 16 Aug 2005 18:00:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59MP-00054W-SK; Tue, 16 Aug 2005 17:52:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59MN-00054F-CH for [e-mail]; Tue, 16 Aug 2005 17:52:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14542 for <[e-mail]>; Tue, 16 Aug 2005 17:52:36 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E59vm-0008Ki-8o for [e-mail]; Tue, 16 Aug 2005 18:29:15 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j7GLqS939905;  Tue, 16 Aug 2005 14:52:28 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7GLqNG65316; Tue, 16 Aug 2005 14:52:23 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Subject: Re: [Idr] WG Last Call on IANA Considerations for 2858bis 
In-Reply-To: Your message of "Tue, 16 Aug 2005 14:47:35 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 16 Aug 2005 14:52:23 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: Bill Fenner <[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]

Pedro,

> On Tue, 2005-08-16 at 14:26 -0700, Yakov Rekhter wrote:
> 
> > If in fact there are no used SAFI above 140, then how about
> > changing IANA FCFS to [64-140] (as to cover all the known
> > used SAFI), and changing reserved to [141-254].
> 
> I'm concerned w/ the space between 128 - 140. There are allocations
> there that are in use that i'd like to make sure IANA doesn't try to
> allocate over. I'd like to see that clarified.
>
> I think we are in rough agreement on the following:
> 
>   Have IANA manage [64 - 128] (including current allocations 64, 65,
> 66).
> 
>   Leave unused space as reserved [141 - 254]. Can be allocated in future
> to IANA, depends on future experience.
> 
> As far as the space [128 - 140],
>   I'd like to mark it as "space not managed by iana", given the presence
> of current allocations. In my previous e-mail i didn't include 130 and
> 131 but i believe these where in use at some point (or at least
> documented).

Would it be sufficient if IANA documents these (current) allocations, 
and then manages the rest of [128-140] on FCFS basis ?

Yakov.

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA22577 for <[e-mail]>; Tue, 16 Aug 2005 17:49:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59Hk-0003m5-3U; Tue, 16 Aug 2005 17:47:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59Hg-0003ls-Dg for [e-mail]; Tue, 16 Aug 2005 17:47:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14253 for <[e-mail]>; Tue, 16 Aug 2005 17:47:45 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E59r6-0008BS-50 for [e-mail]; Tue, 16 Aug 2005 18:24:24 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j7GLldBm059846; Tue, 16 Aug 2005 14:47:39 -0700 (PDT) (envelope-from [e-mail])
Received: from roque-lnx.juniper.net (roque-lnx.juniper.net [172.17.12.76]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7GLlZG64308; Tue, 16 Aug 2005 14:47:35 -0700 (PDT) (envelope-from [e-mail])
Subject: Re: [Idr] WG Last Call on IANA Considerations for 2858bis
From: Pedro Roque Marques <[e-mail]>
To: Yakov Rekhter <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Tue, 16 Aug 2005 14:47:35 -0700
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Cc: Bill Fenner <[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]

On Tue, 2005-08-16 at 14:26 -0700, Yakov Rekhter wrote:

> If in fact there are no used SAFI above 140, then how about
> changing IANA FCFS to [64-140] (as to cover all the known
> used SAFI), and changing reserved to [141-254].

I'm concerned w/ the space between 128 - 140. There are allocations
there that are in use that i'd like to make sure IANA doesn't try to
allocate over. I'd like to see that clarified.

I think we are in rough agreement on the following:

  Have IANA manage [64 - 128] (including current allocations 64, 65,
66).

  Leave unused space as reserved [141 - 254]. Can be allocated in future
to IANA, depends on future experience.

As far as the space [128 - 140],
  I'd like to mark it as "space not managed by iana", given the presence
of current allocations. In my previous e-mail i didn't include 130 and
131 but i believe these where in use at some point (or at least
documented).

  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 RAA20836 for <[e-mail]>; Tue, 16 Aug 2005 17:28:04 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58xa-0007Oe-Bx; Tue, 16 Aug 2005 17:27:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58xZ-0007Mu-18 for [e-mail]; Tue, 16 Aug 2005 17:27:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13429 for <[e-mail]>; Tue, 16 Aug 2005 17:26:58 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E59Wx-0007es-Og for [e-mail]; Tue, 16 Aug 2005 18:03:37 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j7GLQoBm059744; Tue, 16 Aug 2005 14:26:50 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7GLQoG59388; Tue, 16 Aug 2005 14:26:50 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Subject: Re: [Idr] WG Last Call on IANA Considerations for 2858bis 
In-Reply-To: Your message of "Tue, 16 Aug 2005 14:14:28 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 16 Aug 2005 14:26:50 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: Bill Fenner <[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]

Pedro,

> On Tue, 2005-08-16 at 13:49 -0700, Yakov Rekhter wrote:
> > Please indicate your preference wrt these two alternatives (or if you
> > have yet another alternative please post it to the list) as soon
> > as possible, as the deadline for comments is Aug 22.
> 
> Yakov,
> 
> This is the SAFI values that i believe are currently in use:
> 1, 2     (unicast, multicast)
> 4        (label-unicast)
> 64       (tunnel)                             [iana assigned]
> 65       (vpls)                               [iana assigned]
> 66       (mdt)                                [iana assigned]
> 128, 129 (2547 ucast, mcast)
> 129      (vr-based autodiscovery)
> 132      (rt-constrain)
> 133, 134 (flow-spec)
> 140      (l2 auto discovery ?)
> 
> I'd like to see:
> [64-127] Iana FCFS
> [128 - 160] reserved + current usage documented.
> [160 - 254] reserved to be released in future for iana.

If in fact there are no used SAFI above 140, then how about
changing IANA FCFS to [64-140] (as to cover all the known
used SAFI), and changing reserved to [141-254].

Yakov.

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA19812 for <[e-mail]>; Tue, 16 Aug 2005 17:14:52 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58le-0004LR-Sg; Tue, 16 Aug 2005 17:14:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58ld-0004LM-N6 for [e-mail]; Tue, 16 Aug 2005 17:14:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12874 for <[e-mail]>; Tue, 16 Aug 2005 17:14:39 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E59L0-0007LV-C7 for [e-mail]; Tue, 16 Aug 2005 17:51:17 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j7GLETBm059652; Tue, 16 Aug 2005 14:14:29 -0700 (PDT) (envelope-from [e-mail])
Received: from roque-lnx.juniper.net (roque-lnx.juniper.net [172.17.12.76]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7GLESG57082; Tue, 16 Aug 2005 14:14:28 -0700 (PDT) (envelope-from [e-mail])
Subject: Re: [Idr] WG Last Call on IANA Considerations for 2858bis
From: Pedro Roque Marques <[e-mail]>
To: Yakov Rekhter <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Tue, 16 Aug 2005 14:14:28 -0700
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: Bill Fenner <[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]

On Tue, 2005-08-16 at 13:49 -0700, Yakov Rekhter wrote:
> Please indicate your preference wrt these two alternatives (or if you
> have yet another alternative please post it to the list) as soon
> as possible, as the deadline for comments is Aug 22.

Yakov,

This is the SAFI values that i believe are currently in use:
1, 2     (unicast, multicast)
4        (label-unicast)
64       (tunnel)                             [iana assigned]
65       (vpls)                               [iana assigned]
66       (mdt)                                [iana assigned]
128, 129 (2547 ucast, mcast)
129      (vr-based autodiscovery)
132      (rt-constrain)
133, 134 (flow-spec)
140      (l2 auto discovery ?)

I'd like to see:
[64-127] Iana FCFS
[128 - 160] reserved + current usage documented.
[160 - 254] reserved to be released in future for iana.

  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 RAA18814 for <[e-mail]>; Tue, 16 Aug 2005 17:02:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58Xk-0000qf-0l; Tue, 16 Aug 2005 17:00:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58Xh-0000og-Gf for [e-mail]; Tue, 16 Aug 2005 17:00:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12181 for <[e-mail]>; Tue, 16 Aug 2005 17:00:14 -0400 (EDT)
Received: from fiji.merit.edu ([198.108.1.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5976-0006xp-02 for [e-mail]; Tue, 16 Aug 2005 17:36:53 -0400
Received: from localhost (localhost [127.0.0.1]) by fiji.merit.edu (Postfix) with ESMTP id 0F3D419CC; Tue, 16 Aug 2005 17:00:15 -0400 (EDT)
Received: from fiji.merit.edu ([127.0.0.1]) by localhost (fiji.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26164-02; Tue, 16 Aug 2005 17:00:14 -0400 (EDT)
Received: from [192.122.181.86] (dhcp-192-122-181-86.merit.edu [192.122.181.86]) by fiji.merit.edu (Postfix) with ESMTP id 7000E19C0; Tue, 16 Aug 2005 17:00:14 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 16 Aug 2005 17:00:14 -0400
From: Larry Blunk <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Russ White <[e-mail]>
Subject: Re: [Idr] BGP Monitoring Protocol
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: amavisd-new at merit.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Content-Transfer-Encoding: 7bit
Cc: [e-mail], Pedro Roque Marques <[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]

Russ White wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>  
>
>>>Y'all:
>>>
>>>http://www.ietf.org/internet-drafts/draft-scudder-bmp-00.txt
>>>
>>>BGP Monitoring Protocol, latest draft, posted.
>>>
>>>      
>>>
>>Russ,
>>    
>>
>
>  
>
>>grow WG seems to be working on:
>>    
>>
>
>  
>
>>http://ietf.org/internet-drafts/draft-ietf-grow-mrt-00.txt
>>
>>Any chance the 2 efforts can be coordinated / merged ?
>>It seems that the objectives are similar...
>>    
>>
>
>Yep...
>
>Glancing through the MRT spec, it looks a little different. It looks 
>like MRT is encoding, rather than transport (or did I just miss that??). 
>I would envision a working systems as something like this:
>  
>

     Yes, it primarily deals with encoding rather than transport.  There 
were some rudimentary
efforts at dealing with transport (see control types in draft).  But it 
is not fully fleshed out and
has not been implemented to my knowledge.

>- -- Router implements BMP, which just reflects BGP packets to a listener.
>- -- Listener implements some application that converts from BGP to MRT 
>format for local storage.
>
>My main concern with MRT is that it uses a different storage format for 
>each different BGP message type, which means new ones need to be defined 
>as new BGP message types are created (if they ever are). It looks like 
>the same thing for all of the other protocols, as well. Would we really 
>want to support each possible change on a router, along with the 
>processing from the received BGP format into the MRT format before 
>sending it to a monitoring station? Further, if we convert on the 
>router, are we possibly losing some information critical to security 
>systems trying to analyze traffic at a given BGP speaker?
>
>Don't know the answers myself, just asking questions.
>  
>

   The deprecated BGP type has a different subtype for each BGP message 
type, but the
newer BGP4MP type (used by Zebra/Quagga and others) simply encodes the 
entire
BGP message.

 -Larry

>:-)
>
>Russ
>
>- -- 
>[e-mail] CCIE <>< Grace Alone
>
>
>  
>


_______________________________________________
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 QAA17929 for <[e-mail]>; Tue, 16 Aug 2005 16:51:53 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58NK-00076o-6D; Tue, 16 Aug 2005 16:49:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58NI-00076j-GU for [e-mail]; Tue, 16 Aug 2005 16:49:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11793 for <[e-mail]>; Tue, 16 Aug 2005 16:49:29 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E58we-0006ij-RH for [e-mail]; Tue, 16 Aug 2005 17:26:08 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j7GKnJBm059424; Tue, 16 Aug 2005 13:49:20 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7GKnJG51330; Tue, 16 Aug 2005 13:49:19 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: [Idr] WG Last Call on IANA Considerations for 2858bis
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 16 Aug 2005 13:49:19 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: Bill Fenner <[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]

Folks,

So far we have two proposals for the IANA Consideration Section
on the table:

1. As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI
   attributes contain the Subsequence Address Family Identifier (SAFI)
   field. The SAFI name space is defined in this document. The IANA will
   maintain and register values for the SAFI namespace as follows. 
   
   SAFI values 1 and 2 are assigned in this document.  SAFI values
   4 through 63, 65, and 128 are to be assigned by IANA using either
   the "IETF Consensus" policy defined in RFC2434 or the "Early
   IANA Allocation" policy defined in RFC4020. SAFI values 64 and
   66 through 127 are to be assigned by IANA, using the "First  Come
   First Served" policy defined in RFC2434. SAFI values 240 through
   255 are for "private use", and are not to be assigned by IANA.
   SAFI values 0, 3, and 129 through 239 are reserved.

2.  As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI
    attributes contain the Subsequence Address Family Identifier (SAFI)
    field. The SAFI name space is defined in this document. The IANA will
    maintain and register values for the SAFI namespace as follows. 
    
    SAFI values 1 and 2 are assigned in this document.  SAFI values
    4 through 63, 65, and 128 are to be assigned by IANA using either
    the "IETF Consensus" policy defined in RFC2434 or the "Early
    IANA Allocation" policy defined in RFC4020. SAFI values 64 and
    66 through 239 are to be assigned by IANA, using the "First  Come
    First Served" policy defined in RFC2434. SAFI values 240 through
    254 are for "private use", and are not to be assigned by IANA.
    SAFI values 0, 3, and 129 through 239 and 255 are reserved.

The difference between the two is the size of the range for FCFS 
and for Reserved. 

Please indicate your preference wrt these two alternatives (or if you
have yet another alternative please post it to the list) as soon
as possible, as the deadline for comments is Aug 22.

Yakov.

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA07741 for <[e-mail]>; Tue, 16 Aug 2005 08:38:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E50fI-000616-SO; Tue, 16 Aug 2005 08:35:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E50fH-000611-Ee for [e-mail]; Tue, 16 Aug 2005 08:35:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07309 for <[e-mail]>; Tue, 16 Aug 2005 08:35:31 -0400 (EDT)
Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E51EZ-00082l-3K for [e-mail]; Tue, 16 Aug 2005 09:12:04 -0400
Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id FAA24648; Tue, 16 Aug 2005 05:35:01 -0700 (PDT)
Received: from manav ([10.128.16.129]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 05:34:59 -0700
Message-ID: <002701c5a25f$424c0bc0$6401a8c0@manav>
From: "Manav Bhatia" <[e-mail]>
To: "Yakov Rekhter" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: [Idr] advertising more than one route to a destination
Date: Tue, 16 Aug 2005 18:07:20 +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.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-OriginalArrivalTime: 16 Aug 2005 12:35:00.0236 (UTC) FILETIME=[EAF334C0:01C5A25E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
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]

> 
> > 2. Should the IDR WG start work on extending BGP to support
> > such applications ?
> 
> Yes

Yes.

Manav



_______________________________________________
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 GAA25890 for <[e-mail]>; Tue, 16 Aug 2005 06:06:52 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4yKH-00019d-4V; Tue, 16 Aug 2005 06:05:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4yKG-00019Y-6s for [e-mail]; Tue, 16 Aug 2005 06:05:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00850 for <[e-mail]>; Tue, 16 Aug 2005 06:05:41 -0400 (EDT)
Received: from astrolabe.info.ucl.ac.be ([130.104.229.109] helo=info.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4ytY-0004Lo-JB for [e-mail]; Tue, 16 Aug 2005 06:42:14 -0400
Received: from [127.0.0.1] (bismarck [130.104.229.58]) by info.ucl.ac.be (8.12.11/8.12.11) with ESMTP id j7GA5VQw021923; Tue, 16 Aug 2005 12:05:31 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Tue, 16 Aug 2005 12:06:00 +0200
From: Olivier Bonaventure <[e-mail]>
User-Agent: Debian Thunderbird 1.0.2 (X11/20050331)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Yakov Rekhter <[e-mail]>
Subject: Re: [Idr] advertising more than one route to a destination
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-INGI-MailScanner-Information: Please contact the ISP for more information
X-INGI-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Content-Transfer-Encoding: 7bit
Cc: [e-mail], [e-mail], Cristel Pelsser <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Yakov,
> 
> As you know the basic BGP spec currently restricts a BGP speaker
> to advertise at most a single route to a given destination (given
> address prefix).
> 
> The purpose of this e-mail is to solicit opinions on (a) what
> applications could benefit if the above restriction is relaxed, as
> to allow a BGP speaker to advertise multiple routes to a given
> destination, and (b) whether the IDR WG should start work on extending
> BGP to support these applications.
> 
> With this in mind, please answer the following two questions:
> 
> 1. What applications could benefit from allowing a BGP speaker
> to advertise multiple routes to a destination ? 

In addition to the other applications mentionned by Enke and Paul :

* Route-server type applications such as :
  - a monitoring server that learns via iBGP sessions both the active
and candidate routes available inside an AS
  - a PCE could use such an iBGP extension to collect multiple routes to
external destinations from the RR or border routers. This will aid in
the establishment of interdomain LSPs, see
http://www.info.ucl.ac.be/~cpe/Pelsser_IPOM.pdf

* Load-balancing situations where route reflectors advertise multiple
routes to their clients to allow them to load-balance their traffic

* Fast-convergence situations where route reflectors advertise both the
best paths and alternate paths to their clients to allow them to react
quickly (i.e. without waiting for an iBGP convergence) to failures


> 2. Should the IDR WG start work on extending BGP to support
> such applications ?

Yes



Best regards,



Olivier

_______________________________________________
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 SAA14080 for <[e-mail]>; Mon, 15 Aug 2005 18:42:52 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nbT-0007pY-06; Mon, 15 Aug 2005 18:38:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nbQ-0007o5-CF for [e-mail]; Mon, 15 Aug 2005 18:38:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09888 for <[e-mail]>; Mon, 15 Aug 2005 18:38:41 -0400 (EDT)
Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4oAa-0006LL-Uu for [e-mail]; Mon, 15 Aug 2005 19:15:08 -0400
Received: from jersey.sghosh.org ([68.37.244.162]) by comcast.net (rwcrmhc13) with ESMTP id <20050815223831015004obuje>; Mon, 15 Aug 2005 22:38:31 +0000
Received: from jersey.sghosh.org (localhost.localdomain [127.0.0.1]) by jersey.sghosh.org (8.13.1/8.13.1) with ESMTP id j7FMcN5H005550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Aug 2005 18:38:28 -0400
Received: from localhost (sghosh@localhost) by jersey.sghosh.org (8.13.1/8.13.1/Submit) with ESMTP id j7FMcNll005547; Mon, 15 Aug 2005 18:38:23 -0400
X-Authentication-Warning: jersey.sghosh.org: sghosh owned process doing -bs
Date: Mon, 15 Aug 2005 18:38:23 -0400 (EDT)
From: Subhendu Ghosh <[e-mail]>
To: Russ White <[e-mail]>
Subject: Re: [Idr] BGP Monitoring Protocol
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on jersey.sghosh.org
X-Virus-Status: Clean
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed  version=3.0.4
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on jersey.sghosh.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
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, 15 Aug 2005, Russ White wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Y'all:
>
> http://www.ietf.org/internet-drafts/draft-scudder-bmp-00.txt
>
> BGP Monitoring Protocol, latest draft, posted.
>
> :-)
>
> Russ
>

Needs a few line wraps for the message formats.

-- 
-rgds
sg

_______________________________________________
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 SAA12950 for <[e-mail]>; Mon, 15 Aug 2005 18:22:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nKV-00056C-Nt; Mon, 15 Aug 2005 18:21:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nKT-00055f-Pw for [e-mail]; Mon, 15 Aug 2005 18:21:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08882 for <[e-mail]>; Mon, 15 Aug 2005 18:21:11 -0400 (EDT)
Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4ntg-0005xn-66 for [e-mail]; Mon, 15 Aug 2005 18:57:37 -0400
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j7FML3KI024066; Mon, 15 Aug 2005 15:21:03 -0700
Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j7FML3a7024065; Mon, 15 Aug 2005 15:21:03 -0700
X-Authentication-Warning: m106.maoz.com: dmm set sender to [e-mail] using -f
Date: Mon, 15 Aug 2005 15:21:03 -0700
From: David Meyer <[e-mail]>
To: Russ White <[e-mail]>
Subject: Re: [Idr] BGP Monitoring Protocol
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: [e-mail], Pedro Roque Marques <[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>
Content-Type: multipart/mixed; boundary="===============0181857694=="
Sender: [e-mail]
Errors-To: [e-mail]

--===============0181857694==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI"
Content-Disposition: inline


--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 15, 2005 at 06:07:02PM -0400, Russ White wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
>=20
> >>Y'all:
> >>
> >>http://www.ietf.org/internet-drafts/draft-scudder-bmp-00.txt
> >>
> >>BGP Monitoring Protocol, latest draft, posted.
> >>
> > Russ,
>=20
> > grow WG seems to be working on:
>=20
> > http://ietf.org/internet-drafts/draft-ietf-grow-mrt-00.txt
> >=20
> > Any chance the 2 efforts can be coordinated / merged ?
> > It seems that the objectives are similar...
>=20
> Yep...
>=20
> Glancing through the MRT spec, it looks a little different. It looks=20
> like MRT is encoding, rather than transport (or did I just miss that??).=
=20
> I would envision a working systems as something like this:
>=20
> - -- Router implements BMP, which just reflects BGP packets to a listener.
> - -- Listener implements some application that converts from BGP to MRT=
=20
> format for local storage.
>=20
> My main concern with MRT is that it uses a different storage format for=
=20
> each different BGP message type, which means new ones need to be defined=
=20
> as new BGP message types are created (if they ever are). It looks like=20
> the same thing for all of the other protocols, as well. Would we really=
=20
> want to support each possible change on a router, along with the=20
> processing from the received BGP format into the MRT format before=20
> sending it to a monitoring station? Further, if we convert on the=20
> router, are we possibly losing some information critical to security=20
> systems trying to analyze traffic at a given BGP speaker?
>=20
> Don't know the answers myself, just asking questions.


	Russ,

	Both your and Pedro's points are well taken (and as such
	require more thought). And not that this should really
	gate what we eventually do, but there is quite a bit of
	code (and related analyzes) that rely on MRT format, so
	that is something else that requires some thought (to
	some extent and due to the zebra implmentation, MRT
	format became the de-facto standard). That being said,
	there is still a lot of code around that parses Cisco=20
	'sh ip bgp' format archives, which we are still
	collecting...=20

	Dave

--oyUTqETQ0mS9luUI
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFDARVPORgD1qCZ2KcRArnLAJ0d3LAHo4ms28k3DHqTlfFyaIGTJACePc68
z+qK8qQh911Xjnbdhtdi0SQ=
=NyTr
-----END PGP SIGNATURE-----

--oyUTqETQ0mS9luUI--


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

--===============0181857694==--



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 SAA12825 for <[e-mail]>; Mon, 15 Aug 2005 18:20:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nHP-0004LO-6g; Mon, 15 Aug 2005 18:18:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nHO-0004LJ-G0 for [e-mail]; Mon, 15 Aug 2005 18:18:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08525 for <[e-mail]>; Mon, 15 Aug 2005 18:18:00 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4nqa-0005sB-Io for [e-mail]; Mon, 15 Aug 2005 18:54:26 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j7FMHkBm041523; Mon, 15 Aug 2005 15:17:47 -0700 (PDT) (envelope-from [e-mail])
Received: from roque-lnx.juniper.net (roque-lnx.juniper.net [172.17.12.76]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7FMHkG10136; Mon, 15 Aug 2005 15:17:46 -0700 (PDT) (envelope-from [e-mail])
Subject: Re: [Idr] BGP Monitoring Protocol
From: Pedro Roque Marques <[e-mail]>
To: Russ White <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Mon, 15 Aug 2005 15:17:46 -0700
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit
Cc: [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]

On Mon, 2005-08-15 at 18:07 -0400, Russ White wrote:

> Yep...
> 
> Glancing through the MRT spec, it looks a little different. It looks 
> like MRT is encoding, rather than transport (or did I just miss that??). 
> I would envision a working systems as something like this:
> 
> - -- Router implements BMP, which just reflects BGP packets to a listener.
> - -- Listener implements some application that converts from BGP to MRT 
> format for local storage.
> 

What is the difference between a socket and a file ? :-)
Would help to have a single format that can be output to a "storage"
location whether it is local or remote.

At least, at the moment, i don't see the advantage in having 2 formats.

> My main concern with MRT is that it uses a different storage format for 
> each different BGP message type, which means new ones need to be defined 
> as new BGP message types are created (if they ever are). It looks like 
> the same thing for all of the other protocols, as well. Would we really 
> want to support each possible change on a router, along with the 
> processing from the received BGP format into the MRT format before 
> sending it to a monitoring station? Further, if we convert on the 
> router, are we possibly losing some information critical to security 
> systems trying to analyze traffic at a given BGP speaker?
> 
> Don't know the answers myself, just asking questions.

All valid points. Seems like these are issues for the MRT format
regardless... i.e. if message conversion is a potential concern, it
would appear to be a concern for a collector that translates a BGP
session to a MRT file as well.

  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 SAA12131 for <[e-mail]>; Mon, 15 Aug 2005 18:08:09 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4n74-0002lj-Vr; Mon, 15 Aug 2005 18:07:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4n72-0002le-OI for [e-mail]; Mon, 15 Aug 2005 18:07:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07546 for <[e-mail]>; Mon, 15 Aug 2005 18:07:18 -0400 (EDT)
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4ngG-0005fk-6N for [e-mail]; Mon, 15 Aug 2005 18:43:44 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 15 Aug 2005 15:07:12 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.96,108,1122879600"; d="scan'208"; a="6040499:sNHT20869124"
Received: from russpc (rtp-vpn2-524.cisco.com [10.82.242.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7FM77Qm029190;  Mon, 15 Aug 2005 18:07:09 -0400 (EDT)
Received: from [10.82.242.12] by russpc (PGP Universal service); Mon, 15 Aug 2005 18:07:09 -0500
X-PGP-Universal: processed; by russpc on Mon, 15 Aug 2005 18:07:09 -0500
Message-ID: <[e-mail]>
Date: Mon, 15 Aug 2005 18:07:02 -0400
From: Russ White <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pedro Roque Marques <[e-mail]>
Subject: Re: [Idr] BGP Monitoring Protocol
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Type: text/plain; charset="ISO-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: [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]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>Y'all:
>>
>>http://www.ietf.org/internet-drafts/draft-scudder-bmp-00.txt
>>
>>BGP Monitoring Protocol, latest draft, posted.
>>
> Russ,

> grow WG seems to be working on:

> http://ietf.org/internet-drafts/draft-ietf-grow-mrt-00.txt
> 
> Any chance the 2 efforts can be coordinated / merged ?
> It seems that the objectives are similar...

Yep...

Glancing through the MRT spec, it looks a little different. It looks 
like MRT is encoding, rather than transport (or did I just miss that??). 
I would envision a working systems as something like this:

- -- Router implements BMP, which just reflects BGP packets to a listener.
- -- Listener implements some application that converts from BGP to MRT 
format for local storage.

My main concern with MRT is that it uses a different storage format for 
each different BGP message type, which means new ones need to be defined 
as new BGP message types are created (if they ever are). It looks like 
the same thing for all of the other protocols, as well. Would we really 
want to support each possible change on a router, along with the 
processing from the received BGP format into the MRT format before 
sending it to a monitoring station? Further, if we convert on the 
router, are we possibly losing some information critical to security 
systems trying to analyze traffic at a given BGP speaker?

Don't know the answers myself, just asking questions.

:-)

Russ

- -- 
[e-mail] CCIE <>< Grace Alone


-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.2 (Build 2424)

iQA/AwUBQwESDREdu7FIVPTkEQL1GACgnxuQl/KVHNIMfPFDd87ZRK4wgawAn3hK
TBZlUytjiLRgaR1Fj5aYloTe
=iDem
-----END PGP SIGNATURE-----

_______________________________________________
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 SAA11926 for <[e-mail]>; Mon, 15 Aug 2005 18:04:14 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4n36-0001z0-4j; Mon, 15 Aug 2005 18:03:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4n34-0001ys-4H for [e-mail]; Mon, 15 Aug 2005 18:03:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07154 for <[e-mail]>; Mon, 15 Aug 2005 18:03:11 -0400 (EDT)
Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4ncE-0005ZQ-82 for [e-mail]; Mon, 15 Aug 2005 18:39:37 -0400
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j7FM2uIW023422; Mon, 15 Aug 2005 15:02:56 -0700
Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j7FM2uDW023421; Mon, 15 Aug 2005 15:02:56 -0700
X-Authentication-Warning: m106.maoz.com: dmm set sender to [e-mail] using -f
Date: Mon, 15 Aug 2005 15:02:56 -0700
From: David Meyer <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Subject: Re: [Idr] BGP Monitoring Protocol
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: [e-mail], [e-mail], Russ White <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0903743839=="
Sender: [e-mail]
Errors-To: [e-mail]

--===============0903743839==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb"
Content-Disposition: inline


--VS++wcV0S1rZb1Fb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

	Pedro,

On Mon, Aug 15, 2005 at 02:50:38PM -0700, Pedro Roque Marques wrote:
> On Mon, 2005-08-15 at 17:32 -0400, Russ White wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >=20
> > Y'all:
> >=20
> > http://www.ietf.org/internet-drafts/draft-scudder-bmp-00.txt
> >=20
> > BGP Monitoring Protocol, latest draft, posted.
> >=20
>=20
> Russ,
> grow WG seems to be working on:
> http://ietf.org/internet-drafts/draft-ietf-grow-mrt-00.txt
>=20
> Any chance the 2 efforts can be coordinated / merged ?
> It seems that the objectives are similar...

	Possibly, though MRT talks about an output format, and
	BMP is talking about a way to collect the data (which
	might be output in MRT format, for example). However, the
	two are to large extent independent. For example, I may
	want to write a BGP listener that implements BMP and has
	flexible (e.g., pluggable) output formats, one of which
	may be MRT.

	Dave

--VS++wcV0S1rZb1Fb
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFDAREQORgD1qCZ2KcRAo/dAJoCAh8KnIQBSlSWfaj1hBsSKpAFVwCfc/xa
L9i1+coPjNDKr65ASpPahLQ=
=8YQq
-----END PGP SIGNATURE-----

--VS++wcV0S1rZb1Fb--


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

--===============0903743839==--



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 RAA11210 for <[e-mail]>; Mon, 15 Aug 2005 17:51:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mr9-0008Qv-Sk; Mon, 15 Aug 2005 17:50:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mr8-0008Qn-Lt for [e-mail]; Mon, 15 Aug 2005 17:50:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06485 for <[e-mail]>; Mon, 15 Aug 2005 17:50:52 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4nQK-0005Gd-UP for [e-mail]; Mon, 15 Aug 2005 18:27:18 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j7FLoi914905;  Mon, 15 Aug 2005 14:50:44 -0700 (PDT) (envelope-from [e-mail])
Received: from roque-lnx.juniper.net (roque-lnx.juniper.net [172.17.12.76]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7FLodG04468; Mon, 15 Aug 2005 14:50:39 -0700 (PDT) (envelope-from [e-mail])
Subject: Re: [Idr] BGP Monitoring Protocol
From: Pedro Roque Marques <[e-mail]>
To: Russ White <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Mon, 15 Aug 2005 14:50:38 -0700
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Cc: [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]

On Mon, 2005-08-15 at 17:32 -0400, Russ White wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Y'all:
> 
> http://www.ietf.org/internet-drafts/draft-scudder-bmp-00.txt
> 
> BGP Monitoring Protocol, latest draft, posted.
> 

Russ,
grow WG seems to be working on:
http://ietf.org/internet-drafts/draft-ietf-grow-mrt-00.txt

Any chance the 2 efforts can be coordinated / merged ?
It seems that the objectives are similar...

  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 RAA10168 for <[e-mail]>; Mon, 15 Aug 2005 17:32:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mZC-0005NZ-Sp; Mon, 15 Aug 2005 17:32:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mZA-0005Mv-Vs for [e-mail]; Mon, 15 Aug 2005 17:32:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05695 for <[e-mail]>; Mon, 15 Aug 2005 17:32:18 -0400 (EDT)
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4n8L-0004qf-1u for [e-mail]; Mon, 15 Aug 2005 18:08:44 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 15 Aug 2005 14:32:08 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.96,108,1122879600"; d="scan'208"; a="6037416:sNHT19021504"
Received: from russpc (rtp-vpn2-524.cisco.com [10.82.242.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7FLW5Qm022841 for <[e-mail]>; Mon, 15 Aug 2005 17:32:06 -0400 (EDT)
Received: from [10.82.242.12] by russpc (PGP Universal service); Mon, 15 Aug 2005 17:32:06 -0500
X-PGP-Universal: processed; by russpc on Mon, 15 Aug 2005 17:32:06 -0500
Message-ID: <[e-mail]>
Date: Mon, 15 Aug 2005 17:32:00 -0400
From: Russ White <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Type: text/plain; charset="ISO-8859-1"
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Subject: [Idr] BGP Monitoring Protocol
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]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Y'all:

http://www.ietf.org/internet-drafts/draft-scudder-bmp-00.txt

BGP Monitoring Protocol, latest draft, posted.

:-)

Russ


- -- 
[e-mail] CCIE <>< Grace Alone


-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.2 (Build 2424)

iQA/AwUBQwEJ1hEdu7FIVPTkEQJTpQCeOo4EWpkKsBcHf5EmkFJNVybZkRUAoPQ2
AbyJasKnUuVsGv3nWHWBaqbd
=IpH1
-----END PGP SIGNATURE-----

_______________________________________________
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 OAA28122 for <[e-mail]>; Mon, 15 Aug 2005 14:02:01 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4jFZ-0005R3-8S; Mon, 15 Aug 2005 13:59:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4jFY-0005Qy-1w for [e-mail]; Mon, 15 Aug 2005 13:59:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16978 for <[e-mail]>; Mon, 15 Aug 2005 13:59:51 -0400 (EDT)
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4joi-0005Vo-5z for [e-mail]; Mon, 15 Aug 2005 14:36:13 -0400
Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 15 Aug 2005 10:59:42 -0700
Received: from [128.107.134.9] (enke-linux.cisco.com [128.107.134.9]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7FHxcZ1029468; Mon, 15 Aug 2005 10:59:39 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 15 Aug 2005 10:59:38 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Yakov Rekhter <[e-mail]>
Subject: Re: [Idr] advertising more than one route to a destination
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit
Cc: [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]

Hi, Yakov:

Yakov Rekhter wrote:

>Folks,
>
>As you know the basic BGP spec currently restricts a BGP speaker
>to advertise at most a single route to a given destination (given
>address prefix).
>
>The purpose of this e-mail is to solicit opinions on (a) what
>applications could benefit if the above restriction is relaxed, as
>to allow a BGP speaker to advertise multiple routes to a given
>destination, and (b) whether the IDR WG should start work on extending
>BGP to support these applications.
>
>With this in mind, please answer the following two questions:
>
>1. What applications could benefit from allowing a BGP speaker
>to advertise multiple routes to a destination ?
>

Two important ibgp applications:

a) for eliminating persistent route oscillations by route reflection or 
confederation.
b) for eliminating forwarding loops with ibgp multipath and route 
reflection.

> 
>
>2. Should the IDR WG start work on extending BGP to support
>such applications ?
>  
>
Yes.

-- 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 MAA22945 for <[e-mail]>; Mon, 15 Aug 2005 12:32:52 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hrS-0007oi-Ug; Mon, 15 Aug 2005 12:30:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hrR-0007oa-3h for [e-mail]; Mon, 15 Aug 2005 12:30:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11996 for <[e-mail]>; Mon, 15 Aug 2005 12:30:50 -0400 (EDT)
Received: from gateout01.mbox.net ([165.212.64.21] helo=gwo1.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4iQb-00030R-Fl for [e-mail]; Mon, 15 Aug 2005 13:07:13 -0400
Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gwo1.mbox.net (Postfix) with SMTP id 9606712D655; Mon, 15 Aug 2005 16:30:38 +0000 (GMT)
Received: from gateout01.mbox.net [165.212.64.21] by gateout01.mbox.net via mtad (C8.MAIN.3.17K)  with ESMTP id 713JHoqEl0244Mo1; Mon, 15 Aug 2005 16:30:37 GMT
Received: from gw2.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.21U); Mon, 15 Aug 2005 16:30:37 GMT
X-USANET-Source: 165.212.116.254 IN   [e-mail] gw2.EXCHPROD.USA.NET
X-USANET-MsgId: XID949JHoqEl9731Xo1
Received: from localhost ([65.247.36.31]) by gw2.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211);  Mon, 15 Aug 2005 10:30:37 -0600
Date: Mon, 15 Aug 2005 12:30:36 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Subject: Re: WG Last Call on IANA Considerations (was Re: [Idr] IDR WG Minutes)
Message-ID: <[e-mail]>
References: <[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-OriginalArrivalTime: 15 Aug 2005 16:30:37.0292 (UTC) FILETIME=[AAE102C0:01C5A1B6]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
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]

Yakov,

On Mon, Aug 15, 2005 at 09:06:08AM -0700, Yakov Rekhter wrote:
> What is the rationale for having one range for the IETF Consensus
> policy and another range for the FCFS policy ?  In other words, why
> not have just a single block from which IANA could allocate
> either based on the IETF Consensus or on the FCFS policy ?

Just for list reference, we haven't really changed the classes of
allocations we'd be allowing.  We're tweaking the ranges.

As to why we'd want those particular classes, here's my opinion:

We want a range that says, "Here's what IETF wants".  It implies 
organizational "support" for a given mechanism.  This is the IETF
Consensus range.

We want a range that says, "If you want to do something that uses
this mechanism but don't want to get full 'IETF buy-in'", there's
another range.  This is the FCFS range.

We want a range for private experimentation.  This range has a strong
implication that "do what you want here, it probably wont work with
someone else".  This is the private range.  

I think your question is why have blocks at all?  IMO, we want to 
set aside space so that IETF has room to grow in the (unlikely) case
that FCFS gets exhausted too quickly.  It's a shared playground and
there's a limited number of marbles to give away.

> Yakov.

-- 
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 MAA22664 for <[e-mail]>; Mon, 15 Aug 2005 12:28:06 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hmq-00074V-FU; Mon, 15 Aug 2005 12:26:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hmo-00074N-GM for [e-mail]; Mon, 15 Aug 2005 12:26:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11724 for <[e-mail]>; Mon, 15 Aug 2005 12:26:03 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4iLx-0002rc-UX for [e-mail]; Mon, 15 Aug 2005 13:02:26 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j7FGPtBm034828 for <[e-mail]>; Mon, 15 Aug 2005 09:25:55 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7FGPtG20452 for <[e-mail]>; Mon, 15 Aug 2005 09:25:55 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 15 Aug 2005 09:25:55 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 75ac735ede4d089f7192d230671d536e
Subject: [Idr] minutes
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Folks,

The revised minutes have been posted (see below). 

Yakov.
------- Forwarded Message

Date:    Mon, 15 Aug 2005 12:21:20 -0400
From:    Rebecca Bunch <[e-mail]>
To:      Yakov Rekhter <[e-mail]>
Subject: Re: IETF-63 Proceedings Submission

Your proceeding submissions have been posted, please review them on line 
and send any corrections to [e-mail]. The deadline for 
submitting corrections is Monday, September 19, 2005 at 17:00 ET.

https://datatracker.ietf.org/public/proceeding_interim.cgi?meeting_num=63


Yakov Rekhter wrote:

>Hi,
>
>Attached are the IDR WG minutes.
>
>Yakov.
>---------------------------------------------------------------------
>
>IDR WG Minutes 2005.08.04 
>-------------------------
>
>Doc status
>see ppt for info
>
>Danny McPherson to finish Confed implementation report in one month.
>
>Geoff Houston to complete the implementation report for 4-octet AS 
>number space.
>
>New MIB editor see draft
>
>-------------------------
>Tony Li AS Hop count Attribute
>
>see ppt for info
>Essence: Add TTL to each prefix, decrement at AS boundary
>Drop route when TTL hits zero
>Transitive attribute
>
>Alt: Distribution Lists
>List contains ASs that can rx and cannot exclusion
>
>NOTE: NO_EXPORT and AS_HOPCOUNT can be combined
>
>Geoff Houston: is NO_EXPORT dropped or continued when combined?
>
>NOTE:  Can scope 'anycast'
>
>Geoff Houston: when aspath prepending, is that expressed in the HOP_COUNT?
>Tony Li: Decremented by one always
>
>Sue Hares: Two more ASPATHS per route? How does scaling work?
>Tony Li: In the worst case, when setting up a list you can have an 
>arbitrary  number in incl or excl list?
>
>Sue Hares: Is order semantics true but,
>
>Yakov Rekhter: An ASPATH cannot carry all AS in the internet as it
>would exceed the maximum size of the BGP Update message.
>
>Tony Li: An avg ASPATH has ~4 AS' in it so, we are going to have on avg 
>roughly two X
>
>Sue Hares: Why do you say proxy usage is diffficult in Dist List case? 
>TTL is lighter but, why choose between two? Might have both.
>
>Tony Li: From an implementors POV, it is easier to do one and not two
>
>Yakov Rekhter: The increase in number of AS' per route is not a practical 
>issue
>
>Geoff Houston: At the edge, it may work but, topology is dense and we nee
>
>Jason Schiller (UUNET): Scope - useful in subconfeds ... need  a 
>separate counter?
>
>Tony Li: Want to see draft first. Technically what is required is a 
>separate attribute but, look almost identical
>
>Geoff Houston: When comparing the two mechanisms need to look at "what is 
>going on." Distribution lists require complete knowledge of topology. 
>Problem is that you cannot insure that they do not leak. HOPCOUNT 
>does not have 'knowledge' problem but, focuses on accuracy.
>
>Sue Hares: Inclusion requires enumeration but exclusion does not
>
>Geoff Houston: HOPCOUNT allows more specifics w/ a boundary. 
>Advocates HOPCOUNT
>
>Pedro Roque: No productive compare the two. Want to select upstream 
>provider w/ targeted ext comms. HOPCOUNT might prevent this 
>technique. Most common TE technique; customers preferring transit AS' 
>per prefix. Not applicable for transit exit scenario. Two issues and 
>solutions are orthogonal but, neither solution is devalued.
>
>Chris Morrow (UUNET): proxy means "I can add" and/or "I can delete"
>
>Tony Li: Yes and not violate
>
>Chris Morrow: Will it get used if provider ignores or removes
>
>Yakov Rekhter: Who is entity that benefits from this? Which SP.
>
>Tony Li: Table size reduction is goal. One SP adds does the work but, gets 
>no benefits. Altruism or hope of it is a good reason.
>
>Geoff Houston: Zhang drafts in GROW show that altruism is bunk instead 
>self-interest. Most UPDATEs come from lower tier points. Most 
>computation happens at lower level of peering .. therefore, small 
>folks get most thrash. If "I" do this, I help my problem ... 
>therefore altruism is there for the folks that use it and tag it.
>
>David Ward: Affect Hop count?
>
>Tony Li: Not significantly as it would be longer prefixes.
>
>Enke Chen: Can we inject an AS numer as 'signature' of who adds attribute?
>
>May be added to draft. No comments
>
>-------------------------
>Zhang Renhai Entire Route Reflect
>
>Comments held until after Walton's draft
>see ppt for info
>
>-------------------------
>Walton Add Paths
>Alvaro Retana (Cisco) presenter.
>see ppt for info
>
>NOTE: RFC 3107 must be updated
>
>-------------------------
>Walton Oscillation Stop
>Alvaro Retana (Cisco) presenter
>info in same ppt as "Add Paths"
>
>George Swallow: What is frequency of oscillation?
>
>Alvaro Retana: dependent on update timer setting (MIN ADVERT INTERVAL)
>
>Combined questions for both draft authors:
>Danny (unaffiliated) - We are increasing and decreasing table size. 
>Walton's draft is more general and flexible then Zhang's.
>
>Alvaro Retana: Most of increase of table size is internal to an AS (almost all
)
>
>Zhang: I don't understand question.
>
>Zhang: Walton's draft is more general. 
>
>Alvaro Retana: NLRI will be bigger but, no impact on packing.
>
>Gargi (Cisco): Zhang's draft - must specify that you explicitly WD 
>when a nexthop changes or how to announce new NH?  How do you delete 
>the first NH?
>
>Zhang: If NH changes, just add it. To solve the problem there will 
>taken offline to email.
>
>Paul Jakma: If in ECMP case, what AS sequence? How to pass multiple 
>paths to a legacy speaker?
>
>Alvaro Retana:  Cap advert defines who can learn add_path. Other 
>applications like EBGP ECMP and propagating multiple paths will have 
>to be addressed.
>
>Alvaro Retana: Constrained scope.
>
>Pedro Roque: Although you say impact of deployment is localized.
>We need a better understanding of what impact will be. For each
>route prefix, path attrs in Adj RIB Out. Generally announcement,
>is only  when Adj-RIB-Out changes. What is expectation of propagating
>changes when inbound updates would cause outbound content. What are
>consequences?  Size of Adj-RIB-Out? What is key of Adj-RIB-Out?  etc.
>
>Alvaro Retana: Spec says send on path. Change is that we would have
>tracking of two or more paths.
>
>Yakov Rekhter: We can have as many ad hoc solutions as we want or
>a more general solution. We, as a group, should decide on a more
>general solution. We should look at potential new functionality
>once we have more than one path being advertised.
>
>Suggestion is that the authors of three proposals should find common
>solution to all problems that WG would like to address. A mailing
>list will be set up to discuss this problem and solution. On the
>IDR mailing list please identify problems.
>
>Yakov Rekhter: Do we need requirements document?
>
>Ward: No, absolutely not.
>
>-------------------------
>Dubois PM Reqmts
>
>see ppt for info
>
>Yakov Rekhter: Send note to list on whether or not we should take as a WG doc.
>
>Dubois: Earlier solution was not meeting requirements and there are 
>many possible solutions. We need a solution that fits the 
>requirements; we are not encouraging one solution over another:
>
>Ted Seely (Sprint): Why not weight traffic away from peer or 
>interface? There are other techniques that don't require change to 
>protocol.
>
>Ruediger Volk: I lose traffic when I do this technique.
>
>Ruediger Volk: The convergence problem I see is due to the previous issue 
>of config change.
>
>Jason Schiller (UUNET): Is there a hard requirement that this does 
>not require a config change ... taken to the list.
>
>-------------------------
>Hares Dynamic Confed AS
>
>Not requested to be WG item.
>see ppt for info
>
>Roque: I would assume that you would want to do restoration in a 
>seamless way. What is motivation to make failure restoration a 
>visible outside the confederation?
>
>Sue Hares: Goal is to not drop the peering session. Therefore, the purpose 
>is policy rerouting wants to 'hang by itself.' If I drop out of the 
>AS confed, I would have had to drop the session.
>
>Roque: Why not just tunnel back?
>
>Sue Hares: No IGP connectivity and tunnels ran into problems.
>Sue Hares: will send scenarios to list
>
>Chandra Appanna (Cisco): I think you need a few more failsafes. 
>Resend is a MUST, and some mechanisms is nec. that moved did not 
>suddenly change. Need to resend routes due to policy change potential.
>
>Sue Hares: We have added failsafe. We delayed resend, it would be abnormal 
>to send all routes if nothing changed. Will send scenario in email.
>
>Gargi (Cisco): Are there any mechanisms in mind for NO resend if ones 
>moves from one confed to another?
>
>-------------------------
>Multisession update - Chandra Appanna
>
>See ppt for info
>
>Added flexibility for any capability code to cause/create multiple sessions
>
>No comments
>
>-------------------------
>Kapoor SSA - Gargi, Scott Wainner
>
>see ppt for info
>
>-------------------------
>Kapoor Tunnel SAFI
>
>combined w/ SSA preso, same ppt
>
>Gargi did technical side and changes to docs:
>
>more TLVs to express encap:
>
>MPLS, IPsec, GRE in IPsec, L2TPv3 in IPsec
>
>added application scenarios: MPLS over IP tunnels
>
>Scott presented motivations
>
>Combined comments:
>
>Sue Hares: Can you explain status of this mechanism w/in each of these 
>groups (on referenced drafts)? What is approved, required, etc. We 
>need to see something from those chairs that the ref'ed drafts are 
>"blessed."
>
>Scott Wainner:  Walked through
>
>Gargi: We have chicken and egg to get this done. Encoding first or 
>formats first?
>
>Intro work on L3VPN list.
>
>Yakov Rekhter: Very reasonable model where must have both WGs review 
>dependent docs.
>
>Bill Fenner:  Must work w/ other WG for encoding.
>
>Yakov Rekhter: Two possible models - first: semantics or encoding need to 
>be done in L3VPN; second: L2/L3VPN WGs tell us semantics and IDR produces 
>encoding.
>
>Rahul Aggarwal: there were two problems in the past: 1) Motivation wasn't
>clear 2) Authors of draft-raggarwa-ppvpn-tunnel-encap and authors
>of the drafts presented at this IDR meeting were unable to come up
>with a joint proposal. Suggested that since motivations are clearer
>now, this work should be discussed again in the L3VPN WG.
>
>Pedro Roque: Disagree w/ motivations. IGP can provide reachability. I think 
>you use BGP as signaling protocol which is not a problem. But, 
>presentation states that BGP needs to know this information. Please 
>clarify the layering split.
>
>Yakov Rekhter: Can this move to L3VPN
>
>SOLUTION: Joint Last Call in IDR and L3VPN.
>
>-------------------------
>SAFI Space Partition
>In reply to Jeff Hass email on list.
>
>Bill Fenner to send notes on how to alloc SAFI space.
>
>Proposal: take private use space and turn it into reserved and 
>perhaps 16 or so as private use. Reserved is reserved so we can 
>decide later on FCFS or otherwise managed.
>
>Are folks using private space? Do we need to skip some?
>
>Yakov Rekhter: How long will it take to use up first come first served?
>
>Bill Fenner: We should be able to straighten this out quickly and IANA is 
>keeping up. 30 days deadline.
>
>Danny McPherson: Needs to be uniform across all WGs and Areas. Make 
>it IETF aligned.
>
>Pedro Roque: I do not want to see vendor specific space go away altogether. 
>There is much more usage than one case alluded to. Today is only 
>practical alternative, cannot be locked out. Can it be shown to work 
>before we assume 30 days?
>
>Bill Fenner: There are publications on these agreements and promises that 
>it will be done in 30 days. FCFS is you get it now .... no draft, no 
>wait.
>
>Chandra: Cannot get rid of vendor space.  AF/SAFI has lost meaning and 
>is a way to differentiate addrs between two peers. Just need opaque 
>space that we can use between two peers.
>
>Gargi: Must have vendor space perhaps reduced is ok. Second, IANA is 
>faster but, it seems to required Routing ADs having lunch w/ IANA.
>
>Yakov Rekhter: IANA must have strict 30 days max as rule.
>
>Bill Fenner: We are working on this and the stats show that 30 days 
>is being met.
>
>  
>

------- End of Forwarded Message


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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA22081 for <[e-mail]>; Mon, 15 Aug 2005 12:18:18 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hep-0005Zu-OB; Mon, 15 Aug 2005 12:17:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hen-0005Zj-Mx for [e-mail]; Mon, 15 Aug 2005 12:17:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11287 for <[e-mail]>; Mon, 15 Aug 2005 12:17:47 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19lr6dE0jTVKImijMtLMNQOZPC5LTiuE10=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4iDw-0002cW-N6 for [e-mail]; Mon, 15 Aug 2005 12:54:10 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7FGH9IH015908; Mon, 15 Aug 2005 17:17:12 +0100
Date: Mon, 15 Aug 2005 17:17:09 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Yakov Rekhter <[e-mail]>
Subject: Re: [Idr] advertising more than one route to a destination
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mail-Copies-To: [e-mail]
Mail-Followup-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: [e-mail], Inter-Domain Routing List <[e-mail]>, "Nipper, Arnold" <[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, 15 Aug 2005, Yakov Rekhter wrote:

> Folks,
>
> As you know the basic BGP spec currently restricts a BGP speaker
> to advertise at most a single route to a given destination (given
> address prefix).
>
> The purpose of this e-mail is to solicit opinions on (a) what 
> applications could benefit if the above restriction is relaxed, as 
> to allow a BGP speaker to advertise multiple routes to a given 
> destination, and (b) whether the IDR WG should start work on 
> extending BGP to support these applications.

a) eBGP Route-servers at IXes, to act as 'dumb'
   (non-best-path-selecting) reflectors so as to reduce eBGP 'mesh'
   between IX users.

   iBGP reflectors, to reduce route-oscillations (see Walton, et al).

b) Yes.

    Note: there's at least one private draft examining this.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Consultant, n.:
 	An ordinary man a long way from home.

_______________________________________________
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 MAA21734 for <[e-mail]>; Mon, 15 Aug 2005 12:12:06 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hXA-00034k-Fh; Mon, 15 Aug 2005 12:09:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hX9-00034f-PM for [e-mail]; Mon, 15 Aug 2005 12:09:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10566 for <[e-mail]>; Mon, 15 Aug 2005 12:09:53 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4i6I-0002Hn-Tp for [e-mail]; Mon, 15 Aug 2005 12:46:16 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j7FG9iBm034145; Mon, 15 Aug 2005 09:09:44 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7FG9iG16181; Mon, 15 Aug 2005 09:09:44 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 15 Aug 2005 09:09:44 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: [e-mail]
Subject: [Idr] advertising more than one route to a destination
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Folks,

As you know the basic BGP spec currently restricts a BGP speaker
to advertise at most a single route to a given destination (given
address prefix).

The purpose of this e-mail is to solicit opinions on (a) what
applications could benefit if the above restriction is relaxed, as
to allow a BGP speaker to advertise multiple routes to a given
destination, and (b) whether the IDR WG should start work on extending
BGP to support these applications.

With this in mind, please answer the following two questions:

1. What applications could benefit from allowing a BGP speaker
to advertise multiple routes to a destination ? 

2. Should the IDR WG start work on extending BGP to support
such applications ?

The deadline for response is August 29.

Yakov.

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA21491 for <[e-mail]>; Mon, 15 Aug 2005 12:08:06 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hTl-0002oJ-Uv; Mon, 15 Aug 2005 12:06:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hTk-0002md-ES for [e-mail]; Mon, 15 Aug 2005 12:06:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10465 for <[e-mail]>; Mon, 15 Aug 2005 12:06:22 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4i2u-0002DQ-DN for [e-mail]; Mon, 15 Aug 2005 12:42:44 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j7FG6E905123;  Mon, 15 Aug 2005 09:06:14 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j7FG68G15296; Mon, 15 Aug 2005 09:06:09 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Subject: Re: WG Last Call on IANA Considerations (was Re: [Idr] IDR WG Minutes) 
In-Reply-To: Your message of "Mon, 15 Aug 2005 11:37:44 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 15 Aug 2005 09:06:08 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
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,

[speaking as a WG member...]

> Yakov had requested that I forward my proposed wording changes to
> the list.  Here they are:
> 
> : > Are you ok with the proposed text I sent to the list yesterday ?
> : > If not, could you propose and post an alternative text.
> : 
> : Presuming you're talking about the last call, here's how I'd change it:
> : 
> :   - Keep 1-63 as "IETF Consensus/Early Allocation"
> :   - Reclassify 64-223 as "FCFS"
> :     Make special that 128 will remain allocated
> :   - Reclassify 224-239 as "Reserved".
> :   - Retain 240-254 as "private use".
> :   - Reclassify 255 as "Reserved"
> :   - As needed, register values in the Reserved or FCFS range if
> :     previously-deployed protocols come into or are already in
> :     progress within the IETF.
> :   - Recommend that new developments use FCFS or RFC4020 method to get
> :     code points
> :   - In the future, if we run out of FCFS or IETF Consensus numbers,
> :     start using the "Reserved" space as needed.
> : 
> : The modified IANA Consideration section will look as follows:
> : 
> :    As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI
> :    attributes contain the Subsequence Address Family Identifier (SAFI)
> :    field. The SAFI name space is defined in this document. The IANA will
> :    maintain and register values for the SAFI namespace as follows. 
> :    
> :    SAFI values 1 and 2 are assigned in this document.  SAFI values
> :    4 through 63, 65, and 128 are to be assigned by IANA using either
> :    the "IETF Consensus" policy defined in RFC2434 or the "Early
> :    IANA Allocation" policy defined in RFC4020. SAFI values 64 and
> :    66 through 239 are to be assigned by IANA, using the "First  Come
> :    First Served" policy defined in RFC2434. SAFI values 240 through
> :    254 are for "private use", and are not to be assigned by IANA.
> :    SAFI values 0, 3, and 129 through 239 and 255 are reserved.

What is the rationale for having one range for the IETF Consensus
policy and another range for the FCFS policy ?  In other words, why
not have just a single block from which IANA could allocate
either based on the IETF Consensus or on the FCFS policy ?

Yakov.

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA20018 for <[e-mail]>; Mon, 15 Aug 2005 11:43:01 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4h2V-0007dO-59; Mon, 15 Aug 2005 11:38:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4h2T-0007cr-K0 for [e-mail]; Mon, 15 Aug 2005 11:38:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09041 for <[e-mail]>; Mon, 15 Aug 2005 11:38:11 -0400 (EDT)
Received: from gateout02.mbox.net ([165.212.64.22] helo=gwo2.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4hbZ-0001XI-Az for [e-mail]; Mon, 15 Aug 2005 12:14:33 -0400
Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gwo2.mbox.net (Postfix) with SMTP id A6686163CA5 for <[e-mail]>; Mon, 15 Aug 2005 15:37:46 +0000 (GMT)
Received: from gateout02.mbox.net [165.212.64.22] by gateout02.mbox.net via mtad (C8.MAIN.3.17K)  with ESMTP id 997JHoPlt0270Mo2; Mon, 15 Aug 2005 15:37:45 GMT
Received: from gw3.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.21U); Mon, 15 Aug 2005 15:37:45 GMT
X-USANET-Source: 165.212.116.254 IN   [e-mail] gw3.EXCHPROD.USA.NET
X-USANET-MsgId: XID820JHoPlt3300Xo2
Received: from localhost ([65.247.36.31]) by gw3.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211);  Mon, 15 Aug 2005 09:37:44 -0600
Date: Mon, 15 Aug 2005 11:37:44 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Re: WG Last Call on IANA Considerations (was Re: [Idr] IDR WG Minutes)
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
X-OriginalArrivalTime: 15 Aug 2005 15:37:45.0065 (UTC) FILETIME=[48159590:01C5A1AF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Yakov had requested that I forward my proposed wording changes to
the list.  Here they are:

: > Are you ok with the proposed text I sent to the list yesterday ?
: > If not, could you propose and post an alternative text.
: 
: Presuming you're talking about the last call, here's how I'd change it:
: 
:   - Keep 1-63 as "IETF Consensus/Early Allocation"
:   - Reclassify 64-223 as "FCFS"
:     Make special that 128 will remain allocated
:   - Reclassify 224-239 as "Reserved".
:   - Retain 240-254 as "private use".
:   - Reclassify 255 as "Reserved"
:   - As needed, register values in the Reserved or FCFS range if
:     previously-deployed protocols come into or are already in
:     progress within the IETF.
:   - Recommend that new developments use FCFS or RFC4020 method to get
:     code points
:   - In the future, if we run out of FCFS or IETF Consensus numbers,
:     start using the "Reserved" space as needed.
: 
: The modified IANA Consideration section will look as follows:
: 
:    As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI
:    attributes contain the Subsequence Address Family Identifier (SAFI)
:    field. The SAFI name space is defined in this document. The IANA will
:    maintain and register values for the SAFI namespace as follows. 
:    
:    SAFI values 1 and 2 are assigned in this document.  SAFI values
:    4 through 63, 65, and 128 are to be assigned by IANA using either
:    the "IETF Consensus" policy defined in RFC2434 or the "Early
:    IANA Allocation" policy defined in RFC4020. SAFI values 64 and
:    66 through 239 are to be assigned by IANA, using the "First  Come
:    First Served" policy defined in RFC2434. SAFI values 240 through
:    254 are for "private use", and are not to be assigned by IANA.
:    SAFI values 0, 3, and 129 through 239 and 255 are reserved.

-- 
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 KAA14946 for <[e-mail]>; Mon, 15 Aug 2005 10:13:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4ffW-0005Yl-LJ; Mon, 15 Aug 2005 10:10:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4ffU-0005YN-Rr for [e-mail]; Mon, 15 Aug 2005 10:10:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04667 for <[e-mail]>; Mon, 15 Aug 2005 10:10:23 -0400 (EDT)
Received: from gateout02.mbox.net ([165.212.64.22] helo=gwo2.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4gEc-000858-FJ for [e-mail]; Mon, 15 Aug 2005 10:46:44 -0400
Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gwo2.mbox.net (Postfix) with SMTP id 51993163CB1; Mon, 15 Aug 2005 14:09:58 +0000 (GMT)
Received: from gateout02.mbox.net [165.212.64.22] by gateout02.mbox.net via mtad (C8.MAIN.3.17K)  with ESMTP id 045JHooJ50311Mo2; Mon, 15 Aug 2005 14:09:56 GMT
Received: from gw2.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.21U); Mon, 15 Aug 2005 14:09:56 GMT
X-USANET-Source: 165.212.116.254 IN   [e-mail] gw2.EXCHPROD.USA.NET
X-USANET-MsgId: XID640JHooJ53644Xo2
Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by gw2.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.211);  Mon, 15 Aug 2005 08:09:56 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Idr] IDR WG Minutes
Date: Mon, 15 Aug 2005 08:09:53 -0600
Message-ID: <[e-mail]>
Thread-Topic: [Idr] IDR WG Minutes
Thread-Index: AcWfbJVl7G7V0adRTt6lMjsHjgaZ6AB4FC9Q
From: "Susan Hares" <[e-mail]>
To: "Rahul Aggarwal" <[e-mail]>, "Yakov Rekhter" <[e-mail]>
X-OriginalArrivalTime: 15 Aug 2005 14:09:56.0394 (UTC) FILETIME=[03B630A0:01C5A1A3]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8a961490db2a74c7613bf0201229f176
Cc: [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 KAA14946

Rahul:

I've included this change in the updated minutes.  Please confirm
I've got it correctly.

Sue

==================================


IDR WG notes 2005.08.04 -(Dave Ward) 
-------------------------
Agenda:

Agenda: 
1. IDR Documents status update 5 mins 
2. Tony Li
	draft-li-as-hopcount-01.txt  30 mins 
3. Zhang Renhai 
	draft-zhang-idr-bgp-entire-routes-reflect-01.txt 15 mins 
4. 
    draft-walton-bgp-add-paths-03.txt 
    draft-walton-bgp-route-oscillation-stop-01.txt 
    20 mins 
5. Nicolas Dubois
    draft-dubois-bgp-pm-reqs-01.txt 15 mins 
6. Sue Hares 
   draft-hares-bose-dynamic_as-01.txt 10 mins
  
7. Chandra Appanna 
    draft-ietf-idr-bgp-multisession-01.txt 10 mins 

8. Gargi 
    draft-kapoor-nalawade-idr-bgp-ssa-02.txt
draft-nalawade-kapoor-tunnel-safi-03.txt. 15 mins 


==================================================

Doc status

Danny McPherson to finish Confed implementation report in one month
Geoff Houston to complete 4-octet AS number
New MIB editor see draft

see ppt



-------------------------
Li AS Hop count Attribute

see ppt for info
Essence: Add TTL to each prefix, decrement at AS boundary Drop route
when TTL hits zero Transitive attribute

Alt: Distribution Lists
List contains ASs that can rx and cannot exclusion

NOTE: NO_EXPORT and AS_HOPCOUNT can be combined

Houston: is NO_EXPORT dropped or continued when combined?

NOTE:  Can scope 'anycast'

Houston: when aspath prepending, is that expressed in the HOP_COUNT?
Li: Decremented by one always

Hares: Two more ASPATHS per route? How does scaling work?
Li: In the worst case, when setting up a list you can have an arbitrary
number in incl or excl list?

Hares: Is order semantics true but,

Rekhter: An ASPATH cannot carry all AS in the internet as not enough
space

Li: An avg ASPATH has ~4 AS' in it so, we are going to have on avg
roughly two X

Hares: Why do you say proxy usage is diffficult in Dist List case? 
TTL is lighter but, why choose between two? Might have both.

Li: From an implementors POV, it is easier to do one and not two

Rekhter: The increase in number of AS' per route is not a practical
issue

Houston: At the edge, it may work but, topology is dense and we nee

Jason Schiller (UUNET): Scope - useful in subconfeds ... need  a
separate counter?

Li: Want to see draft first. Technically what is required is a separate
attribute but, look almost identical

Houston: When comparing the two mechanisms need to look at "what is
going on." Distribution lists require complete knowledge of topology. 
Problem is that you cannot insure that they do not leak. HOPCOUNT does
not have 'knowledge' problem but, focuses on accuracy.

Hares: Inclusion requires enumeration but exclusion does not.

Houston: HOPCOUNT allows more specifics w/ a boundary. Advocates
HOPCOUNT

Roque: No productive compare the two. Want to select upstream provider
w/ targeted ext comms. HOPCOUNT might prevent this technique. Most
common TE technique; customers preferring transit AS' 
per prefix. Not applicable for transit exit scenario. Two issues and
solutions are orthogonal but, neither solution is devalued.

Chris Morrow (UUNET): proxy means "I can add" and/or "I can delete"

Li: Yes and not violate

Chris; Will it get used if provider ignores or removes

Rekhter: Who is entity that benefits from this? Which SP.

Li: Table size reduction is goal. One SP adds does the work but, gets no
benefits. Altruism or hope of it is a good reason.

Houston: Zhang drafts in GROW show that altruism is bunk instead
self-interest. Most UPDATEs come from lower tier points. Most
computation happens at lower level of peering .. therefore, small folks
get most thrash. If "I" do this, I help my problem ... 
therefore altruism is there for the folks that use it and tag it.

David Ward: Affect Hop count?

Li: Not significantly as it would be longer prefixes.

Enke: Can we inject an AS numer as 'signature' of who adds attribute?

May be added to draft. No comments

-------------------------
Zhang Renhai Entire Route Reflect

Comments held until after Walton's draft see ppt for info

-------------------------
Walton Add Paths
Alvaro Retana (Cisco) presenter.
see ppt for info

NOTE: RFC 3107 must be updated

-------------------------
Walton Oscillation Stop
Alvaro Retana (Cisco) presenter
info in same ppt as "Add Paths"

Swallow: What is frequency of oscillation?

Retana: dependent on update timer setting (MIN ADVERT INTERVAL)

Combined questions for both draft authors:
Danny (unaffiliated) - We are increasing and decreasing table size. 
Walton's draft is more general and flexible then Zhang's.

Retana: Most of increase of table size is internal to an AS (almost all)

zhang: I don't understand question.

Zhang: Walton's draft is more general. Because you add attribute, do you
think that efficiency of packing will be affected?

Retana: NLRI will be bigger but, no impact on packing.

Gargi (Cisco): Zhang's draft - must specify that you explicitly WD when
a nexthop changes or how to announce new NH?  How do you delete the
first NH?

Zhang: If NH changes, just add it. To solve the problem there will taken
offline to email.

Paul ??: If in ECMP case, what AS sequence? How to pass multiple paths
to a legacy speaker?

Retana:  Cap advert defines who can learn add_path. Other applications
like EBGP ECMP and propagating multiple paths will have to be addressed.

Retana: Constrained scope.

Roque: Although you say impact of deployment is localized. We need a
better understanding of what impact will be. For each route prefix, path
attrs in Adj RIB Out. Generally announcement, is only  when Adj-RIB-Out
changes. What is expectation of propagating changes when inbound updates
would cause outbound content. What are consequences? 
Size of Adj-RIB-Out? What is key of Adj-RIB-Out? etc.

Retana: Spec says send on path. Change is that we would have tracking of
two or more paths.

Rekhter: We can have as many ad hoc solutions as we want or a more
general solution. We as a group should decide on a more general
solution. We should look at potential new functionality once we have
more than one path being advertised.
Suggestion is that the authors of three proposals should find common
solution to all problems that WG would like to address. A mailing list
will be set up to discuss this problem and solution. On the IDR mailing
list please identify problems.

[3 proposals are:

draft-bhatia-ecmp-routes-in-bgp-01.txt
draft-zhang-idr-bgp-entire-routes-reflect-00.txt
draft-walton-bgp-add-paths-03.txt]


Rekhter: Do we need requirements document?

Ward: No, absolutely not.

-------------------------
Dubois PM Reqmts

see ppt for info

Rekhter: Send note to list on whether or not we should take as a WG doc.

Dubois: Earlier solution was not meeting requirements and there are many
possible solutions. We need a solution that fits the requirements; we
are not encouraging one solution over another:

Ted Seely (Sprint): Why not weight traffic away from peer or interface?
There are other techniques that don't require change to protocol.

Ruediger Volk: I lose traffic when I do this technique.

Ruediger: The convergence problem I see is due to the previous issue of
config change.

Jason Schiller (UUNET): Is there a hard requirement that this does not
require a config change ... taken to the list.

-------------------------
Hares Dynamic Confed AS

Not requested to be WG item.
see ppt for info

Roque: I would assume that you would want to do restoration in a
seamless way. What is motivation to make failure restoration a visible
outside the confederation?

SKH: Goal is to not drop the peering session. Therefore, the purpose is
policy rerouting wants to 'hang by itself.' If I drop out of the AS
confed, I would have had to drop the session.

Roque: Why not just tunnel back?

SKH: No IGP connectivity and tunnels ran into problems.
SKH: will send scenarios to list

Chandra Appanna (Cisco): I think you need a few more failsafes. 
Resend is a MUST, and some mechanisms is nec. that moved did not
suddenly change. Need to resend routes due to policy change potential.

SKH: We have added failsafe. We delayed resend, it would be abnormal to
send all routes if nothing changed. Will send scenario in email.

Gargi (Cisco): Are there any mechanisms in mind for NO resend if ones
moves from one confed to another?

-------------------------
Multisession update - Chandra Appanna

See ppt for info

Added flexibility for any capability code to cause/create multiple
sessions

No comments

-------------------------
Kapoor SSA - Gargi, Scott Wainner

see ppt for info

-------------------------
Kapoor Tunnel SAFI

combined w/ SSA preso, same ppt

Gargi did technical side and changes to docs:

more TLVs to express encap:

MPLS, IPsec, GRE in IPsec, L2TPv3 in IPsec

added application scenarios: MPLS over IP tunnels

Scott presented motivations

Combined comments:

SKH: Can you explain status of this mechanism w/in each of these groups
(on referenced drafts)? What is approved, required, etc. We need to see
something from those chairs that the ref'ed drafts are "blessed."

Scott:  Walked through

Gargi: We have chicken and egg to get this done. Encoding first or
formats first?

Intro work on L3VPN list.

Rekhter: Very reasonable model where must have both WGs review dependent
docs.

Bill Fenner:  Must work w/ other WG for encoding.

Rekhter: Two possible models - first: semantics or encoding need to be
done in L3VPN
    second: L2/L3VPN WGs tell us semantics and IDR produces codepoints

Rahul: There were two problems in the past: 1) Motivation wasn't clear
2) Authors of draft-raggarwa-ppvpn-tunnel-encap and authors of the
drafts presented at this IDR meeting were unable to come up with a joint
proposal. I suggested that since motivations are clearer now, this work
should be discussed again in the L3VPN WG.

Roque: Disagree w/ motivations. IGP can provide reachability. I think
you use BGP as signaling protocol which is not a problem. But,
presentation states that BGP needs to know this information. Please
clarify the layering split.

Rekhter: Can this move to L3VPN

SOLUTION: Joint Last Call in IDR and L3VPN.


-------------------------
SAFI Space Partition
In reply to Jeff Hass email on list.

Fenner to send notes on how to alloc SAFI space.

Proposal: take private use space and turn it into reserved and perhaps
16 or so as private use. Reserved is reserved so we can decide later on
FCFS or otherwise managed.

Are folks using private space? Do we need to skip some?

Rekhter: How long will it take to use up first come first served?

Fenner: We should be able to straighten this out quickly and IANA is
keeping up. 30 days deadline.

Danny McPherson: Needs to be uniform across all WGs and Areas. Make it
IETF aligned.

Roque: I do not want to see vendor specific space go away altogether. 
There is much more usage than one case alluded to. Today is only
practical alternative, cannot be locked out. Can it be shown to work
before we assume 30 days?

Fenner: There are publications on these agreements and promises that it
will be done in 30 days. FCFS is you get it now .... no draft, no wait.

Chandra; Cannot get rid of vendor space.  AF/SAFI has lost meaning and
is a way to differentiate addrs between two peers. Just need opaque
space that we can use between two peers.

Gargi: Must have vendor space perhaps reduced is ok. Second, IANA is
faster but, it seems to required Routing ADs having lunch w/ IANA.

Rekhter: IANA must have strict 30 days max as rule.

Fenner: We are working on this and the stats show that 30 days is being
met.


_______________________________________________
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 UAA15902 for <[e-mail]>; Sun, 14 Aug 2005 20:21:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4SiA-0003rT-Q0; Sun, 14 Aug 2005 20:20:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4Si8-0003rL-PI for [e-mail]; Sun, 14 Aug 2005 20:20:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20341 for <[e-mail]>; Sun, 14 Aug 2005 20:20:14 -0400 (EDT)
Received: from relay00.pair.com ([209.68.1.20] helo=relay.pair.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E4TH9-00008q-Iq for [e-mail]; Sun, 14 Aug 2005 20:56:28 -0400
Received: (qmail 16504 invoked from network); 15 Aug 2005 00:20:04 -0000
Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 15 Aug 2005 00:20:04 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j7F0K0Sf069509; Sun, 14 Aug 2005 20:20:01 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "DECRAENE Bruno RD-CORE-ISS" <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc 
In-reply-to: Your message of "Mon, 08 Aug 2005 16:41:56 +0200." <[e-mail]>
Date: Sun, 14 Aug 2005 20:20:00 -0400
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: [e-mail], FONDEVIOLE Benoit RD-CORE-ISS <[e-mail]>, DUBOIS Nicolas ROSI-DAS-ARI <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
"DECRAENE Bruno RD-CORE-ISS" writes:
>  
> We raise the issue, which is a first step.


OK.  You've successfully raised the issue.  Thanks for doing so.
There may not be a need for a separate RFC to raise the issue if the
issue can be clearly and very concisely stated and if there is a very
simple solution.  So lets consider solving it for a moment.

If you are trying to remove routes from your own IGP costing out is
the best solution.  In ISIS you use the OVERLOAD bit.  In OSPF you can
cost out all links.

For the case where you are removing EBGP learned routes from your own
IBGP you can cost out your advertisements with a high LOCAL_PREF.
Costing out with LOCAL_PREF is better than sending MP_UNREACH since no
router is ever temporarily without a route if an alternate exists but
the advertisement is suppressed by normal BGP rules including RR
topologies.

For this case at most you could ask your favorite router vendor for a
"poison-peer" command that changes the LOCAL_PREF of all routes to a
very high value (make up your own keyword and syntax which specifies
the peer and value).  If taking the whole router down, then a
"poison-peer all" or "poison-self" variation would be handy.

For the benefit of your peer, prior notification to their NOC of your
maintenance is still needed if you plan to take an EBGP session down
or take a router down.

For the benefit of your peer router some indication that its time for
them to "cost out" your routes (or poison your peering in the above
terminology) might help.  The advantage of using a CEASE subcode is
that any router that doesn't understand will just treat it as any
other CEASE.  Backwards compatibility is always nice.  If both routers
understand, they'd just LOCAL_PREF poison each side of the peering and
then after some delay (probably best to specify a default and
"configured on the local router") send MP_UNREACH for all the routes.
A disadvantage of a CEASE subcode is that if a specific prefix went
unreachable there is no longer a way to send an MP_UNREACH across the
peering, unless this is made a non-fatal CEASE to be followed by
another CEASE very shortly.

If I'm not mistaken, then all that is needed is an internet-draft with
a CEASE subcode and some wording to indicate that it should be treated
as non-fatal and result in both sides setting a very high LOCAL_PREF
for all routes on the peering regardless of local policy.  I suggest
that each router should enforce a maximum time to keep the peering
after getting one of these CEASE, making sure that it is only used as
a temporarily non-fatal policy override.

Lets see what other on the IDR list have to say about this as a
potential solution.

Curtis

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA10259 for <[e-mail]>; Sun, 14 Aug 2005 19:10:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4Rbx-0004Lu-Ec; Sun, 14 Aug 2005 19:09:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4Rbv-0004Ll-35 for [e-mail]; Sun, 14 Aug 2005 19:09:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18167 for <[e-mail]>; Sun, 14 Aug 2005 19:09:43 -0400 (EDT)
Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E4SAv-0007L9-BD for [e-mail]; Sun, 14 Aug 2005 19:45:58 -0400
Received: (qmail 83925 invoked from network); 14 Aug 2005 23:09:38 -0000
Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 14 Aug 2005 23:09:38 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j7EN9a37069270; Sun, 14 Aug 2005 19:09:36 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "DECRAENE Bruno RD-CORE-ISS" <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc 
In-reply-to: Your message of "Mon, 08 Aug 2005 14:33:54 +0200." <[e-mail]>
Date: Sun, 14 Aug 2005 19:09:36 -0400
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: [e-mail], [e-mail], FONDEVIOLE Benoit RD-CORE-ISS <[e-mail]>, DUBOIS Nicolas ROSI-DAS-ARI <[e-mail]>, Paul Jakma <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
"DECRAENE Bruno RD-CORE-ISS" writes:
> > 
> > Would it not be enough to simply withdraw the advertised 
> > routes before bringing the session down towards given peer ? 
> > If operator enters shutdown on BGP session this should not 
> > trigger any immediate BGP/TCP action .. instead one could 
> > send MP_UNREACH then at some decent timeout actually bring 
> > the sessions down.
>  
> It's indeed a possible solution. In fact it's exactly what we proposed
> in "draft-dubois-bgp-planned-maintenance-00.txt" in San Diego.
> Unfortunately, it's not working for all the iBGP topologies:
> - If you have a full iBGP mesh, all your peers already know the backup
> path and will select it. So this will work fine.
> - If you have RRs, iBGP routers (including your RR) may not have the
> backup path. The RR will propagate the withdraw and the destination will
> be removed from the RIB. 


Use LOCAL_PREF instead of MP_UNREACH.  The RR will use the best route
it has with the high LOCAL_PREF until another router announces a route
with a lower LOCAL_PREF.

This is easy to do.  If the peering goes down a one liner sets the
LOCAL_PREF for the peer.  If its the entire router going down, its
easy enough to set the default LOCAL_PREF to a high number.  If you
already use LOCAL_PREF, then you'll need to remove LOCAL_PREF lines
but not write out the config so things go back to normal after the
router comes up again.

Curtis

ps - Sorry for the noise if this is already suggested.  Didn't read to
the end of this thread yet.

_______________________________________________
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 OAA27524 for <[e-mail]>; Fri, 12 Aug 2005 14:36:06 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3eM2-0002SA-SC; Fri, 12 Aug 2005 14:34:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3eM1-0002Qe-Fj for [e-mail]; Fri, 12 Aug 2005 14:34:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09673 for <[e-mail]>; Fri, 12 Aug 2005 14:34:03 -0400 (EDT)
Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3euZ-0001QP-S1 for [e-mail]; Fri, 12 Aug 2005 15:09:49 -0400
Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by kremlin.juniper.net with ESMTP; 12 Aug 2005 11:33:51 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.96,103,1122879600";  d="scan'208"; a="460362906:sNHT22052984"
Received: from sapphire.juniper.net ([172.17.28.108]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211);  Fri, 12 Aug 2005 11:33:50 -0700
Date: Fri, 12 Aug 2005 11:33:50 -0700 (PDT)
From: Rahul Aggarwal <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Subject: Re: [Idr] IDR WG Minutes
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-OriginalArrivalTime: 12 Aug 2005 18:33:50.0858 (UTC) FILETIME=[628C66A0:01C59F6C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
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]

Hi Yakov,

A comment inline:

[snipped]

> Kapoor SSA - Gargi, Scott Wainner
>
> see ppt for info
>
> -------------------------
> Kapoor Tunnel SAFI
>
> combined w/ SSA preso, same ppt
>
> Gargi did technical side and changes to docs:
>
> more TLVs to express encap:
>
> MPLS, IPsec, GRE in IPsec, L2TPv3 in IPsec
>
> added application scenarios: MPLS over IP tunnels
>
> Scott presented motivations
>
> Combined comments:
>
> SKH: Can you explain status of this mechanism w/in each of these
> groups (on referenced drafts)? What is approved, required, etc. We
> need to see something from those chairs that the ref'ed drafts are
> "blessed."
>
> Scott:  Walked through
>
> Gargi: We have chicken and egg to get this done. Encoding first or
> formats first?
>
> Intro work on L3VPN list.
>
> Rekhter: Very reasonable model where must have both WGs review dependent docs.
>
> Bill Fenner:  Must work w/ other WG for encoding.
>
> Rekhter: Two possible models - first: semantics or encoding need to
> be done in L3VPN
>     second: L2/L3VPN WGs tell us semantics and IDR produces codepoints
>
> Rahul:  C/E problem wasn't problem in the past but, applicability.
> Applicability has been cleared up. Now that motivations are clear,
> the multiple proposal should be conjoined. Do work wherever ADs state
>

More specifically I said that there were two problems in the past: 1)
Motivation wasn't clear 2) Authors of draft-raggarwa-ppvpn-tunnel-encap
and authors of the drafts presented at this IDR meeting were unable to
come up with a joint proposal. I suggested that since motivations are
clearer now, this work should be discussed again in the L3VPN WG.

thanks,
rahul

> Roque: Disagree w/ motivations. IGP can provide reachability. I think
> you use BGP as signaling protocol which is not a problem. But,
> presentation states that BGP needs to know this information. Please
> clarify the layering split.
>
> Rekhter: Can this move to L3VPN
>
> SOLUTION: Joint Last Call in IDR and L3VPN.
>
>
> -------------------------
> SAFI Space Partition
> In reply to Jeff Hass email on list.
>
> Fenner to send notes on how to alloc SAFI space.
>
> Proposal: take private use space and turn it into reserved and
> perhaps 16 or so as private use. Reserved is reserved so we can
> decide later on FCFS or otherwise managed.
>
> Are folks using private space? Do we need to skip some?
>
> Rekhter: How long will it take to use up first come first served?
>
> Fenner: We should be able to straighten this out quickly and IANA is
> keeping up. 30 days deadline.
>
> Danny McPherson: Needs to be uniform across all WGs and Areas. Make
> it IETF aligned.
>
> Roque: I do not want to see vendor specific space go away altogether.
> There is much more usage than one case alluded to. Today is only
> practical alternative, cannot be locked out. Can it be shown to work
> before we assume 30 days?
>
> Fenner: There are publications on these agreements and promises that
> it will be done in 30 days. FCFS is you get it now .... no draft, no
> wait.
>
> Chandra; Cannot get rid of vendor space.  AF/SAFI has lost meaning and
> is a way to differentiate addrs between two peers. Just need opaque
> space that we can use between two peers.
>
> Gargi: Must have vendor space perhaps reduced is ok. Second, IANA is
> faster but, it seems to required Routing ADs having lunch w/ IANA.
>
> Rekhter: IANA must have strict 30 days max as rule.
>
> Fenner: We are working on this and the stats show that 30 days is being met.
>
> _______________________________________________
> 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 NAA21160 for <[e-mail]>; Fri, 12 Aug 2005 13:15:01 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3d5Q-0006Vw-EI; Fri, 12 Aug 2005 13:12:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3d5O-0006Vr-1A for [e-mail]; Fri, 12 Aug 2005 13:12:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06277 for <[e-mail]>; Fri, 12 Aug 2005 13:12:46 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX18x+gluaS3AERvRdMWIxP76gBwZ8oQ1fWg=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3ddu-0007mP-Va for [e-mail]; Fri, 12 Aug 2005 13:48:33 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7CHAYfS032228; Fri, 12 Aug 2005 18:10:38 +0100
Date: Fri, 12 Aug 2005 18:10:34 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Bill Fenner <[e-mail]>
Subject: Re: [Idr] AD Review comments on draft-ietf-idr-restart
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mail-Copies-To: [e-mail]
Mail-Followup-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: [e-mail], [e-mail], [e-mail], [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]

On Fri, 12 Aug 2005, Bill Fenner wrote:

> In fact, you don't know that it's a restarting connection until 
> you've gotten the OPEN on the new connection, right?

A concern here, is that the GR peer assumes forwarding will stay up. 
So NOTIFY/CEASE now becomes (between GR negotiated peers):

 	"I'm shutting down (implicit: assume I keep forwarding in place)"

However, in light of other discussions, that assumption presents a 
problem for possible future IDR work that intends to try gracefully 
handle shutdown of forwarding - ie the ability to say:

 	"I'm shutting down"

without any assumptions is lost between GR peers.

(The assumption is bounded by timers, but that introduces delays for 
any graceful full-shutdown work..)

It /might/ be an idea to require GR peers to explicitely signal their 
intent to keep forwarding up during restart, or even just:

 	"I'm restarting"

And let this new CEASE sub-code carry the assumption (or maybe 
ADMIN_RESET would suffice?)

(No idea whether it's a good idea to use sub-codes for anything other 
than informational content).

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
He who is flogged by fate and laughs the louder is a masochist.

_______________________________________________
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 MAA19394 for <[e-mail]>; Fri, 12 Aug 2005 12:52:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3clF-0000B4-Se; Fri, 12 Aug 2005 12:52:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3clE-000084-CT for [e-mail]; Fri, 12 Aug 2005 12:52:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05442 for <[e-mail]>; Fri, 12 Aug 2005 12:51:56 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/W7Ob5wge/UmBYZnPM0LGa+PL4s9r4LiE=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3dJk-0007EH-Ut for [e-mail]; Fri, 12 Aug 2005 13:27:42 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7CGpQ5L031856; Fri, 12 Aug 2005 17:51:30 +0100
Date: Fri, 12 Aug 2005 17:51:26 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Olivier Bonaventure <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
Mail-Followup-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Cc: DECRAENE Bruno RD-CORE-ISS <[e-mail]>, Inter-Domain Routing List <[e-mail]>, vijay gill <[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]

Hi Olivier,

> You need at least to be able to distinguish between :

> - a NOTIFY/CEASE that must be processed immediately
> - a NOTIFY/CEASE that must be processed after N seconds (note that
> selecting the good value for N is an issue)

The receiving router or the sender? As for selecting a good value, 
yes :), tis an issue.

> The solution to be used will depend on how packets are forwarded inside
> the AS. There are two possible solutions :

> - pervasive BGP where all routers run BGP and consult their FIB to
> forward each received transit packet

> - encapsulation such as an MPLS-enabled network. In this case, the
> ingress router selects the egress router and forward the packets
> directly to the egress router (no transit router need to consult its BGP
> FIB to forward the packet).
>
> With pervasive BGP, the solution must ensure that no transient 
> forwarding loop will occcur during the update of the FIBs of all 
> routers. This is more complex than simply setting a delay of N 
> seconds on one router.

Generally, yes, I'm sure it is. Seems it could work for the scenario 
presented though, if the two 'edge' routers (CUST-ASBR{1,2}) both 
delayed their FIB updates, thus giving time for interior iBGP 
speakers (P1, P2) to update their paths. (Ie if N is greater than the 
time it takes for P1 and P2, then there is no time during which 
either ASBR1 or ASBR2 will refuse to forward to P2).

It likely wouldn't work for more complex edge scenarios, but that's 
(hopefully) what you guys are considering ;).

> Note that this document considers the ordered update of FIBs with 
> only a link-state routing protocol. It does not consider any 
> interaction with BGP.

Indeed.

Your (plural) work applies generally though to topology updates, 
doesn't it?

Further, given iBGP should not result in complex forwarding (iBGP 
topology should nearly always be 'flat' in the abstract - nexthops 
are abstracted, should always point to the 'edge'), it means, from an 
iBGP POV, you should not have a complex topology to contend with.

Eg, in the example scenario given previously, consider some other 
router within AS 2, call it P3. It's interior path to the routers 
ASBR{1,2} is arbitrary (be it: many hops, lots of redundant paths; or 
maybe its directly to one or both of P1 and P2, who knows). However, 
as iBGP abstracts interior topology it's iBGP path to CUST is always:

 	x/y via CUST

The only sane place to distribute this external nexthop into iBGP (if 
at all, if using IGP - then we dont need to worry at all) is on 
either ASBR1 or ASBR2.

So the delayed update trick on ASBR1 will work fine, as long as the 
delay is sufficient for iBGP to converge on ASBR2.

Similarly, if CUST's sessions to ASBR1 and ASBR2 have different 
nexthops, in iBGP we will have one of:

 	x/y via CUST-nh1 (connected to ASBR1)

or

 	x/y via CUST-nh2 (connected to ASBR2)

installed throughout the rest of the iBGP domain. And again, the 
delayed FIB update on ASBR1 should allow anyone in the iBGP of AS2 
using the former path to update to the latter.

In both cases, while others converge, ASBR1 will still forward to 
CUST (as will ASBR2 obviously). Once convergence is complete, ASBR1 
should no longer see any packets destined for x/y at all, and it 
doesnt matter what it does really.

Ie, the abstracted topology which iBGP propogates makes analysis of 
this quite easy, doesn't it? At least for the shutdown case, not 
considering the 'up' case.

Obviously, if the nexthops are carried in IGP, then updates of those 
are an IGP problem - which is being looked at, AIUI (by yourself and 
others).

> There is a full paper on the FIB update order with mathematical 
> proofs, see Pierre Francois' INFOCOM paper available from 
> http://www.info.ucl.ac.be/people/OBO/biblio.html

Ah, bedankt! I'll have a read.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Old MacDonald had an agricultural real estate tax abatement.

_______________________________________________
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 LAA11602 for <[e-mail]>; Fri, 12 Aug 2005 11:15:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bET-0003rd-CK; Fri, 12 Aug 2005 11:14:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bEO-0003oB-Ku for [e-mail]; Fri, 12 Aug 2005 11:14:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00194 for <[e-mail]>; Fri, 12 Aug 2005 11:13:57 -0400 (EDT)
Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3bmv-0004Hb-9W for [e-mail]; Fri, 12 Aug 2005 11:49:42 -0400
Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id EFCAB197537; Fri, 12 Aug 2005 11:04:21 -0400 (EDT)
Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j7CFDnq2012021;  Fri, 12 Aug 2005 11:13:49 -0400
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Date: Fri, 12 Aug 2005 11:13:49 -0400
From: Bill Fenner <[e-mail]>
Versions: dmail (linux) 2.6d/makemail 2.10
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: [e-mail]
Subject: [Idr] AD Review comments on draft-ietf-idr-restart
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

I'm sorry that these are so late, especially since I found only a couple of
concerns.

1. Very minor - the document needs an IANA Considerations section,
probably just one sentence asking to change the reference for
64 from [Chen] to this document.

2. There's a new timer introduced (upper bound on the amount of time a
router defers its route selection) which MUST be supported but there's
no guidance on a default value or whether it should be used at all
by default.  (It may be easiest to just say that it SHOULD not be
configured to be used by default, and the upper bound is left to be
chosen by configuration by the user; if there's some guidance as to
how to set it that'd be even better)

3. In the description of the state machine modification, I'm concerned
that the literal interpretation of

      If the Graceful Restart capability with one or more AFI/SAFI has
      been received for the session, then TcpConnectionConfirmed (Event
      17) is treated as TcpConnectionFails (Event 18).

is that the new connection is torn down -- in Established state,
the FSM says that receiving a TcpConnectionFails means

              - sets the ConnectRetryTimer to zero,
              - deletes all routes associated with this connection,
              - releases all the BGP resources,
              - drops the TCP connection,
              - increments the ConnectRetryCounter by 1,
              - changes its state to Idle.

and clearly in graceful restart you don't want to do most of those things.

In fact, you don't know that it's a restarting connection until you've
gotten the OPEN on the new connection, right?  You probably want to
be modifying the "If a valid OPEN message (BGPOpen (Event 19)) is received"
condition in the Established state of the FSM?

  Bill

_______________________________________________
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 IAA28316 for <[e-mail]>; Fri, 12 Aug 2005 08:27:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Yc8-00027i-5p; Fri, 12 Aug 2005 08:26:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Yc6-00027V-JZ for [e-mail]; Fri, 12 Aug 2005 08:26:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18911 for <[e-mail]>; Fri, 12 Aug 2005 08:26:16 -0400 (EDT)
Received: from bay17-f34.bay17.hotmail.com ([64.4.43.84] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3ZAZ-0007Uo-NJ for [e-mail]; Fri, 12 Aug 2005 09:01:59 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 12 Aug 2005 05:26:05 -0700
Message-ID: <[e-mail]>
Received: from 205.161.7.99 by by17fd.bay17.hotmail.msn.com with HTTP; Fri, 12 Aug 2005 12:26:05 GMT
X-Originating-IP: [202.144.106.188]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
In-Reply-To: <[e-mail]>
From: "john smith" <[e-mail]>
To: [e-mail]
Subject: RE: [Idr] IDR WG Minutes
Date: Fri, 12 Aug 2005 12:26:05 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 12 Aug 2005 12:26:05.0432 (UTC) FILETIME=[02879780:01C59F39]
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
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]

John,

>
> > Paul ??: If in ECMP case, what AS sequence? How to pass multiple
> > paths to a legacy speaker?
> >
> > Retana:  Cap advert defines who can learn add_path. Other
> > applications like EBGP ECMP and propagating multiple paths will have
> > to be addressed.
> >
> > Retana: Constrained scope.
>
>I dont think we should be considering proposals that preclude advertising 
>and using BGP
>ECMP routes. More so when the WG is considering taking this up as an item.
>
Given the assumption that
a. CPUs will grow faster that ASICs.
b. memory on control plane will be cheaper than those in the forwarding 
plane components,

i see a benefit in signalling paths to solve a problem that BGP may not 
solve in its current form.

the only advantage this gives is help solve negative arcs.
Closer to Local_pref on eBGP/MED oscillations scenarios.

the only reason I brought up this topic was that i was not dead sure how 
weights are used on eBGP peers.
Could be my lack of knowledge of coupled be too much obfuscation around the 
correct solution :-).

It does make sense to have the feature though.

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/


_______________________________________________
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 PAA26092 for <[e-mail]>; Wed, 10 Aug 2005 15:23:53 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2w5b-00022E-FA; Wed, 10 Aug 2005 15:18:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2w5Y-00021z-Ks for [e-mail]; Wed, 10 Aug 2005 15:18:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21434 for <[e-mail]>; Wed, 10 Aug 2005 15:18:07 -0400 (EDT)
Received: from astrolabe.info.ucl.ac.be ([130.104.229.109] helo=info.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2wdh-0000h6-Pt for [e-mail]; Wed, 10 Aug 2005 15:53:27 -0400
Received: from [127.0.0.1] (bismarck [130.104.229.58]) by info.ucl.ac.be (8.12.11/8.12.11) with ESMTP id j7AJGQ6V007052; Wed, 10 Aug 2005 21:16:26 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Wed, 10 Aug 2005 21:16:57 +0200
From: Olivier Bonaventure <[e-mail]>
User-Agent: Debian Thunderbird 1.0.2 (X11/20050331)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Jakma <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-INGI-MailScanner-Information: Please contact the ISP for more information
X-INGI-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
Content-Transfer-Encoding: 7bit
Cc: DECRAENE Bruno RD-CORE-ISS <[e-mail]>, Inter-Domain Routing List <[e-mail]>, vijay gill <[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]

Paul,

>> Could you be a little more specific about your proposition?
> 
> 
> Put a delay in between NOTIFY/CEASE and updating your FIB.

You need at least to be able to distinguish between :
- a NOTIFY/CEASE that must be processed immediately
- a NOTIFY/CEASE that must be processed after N seconds (note that
selecting the good value for N is an issue)

>> If this is a correct understanding, let's take the following topology
>> (from the requirement draft):
>>                             '
>>                             '
>>                             '
>>                       AS1   '      AS2
>>                             '
>>
>>
>>                       /-----------ASBR1-----P1----
>>                      /                      |
>>                     /                       |
>>                 CUST                        |
>>                     \                       |
>>              X.Y/16  \                      |
>>                       \-----------ASBR2-----P2----
>>
>>
>>                             '
>>                             '
>>                       AS1   '      AS2
>>                             '
>>
>>                   Figure 1: Redundant peering example.
>>
>>
>> We want to close CUST-ASBR1 link.
>>
>> After sending the "CEASE" to CUST, ASBR1 removes the routes learned
>> through this eBGP session. You have 2 cases:
>>
>> -0- BGP don't know the backup path, so it will remove the destination
>> from the RIB. ==> packets to the destination X.Y/16 (your customer) are
>> dropped on ASBR1.
> 

Note that this can happen simply if CUST-ASBR2 has a lower local-pref
than CUST-ASBR1

> Not sure what you mean by "BGP" here - ASBR1 or P1?
> 
> 1. ASBR1 Sends CEASE/NOTIFY to CUST1
> 2. ASBR1 processes any routes it may have received from CUST1
>     2a. Form withdrawals and send to P1
>     2b. Queue up FIB updates to process with some delay X
> 3. After delay X expires, process the FIB updates due to 2a
> 
> P1 will get the withdrawal. If it doesn't know the backup path via P2,
> it's surely in trouble regardless of what you propose for BGP ;). If you
> mean ASBR1 is not aware - that's ok, it will continue forwarding to
> CUST1 for a while.
> 
> The delay X, if large enough, gives P1 sufficient time to process the
> withdrawal, calculate the new path via P2 and install it.

The solution to be used will depend on how packets are forwarded inside
the AS. There are two possible solutions :
- pervasive BGP where all routers run BGP and consult their FIB to
forward each received transit packet
- encapsulation such as an MPLS-enabled network. In this case, the
ingress router selects the egress router and forward the packets
directly to the egress router (no transit router need to consult its BGP
FIB to forward the packet).

With pervasive BGP, the solution must ensure that no transient
forwarding loop will occcur during the update of the FIBs of all
routers. This is more complex than simply setting a delay of N seconds
on one router.

...
> 
> This is all essentially what several people have been considering
> already, eg the "Ordered FIB Updates" draft (i think you're aware of it,
> no?):
> 
>     http://bgp.potaroo.net/ietf/idref/draft-francois-ordered-fib/

Note that this document considers the ordered update of FIBs with only a
link-state routing protocol. It does not consider any interaction with BGP.

> Essentially, seems to me there are two rules of thumb:
> 
>     - for a path shutdown, FIB updates should lag RIB updates
> 
>     - for a path addition, FIB updates should lead RIB updates
>       and propogation.
> 
> (iirc) Francois had a very interesting presentation at the routing area
> meeting on this. They're looking deeply at this already, mathematically
> AIUI (havn't seen any papers on that side of things though), so
> hopefully some really useful techniques will come out of that in time.

There is a full paper on the FIB update order with mathematical proofs,
see Pierre Francois' INFOCOM paper available from
http://www.info.ucl.ac.be/people/OBO/biblio.html

Best regards

Olivier

_______________________________________________
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 OAA20534 for <[e-mail]>; Wed, 10 Aug 2005 14:13:12 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2v2a-0006gK-Px; Wed, 10 Aug 2005 14:11:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2v2Y-0006eW-Ke for [e-mail]; Wed, 10 Aug 2005 14:10:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14611 for <[e-mail]>; Wed, 10 Aug 2005 14:10:57 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1+uEypK00BDxAHNd0pvqfbW/u0BR+ncMgA=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2vag-0006Pt-Fh for [e-mail]; Wed, 10 Aug 2005 14:46:16 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7AIAhkg000835; Wed, 10 Aug 2005 19:10:46 +0100
Date: Wed, 10 Aug 2005 19:10:40 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: DECRAENE Bruno RD-CORE-ISS <[e-mail]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mail-Copies-To: [e-mail]
Mail-Followup-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: Inter-Domain Routing List <[e-mail]>, vijay gill <[e-mail]>, Olivier Bonaventure <[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 Wed, 10 Aug 2005, DECRAENE Bruno RD-CORE-ISS wrote:

> To adress the other direction of the IP flow, it would probably 
> require that on reception of a BGP NOTIFY/CEASE, you activate the 
> same trick.

If P1 were to be shutdown? Yes, then you'd want P1 to support this 
"trick". However, it's still useful in a mixed environment. Eg, for 
your ASBR1 case, even if P1 doesn't support this, it still should 
enhance routing.

> And it would require some extra trick if you have multiple RR 
> between the 2 ASBR advertising the path to the destination. (for 
> example full-reflection as you mention, but that also has a cost).

Yes. I'd suggest looking at the 3 drafts which potentially could 
solve the full-reflection + "CEASE + wait" optimisation case.

> If we come back to the requirement doc, it does not state that the 
> BGP protocol should necessarily be modified. It merely points out 
> an issue which could possibly be resolved with an informational or 
> BCP doc.

Fair enough.

> I guess most of us agree on the issue with the default behavior, but we
> disagree on what should be done:

> - Some expressed that it could already be solved now using specific
> route policies, manually configured or scripted.

> - I guess your point is that the issue could be resolved by an
> implementation without requiring any BGP modification and as such IDR
> should not be involved.

Yes, or at least that one could implement "CEASE and wait" first and 
garner some experience first before attempting to see what needs to 
be done at IDR. (I'm an IETF/IDR process newbie though, so my opinion 
might be incompatible with IETF/IDR practice).

> - Our point is that currently no popular implementation has 
> addressed this issue and that IDR could discuss this point. The 
> result of this discussion may be that it should be left to each 
> implementation but why presuppose the conclusion.

Hmm, well, I don't know when I'll get around to it (no promises), but 
hacking CEASE+wait into a Free Software BGP implemention is now on my 
lower-priority TODO list.

Mightn't be useful for you for deployment, but likely would be useful 
for laboratory testing to see how well CEASE+wait could work.

> It deals with link state IGP. I'd be fine if someone wrote an 
> equivalent draft for BGP.

It deals with topology changes in general, and discusses them in 
context of IGP - the topology change stuff is obviously still 
applicable to BGP to some extent.. interesting stuff anyway.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
A New York City ordinance prohibits the shooting of rabbits from the
rear of a Third Avenue street car -- if the car is in motion.

_______________________________________________
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 NAA19079 for <[e-mail]>; Wed, 10 Aug 2005 13:54:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2uis-0000re-0m; Wed, 10 Aug 2005 13:50:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2uip-0000qZ-6O for [e-mail]; Wed, 10 Aug 2005 13:50:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13621 for <[e-mail]>; Wed, 10 Aug 2005 13:50:33 -0400 (EDT)
Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2vGy-0005t0-JC for [e-mail]; Wed, 10 Aug 2005 14:25:52 -0400
Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211);  Wed, 10 Aug 2005 19:49:34 +0200
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"
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Wed, 10 Aug 2005 19:32:08 +0200
Message-ID: <[e-mail]>
Thread-Topic: [idr] BGP planned maintenance requirements as an IDR WG doc
Thread-Index: AcWduPBF5+cF+8HuS8G1Uob7CeFOZAABF6KQ
From: "DECRAENE Bruno RD-CORE-ISS" <[e-mail]>
To: "Paul Jakma" <[e-mail]>
X-OriginalArrivalTime: 10 Aug 2005 17:49:34.0126 (UTC) FILETIME=[DE2FC4E0:01C59DD3]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: Inter-Domain Routing List <[e-mail]>, vijay gill <[e-mail]>, Olivier Bonaventure <[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 NAA19079

Hi Paul,

> > Could you be a little more specific about your proposition?
> 
> Put a delay in between NOTIFY/CEASE and updating your FIB.
 
Fine. It's a possible solution.

To adress the other direction of the IP flow, it would probably require
that on reception of a BGP NOTIFY/CEASE, you activate the same trick.
And it would require some extra trick if you have multiple RR between
the 2 ASBR advertising the path to the destination. (for example
full-reflection as you mention, but that also has a cost).



If we come back to the requirement doc, it does not state that the BGP
protocol should necessarily be modified. It merely points out an issue
which could possibly be resolved with an informational or BCP doc. 
I guess most of us agree on the issue with the default behavior, but we
disagree on what should be done:
- Some expressed that it could already be solved now using specific
route policies, manually configured or scripted.
- I guess your point is that the issue could be resolved by an
implementation without requiring any BGP modification and as such IDR
should not be involved.
- Our point is that currently no popular implementation has addressed
this issue and that IDR could discuss this point. The result of this
discussion may be that it should be left to each implementation but why
presuppose the conclusion.



> This is all essentially what several people have been considering
already, eg the "Ordered FIB Updates" draft (i think you're aware of it,
no?):
> 	http://bgp.potaroo.net/ietf/idref/draft-francois-ordered-fib/

I'm aware of this draft which is indeed very interesting.
It deals with link state IGP. I'd be fine if someone wrote an equivalent
draft for BGP.


Regards,
Bruno

_______________________________________________
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 KAA03435 for <[e-mail]>; Wed, 10 Aug 2005 10:37:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rhR-0001sC-G7; Wed, 10 Aug 2005 10:36:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rhO-0001oQ-CV for [e-mail]; Wed, 10 Aug 2005 10:36:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02980 for <[e-mail]>; Wed, 10 Aug 2005 10:36:52 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/2B99pkUP7tpYzaEMDVjULxfjuryfV63g=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2sFT-0000Kk-NS for [e-mail]; Wed, 10 Aug 2005 11:12:10 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7AEaW8m030797; Wed, 10 Aug 2005 15:36:36 +0100
Date: Wed, 10 Aug 2005 15:36:30 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: DECRAENE Bruno RD-CORE-ISS <[e-mail]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mail-Copies-To: [e-mail]
Mail-Followup-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8
Cc: Inter-Domain Routing List <[e-mail]>, vijay gill <[e-mail]>, Olivier Bonaventure <[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 Wed, 10 Aug 2005, DECRAENE Bruno RD-CORE-ISS wrote:

> Could you be a little more specific about your proposition?

Put a delay in between NOTIFY/CEASE and updating your FIB.

> If this is a correct understanding, let's take the following topology
> (from the requirement draft):
>                             '
>                             '
>                             '
>                       AS1   '      AS2
>                             '
>
>
>                       /-----------ASBR1-----P1----
>                      /                      |
>                     /                       |
>                 CUST                        |
>                     \                       |
>              X.Y/16  \                      |
>                       \-----------ASBR2-----P2----
>
>
>                             '
>                             '
>                       AS1   '      AS2
>                             '
>
>                   Figure 1: Redundant peering example.
>
>
> We want to close CUST-ASBR1 link.
>
> After sending the "CEASE" to CUST, ASBR1 removes the routes learned
> through this eBGP session. You have 2 cases:
>
> -0- BGP don't know the backup path, so it will remove the destination
> from the RIB. ==> packets to the destination X.Y/16 (your customer) are
> dropped on ASBR1.

Not sure what you mean by "BGP" here - ASBR1 or P1?

1. ASBR1 Sends CEASE/NOTIFY to CUST1
2. ASBR1 processes any routes it may have received from CUST1
 	2a. Form withdrawals and send to P1
 	2b. Queue up FIB updates to process with some delay X
3. After delay X expires, process the FIB updates due to 2a

P1 will get the withdrawal. If it doesn't know the backup path via 
P2, it's surely in trouble regardless of what you propose for BGP ;). 
If you mean ASBR1 is not aware - that's ok, it will continue 
forwarding to CUST1 for a while.

The delay X, if large enough, gives P1 sufficient time to process the 
withdrawal, calculate the new path via P2 and install it.

ASBR1, during this time, will continue forwarding any packets P1 
sends via it on to CUST1. If ASBR1 does not know about the backup 
path, that's ok, because when ASBR1 eventually updates it's FIB, P1 
should already have updated its FIB and will no longer be sending 
packets to it for CUST1.

Eventually P1 should pass an announcement for CUST1 (learned from P2) 
to ASBR1 and ASBR1 updates its FIB. ASBR1 shouldn't see any traffic 
at all directed towards CUST1 though - it will be idle.

> -1- BGP knows the backup path, so it will install it in the RIB ==>
> packets to that destination are sent back to P1. Unfortunately, P1
> doesn't know yet that CUST-ASBR1 eBGP session is down. So it sends back
> to packet to ASBR1 ==> packets are looped between ASBR1 and P1.

If ASBR1 knows the backup path, that's ok. Because it will not update 
its FIB for a while - sufficient time for P1 to update its own RIB 
and FIB to point CUST1 route in the direction of P2.

This is all essentially what several people have been considering 
already, eg the "Ordered FIB Updates" draft (i think you're aware of 
it, no?):

 	http://bgp.potaroo.net/ietf/idref/draft-francois-ordered-fib/

Essentially, seems to me there are two rules of thumb:

 	- for a path shutdown, FIB updates should lag RIB updates

 	- for a path addition, FIB updates should lead RIB updates
 	  and propogation.

(iirc) Francois had a very interesting presentation at the routing 
area meeting on this. They're looking deeply at this already, 
mathematically AIUI (havn't seen any papers on that side of things 
though), so hopefully some really useful techniques will come out of 
that in time.

> Could you please have a look at slide 4 in our presentation?

Where is your presentation exactly? I remember the presentation only 
vaguely at this stage - note that powerpoint format is inconvenient 
for me.

> It looks to me that your proposition has been tested (The BGP 
> session have been shutdown, the interface has not even been 
> shutdown) and yet you lose some trafic.

If the FIB was updated, i can imagine so, yes.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
We'll try to cooperate fully with the IRS, because, as citizens, we feel
a strong patriotic duty not to go to jail.
 		-- Dave Barry

_______________________________________________
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 JAA28061 for <[e-mail]>; Wed, 10 Aug 2005 09:30:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2qeW-0006Ho-0l; Wed, 10 Aug 2005 09:29:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2qeU-0006Hb-Nd; Wed, 10 Aug 2005 09:29:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27224; Wed, 10 Aug 2005 09:29:49 -0400 (EDT)
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2rCa-0006Lm-Ql; Wed, 10 Aug 2005 10:05:06 -0400
Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211);  Wed, 10 Aug 2005 15:29:38 +0200
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"
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Wed, 10 Aug 2005 15:29:36 +0200
Message-ID: <[e-mail]>
Thread-Topic: [idr] BGP planned maintenance requirements as an IDR WG doc
Thread-Index: AcWdpYQ5tshEjdHhROeWMU4shVvohgABHzpg
From: "DECRAENE Bruno RD-CORE-ISS" <[e-mail]>
To: "Paul Jakma" <[e-mail]>, "AHMAD Zubair EQUANT" <[e-mail]>
X-OriginalArrivalTime: 10 Aug 2005 13:29:38.0359 (UTC) FILETIME=[8E629470:01C59DAF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: [e-mail], [e-mail], Olivier Bonaventure <[e-mail]>, vijay gill <[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 JAA28061

Hi Paul,

> At least one signalling method exists (CEASE) - why not implement 
> CEASE+wait first and get some experience of it before considering
> what protocol changes could make it work better?

Could you be a little more specific about your proposition?

>From your description, I understand that you close the BGP session
according to the BGP spec, then wait some time, then shut down the
interface and proceed with the maintenance.

If this is a correct understanding, let's take the following topology
(from the requirement draft):
                             '  
                             '  
                             '  
                       AS1   '      AS2  
                             '  
               
                         
                       /-----------ASBR1-----P1----  
                      /                      |   
                     /                       |  
                 CUST                        | 
                     \                       | 
              X.Y/16  \                      | 
                       \-----------ASBR2-----P2---- 
               
                   
                             '  
                             '  
                       AS1   '      AS2  
                             '  
                                      
                   Figure 1: Redundant peering example.  


We want to close CUST-ASBR1 link.

After sending the "CEASE" to CUST, ASBR1 removes the routes learned
through this eBGP session. You have 2 cases:

-0- BGP don't know the backup path, so it will remove the destination
from the RIB. ==> packets to the destination X.Y/16 (your customer) are
dropped on ASBR1.
-1- BGP knows the backup path, so it will install it in the RIB ==>
packets to that destination are sent back to P1. Unfortunately, P1
doesn't know yet that CUST-ASBR1 eBGP session is down. So it sends back
to packet to ASBR1 ==> packets are looped between ASBR1 and P1.



>I'd like to see:

> - implementation of the CEASE and wait solution
> - some field experience of it
> - maybe kind of informational ID discussing the previous two points

> *Then* and only then is it sensible to start talking about a 
> potential requirements draft for tackling any shortcomings in BGP wrt 
>maintainance, and possible suitable changes to it.

> Understand the problem first please (surely?).

Could you please have a look at slide 4 in our presentation?
It looks to me that your proposition has been tested (The BGP session
have been shutdown, the interface has not even been shutdown) and yet
you lose some trafic.


Regards,
Bruno

_______________________________________________
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 IAA24082 for <[e-mail]>; Wed, 10 Aug 2005 08:39:48 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2pp4-0000Zt-84; Wed, 10 Aug 2005 08:36:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2pp2-0000Zo-Ab for [e-mail]; Wed, 10 Aug 2005 08:36:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24247 for <[e-mail]>; Wed, 10 Aug 2005 08:36:39 -0400 (EDT)
Received: from smtp-out.hotpop.com ([38.113.3.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2qN8-0004qJ-67 for [e-mail]; Wed, 10 Aug 2005 09:11:55 -0400
Received: from hotpop.com (kubrick.hotpop.com [38.113.3.103]) by smtp-out.hotpop.com (Postfix) with SMTP id D51AA1567B27 for <[e-mail]>; Wed, 10 Aug 2005 12:36:29 +0000 (UTC)
Received: from ALOKLXP (unknown [202.144.106.188]) by smtp-3.hotpop.com (Postfix) with ESMTP id AE21A17A60B5; Wed, 10 Aug 2005 12:36:27 +0000 (UTC)
Message-ID: <005701c59da8$14fda180$[e-mail]>
From: "Alok" <[e-mail]>
To: "Paul Jakma" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Wed, 10 Aug 2005 18:06:04 +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: 057ebe9b96adec30a7efb2aeda4c26a4
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]

hi Paul,

just a couple of questions?

Why cant you simply what for the GR timers to time out before actually
pulling the router out of service?

In other words GR makes the assumption AFAIK that the remote router has to
come up in sometime.

if it doesnt, BGP declares the peer as down.

Simply dont pull the router out of service till the timers expire?
The remote end would automatically discover the peer is down in that time.
(coupled with the other post where you could track the incoming traffic on
forwarding plane to ensure static/policy routed peers also change their
routes)

-thanks
Alok
----- Original Message ----- 
From: "Paul Jakma" <[e-mail]>
To: <[e-mail]>
Cc: "DECRAENE Bruno RD-CORE-ISS" <[e-mail]>;
<[e-mail]>; <[e-mail]>; "Olivier Bonaventure"
<[e-mail]>; "vijay gill" <[e-mail]>
Sent: Wednesday, August 10, 2005 5:47 PM
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc


> Hi Zubair,
>
> On Wed, 10 Aug 2005, [e-mail] wrote:
>
> > ZA>> Well the signalling of maintenance action is definitely
> > needed.
> > only a requirements draft, I believe we should better focus on
> > clarifying and refining the requirements for planned maintenance
> > and leave the discussion about potential solutions for the next
> > step (solution proposal/draft)..
>
> Horse before cart please.
>
> At least one signalling method exists (CEASE) - why not implement
> CEASE+wait first and get some experience of it before considering
> what protocol changes could make it work better?
>
> I don't see how one can even know what the requirements are at this
> point in time.
>
> Get some operational experience of the 'CEASE + wait + shutdown
> forwarding' solution, only then can you know what would be useful to
> add to the actual BGP protocol.
>
> > ZA>> I agree that it would be nice if we can achieve the desired
> > behavior (i.e. graceful shutdown that eliminates or minimizes
> > packet loss during BGP convergence) using the so called 'trick'
> > implemented only locally (without requiring any protocol extensions
> > on the peers). However, such implementation must cover the various
> > topologies of interest that are presented in the draft.
>
> It does. The wait period just has to be long enough to allow everyone
> else to converge.
>
> > Again, I would suggest to leave this discussion on possible
> > soutions for the Solutions draft.
>
> What solutions draft?
>
> > ZA>> Interaction with GR is dependent on the type of solution
> > (trick) that gets implemented.  I think we should include this
> > point in the requirement draft that any solutions for BGP Graceful
> > Shutdown must consider & ensure compatibility with BGP GR (if GR
> > capability is enabled).
>
> I'd like to see:
>
> - implementation of the CEASE and wait solution
> - some field experience of it
> - maybe kind of informational ID discussing the previous two points
>
> *Then* and only then is it sensible to start talking about a
> potential requirements draft for tackling any shortcomings in BGP wrt
> maintainance, and possible suitable changes to it.
>
> Understand the problem first please (surely?).
>
> My recursion detector is telling me i've now been here before several
> times in this thread, so I'll bow out.
>
> regards,
> -- 
> Paul Jakma [e-mail] [e-mail] Key ID: 64A2FF6A
> Fortune:
> Q: What is purple and concord the world?
> A: Alexander the Grape.
>
> _______________________________________________
> 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 IAA22476 for <[e-mail]>; Wed, 10 Aug 2005 08:19:12 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2pWp-0004NF-5p; Wed, 10 Aug 2005 08:17:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2pWm-0004N4-Sl; Wed, 10 Aug 2005 08:17:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23351; Wed, 10 Aug 2005 08:17:47 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1+LL6uuSBN3xQoWStrZy9RQa87aNuCRtcI=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2q4t-0004MV-1i; Wed, 10 Aug 2005 08:53:03 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j7ACHJTC029213; Wed, 10 Aug 2005 13:17:22 +0100
Date: Wed, 10 Aug 2005 13:17:17 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mail-Copies-To: [e-mail]
Mail-Followup-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: DECRAENE Bruno RD-CORE-ISS <[e-mail]>, [e-mail], [e-mail], Olivier Bonaventure <[e-mail]>, vijay gill <[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]

Hi Zubair,

On Wed, 10 Aug 2005, [e-mail] wrote:

> ZA>> Well the signalling of maintenance action is definitely 
> needed.
> only a requirements draft, I believe we should better focus on 
> clarifying and refining the requirements for planned maintenance 
> and leave the discussion about potential solutions for the next 
> step (solution proposal/draft)..

Horse before cart please.

At least one signalling method exists (CEASE) - why not implement 
CEASE+wait first and get some experience of it before considering 
what protocol changes could make it work better?

I don't see how one can even know what the requirements are at this 
point in time.

Get some operational experience of the 'CEASE + wait + shutdown 
forwarding' solution, only then can you know what would be useful to 
add to the actual BGP protocol.

> ZA>> I agree that it would be nice if we can achieve the desired 
> behavior (i.e. graceful shutdown that eliminates or minimizes 
> packet loss during BGP convergence) using the so called 'trick' 
> implemented only locally (without requiring any protocol extensions 
> on the peers). However, such implementation must cover the various 
> topologies of interest that are presented in the draft.

It does. The wait period just has to be long enough to allow everyone 
else to converge.

> Again, I would suggest to leave this discussion on possible 
> soutions for the Solutions draft.

What solutions draft?

> ZA>> Interaction with GR is dependent on the type of solution 
> (trick) that gets implemented.  I think we should include this 
> point in the requirement draft that any solutions for BGP Graceful 
> Shutdown must consider & ensure compatibility with BGP GR (if GR 
> capability is enabled).

I'd like to see:

- implementation of the CEASE and wait solution
- some field experience of it
- maybe kind of informational ID discussing the previous two points

*Then* and only then is it sensible to start talking about a 
potential requirements draft for tackling any shortcomings in BGP wrt 
maintainance, and possible suitable changes to it.

Understand the problem first please (surely?).

My recursion detector is telling me i've now been here before several 
times in this thread, so I'll bow out.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Q:	What is purple and concord the world?
A:	Alexander the Grape.

_______________________________________________
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 HAA17106 for <[e-mail]>; Wed, 10 Aug 2005 07:11:07 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2oSW-0002P4-0n; Wed, 10 Aug 2005 07:09:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2oST-0002Oz-Lg for [e-mail]; Wed, 10 Aug 2005 07:09:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20256 for <[e-mail]>; Wed, 10 Aug 2005 07:09:14 -0400 (EDT)
Received: from smtp-out.hotpop.com ([38.113.3.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2p0S-0002VP-GU for [e-mail]; Wed, 10 Aug 2005 07:44:32 -0400
Received: from hotpop.com (kubrick.hotpop.com [38.113.3.103]) by smtp-out.hotpop.com (Postfix) with SMTP id 64A501567856 for <[e-mail]>; Wed, 10 Aug 2005 11:08:48 +0000 (UTC)
Received: from ALOKLXP (unknown [202.144.106.188]) by smtp-3.hotpop.com (Postfix) with ESMTP id 9010E17AB156 for <[e-mail]>; Wed, 10 Aug 2005 11:08:44 +0000 (UTC)
Message-ID: <027d01c59d9b$d94b4e50$[e-mail]>
From: "Alok" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Wed, 10 Aug 2005 16:38:29 +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: 8abaac9e10c826e8252866cbe6766464
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]

>
> ZA>> I agree that it would be nice if we can achieve the desired behavior
> (i.e. graceful shutdown that eliminates or minimizes packet loss during
BGP
> convergence) using the so called 'trick' implemented only locally (without
> requiring any protocol extensions on the peers). However, such
> implementation must cover the various topologies of interest that are
> presented in the draft.  Again, I would suggest to leave this discussion
on
> possible soutions for the Solutions draft.
>
> The main immediate thing to look at is interaction of above
> implementation trick with the GR draft, maybe GR needs some changes
> to allow it to work nicely with above. Immediate in the "while GR is
> still a draft" sense ;). (this trick has some incompatibilies with GR
> it seems to me. If GR is enabled, the remote peer will assume your
> forwarding plane is staying up, initially at least).
>
> ZA>> Interaction with GR is dependent on the type of solution (trick) that
> gets implemented.  I think we should include this point in the requirement
> draft that any solutions for BGP Graceful Shutdown must consider & ensure
> compatibility with BGP GR (if GR capability is enabled).

Can someone please figure out how one can possibly *know* that there is no
traffic coming from peers?
How about: dont allow shutdown command if interface stats are increasing or
selective links, which can be specified are still up?





_______________________________________________
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 BAA20600 for <[e-mail]>; Wed, 10 Aug 2005 01:36:02 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2jBI-0004Iv-2k; Wed, 10 Aug 2005 01:31:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2jBG-0004Il-2C; Wed, 10 Aug 2005 01:31:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07184; Wed, 10 Aug 2005 01:31:09 -0400 (EDT)
From: [e-mail]
Received: from mx3.equant.com ([199.184.38.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2jjJ-0001zB-0p; Wed, 10 Aug 2005 02:06:21 -0400
Received: from us-res-dms2.domino.globalone.net (mail.internal.equant.com [199.184.38.65]) by mx3.equant.com  with ESMTP id j7A5UlHT003460; Wed, 10 Aug 2005 01:30:49 -0400 (EDT)
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
To: Paul Jakma <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <[e-mail]>
Date: Wed, 10 Aug 2005 01:30:45 -0400
X-MIMETrack: Serialize by Router on US-Res-DMS2/Servers/GlobalOne(5012HF429 | October 14, 2003) at 08/10/2005 01:30:49 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Cc: DECRAENE Bruno RD-CORE-ISS <[e-mail]>, [e-mail], [e-mail], Olivier Bonaventure <[e-mail]>, vijay gill <[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]

Pls see some comments inline.
cheers,
Zubair

Zubair Ahmad
Equant - Network Technology & Architecture
13775 McLearen Road, Oak Hill VA
Phone: [phone]



                                                                                                                                       
            Paul Jakma <[e-mail]>                                                                                                 
            Sent by: [e-mail]                                                                                              
            08/09/2005 03:46 PM                To: DECRAENE Bruno RD-CORE-ISS <[e-mail]>                       
                                               cc: [e-mail], vijay gill <[e-mail]>, Olivier Bonaventure                 
                                                  <[e-mail]>                                                         
                                               bcc:                                                                                    
                                               Subject:  RE: [idr] BGP planned maintenance requirements as an IDR WG doc               
                                                                                                                                       
                                                                                                                                       




On Tue, 9 Aug 2005, DECRAENE Bruno RD-CORE-ISS wrote:

> And signaling the future unreachability of some destinations before
> closing the BGP session could be part of the BGP signaling.

Just to reiterate points made already (given above comment suggets it
doesn't seem to have gotten through):

- Means for signalling /already/ exist within BGP, either:
      - (NOTIFY,CEASE), an implicit withdraw of all advertised routes
           as per normal when you shutdown a session.
      - obviously, withdrawing individual specific prefixes

- Hence: No support in protocol is directly required for an
   implementation to signal shutdown well before it actually performs
   its shut down

ZA>> Well the signalling of maintenance action is definitely needed.
However, it may rely on implicit BGP behavior (such as implicit Withdraw as
you mention).  The draft already clearly mentions that such signalling
mechanism may be either "implicit" or "explicit" (see section 4 - Goals &
Requirements).  Since this is only a requirements draft, I believe we
should better focus on clarifying and refining the requirements for planned
maintenance and leave the discussion about potential solutions for the next
step (solution proposal/draft)..

There is no /immediate/ need for protocol changes for the one "trick"
we've discussed here so far.

The route-reflector case you raised is a different thing imho,
requires full-reflection really and there are other drafts looking at
that.

ZA>> I agree that it would be nice if we can achieve the desired behavior
(i.e. graceful shutdown that eliminates or minimizes packet loss during BGP
convergence) using the so called 'trick' implemented only locally (without
requiring any protocol extensions on the peers). However, such
implementation must cover the various topologies of interest that are
presented in the draft.  Again, I would suggest to leave this discussion on
possible soutions for the Solutions draft.

The main immediate thing to look at is interaction of above
implementation trick with the GR draft, maybe GR needs some changes
to allow it to work nicely with above. Immediate in the "while GR is
still a draft" sense ;). (this trick has some incompatibilies with GR
it seems to me. If GR is enabled, the remote peer will assume your
forwarding plane is staying up, initially at least).

ZA>> Interaction with GR is dependent on the type of solution (trick) that
gets implemented.  I think we should include this point in the requirement
draft that any solutions for BGP Graceful Shutdown must consider & ensure
compatibility with BGP GR (if GR capability is enabled).

Other considerations:

- The delay between signalling shutdown and shutting down forwarding
probably should be larger than the time for all routers in your iBGP
to converge on the new set of routes, not the time for your immediate
peers. This delay factor is likely something an operator can
empirically determine for themselves. It may be interesting to
examine how the protocol could determine this automatically at some
stage in the future (once the 'trick' is implemented widely and there
is experience of it).

- Another thing to consider (or even, is being actively considered by
others, at least for IGP) is stuff like that 'Ordered FIB removal'
work and whether some of its tricks could apply to iBGP. Eg, as we've
discussed that shutdown of protocol should ideally occur before
forwarding shutdown, that draft also suggests that on starting up it
might be a good idea to 'listen but not speak' initially, before
proceeding to announce anything (self-originated or not). Ie
stabilise your forwarding plane first, before telling anyone they may
forward through you (maybe).

I suspect right now what is needed are implementations of the 'wait
between CEASE and forwarding shutdown' and field experience of it,
given no protocol work is actually needed, before proceeding
contemplating what actual protocol changes/additions would or would
not be useful.

I.e., right now, this is probably something to discuss with your
vendor, no?

regards,
--
Paul Jakma  [e-mail]     [e-mail]    Key ID: 64A2FF6A
Fortune:
If *I* had a hammer, there'd be no more folk singers.

_______________________________________________
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 PAA04330 for <[e-mail]>; Tue, 9 Aug 2005 15:47:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2a3f-0007sJ-IU; Tue, 09 Aug 2005 15:46:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2a3d-0007sB-AH for [e-mail]; Tue, 09 Aug 2005 15:46:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03458 for <[e-mail]>; Tue, 9 Aug 2005 15:46:38 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX18/24pogyBb1iq9qnm3ygQJNcQ2iTVdp0k=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2abZ-0002VU-Et for [e-mail]; Tue, 09 Aug 2005 16:21:47 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j79JkBYX020194; Tue, 9 Aug 2005 20:46:14 +0100
Date: Tue, 9 Aug 2005 20:46:09 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: DECRAENE Bruno RD-CORE-ISS <[e-mail]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mail-Copies-To: [e-mail]
Mail-Followup-To: [e-mail]
X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: [e-mail], vijay gill <[e-mail]>, Olivier Bonaventure <[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 Tue, 9 Aug 2005, DECRAENE Bruno RD-CORE-ISS wrote:

> And signaling the future unreachability of some destinations before
> closing the BGP session could be part of the BGP signaling.

Just to reiterate points made already (given above comment suggets it 
doesn't seem to have gotten through):

- Means for signalling /already/ exist within BGP, either:
 	- (NOTIFY,CEASE), an implicit withdraw of all advertised routes
           as per normal when you shutdown a session.
 	- obviously, withdrawing individual specific prefixes

- Hence: No support in protocol is directly required for an
   implementation to signal shutdown well before it actually performs
   its shut down

There is no /immediate/ need for protocol changes for the one "trick" 
we've discussed here so far.

The route-reflector case you raised is a different thing imho, 
requires full-reflection really and there are other drafts looking at 
that.

The main immediate thing to look at is interaction of above 
implementation trick with the GR draft, maybe GR needs some changes 
to allow it to work nicely with above. Immediate in the "while GR is 
still a draft" sense ;). (this trick has some incompatibilies with GR 
it seems to me. If GR is enabled, the remote peer will assume your 
forwarding plane is staying up, initially at least).

Other considerations:

- The delay between signalling shutdown and shutting down forwarding 
probably should be larger than the time for all routers in your iBGP 
to converge on the new set of routes, not the time for your immediate 
peers. This delay factor is likely something an operator can 
empirically determine for themselves. It may be interesting to 
examine how the protocol could determine this automatically at some 
stage in the future (once the 'trick' is implemented widely and there 
is experience of it).

- Another thing to consider (or even, is being actively considered by 
others, at least for IGP) is stuff like that 'Ordered FIB removal' 
work and whether some of its tricks could apply to iBGP. Eg, as we've 
discussed that shutdown of protocol should ideally occur before 
forwarding shutdown, that draft also suggests that on starting up it 
might be a good idea to 'listen but not speak' initially, before 
proceeding to announce anything (self-originated or not). Ie 
stabilise your forwarding plane first, before telling anyone they may 
forward through you (maybe).

I suspect right now what is needed are implementations of the 'wait 
between CEASE and forwarding shutdown' and field experience of it, 
given no protocol work is actually needed, before proceeding 
contemplating what actual protocol changes/additions would or would 
not be useful.

I.e., right now, this is probably something to discuss with your 
vendor, no?

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
If *I* had a hammer, there'd be no more folk singers.

_______________________________________________
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 OAA00020 for <[e-mail]>; Tue, 9 Aug 2005 14:53:03 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ZAn-0001MU-8M; Tue, 09 Aug 2005 14:50:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ZAl-0001Lg-Gm for [e-mail]; Tue, 09 Aug 2005 14:49:59 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29149 for <[e-mail]>; Tue, 9 Aug 2005 14:49:57 -0400 (EDT)
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Zih-0000uL-OT for [e-mail]; Tue, 09 Aug 2005 15:25:05 -0400
Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211);  Tue, 9 Aug 2005 20:26:03 +0200
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"
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Tue, 9 Aug 2005 20:26:04 +0200
Message-ID: <[e-mail]>
Thread-Topic: [idr] BGP planned maintenance requirements as an IDR WG doc
Thread-Index: AcWdDIfJqwMKQF43RoCBc/NwbkWATgAAONTA
From: "DECRAENE Bruno RD-CORE-ISS" <[e-mail]>
To: "Ted Seely" <[e-mail]>, "vijay gill" <[e-mail]>
X-OriginalArrivalTime: 09 Aug 2005 18:26:03.0818 (UTC) FILETIME=[CCEE80A0:01C59D0F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: [e-mail], Olivier Bonaventure <[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 OAA00020

> > > If you send an email, you warn the human operators. If you send
BGP 
> > > messages, you warn the routers. I would prefer a model where BGP 
> > > routers  can automatically react to planned failures compared to a

> > > model where a human intervention is required to handle a planned
failure elsewhere.
> > >
> >
> > We do a lot of maintenances on our routers and we have a tool that 
> > automatically sends out mail to each contact that is on that 
> > particular router. The reason we do this is that people get irate
when 
> > sessions or traffic flows get disrupted (notice I said people, not 
> > routers) and they would like for prior notification so they aren't 
> > surprised when something alarms on their monitoring system. As
someone 
> > who is on-call, having a BGP session flap will almost always result
in 
> > a page. I'd rather my monitoring desk already be aware that there
will 
> > be an event and therefore, not page me.
> >
> > Also, for major peers etc, it is important to get notification, 
> > because it could be that we are in scheduled jeopardy and as such,
we 
> > can disallow that maintenance if necessary, esp. if we have backup 
> > capacity being down. Eg, one of my peers is upgrading code in 
> > frankfurt, and I'm upgrading code in london and frankfurt is acting
as a backup for london.
> > Having the routers understand the failure is completely useless to
me. 
> > I want people to understand so I can plan around the issue.
> 
> Well said Vijay.  This captures exactly why automation (signalled or
> invoked) can burn you.  Large networks where large amounts of 
> traffic will swing ( 500M to 1G+ ) when circuits go down 
> because of planned events must be coordinated at the human level.

I see two independent steps:
-1- Coordination at the human level using e-mail/phone/fax/letters.
-2- Having the networks/routers/BGP reroute the traffic with minimal
impact/loss.

The draft only deals with step 2. It doesn't mention that step 1 should
be skipped.

Coordination and carefull planification can only be done by humans.
IMO, BGP signaling can be done by routers without human intervention.
And signaling the future unreachability of some destinations before
closing the BGP session could be part of the BGP signaling. 

_______________________________________________
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 OAA25992 for <[e-mail]>; Tue, 9 Aug 2005 14:02:04 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2YQ4-0006i1-Kj; Tue, 09 Aug 2005 14:01:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2YQ3-0006eP-5k for [e-mail]; Tue, 09 Aug 2005 14:01:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26468 for <[e-mail]>; Tue, 9 Aug 2005 14:01:41 -0400 (EDT)
Received: from ibogw-fw2.sprintlink.net ([199.0.233.3] helo=elle.res.sprintlink.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Yxz-00082h-AN for [e-mail]; Tue, 09 Aug 2005 14:36:48 -0400
Received: from iscserv1.res.sprintlink.net (iscserv1.res.sprintlink.net [199.0.237.253]) by elle.res.sprintlink.net (8.11.6+Sun/8.11.6) with ESMTP id j79Ht0Q26993; Tue, 9 Aug 2005 13:55:00 -0400 (EDT)
Received: from localhost (tseely@localhost) by iscserv1.res.sprintlink.net (8.8.8+Sun/8.6.12) with ESMTP id OAA23545; Tue, 9 Aug 2005 14:01:18 -0400 (EDT)
X-Authentication-Warning: iscserv1.res.sprintlink.net: tseely owned process doing -bs
Date: Tue, 9 Aug 2005 14:01:17 -0400 (EDT)
From: Ted Seely <[e-mail]>
X-X-Sender: <tseely@iscserv1>
To: vijay gill <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
In-Reply-To: <[e-mail]>
Message-ID: <Pine.GSO.4.33.0508091357400.16307-100000@iscserv1>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: [e-mail], Olivier Bonaventure <[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, 8 Aug 2005, vijay gill wrote:

> Olivier Bonaventure wrote:
>
> >
> >
> > If you send an email, you warn the human operators. If you send BGP
> > messages, you warn the routers. I would prefer a model where BGP routers
> >  can automatically react to planned failures compared to a model where a
> > human intervention is required to handle a planned failure elsewhere.
> >
>
> We do a lot of maintenances on our routers and we have a tool that
> automatically sends out mail to each contact that is on that particular
> router. The reason we do this is that people get irate when sessions or
> traffic flows get disrupted (notice I said people, not routers) and they
> would like for prior notification so they aren't surprised when
> something alarms on their monitoring system. As someone who is on-call,
> having a BGP session flap will almost always result in a page. I'd
> rather my monitoring desk already be aware that there will be an event
> and therefore, not page me.
>
> Also, for major peers etc, it is important to get notification, because
> it could be that we are in scheduled jeopardy and as such, we can
> disallow that maintenance if necessary, esp. if we have backup capacity
> being down. Eg, one of my peers is upgrading code in frankfurt, and I'm
> upgrading code in london and frankfurt is acting as a backup for london.
> Having the routers understand the failure is completely useless to me. I
> want people to understand so I can plan around the issue.

Well said Vijay.  This captures exactly why automation (signalled or
invoked) can burn you.  Large networks where large amounts of traffic
will swing ( 500M to 1G+ ) when circuits go down because of planned events
must be coordinated at the human level.

-ted

>
> /vijay
>
> _______________________________________________
> 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 KAA11181 for <[e-mail]>; Tue, 9 Aug 2005 10:53:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VRJ-00088Q-6W; Tue, 09 Aug 2005 10:50:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VRH-00088H-KG for [e-mail]; Tue, 09 Aug 2005 10:50:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12753 for <[e-mail]>; Tue, 9 Aug 2005 10:50:45 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2VzC-0001sR-0I for [e-mail]; Tue, 09 Aug 2005 11:25:51 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j79EoU934765;  Tue, 9 Aug 2005 07:50:30 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j79EoPG75122; Tue, 9 Aug 2005 07:50:25 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Enke Chen <[e-mail]>
Subject: Re: [Idr] IDR WG Minutes 
In-Reply-To: Your message of "Mon, 08 Aug 2005 21:46:41 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 09 Aug 2005 07:50:25 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
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]

Enke,

> Hi, Yakov:
> 
> One comment below.
> 
> Yakov Rekhter wrote:
> 
> >Folks,
> >
> >Attached are the minutes. Please review for correctness *before*
> >end of this week.
> >
> >Yakov.
> >-------------------------------------------------------------------
> >
> >IDR WG notes 2005.08.04 -DWard
> >-------------------------
> >
> >Doc status
> >see ppt
> >
> >Danny McPherson to finish Confed implementation report in one month
> >
> >Geoff Houston to complete 4-octet AS number space
> >  
> >
> Some words are missing here - I believe that this one refers to the 
> "implementation report for the 4-octet AS Number".

Correct.

Yakov.

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA07475 for <[e-mail]>; Tue, 9 Aug 2005 03:44:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2OmD-0000pO-MA; Tue, 09 Aug 2005 03:43:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2OmC-0000oU-4U for [e-mail]; Tue, 09 Aug 2005 03:43:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18973 for <[e-mail]>; Tue, 9 Aug 2005 03:43:54 -0400 (EDT)
Received: from bay17-f21.bay17.hotmail.com ([64.4.43.71] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2PK0-0006TW-MM for [e-mail]; Tue, 09 Aug 2005 04:18:56 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Aug 2005 00:43:40 -0700
Message-ID: <[e-mail]>
Received: from 209.170.95.212 by by17fd.bay17.hotmail.msn.com with HTTP; Tue, 09 Aug 2005 07:43:40 GMT
X-Originating-IP: [202.144.106.188]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
In-Reply-To: <[e-mail]>
From: "john smith" <[e-mail]>
To: [e-mail]
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Tue, 09 Aug 2005 07:43:40 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 09 Aug 2005 07:43:40.0937 (UTC) FILETIME=[0F959790:01C59CB6]
X-Spam-Score: 1.6 (+)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
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]

well all said and done,
I know atleast one router vendor who could possibly consider using the 
"rollback" feature to achieve this.


>From: vijay gill <[e-mail]>
>To: Olivier Bonaventure <[e-mail]>
>CC: [e-mail]
>Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
>Date: Mon, 08 Aug 2005 22:47:51 -0400

>
>Also, for major peers etc, it is important to get notification, because it 
>could be that we are in scheduled jeopardy and as such, we can disallow 
>that maintenance if necessary, esp. if we have backup capacity being down. 
>Eg, one of my peers is upgrading code in frankfurt, and I'm upgrading code 
>in london and frankfurt is acting as a backup for london. Having the 
>routers understand the failure is completely useless to me. I want people 
>to understand so I can plan around the issue.
>
>/vijay
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/idr

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/


_______________________________________________
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 AAA23547 for <[e-mail]>; Tue, 9 Aug 2005 00:50:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2M0z-0006ZS-5k; Tue, 09 Aug 2005 00:47:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2M0v-0006W5-Cg for [e-mail]; Tue, 09 Aug 2005 00:46:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28412 for <[e-mail]>; Tue, 9 Aug 2005 00:46:54 -0400 (EDT)
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.43) id 1E2MYf-0001uD-IR for [e-mail]; Tue, 09 Aug 2005 01:21:55 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Aug 2005 21:46:42 -0700
X-IronPort-AV: i="3.96,90,1122879600";  d="scan'208"; a="330343850:sNHT29653350"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j794kZQQ014865; Mon, 8 Aug 2005 21:46:39 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 21:46:38 -0700
Received: from [10.21.145.162] ([10.21.145.162]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 21:46:37 -0700
Message-ID: <[e-mail]>
Date: Mon, 08 Aug 2005 21:46:41 -0700
From: Enke Chen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Yakov Rekhter <[e-mail]>
Subject: Re: [Idr] IDR WG Minutes
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Aug 2005 04:46:37.0784 (UTC) FILETIME=[53B11580:01C59C9D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
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]

Hi, Yakov:

One comment below.

Yakov Rekhter wrote:

>Folks,
>
>Attached are the minutes. Please review for correctness *before*
>end of this week.
>
>Yakov.
>-------------------------------------------------------------------
>
>IDR WG notes 2005.08.04 -DWard
>-------------------------
>
>Doc status
>see ppt
>
>Danny McPherson to finish Confed implementation report in one month
>
>Geoff Houston to complete 4-octet AS number space
>  
>
Some words are missing here - I believe that this one refers to the 
"implementation report for the 4-octet AS Number".

-- 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 WAA13984 for <[e-mail]>; Mon, 8 Aug 2005 22:49:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2KAL-0006Pf-NQ; Mon, 08 Aug 2005 22:48:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2KAJ-0006OM-Ux for [e-mail]; Mon, 08 Aug 2005 22:48:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24385 for <[e-mail]>; Mon, 8 Aug 2005 22:48:29 -0400 (EDT)
Received: from challah.msrl.com ([198.137.194.222]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Ki7-0007jb-4o for [e-mail]; Mon, 08 Aug 2005 23:23:29 -0400
Received: (qmail 2739 invoked by uid 211); 9 Aug 2005 02:47:58 -0000
Received: from challah.msrl.com (HELO ?127.0.0.1?) (vgill@198.137.194.222) by challah.msrl.com with RC4-MD5 encrypted SMTP; 9 Aug 2005 02:47:58 -0000
Message-ID: <[e-mail]>
Date: Mon, 08 Aug 2005 22:47:51 -0400
From: vijay gill <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Olivier Bonaventure <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
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]

Olivier Bonaventure wrote:

> 
> 
> If you send an email, you warn the human operators. If you send BGP
> messages, you warn the routers. I would prefer a model where BGP routers
>  can automatically react to planned failures compared to a model where a
> human intervention is required to handle a planned failure elsewhere.
> 

We do a lot of maintenances on our routers and we have a tool that 
automatically sends out mail to each contact that is on that particular 
router. The reason we do this is that people get irate when sessions or 
traffic flows get disrupted (notice I said people, not routers) and they 
would like for prior notification so they aren't surprised when 
something alarms on their monitoring system. As someone who is on-call, 
having a BGP session flap will almost always result in a page. I'd 
rather my monitoring desk already be aware that there will be an event 
and therefore, not page me.

Also, for major peers etc, it is important to get notification, because 
it could be that we are in scheduled jeopardy and as such, we can 
disallow that maintenance if necessary, esp. if we have backup capacity 
being down. Eg, one of my peers is upgrading code in frankfurt, and I'm 
upgrading code in london and frankfurt is acting as a backup for london. 
Having the routers understand the failure is completely useless to me. I 
want people to understand so I can plan around the issue.

/vijay

_______________________________________________
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 RAA20088 for <[e-mail]>; Mon, 8 Aug 2005 17:48:20 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2FQF-0006h5-Fr; Mon, 08 Aug 2005 17:44:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2FQC-0006gv-Uf for [e-mail]; Mon, 08 Aug 2005 17:44:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26605 for <[e-mail]>; Mon, 8 Aug 2005 17:44:34 -0400 (EDT)
Received: from bay17-f20.bay17.hotmail.com ([64.4.43.70] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Fxt-0007rR-7g for [e-mail]; Mon, 08 Aug 2005 18:19:31 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 Aug 2005 14:44:21 -0700
Message-ID: <[e-mail]>
Received: from 80.15.249.164 by by17fd.bay17.hotmail.msn.com with HTTP; Mon, 08 Aug 2005 21:44:21 GMT
X-Originating-IP: [59.92.135.201]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
In-Reply-To: <[e-mail]>
From: "john smith" <[e-mail]>
To: [e-mail]
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 08 Aug 2005 21:44:21 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 08 Aug 2005 21:44:21.0117 (UTC) FILETIME=[55DC82D0:01C59C62]
X-Spam-Score: 4.9 (++++)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
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]

Well  i guess if they say so then they must be right.
Lets go ahead with this feature!! what are we waiting for! :)

>From: Olivier Bonaventure <[e-mail]>
>To: john smith <[e-mail]>
>CC: [e-mail], [e-mail]
>Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
>Date: Mon, 08 Aug 2005 23:22:39 +0200
>
>John,
>
> >
> >> All those solutions try to avoid as much as possible packet losses. The
> >> document proposed by Nicolas and Bruno is another useful step in this
> >> direction. Reacting to planned failures is important as measurements
> >> done in ISP networks have shown that a large fraction of the failures
> >> are indeed planned.
> >>
> >
> > Please let me know which is the institute invests time and money only to
> > come to a conclusion that "failures are planned".
> > I would like to see the data and their defination of a so called
> > "planned failure". :)
>
>Basically, they assumed that if the failures occur during maintenance
>hours they are caused by manual operations and thus are planned. See e.g. :
>http://www.cambridge.intel-research.net/~gianluca/talks/icnp-tutorial.pdf
>, slide 61
>
>http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-routing-fcp.pdf,
>slide 5
>
>
> >
> >> Another point to consider when evaluating this document is the
> >> following. Today, most operators perform their maintenance operations
> >> early in the morning, e.g. 4-6 am to reduce the impact of the
> >> maintenance. From a human ressource viewpoint, this implies that 
>special
> >> staff is required during the night shift. This increases the costs of
> >> the ISP. If it was possible to perform maintenance operations during 
>the
> >> day *without impacting traffic and causing any packet loss*, I'm sure
> >> that ISPs would prefer to perform their maintenace during the day while
> >> all the engineers are available to react in case of problems.
> >
> >
> > How has the time of day got anything to do with the matter? Your peers
> > will never be able to rewrite their policies in 3 minutes, whether you
> > perform the "planned failure" at 2am or 2pm. You would have to give them
> > a few hours of prior notification.
>
>You assume that the peer should perform manual operations to handle the
>planned failure. I would prefer a solution where the BGP routers in the
>peer automatically adapt to the planned failure.
>
> >
> >> This would
> >> require the ability  to change any configuration without causing any
> >> packet loss. Nicolas and Bruno's draft are one step in this direction
> >> for eBGP.
> >>
> >
> > I think I just pointed out above how a just a few minutes of warning can
> > lead to packet loss. While I do understand what you are trying to say, I
> > do not get why you feel signalling a "planned failure" gives one any
> > greater advantage than sending an email?
> >
>
>If you send an email, you warn the human operators. If you send BGP
>messages, you warn the routers. I would prefer a model where BGP routers
>  can automatically react to planned failures compared to a model where a
>human intervention is required to handle a planned failure elsewhere.
>
>
>
>Olivier

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.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 RAA18142 for <[e-mail]>; Mon, 8 Aug 2005 17:24:13 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2F4b-0006lY-Ps; Mon, 08 Aug 2005 17:22:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2F4Z-0006lN-Ty for [e-mail]; Mon, 08 Aug 2005 17:22:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25573 for <[e-mail]>; Mon, 8 Aug 2005 17:22:13 -0400 (EDT)
Received: from astrolabe.info.ucl.ac.be ([130.104.229.109] helo=info.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2FcL-0007Fo-1m for [e-mail]; Mon, 08 Aug 2005 17:57:10 -0400
Received: from [127.0.0.1] (bismarck [130.104.229.58]) by info.ucl.ac.be (8.12.11/8.12.11) with ESMTP id j78LM8ra009409; Mon, 8 Aug 2005 23:22:08 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Mon, 08 Aug 2005 23:22:39 +0200
From: Olivier Bonaventure <[e-mail]>
User-Agent: Debian Thunderbird 1.0.2 (X11/20050331)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: john smith <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-INGI-MailScanner-Information: Please contact the ISP for more information
X-INGI-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: 7bit
Cc: [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]

John,

> 
>> All those solutions try to avoid as much as possible packet losses. The
>> document proposed by Nicolas and Bruno is another useful step in this
>> direction. Reacting to planned failures is important as measurements
>> done in ISP networks have shown that a large fraction of the failures
>> are indeed planned.
>>
> 
> Please let me know which is the institute invests time and money only to
> come to a conclusion that "failures are planned".
> I would like to see the data and their defination of a so called
> "planned failure". :)

Basically, they assumed that if the failures occur during maintenance
hours they are caused by manual operations and thus are planned. See e.g. :
http://www.cambridge.intel-research.net/~gianluca/talks/icnp-tutorial.pdf
, slide 61

http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-routing-fcp.pdf,
slide 5


> 
>> Another point to consider when evaluating this document is the
>> following. Today, most operators perform their maintenance operations
>> early in the morning, e.g. 4-6 am to reduce the impact of the
>> maintenance. From a human ressource viewpoint, this implies that special
>> staff is required during the night shift. This increases the costs of
>> the ISP. If it was possible to perform maintenance operations during the
>> day *without impacting traffic and causing any packet loss*, I'm sure
>> that ISPs would prefer to perform their maintenace during the day while
>> all the engineers are available to react in case of problems.
> 
> 
> How has the time of day got anything to do with the matter? Your peers
> will never be able to rewrite their policies in 3 minutes, whether you
> perform the "planned failure" at 2am or 2pm. You would have to give them
> a few hours of prior notification.

You assume that the peer should perform manual operations to handle the
planned failure. I would prefer a solution where the BGP routers in the
peer automatically adapt to the planned failure.

> 
>> This would
>> require the ability  to change any configuration without causing any
>> packet loss. Nicolas and Bruno's draft are one step in this direction
>> for eBGP.
>>
> 
> I think I just pointed out above how a just a few minutes of warning can
> lead to packet loss. While I do understand what you are trying to say, I
> do not get why you feel signalling a "planned failure" gives one any
> greater advantage than sending an email?
> 

If you send an email, you warn the human operators. If you send BGP
messages, you warn the routers. I would prefer a model where BGP routers
 can automatically react to planned failures compared to a model where a
human intervention is required to handle a planned failure elsewhere.



Olivier

_______________________________________________
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 RAA17095 for <[e-mail]>; Mon, 8 Aug 2005 17:11:13 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2EsA-0001dI-OF; Mon, 08 Aug 2005 17:09:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Es6-0001bm-4G for [e-mail]; Mon, 08 Aug 2005 17:09:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25098 for <[e-mail]>; Mon, 8 Aug 2005 17:09:19 -0400 (EDT)
Received: from bay17-f7.bay17.hotmail.com ([64.4.43.57] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2FPm-0006xa-2P for [e-mail]; Mon, 08 Aug 2005 17:44:16 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 Aug 2005 14:09:05 -0700
Message-ID: <[e-mail]>
Received: from 80.15.249.149 by by17fd.bay17.hotmail.msn.com with HTTP; Mon, 08 Aug 2005 21:09:05 GMT
X-Originating-IP: [59.92.135.201]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
In-Reply-To: <[e-mail]>
From: "john smith" <[e-mail]>
To: [e-mail]
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 08 Aug 2005 21:09:05 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 08 Aug 2005 21:09:05.0557 (UTC) FILETIME=[68E3AC50:01C59C5D]
X-Spam-Score: 4.0 (++++)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Cc: [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]

> >
> > What about "his" customers? His SLAs may be more stringent than your
> > SLAs...
> >
> > I would agree with Howard in a way, GROW would be a nice place to bring
> > this up.
> > As far as i know most people rely on exchanging information a few hours
> > prior to a restart.
> >
>
>To understand the requirements from Nicolas and Bruno, we have to
>consider that the Internet has changed. Ten years ago, routing protocols
>were used to support mainly researchers sending best effort packets. For
>those users, loosing ten seconds worth of packets was not a problem.

ok

>
>Today, IP routing protocols are used to support IP and MPLS-based
>networks carrying various types of mission critical data including :
>- Voice over IP
>- Video over IP
>- Virtual Private Networks
>- various types of leased line emulation

ok

>
>For many of those services, SPs are pushed by their customers to offer
>stringent Service Level Agreements. If those SLAs are not met, the
>customer is often eligible for a refund. To avoid losing packets,
>Service Providers use various types of techniques. In the data plane,
>marking, scheduling, buffer acceptance are commonly used to favor
>important packets over others. In the control plane, several approaches
>are used :
>- tune the implementation of the routing protocols to achieve sub-second
>convergence. This is possible with ISIS/OSPF, but is more challenging
>with BGP
>- use MPLS-based fast reroute techniques to protect important LSPs in
>case of failures
>- develope IP-based fast reroute techniques to provide similar
>mechanisms for pure IP networks
>

ok.

>All those solutions try to avoid as much as possible packet losses. The
>document proposed by Nicolas and Bruno is another useful step in this
>direction. Reacting to planned failures is important as measurements
>done in ISP networks have shown that a large fraction of the failures
>are indeed planned.
>

Please let me know which is the institute invests time and money only to 
come to a conclusion that "failures are planned".
I would like to see the data and their defination of a so called "planned 
failure". :)


>Another point to consider when evaluating this document is the
>following. Today, most operators perform their maintenance operations
>early in the morning, e.g. 4-6 am to reduce the impact of the
>maintenance. From a human ressource viewpoint, this implies that special
>staff is required during the night shift. This increases the costs of
>the ISP. If it was possible to perform maintenance operations during the
>day *without impacting traffic and causing any packet loss*, I'm sure
>that ISPs would prefer to perform their maintenace during the day while
>all the engineers are available to react in case of problems.

How has the time of day got anything to do with the matter? Your peers will 
never be able to rewrite their policies in 3 minutes, whether you perform 
the "planned failure" at 2am or 2pm. You would have to give them a few hours 
of prior notification.


>This would
>require the ability  to change any configuration without causing any
>packet loss. Nicolas and Bruno's draft are one step in this direction
>for eBGP.
>

I think I just pointed out above how a just a few minutes of warning can 
lead to packet loss. While I do understand what you are trying to say, I do 
not get why you feel signalling a "planned failure" gives one any greater 
advantage than sending an email?

>
>Best regards,
>
>
>Olivier
>
>
>
>
>--
>CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/
^^^^^^^^^^^^^^^^

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


_______________________________________________
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 QAA15144 for <[e-mail]>; Mon, 8 Aug 2005 16:45:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ERX-00007W-Tn; Mon, 08 Aug 2005 16:41:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ERT-00007I-Jz for [e-mail]; Mon, 08 Aug 2005 16:41:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23554 for <[e-mail]>; Mon, 8 Aug 2005 16:41:49 -0400 (EDT)
Received: from astrolabe.info.ucl.ac.be ([130.104.229.109] helo=info.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2EzF-0006AF-DM for [e-mail]; Mon, 08 Aug 2005 17:16:45 -0400
Received: from [127.0.0.1] (bismarck [130.104.229.58]) by info.ucl.ac.be (8.12.11/8.12.11) with ESMTP id j78KfZE7007039; Mon, 8 Aug 2005 22:41:37 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Mon, 08 Aug 2005 22:42:06 +0200
From: Olivier Bonaventure <[e-mail]>
User-Agent: Debian Thunderbird 1.0.2 (X11/20050331)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: john smith <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-INGI-MailScanner-Information: Please contact the ISP for more information
X-INGI-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit
Cc: [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]

John,
> 
> What about "his" customers? His SLAs may be more stringent than your
> SLAs...
> 
> I would agree with Howard in a way, GROW would be a nice place to bring
> this up.
> As far as i know most people rely on exchanging information a few hours
> prior to a restart.
> 

To understand the requirements from Nicolas and Bruno, we have to
consider that the Internet has changed. Ten years ago, routing protocols
were used to support mainly researchers sending best effort packets. For
those users, loosing ten seconds worth of packets was not a problem.

Today, IP routing protocols are used to support IP and MPLS-based
networks carrying various types of mission critical data including :
- Voice over IP
- Video over IP
- Virtual Private Networks
- various types of leased line emulation

For many of those services, SPs are pushed by their customers to offer
stringent Service Level Agreements. If those SLAs are not met, the
customer is often eligible for a refund. To avoid losing packets,
Service Providers use various types of techniques. In the data plane,
marking, scheduling, buffer acceptance are commonly used to favor
important packets over others. In the control plane, several approaches
are used :
- tune the implementation of the routing protocols to achieve sub-second
convergence. This is possible with ISIS/OSPF, but is more challenging
with BGP
- use MPLS-based fast reroute techniques to protect important LSPs in
case of failures
- develope IP-based fast reroute techniques to provide similar
mechanisms for pure IP networks

All those solutions try to avoid as much as possible packet losses. The
document proposed by Nicolas and Bruno is another useful step in this
direction. Reacting to planned failures is important as measurements
done in ISP networks have shown that a large fraction of the failures
are indeed planned.

Another point to consider when evaluating this document is the
following. Today, most operators perform their maintenance operations
early in the morning, e.g. 4-6 am to reduce the impact of the
maintenance. From a human ressource viewpoint, this implies that special
staff is required during the night shift. This increases the costs of
the ISP. If it was possible to perform maintenance operations during the
day *without impacting traffic and causing any packet loss*, I'm sure
that ISPs would prefer to perform their maintenace during the day while
all the engineers are available to react in case of problems. This would
require the ability  to change any configuration without causing any
packet loss. Nicolas and Bruno's draft are one step in this direction
for eBGP.


Best regards,


Olivier




-- 
CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/

_______________________________________________
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 QAA13203 for <[e-mail]>; Mon, 8 Aug 2005 16:21:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2E6O-0006st-TB; Mon, 08 Aug 2005 16:20:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2E6N-0006sR-Hv for [e-mail]; Mon, 08 Aug 2005 16:20:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22382 for <[e-mail]>; Mon, 8 Aug 2005 16:20:01 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Ee7-0005YS-8o for [e-mail]; Mon, 08 Aug 2005 16:54:57 -0400
Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 08 Aug 2005 22:19:53 +0200
Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j78KJmVP021581; Mon, 8 Aug 2005 22:19:48 +0200 (MEST)
Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211);  Mon, 8 Aug 2005 22:19:48 +0200
Received: from [10.61.124.212] ([10.61.124.212]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 8 Aug 2005 22:19:47 +0200
Message-ID: <[e-mail]>
Date: Mon, 08 Aug 2005 13:19:44 -0700
From: Robert Raszuk <[e-mail]>
Organization: Signature: http://www.employees.org/~raszuk/sig/
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Jakma <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Aug 2005 20:19:48.0085 (UTC) FILETIME=[86194250:01C59C56]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: DECRAENE Bruno RD-CORE-ISS <[e-mail]>, [e-mail], FONDEVIOLE Benoit RD-CORE-ISS <[e-mail]>, DUBOIS Nicolas ROSI-DAS-ARI <[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]

Paul,

Why do you ever need to shut IBGP session ? Those are to loopbacks and 
you have two choices:

* Take out an entire router (ISIS overload bit or OSPF max age LSA is 
your friend here)

* Take out a line card .. loopback should be still reachable via the IGP.

Cheers,
R.


> On Mon, 8 Aug 2005, DECRAENE Bruno RD-CORE-ISS wrote:
> 
>> - If you have RRs, iBGP routers (including your RR) may not have the 
>> backup path. The RR will propagate the withdraw and the destination 
>> will be removed from the RIB.
> 
> 
> So you'd need some kind of full-reflection extension to BGP...
> 
> regards,



_______________________________________________
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 PAA07194 for <[e-mail]>; Mon, 8 Aug 2005 15:04:07 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2CtS-0005bA-Ay; Mon, 08 Aug 2005 15:02:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2CtR-0005ar-9j for [e-mail]; Mon, 08 Aug 2005 15:02:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09343 for <[e-mail]>; Mon, 8 Aug 2005 15:02:34 -0400 (EDT)
Received: from gateout02.mbox.net ([165.212.64.22] helo=gwo2.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2DR9-0000Qk-CJ for [e-mail]; Mon, 08 Aug 2005 15:37:29 -0400
Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gwo2.mbox.net (Postfix) with SMTP id 0B3EA163812; Mon,  8 Aug 2005 19:02:13 +0000 (GMT)
Received: from gateout02.mbox.net [165.212.64.22] by gateout02.mbox.net via mtad (C8.MAIN.3.17K)  with ESMTP id 875JHHTcm0452Mo2; Mon, 08 Aug 2005 19:02:12 GMT
Received: from gw3.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.21U); Mon, 08 Aug 2005 19:02:12 GMT
X-USANET-Source: 165.212.116.254 IN   [e-mail] gw3.EXCHPROD.USA.NET
X-USANET-MsgId: XID236JHHTcm3465Xo2
Received: from localhost ([65.247.36.31]) by gw3.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211);  Mon, 8 Aug 2005 13:02:10 -0600
Date: Mon, 8 Aug 2005 15:02:09 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Subject: WG Last Call on IANA Considerations (was Re: [Idr] IDR WG Minutes)
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-OriginalArrivalTime: 08 Aug 2005 19:02:10.0551 (UTC) FILETIME=[ADFDF870:01C59C4B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
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, Aug 08, 2005 at 08:06:55AM -0700, Yakov Rekhter wrote:
> SAFI Space Partition
> In reply to Jeff Hass email on list.

Typo on my last name. :-)

> Fenner to send notes on how to alloc SAFI space.
> 
> Proposal: take private use space and turn it into reserved and 
> perhaps 16 or so as private use. Reserved is reserved so we can 
> decide later on FCFS or otherwise managed.
> 
> Are folks using private space? Do we need to skip some?
> 
> Rekhter: How long will it take to use up first come first served?
> 
> Fenner: We should be able to straighten this out quickly and IANA is 
> keeping up. 30 days deadline.
> 
> Danny McPherson: Needs to be uniform across all WGs and Areas. Make 
> it IETF aligned.
> 
> Roque: I do not want to see vendor specific space go away altogether. 

I'll stop here.

If we examine RFC 2434, there's no such thing as "vendor specific space".
Private space means something else.

"Vendor space", I believe, is simply a specific instance of a FCFS
policy .  Arguably, it might even fall under the category of 
"specification required".

If this belief matches what IANA believes is reality, I'll make a 
slightly different proposal for the last call.

Keep 240-255 as "private" or special case 255 as "reserved" with
the usual idea of "keep a 'bit' around for extensions".  This should
provide enough space for experimentation where you don't care
about numbering conflicts (see RFC 2434).

Reserve 224-239.

Extend FCFS all the way up to 223.  Declare victory on SAFI 128
and friends by saying that it was FCFS anyway. :-)

Given what sounds like strong disagreement with "getting rid of vendor
specific space", I'll state for the record that I never objected
to that.  It is my belief that people just misunderstood what "private"
really meant.  FCFS was always the right answer.  IMO, early allocation
should be encouraged for solutions we expect to be widely deployed.

That said, it's just a number.

-- 
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 OAA03481 for <[e-mail]>; Mon, 8 Aug 2005 14:16:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2C95-0007ic-8S; Mon, 08 Aug 2005 14:14:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2C93-0007iW-89 for [e-mail]; Mon, 08 Aug 2005 14:14:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07168 for <[e-mail]>; Mon, 8 Aug 2005 14:14:39 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Cgm-0007hQ-Qc for [e-mail]; Mon, 08 Aug 2005 14:49:34 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j78IEUBm059937; Mon, 8 Aug 2005 11:14:30 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j78IEUG55825; Mon, 8 Aug 2005 11:14:30 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: John Smith <[e-mail]>
Subject: Re: [Idr] IDR WG Minutes 
In-Reply-To: Your message of "Mon, 08 Aug 2005 19:00:48 BST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 08 Aug 2005 11:14:30 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
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]

John,

> > Paul ??: If in ECMP case, what AS sequence? How to pass multiple 
> > paths to a legacy speaker?
> > 
> > Retana:  Cap advert defines who can learn add_path. Other 
> > applications like EBGP ECMP and propagating multiple paths will have 
> > to be addressed.
> > 
> > Retana: Constrained scope.
> 
> I dont think we should be considering proposals that preclude advertising and
> using BGP ECMP routes. More so when the WG is considering taking this up 
> as an item. 

Please repost this point once we'll start a discussion on the mailing
list about this work (I am going to post an e-mail on this topic shortly).

> > Rekhter: We can have as many ad hoc solutions as we want or a more 
> > general solution. We as a group should decide on a more general 
> > solution. We should look at potential new functionality once we have 
> > more than one path being advertised.
> > Suggestion is that the authors of three proposals should find common 
> 
> Which third proposal?

Here are the three proposals (in no particular order):

draft-bhatia-ecmp-routes-in-bgp-01.txt 
draft-zhang-idr-bgp-entire-routes-reflect-00.txt
draft-walton-bgp-add-paths-03.txt

> > solution to all problems that WG would like to address. A mailing 
> > list will be set up to discuss this problem and solution. On the IDR
> > mailing list please identify problems.
> 
> A good step IMO.
> 
> > 
> > Rekhter: Do we need requirements document?
> > 
> > Ward: No, absolutely not.
> 
> John 

Yakov.

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA02824 for <[e-mail]>; Mon, 8 Aug 2005 14:08:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2C1U-0005IF-9I; Mon, 08 Aug 2005 14:06:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2C1S-0005IA-QH for [e-mail]; Mon, 08 Aug 2005 14:06:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06865 for <[e-mail]>; Mon, 8 Aug 2005 14:06:49 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2CZC-0007V2-Bd for [e-mail]; Mon, 08 Aug 2005 14:41:43 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j78I6d910063;  Mon, 8 Aug 2005 11:06:39 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j78I6YG53123; Mon, 8 Aug 2005 11:06:34 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 08 Aug 2005 11:06:34 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: Bill Fenner <[e-mail]>
Subject: [Idr] WG Last Call on IANA Considerations for 2858bis
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Folks,

This is to start the WG Last Call on the proposal from Bill Fenner
to modify the IANA Consideration section of 2858bis along the
following lines:

  - Keep 1-63 as "IETF Consensus/Early Allocation" and 64-127 as "FCFS"
  - Register 128 as "IETF Consensus"
  - Reclassify 129-239 as "Reserved".
  - Retain 240-255 as "private use".
  - As needed, register values in the Reserved range if previously-deployed
    protocols come into the IETF.
  - Recommend that new developments use FCFS or RFC4020 method to get
    code points
  - In the future, if we run out of FCFS or IETF Consensus numbers,
    start using the "Reserved" space as needed.

The modified IANA Consideration section will look as follows:

   As specified in this document, the MP_REACH_NLRI and MP_UNREACH_NLRI
   attributes contain the Subsequence Address Family Identifier (SAFI)
   field. The SAFI name space is defined in this document. The IANA will
   maintain and register values for the SAFI namespace as follows. 
   
   SAFI values 1 and 2 are assigned in this document.  SAFI values
   4 through 63, 65, and 128 are to be assigned by IANA using either
   the "IETF Consensus" policy defined in RFC2434 or the "Early
   IANA Allocation" policy defined in RFC4020. SAFI values 64 and
   66 through 127 are to be assigned by IANA, using the "First  Come
   First Served" policy defined in RFC2434. SAFI values 240 through
   255 are for "private use", and are not to be assigned by IANA.
   SAFI values 0, 3, and 129 through 239 are reserved.

The deadline for comments is Aug 22, 2005.

Yakov.

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA02599 for <[e-mail]>; Mon, 8 Aug 2005 14:05:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Bvo-0002qk-NM; Mon, 08 Aug 2005 14:01:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Bvn-0002qd-MH for [e-mail]; Mon, 08 Aug 2005 14:00:59 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06227 for <[e-mail]>; Mon, 8 Aug 2005 14:00:58 -0400 (EDT)
Received: from web25303.mail.ukl.yahoo.com ([217.12.10.75]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E2CTX-0007F1-2X for [e-mail]; Mon, 08 Aug 2005 14:35:52 -0400
Received: (qmail 62054 invoked by uid 60001); 8 Aug 2005 18:00:48 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Vgzc9SrWb95pMv4hV2lmbnVUEeOmGV1Vj8ImXcbNuYpnFM/reC96k9bqnanzrLinxu98HIhkpIaCY5C0j2jrQGRrU+gjn8n4lJxhnC0DOtMznIzKqFERz5jG8r9n7SyBsZnoBCH1KMKGZcCWN0iQ40L0O4N5rddGf5UB9Jvbxnk= ; 
Message-ID: <[e-mail]>
Received: from [59.92.147.39] by web25303.mail.ukl.yahoo.com via HTTP; Mon, 08 Aug 2005 19:00:48 BST
Date: Mon, 8 Aug 2005 19:00:48 +0100 (BST)
From: John Smith <[e-mail]>
Subject: RE: [Idr] IDR WG Minutes
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 8bit
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]

> Paul ??: If in ECMP case, what AS sequence? How to pass multiple 
> paths to a legacy speaker?
> 
> Retana:  Cap advert defines who can learn add_path. Other 
> applications like EBGP ECMP and propagating multiple paths will have 
> to be addressed.
> 
> Retana: Constrained scope.

I dont think we should be considering proposals that preclude advertising and using BGP
ECMP routes. More so when the WG is considering taking this up as an item. 

> Rekhter: We can have as many ad hoc solutions as we want or a more 
> general solution. We as a group should decide on a more general 
> solution. We should look at potential new functionality once we have 
> more than one path being advertised.
> Suggestion is that the authors of three proposals should find common 

Which third proposal?

> solution to all problems that WG would like to address. A mailing 
> list will be set up to discuss this problem and solution. On the IDR
> mailing list please identify problems.

A good step IMO.

> 
> Rekhter: Do we need requirements document?
> 
> Ward: No, absolutely not.

John 



		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.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 NAA29879 for <[e-mail]>; Mon, 8 Aug 2005 13:31:09 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2BSJ-00019o-PI; Mon, 08 Aug 2005 13:30:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2BSI-00019j-EN for [e-mail]; Mon, 08 Aug 2005 13:30:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04349 for <[e-mail]>; Mon, 8 Aug 2005 13:30:27 -0400 (EDT)
Received: from bay17-f14.bay17.hotmail.com ([64.4.43.64] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Bzw-0006JB-LU for [e-mail]; Mon, 08 Aug 2005 14:05:23 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 Aug 2005 10:30:14 -0700
Message-ID: <[e-mail]>
Received: from 80.15.249.164 by by17fd.bay17.hotmail.msn.com with HTTP; Mon, 08 Aug 2005 17:30:14 GMT
X-Originating-IP: [59.92.135.201]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "john smith" <[e-mail]>
To: [e-mail]
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 08 Aug 2005 17:30:14 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 08 Aug 2005 17:30:14.0486 (UTC) FILETIME=[D6293F60:01C59C3E]
X-Spam-Score: 3.9 (+++)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
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]

What is wrong with tracking the state of the FT :( as specific in the GR
It is not like it is patented or something.....

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


_______________________________________________
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 NAA28071 for <[e-mail]>; Mon, 8 Aug 2005 13:08:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2B5O-0002ND-GR; Mon, 08 Aug 2005 13:06:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2B5N-0002MP-Oh for [e-mail]; Mon, 08 Aug 2005 13:06:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03239 for <[e-mail]>; Mon, 8 Aug 2005 13:06:46 -0400 (EDT)
Received: from ibogw-fw1.sprintlink.net ([199.0.233.3] helo=elle.res.sprintlink.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Bd6-0005i9-RR for [e-mail]; Mon, 08 Aug 2005 13:41:42 -0400
Received: from iscserv1.res.sprintlink.net (iscserv1.res.sprintlink.net [199.0.237.253]) by elle.res.sprintlink.net (8.11.6+Sun/8.11.6) with ESMTP id j78H0DO03171 for <[e-mail]>; Mon, 8 Aug 2005 13:00:13 -0400 (EDT)
Received: from localhost (tseely@localhost) by iscserv1.res.sprintlink.net (8.8.8+Sun/8.6.12) with ESMTP id NAA24921; Mon, 8 Aug 2005 13:06:32 -0400 (EDT)
X-Authentication-Warning: iscserv1.res.sprintlink.net: tseely owned process doing -bs
Date: Mon, 8 Aug 2005 13:06:32 -0400 (EDT)
From: Ted Seely <[e-mail]>
X-X-Sender: <tseely@iscserv1>
To: john smith <[e-mail]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
In-Reply-To: <[e-mail]>
Message-ID: <Pine.GSO.4.33.0508081303590.15695-100000@iscserv1>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
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 Sun, 7 Aug 2005, john smith wrote:

> Hi,
>
> I think if *we know* that a bomb is going to fall on our town at X'oclock,
> we warn everyone to leave town beforehand.... and not wait till the last
> minute and send out a message?
>
> So generally most operators simply send out an "email" to the peering NOCs.
> Practical..no?
>

yes, and we also gracefully bleed the traffic off affected ckt(s) prior
to said scheduled maintenances.

in the case where it is not scheduled, you usually have to wait for the
router to finish booting anyway, so .....  :)  Perhaps one day we'll solve
that problem as well.

-ted



>
> -JS
>
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today it's FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/idr
>



Ted Seely
Principal Network Design Engineer
Internet Engineering - SprintLink
(W) 703.689.6425
(M) 703.967.3289
AIM - wanpro00
Yahoo IM - tseely01

"granular process independence, fault containment, and isolation"


_______________________________________________
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 LAA19447 for <[e-mail]>; Mon, 8 Aug 2005 11:18:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29Ng-0001ZD-Jf; Mon, 08 Aug 2005 11:17:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29Ne-0001Z8-Cz for [e-mail]; Mon, 08 Aug 2005 11:17:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27733 for <[e-mail]>; Mon, 8 Aug 2005 11:17:32 -0400 (EDT)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E29vM-0002hB-AS for [e-mail]; Mon, 08 Aug 2005 11:52:25 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j78FHEu17332; Mon, 8 Aug 2005 18:17:14 +0300
Date: Mon, 8 Aug 2005 18:17:14 +0300 (EEST)
From: Pekka Savola <[e-mail]>
To: Curtis Villamizar <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: DECRAENE Bruno RD-CORE <[e-mail]>, [e-mail], FONDEVIOLE Benoit RD-CORE <[e-mail]>, DUBOIS Nicolas ROSI/DAS/ARI <[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 Sun, 7 Aug 2005, Curtis Villamizar wrote:
> Sorry.  I used to maintain a tier-1 network and I can't see why it
> would be so difficult to change policy to not advertise the EBGP into
> IBGP, then not accept the EBGP, then shut down the EBGP.

There is a wide world beyond tier-1's.  I don't think this is so much 
an issue of clue, but rather the amount of time wasted (and the 
potential for typos and other similar results) when performing manual 
operations.

Where tier-1's might differ from the rest is that maybe they have more 
BGP maintenances that writing scripts etc. to deal with these events 
is worth the effort and their continuing maintenance.

For the rest, all of these actions would need to be done manually. 
Doing so is a pain in the ass.  As an operator of a smaller network, 
I'd certainly be happy to see the implementations move to sane or 
easily configurable default behaviour (which may or may not include 
protocol enhancements).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
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 LAA19163 for <[e-mail]>; Mon, 8 Aug 2005 11:14:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29Jj-0000nU-Dy; Mon, 08 Aug 2005 11:13:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29Jh-0000nJ-T4 for [e-mail]; Mon, 08 Aug 2005 11:13:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27472 for <[e-mail]>; Mon, 8 Aug 2005 11:13:27 -0400 (EDT)
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E29rP-0002Zb-SN for [e-mail]; Mon, 08 Aug 2005 11:48:21 -0400
Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211);  Mon, 8 Aug 2005 17:13:26 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 8 Aug 2005 17:13:25 +0200
Message-ID: <[e-mail]>
Thread-Topic: [idr] BGP planned maintenance requirements as an IDR WG doc
Thread-Index: AcWcKFZhKeUilCQsQoSkgxKFkisWTQAAKLRQ
From: "DECRAENE Bruno RD-CORE-ISS" <[e-mail]>
To: "john smith" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 08 Aug 2005 15:13:26.0259 (UTC) FILETIME=[B9AD3430:01C59C2B]
X-Spam-Score: 1.5 (+)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
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 LAA19163

Let's put it in another way.

BGP needs to advertise the unreachability of some destinations. If BGP
had a minute before the real failure (in the forwarding plane), could it
advertise the unreachability in a way that no (or minimal) packet to
these destination were lost?

A similar topic is discused in rtg-wg with the doc
draft-francois-ordered-fib-00.txt but for the intra-AS case.
 
 
> any vendor has a hook into microsoft outlook calender with BGP? ;-)
> 
> >From: "john smith" <[e-mail]>
> >To: [e-mail], [e-mail]
> >Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG 
> >doc
> >Date: Mon, 08 Aug 2005 14:33:01 +0000
> >
> >Hi,
> >
> >What about "his" customers? His SLAs may be more stringent than your 
> >SLAs...
> >
> >I would agree with Howard in a way, GROW would be a nice 
> place to bring 
> >this up.
> >As far as i know most people rely on exchanging information 
> a few hours 
> >prior to a restart.
> >
> >>From: "DECRAENE Bruno RD-CORE-ISS" 
> <[e-mail]>
> >>To: "john smith" <[e-mail]>,<[e-mail]>
> >>Subject: RE: [idr] BGP planned maintenance requirements as 
> an IDR WG 
> >>doc
> >>Date: Mon, 8 Aug 2005 16:14:10 +0200
> >>
> >> > ....Well but if they are heavy traffic bearing links it would be 
> >> > better to inform your peers a few hours in advance so 
> that he can 
> >> > rewrite his policies.. it is also his $$ after all :-)
> >>
> >>If it's my customer (Internet or VPN) this is my $$ if I 
> broke the SLA.
> >>In a BGP/MPLS VPN situation, if I manage the CE, it's my 
> time/money to 
> >>rewrite it's policy.
> >>
> >>
> >> > >Hi John,
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > > I think if *we know* that a bomb is going to fall on 
> our town 
> >> > > > at X'oclock, we warn everyone to leave town beforehand....
> >> > > > and not wait till the last minute and send out a message?
> >> > >
> >> > >That's exactly our point.
> >> > >We know the forwarding will be shutdown. Why wait the 
> last second 
> >> > >to send a BGP CEASE? Why not inform all your BGP peers a few 
> >> > >seconds/minutes before? In a way that would allow minimal
> >> > packet loss
> >> > >during BGP convergence.
> >> > >
> >> > >
> >> > > > So generally most operators simply send out an 
> "email" to the 
> >> > > > peering NOCs.
> >> > > > Practical..no?
> >> > >
> >> > >Warning the peer is one thing. Shuting down the session with 
> >> > >minimal pack loss is still desirable.
> >> > >
> >> > >In some situation, we don't care about loosing some trafic
> >> > or both NOC
> >> > >we'll write some route map/policy to gracefully reroute the
> >> > packets (or
> >> > >believe so).
> >> > >
> >> > >In some other situation, customers do cares about their 
> SLA, and 
> >> > >modifying the route map each time is too error prone and 
> >> > >time/money consuming.
> >> >
> >> > _________________________________________________________________
> >> > Express yourself instantly with MSN Messenger! Download 
> today it's 
> >> > FREE!
> >> > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> >> >
> >> >
> >
> >_________________________________________________________________
> >Don't just search. Find. Check out the new MSN Search! 
> >http://search.msn.click-url.com/go/onm00200636ave/direct/01/
> >
> >
> >_______________________________________________
> >Idr mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/idr
> 
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today 
> it's FREE! 
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> 
> 
> _______________________________________________
> 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 LAA18695 for <[e-mail]>; Mon, 8 Aug 2005 11:08:56 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29DX-0007Ys-0w; Mon, 08 Aug 2005 11:07:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E29DV-0007XR-PO for [e-mail]; Mon, 08 Aug 2005 11:07:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27194 for <[e-mail]>; Mon, 8 Aug 2005 11:07:03 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E29lE-0002P1-5A for [e-mail]; Mon, 08 Aug 2005 11:41:56 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j78F6uBm053350 for <[e-mail]>; Mon, 8 Aug 2005 08:06:56 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j78F6uG02001 for <[e-mail]>; Mon, 8 Aug 2005 08:06:56 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 08 Aug 2005 08:06:55 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c
Subject: [Idr] IDR WG Minutes
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Folks,

Attached are the minutes. Please review for correctness *before*
end of this week.

Yakov.
-------------------------------------------------------------------

IDR WG notes 2005.08.04 -DWard
-------------------------

Doc status
see ppt

Danny McPherson to finish Confed implementation report in one month

Geoff Houston to complete 4-octet AS number space

New MIB editor see draft

-------------------------
Li AS Hop count Attribute

see ppt for info
Essence: Add TTL to each prefix, decrement at AS boundary
Drop route when TTL hits zero
Transitive attribute

Alt: Distribution Lists
List contains ASs that can rx and cannot exclusion

NOTE: NO_EXPORT and AS_HOPCOUNT can be combined

Houston: is NO_EXPORT dropped or continued when combined?

NOTE:  Can scope 'anycast'

Houston: when aspath prepending, is that expressed in the HOP_COUNT?
Li: Decremented by one always

Hares: Two more ASPATHS per route? How does scaling work?
Li: In the worst case, when setting up a list you can have an 
arbitrary  number in incl or excl list?

Hares: Is order semantics true but,

Rekhter: An ASPATH cannot carry all AS in the internet as not enough space

Li: An avg ASPATH has ~4 AS' in it so, we are going to have on avg 
roughly two X

Hares: Why do you say proxy usage is diffficult in Dist List case? 
TTL is lighter but, why choose between two? Might have both.

Li: From an implementors POV, it is easier to do one and not two

Rekhter: The increase in number of AS' per route is not a practical issue

Houston: At the edge, it may work but, topology is dense and we nee

Jason Schiller (UUNET): Scope - useful in subconfeds ... need  a 
separate counter?

Li: Want to see draft first. Technically what is required is a 
separate attribute but, look almost identical

Houston: When comparing the two mechanisms need to look at "what is 
going on." Distribution lists require complete knowledge of topology. 
Problem is that you cannot insure that they do not leak. HOPCOUNT 
does not have 'knowledge' problem but, focuses on accuracy.

Hares: Inclusion requires enumeration but exclusion does not

Houston: HOPCOUNT allows more specifics w/ a boundary. Advocates HOPCOUNT

Roque: No productive compare the two. Want to select upstream 
provider w/ targeted ext comms. HOPCOUNT might prevent this 
technique. Most common TE technique; customers preferring transit AS' 
per prefix. Not applicable for transit exit scenario. Two issues and 
solutions are orthogonal but, neither solution is devalued.

Chris Morrow (UUNET): proxy means "I can add" and/or "I can delete"

Li: Yes and not violate

Chris; Will it get used if provider ignores or removes

Rekhter: Who is entity that benefits from this? Which SP.

Li: Table size reduction is goal. One SP adds does the work but, gets 
no benefits. Altruism or hope of it is a good reason.

Houston: Zhang drafts in GROW show that altruism is bunk instead 
self-interest. Most UPDATEs come from lower tier points. Most 
computation happens at lower level of peering .. therefore, small 
folks get most thrash. If "I" do this, I help my problem ... 
therefore altruism is there for the folks that use it and tag it.

David Ward: Affect Hop count?

Li: Not significantly as it would be longer prefixes.

Enke: Can we inject an AS numer as 'signature' of who adds attribute?

May be added to draft. No comments

-------------------------
Zhang Renhai Entire Route Reflect

Comments held until after Walton's draft
see ppt for info

-------------------------
Walton Add Paths
Alvaro Retana (Cisco) presenter.
see ppt for info

NOTE: RFC 3107 must be updated

-------------------------
Walton Oscillation Stop
Alvaro Retana (Cisco) presenter
info in same ppt as "Add Paths"

Swallow: What is frequency of oscillation?

Retana: dependent on update timer setting (MIN ADVERT INTERVAL)

Combined questions for both draft authors:
Danny (unaffiliated) - We are increasing and decreasing table size. 
Walton's draft is more general and flexible then Zhang's.

Retana: Most of increase of table size is internal to an AS (almost all)

zhang: I don't understand question.

Zhang: Walton's draft is more general. Because you add attribute, do 
you think that efficiency of packing will be affected?

Retana: NLRI will be bigger but, no impact on packing.

Gargi (Cisco): Zhang's draft - must specify that you explicitly WD 
when a nexthop changes or how to announce new NH?  How do you delete 
the first NH?

Zhang: If NH changes, just add it. To solve the problem there will 
taken offline to email.

Paul ??: If in ECMP case, what AS sequence? How to pass multiple 
paths to a legacy speaker?

Retana:  Cap advert defines who can learn add_path. Other 
applications like EBGP ECMP and propagating multiple paths will have 
to be addressed.

Retana: Constrained scope.

Roque: Although you say impact of deployment is localized. We need a 
better understanding of what impact will be. For each route prefix, 
path attrs in Adj RIB Out. Generally announcement, is only  when 
Adj-RIB-Out changes. What is expectation of propagating changes when 
inbound updates would cause outbound content. What are consequences? 
Size of Adj-RIB-Out? What is key of Adj-RIB-Out? etc.

Retana: Spec says send on path. Change is that we would have tracking 
of two or more paths.

Rekhter: We can have as many ad hoc solutions as we want or a more 
general solution. We as a group should decide on a more general 
solution. We should look at potential new functionality once we have 
more than one path being advertised.
Suggestion is that the authors of three proposals should find common 
solution to all problems that WG would like to address. A mailing 
list will be set up to discuss this problem and solution. On the IDR
mailing list please identify problems.

Rekhter: Do we need requirements document?

Ward: No, absolutely not.

-------------------------
Dubois PM Reqmts

see ppt for info

Rekhter: Send note to list on whether or not we should take as a WG doc.

Dubois: Earlier solution was not meeting requirements and there are 
many possible solutions. We need a solution that fits the 
requirements; we are not encouraging one solution over another:

Ted Seely (Sprint): Why not weight traffic away from peer or 
interface? There are other techniques that don't require change to 
protocol.

Ruediger Volk: I lose traffic when I do this technique.

Ruediger: The convergence problem I see is due to the previous issue 
of config change.

Jason Schiller (UUNET): Is there a hard requirement that this does 
not require a config change ... taken to the list.

-------------------------
Hares Dynamic Confed AS

Not requested to be WG item.
see ppt for info

Roque: I would assume that you would want to do restoration in a 
seamless way. What is motivation to make failure restoration a 
visible outside the confederation?

SKH: Goal is to not drop the peering session. Therefore, the purpose 
is policy rerouting wants to 'hang by itself.' If I drop out of the 
AS confed, I would have had to drop the session.

Roque: Why not just tunnel back?

SKH: No IGP connectivity and tunnels ran into problems.
SKH: will send scenarios to list

Chandra Appanna (Cisco): I think you need a few more failsafes. 
Resend is a MUST, and some mechanisms is nec. that moved did not 
suddenly change. Need to resend routes due to policy change potential.

SKH: We have added failsafe. We delayed resend, it would be abnormal 
to send all routes if nothing changed. Will send scenario in email.

Gargi (Cisco): Are there any mechanisms in mind for NO resend if ones 
moves from one confed to another?

-------------------------
Multisession update - Chandra Appanna

See ppt for info

Added flexibility for any capability code to cause/create multiple sessions

No comments

-------------------------
Kapoor SSA - Gargi, Scott Wainner

see ppt for info

-------------------------
Kapoor Tunnel SAFI

combined w/ SSA preso, same ppt

Gargi did technical side and changes to docs:

more TLVs to express encap:

MPLS, IPsec, GRE in IPsec, L2TPv3 in IPsec

added application scenarios: MPLS over IP tunnels

Scott presented motivations

Combined comments:

SKH: Can you explain status of this mechanism w/in each of these 
groups (on referenced drafts)? What is approved, required, etc. We 
need to see something from those chairs that the ref'ed drafts are 
"blessed."

Scott:  Walked through

Gargi: We have chicken and egg to get this done. Encoding first or 
formats first?

Intro work on L3VPN list.

Rekhter: Very reasonable model where must have both WGs review dependent docs.

Bill Fenner:  Must work w/ other WG for encoding.

Rekhter: Two possible models - first: semantics or encoding need to 
be done in L3VPN
    second: L2/L3VPN WGs tell us semantics and IDR produces codepoints

Rahul:  C/E problem wasn't problem in the past but, applicability. 
Applicability has been cleared up. Now that motivations are clear, 
the multiple proposal should be conjoined. Do work wherever ADs state

Roque: Disagree w/ motivations. IGP can provide reachability. I think 
you use BGP as signaling protocol which is not a problem. But, 
presentation states that BGP needs to know this information. Please 
clarify the layering split.

Rekhter: Can this move to L3VPN

SOLUTION: Joint Last Call in IDR and L3VPN.


-------------------------
SAFI Space Partition
In reply to Jeff Hass email on list.

Fenner to send notes on how to alloc SAFI space.

Proposal: take private use space and turn it into reserved and 
perhaps 16 or so as private use. Reserved is reserved so we can 
decide later on FCFS or otherwise managed.

Are folks using private space? Do we need to skip some?

Rekhter: How long will it take to use up first come first served?

Fenner: We should be able to straighten this out quickly and IANA is 
keeping up. 30 days deadline.

Danny McPherson: Needs to be uniform across all WGs and Areas. Make 
it IETF aligned.

Roque: I do not want to see vendor specific space go away altogether. 
There is much more usage than one case alluded to. Today is only 
practical alternative, cannot be locked out. Can it be shown to work 
before we assume 30 days?

Fenner: There are publications on these agreements and promises that 
it will be done in 30 days. FCFS is you get it now .... no draft, no 
wait.

Chandra; Cannot get rid of vendor space.  AF/SAFI has lost meaning and 
is a way to differentiate addrs between two peers. Just need opaque 
space that we can use between two peers.

Gargi: Must have vendor space perhaps reduced is ok. Second, IANA is 
faster but, it seems to required Routing ADs having lunch w/ IANA.

Rekhter: IANA must have strict 30 days max as rule.

Fenner: We are working on this and the stats show that 30 days is being met.

_______________________________________________
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 KAA17150 for <[e-mail]>; Mon, 8 Aug 2005 10:49:08 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28vA-0001QF-BU; Mon, 08 Aug 2005 10:48:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28v8-0001Pn-39 for [e-mail]; Mon, 08 Aug 2005 10:48:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25961 for <[e-mail]>; Mon, 8 Aug 2005 10:48:03 -0400 (EDT)
Received: from bay17-f33.bay17.hotmail.com ([64.4.43.83] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E29Sp-0001mY-SX for [e-mail]; Mon, 08 Aug 2005 11:22:57 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 Aug 2005 07:47:54 -0700
Message-ID: <[e-mail]>
Received: from 205.161.7.116 by by17fd.bay17.hotmail.msn.com with HTTP; Mon, 08 Aug 2005 14:47:54 GMT
X-Originating-IP: [202.144.106.188]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
In-Reply-To: <[e-mail]>
From: "john smith" <[e-mail]>
To: [e-mail]
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 08 Aug 2005 14:47:54 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 08 Aug 2005 14:47:54.0876 (UTC) FILETIME=[28E6B3C0:01C59C28]
X-Spam-Score: 3.3 (+++)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
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]

any vendor has a hook into microsoft outlook calender with BGP? ;-)

>From: "john smith" <[e-mail]>
>To: [e-mail], [e-mail]
>Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
>Date: Mon, 08 Aug 2005 14:33:01 +0000
>
>Hi,
>
>What about "his" customers? His SLAs may be more stringent than your 
>SLAs...
>
>I would agree with Howard in a way, GROW would be a nice place to bring 
>this up.
>As far as i know most people rely on exchanging information a few hours 
>prior to a restart.
>
>>From: "DECRAENE Bruno RD-CORE-ISS" <[e-mail]>
>>To: "john smith" <[e-mail]>,<[e-mail]>
>>Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
>>Date: Mon, 8 Aug 2005 16:14:10 +0200
>>
>> > ....Well but if they are heavy traffic bearing links it would
>> > be better to inform your peers a few hours in advance so that
>> > he can rewrite his policies.. it is also his $$ after all :-)
>>
>>If it's my customer (Internet or VPN) this is my $$ if I broke the SLA.
>>In a BGP/MPLS VPN situation, if I manage the CE, it's my time/money to
>>rewrite it's policy.
>>
>>
>> > >Hi John,
>> > >
>> > > > Hi,
>> > > >
>> > > > I think if *we know* that a bomb is going to fall on our town at
>> > > > X'oclock, we warn everyone to leave town beforehand....
>> > > > and not wait till the last minute and send out a message?
>> > >
>> > >That's exactly our point.
>> > >We know the forwarding will be shutdown. Why wait the last second to
>> > >send a BGP CEASE? Why not inform all your BGP peers a few
>> > >seconds/minutes before? In a way that would allow minimal
>> > packet loss
>> > >during BGP convergence.
>> > >
>> > >
>> > > > So generally most operators simply send out an "email" to the
>> > > > peering NOCs.
>> > > > Practical..no?
>> > >
>> > >Warning the peer is one thing. Shuting down the session with minimal
>> > >pack loss is still desirable.
>> > >
>> > >In some situation, we don't care about loosing some trafic
>> > or both NOC
>> > >we'll write some route map/policy to gracefully reroute the
>> > packets (or
>> > >believe so).
>> > >
>> > >In some other situation, customers do cares about their SLA, and
>> > >modifying the route map each time is too error prone and time/money
>> > >consuming.
>> >
>> > _________________________________________________________________
>> > Express yourself instantly with MSN Messenger! Download today
>> > it's FREE!
>> > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>> >
>> >
>
>_________________________________________________________________
>Don't just search. Find. Check out the new MSN Search! 
>http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/idr

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


_______________________________________________
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 KAA17026 for <[e-mail]>; Mon, 8 Aug 2005 10:47:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28sf-0000cG-OG; Mon, 08 Aug 2005 10:45:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28se-0000c8-2N for [e-mail]; Mon, 08 Aug 2005 10:45:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25743 for <[e-mail]>; Mon, 8 Aug 2005 10:45:29 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19Ely+YGtczl3yK2OtG99aLeHPrRWTuSxU=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E29QK-0001ha-Gw for [e-mail]; Mon, 08 Aug 2005 11:20:23 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j78EjLcZ001657; Mon, 8 Aug 2005 15:45:25 +0100
Date: Mon, 8 Aug 2005 15:45:19 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: DECRAENE Bruno RD-CORE-ISS <[e-mail]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mail-Copies-To: [e-mail]
Mail-Followup-To: [e-mail]
X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: [e-mail], FONDEVIOLE Benoit RD-CORE-ISS <[e-mail]>, DUBOIS Nicolas ROSI-DAS-ARI <[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, 8 Aug 2005, DECRAENE Bruno RD-CORE-ISS wrote:

> If you *know* the forwarding plane will be shutdown, will not 
> advertising this /before/ the failure?

I'm not terribly familiar with GR - I dont know. I don't /see/ how GR 
allows signalling intent of forwarding state in advance of the 
shutdown, but I could be wrong. You should ask the GR author.

At a guess, there's very little to be gained (in the context of GR 
solely). Signalling a fact (I /did/ keep my forwarding state up) is 
probably better than an intent (I /intend/ to keep my forwarding 
state up).

However, in the context of both GR and a "notify + wait a while" 
optimisation, it might indeed be an idea to consider this, and 
possibly modify GR. Ie to be able to signal intent to take down 
forwarding (an intention easier to satisfy than keeping forwarding 
up).

/Maybe/ this could be satisfied with additional NOTIFY CEASE 
sub-codes? Eg, ADMIN_RESTART (complete restart) and ADMIN_RESTART_BGP 
(restarting only BGP, intend to leave FIB in place). Seems hacky to 
use subcodes for anything other than informational purposes, but 
that's only way really.

> You could:
> -1- warn your peers about the planned maintenance
> -2- keeps FIB & forwarding while BGP convergence
> -3- shut the BGP session as usual.

Yep.

> We hope that a least a significant part of the requirements could be
> fullfilled without protocol extension.

That seems likely.

So the main issue, it seems, is that interaction with GR needs to be 
considered. Which may require interacting additionally with the 
draft-ietf-idr-cease-subcode authors.

> It could work in some situation but if your peers doesn't know 
> about the back up path (because of a RR on the path) you will lose 
> traffic.

That would seem to be a route-reflector issue, best addressed 
seperately?

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
The generation of random numbers is too important to be left to chance.

_______________________________________________
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 KAA16847 for <[e-mail]>; Mon, 8 Aug 2005 10:45:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28pW-0008TX-0u; Mon, 08 Aug 2005 10:42:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28pV-0008TP-15 for [e-mail]; Mon, 08 Aug 2005 10:42:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25594 for <[e-mail]>; Mon, 8 Aug 2005 10:42:14 -0400 (EDT)
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E29ND-0001c2-JR for [e-mail]; Mon, 08 Aug 2005 11:17:08 -0400
Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211);  Mon, 8 Aug 2005 16:41:57 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc 
Date: Mon, 8 Aug 2005 16:41:56 +0200
Message-ID: <[e-mail]>
Thread-Topic: [idr] BGP planned maintenance requirements as an IDR WG doc 
Thread-Index: AcWcAZVnLbzlP0BHRSSuvwlS+lT7ngAIgokQ
From: "DECRAENE Bruno RD-CORE-ISS" <[e-mail]>
To: <[e-mail]>, "DUBOIS Nicolas ROSI-DAS-ARI" <[e-mail]>
X-OriginalArrivalTime: 08 Aug 2005 14:41:57.0630 (UTC) FILETIME=[53F749E0:01C59C27]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Cc: [e-mail], FONDEVIOLE Benoit RD-CORE-ISS <[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 KAA16847

Hi Curtis,

Thanks for your feedback. 
Some comments inlined

> >  
> > Curtis,
> >  
> > Thanks for reading the draft, some comments:
> >  
> > If you've got a 2.5 gig line card and want to upgrade it to 
> a 10 or 40 
> > gig line card, I still think you need to shut down the BGP session 
> > that is running on it and in order to replace the card.
> 
> Only if its an EBGP session.  If its IBGP you don't need to 
> take down anything to replace a card unless your network has 
> no internal redundancy.

OK
 
> For the EBGP session we already have BGP Gracefull Restart 
> but that doesn't cover upgrading if you are going to pull the 
> old card.

OK. 
The draft cover the case when the forwarding cannont be preserved, so
Gracefull Restart cannot be used.
 
> The forwarding that is kept in place during gracefull restart 
> won't be in place while neither card is in the slot.  Are you 
> suggesting that the BGP session should stay up and maintain a 
> black hole while the cards are swapped? 

No. We are suggesting to advertise the planned failure before the
forwarding is shut down. In such a way that no or minimal traffic is
lost.

> I hope not and 
> that's not what I read.
> 
> In this particular example, both providers would bring up the 
> 40 Gig and then bring down the 10 Gig.  Of course since a lot 
> of 40 Gig interfaces are really concatonated 10 Gigs (4 x 
> OC192), in this example they'd add 3 10 gigs with no 
> disruption at all.  Either way no bits are lost if for a time 
> there are two peerings before the old one is shut down.
> Of course if you are out of card slots there are some routers 
> that let you expand the backplane without disruption.  Not 
> all routers do that.

For sure.
Not all routers are even capable of keeping forwarding up during a
control plane switch over...
 
> > Of course you can do it gracefully with some route-map tricks, ...
But 
> > on large operationnal routers it can be quite complex, and it would
be 
> > better to have it automatic and directly embedded in the router
software.
> 
> Sorry.  I used to maintain a tier-1 network and I can't see 
> why it would be so difficult to change policy to not 
> advertise the EBGP into IBGP, then not accept the EBGP, then 
> shut down the EBGP.  Yes, I know that today's NOC staff are 
> not what they used to be but many of our NOC staff were 
> college students who didn't know what BGP was until their on 
> the jub training.  It seems that this would be your best solution.

I don't see the point of doing it manually each time when it can be
automated if we agree on a way to do it and have it implemented.
 
> In the old days some bright operations engineer might write a 
> perl program which given a peering line could write the 
> policy to disable the EBGP to IBGP, then disable the EBGP, 
> then take down the peering.
> The operator could then paste that into the router config.  
> It sounds like what you are asking for is a way for the 
> router to shut down the peering in a similar order but do so 
> automaticly.

Yes.
We're asking for a way to do it with minimal packet loss in all typical
situations. I'm not sure this is that obvious. If you belive it is,
could you please send an URL with the procedure?
And to have it down automaticly by the router itself.

 
> > BTW, graceful restart is really efficient when all (all !) peers are

> > supporting it.If some of the peer are not supporting it, I wouldn't 
> > say it's harmful but ... You never know. I do not know many service 
> > providers who can successfully use it on a large ASBRs 
> currently. In  our case many of our customers and peers do not support
GR even in 
> > helper only mode. So GR is still a "for future use" feature to me.
> 
> The document that you are asking to be considered looks to be 
> just a requirements document.

It is.
It does'nt seems so easy to first agree on the requirement.
 
> What you might be better off advocating is that more routers 
> implement BGP gracefull restart and more or your peers enable 
> it.  In the example you just gave gracefull restart doesn't 
> help.  Given the draft and then the example above, its not 
> clear what problem you are trying to address and what 
> solution you have in mind.  Is it time for me to reread the draft?
> 
> > > If you are taking a router completely out of service you 
> can cost it 
> > > out of the IGP first then take down the EBGP peerings, 
> then shut it 
> > > down.
> >  
> > This is not going to work in all situations.
> 
> Yes but your document adds nothing to improve it.

We raise the issue, which is a first step.

> 
> > Best regards
> > 	
> > Nicolas Dubois
> > Tel :  [phone]	
> 
> Regards,
> 
> Curtis
> 

Regards,
Bruno

_______________________________________________
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 KAA15979 for <[e-mail]>; Mon, 8 Aug 2005 10:34:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28gl-0005bv-KZ; Mon, 08 Aug 2005 10:33:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28gj-0005bq-P8 for [e-mail]; Mon, 08 Aug 2005 10:33:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25006 for <[e-mail]>; Mon, 8 Aug 2005 10:33:11 -0400 (EDT)
Received: from bay17-f35.bay17.hotmail.com ([64.4.43.85] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E29EQ-0001LN-Bu for [e-mail]; Mon, 08 Aug 2005 11:08:04 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 Aug 2005 07:33:01 -0700
Message-ID: <[e-mail]>
Received: from 205.161.7.116 by by17fd.bay17.hotmail.msn.com with HTTP; Mon, 08 Aug 2005 14:33:01 GMT
X-Originating-IP: [202.144.106.188]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
In-Reply-To: <[e-mail]>
From: "john smith" <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 08 Aug 2005 14:33:01 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 08 Aug 2005 14:33:01.0922 (UTC) FILETIME=[14A8BC20:01C59C26]
X-Spam-Score: 3.2 (+++)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
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]

Hi,

What about "his" customers? His SLAs may be more stringent than your SLAs...

I would agree with Howard in a way, GROW would be a nice place to bring this 
up.
As far as i know most people rely on exchanging information a few hours 
prior to a restart.

>From: "DECRAENE Bruno RD-CORE-ISS" <[e-mail]>
>To: "john smith" <[e-mail]>,<[e-mail]>
>Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
>Date: Mon, 8 Aug 2005 16:14:10 +0200
>
> > ....Well but if they are heavy traffic bearing links it would
> > be better to inform your peers a few hours in advance so that
> > he can rewrite his policies.. it is also his $$ after all :-)
>
>If it's my customer (Internet or VPN) this is my $$ if I broke the SLA.
>In a BGP/MPLS VPN situation, if I manage the CE, it's my time/money to
>rewrite it's policy.
>
>
> > >Hi John,
> > >
> > > > Hi,
> > > >
> > > > I think if *we know* that a bomb is going to fall on our town at
> > > > X'oclock, we warn everyone to leave town beforehand....
> > > > and not wait till the last minute and send out a message?
> > >
> > >That's exactly our point.
> > >We know the forwarding will be shutdown. Why wait the last second to
> > >send a BGP CEASE? Why not inform all your BGP peers a few
> > >seconds/minutes before? In a way that would allow minimal
> > packet loss
> > >during BGP convergence.
> > >
> > >
> > > > So generally most operators simply send out an "email" to the
> > > > peering NOCs.
> > > > Practical..no?
> > >
> > >Warning the peer is one thing. Shuting down the session with minimal
> > >pack loss is still desirable.
> > >
> > >In some situation, we don't care about loosing some trafic
> > or both NOC
> > >we'll write some route map/policy to gracefully reroute the
> > packets (or
> > >believe so).
> > >
> > >In some other situation, customers do cares about their SLA, and
> > >modifying the route map each time is too error prone and time/money
> > >consuming.
> >
> > _________________________________________________________________
> > Express yourself instantly with MSN Messenger! Download today
> > it's FREE!
> > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> >
> >

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/


_______________________________________________
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 KAA15574 for <[e-mail]>; Mon, 8 Aug 2005 10:29:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28aM-00031v-Ni; Mon, 08 Aug 2005 10:26:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28aL-00031j-At for [e-mail]; Mon, 08 Aug 2005 10:26:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24491 for <[e-mail]>; Mon, 8 Aug 2005 10:26:35 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2982-00017p-ME for [e-mail]; Mon, 08 Aug 2005 11:01:28 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j78EQJ901338;  Mon, 8 Aug 2005 07:26:19 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j78EQEG94656; Mon, 8 Aug 2005 07:26:14 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Paul Jakma <[e-mail]>
Subject: Re: [Idr] IANA assigned bgp-params mixup 
In-Reply-To: Your message of "Mon, 08 Aug 2005 02:24:12 BST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 08 Aug 2005 07:26:14 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: Inter-Domain Routing List <[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]

Paul,

> Is it my imagination or does:
> 
>  	http://www.iana.org/assignments/bgp-parameters
> 
> have the KEEPALIVE and NOTIFICATION message types the wrong way 
> around?

No, it is not your imagination - it is due to my mistake, as 
in the IANA consideration section of the spec I made a mistake. I am going
to contact IANA to fix this.

Many thanks for pointing this out.

Yakov.

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA14398 for <[e-mail]>; Mon, 8 Aug 2005 10:14:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28ON-0008UU-Fs; Mon, 08 Aug 2005 10:14:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28OL-0008U3-QM for [e-mail]; Mon, 08 Aug 2005 10:14:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23429 for <[e-mail]>; Mon, 8 Aug 2005 10:14:11 -0400 (EDT)
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E28w4-0000p2-5a for [e-mail]; Mon, 08 Aug 2005 10:49:04 -0400
Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211);  Mon, 8 Aug 2005 16:14:11 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 8 Aug 2005 16:14:10 +0200
Message-ID: <[e-mail]>
Thread-Topic: [idr] BGP planned maintenance requirements as an IDR WG doc
Thread-Index: AcWcIT1aReBE2q3cR4awJsCzVoxZCAAAZ64A
From: "DECRAENE Bruno RD-CORE-ISS" <[e-mail]>
To: "john smith" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 08 Aug 2005 14:14:11.0594 (UTC) FILETIME=[72EE5EA0:01C59C23]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
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 KAA14398

> ....Well but if they are heavy traffic bearing links it would 
> be better to inform your peers a few hours in advance so that 
> he can rewrite his policies.. it is also his $$ after all :-)

If it's my customer (Internet or VPN) this is my $$ if I broke the SLA.
In a BGP/MPLS VPN situation, if I manage the CE, it's my time/money to
rewrite it's policy.


> >Hi John,
> >
> > > Hi,
> > >
> > > I think if *we know* that a bomb is going to fall on our town at 
> > > X'oclock, we warn everyone to leave town beforehand....
> > > and not wait till the last minute and send out a message?
> >
> >That's exactly our point.
> >We know the forwarding will be shutdown. Why wait the last second to 
> >send a BGP CEASE? Why not inform all your BGP peers a few 
> >seconds/minutes before? In a way that would allow minimal 
> packet loss 
> >during BGP convergence.
> >
> >
> > > So generally most operators simply send out an "email" to the 
> > > peering NOCs.
> > > Practical..no?
> >
> >Warning the peer is one thing. Shuting down the session with minimal 
> >pack loss is still desirable.
> >
> >In some situation, we don't care about loosing some trafic 
> or both NOC 
> >we'll write some route map/policy to gracefully reroute the 
> packets (or 
> >believe so).
> >
> >In some other situation, customers do cares about their SLA, and 
> >modifying the route map each time is too error prone and time/money 
> >consuming.
> 
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today 
> it's FREE! 
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> 
> 

_______________________________________________
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 KAA14052 for <[e-mail]>; Mon, 8 Aug 2005 10:09:57 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28Jr-0006jG-OG; Mon, 08 Aug 2005 10:09:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E28Jq-0006jB-4u for [e-mail]; Mon, 08 Aug 2005 10:09:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22852 for <[e-mail]>; Mon, 8 Aug 2005 10:09:32 -0400 (EDT)
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E28rX-0000f6-Hc for [e-mail]; Mon, 08 Aug 2005 10:44:24 -0400
Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211);  Mon, 8 Aug 2005 16:09:30 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 8 Aug 2005 16:09:29 +0200
Message-ID: <[e-mail]>
Thread-Topic: [idr] BGP planned maintenance requirements as an IDR WG doc
Thread-Index: AcWbWP2cXLdtqAIiT+CmVsm7ouFlMgAwwwIg
From: "DECRAENE Bruno RD-CORE-ISS" <[e-mail]>
To: "Paul Jakma" <[e-mail]>, "DUBOIS Nicolas ROSI-DAS-ARI" <[e-mail]>
X-OriginalArrivalTime: 08 Aug 2005 14:09:30.0284 (UTC) FILETIME=[CB41DEC0:01C59C22]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: [e-mail], FONDEVIOLE Benoit RD-CORE-ISS <[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 KAA14052

 
> > Basically GR restart is:
> > 	Forwarding plane stays up / control plane says I'll be back.
> 
> Right. Though note that GR specifies a forwarding-state bit, 
> so you can signal to your peer, /after/ the fact (when you 
> bring your session back up), whether or not your forwarding 
> plane stayed up.


If you *know* the forwarding plane will be shutdown, will not
advertising this /before/ the failure?
 
> > Planned maintenance requirement is:
> 
> > 	Forwarding going away, control plane going away / let's do it
> >	gracefully.
> 
> Ok, I guess my question then is what you think can be done 
> for this case, eg /lack/ of graceful-restart capability.

You could:
-1- warn your peers about the planned maintenance
-2- keeps FIB & forwarding while BGP convergence
-3- shut the BGP session as usual.

 
> Further, as above, how can you even reliably distinguish 
> between the two cases above (presuming GR is enabled)?

This is a maintenance situation and the operator knows that the
forwarding plane needs to be shutdown.

> Given 
> the GR draft, you can't determine anything until the peer 
> comes back. Ie, given GR, there is a window of uncertainty 
> where you can not say whether forwarding stayed up or not, 
> you only know when it comes back and you can examine the F 
> bit in the GR capability advertisement for the appropriate AFI/SAFI.
> 
> Something to consider anyway (the interaction of the two).
> 
> A final thought: Does the second case even require any protocol work?

We hope that a least a significant part of the requirements could be
fullfilled without protocol extension.
 
> It strikes me that the second case can easily be handled 
> entirely within the confines of existing specified BGP, by 
> simply having an implementation take the relevant BGP 
> session(s) down (ie sending a
> CEASE) and just waiting a while to let the relevant remote 
> peers update their routes, before proceeding with actually 
> removing the routes from RIB and FIB and then restarting.

It could work in some situation but if your peers doesn't know about the
back up path (because of a RR on the path) you will lose traffic.
 
> I reckon the most protocol work this needs is just to have 
> implementations advertise a "I reckon I need X milliseconds 
> to clear Y number of routes" or even just "Hey, if you're 
> going down, try give me X seconds advance notice if you can" 
> capability, which could be used to supercede any 
> implementation specific default.
> 
> > Best regards,
> >
> > Nicolas Dubois
> > Tel :  [phone]
> 
> regards,
> -- 
> Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
> Fortune:
> Finagle's Seventh Law:
>  	The perversity of the universe tends toward a maximum.
> 

_______________________________________________
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 KAA13506 for <[e-mail]>; Mon, 8 Aug 2005 10:03:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E289E-0003Nr-U1; Mon, 08 Aug 2005 09:58:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E289C-0003NT-Op for [e-mail]; Mon, 08 Aug 2005 09:58:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21742 for <[e-mail]>; Mon, 8 Aug 2005 09:58:32 -0400 (EDT)
Received: from bay17-f42.bay17.hotmail.com ([64.4.43.92] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E28gr-0000IK-0n for [e-mail]; Mon, 08 Aug 2005 10:33:25 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 Aug 2005 06:58:20 -0700
Message-ID: <[e-mail]>
Received: from 67.131.237.19 by by17fd.bay17.hotmail.msn.com with HTTP; Mon, 08 Aug 2005 13:58:20 GMT
X-Originating-IP: [202.144.106.188]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
In-Reply-To: <[e-mail]>
From: "john smith" <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 08 Aug 2005 13:58:20 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 08 Aug 2005 13:58:20.0720 (UTC) FILETIME=[3C2A8300:01C59C21]
X-Spam-Score: 3.2 (+++)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
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]

....Well but if they are heavy traffic bearing links it would be better to 
inform your peers a few hours in advance so that he can rewrite his 
policies.. it is also his $$ after all :-)




>From: "DECRAENE Bruno RD-CORE-ISS" <[e-mail]>
>To: "john smith" <[e-mail]>,<[e-mail]>
>Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
>Date: Mon, 8 Aug 2005 15:12:35 +0200
>
>Hi John,
>
> > Hi,
> >
> > I think if *we know* that a bomb is going to fall on our town
> > at X'oclock, we warn everyone to leave town beforehand....
> > and not wait till the last minute and send out a message?
>
>That's exactly our point.
>We know the forwarding will be shutdown. Why wait the last second to
>send a BGP CEASE? Why not inform all your BGP peers a few
>seconds/minutes before? In a way that would allow minimal packet loss
>during BGP convergence.
>
>
> > So generally most operators simply send out an "email" to the
> > peering NOCs.
> > Practical..no?
>
>Warning the peer is one thing. Shuting down the session with minimal
>pack loss is still desirable.
>
>In some situation, we don't care about loosing some trafic or both NOC
>we'll write some route map/policy to gracefully reroute the packets (or
>believe so).
>
>In some other situation, customers do cares about their SLA, and
>modifying the route map each time is too error prone and time/money
>consuming.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


_______________________________________________
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 JAA09695 for <[e-mail]>; Mon, 8 Aug 2005 09:15:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27S2-0007rH-6i; Mon, 08 Aug 2005 09:13:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27Rz-0007q1-V4 for [e-mail]; Mon, 08 Aug 2005 09:13:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19606 for <[e-mail]>; Mon, 8 Aug 2005 09:13:54 -0400 (EDT)
Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E27zg-0007aa-0G for [e-mail]; Mon, 08 Aug 2005 09:48:46 -0400
Received: from [192.168.0.2] (pcp09296126pcs.arlngt01.va.comcast.net[69.143.165.226]) by comcast.net (rwcrmhc11) with ESMTP id <2005080813133901300drnlpe>; Mon, 8 Aug 2005 13:13:43 +0000
Mime-Version: 1.0
Message-Id: <p06230910bf1d07ef5cd2@[192.168.0.2]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 8 Aug 2005 09:13:31 -0400
To: [e-mail]
From: "Howard C. Berkowitz" <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
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]

Assume, for a moment, that there is a legitimate need for knowing 
when planned maintenance is scheduled. If that is the case, however, 
it would seem that it is as important to know when other critical 
resources will be out of service, ranging from an optical multiplexer 
that handles the physical layer for several BGP speakers, to security 
devices that ensure link level or firewall-to-firewall encryption 
between two ISPs.

The first will clearly affect routing, but would it be handled 
adequately with a BGP Maintenance Planned message for each affected 
router, without a message identifying the common resource? As more 
and more root cause analysis goes into network management systems, 
would it be even more useful to know the multiplexer is going down, 
to know the systems dependent on it, and, when the link goes down, 
suppress the consequential router alarms from the NMS? Again, 
assuming knowledge of related entities, the BGP speakers could 
receive a local signal that a resource on which they depend is going 
down, and to begin graceful shutdown N minutes before the scheduled 
maintenance?

In other words, if this is a good idea for BGP, it would seem a good 
idea for other critical components. The question might be split: is 
the requirement useful, and, if so, what should be the transport 
mechanism for the messages? Given the tendency to overload BGP into a 
generalized signaling method, perhaps the focus in IDR should be on 
the transport and the subset of BGP informational messages.

My sense is that the overall problem is more for the Operations than 
Routing area, and that alternate transport mechanisms should be 
examined. It may well be that the messages should be carried in BGP, 
as the de facto one known intercarrier signaling mechanism, but 
perhaps the BGP implementation should be closer to the OSPF Opaque 
LSA.  Certain messages carried in that manner could be locally 
significant in starting graceful shutdown, or a different operational 
procedure that assumes the forwarding path won't be back in the near 
term.

_______________________________________________
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 JAA09633 for <[e-mail]>; Mon, 8 Aug 2005 09:15:03 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27OA-0007I1-AT; Mon, 08 Aug 2005 09:09:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27O9-0007HC-5W for [e-mail]; Mon, 08 Aug 2005 09:09:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19452 for <[e-mail]>; Mon, 8 Aug 2005 09:09:55 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/5mOLz7cXawfSbh+e+SOd+ay2YXuicO2s=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E27vm-0007TO-GC for [e-mail]; Mon, 08 Aug 2005 09:44:47 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j78D9PQU000402; Mon, 8 Aug 2005 14:09:30 +0100
Date: Mon, 8 Aug 2005 14:09:23 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: DECRAENE Bruno RD-CORE-ISS <[e-mail]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mail-Copies-To: [e-mail]
Mail-Followup-To: [e-mail]
X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: [e-mail], [e-mail], FONDEVIOLE Benoit RD-CORE-ISS <[e-mail]>, DUBOIS Nicolas ROSI-DAS-ARI <[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, 8 Aug 2005, DECRAENE Bruno RD-CORE-ISS wrote:

> - If you have RRs, iBGP routers (including your RR) may not have 
> the backup path. The RR will propagate the withdraw and the 
> destination will be removed from the RIB.

So you'd need some kind of full-reflection extension to BGP...

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
They're giving bank robbing a bad name.
 		-- John Dillinger, on Bonnie and Clyde

_______________________________________________
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 JAA09478 for <[e-mail]>; Mon, 8 Aug 2005 09:13:01 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27Qp-0007WW-Dr; Mon, 08 Aug 2005 09:12:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27Qn-0007WF-Ov for [e-mail]; Mon, 08 Aug 2005 09:12:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19533 for <[e-mail]>; Mon, 8 Aug 2005 09:12:40 -0400 (EDT)
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E27yS-0007Xu-DM for [e-mail]; Mon, 08 Aug 2005 09:47:28 -0400
Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211);  Mon, 8 Aug 2005 15:12:36 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 8 Aug 2005 15:12:35 +0200
Message-ID: <[e-mail]>
Thread-Topic: [idr] BGP planned maintenance requirements as an IDR WG doc
Thread-Index: AcWbW7BuuGriWa7OQPm4jXRD3gQGrQAucnpQ
From: "DECRAENE Bruno RD-CORE-ISS" <[e-mail]>
To: "john smith" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 08 Aug 2005 13:12:36.0383 (UTC) FILETIME=[D869EAF0:01C59C1A]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
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 JAA09478

Hi John,

> Hi,
> 
> I think if *we know* that a bomb is going to fall on our town 
> at X'oclock, we warn everyone to leave town beforehand.... 
> and not wait till the last minute and send out a message?

That's exactly our point.
We know the forwarding will be shutdown. Why wait the last second to
send a BGP CEASE? Why not inform all your BGP peers a few
seconds/minutes before? In a way that would allow minimal packet loss
during BGP convergence.

 
> So generally most operators simply send out an "email" to the 
> peering NOCs.
> Practical..no?

Warning the peer is one thing. Shuting down the session with minimal
pack loss is still desirable.

In some situation, we don't care about loosing some trafic or both NOC
we'll write some route map/policy to gracefully reroute the packets (or
believe so).

In some other situation, customers do cares about their SLA, and
modifying the route map each time is too error prone and time/money
consuming.

_______________________________________________
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 IAA06446 for <[e-mail]>; Mon, 8 Aug 2005 08:34:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E26pT-0006Sx-UJ; Mon, 08 Aug 2005 08:34:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E26pR-0006Ss-Uc for [e-mail]; Mon, 08 Aug 2005 08:34:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17722 for <[e-mail]>; Mon, 8 Aug 2005 08:34:04 -0400 (EDT)
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E27N8-0006Xy-Hc for [e-mail]; Mon, 08 Aug 2005 09:08:55 -0400
Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211);  Mon, 8 Aug 2005 14:34:01 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Mon, 8 Aug 2005 14:33:54 +0200
Message-ID: <[e-mail]>
Thread-Topic: [idr] BGP planned maintenance requirements as an IDR WG doc
Thread-Index: AcWbpj0gjplhR6/KQg+y0q+NRYe+bwAa8ODw
From: "DECRAENE Bruno RD-CORE-ISS" <[e-mail]>
To: <[e-mail]>, "DUBOIS Nicolas ROSI-DAS-ARI" <[e-mail]>
X-OriginalArrivalTime: 08 Aug 2005 12:34:01.0242 (UTC) FILETIME=[747B6FA0:01C59C15]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: [e-mail], FONDEVIOLE Benoit RD-CORE-ISS <[e-mail]>, Paul Jakma <[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 IAA06446

> > A final thought: Does the second case even require any protocol
work?
> > 
> > It strikes me that the second case can easily be handled entirely 
> > within the confines of existing specified BGP, by simply having an 
> > implementation take the relevant BGP session(s) down (ie sending a
> > CEASE) and just waiting a while to let the relevant remote peers 
> > update their routes, before proceeding with actually removing the 
> > routes from RIB and FIB and then restarting.
> > 
> > I reckon the most protocol work this needs is just to have 
> > implementations advertise a "I reckon I need X milliseconds to clear
Y 
> > number of routes" or even just "Hey, if you're going down, try give
me 
> > X seconds advance notice if you can" capability, which could be used

> > to supercede any implementation specific default.
> 
> As this mail is the closest to my line of understanding this 
> problem let me ask a very basic question of course assuming 
> that GR is for "the future" ...
> 
> Would it not be enough to simply withdraw the advertised 
> routes before bringing the session down towards given peer ? 
> If operator enters shutdown on BGP session this should not 
> trigger any immediate BGP/TCP action .. instead one could 
> send MP_UNREACH then at some decent timeout actually bring 
> the sessions down.

It's indeed a possible solution. In fact it's exactly what we proposed
in "draft-dubois-bgp-planned-maintenance-00.txt" in San Diego.
Unfortunately, it's not working for all the iBGP topologies:
- If you have a full iBGP mesh, all your peers already know the backup
path and will select it. So this will work fine.
- If you have RRs, iBGP routers (including your RR) may not have the
backup path. The RR will propagate the withdraw and the destination will
be removed from the RIB. 


> No protocol changes required.

There's lot of possible ways to improve the current eBGP shutdowns.
Could we possibly agree on a solution?
We would all prefer that this solution does require any protocol change.
In that case, a BCP could document the solution.

Then, each ISP could use that solution for each maintenance. Or
preferably, vendors will automate the solution.

> All it would take is a local implementation little twick ;).

That would be fine for me.


Cheers,
Bruno

> 
> Cheers,
> R.
> 

_______________________________________________
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 VAA18447 for <[e-mail]>; Sun, 7 Aug 2005 21:26:01 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1wNM-0003P5-U0; Sun, 07 Aug 2005 21:24:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1wNK-0003N3-GQ for [e-mail]; Sun, 07 Aug 2005 21:24:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09047 for <[e-mail]>; Sun, 7 Aug 2005 21:24:21 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1+x5aiR/qRGgHbI5N/W+PvQdysIUHC1rKc=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1wuu-0007Os-LZ for [e-mail]; Sun, 07 Aug 2005 21:59:06 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j781OEGZ026841 for <[e-mail]>; Mon, 8 Aug 2005 02:24:17 +0100
Date: Mon, 8 Aug 2005 02:24:12 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Inter-Domain Routing List <[e-mail]>
Message-ID: <[e-mail]>
Mail-Copies-To: [e-mail]
Mail-Followup-To: [e-mail]
X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Subject: [Idr] IANA assigned bgp-params mixup
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]

Is it my imagination or does:

 	http://www.iana.org/assignments/bgp-parameters

have the KEEPALIVE and NOTIFICATION message types the wrong way 
around?

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Practically perfect people never permit sentiment to muddle their thinking.
 		-- Mary Poppins

_______________________________________________
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 SAA03302 for <[e-mail]>; Sun, 7 Aug 2005 18:12:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1tMo-0005hK-Fz; Sun, 07 Aug 2005 18:11:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1tMl-0005hC-AK for [e-mail]; Sun, 07 Aug 2005 18:11:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00588 for <[e-mail]>; Sun, 7 Aug 2005 18:11:32 -0400 (EDT)
Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E1tuJ-0003Kk-4A for [e-mail]; Sun, 07 Aug 2005 18:46:17 -0400
Received: (qmail 8722 invoked from network); 7 Aug 2005 22:11:20 -0000
Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 7 Aug 2005 22:11:20 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j77MCkoJ046476; Sun, 7 Aug 2005 18:12:47 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "DUBOIS Nicolas ROSI/DAS/ARI" <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc 
In-reply-to: Your message of "Sun, 07 Aug 2005 14:05:45 +0200." <[e-mail]> 
Date: Sun, 07 Aug 2005 18:12:46 -0400
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: DECRAENE Bruno RD-CORE <[e-mail]>, [e-mail], FONDEVIOLE Benoit RD-CORE <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
"DUBOIS Nicolas ROSI/DAS/ARI" writes:
>  
> Curtis,
>  
> Thanks for reading the draft, some comments:
>  
> If you've got a 2.5 gig line card and want to upgrade it to a 10 or 40 gig
> line card, I still think you need to shut down the BGP session that is
> running on it and in order to replace the card.

Only if its an EBGP session.  If its IBGP you don't need to take down
anything to replace a card unless your network has no internal
redundancy.

For the EBGP session we already have BGP Gracefull Restart but that
doesn't cover upgrading if you are going to pull the old card.

The forwarding that is kept in place during gracefull restart won't be
in place while neither card is in the slot.  Are you suggesting that
the BGP session should stay up and maintain a black hole while the
cards are swapped?  I hope not and that's not what I read.

In this particular example, both providers would bring up the 40 Gig
and then bring down the 10 Gig.  Of course since a lot of 40 Gig
interfaces are really concatonated 10 Gigs (4 x OC192), in this
example they'd add 3 10 gigs with no disruption at all.  Either way no
bits are lost if for a time there are two peerings before the old one
is shut down.

Of course if you are out of card slots there are some routers that let
you expand the backplane without disruption.  Not all routers do that.

> Of course you can do it gracefully with some route-map tricks, ... But on
> large operationnal routers it can be quite complex, and it would be better
> to have it automatic and directly embedded in the router software.

Sorry.  I used to maintain a tier-1 network and I can't see why it
would be so difficult to change policy to not advertise the EBGP into
IBGP, then not accept the EBGP, then shut down the EBGP.  Yes, I know
that today's NOC staff are not what they used to be but many of our
NOC staff were college students who didn't know what BGP was until
their on the jub training.  It seems that this would be your best
solution.

In the old days some bright operations engineer might write a perl
program which given a peering line could write the policy to disable
the EBGP to IBGP, then disable the EBGP, then take down the peering.
The operator could then paste that into the router config.  It sounds
like what you are asking for is a way for the router to shut down the
peering in a similar order but do so automaticly.

> BTW, graceful restart is really efficient when all (all !) peers are
> supporting it.If some of the peer are not supporting it, I wouldn't say it's
> harmful but ... You never know. I do not know many service providers who can
> successfully use it on a large ASBRs currently. In our case many of our
> customers and peers do not support GR even in helper only mode. So GR is
> still a "for future use" feature to me.

The document that you are asking to be considered looks to be just a
requirements document.

What you might be better off advocating is that more routers implement
BGP gracefull restart and more or your peers enable it.  In the
example you just gave gracefull restart doesn't help.  Given the draft
and then the example above, its not clear what problem you are trying
to address and what solution you have in mind.  Is it time for me to
reread the draft?

> > If you are taking a router completely out of service you can cost it
> > out of the IGP first then take down the EBGP peerings, then shut it
> > down. 
>  
> This is not going to work in all situations.

Yes but your document adds nothing to improve it.

> Best regards 
> 	
> Nicolas Dubois
> Tel :  [phone]	

Regards,

Curtis

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA27182 for <[e-mail]>; Sun, 7 Aug 2005 16:55:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1s9v-00011w-17; Sun, 07 Aug 2005 16:54:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1s9o-00011r-Qb for [e-mail]; Sun, 07 Aug 2005 16:54:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27165 for <[e-mail]>; Sun, 7 Aug 2005 16:54:06 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/APi/VAwGAvEuKq0GyYA/jLG39zX+qyOU=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1shN-0001fD-7s for [e-mail]; Sun, 07 Aug 2005 17:28:50 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j77KrggV024698; Sun, 7 Aug 2005 21:53:44 +0100
Date: Sun, 7 Aug 2005 21:53:40 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: Robert Raszuk <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mail-Copies-To: [e-mail]
Mail-Followup-To: [e-mail]
X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: DECRAENE Bruno RD-CORE <[e-mail]>, [e-mail], FONDEVIOLE Benoit RD-CORE <[e-mail]>, DUBOIS Nicolas ROSI/DAS/ARI <[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 Sun, 7 Aug 2005, Robert Raszuk wrote:

[you forgot to attribute text of mine which you quoted]

>> It strikes me that the second case can easily be handled entirely within 
>> the confines of existing specified BGP, by simply having an implementation 
>> take the relevant BGP session(s) down (ie sending a CEASE) and just waiting 
>> a while to let the relevant remote peers update their routes, before 
>> proceeding with actually removing the routes from RIB and FIB and then 
>> restarting.

> Would it not be enough to simply withdraw the advertised routes 
> before bringing the session down towards given peer ?

See above, shutting the session down implies the remote side should 
withdraw (if GR is /not/ involved). No need to send 160k+ withdraws.

What matters, AFAICT, is that you keep your forwarding in place for 
as long as it takes to allow the remote peers concerned to complete 
withdrawal of your routes. No?

> No protocol changes required. All it would take is a local 
> implementation little twick ;).

Indeed.

It could be made better though. The ultimate would be some kind of 
callback mechanism:

(router shutting down)		(remote peer)
Rzzz's     			Rb
----------------------------------------------
Notify/intend-shutdown	---->
 			       <updates its RIB and FIB>
 		        <---   Notify/shutdown-go-ahead

Course, NOTIFY is an error condition, and 1771 states:

 	"The BGP connection is closed immediately after sending it."

Which presents a problem. BGP would need a non-error notification 
method to do the above.

A "If you shutdown, try send me the NOTIFY Xs in advance, please" 
OPEN capability would be easier/quicker to do, and would at least 
remove need for an implementation to simply guess how long /other/ 
implementations might need.

Anyone reckon that'd be something to write-up? :) (would be vaguely 
complementary to the "Estimated Restart Time" field in the Graceful 
Capability).

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
fortune: cannot execute.  Out of cookies.

_______________________________________________
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 QAA23105 for <[e-mail]>; Sun, 7 Aug 2005 16:04:01 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1rLM-0001wu-L9; Sun, 07 Aug 2005 16:02:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1rLK-0001vb-Hq for [e-mail]; Sun, 07 Aug 2005 16:01:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24331 for <[e-mail]>; Sun, 7 Aug 2005 16:01:56 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1rss-0000LN-GY for [e-mail]; Sun, 07 Aug 2005 16:36:39 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 07 Aug 2005 13:01:49 -0700
X-IronPort-AV: i="3.95,173,1120460400";  d="scan'208"; a="203366418:sNHT32654276"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j77K1g0J017835; Sun, 7 Aug 2005 13:01:43 -0700 (PDT)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 7 Aug 2005 13:01:44 -0700
Received: from [10.21.96.126] ([10.21.96.126]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 7 Aug 2005 13:01:36 -0700
Message-ID: <[e-mail]>
Date: Sun, 07 Aug 2005 13:01:39 -0700
From: Robert Raszuk <[e-mail]>
Organization: Signature: http://www.employees.org/~raszuk/sig/
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: DUBOIS Nicolas ROSI/DAS/ARI <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Aug 2005 20:01:36.0678 (UTC) FILETIME=[D1280460:01C59B8A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: DECRAENE Bruno RD-CORE <[e-mail]>, [e-mail], FONDEVIOLE Benoit RD-CORE <[e-mail]>, Paul Jakma <[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]

> A final thought: Does the second case even require any protocol work?
> 
> It strikes me that the second case can easily be handled entirely within 
> the confines of existing specified BGP, by simply having an 
> implementation take the relevant BGP session(s) down (ie sending a 
> CEASE) and just waiting a while to let the relevant remote peers update 
> their routes, before proceeding with actually removing the routes from 
> RIB and FIB and then restarting.
> 
> I reckon the most protocol work this needs is just to have 
> implementations advertise a "I reckon I need X milliseconds to clear Y 
> number of routes" or even just "Hey, if you're going down, try give me X 
> seconds advance notice if you can" capability, which could be used to 
> supercede any implementation specific default.

As this mail is the closest to my line of understanding this problem let 
me ask a very basic question of course assuming that GR is for "the 
future" ...

Would it not be enough to simply withdraw the advertised routes before 
bringing the session down towards given peer ? If operator enters 
shutdown on BGP session this should not trigger any immediate BGP/TCP 
action .. instead one could send MP_UNREACH then at some decent timeout 
actually bring the sessions down.

No protocol changes required. All it would take is a local 
implementation little twick ;).

Cheers,
R.

_______________________________________________
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 KAA26439 for <[e-mail]>; Sun, 7 Aug 2005 10:23:53 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1m3X-0008V8-7e; Sun, 07 Aug 2005 10:23:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1m3V-0008V1-6h for [e-mail]; Sun, 07 Aug 2005 10:23:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09294 for <[e-mail]>; Sun, 7 Aug 2005 10:23:11 -0400 (EDT)
Received: from bay17-f40.bay17.hotmail.com ([64.4.43.90] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1mav-00013L-6A for [e-mail]; Sun, 07 Aug 2005 10:57:51 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 7 Aug 2005 07:22:57 -0700
Message-ID: <[e-mail]>
Received: from 80.15.249.164 by by17fd.bay17.hotmail.msn.com with HTTP; Sun, 07 Aug 2005 14:22:57 GMT
X-Originating-IP: [59.92.136.196]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
In-Reply-To: <[e-mail]>
From: "john smith" <[e-mail]>
To: [e-mail]
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Sun, 07 Aug 2005 14:22:57 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 07 Aug 2005 14:22:57.0434 (UTC) FILETIME=[81F16FA0:01C59B5B]
X-Spam-Score: 3.9 (+++)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
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,

I think if *we know* that a bomb is going to fall on our town at X'oclock, 
we warn everyone to leave town beforehand.... and not wait till the last 
minute and send out a message?

So generally most operators simply send out an "email" to the peering NOCs.
Practical..no?


-JS

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


_______________________________________________
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 KAA25046 for <[e-mail]>; Sun, 7 Aug 2005 10:06:07 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1llV-0005W9-V9; Sun, 07 Aug 2005 10:04:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1llU-0005W4-67 for [e-mail]; Sun, 07 Aug 2005 10:04:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07662 for <[e-mail]>; Sun, 7 Aug 2005 10:04:34 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX18p2fAmOMo0S0ABxMr7VK5hIqN6jDS0qvw=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1mIx-0000gh-L3 for [e-mail]; Sun, 07 Aug 2005 10:39:14 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j77E4KvS021651; Sun, 7 Aug 2005 15:04:23 +0100
Date: Sun, 7 Aug 2005 15:04:19 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: DUBOIS Nicolas ROSI/DAS/ARI <[e-mail]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mail-Copies-To: [e-mail]
Mail-Followup-To: [e-mail]
X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: DECRAENE Bruno RD-CORE <[e-mail]>, [e-mail], FONDEVIOLE Benoit RD-CORE <[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]

Hi Nicholas,

On Sun, 7 Aug 2005, DUBOIS Nicolas ROSI/DAS/ARI wrote:

> Basically GR restart is:
> 	Forwarding plane stays up / control plane says I'll be back.

Right. Though note that GR specifies a forwarding-state bit, so you 
can signal to your peer, /after/ the fact (when you bring your 
session back up), whether or not your forwarding plane stayed up.

> Planned maintenance requirement is:

> 	Forwarding going away, control plane going away / let's do it
>	gracefully.

Ok, I guess my question then is what you think can be done for this 
case, eg /lack/ of graceful-restart capability.

Further, as above, how can you even reliably distinguish between the 
two cases above (presuming GR is enabled)? Given the GR draft, you 
can't determine anything until the peer comes back. Ie, given GR, 
there is a window of uncertainty where you can not say whether 
forwarding stayed up or not, you only know when it comes back and you 
can examine the F bit in the GR capability advertisement for the 
appropriate AFI/SAFI.

Something to consider anyway (the interaction of the two).

A final thought: Does the second case even require any protocol work?

It strikes me that the second case can easily be handled entirely 
within the confines of existing specified BGP, by simply having an 
implementation take the relevant BGP session(s) down (ie sending a 
CEASE) and just waiting a while to let the relevant remote peers 
update their routes, before proceeding with actually removing the 
routes from RIB and FIB and then restarting.

I reckon the most protocol work this needs is just to have 
implementations advertise a "I reckon I need X milliseconds to clear 
Y number of routes" or even just "Hey, if you're going down, try give 
me X seconds advance notice if you can" capability, which could be 
used to supercede any implementation specific default.

> Best regards,
>
> Nicolas Dubois
> Tel :  [phone]

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
Finagle's Seventh Law:
 	The perversity of the universe tends toward a maximum.

_______________________________________________
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 IAA16764 for <[e-mail]>; Sun, 7 Aug 2005 08:19:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1k7g-0003zw-Cs; Sun, 07 Aug 2005 08:19:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1k7f-0003zr-OR for [e-mail]; Sun, 07 Aug 2005 08:19:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03459 for <[e-mail]>; Sun, 7 Aug 2005 08:19:22 -0400 (EDT)
Received: from relais-inet.francetelecom.com ([212.234.67.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1kfA-0006k4-If for [e-mail]; Sun, 07 Aug 2005 08:54:01 -0400
Received: from prive-Rline2.com ([192.168.1.22] [192.168.1.22]) by Rline2.francetelecom.com with ESMTP for [e-mail]; Sun, 7 Aug 2005 14:19:14 +0200
Received: from smtp2.smtpft.francetelecom.fr ([193.249.133.11] [193.249.133.11]) by Rline2.francetelecom.com with ESMTP for [e-mail]; Sun, 7 Aug 2005 14:19:14 +0200
Received: from FTBIEZ3ZCWRQWV ([10.172.48.15]) by smtp2.smtpft.francetelecom.fr (Netscape Messaging Server 4.15) with ESMTP id IKUQ8101.E2B; Sun, 7 Aug 2005 14:19:13 +0200 
From: "DUBOIS Nicolas ROSI/DAS/ARI" <[e-mail]>
To: "'John Leslie'" <[e-mail]>, "'Curtis Villamizar'" <[e-mail]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Sun, 7 Aug 2005 14:19:13 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Thread-Index: AcWaC2f+7GAMiZwVTN6D49dKYwPpkgBPWnuw
In-reply-to: <20050805221316.GB9135@verdi>
Message-Id: <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id IAA16764

Hi John,

Thanks for reading the draft,

>> but my problem with it is that it fails to propose adequate algorithms
for graceful shutdown.

I think it is better to first agree that there is a need for a graceful
shutdown and then discuss of the acceptable solutions. Depending on the
scope of this graceful shutdown, there are many acceptable solutions.

I think a requirement should not explain the problem and the solution at the
same time.

>    It would be good to have a mechanism for deprecating 
> routes a bit more gracefully than prepending in hopes that 
> some other route will be preferred; and it would be good to 
> have some mechanism to ensure that the propagation of 
> deprecating routes never causes packets to be dropped for 
> lack of an immediately-available alternate route.
> 

I agree with that and it is the idea we would like to push with the draft.

Best regards,

	
Nicolas Dubois
Tel :  [phone]	

 

> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] De la 
> part de John Leslie
> Envoyé : samedi 6 août 2005 00:13
> À : Curtis Villamizar
> Cc : [e-mail]; DUBOIS Nicolas ROSI/DAS/ARI
> Objet : Re: [idr] BGP planned maintenance requirements as an 
> IDR WG doc
> 
> Curtis Villamizar <[e-mail]> wrote:
> > In message <[e-mail]>
> > "DUBOIS Nicolas ROSI/DAS/ARI" writes:
> >>  
> >> Following IETF 63, I'd like to suggest that BGP planned 
> maintenance 
> >> requirements (draft-dubois-bgp-pm-reqs-02.txt) be considered as an 
> >> IDR working group document.
> > 
> > What's the point?  There is BGP gracefull restart and there are 
> > routers with warm standby route servers that can do things like 
> > software upgrades without impacting service.  All line cards these 
> > days are hot pluggable.
> 
>    I cannot support this I-D as a Working Group document 
> either; but my problem with it is that it fails to propose 
> adequate algorithms for graceful shutdown. (There are 
> occasions where power is failing and shutdown will be 
> necessary: if we were to adopt it, we should at least change 
> the title.)
> 
>    It would be good to have a mechanism for deprecating 
> routes a bit more gracefully than prepending in hopes that 
> some other route will be preferred; and it would be good to 
> have some mechanism to ensure that the propagation of 
> deprecating routes never causes packets to be dropped for 
> lack of an immediately-available alternate route.
> 
>    But I do not see that in this draft.
> 
> --
> John Leslie <[e-mail]>
> 
> _______________________________________________
> 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 IAA16047 for <[e-mail]>; Sun, 7 Aug 2005 08:11:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1jxa-0001vI-7l; Sun, 07 Aug 2005 08:08:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1jxY-0001v1-KE for [e-mail]; Sun, 07 Aug 2005 08:08:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03062 for <[e-mail]>; Sun, 7 Aug 2005 08:08:55 -0400 (EDT)
Received: from relais-inet.francetelecom.com ([212.234.67.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1kV2-0006WJ-31 for [e-mail]; Sun, 07 Aug 2005 08:43:33 -0400
Received: from prive-Rline1.com ([192.168.1.12] [192.168.1.12]) by Rline1.francetelecom.com with ESMTP for [e-mail]; Sun, 7 Aug 2005 14:08:45 +0200
Received: from smtp2.smtpft.francetelecom.fr ([193.249.133.11] [193.249.133.11]) by Rline1.francetelecom.com with ESMTP for [e-mail]; Sun, 7 Aug 2005 14:08:45 +0200
Received: from FTBIEZ3ZCWRQWV ([10.172.48.15]) by smtp2.smtpft.francetelecom.fr (Netscape Messaging Server 4.15) with ESMTP id IKUPQL00.12N; Sun, 7 Aug 2005 14:08:45 +0200 
From: "DUBOIS Nicolas ROSI/DAS/ARI" <[e-mail]>
To: "'Paul Jakma'" <[e-mail]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Sun, 7 Aug 2005 14:08:44 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Thread-Index: AcWalaKt8NAJy3iITzusZJeyuTV2cwAsr7Eg
In-reply-to: <[e-mail]>
Message-Id: <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: DECRAENE Bruno RD-CORE <[e-mail]>, [e-mail], FONDEVIOLE Benoit RD-CORE <[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 IAA16047

Basically GR restart is:
	Forwarding plane stays up / control plane says I'll be back.

Planned maintenance requirement is:
	Forwarding going away, control plane going away / let's do it
gracefully.

Best regards,
	
Nicolas Dubois
Tel :  [phone]	

 

> -----Message d'origine-----
> De : Paul Jakma [mailto:[e-mail]] 
> Envoyé : samedi 6 août 2005 16:46
> À : DUBOIS Nicolas ROSI/DAS/ARI
> Cc : [e-mail]; DECRAENE Bruno RD-CORE; FONDEVIOLE Benoit RD-CORE
> Objet : Re: [idr] BGP planned maintenance requirements as an 
> IDR WG doc
> 
> On Fri, 5 Aug 2005, DUBOIS Nicolas ROSI/DAS/ARI wrote:
> 
> > Hi Folks,
> >
> > Following IETF 63, I'd like to suggest that BGP planned maintenance 
> > requirements (draft-dubois-bgp-pm-reqs-02.txt) be 
> considered as an IDR 
> > working group document.
> 
> I meant to ask this at the WG meeting, but exactly what do 
> you intend to cover with this which isnt covered by graceful restart?
> 
> regards,
> -- 
> Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
> Fortune:
> On the other hand, you have different fingers.


_______________________________________________
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 IAA15759 for <[e-mail]>; Sun, 7 Aug 2005 08:07:15 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1jup-0001NV-Ef; Sun, 07 Aug 2005 08:06:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1juo-0001MF-4k for [e-mail]; Sun, 07 Aug 2005 08:06:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02910 for <[e-mail]>; Sun, 7 Aug 2005 08:06:05 -0400 (EDT)
Received: from relais-inet.francetelecom.com ([212.234.67.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1kSG-0006Rp-Pp for [e-mail]; Sun, 07 Aug 2005 08:40:43 -0400
Received: from prive-Rline2.com ([192.168.1.22] [192.168.1.22]) by Rline2.francetelecom.com with ESMTP for [e-mail]; Sun, 7 Aug 2005 14:05:48 +0200
Received: from smtp2.smtpft.francetelecom.fr ([193.249.133.11] [193.249.133.11]) by Rline2.francetelecom.com with ESMTP for [e-mail]; Sun, 7 Aug 2005 14:05:48 +0200
Received: from FTBIEZ3ZCWRQWV ([10.172.48.15]) by smtp2.smtpft.francetelecom.fr (Netscape Messaging Server 4.15) with ESMTP id IKUPLO00.K2W; Sun, 7 Aug 2005 14:05:48 +0200 
From: "DUBOIS Nicolas ROSI/DAS/ARI" <[e-mail]>
To: <[e-mail]>
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc 
Date: Sun, 7 Aug 2005 14:05:45 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Thread-Index: AcWZ+GLkVyhGnjGFR6mZKTXcQMa8XQBTj7Ig
In-reply-to: <[e-mail]>
Message-Id: <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc: DECRAENE Bruno RD-CORE <[e-mail]>, [e-mail], FONDEVIOLE Benoit RD-CORE <[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 IAA15759

Curtis,

Thanks for reading the draft, some comments:

If you've got a 2.5 gig line card and want to upgrade it to a 10 or 40 gig
line card, I still think you need to shut down the BGP session that is
running on it and in order to replace the card.
 
Of course you can do it gracefully with some route-map tricks, ... But on
large operationnal routers it can be quite complex, and it would be better
to have it automatic and directly embedded in the router software.

BTW, graceful restart is really efficient when all (all !) peers are
supporting it.If some of the peer are not supporting it, I wouldn't say it's
harmful but ... You never know. I do not know many service providers who can
successfully use it on a large ASBRs currently. In our case many of our
customers and peers do not support GR even in helper only mode. So GR is
still a "for future use" feature to me.

> If you are taking a router completely out of service you can cost it
> out of the IGP first then take down the EBGP peerings, then shut it
> down. 

This is not going to work in all situations.

Best regards 
	
Nicolas Dubois
Tel :  [phone]	

 

> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] De la 
> part de Curtis Villamizar
> Envoyé : vendredi 5 août 2005 22:00
> À : DUBOIS Nicolas ROSI/DAS/ARI
> Cc : DECRAENE Bruno RD-CORE; [e-mail]; FONDEVIOLE Benoit RD-CORE
> Objet : Re: [idr] BGP planned maintenance requirements as an 
> IDR WG doc 
> 
> 
> In message <[e-mail]>
> "DUBOIS Nicolas ROSI/DAS/ARI" writes:
> >  
> >  
> > Hi Folks,
> >  
> > Following IETF 63, I'd like to suggest that BGP planned maintenance 
> > requirements (draft-dubois-bgp-pm-reqs-02.txt) be 
> considered as an IDR 
> > working group document.
> >  
> > Thanks,
> >  
> > Nicolas
> > [phone]
> 
> 
> What's the point?  There is BGP gracefull restart and there are
> routers with warm standby route servers that can do things like
> software upgrades without impacting service.  All line cards these
> days are hot pluggable.
> 
> If you are taking a router completely out of service you can cost it
> out of the IGP first then take down the EBGP peerings, then shut it
> down.  These days better there is less need to do this.  For example,
> on some routers you can do a hardware upgrade to a newer route
> processor by installing it as a backup route processor and forcing a
> swap of control.
> 
> Unless you need to swap out a faulty backplane there are routers today
> that can be upgraded incrementally over a very wide range of capacity,
> including increasing the backplane capacity, all without a reboot.
> 
> Isn't this requirement a few years late?
> 
> Curtis
> 
> ps - send email off list if you want details that are outside the
> scope of the IDR discussion.
> 
> _______________________________________________
> 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 141675240 (user-0cdf76m.cable.mindspring.com [24.215.156.214]) by nic.merit.edu (8.9.3/8.9.1) with SMTP id XAA04685 for <[e-mail]>; Sat, 6 Aug 2005 23:16:46 -0400 (EDT)
Received: from e-hkma.com (144099448 [141415256]) by user-0cdf76m.cable.mindspring.com (Qmailv1) with ESMTP id 4A784722FC for <[e-mail]>; Sat, 06 Aug 2005 20:19:31 -0700
Date: Sat, 06 Aug 2005 20:19:31 -0700
From: "Civvies D. Electrocardiographs" <[e-mail]>
X-Mailer: The Bat! (v2.00.8) Personal
X-Priority: 3
Message-ID: <[e-mail]>
To: Idr <[e-mail]>
Subject: Please visit our OEM software supertore!
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----------CE91B825A6030AC"
X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.5; AVE: 6.17.0.2; VDF: 6.17.0.5; host: user-0cdf76m.cable.mindspring.com)

This is a multi-part message in MIME format.

------------CE91B825A6030AC
Content-Type: text/plain
Content-Transfer-Encoding: 7bit



 http://bkzu.unearnedkh.info/?OxQTQ3i0_npCyCO

Three steps to the software you need for the price you want.

 Please check our reduced price. 

 Premiere 6.5 - $80 
 Dreamweaver MX 2004 - $60 
 MS Office 2003 Professional (1 CD Edition) - $89.95 
 MS Plus! XP - $50 
 Flash MX 2004 - $60 
 Microsoft Office 2000 Premium Edition (2 CD Edition) - $59.95 
 Microsoft Office 2k PE (2 CD Edition) - $59.95 
 FreeHand MX - $60 
 Extensis Portfolio 7.0 - $50 
 Windows 98 - $40 
 Fireworks MX 2004 - $60 
 MS Office 2k PE (2 CD) - $59.95 
 Windows 2000 Professional - $59.95 
 Windows NT 4.0 Server - $40 
 MS Office 2003 Pro (1 CD Edition) - $89.95 


 Go to site
 http://avsvamo.jansenisten.info/?JsfOfuJrqiQxZ1J


------------CE91B825A6030AC
Content-Type: text/html
Content-Transfer-Encoding: 7bit

<html>
<head>
<meta content="text/html; charset=iso-8859-15" = http-equiv=Content-Type>
</head>
<body>


<table align=center>
<tr><td align=center>
<strong align=center><a href="http://evdqq.nonlifenj.info/?o7qtWFoCBt_cEcU">
<font size=4 color=#1213a7>
YAHOO software news
</a></strong>
</td></tr>
<tr><td align=center><font size=3>Check our prices.</font></td></tr>
</table>
<table align=center border=0>
<tr><td align=center colspan=2>Special Offers:</td></tr>
<tr><td>Bundle Special:Microsoft Win XP Pro + Microsoft Office XP Pro</td><td>$89.95</td></tr><tr><td>Bundle Special:Photoshop  + Premiere  + Illustrator </td><td>$129.95</td></tr><tr><td>Bundle Special:Win XP Pro With SP2 Full Version + Office 2003 Pro (1 CD)</td><td>$99.95</td></tr><tr><td>Bundle Special:Dreamwaver MX 2004 + Flash MX 2004</td><td>$109.95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=center colspan=2>Microsoft|R| Windows|R| </td></tr>
<tr><td>Windows 2k Professional</td><td>$59.95</td></tr><tr><td>Windows 95</td><td>$49.95</td></tr><tr><td>Windows Millenium </td><td>$59.95</td></tr><tr><td>Windows XP Professional</td><td>$69.95</td></tr><tr><td>Windows 2k Advanced Server </td><td>$69.95</td></tr><tr><td>Windows XP Professional With SP2 Full Version</td><td>$79.95</td></tr><tr><td>Windows NT 4.0 Terminal Server</td><td>$49.95</td></tr><tr><td>Windows 98 Second Edition </td><td>$49.95</td></tr><tr><td>Windows NT 4.0 Server </td><td>$49.95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=center colspan=2>Microsoft|R| Office|R|:</td></tr>
<tr><td>Office 2003 Pro (1 CD Edition)</td><td>$89.95</td></tr><tr><td>Office 2000 PE (2 CD)</td><td>$59.95</td></tr><tr><td>Office XP Pro</td><td>$79.95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=center colspan=2>Other Microsoft|R| Software:</td></tr>
<tr><td>Microsoft Works 7</td><td>$69.95</tr></td><tr><td>Microsoft Money 2004</td><td>$69.95</tr></td><tr><td>Microsoft Picture It Premium 9</td><td>$59.95</tr></td><tr><td>Microsoft Streets and Trips 2004 North America (2 CD)</td><td>$69.95</tr></td><tr><td>Microsoft Visual Studio .NET Architect Edition (8CD)</td><td>$139.95</tr></td><tr><td>Microsoft Encarta Encyclopedia Delux 2004 (3 CD Edition)</td><td>$89.95</tr></td><tr><td>Microsoft Exchange 2003 Enterprise Server</td><td>$69.95</tr></td><tr><td>Microsoft SQL Server 2k Enterprise Edition</td><td>$69.95</tr></td><tr><td>Microsoft Project 2003 Professional</td><td>$69.95</tr></td><tr><td>Microsoft Plus! XP</td><td>$59.95</tr></td>
<tr><td>&nbsp;</td></tr>
<tr><td align=center colspan=2>Adobe Software for PC:</td></tr>
<tr><td> Photoshop Elements 3.0 Windows </td><td>$59.95</td></tr><tr><td> Premiere 7 </td><td>$69.95</td></tr><tr><td> Photoshop CS with ImageReady CS </td><td>$99.95</td></tr><tr><td> Creative Suite Standard (3 CD) </td><td>$129.95</td></tr><tr><td> Acrobat 6 Professional </td><td>$79.95</td></tr><tr><td> Photoshop 7 </td><td>$69.95</td></tr><tr><td> PageMaker 7 (2 CD) </td><td>$69.95</td></tr><tr><td> Creative Suite Premium (5 CD) </td><td>$149.95</td></tr><tr><td> InDesign CS PageMaker Edition (2 CD) </td><td>$69.95</td></tr><tr><td> Illustrator 10 </td><td>$69.95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=center colspan=2>Adobe Software for Mac:</td></tr>
<tr><td>Adobe Premiere 6.5 (Apple Macintosh)</td><td>$89.95</td></tr><tr><td>Adobe InDesign CS (Apple Macintosh)</td><td>$69.95</td></tr><tr><td>Adobe Actobat 6 Pro (Apple Macintosh)</td><td>$79.95</td></tr><tr><td>Adobe LiveMotion 2 (Apple Macintosh)</td><td>$69.95</td></tr><tr><td>Adobe Illustrator CS CE (Apple Macintosh)</td><td>$69.95</td></tr><tr><td>Adobe Photoshop CS (Apple Macintosh)</td><td>$99.95</td></tr><tr><td>Adobe After Effects 6 (Apple Macintosh)</td><td>$69.95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=center colspan=2>Macromedia Software for PC:</td></tr>
<tr><td>Macromedia Fireworks MX 2004</td><td>$69.95</tr></td><tr><td>Macromedia Dreamwaver MX 2004</td><td>$69.95</tr></td><tr><td>Macromedia Freehand MX 11</td><td>$69.95</tr></td><tr><td>Macromedia Flash MX 2004</td><td>$69.95</tr></td>
<tr><td>&nbsp;</td></tr>
<tr><td align=center colspan=2>Macromedia Software for Mac:</td></tr>
<tr><td>Macromedia Director MX 2004 (Mac)</td><td>$69.95</td></tr><tr><td>Macromedia Flash MX 2004 (Mac)</td><td>$69.95</td></tr><tr><td>Macromedia Studio MX 2004 with Director MX 2004 (Mac)</td><td>$139.95</td></tr><tr><td>Macromedia Dreamweaver MX 2004 (Mac)</td><td>$69.95</td></tr><tr><td>Macromedia Fireworks MX 2004 (Mac)</td><td>$69.95</td></tr><tr><td>Macromedia FreeHand MX (Mac)</td><td>$69.95</td></tr>
<tr><td>&nbsp;</td></tr>
<tr><td align=center colspan=2>Corel Software:</td></tr>
<tr><td>Corel Draw Graphics Suite 11</td><td>$59.95</td></tr><tr><td>Corel Draw Graphics Suite 11 (Mac)</td><td>$59.95</td></tr><tr><td>Corel Photo Painter 8.0</td><td>$59.95</td></tr><tr><td>Corel WordPerfect Office </td><td>$69.95</td></tr><tr><td>Corel Photo Painter 8.0 (Mac)</td><td>$59.95</td></tr>
<tr><td>&nbsp;</td></tr>

</table>
<table align=center>
<tr><td align=center>
<a href="http://evdqq.nonlifenj.info/?o7qtWFoCBt_cEcU"><h3><font size=3 color=#212346>Get to site</font></h3></a>

</td></tr>
</table>
</body>
</html>


------------CE91B825A6030AC--




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 WAA29016 for <[e-mail]>; Sat, 6 Aug 2005 22:05:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1aXt-0003mv-UN; Sat, 06 Aug 2005 22:05:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1aXs-0003mq-Dp for [e-mail]; Sat, 06 Aug 2005 22:05:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25156 for <[e-mail]>; Sat, 6 Aug 2005 22:05:46 -0400 (EDT)
Received: from web25302.mail.ukl.yahoo.com ([217.12.10.74]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E1b5B-0005un-5Z for [e-mail]; Sat, 06 Aug 2005 22:40:20 -0400
Received: (qmail 15543 invoked by uid 60001); 7 Aug 2005 02:05:25 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Mee6UfHGerUpBPC6AlNk7HyuzKmtW7QqQgrTQnteAk6PSwvQXch9NpQ1eMjSjCN7rhtoDsmAnul02Y/6UcDRsRwlNqCreupSiCIBakg9KKTMJ2lDYqPDcpm6HSYS/esKXFtS2OweeuCPuGMPMvy9U5PrwuLW/+MYXCRjT4GRoyE= ; 
Message-ID: <[e-mail]>
Received: from [202.144.106.189] by web25302.mail.ukl.yahoo.com via HTTP; Sun, 07 Aug 2005 03:05:25 BST
Date: Sun, 7 Aug 2005 03:05:25 +0100 (BST)
From: John Smith <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 8bit
Subject: [Idr] Minutes
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]

Hello,

Can somebody please post the minutes of the meeting?

Thanks,
JOhn


		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.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 KAA17706 for <[e-mail]>; Sat, 6 Aug 2005 10:47:14 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1PwM-0000Pl-9s; Sat, 06 Aug 2005 10:46:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1PwK-0000OC-Kh for [e-mail]; Sat, 06 Aug 2005 10:46:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26744 for <[e-mail]>; Sat, 6 Aug 2005 10:46:18 -0400 (EDT)
Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19D2ECGo4U/h2WOvxf92t9njYwxPwTZmuM=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1QTd-0000Ca-PI for [e-mail]; Sat, 06 Aug 2005 11:20:46 -0400
Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j76EkDJY004719; Sat, 6 Aug 2005 15:46:16 +0100
Date: Sat, 6 Aug 2005 15:46:11 +0100 (IST)
From: Paul Jakma <[e-mail]>
X-X-Sender: [e-mail]
To: DUBOIS Nicolas ROSI/DAS/ARI <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
Mail-Copies-To: [e-mail]
Mail-Followup-To: [e-mail]
X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: DECRAENE Bruno RD-CORE <[e-mail]>, [e-mail], FONDEVIOLE Benoit RD-CORE <[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 Fri, 5 Aug 2005, DUBOIS Nicolas ROSI/DAS/ARI wrote:

> Hi Folks,
>
> Following IETF 63, I'd like to suggest that BGP planned maintenance 
> requirements (draft-dubois-bgp-pm-reqs-02.txt) be considered as an 
> IDR working group document.

I meant to ask this at the WG meeting, but exactly what do you intend 
to cover with this which isnt covered by graceful restart?

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
On the other hand, you have different fingers.

_______________________________________________
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 SAA24709 for <[e-mail]>; Fri, 5 Aug 2005 18:16:17 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1ARV-0002jg-17; Fri, 05 Aug 2005 18:13:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1ART-0002jL-5c for [e-mail]; Fri, 05 Aug 2005 18:13:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06925 for <[e-mail]>; Fri, 5 Aug 2005 18:13:24 -0400 (EDT)
Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1Ayd-0004tk-3D for [e-mail]; Fri, 05 Aug 2005 18:47:44 -0400
Received: by mailhost.jlc.net (Postfix, from userid 104) id 6E4C3E047D; Fri,  5 Aug 2005 18:13:16 -0400 (EDT)
Date: Fri, 5 Aug 2005 18:13:16 -0400
From: John Leslie <[e-mail]>
To: Curtis Villamizar <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc
Message-ID: <20050805221316.GB9135@verdi>
References: <[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.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: [e-mail], DUBOIS Nicolas ROSI/DAS/ARI <[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]

Curtis Villamizar <[e-mail]> wrote:
> In message <[e-mail]>
> "DUBOIS Nicolas ROSI/DAS/ARI" writes:
>>  
>> Following IETF 63, I'd like to suggest that BGP planned maintenance
>> requirements (draft-dubois-bgp-pm-reqs-02.txt) be considered as an IDR
>> working group document.
> 
> What's the point?  There is BGP gracefull restart and there are
> routers with warm standby route servers that can do things like
> software upgrades without impacting service.  All line cards these
> days are hot pluggable.

   I cannot support this I-D as a Working Group document either; but my
problem with it is that it fails to propose adequate algorithms for
graceful shutdown. (There are occasions where power is failing and
shutdown will be necessary: if we were to adopt it, we should at least
change the title.)

   It would be good to have a mechanism for deprecating routes a bit
more gracefully than prepending in hopes that some other route will be
preferred; and it would be good to have some mechanism to ensure that
the propagation of deprecating routes never causes packets to be
dropped for lack of an immediately-available alternate route.

   But I do not see that in this draft.

--
John Leslie <[e-mail]>

_______________________________________________
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 QAA14156 for <[e-mail]>; Fri, 5 Aug 2005 16:00:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E18Kv-0003Kj-LA; Fri, 05 Aug 2005 15:58:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E18Kt-0003K6-4i for [e-mail]; Fri, 05 Aug 2005 15:58:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29539 for <[e-mail]>; Fri, 5 Aug 2005 15:58:27 -0400 (EDT)
Received: from relay00.pair.com ([209.68.1.20] helo=relay.pair.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E18s0-0001HW-Jr for [e-mail]; Fri, 05 Aug 2005 16:32:46 -0400
Received: (qmail 35463 invoked from network); 5 Aug 2005 19:58:17 -0000
Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 5 Aug 2005 19:58:17 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j75K09Dq033121; Fri, 5 Aug 2005 16:00:09 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "DUBOIS Nicolas ROSI/DAS/ARI" <[e-mail]>
Subject: Re: [idr] BGP planned maintenance requirements as an IDR WG doc 
In-reply-to: Your message of "Fri, 05 Aug 2005 19:14:40 +0200." <[e-mail]> 
Date: Fri, 05 Aug 2005 16:00:09 -0400
From: Curtis Villamizar <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: DECRAENE Bruno RD-CORE <[e-mail]>, [e-mail], FONDEVIOLE Benoit RD-CORE <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

In message <[e-mail]>
"DUBOIS Nicolas ROSI/DAS/ARI" writes:
>  
>  
> Hi Folks,
>  
> Following IETF 63, I'd like to suggest that BGP planned maintenance
> requirements (draft-dubois-bgp-pm-reqs-02.txt) be considered as an IDR
> working group document.
>  
> Thanks,
>  
> Nicolas 
> [phone]


What's the point?  There is BGP gracefull restart and there are
routers with warm standby route servers that can do things like
software upgrades without impacting service.  All line cards these
days are hot pluggable.

If you are taking a router completely out of service you can cost it
out of the IGP first then take down the EBGP peerings, then shut it
down.  These days better there is less need to do this.  For example,
on some routers you can do a hardware upgrade to a newer route
processor by installing it as a backup route processor and forcing a
swap of control.

Unless you need to swap out a faulty backplane there are routers today
that can be upgraded incrementally over a very wide range of capacity,
including increasing the backplane capacity, all without a reboot.

Isn't this requirement a few years late?

Curtis

ps - send email off list if you want details that are outside the
scope of the IDR discussion.

_______________________________________________
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 NAA01285 for <[e-mail]>; Fri, 5 Aug 2005 13:14:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E15mX-00034i-0a; Fri, 05 Aug 2005 13:14:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E15mV-00033q-Og for [e-mail]; Fri, 05 Aug 2005 13:14:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20852 for <[e-mail]>; Fri, 5 Aug 2005 13:14:48 -0400 (EDT)
Received: from relais-inet.francetelecom.com ([212.234.67.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E16Jc-00051S-KC for [e-mail]; Fri, 05 Aug 2005 13:49:06 -0400
Received: from prive-Rline2.com ([192.168.1.22] [192.168.1.22]) by Rline2.francetelecom.com with ESMTP for [e-mail]; Fri, 5 Aug 2005 19:14:35 +0200
Received: from smtp2.smtpft.francetelecom.fr ([193.249.133.11] [193.249.133.11]) by Rline2.francetelecom.com with ESMTP for [e-mail]; Fri, 5 Aug 2005 19:14:35 +0200
Received: from FTBIEZ3ZCWRQWV ([10.158.49.235]) by smtp2.smtpft.francetelecom.fr (Netscape Messaging Server 4.15) with ESMTP id IKREKB00.543; Fri, 5 Aug 2005 19:14:35 +0200 
From: "DUBOIS Nicolas ROSI/DAS/ARI" <[e-mail]>
To: <[e-mail]>
Subject: [idr] BGP planned maintenance requirements as an IDR WG doc
Date: Fri, 5 Aug 2005 19:14:40 +0200
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Thread-Index: AcWZ4SnGrXegk7odTL2OrCGR5pFRFA==
Message-Id: <[e-mail]>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Cc: DECRAENE Bruno RD-CORE <[e-mail]>, FONDEVIOLE Benoit RD-CORE <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1949024237=="
Sender: [e-mail]
Errors-To: [e-mail]

This is a multi-part message in MIME format.

--===============1949024237==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0046_01C599F1.ED856E80"

This is a multi-part message in MIME format.

------=_NextPart_000_0046_01C599F1.ED856E80
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Folks,
 
Following IETF 63, I'd like to suggest that BGP planned maintenance
requirements (draft-dubois-bgp-pm-reqs-02.txt) be considered as an IDR
working group document. 
 
Thanks,
 
Nicolas 
[phone]

------=_NextPart_000_0046_01C599F1.ED856E80
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1505" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D369510417-05082005>Hi=20
Folks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D369510417-05082005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D369510417-05082005>Following IETF 63,=20
I'd like to suggest that BGP planned maintenance requirements=20
(draft-dubois-bgp-pm-reqs-02.txt) be considered as an IDR working group=20
document. </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D369510417-05082005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D369510417-05082005>Thanks,</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2>Nicolas =
</FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2>[phone]=20
17</FONT></DIV></BODY></HTML>

------=_NextPart_000_0046_01C599F1.ED856E80--



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

--===============1949024237==--




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 KAA28946 for <[e-mail]>; Thu, 4 Aug 2005 10:59:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0h8W-0003ql-8q; Thu, 04 Aug 2005 10:55:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0h8U-0003pG-Nm for [e-mail]; Thu, 04 Aug 2005 10:55:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17201 for <[e-mail]>; Thu, 4 Aug 2005 10:55:52 -0400 (EDT)
Received: from gateout02.mbox.net ([165.212.64.22] helo=gwo2.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0hfM-0006A1-6O for [e-mail]; Thu, 04 Aug 2005 11:29:54 -0400
Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gwo2.mbox.net (Postfix) with SMTP id 4045A163D3F; Thu,  4 Aug 2005 14:55:36 +0000 (GMT)
Received: from gateout02.mbox.net [165.212.64.22] by gateout02.mbox.net via mtad (C8.MAIN.3.17K)  with ESMTP id 100JHDo4j0358Mo2; Thu, 04 Aug 2005 14:55:35 GMT
Received: from gw4.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.21U); Thu, 04 Aug 2005 14:55:35 GMT
X-USANET-Source: 165.212.116.254 IN   [e-mail] gw4.EXCHPROD.USA.NET
X-USANET-MsgId: XID824JHDo4j3260Xo2
Received: from localhost ([65.247.36.31]) by gw4.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211);  Thu, 4 Aug 2005 08:55:35 -0600
Date: Thu, 4 Aug 2005 10:55:34 -0400
From: Jeffrey Haas <[e-mail]>
To: Bill Fenner <[e-mail]>
Subject: Re: [Idr] SAFI and other codepoint issues
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-OriginalArrivalTime: 04 Aug 2005 14:55:35.0165 (UTC) FILETIME=[919A3AD0:01C59904]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: [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]

Bill,

On Thu, Aug 04, 2005 at 03:36:35PM +0200, Bill Fenner wrote:
>   However, as you know, circumstances dictated that 2547 be allowed to
> continue to use the "private use" number that it was deployed with.
> Obviously, a strict adherence to policy would have simply gotten in
> the way of having a working protocol.  I'm sure that there will be
> other examples of this coming soon.

Definitely.  One of the proposals is up to SAFI 132.  There may
be others beyond this, but I haven't found any with some quick googling.

>   The IETF has been working with the IANA since October 2004 to ensure
> that the IANA can meet the IETF's needs.  We agreed at that time that,
> as an interim goal, IANA should be able to allocate a number from a
> FCFS space within 30 days.

I suspect this will address 2/3 of the problem.

> Moving forward, I'd like to recommend the following:
> 
> - Reclassify 129-239 as "Reserved".
> - Retain 240-255 as "private use".
> - As needed, register values in the Reserved range if previously-deployed
>   protocols come into the IETF.
> - Recommend that new developments use FCFS or RFC4020 method to get
>   code points
> - In the future, if we run out of FCFS or IETF Consensus numbers,
>   start using the "Reserved" space as needed.

This seems very reasonable.

The other half of this effort is the awkward portion.  Working group
chairs need to be aware that things that are best done as FCFS or RFC 4020
should be done that way.  Drafts should be rejected as WG documents 
without getting an appropriate delegation.


-- 
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 JAA22821 for <[e-mail]>; Thu, 4 Aug 2005 09:40:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ftv-0003fQ-IO; Thu, 04 Aug 2005 09:36:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ftt-0003fK-Rd for [e-mail]; Thu, 04 Aug 2005 09:36:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10428 for <[e-mail]>; Thu, 4 Aug 2005 09:36:44 -0400 (EDT)
Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0gQm-0002ue-Lj for [e-mail]; Thu, 04 Aug 2005 10:10:45 -0400
Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id C80B2A7BC5; Thu,  4 Aug 2005 09:36:35 -0400 (EDT)
Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j74DaZKJ022857;  Thu, 4 Aug 2005 15:36:35 +0200
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: [e-mail]
Subject: Re: [Idr] SAFI and other codepoint issues
Date: Thu, 4 Aug 2005 15:36:35 +0200
From: Bill Fenner <[e-mail]>
Versions: dmail (linux) 2.6d/makemail 2.10
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: [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]

Jeff,

  Here's my proposal for this particular situation.  As you say, the
current ranges are:
1-63: "IETF Consensus"
64-127: "FCFS"
128-255: "private use"

  However, as you know, circumstances dictated that 2547 be allowed to
continue to use the "private use" number that it was deployed with.
Obviously, a strict adherence to policy would have simply gotten in
the way of having a working protocol.  I'm sure that there will be
other examples of this coming soon.

  The IETF has been working with the IANA since October 2004 to ensure
that the IANA can meet the IETF's needs.  We agreed at that time that,
as an interim goal, IANA should be able to allocate a number from a
FCFS space within 30 days.  They have implemented tracking systems and
hired staff and from what we can tell they are now meeting this goal.
Given this change, it may be more acceptable to use FCFS (or, perhaps,
the RFC 4020 "early allocation" mechanism) for newer work.

Moving forward, I'd like to recommend the following:

- Reclassify 129-239 as "Reserved".
- Retain 240-255 as "private use".
- As needed, register values in the Reserved range if previously-deployed
  protocols come into the IETF.
- Recommend that new developments use FCFS or RFC4020 method to get
  code points
- In the future, if we run out of FCFS or IETF Consensus numbers,
  start using the "Reserved" space as needed.

With respect to this kind of experience:

>: At least in my experience requesting a number from
>: IANA is equivalent to attempting a conversation w/ /dev/null.

I have no doubt that it *was* true, but the new process and planned
assignment progress monitoring system should make it a thing of the past.

  Bill


P.S. In the WG meeting, people asked for a pointer to this agreement
on the IANA site.  There is no such announcement at the moment, but
they have agreed to put one there and I will forward the information
when I get it.

_______________________________________________
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 JAA03180 for <[e-mail]>; Wed, 3 Aug 2005 09:47:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JWt-0008I7-OX; Wed, 03 Aug 2005 09:43:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JWr-0008GP-Ur for [e-mail]; Wed, 03 Aug 2005 09:43:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16600 for <[e-mail]>; Wed, 3 Aug 2005 09:43:28 -0400 (EDT)
Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0K3V-0001bd-Th for [e-mail]; Wed, 03 Aug 2005 10:17:17 -0400
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 03 Aug 2005 21:46:37 +0800 (CST)
Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 03 Aug 2005 21:46:36 +0800 (CST)
Received: from l10814dell (open-29-186.ietf63.ietf.org [86.255.29.186]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004)) with ESMTPA id <[e-mail]>; Wed, 03 Aug 2005 21:53:01 +0800 (CST)
Date: Wed, 03 Aug 2005 21:43:08 +0800
From: Zhang Renhai <[e-mail]>
Subject: Re: Re: [Idr] Re:Commentsondraft-zhang-idr-bgp-entire-routes-reflect-00.txt
To: Manav Bhatia <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Foxmail 4.2 [cn]
Content-type: text/plain; charset=GB2312
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Cc: "[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 JAA03180

Hi, Manav

  Sorry for replying you so late.

  Actually, I think if the attribute of any route is not changed when
forwarding, then loop will not occur.

Thanks,
Zhang 
	

======= 2005-07-30 08:03:00£º=======

>Hi Zhang,
>
>Besides proposing a way to advertise multiple paths,
>draft-bhatia-ecmp-routes-in-bgp-01.txt also discusses how an implementation
>should construct its AS_PATH wherein the path length is preserved and
>sufficient information is provided to avoid loops, if its using equal cost
>BGP paths for its forwarding.
>
>Thanks,
>Manav
>
>----- Original Message ----- 
>From: "Zhang Renhai" <[e-mail]>
>To: "Alvaro Retana" <[e-mail]>; "Tulip Rasputin"
><[e-mail]>
>Cc: <[e-mail]>; <[e-mail]>
>Sent: Friday, July 29, 2005 11:45 AM
>Subject: Re: [Idr]
>Re:Commentsondraft-zhang-idr-bgp-entire-routes-reflect-00.txt
>
>
>> Hi, Alvaro
>>
>>  I think this is an interesting topic because there are now three drafts
>addressing it
>> I recently looked through other two drafts,  one is yours and other is
>> draft-bhatia-ecmp-routes-in-bgp-01.txt,  and I think the goal is basically
>same but the
>> mechanism to achieve it is very different. If you will, I'd like to
>discuss with you next
>> week at Paris if the meeting time is not enough to talk.
>>
>> Cheers,
>> Zhang
>>
>> ----- Original Message ----- 
>> From: "Alvaro Retana" <[e-mail]>
>> To: "Tulip Rasputin" <[e-mail]>
>> Cc: <[e-mail]>; <[e-mail]>
>> Sent: Thursday, July 28, 2005 5:16 AM
>> Subject: Re: [Idr] Re:
>Commentsondraft-zhang-idr-bgp-entire-routes-reflect-00.txt
>>
>>
>> > On Tue, 19 Jul 2005, Tulip Rasputin wrote:
>> >
>> > Tulip:
>> >
>> > -> !> Would you be so kind to comment what proposed in your draft has
>not
>> > -> !> already been addressed in our ADD_PATHs proposal RR !>
>functionality
>> > -> wise ?
>> > ->
>> > -> I see absolutely nothing wrong in this!
>> > ->
>> > -> There isnt any rule in the IETF that forbids multiple submissions to
>> > -> achieve the same objective. Its left on the community to decide which
>> > -> proposal they are most comfortable with. If it happens to be the
>draft
>> > -> thats been submitted later, then so be it!
>> > ->
>> > -> IETF is an open standards body, in case you forgot that, and nothing,
>> > -> is patented here. If you dont want others to address the same issues
>> > -> that you've been trying to solve, then IETF isnt really the right
>place
>> > -> for you to start with!
>> > ->
>> > -> YOu should be patenting your ideas, but then, nobody else is going to
>> > -> implement them.
>> >
>> > I think Robert was only asking Zhang to compare...nothing else.
>> >
>> > In any case, I think we can all agree about the openness of the IETF,
>> > multiple solutions, community, etc..
>> >
>> > Just to clarify, we have no IPR claims over any part of the ADD_PATH
>work.
>> > Also, We have posted an update to the draft and plan to talk about it
>next
>> > week.
>> >
>> > Thanks!
>> >
>> > Alvaro.
>> >
>> > -> !> Ref: draft-walton-bgp-add-paths-03.txt
>> >
>> > _______________________________________________
>> > Idr mailing list
>> > [e-mail]
>> > https://www1.ietf.org/mailman/listinfo/idr
>>
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/idr

= = = = = = = = = = = = = = = = = = = =

¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Zhang Renhai
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡[e-mail]
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-08-03



_______________________________________________
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 SAA09934 for <[e-mail]>; Tue, 2 Aug 2005 18:10:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E04rt-0006oc-T9; Tue, 02 Aug 2005 18:04:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E04rr-0006oS-Au for [e-mail]; Tue, 02 Aug 2005 18:04:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19840 for <[e-mail]>; Tue, 2 Aug 2005 18:04:08 -0400 (EDT)
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E05OO-0004mF-2e for [e-mail]; Tue, 02 Aug 2005 18:37:50 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j72M3o942726;  Tue, 2 Aug 2005 15:03:50 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j72M3bG36901; Tue, 2 Aug 2005 15:03:37 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Subject: Re: [Idr] SAFI and other codepoint issues 
In-Reply-To: Your message of "Mon, 01 Aug 2005 17:02:22 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 02 Aug 2005 15:03:37 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: Alex Zinin <[e-mail]>, [e-mail], Bill Fenner <[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,

> I am unable to attend this IETF and am unable to bring this issue 
> up in front of the sitting working group. I'd like to suggest
> that the working group spend a few cycles on what I perceive to be
> an issue with code point assignments.
> 
> RFC 2858's IANA considerations requested the following:
> 
> :    As specified in this document, the MPL_REACH_NLRI and MP_UNREACH_NLRI
> :    attributes contain the Subsequence Address Family Identifier (SAFI)
> :    field. The SAFI name space is defined in Section 9. The IANA will
> :    maintain and register values for the SAFI namespace as follows.  SAFI
> :    value 0 is reserved. SAFI values 1, 2, and 3 are assigned in this
> :    document.  SAFI values 4 through 63 are to be assigned by IANA using
> :    the "IETF Consensus" policy defined in RFC 2434. SAFI values 64
> :    through 127 are to be assigned by IANA, using the "First Come First
> :    Served" policy defined in RFC 2434. SAFI values 128 through 255 are
> :    for "private use", and values in this range are not to be assigned by
> :    IANA.
> 
> (I never noticed the typo, MPL_REACH_NLRI :-)
> 
> By definition of RFC 2434, private use is:
> 
> :       Private Use - For private or local use only, with the type and
> :            purpose defined by the local site. No attempt is made to
> :            prevent multiple sites from using the same value in different
> :            (and incompatible) ways. There is no need for IANA to review
> :            such assignments and assignments are not generally useful for
> :            interoperability.
> 
> I am under the general impression that "private use" should NOT be used
> for any protocol mechanism standardized by the IETF.  However, a number
> of mechanisms, deployed or in the process of being deployed, are making
> use of these supposed "private use" codepoints.  For example, RFC 2547
> utilizes SAFI 128.
> 
> IANA seems to be tracking this usage:
> http://www.iana.org/assignments/safi-namespace
> 
> An author of one of these recent mechanisms put it to me during
> a review:
> 
> : IANA managed space is not a realistic option imho... the process to
> : get a number assigned takes too long given that it is usually tied to
> : WG/IESG approval. At least in my experience requesting a number from
> : IANA is equivalent to attempting a conversation w/ /dev/null.
> 
> It seems to me that FCFS is the appropriate mechanism for this.  I have
> no experience in getting a FCFS assignment from IANA so I can't vouch
> for whether this experience is typical or not.
> 
> For the working group, I'd like to ask: Is there a better way to 
> avoid collisions other than behind-the-scenes collusion between vendors?
> 
> For the area directors: Are there really issues with IANA?  Why are
> we approving protocol mechanisms with code point assignments in
> supposedly private space?  Why is IANA tracking them?
> 
> This issue, in the grand scheme of things, is minor.  Work gets done and
> code gets written.  However, it argues we have a procedural issue.

Thanks for bringing this up. May I suggest that folks should look
at the discussion on the pwe3 wg mailing list subject "[PWE3] PWE3 
IANA policy - rough consesnus", as it is relevant to the topic brought
up here.

Yakov.

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


Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA15946 for <[e-mail]>; Mon, 1 Aug 2005 17:03:55 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzhQz-000838-D1; Mon, 01 Aug 2005 17:02:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzhQu-00080z-B6 for [e-mail]; Mon, 01 Aug 2005 17:02:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23027 for <[e-mail]>; Mon, 1 Aug 2005 17:02:46 -0400 (EDT)
Received: from gateout01.mbox.net ([165.212.64.21] helo=gwo1.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzhxC-0001KA-Ok for [e-mail]; Mon, 01 Aug 2005 17:36:14 -0400
Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gwo1.mbox.net (Postfix) with SMTP id AA55E12D849; Mon,  1 Aug 2005 21:02:25 +0000 (GMT)
Received: from gateout01.mbox.net [165.212.64.21] by gateout01.mbox.net via mtad (C8.MAIN.3.17K)  with ESMTP id 902JHaVcX0228Mo1; Mon, 01 Aug 2005 21:02:23 GMT
Received: from gw4.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.21U); Mon, 01 Aug 2005 21:02:23 GMT
X-USANET-Source: 165.212.116.254 IN   [e-mail] gw4.EXCHPROD.USA.NET
X-USANET-MsgId: XID388JHaVcy4358Xo1
Received: from localhost ([65.247.36.31]) by gw4.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211);  Mon, 1 Aug 2005 15:02:23 -0600
Date: Mon, 1 Aug 2005 17:02:22 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail], Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
X-OriginalArrivalTime: 01 Aug 2005 21:02:23.0551 (UTC) FILETIME=[50622CF0:01C596DC]
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: Jeffrey Haas <[e-mail]>
Subject: [Idr] SAFI and other codepoint issues
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

I am unable to attend this IETF and am unable to bring this issue 
up in front of the sitting working group. I'd like to suggest
that the working group spend a few cycles on what I perceive to be
an issue with code point assignments.

RFC 2858's IANA considerations requested the following:

:    As specified in this document, the MPL_REACH_NLRI and MP_UNREACH_NLRI
:    attributes contain the Subsequence Address Family Identifier (SAFI)
:    field. The SAFI name space is defined in Section 9. The IANA will
:    maintain and register values for the SAFI namespace as follows.  SAFI
:    value 0 is reserved. SAFI values 1, 2, and 3 are assigned in this
:    document.  SAFI values 4 through 63 are to be assigned by IANA using
:    the "IETF Consensus" policy defined in RFC 2434. SAFI values 64
:    through 127 are to be assigned by IANA, using the "First Come First
:    Served" policy defined in RFC 2434. SAFI values 128 through 255 are
:    for "private use", and values in this range are not to be assigned by
:    IANA.

(I never noticed the typo, MPL_REACH_NLRI :-)

By definition of RFC 2434, private use is:

:       Private Use - For private or local use only, with the type and
:            purpose defined by the local site. No attempt is made to
:            prevent multiple sites from using the same value in different
:            (and incompatible) ways. There is no need for IANA to review
:            such assignments and assignments are not generally useful for
:            interoperability.

I am under the general impression that "private use" should NOT be used
for any protocol mechanism standardized by the IETF.  However, a number
of mechanisms, deployed or in the process of being deployed, are making
use of these supposed "private use" codepoints.  For example, RFC 2547
utilizes SAFI 128.

IANA seems to be tracking this usage:
http://www.iana.org/assignments/safi-namespace

An author of one of these recent mechanisms put it to me during
a review:

: IANA managed space is not a realistic option imho... the process to
: get a number assigned takes too long given that it is usually tied to
: WG/IESG approval. At least in my experience requesting a number from
: IANA is equivalent to attempting a conversation w/ /dev/null.

It seems to me that FCFS is the appropriate mechanism for this.  I have
no experience in getting a FCFS assignment from IANA so I can't vouch
for whether this experience is typical or not.

For the working group, I'd like to ask: Is there a better way to 
avoid collisions other than behind-the-scenes collusion between vendors?

For the area directors: Are there really issues with IANA?  Why are
we approving protocol mechanisms with code point assignments in
supposedly private space?  Why is IANA tracking them?

This issue, in the grand scheme of things, is minor.  Work gets done and
code gets written.  However, it argues we have a procedural issue.

-- 
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 NAA04085 for <[e-mail]>; Mon, 1 Aug 2005 13:30:53 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dze71-0004D2-Nb; Mon, 01 Aug 2005 13:30:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dze6y-0004Bt-I6 for [e-mail]; Mon, 01 Aug 2005 13:30:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25870 for <[e-mail]>; Mon, 1 Aug 2005 13:29:57 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzedF-0003qH-Gs for [e-mail]; Mon, 01 Aug 2005 14:03:24 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j71HTeBm084955; Mon, 1 Aug 2005 10:29:40 -0700 (PDT) (envelope-from [e-mail])
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j71HTdG69876; Mon, 1 Aug 2005 10:29:39 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "DUBOIS Nicolas ROSI/DAS/ARI" <[e-mail]>
Subject: Re: [Idr] IDR WG agenda 
In-Reply-To: Your message of "Tue, 12 Jul 2005 16:51:17 +0200." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 01 Aug 2005 10:29:39 -0700
From: Yakov Rekhter <[e-mail]>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: [e-mail], "'Yakov Rekhter'" <[e-mail]>, FONDEVIOLE Benoit RD-CORE <[e-mail]>, DECRAENE Bruno RD-CORE <[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]

Nicolas,

> Hi Sue, Yakov,
> 
> Would it be possible to have a 10 min slot at the next IETF GROw meeting in
> order to present an updated version (to be posted soon) of the following
> draft: 
>   
> http://www.ietf.org/internet-drafts/draft-dubois-bgp-pm-reqs-01.txt 
>   
> We also requested a slot in the GROw working group. We do not know if it is
> better to present the draft in grow, in IDR or in both ?

I still did not receive the slides. Please send them to me asap.

Yakov.

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