Hi Brian, > directly from BGP4 collapseMaybe I have missed some threads on RRG but this is first time I see such term about "BGP4 collapsing". Why it this going to collapse ? What elements of BGP4 are going to collapse ? What would make it's replacement not to collapse ? I am just trying to understand your line of thinking in regards of BGP4 collapsing ....
In BGP4 we have a lot of machinery build into the protocol for it not to collapse. Most of them can be just configured in most of the shipping & deployed implementation of BGP. Introducing the explicit indirection in what we have today would make such configuration much easier.
Also ... are you saying that any proposal (like APT) which uses proven BGP4 for propagating mapping information will collapse while other proposals will last really long just because they do not use BGP4 ?
Thx, R.
Robert, On 2008-01-08 22:06, Robert Raszuk wrote:Hi Eliot,I agree with you. If ETR/ITR function will not be automatic and transparent to end sites running on a very lowest end boxes I think any of the solutions discussed here will completely fail deployment wise.That really depends on whether you expect the ETRs to be deployed by ISPs on behalf of SMB customers, or whether you expect the SMB customers to buy them at the supermarket. Since it's the ISPs that will suffer directly from BGP4 collapse, I think the economic incentive will apply to the ISPs. BrianCheers, R.Brian, > That appears to me to be a very big "if" except for large and > sophisticated customers; it seems to me that the large majority > of medium size sites will be very unlikely to run an ETR, even if > they are connected to more than one ISP. I think this depends on the complexity of running one. If it adds no operational complexity, why not have them in a Linksys box? Eliot
-- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg