I am interested in input from the list on loose behavior we've seen from various BGP specs. The specific example in question is a case we are seeing in the wild where a NEW_AS_PATH attribute has 8 data bytes, but sets the Extended Length bit and uses a 2-byte length field. RFC 1771 explicitly states "Extended Length may be used only if the length of the attribute value is greater than 255 octets." However, the superceding RFC 4271 does not have this explicit language, therefore would imply that either of the following cases would technically be compliant: A. Ext-Len is set (1), 2-byte length field is used, regardless of length of attribute B. Ext-Len is clear (0), 1-byte length field is uses, and attribute is <= 255 bytes Furthermore, I've seen loose language, such as draft-kumaki-pce-bgp-disco-attribute-00.txt that seems to imply to always set Ext-Len bit regardless. Specifically, is anyone aware of any new BGP extensions that would REQUIRE Ext-Len to be set, even if attribute is <= 255 bytes? Our thought is that if we receive a case A above with length <= 255 bytes, we are free to propogate to downstream neighbors as a case B (generically, for any attribute in BGP)." -- -m ==================================================================== Key fingerprint = 8E48 6CD0 6D2B 538E 264B D1D0 21E2 E7EE A40F 2A0B gpg --keyserver wwwkeys.pgp.net --recv-keys 0xA40F2A0B ====================================================================
Attachment:
pgpTJrE0C_SVo.pgp
Description: PGP signature
_______________________________________________ Idr mailing list Idr at ietf.org https://www.ietf.org/mailman/listinfo/idr