IETF Logo Mail Archive

Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Mon, 27 June 2016 17:26 UTC

Return-Path: <jheitz@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEADA12D88C; Mon, 27 Jun 2016 10:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level:
X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhAFQZBPyBEt; Mon, 27 Jun 2016 10:26:31 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF2012D88D; Mon, 27 Jun 2016 10:26:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2182; q=dns/txt; s=iport; t=1467048388; x=1468257988; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Hyz9vSDURK+KNtIOx1AVBWh+GPWXjse+AjNtytowsmE=; b=TSeO2obrpA3ALJgYFyvBMrLo9aGciZVpA8Yx0wFvI4LvNb2eOAm/E5du UFdR+lu1dk/couQXHA4Bko/7wzX6gZxxH423CdPa12x7K92DpGUsFdgA5 30WCqrFme6aEsOZzwft2jhyWcGAS3hxov7cuuixTwtVsGZ/CY/3RZeQ82 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D1AQDJYHFX/5pdJa1bgz6BUwa6J4F7hhgCgTQ4FAEBAQEBAQFlJ4RMAQEBAwE6PwwEAgEIEQQBAQEeCQcyFAkIAgQOBQiIIAjDAQEBAQEBAQEBAQEBAQEBAQEBAQEBARyGKIRNihsFmQEBji+PK49+AR42g3BuiHh/AQEB
X-IronPort-AV: E=Sophos;i="5.26,537,1459814400"; d="scan'208";a="289810849"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2016 17:26:27 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u5RHQRY0031294 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jun 2016 17:26:27 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Jun 2016 12:26:26 -0500
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Mon, 27 Jun 2016 12:26:26 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: "John G. Scudder" <jgs@juniper.net>
Thread-Topic: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04
Thread-Index: AQHRzmgGBv3fZ5fA9ES7A4n0pFWtDZ/8Z5yQgAFwVID//7bekA==
Date: Mon, 27 Jun 2016 17:26:26 +0000
Message-ID: <bbc25621e7a641b7b96e8b22d06c20c6@XCH-ALN-014.cisco.com>
References: <m8h688tnbwxkug7d8u82j25c.1466634873538@email.android.com> <952977D8-B35A-4C1A-8526-9D616BD0F0B6@juniper.net> <cb0f8e65-5ec8-8820-3078-f0a20ecf5d41@cisco.com> <56a07f338f5d4a1f8dfd539040b1002e@XCH-ALN-014.cisco.com> <2FBB796F-76B7-4F5F-B183-62A1FCA30313@juniper.net>
In-Reply-To: <2FBB796F-76B7-4F5F-B183-62A1FCA30313@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.91.214]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/QfYDlCr1TtjVtzg1_cAtojQUwgk>
Cc: "idr@ietf.org" <idr@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-idr-ext-opt-param@ietf.org" <draft-ietf-idr-ext-opt-param@ietf.org>, "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>, Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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>
X-List-Received-Date: Mon, 27 Jun 2016 17:26:35 -0000


> -----Original Message-----
> From: John G. Scudder [mailto:jgs@juniper.net]
> Sent: Monday, June 27, 2016 9:25 AM
> To: Jakob Heitz (jheitz) <jheitz@cisco.com>
> Cc: Enke Chen (enkechen) <enkechen@cisco.com>; idr@ietf.org; rtg-dir@ietf.org; draft-ietf-idr-ext-opt-param@ietf.org;
> Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com>; Susan Hares <shares@ndzh.com>
> Subject: Re: [Idr] Routing directorate QA review of draft-ietf-idr-ext-opt-param-04
> 
> On Jun 26, 2016, at 7:39 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
> >
> > "An optional parameter with parameter type of 0xFF MUST NOT appear in the
> > list of optional parameters other than in first place and if it does appear,
> > then the optional parameters length MUST be 0xFF."
> 
> And it's a fatal error if it's not?

Absolutely. As you say, the session is not up yet.

> 
> (Remember this is before the session becomes established, so the principle of service survival above all that would
> applied in the error-handling spec doesn't apply.)
> 
> > There is really no reason to entertain other combinations and I don't
> > want to have to write code to handle them.
> 
> Is there some reason insisting that the non-extended length field be 255 is better than ignoring it once you've
> determined by inspection of the non-extended parameter type that the extended encoding is in use? The logic would be,
> if the (one byte, non-extended) parameter type = 255, then use the extended encoding, and ignore the one byte non-
> extended length field.
> 
> If we made this change, the spec would say, MUST send non-extended length as 255, MUST ignore on receipt if the
> following eight bits (the non-extended type field) are 255.

To Enke's point, can we make the non-extended length at least 1?
Legacy speakers...

In addition: An otional parameter of type 255 MUST NOT appear in the
list of optional parameters other than in first place.

Should we set a maximum length of 4k?
There will always be smaller boxes wishing to speak BGP that will never support extended messages.

> 
> Thanks,
> 
> --John

v2.23.0 | Report a Bug | By Email