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

[Enke Chen <[e-mail]>]

Hi, Danny:

Regarding the specific change from 1966 to RFC 2796 that you mentioned, 
the reason was to make the spec. be consistent with the deployment 
(which has the behavior since Day 1 of the RR era).   AFAIK, there is 
nothing unusual about it in the iterative process for a protocol, and it 
is not alone. Take RFC 4271 as an example, one of the changes is the 
following:

     UPDATE Message Error subcode 7 (AS Routing Loop) has been deprecated.


The change reflects deployment and allows for implementation flexibility.

-- Enke

Danny McPherson wrote:
> On Apr 30, 2008, at 11:45 AM, John G. Scudder wrote:
>   
>> The nice thing is that the feature is backward compatible and fails
>> safe -- if the client doesn't know how to handle the community, then
>> it sees itself in the ORIGINATOR_ID and drops the route.  No route, no
>> routing information loop.  Granted the behavior of dropping the route
>> is undesired, but not horrible.
>>     
>
> Even your draft disagrees with this, else it wouldn't mention
> the disabling RFC 1966 behavior (as opposed to the discard
> based on ORIGINATOR_ID on the client that RFC 2796
> introduced -  for no valid _protocol reason, mind you, which
> annoys me considerably).  Along this vein, I would be quite
> interested in someone providing an explanation of why this
> behavior was changed from 1966 to 2796....
>   
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr