[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures

Hi Brian,

> Well, we're here because of the concern that BGP4 updates will become
> prohibitive as multihoming expands, aren't we ?

It is actually a very good question why we are here :).
There was a number of reasons stated in Amsterdam IAB meeting. I don't think there was one stating that "BGP4 updates will become prohibitive".
Today BGP runs flat with next hops rewritten at each EBGP peering. APT is a first attempt I see to make it run in real hierarchy by just calling next hops as locators and keeping it unchanged across EBGP boundaries.
There are other ideas along the same lines and few trying to replace BGP control plane with something virtual ... something new.
I do encourage all ongoing research for a better control plane especially having it's deployment targets 5-10 years from now.
But I would like to also see the real list of what are the issue in BGP we are trying to address ... Is this point-to-point model, is this TCP transport, is this update format ... No one yet stated what is broken. And when we do not know what is broken .. or which link of BGP chain is fragile it is quite a challenge to design new thing around the unknown. 

Cheers,
R.




On 2008-01-09 10:24, Robert Raszuk wrote:
 > Hi Brian,
 >
 >  > directly from BGP4 collapse
 >
 > Maybe 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 ....

Well, we're here because of the concern that BGP4 updates will become
prohibitive as multihoming expands, aren't we?

     Brian

 >
 > 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.
 >>
 >>     Brian
 >>
 >>>
 >>> Cheers,
 >>> 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