[BGPCEP-220] Renegotiation not working Created: 06/May/15 Updated: 03/Mar/19 Resolved: 07/May/15 |
|
| Status: | Resolved |
| Project: | bgpcep |
| Component/s: | BGP |
| Affects Version/s: | Bugzilla Migration |
| Fix Version/s: | Bugzilla Migration |
| Type: | Improvement | ||
| Reporter: | Dana Kutenicsova | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Description |
|
According to RFC 5492: A BGP speaker determines that its peer doesn't support capabilities advertisement if, in response to an OPEN message that carries the Capabilities Optional Parameter, the speaker receives a NOTIFICATION message with the Error Subcode set to Unsupported Optional Parameter. (This is a consequence of the base BGP-4 specification [RFC4271] and not a new requirement.) In this case, the speaker SHOULD attempt to re-establish a BGP connection with the peer without sending to the peer the Capabilities Optional Parameter. |
| Comments |
| Comment by Robert Varga [ 06/May/15 ] |
|
We are well within the spirit of the specification. What we may be able to do is to mark certain advertised tables as optional and drop them when they get rejected. |
| Comment by Luis Gomez [ 06/May/15 ] |
|
Yes we are but with current implementation we can only interop with BGP-LS capable routers which are very few vendors and models in the market |
| Comment by Robert Varga [ 06/May/15 ] |
|
I am sorry, Luis, but your last statement is simply not true. Our implementation needs to be configured appropriately, just as any router out there. |
| Comment by Luis Gomez [ 06/May/15 ] |
|
Agree, as I said in the mail we can close this bug and I only ask to put more documentation on how to configure the capabilities. |
| Comment by Dana Kutenicsova [ 07/May/15 ] |
| Comment by Luis Gomez [ 07/May/15 ] |
|
Thanks Dana |