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

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:
>
>> From: Internet-Drafts@ietf.org
>> Date: April 25, 2008 3:30:01 PM MDT
>> To: i-d-announce@ietf.org
>> Subject: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt
>> Reply-To: internet-drafts@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 receive
>>   and accept its own advertised route from a route reflector with  
>> more
>>   fine-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  
>> perform
>>   such 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 message
>>   and process the associated routes even when the ORIGINATOR_ID or  
>> the
>>   NEXT_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.txt
>>
>> Internet-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.
> Content-Type: text/plain<BR>Content-ID: &lt;2008-4-25141805.I- 
> D@ietf.org&gt;<BR><BR>
>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@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@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr