Subject: [Idr] BGP confederations and MED

From: "Ilya Varlashkin" <[email-masked]>
Date: Thu, 17 Aug 2006 00:09:23 +0200

Hello,

I was went through several BGP-related RFC (4271, 3065, 3345) looking
for info on how MED should be treated within confederation, but could
find definetive answer.

Consider a confederation consisting of AS 65001, 65002 and 65003 and
peers with external AS100. A router within AS65003 has learned
following:

192.168.1.0/24	AS_PATH: (65001) 100  MED 10   NEXT_HOP_IGP_COST   10
192.168.1.0/24     AS_PATH: (65002) 100  MED 20   NEXT_HOP_IGP_COST   5

Is it valid to compare MED of this two path's? I know that at least in
one implementation with default configuration only exteral peer AS will
be use to decide whether MED are comparable or not, therefore in above
situation first path (65001) 100 will be selected. Is this is universal
behaviour or not?

The closest related info I could find in RFC was that a)
AS_CONFED_SEQUENCE influences AS_PATH length for decision purpose; b)
using confederations one should be careful selecting MED values; c)
avoid BGP route selection based on MED. But none of this really says
whether it's first AS in first AS_SEQUENCE (i.e. real external AS)
should be the same or first AS must be the same including AS in
AS_CONFED_SEQUENCE if that happens to be first (i.e. MED compared only
for routes learned from the same member AS peer).

Concern here is consistency between implementations - if one
implementation requires only external peer AS to be the same for
comparing MED, while another takes also into account confederation
member AS, then routing loops may occur. Looks like it makes more sense
to require only external AS to be the same and perhaps all current
implementations are compliant with this behaviour, but I thought it may
make sense mention somewhere about such process just to ensure
consistency. RFC3065, and therefore draft rfc3065bis, seems to be
appropriate place for it, though beeing in last call I guess it's too
late to make such addition.

Kind regards,
iLya

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr