Subject: [Idr] RFC 5575: broken implementation

From: Thomas Mangin <[email-masked]>
Date: Mon, 27 Jan 2014 19:59:18 +0000

Hello,

One of ExaBGP's user recently found that JunOS implementation does not respect RFC 5575 section 7[1] which says that the traffic rate is expressed in BYTES per seconds. JunOS parses the packet data received as BITS per seconds. On notification, Juniper's TAC updated their documentation from Bps to bps .. [2] so it seems unlikely that a fix is pending ...

I am wondering if this behaviour is consistent with other vendors ( AFAIK only ALU has implemented it but I have no way to test how they interpret the data ).
Should the behaviour be consistently BITS per seconds. I am wondering if it would be better to update the RFC and not the implementations ?

Any help sorting out this issue would be most welcome. 

Sincerely,

Thomas

[1] http://tools.ietf.org/html/rfc5575#section-7
[2] http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/flow-routes-understanding.html

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 27 Jan 2014 15:38:26 -0500

[I generally try to avoid speaking for the employer outside of standards
from this address, but IDR usually doesn't talk about vendor bugs. :-) ]

> One of ExaBGP's user recently found that JunOS implementation does not respect RFC 5575 section 7[1] which says that the traffic rate is expressed in BYTES per seconds. JunOS parses the packet data…

Already fixed as PR 864496.  I unfortunately don't have the cycles to hunt
down the public face of this bug.

> Should the behaviour be consistently BITS per seconds. I am wondering if it would be better to update the RFC and not the implementations ?

This is probably the more interesting story long term.  Much of the point of
interoperable deployments is that these silly bugs don't morph into a fight
between updating the code vs. the specs.  (Long time readers of IDR will
recall the code point issues for BGP Confederation segments. ;-)

Where such things become ugly is when you have a mixed deployment of things
with the bug fixes vs. not.  Whether to give fixes knobs often comes down on
which big customer is annoyed by the change.

> Any help sorting out this issue would be most welcome. 

Get your JTAC person to find you a version that covers PR 864496.  Do the right
thing.

In the absence of the fix, realize there's a bug.  Deal accordingly.

-- Jeff