Paul,

That's exactly the point I was making. IMHO the current draft could be 
the right place to accommodate this as this is just a subset of the VA 
overall idea.

Cheers,
R.

PS. Also as said I agree to use Trabants on the back roads. Some people 
are really attached to them :)))


> I see...so I think you are saying:
> 
> o   let's allow for a special case of VA where there is a single virtual
> prefix which is a /0 (the default route),
> 
> o   that this works perfectly well for ISPs who design their POPs such that
> the default routes feed into routers that contain the full FIB (using
> existing anycast-like failover techniques), 
> 
> o   that if you run it this way, then the question of what goes in the FIB is
> simplified (i.e. anything or nothing for edge routers, everything for "full"
> routers), and therefore you no longer have to tag the default route with an
> attribute calling it a VP.
> 
> o   edge routers can still keep the full RIB in order to peer with external
> peers, or we use the multi-hop BGP trick to get the "full" router to peer
> with external peers (FAIW, we mention this in the tech report cited in the VA
> draft)
> 
> 
> If I'm getting you right, this seems very reasonable to me.  Do you think it
> makes sense to modify the current draft to include this case, or to make it a
> separate thing?  
> 
> To extend your highway analogy, I agree that you don't want Trabants on the
> autobahn, but it is reasonable to continue to use them on back roads...
> 
> PF
> 
> 
>> -----Original Message-----
>> From: Robert Raszuk [mailto:raszuk@juniper.net]
>> Sent: Friday, July 11, 2008 7:29 AM
>> To: Paul Francis
>> Cc: curtis@occnc.com; idr@ietf.org
>> Subject: Re: [Idr] draft on virtual aggregation
>>
>> Hi Paul,
>>
>>>> True that some networks do not have the core ... the network can be
>>>> meshed edges or more specifically meshed POPs.
>>>>
>>>> A very simple observation can be made that you can use a tunnel from
>>>> the
>>>> edge to one router (per POP for example) do IP lookup then
>> encapsulate
>>>> to the exit point. In that scenario your edge routers are free from
>>>> carrying full table and due to shift in the place where single IP
>>>> lookup
>>>> is done and switching decision determined.
>>> This would overload that one router, as well as create a point of
>> failure.
>>  > So you'd need to increase the capacity of that router, plus
>> replicate
>>  > it for failure.
>>
>> It needs to be noticed that this one router can be any of today's edge
>> router as if current edge handles full Internet table in FIB. The gain
>> is that all other edge routers do not any more keep state in FIB.
>>
>> Reg single point of failure ... of course not. Two such routers (per
>> POP
>> or in small AS per network) would anycast common next hop and we would
>> relay on IGP for failure detection and even for data packets in flight
>> redirection.
>>
>>> So in essence you are designing a core architecture.  The point
>>> behind VA is that you don't force ISPs to change their architecture
>> and
>>
>> Disagree 100%. VA is what I described + dividing the address space into
>> chunks.
>>
>>> upgrade their routers to deal with table growth.  Plus anyway you
>> can't do
>>> this for your edge routers that peer with ISPs that require the full
>> routing
>>> table, so this fix is quite limited.
>> Why not ? Remember we are dealing with FIB only. (My idea works with
>> RIB
>> as well using multihop ebgp session, but let's focus on FIB). Why ASBRs
>> peering with ISPs would require to store all the routes in FIB ?
>> Core/POP full nodes would attract all traffic make switching decision
>> then encapsulate and ship. It is very much the same as Lixia's APT
>> model
>> except no mapping plane is needed :).
>>
>>>> It is clearly not true that vendors today have any issues in
>> delivering
>>>> boxes which could keep today's Internet table and at least allow for
>>>> 5-10 time it's grow. I know at least two of them which have been
>>>> shipping such routers for few years now.
>>> Yes I understand that there are routers that can hold 5x or 10x the
>> current
>>> table.  Your company makes them.  How long will these routers last,
>> given the
>>> "end-game" of IPv4 address allocation?  5 years ago the new
>> generation of
>>> routers looked like they could handle a lot of table growth, but now
>> they
>>> have run out of space and yet ISPs want to keep them.
>> If one have bought an ISP class router 5 years ago there is no reason
>> to
>> upgrade now capacity wise. 5 years ago internet table were about 130K
>> today is 270K src: http://www.cidr-report.org/
>>
>> Those routers 5 years ago were already design and ready to handle 1-2M
>> routes and not due to expectation of Internet growth ... due to
>> requirement for L3VPN deployments.
>>
>>> Basically you are
>>> telling them that the solution is simple---buy your latest product.
>> And to
>>> not worry about growth because you'll have yet another product for
>> them a few
>>> years down the road.  This is exactly what this draft is trying to
>> avoid.
>>
>> If we compare Internet to Highways your draft still is trying to keep
>> old Trabants going ... moreover bunch of them. It seems that they may
>> be
>> at some point became an obstacle on the road and it may be much better
>> to find other uses for them then carrying passengers.
>>
>> What I proposed is to keep all of those still running on the edge while
>> based the
>>
>>
>>>> And such architecture does not require dividing address space in any
>>>> chunks and can be deployed today on any exiting hardware without
>>>> waiting
>>>> for any new protocol extensions.
>>> I'm not sure what you mean by "such architecture".  But many existing
>> routers
>>> in the field today cannot realistically use the kind of trick you
>> mention
>>> above to manage FIB size.  Rather, they resort to simply dropping
>> some
>>> fraction of routes, for instance.
>> What would be a single reason why at least pair of routers in any ISP
>> could not carry full Internet table today in FIB ? I know quite a few
>> ISP & SP networks worldwide and can't find any such example. Rest of
>> the
>> edge routers could function just fine without even slight need to drop
>> anything.
>>
>> My proposal is a special case of yours ... So saying that routers in
>> the
>> field can not support this means that your proposal suffers from the
>> same.
>>
>> The overall idea is good it is just I want to make sure that in
>> whatever
>> form this work goes forward ISP MUST be allowed to have single VA as
>> well.
>>
>> And that would not require any new protocol extension as BGP could
>> inject such default route today with next hop being APR.
>>
>> That means that the extended community attribute you are proposing
>> should be optional as well.
>>
>>> To be clear, we are talking about one new attribute, zero changes to
>> the data
>>> plane, zero changes to the existing BGP decision process....just some
>> rules
>>> for automatically setting up tunnels and new address aggregates
>> (virtual
>>> prefixes).  Better to do this now well before the next generation of
>> routers
>>> runs out of FIB.
>> My concern is not about adding new attribute. The concern is about the
>> additional deployment, operational and troubleshooting difficulties it
>> will introduce.
>>
>> Having forwarding boxes partitioned with different information (which
>> will have to be statically managed by hand) is very error prone. It
>> also
>> have other consequences including the need redesign on behavior of fast
>> reroute technics or HA features. It is not the steady state of
>> operation
>> where things go out of control.
>>
>> Cheers,
>> R.
> 

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr