Robert -In the L3VPN WG I asked a question on your use of well-known BGP communities in this draft (as it is related to the IANA BGP Well- Known Communities reservation procedures discussed in IDR). The question was "how do you know when the community is well-known throughout the internet or service provider network?" You answer was "it is off by default and you have to configure it to be on, therefore the operator knows what they are doing." That is a fine answer but, you are using this as a reserved codepoint vs the semantics of well-known communities (in which if a router receives the well-known community whether configured or not, action is taken). Does anyone care about the change of semantics and a router will not pay attention to the community without configuration?
Thanks -DWard On Apr 29, 2008, at 11:38 PM, Danny McPherson wrote:
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. -danny Begin forwarded message:Content-Type: text/plain<BR>Content-ID: <2008-4-25141805.I- D at ietf.org><BR><BR>From: Internet-Drafts at ietf.org Date: April 25, 2008 3:30:01 PM MDT To: i-d-announce at ietf.org Subject: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt Reply-To: internet-drafts at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP ACCEPT_OWN Well-known Community Attribute Author(s) : J. Uttaro, P. Mohapatra, D. Smith, R. Raszuk, J. Scudder Filename : draft-pmohapat-idr-acceptown-community-01.txt Pages : 8 Date : 2008-4-25 It may be useful for a BGP speaker in an autonomous system to receiveand accept its own advertised route from a route reflector with morefine-grained route control. For example, the route reflector can change certain attributes of a route as desired, and then re-advertise it back to the originator. Though it is possible to performsuch policy control directly at the originator, it may be operationally cumbersome in a network with a large number of border routers having complex BGP policies. This draft defines a new and well-known BGP community value, ACCEPT_OWN, that signals a BGP speaker to accept an UPDATE messageand process the associated routes even when the ORIGINATOR_ID or theNEXT_HOP matches that of the receiving speaker. A URL for this Internet-Draft is:http://www.ietf.org/internet-drafts/draft-pmohapat-idr-acceptown- community-01.txtInternet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft._______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt_______________________________________________ Idr mailing list Idr at ietf.org https://www.ietf.org/mailman/listinfo/idr
_______________________________________________ Idr mailing list Idr at ietf.org https://www.ietf.org/mailman/listinfo/idr