Subject: Re: [Idr] Dynamic Capability for BGP-4

From: Neil Matthew <[email-masked]>
Date: Fri, 01 Sep 2006 09:05:55 +0100

I'm not too concerned with the implementation of the feature as 
specified in the draft.  As I say, my main concern is the associated 
impact on features such as ORF and Graceful Restart.  Am I on my own 
here to make decisions on how I think these features will react to a 
dynamic change?

As an example, of the top of my head, does an implementation remove a 
local ORF if an ORF type is removed from the capabilities advertised by 
a peer, or maybe it is assumed that the peer sends a REMOVE-ALL - that's 
what I mean by "concern". :)

If it's up to the developer to make intelligent decisions on this then I 
guess that's the way it will have to be although I would have thought 
that this could lead to interoperability issues especially if there 
aren't actually any implementations out there yet (please correct me if 
I'm wrong).

Cheers

Neil

Enke Chen wrote:

> Hi, Neil:
>
> Just noticed that the draft has expired,  will refresh. In the 
> meantime, you can find the draft here:
>
>                      
> http://ietfreport.isoc.org/all-ids/draft-ietf-idr-dynamic-cap-08.txt
>
> Regarding its status, the spec has been stable since the sync 
> mechanism was introduced several years ago.
>
> -- Enke
>
> Neil Matthew wrote:
>
>> Hi Folks
>>
>> I note that the topic of dynamic capability support has gone kind of 
>> quiet.  Can anyone update me with the current state of play?
>>
>> My primary concern is how it impacts the features (such as ORF and 
>> Graceful Restart) that lie behind these capabilities.  Is there any 
>> work going on behind the scenes to detail this or is the intention 
>> that such matters be left to the developer?
>>
>> There was some discussion on this subject around 4 years ago!
>>
>> On a related note, are there any implementations in existence?
>>
>> Cheers
>>
>> Neil
>>
>>
>>
>> _______________________________________________
>> Idr mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/idr
>
>
>

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Enke Chen <[email-masked]>
Date: Fri, 01 Sep 2006 15:40:19 -0700

Hi, Neil:

The behavior is capability specific.  The semantics for having a 
capability should have already been defined for that particular 
capability.  One the other hand, once a remote speaker removes a 
capability, the local speaker should clean up the data structures and 
actions that resulted from the remote speaker having that capability 
(that is, just the reverse of having the capability).

In your example, if an ORF type is removed from the capability by the 
remote speaker, then the local speaker should:

    o remove the ORF entries (of the ORF type) received from the remote 
speaker.
    o stop sending the ORF entries of the ORF type.

-- Enke

Neil Matthew wrote:

> local ORF if an ORF type is removed from the capabilities advertised 
> by a peer, or maybe it is assumed that the peer sends a REMOVE-ALL - 
> that's what I mean by "concern". :)
>
> If it's up to the developer to make intelligent decisions on this then 
> I guess that's the way it will have to be although I would have 
> thought that this could lead to interoperability issues especially if 
> there aren't actually any implementations out there yet (please 
> correct me if I'm wrong).
>
> Cheers
>
> Neil
>
>
> Enke Chen wrote:
>
>> Hi, Neil:
>>