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

["Vishwas Manral" <vishwas.ietf at gmail.com>]

Hi Jeffrey,

One correction to what you said.
>  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.
In going with the principle of being conservative in what we send out
and liberal in what we accept, I would say an implementation should
not use Extended Length field if the length is lesser than 255 and an
Extended Length when it is more. While accepting ofcourse, we should
try to be more liberal there.

Thanks,
Vishwas


On Thu, Mar 13, 2008 at 10:56 AM, Jeffrey Haas <jhaas at pfrc.org> wrote:
> 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 at ietf.org
>
>
> https://www.ietf.org/mailman/listinfo/idr
>
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr