Hi,
I happened to stumble on this same question this afternoon.
On Wed, 14 Mar 2012, Chris Hall wrote:
So, I've been looking at the BGP Update Message Attribute handling...
...RFC4724 says that a completely empty UPDATE message is an
End-of-RIB for IPv4 Unicast.
...it then says:
"For any other address family, it is an UPDATE message that
contains only the MP_UNREACH_NLRI attribute [BGP-MP] with
no withdrawn routes for that <AFI, SAFI>."
I read this as meaning that to be an End-of-RIB, the update MESSAGE
should contain absolutely nothing other than the empty
MP_UNREACH_NLRI.
The current code:
1. will not recognise an empty MP_UNREACH_NLRI for IPv4
Unicast as an End-of-RIB.
It is arguable that is what the RFC means by "For any
*other* address family" (my emphasis).
It would be perverse to send such a message...
...so, so far, so good.
2. will recognise an empty MP_UNREACH_NLRI as End-of-RIB
*provided* there are no other Withdrawn Routes.
This means that there may be:
* any number of other attributes.
* any number of ordinary IPv4 Unicast NLRI
* any number of NLRI in an MP_REACH_NLRI attribute
Which isn't what I read the RFC as specifying.
I'd agree. The RFC seems clear that an IPv4 EoR should be an empty
UPDATE. An EoR for any other AFI/SAFI should be a near-empty UPDATE bar
an empty MP_UNREACH for that AFI/SAFI.
Now, I guess you have to be borderline mad to issue an empty
MP_UNREACH_NLRI in any case *except* End-of-RIB.
So, I suppose one could piggy-back the End-of-RIB in the same message
as the last NLRI for the AFI/SAFI in question.
That seems the case in the current code. It seems wrong though, doesn't
it?
The generating side generates what you'd expect from the RFCs.
Is the current code allowing for something which happens in practice,
but the RFC does not (as I read it) allow ?
Or is the current code just a wee bit sloppy ?
Is there an expert in the house who can advise, please ?
I suspect it's just sloppy.
I intend to supply a patch as part of a little cleanup.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
T-1's congested due to porn traffic to the news server.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
