Re: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-extended-messages-11

"Brian Weis (bew)" <bew@cisco.com> Wed, 09 September 2015 01:04 UTC

Return-Path: <bew@cisco.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0091B2D66; Tue, 8 Sep 2015 18:04:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 oOw7Sgn4K36J; Tue, 8 Sep 2015 18:04:41 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE851B2D51; Tue, 8 Sep 2015 18:04:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12479; q=dns/txt; s=iport; t=1441760675; x=1442970275; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5qPddf0DkD+H/LwgfFE71udyxeHSxLWT1D31IJaoCuE=; b=g2E58Vdk7AT1vcpWd+gAzdmAbFXPGwO9ebE/QWIQjOi69TVSA9ti5T3u lHx5FzUhkPaZ3y39y5Ezyg8LGwpnTe9dXgX9icAwN/sXUPWKZX2qk+/ID yKyBoCIaEmyYNPC3JVReSuunEzeMiJ4JJZZz3DAanKYV8XrkwJ+FWdP1i c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CFAgBChe9V/4ENJK1aA4JWTVRpBr0kAQmBd4V5AoE9OBQBAQEBAQEBgQqEJAEBBHkQAgEIPwcyFBECBA4FiC4NynsBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIkCgmyEKREBQQwEBgESgwaBFAWVVQGFCWeHCYFMh1KNbYNsJoQAcQGHCTqBBQEBAQ
X-IronPort-AV: E=Sophos;i="5.17,493,1437436800"; d="scan'208,217";a="186293224"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP; 09 Sep 2015 01:04:34 +0000
Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t8914YeV032596 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Sep 2015 01:04:34 GMT
Received: from xch-rcd-011.cisco.com (173.37.102.21) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 8 Sep 2015 20:04:33 -0500
Received: from xhc-rcd-x02.cisco.com (173.37.183.76) by xch-rcd-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 8 Sep 2015 20:04:33 -0500
Received: from xmb-aln-x04.cisco.com ([169.254.9.110]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0248.002; Tue, 8 Sep 2015 20:04:32 -0500
From: "Brian Weis (bew)" <bew@cisco.com>
To: "John G. Scudder" <jgs@juniper.net>
Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-extended-messages-11
Thread-Index: AQHQ5pyavJqj3SsTMUuXdi1VXKYzo54zIhaAgACbewA=
Date: Wed, 09 Sep 2015 01:04:32 +0000
Message-ID: <00A4493E-F39C-4F78-B588-C75C723D99A4@cisco.com>
References: <AF599976-2CAE-4180-998B-47C1EA6CFF79@cisco.com> <893EC42D-AC9F-481E-AADF-11A5E35333CA@juniper.net>
In-Reply-To: <893EC42D-AC9F-481E-AADF-11A5E35333CA@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.37.102.12]
Content-Type: multipart/alternative; boundary="_000_00A4493EF39C4F78B588C75C723D99A4ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/IdGOwo4lz4kI1cqVZSFk1GppCaU>
Cc: "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-extended-messages.all@ietf.org" <draft-ietf-idr-extended-messages.all@ietf.org>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-extended-messages-11
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Sep 2015 01:04:43 -0000

Hi John,

On Sep 8, 2015, at 8:48 AM, John G. Scudder <jgs@juniper.net<mailto:jgs@juniper.net>> wrote:

Hi Brian,

Some comments below (to be clear, I'm commenting as a working group contributor and not co-chair).

On Sep 3, 2015, at 7:02 PM, Brian Weis (bew) <bew@cisco.com<mailto:bew@cisco.com>> wrote:

Minor Issues:
Section 5 (Error Handling) delineates two error cases possible when a BGP speaker has not advertised that it can use extended messages, but does receive one from a peer. Each case has its own paragraph in this section. The first paragraph describes a BGP speaker that can use extended messages (but has not advertised it); the second paragraph describes a BGP speaker that actually cannot use extended messages. In the second paragraph the error response is clearly stated (i.e., follow the error handling procedures of RFC 4221 and reset the session). But as written it does not seem that any such response is required for the first case. It isn’t clear to me why this type of BGP speaker would respond differently, and if the error response was intended for both cases then I suggest the text describing the response be separated into a third paragraph. In any case it would be valuable to explicitly describe the expected response of the BGP speaker in both cases.

Here is the text of the section in question:


   A BGP speaker that has the ability to use extended messages but has
   not advertised the BGP Extended Messages capability, presumably due
   to configuration, SHOULD NOT accept such a message.

   However, a BGP speaker that does not advertise the BGP Extended
   Messages capability might also genuinely not support extended
   messages.  Such a speaker would be expected to follow the error
   handling procedures of [RFC4221], Section 6.1<https://tools.ietf.org/html/rfc4221#section-6.1>, and reset the session
   with a Bad Message Length NOTIFICATION if it receives an extended
   message.  A speaker that treats an improper extended message as a
   fatal error should do likewise.


First of all, my own opinion is that the same "keep the session up at (almost) all costs" philosophy (and I use the term loosely) that led the working group to adopt treat-as-withdraw as the preferred way of handling attribute errors (RFC 7606), suggests that the SHOULD in the first paragraph ought to be a SHOULD NOT. That is, the implementation ought to go ahead and accept the message if it's capable of doing so. However, just as with the attribute error-handling spec, I acknowledge this choice would be fairly disgusting, and I understand why the authors didn't make it.

In reading your comment, I'm not actually sure what you're asking for. As I read the text, it says "reset the session if you get an unexpected extended message”.

Sorry to be confusing. To a first time reader, it is clear that a BGP speaker is expected to discard extended messages in both cases mentioned, but it’s not clear to me that the BGP speaker is always instructed to inform its peer that it is discarding its messages. The instruction to “reset the session” appears to only cover the case where the BGP speaker can’t support extended messages. It isn’t clear that the last sentence in the 2nd paragraph is referring back to the 1st paragraph. My ask was to make the expected response clearer, and what you suggest below does that.

The only corner case that isn't covered by the text is the case where an implementation does choose to "be liberal in what it accepts", that is, where it disregards the SHOULD NOT and instead accepts the unexpected but otherwise well-formed message. In such a case, it would be reasonable to expect that the draft might have a MAY clause to explain when the SHOULD NOT can be disregarded, and what should be done instead in that case.

This also seems like a good idea to me.

Or, maybe the final sentence is too weak? Perhaps it would be clearer if worded as "A speaker that treats an improper extended message as a fatal error, as described in the preceding paragraph, MUST do likewise.”

That was the problem. The new text works for me, thanks.

Brian


Thanks,

--John

--
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com<mailto:bew@cisco.com>