Hi Vishwas, If the restriction defined in RFC1771 is not longer valid, that means we can expect to receive an update with Extended Length bit set, but e.g. length of only 6? This is one case where I see this needs a clarification: what should outgoing updates do when the Extended Length bit is set but but length <= 255 oct? Ignore it, accept updates with Extended Length even when <= 255 octets anyways? This could cause a packet malformed if the implementaion uses RFC1771 where Extended Length bit is being checked before sending the update. -m with length of 6 we only use a 1-byte (i.e. non-extended) length field On Thu, Mar 13, 2008 at 10:08:53AM -0700, Vishwas Manral wrote: > > Hi Marcelo, > > RFC4271 obsoletes RFC1771. In my view as the RFC4271 does not mention > the "Extended Length" restriction as defined below in RFC1771, the > restriction no longer applies to RFC4271. > > "Extended Length may be used only if the length of the attribute value > is greater than 255 octets." > > I agree clarification on the same would have been good though. > > Thanks, > Vishwas > > On Thu, Mar 13, 2008 at 8:48 AM, Marcelo Schmidt > <mschmidt at equinix.com> wrote: > > 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 > > > ==================================================================== > > > > > > _______________________________________________ > > Idr mailing list > > Idr at ietf.org > > [1]https://www.ietf.org/mailman/listinfo/idr > > > > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.518 / Virus Database: 269.21.7/1327 - Release Date: > 3/12/2008 1:27 PM > > References > > 1. https://www.ietf.org/mailman/listinfo/idr -- -m ==================================================================== Key fingerprint = 8E48 6CD0 6D2B 538E 264B D1D0 21E2 E7EE A40F 2A0B gpg --keyserver wwwkeys.pgp.net --recv-keys 0xA40F2A0B ====================================================================
Attachment:
pgptfbc8_dClo.pgp
Description: PGP signature
_______________________________________________ Idr mailing list Idr at ietf.org https://www.ietf.org/mailman/listinfo/idr