Subject: Attribute manipulation on routes announced to a RR client

From: Martin Clouatre <[email-masked]>
Date: Thu, 14 Nov 2002 14:17:41 -0500

The BGP Route Reflection RFC specifies the following:

======================================================
8. Implementation and Configuration Considerations 
[...] In some implementations, modification of the BGP path attribute,
NEXT_HOP is possible. For example, there could be a need for a RR to modify
NEXT_HOP for EBGP learned routes sent to its internal peers. However, it
must not be possible for an RR to set on reflected IBGP routes as this
breaks the basic principle of Route Reflection and will result in potential
black holeing of traffic. An RR should not modify any AS-PATH attributes
(i.e. LOCAL_PREF, MED, DPA)that could change consistent route selection.
This could result in potential loops. The BGP protocol provides no way for a
Client to identify itself dynamically as a Client to an RR configured BGP
speaker and the simplest way to achieve this is by manual configuration. 
================================================

I have two questions about that statement:

FIRST QUESTION
I think this statement should also specify that a RR should not perform
outbound route filtering on reflected IBGP routes. Do you agree?

SECOND QUESTION
I did not find any equivalent statement in the BGP confederation RFC. Why is
that?
Bad attribute manipulation when advertising IBGP routes to an EIBGP peer can
also result in loops. 
My understanding is that, when a BGP router advertises an IBGP route to an
EIBGP peer, it should not be allowed to modify any AS-PATH attributes that
could change consistent route selection.

Martin Clouâtre, ing 
développement logiciel - équipe BGP 
[email-masked] < <mailto:[email-masked]>> 
www.hyperchip.com < <http://www.hyperchip.com/>> 
tél : 514.906.4922 
fax: 514.906.2484 

Venez rencontrer Hyperchip à :
Lightspeed Europe 02 - London, UK - Tues, Dec 3rd @ 2:15pm - Richard Norman,
panelist, "Future Network Architectures"

Prenez connaissance de nos présentations à SUPERCOMM  disponible en ligne à
www.hyperchip.com/supercomm <http://www.hyperchip.com/supercomm>

---

From: Danny McPherson <[email-masked]>
Date: Thu, 14 Nov 2002 16:58:30 -0700

> outbound route filtering on reflected IBGP routes. Do you agree?

No.  Route filtering is considered an implementation and/or 
deployment issue.
 
> SECOND QUESTION
> I did not find any equivalent statement in the BGP confederation RFC.
> Why is that?

Section 7 of RFC 3065 does provide some discussion of this.

> Bad attribute manipulation when advertising IBGP routes to an EIBGP
> peer can also result in loops.

With consideration of RFC 2065, can you provide an example?

> My understanding is that, when a BGP router advertises an IBGP route to 
> an EIBGP peer, it should not be allowed to modify any AS-PATH attributes
> that could change consistent route selection.

Did you mean "AS-PATH attributes" or "path attributes"?  Either way, 
I believe the current text suffices.  However, if you'd care to provide 
specific examples with which you're concerned we'll certainly considering 
addressing them in the next revision, if need be.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Thu, 14 Nov 2002 17:06:33 -0700

> With consideration of RFC 2065, can you provide an example?
                            ^^^^
This was obviously supposed to be 3065.

-danny

---

From: Martin Clouatre <[email-masked]>
Date: Fri, 15 Nov 2002 08:50:19 -0500

OK here is more details about my concerns.

From section 8 of RFC 2796 (RR), I understand that a router should not allow
a user to perform attribute manipulation (via an outbound route map for
instance) on reflected routes.
   "Care should be taken to make sure that none of the BGP path
   attributes defined above can be modified through configuration when
   exchanging internal routing information between RRs and Clients and
   Non-Clients."

From section 7 of RFC3065 (confed), I understand that some EBGP rules can be
broken when doing EIBGP. For instance, LOCAL_PREF can be used and MED must
be preserved. However, there is not a statement similar to the one above
specifying if user could manipulate those attributes anyway through
configuration. 

In fact, my concerns is: Is an implementation allowed to provide
configuration tools to the user to manipulate attributes on routes reflected
to a RRclient or on routes announced to an internal peer in the confed? I
noticed that Cisco's route map attribute manipulation has no effect on
reflected routes. Is that an implementation detail or is that based on RFC?
However I did not see any equivalent behavior in the context of confed. Why
not? Both mechanisms are used to reduced the full mesh. Therefore they
should be implemented in consistent manners.

In my previous message, by "AS-PATH attributes", I meant "path attributes",
i.e. MED, LOCAL_PREF, ORIGIN, etc., that can have an impact on the BGP
decision process. Sorry for the ambiguity.

Thanks in advance you for your valuable inputs...

Martin Clouatre

-----Original Message-----
From: Danny McPherson [mailto:[email-masked]]
Sent: Thursday, November 14, 2002 6:59 PM
To: [email-masked]'
Subject: Re: Attribute manipulation on routes announced to a RR client

 

-danny

---

From: Danny McPherson <[email-masked]>
Date: Fri, 15 Nov 2002 10:17:50 -0700

> to a RRclient or on routes announced to an internal peer in the confed?

In reality, an implementation can provide whatever configuration 
capabilities they wish, though they should be cautious not to break 
anything and that what they're doing works for the folks that are 
intending to deploy it.

> I noticed that Cisco's route map attribute manipulation has no effect on

Uhhmm.., an implementation detail based on the RFC and deployment....?
For example, an RR would likely want to set the NEXT_HOP attribute 
value to 'itself' for EBGP learned and advertised routes but probably 
not for routes that are 'reflected'.  How else would this be 
accomplished? 

On the other hand, an EIBGP Member-AS border router would likely want 
to modify the NEXT_HOP value for routes advertised to other Member-ASs.

> should be implemented in consistent manners.

But they're NOT deployed in consistent manners.  Often Member-ASs of a 
confederation are under different administrative control, run separate
IGPs, employ RR for inter-Member-AS hierarchy, etc..  Much of the control 
over attribute manipulation you're seeing in existing implementations 
has been implemented as such as a result.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Fri, 15 Nov 2002 10:20:06 -0700

> IGPs, employ RR for inter-Member-AS hierarchy, etc..  Much of the 

s/inter-Member-AS/intra-Member-AS/

-danny