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

"Vishwas Manral" <vishwas.ietf@gmail.com> Thu, 13 March 2008 18:23 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: ietfarch-idr-archive@core3.amsl.com
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03D428C515; Thu, 13 Mar 2008 11:23:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.544
X-Spam-Level:
X-Spam-Status: No, score=-100.544 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZzRqXJ36KHe; Thu, 13 Mar 2008 11:23:32 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6570528C1EF; Thu, 13 Mar 2008 11:23:32 -0700 (PDT)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00AF43A6E59 for <idr@core3.amsl.com>; Thu, 13 Mar 2008 11:23:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQBuY8ACx+Q1 for <idr@core3.amsl.com>; Thu, 13 Mar 2008 11:23:30 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 216BF3A6B9B for <idr@ietf.org>; Thu, 13 Mar 2008 11:23:30 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 25so3784716wfa.31 for <idr@ietf.org>; Thu, 13 Mar 2008 11:21:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=dd7s0V/1RUhu/LqzANLgNW2oli2FT1ZfQxSw9eFoSdk=; b=VIVfTaPGvNGAz/wZ6VciujKTDaILJvzqIIWlv6TCClfLLO19/yPVWsUHQjvCXWS9MVHFmUDFRRcKH0h8zIqipY5AOS+R8fGMHdgCK7fq/ktOIpC1z20o46CB/U5oXIFVAmdo7r/e5HSnfH036vY4J6jqU84P/wxXicUXh6a3aao=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qwnE9pDA15SgTu2fzaZl1x7wu7lCAZYI2YJpbuNw/jZBfs6lqxTkPE7IJueVX7Gd4ZaGHp0Cnyfc8sc/QwOTN8+MEdiHBwCRHs64XSxHOTf+8GkqsPCOU4S8K3Wjdb7fnP56GXX8bW3ZdvGLbfLe1JGc/WI1egJGi0WZJC0fVbA=
Received: by 10.142.237.20 with SMTP id k20mr4527987wfh.174.1205432472282; Thu, 13 Mar 2008 11:21:12 -0700 (PDT)
Received: by 10.143.164.14 with HTTP; Thu, 13 Mar 2008 11:21:11 -0700 (PDT)
Message-ID: <77ead0ec0803131121v110c09f7hdc08f354948272a9@mail.gmail.com>
Date: Thu, 13 Mar 2008 11:21:11 -0700
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <20080313175645.GA23909@scc.mi.org>
MIME-Version: 1.0
Content-Disposition: inline
References: <20080313154849.GL18190@equinix.com> <77ead0ec0803131008i6915cf91g8801970eb444a63e@mail.gmail.com> <20080313173705.GN18190@equinix.com> <20080313175645.GA23909@scc.mi.org>
Cc: idr@ietf.org
Subject: Re: [Idr] RFC-compliant use of Extended Length for new BGP attributes
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

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@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@ietf.org
>
>
> https://www.ietf.org/mailman/listinfo/idr
>
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr