Re: [Idr] RFC-compliant use of Extended Length for new BGP attributes

Marcelo,

On Thu, Mar 13, 2008 at 10:37:05AM -0700, Marcelo Schmidt wrote:
> 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?

Expect the attribute length to be 2 octets and calculate the total path
attribute length accordingly.

> Ignore it, accept updates with Extended Length even when <= 255 octets anyways?

I'd certainly hope so.

> This could cause a packet malformed if the implementaion uses RFC1771 where
> Extended Length bit is being checked before sending the update.

The packet is well formed.  As you say, by 1771 rules, it is
semantically incorrect.  The only implementation I would expect to do
anything about this would be the ones run by conformance validation tools.

One reason why implementors may wish to just use the extended length
value always is that it reduces the possible code paths for packet
construction.  Length errors when constructing TLVs are a class of bugs
that crop up all too often in networking.

Of course, even an implementation that always sent using the extended
length bit must be able to receive without it.

-- Jeff
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr