Re: [Idr] RFC-compliant use of Extended Length for new BGP attributes
"Vishwas Manral" <vishwas.ietf@gmail.com> Thu, 13 March 2008 17:11 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 E7E4728C3C7; Thu, 13 Mar 2008 10:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.378
X-Spam-Level:
X-Spam-Status: No, score=-100.378 tagged_above=-999 required=5 tests=[AWL=-0.540, 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 tQ4iMdwtL9V5; Thu, 13 Mar 2008 10:11:19 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C8C28C1F2; Thu, 13 Mar 2008 10:11:19 -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 11DE328C29D for <idr@core3.amsl.com>; Thu, 13 Mar 2008 10:11:18 -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 jFRKgoanujTg for <idr@core3.amsl.com>; Thu, 13 Mar 2008 10:11:11 -0700 (PDT)
Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.186]) by core3.amsl.com (Postfix) with ESMTP id C8C9728C1F2 for <idr@ietf.org>; Thu, 13 Mar 2008 10:11:11 -0700 (PDT)
Received: by rn-out-0910.google.com with SMTP id a46so2409744rne.9 for <idr@ietf.org>; Thu, 13 Mar 2008 10:08:53 -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=pyHp6gkAb3hMoGLeBa25/FK72ComjGkXeh39uBHSfAw=; b=PKza++/TTMaNVT+Fg+AaGSX7SskqD6DqI7ZYDfY5VH+L2zcWggxMZMjwSOdf+5qBa72VAREuY+08+gE4eKKfEokZR/j0iygwlTKeEoJlBQeV4VfnxAcF3uv0kAA0me6zySurOZRKDdfx1nKf3aIu3xatQ5B5Og2zSONo2r23WCc=
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=KRt4Y4dBP8hAhXZ/HCmL/jIhp+SLpQ+JUnJ85fw9PUxZyvmm/tarpdU9QD5+9XGDXniQ4druxtFp0qnQbSkC/v3UmYEF2fsO9Jo7fNpNWqFchEUvlWJYJpdTvVKVwhJYa/dTcTyR7oQ7y+/nWGmaWSeOxcgfIR5nLCvMHq11vMM=
Received: by 10.142.240.9 with SMTP id n9mr4422398wfh.79.1205428133075; Thu, 13 Mar 2008 10:08:53 -0700 (PDT)
Received: by 10.143.164.14 with HTTP; Thu, 13 Mar 2008 10:08:53 -0700 (PDT)
Message-ID: <77ead0ec0803131008i6915cf91g8801970eb444a63e@mail.gmail.com>
Date: Thu, 13 Mar 2008 10:08:53 -0700
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Marcelo Schmidt <mschmidt@equinix.com>
In-Reply-To: <20080313154849.GL18190@equinix.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <20080313154849.GL18190@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, 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 > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
- [Idr] RFC-compliant use of Extended Length for ne… Marcelo Schmidt
- Re: [Idr] RFC-compliant use of Extended Length fo… Vishwas Manral
- Re: [Idr] RFC-compliant use of Extended Length fo… Marcelo Schmidt
- Re: [Idr] RFC-compliant use of Extended Length fo… Vishwas Manral
- Re: [Idr] RFC-compliant use of Extended Length fo… Jeffrey Haas
- Re: [Idr] RFC-compliant use of Extended Length fo… Vishwas Manral
- Re: [Idr] RFC-compliant use of Extended Length fo… Vishwas Manral
- Re: [Idr] RFC-compliant use of Extended Length fo… Jeffrey Haas
- Re: [Idr] RFC-compliant use of Extended Length fo… Samita Chakrabarti
- Re: [Idr] RFC-compliant use of Extended Length fo… Paul Jakma