Re: [Idr] draft-uttaro-idr-bgp-persistence-01 as IDR WG document - 3 more weeks

[Robert Raszuk <[e-mail]>]

Hi Hannes,

I am glad you fundamentally agree. Just a few follow-up comments ...

>> It is about running services BGP and IP BGP together which I am
>> questioning. Keyur and I had a draft http://goo.gl/GWrIs "Transport
>> Instance BGP" to allow for clear separation of the two instances.
>
> thats a valid concern - although i have to say that the TI draft is
> more about implementation and not protocol spec ;-)

Not really. All it does is clear separation between two BGP instances. 
Sure you can separate them with multisession - what was actually John's 
response in next rev of multisession draft after transport instance got 
posted .. however we went nowhere with both as a result :(

> wrt to TI -  why
> restrict to internet vs. non-internet  - to some e.g. the labeled-BGP
> infra may appear more crucial than the internet service itself. - i
> can certainly see the need for a *proper* separation between BGP
> service instances.

100% agree. In fact I would see labeled-BGP to belong to IP/Routing 
instance .. solid as it can be. That is an infrastructure for a service 
not a service itself.

Besides the TI draft made it very clear that the choice which AFI/SAFI 
is served by which instance would be not be up to IETF but would be left 
to the operator.

The problem with the latter approach of each SAFI having separate 
instance seems to be really difficult to handle by IETF if protocol 
would differ on a per SAFI basis. That's why TI took a very pragmatic 
approach to just allowing number of instances equal 2. But this could be 
up to discussion. Currently we have one or any instance served by the 
same very protocol hence the collisions of group who on one hand want to 
protect the IP/Routing and those on the other hand who careless about IP 
Internet, but do care about their services.

And the most interesting part is that both may be actually correct in 
their own views. Unfortunately single BGP protocol instance causes the 
collision of interests.


>> Yes I realize that for you it means more code to maintain so there
>> is price to that. The only question I think which should be stated
>> if perhaps cost vs benefit of such separation is getting to right
>> more now.
>
> unless we have a proper fault containment within any given
> implementation of BGP, we can only try to control the failure
> behavior of routing software, and its garbage collection mechanisms.

I do agree but that is an implementation. I am just focusing on the 
value of protocol delta between different uses of BGP instances.

> i think extended-GR plus the ability to restart a single AFI/SAFI
> anytime when the TCP session already has been established would be
> more flexible than todays integrated approach where addition/deletion
> of an AFI/SAFI always restart in a complete restart of the entire
> session.

Does not need to. Dynamic capabilities have been invented long time back 
and some are even implementing it :) No longer you need to restart the 
entire session to add or delete a new SAFI.

Ability to restart single AFI/SAFI is again an implementation choice in 
my view.


>> I think if we would address each problem space separately we would
>> be much better off with finding the right solution to both
>
> i think if you fix BGP implementation and allow graceful restart of
> sessions and session instances, then you do not need to worry that
> much about the failure behavior and how to mitigate that.

Maybe ... I am not convinced. Clearly persistent folks are not convinced 
too - otherwise they would not be pushing for it, but instead would be 
banging your door to get new junos version soon :-)


> true - multipathing is a viable way of cheating around the problem of
> control-plane failure ;-)

A lot of people consider cheating as a bad thing. So I would not call it 
that way. For me this is rather robust network design.


>> In GR you could allow that for 1h .. it is already too long. But to
>> allow that for more I am of the opinion that this is not BGP but
>> NETCONF.
>
> garbage collection intervals of stale prefixes should entirely an
> operators choice. SPs know how large their RIBs are and they know
> when its time to clean up stale prefixes;

At this point the spec does not allow that. If STALE is stripped by 
someone there is no base to do any garbage collection any more. Besides 
when each AS would choose to do different time for such garbage 
collection you can imagine what would happen right ?

R.