Subject: mboned: draft-ietf-idr-rfc2858bis-07.txt, SAFI=3 removed?

From: Pekka Savola <[email-masked]>
Date: Wed, 24 Aug 2005 08:47:46 +0300 (EEST)

Hi,

On Tue, 23 Aug 2005 [email-masked] 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
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 24 Aug 2005 06:38:05 -0700

> reviewed by multicast communities?

Which IETF process are you referring to when you say "reviewed by
multicast communities". AFAIK, there is none. My best impression of
the process was "If you care what happens in BGP you need to go to IDR".

Also, who is "the multicast community" ?  Mboned ?

But this is not new, SAFI=3 removal was in the draft for a long time
(i'd guess 3 years at least ?), and that's how long i think most
everybody who does care is aware of this. I think to remember that i
quite vocally complained about the process in the IETF that IDR decided
on this by themselves, which like anything else in the IETF was acknowledged
with a well trained shrug of compassion. I would have expected something
like people from IDR who would want to represent this change to do it in
MBoned at some point, but i am not aware that this ever happened at an MBoned
meeting (except for Bill standing up at some point in time in i think
MBoned, explaining that he was the only one amongst a herd or BGP folks in
IDR pointing out the downsides of this decision).

To me this is just another one in "a series of unfortunate events" around
BGP helping to make multicast more complex than necessary and less scalable,
but as far as i am concerned this one is gone, and won't change. Of
course i think it's not good:

  I think that routing protocols (not BGP only, but BGP too) should 
  have a preference in scalability and performance for networks with
  congruent unicast/multicast topologies while still allowing to introduce
  incongruency without having to redesign your routing protocol configuration
  - but if you have such incongruency, then this is ok. to be more expensive
  within the protocol (memory/cpu).

With just SAFI=1 and SAFI=2, it's always as expensive to
have a congruent topology as it is to have a non-congruent topology,
and obviously, there will be customers who don't lilke that , so they
will ask to also use SAFI=1 BGP routes for multicast RPF because they
have completely congruent topologies, so you implement a hack in your
software that can support this, and then later on at some place of the
topology you get an incongruency, and then this hack bites you because 
now you're starting again to compare SAFI=1 and SAFI=2 routes in your 
multicast RPF, and they happen to have different prefix length - like
the SAFI=1 route has a longer prefix length and so you need to rewalk 
your transitive topology, remove the hack and export everything correctly
as SAFI=2 for multicast so that you don't start trying to use your 
unicast-only paths with longer prefixes, or you hack it to export
exual prefix length SAFI=2 routes for every SAFI=1 route you know to
override them based on better distance, which isn't a completely valid
alternative to shoot yourself into the feet, ... and so on.

That's the status that we have in our IPv6 multicast implementation,
eg: We do support SAFI=1 and SAFI=2 and do not use SAFI=1 for multicast
RPF, unless the customer complains enough and wants it easier (no duplication
of all routes from SAFI=1 into SAFI=2), then i guess we can let ourselves
be forced to tell the customer the hidden command to allow using SAFI=1
in multicast RPF-lookup, and then i guess we need to wait another few years
before the config explodes (like described above) in the customers face.

Obviously, the main message we give to customer is that they _MUST_
always use SAFI=2 BGP multicast RPF, no questions asked, but how well that
will stick... Depends on the price of memory for routers i guess vs. 
the amount of incongruency in the network.

This is of course also a problem of not having the operational recommendation
from MBoned to exactly operate BGP in the way implied by the BGP draft, and
to condem shortcuts like "use SAFI=1 routes for multicast RPF" as far as
operational practices of the IETF go... I think something like that would
certainly be helpfull to avoid issues like explained above and steer
customers further away from hacks then we as a vendor alone can do.

Just to throw in a word for the other side of this dicussion: of course 
a BGP implementation itself is easier with just SAFI=1 and SAFI=2. There
are implementation complexities in BGP with SAFI=1,2,3. The analysis in
which circumstances SAFI=3 would provide significant memory savings without
simultaneously making best-path calculation time unacceptably higher is
difficult, but of course a lot of this complexity also comes from the
fact that BGP was never designed to support such multi-topology announcements
with congruency optimization well. I think the the analysis would 
have been "sorry, SAFI=3 is the right idea to best scale for desired
(mostly congruent) unicast/multicast topologies, but it would just mean
too many changes in BGP to support it effectively such that it provides
scaling benefits - aka: the protocol sucks so we can't do it well, so let's
get rid of it".

I am not a BGP (implementation) expert, i just try to remember the 
conclusion of the discussion we had on this. But whatever the analysis
and it's conclusion (and i bet that BGP zeleats would be capable to sell
SAFI=1,2 only as a great improvement for mankind), i think it should have
been put into an ancillariy IDR document and used as a reference in the 
new BGP draft to justify the decision to get rid of SAFI=3. But that of course
would have been too much work writing down. IETF decisions are just made,
they are not explained.

> result in two sets of prefixes for SAFI=1, then SAFI=2 or just 

Depends on implementation. Hopefully no vendor did the cool thing
and implemented SAFI=3 or else that vendors effort will have been nicely
invalidated by IDR. But that would have had to be an autistic vendor anyhow.

So in summary: The decision is set, the IETF process sucked,
the protocol change is in the draft, the operational fallout will
comne down the road, what else is new ? Let's move on, there are far
more exciting catastropies down the road for BGP.

Cheers
	Toerless

---

From: Bill Fenner <[email-masked]>
Date: Fri, 26 Aug 2005 13:36:35 -0400

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