Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt

["Ilya Varlashkin" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Danny McPherson
> Sent: Wednesday, April 30, 2008 6:39 AM
> To: idr idr
> Subject: [Idr] Fwd: I-D 
> ACTION:draft-pmohapat-idr-acceptown-community-01.txt
> 
> 	
> Surprisingly, I don't recall seeing this draft discussed here yet.
> 
> In short, I think the is a really bad idea.  It's bad enough 
> the route reflection spec was changed from 1966 to 2796 to 
> permit an RR to reflect routes to a client even if they were 
> learned from that client - arguably, to enable an 
> implementation optimization, but for this to recommend a 
> well-known community and further recommend disabling RFC 1966 
> "suppression" on the RR if the BGP community is present in 
> order to save configuration overhead on the PEs is going a 
> bit overboard.
> 

I share Danny's view regarding this proposal. To me it seems like
ACCEPT_OWN doesn't add anything what is not possible today, while
potentially creates opportunities for new bugs in the heart of BGP route
handling both on RR and edge routers; as well as, from operational
prospective, undermining stable operations of the route reflector(s). 

Often operations of the core network and the edge are split between
different teams, and route reflectors are often operated by the core
team who needs to ensure that network runs fine as whole, once setup
RR's are usually left intact. ACCEPT_OWN implies that policies regarding
inter-VPN route import/export will shift from the edge to the core,
while still being operated by edge/access team. Due to misconfiguration
on RR during manipulation of inter-VPN policies, there will be risk to
affect routing stability of the whole network, which is bad idea.

Usually RR's do not have specific VPN's defined and just relay routes
based on generic BGP rules. ACCEPT_OWN will require RR to be aware at
least of some VPN's (many in fact, else it doesn't make sense). This
will require extra work on RR part, extra data structures, code, meaning
more opportunities for things to go wrong.

Next, it's quite possible that for the path optimisations BGP clients
will peer not only with RR, but also between themselves and
client-to-client reflection is disabled. This will break integrity of
the routing information within AS since RR will send modified updates
only to non-clients, while clients within the cluster will still have
original unmodified information about given prefix.

Last, same functionality as offered by ACCEPT_OWN is reasonably easy
implemented on PE via generic policies that are setup once VRF
provisioned. Complexity that is necessary to mark prefixes with
ACCEPT_OWN community is on par with complexity necessary to tag prefixes
with something else and use generic policies locally on PE. So at the
end of the day, moving policies to RR isn't magic bullet that will
eliminate need for any work on PE, and on the other hand efficient
generic policies can make PE configuration as easy as it would be done
on RR.

Kind regards,
iLya
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr