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

"Vishwas Manral" <vishwas.ietf@gmail.com> Thu, 13 March 2008 17:50 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 A60CA28C4CA; Thu, 13 Mar 2008 10:50:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.244
X-Spam-Level:
X-Spam-Status: No, score=-100.244 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_12=0.6, 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 9bgcvN+lUYNK; Thu, 13 Mar 2008 10:50:32 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B8F28C37E; Thu, 13 Mar 2008 10:50: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 69CDF28C4D6 for <idr@core3.amsl.com>; Thu, 13 Mar 2008 10:50: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 YAlvFYvtysMn for <idr@core3.amsl.com>; Thu, 13 Mar 2008 10:50:30 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 7015628C4B9 for <idr@ietf.org>; Thu, 13 Mar 2008 10:50:30 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 25so3770038wfa.31 for <idr@ietf.org>; Thu, 13 Mar 2008 10:48: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=pwvAIt/K00RKc3i3DuxBhBG8rmiAW7PCkgzUn+dvmr0=; b=b/qV8rwqhOOG9EB4bHKym9FxCGcp57OGLIQoERytOnLwsgZ2/MOj7hGtZe9mnH/1GZF8tIGoXcLD30ZGQOfJStgvxR/jY768khOvEQJ/B3HCtyFZPO8/0nRRA6Y2+mEBNuFDZMshNEx5pFKZSC6xqC0iopQwtPzef4pTlXSkiyA=
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=Eze/U1KC67Ix+BUn5r45DFeQ2/HnitIqrPQ68LfLfU6nzgq7rpfum+U+1PiPy26lMOgdguG8Guo1freM43/nRU8PqyuOKWm+6MulkkRg5GQTZH5OreTy0I0VEmZVagHpl8K4zfC88daPQJRb18I2dD9FYiKbae+LdQ60G/pdSck=
Received: by 10.142.252.11 with SMTP id z11mr4466762wfh.232.1205430492697; Thu, 13 Mar 2008 10:48:12 -0700 (PDT)
Received: by 10.143.164.14 with HTTP; Thu, 13 Mar 2008 10:48:12 -0700 (PDT)
Message-ID: <77ead0ec0803131048r6c3e389ci82cddda20bcc6214@mail.gmail.com>
Date: Thu, 13 Mar 2008 10:48:12 -0700
From: "Vishwas Manral" <vishwas.ietf@gmail.com>
To: "Marcelo Schmidt" <mschmidt@equinix.com>
In-Reply-To: <20080313173705.GN18190@equinix.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <20080313154849.GL18190@equinix.com> <77ead0ec0803131008i6915cf91g8801970eb444a63e@mail.gmail.com> <20080313173705.GN18190@equinix.com>
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 Marcelo,

You are right. This does cause non-interoperability between RFC1771
and RFC4271 related implementations and could be clarified.

However my take is we should accept Extended length even if it is
lesser than 255. It would be an easier option to have the code under
some run time flag of RFC1771 compatible versus RFC4271 compatible.

Thanks,
Vishwas

On Thu, Mar 13, 2008 at 10:37 AM, Marcelo Schmidt <mschmidt@equinix.com> wrote:
> 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@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@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
>  ====================================================================
>
>
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr