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

[Danny McPherson <[e-mail]>]

On Apr 30, 2008, at 9:30 AM, John G. Scudder wrote:

> Danny:
>
> I get that you have a bad feeling about the idea.  Can you provide
> some specifics, though?  As far as I can tell, the proposed extension
> is safe (for the same value of "safe" as the rest of the
> protocol...).  See also my comments below regarding defaulting it off.

Take, for example, the case where the client doesn't know how
to handle the new community and some routing information loop
results.

I saw this occur in a real network when vendor 'n' changed their
RR behavior to that of 2796 and reflected routes back to clients
while the clients, vendor 'm', didn't know they were supposed to
drop the routes.

Additional configuration would be required to avoid the above,
and even more care would now be required to setup congruent
or overlay BGP topologies - while localized configuration is what
you're trying to avoid on the PEs in the application provided.

I suspect there are other scenarios where this could occur,
in particular if hierarchal RRs are used, etc..,

> With regard to some of your other points, I think the proposed feature
> should be only be enabled if configured, i.e. the default should be
> the current behavior.  The draft should be updated to say this
> explicitly.  As long as it defaults to off, usage of the feature
> becomes a "consenting adults" thing.  As for your observations
> regarding specific deployments (e.g., disabled client-to-client
> reflection) I think it's reasonable to ask that the network operator
> know what they're doing before enabling the feature and will avoid
> using configurations which are broken!  This is no different than the
> situation today, since the possibility to configure the protocol in
> broken ways has always existed, nor is it unique to BGP.
>
> Finally, I don't agree with this point:
>
>> 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.
>
> In fact, very little new RR code would be required to take advantage
> of the feature.  The RR needs to be able to match on an RT, add an RT,
> and add the well-known community.  Matching and adding RTs (which are
> just extended communities) and adding other communities is existing
> functionality.  This requires additional configuration, but little or
> no new code.

Right, it's the client that needs most of the code..  Of course,
more than likely, the clients and the RRs will be on the same
code base - unless there are address family overlays constructed,
and then we're adding one more variable to the mis-configuration
opportunity mix, when some clients are older and can't support
newer code, then I've got a mix of topology and behavior types
that didn't previously exist.

How much configuration overhead is actually being saved
on the PEs that justifies changing basic BGP specification
behavior and introducing even more redundant network
state?

-danny
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr