Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

Alvaro Retana <aretana.ietf@gmail.com> Wed, 31 July 2019 12:20 UTC

Return-Path: <aretana.ietf@gmail.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 27E2E120164; Wed, 31 Jul 2019 05:20:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Rhd8ySeKECSG; Wed, 31 Jul 2019 05:20:14 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7C09120153; Wed, 31 Jul 2019 05:20:13 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id e3so65523633edr.10; Wed, 31 Jul 2019 05:20:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Va9aUFvsyL9gWC2qzoRMBEr7BBFaFUjB64ftVr1EJt0=; b=sFIO+DloGOHani9fp1AaZwLAgOXBYa7yW+qlwj3h19P3+QCwzvh6xam+AknnC9aoxI 5nPQ7iMPH9RPPY9yTvOE0dfDtKAhIZZj8eyN+9Hlb4dU+UbVARHHnd7RERpCiu2uPRmw PC4mSUDC8FpXYVWSVpzz2lxMR8GkP1k/aDGBgRqykfxSOGy/61xYNh0Mp08CRKn+O9WO hyp8J76DpnZ4Xd7Yfx73WXbUzun9oI4dYP/E7bRg2HIoeGh+C1GMbsC+HhwbwmKZSrb6 qQIRQg/65pq/lILjw25Lhoml+77p0oXyG+geb1qICysADJbAKPGOu8GpaRRwKEQUJMlB YnqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Va9aUFvsyL9gWC2qzoRMBEr7BBFaFUjB64ftVr1EJt0=; b=l5y6GgUp8dV7H9TsNRC5ynjobgcvhfl1HL6HEFFNyGFInZC/DxdaFbJr+OEckdApfE eWlcVxEmk+aWukh2HppQizEdne++mmIwJF/QYWffkPiEhsuc0DHTHKPQw6jY2o9K8eN6 N1gTVHe/o/ErI81GdrrVm4NpnJl4ZhnMP3jg65ybQcrKYC5KSKxQ3kviCnLzhL7b7cZL +xVNaX+gXYGGTeaOUF1DhtZ4i6D4/8IocVX1qVonCu+rdOrvmxVGF6tb/R7xndGy3edC YtmNcQxB4gbwiWkPvbmk6JzAR94fuUfpmMacVRfeC36yyW0A7UXo+Ntu8ZpfsgSjaHqG +vFg==
X-Gm-Message-State: APjAAAVIY9Hgwfv0i5pdQUsOO+4f6QSBReIPnROh9CFW9EAGEQ4LH1sL HN5g34aPUOAmohdAUj4IC5VcnYWdikvpShajPN0=
X-Google-Smtp-Source: APXvYqxK5onzd2E5Qvt+vfsTeHnZeTL0u0hj5AAvB0lgX8E1ohK1l2W1jlPkT4c3ri0KFz/JBaK2rOjVkNr5kUkuGqU=
X-Received: by 2002:aa7:c313:: with SMTP id l19mr95007321edq.258.1564575612456; Wed, 31 Jul 2019 05:20:12 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 31 Jul 2019 05:20:11 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <EC487235-A83C-44F5-B51F-C92A05E56BF8@cisco.com>
References: <156449387998.2643.18137174091685834097.idtracker@ietfa.amsl.com> <m27e7zxpv1.wl-randy@psg.com> <CAMMESsxccHKqaXeGKO1sD9jAiEM7McT9_+VUx4G_nqt_2TX3GA@mail.gmail.com> <m2zhkvw8in.wl-randy@psg.com> <m21ry7vvzk.wl-randy@psg.com> <EC487235-A83C-44F5-B51F-C92A05E56BF8@cisco.com>
MIME-Version: 1.0
Date: Wed, 31 Jul 2019 05:20:11 -0700
Message-ID: <CAMMESszSXpYOgzz=Jk88J0_UJp8dhtmne1Nh88zEeFFmKJoPag@mail.gmail.com>
To: "Enke Chen (enkechen)" <enkechen@cisco.com>, Randy Bush <randy@psg.com>
Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind_via_Datatracker?= <noreply@ietf.org>, "draft-ietf-idr-bgp-extended-messages@ietf.org" <draft-ietf-idr-bgp-extended-messages@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009ad3eb058ef92577"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/4VXvuWoMIOPNG2Tzxhtu44vI8rE>
Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-idr-bgp-extended-messages-33=3A_=28with_COMMENT=29?=
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 31 Jul 2019 12:20:16 -0000

On July 30, 2019 at 9:53:36 PM, Enke Chen (enkechen) (enkechen@cisco.com)
wrote:

Enke:

Hi!

Here is a patch that would clarify the capability definition, the issue
that I brought up before.
It also include changing "BGP listener" to "BGP speaker" in two places.

I looked at the changes and they look good tome.  I think that generalizing
to “speaker” does help.

Thanks!!

Alvaro.



*** bgp-large-msg-34.txt.orig Tue Jul 30 18:24:32
<http://airmail.calendar/2019-07-30 18:24:32 GMT-4> 2019
--- bgp-large-msg-34.txt Tue Jul 30 18:34:07
<http://airmail.calendar/2019-07-30 18:34:07 GMT-4> 2019
*************** Internet-Draft Extended Message sup
*** 120,148 ****
defined with Capability code 6 and Capability length 0.

To advertise the BGP Extended Message Capability to a peer, a BGP
speaker uses BGP Capabilities Advertisement [RFC5492]. By
advertising the BGP Extended Message Capability to a peer, a BGP
! speaker conveys that it is able to send, receive, and properly
handle, see Section 4, BGP Extended Messages.

- A peer which does not advertise this capability MUST NOT send BGP
- Extended Messages, and BGP Extended Messages MUST NOT be sent to it.
-
Peers that wish to use the BGP Extended Message capability MUST
support Error Handling for BGP UPDATE Messages per [RFC7606].

4. Operation

The Extended Message Capability applies to all messages except for
the OPEN and KEEPALIVE messages. The former exception is to reduce
the complexity of providing backward compatibility.

! A BGP speaker that is capable of sending and receiving BGP Extended
Messages SHOULD advertise the BGP Extended Message Capability to its
peers using BGP Capabilities Advertisement [RFC5492]. A BGP speaker
! MAY send Extended Messages to a peer if the Extended Message
Capability was received from that peer.

An implementation that advertises the BGP Extended Message capability
MUST be capable of receiving a message with a Length up to and
including 65,535 octets.
--- 120,145 ----
defined with Capability code 6 and Capability length 0.

To advertise the BGP Extended Message Capability to a peer, a BGP
speaker uses BGP Capabilities Advertisement [RFC5492]. By
advertising the BGP Extended Message Capability to a peer, a BGP
! speaker conveys that it is able to receive, and properly
handle, see Section 4, BGP Extended Messages.

Peers that wish to use the BGP Extended Message capability MUST
support Error Handling for BGP UPDATE Messages per [RFC7606].

4. Operation

The Extended Message Capability applies to all messages except for
the OPEN and KEEPALIVE messages. The former exception is to reduce
the complexity of providing backward compatibility.

! A BGP speaker that is capable of receiving BGP Extended
Messages SHOULD advertise the BGP Extended Message Capability to its
peers using BGP Capabilities Advertisement [RFC5492]. A BGP speaker
! MAY send Extended Messages to a peer only if the Extended Message
Capability was received from that peer.

An implementation that advertises the BGP Extended Message capability
MUST be capable of receiving a message with a Length up to and
including 65,535 octets.
*************** Internet-Draft Extended Message sup
*** 157,168 ****
4,096 octet pre- Extended Message limit, so as not to require
downstream routers to decompose for peers that do not support
Extended Messages. See Section 8.

If a BGP message with a Length greater than 4,096 octets is received
! by a BGP listener who has not advertised the Extended Message
! Capability, the listener will generate a NOTIFICATION with the Error
Subcode set to Bad Message Length ([RFC4271] Sec 6.1).



Bush, et al. Expires January 31, 2020 [Page 3]
--- 154,165 ----
4,096 octet pre- Extended Message limit, so as not to require
downstream routers to decompose for peers that do not support
Extended Messages. See Section 8.

If a BGP message with a Length greater than 4,096 octets is received
! by a BGP speaker who has not advertised the Extended Message
! Capability, the speaker will generate a NOTIFICATION with the Error
Subcode set to Bad Message Length ([RFC4271] Sec 6.1).



Bush, et al. Expires January 31, 2020 [Page 3]
*************** Internet-Draft Extended Message sup
*** 175,190 ****
speakers which may not support Extended Messages. Therefore, an
announcement in an Extended Message where the size of the attribute
set plus the NLRI is larger than 4,096 octets may cause lack of
reachability.

! A BGP speaker with a mixture of peers some of which have advertised
! the BGP Extended Message capability and some which have not, may
! receive an UPDATE from one of its capable peers that produces an
ongoing announcement that is larger than 4,096 octets. When
propagating that UPDATE onward to a neighbor which has not advertised
! the BGP Extended Message capability, the sender SHOULD try to reduce
the outgoing message size by removing attributes eligible under the
"attribute discard" approach of [RFC7606]. If the message is still
too big, then it must not be sent to the neighbor ([RFC4271],
Section 9.2). Additionally, if the NLRI was previously advertised to
that peer, it must be withdrawn from service ([RFC4271],
--- 172,187 ----
speakers which may not support Extended Messages. Therefore, an
announcement in an Extended Message where the size of the attribute
set plus the NLRI is larger than 4,096 octets may cause lack of
reachability.

! A BGP speaker that has advertised
! the BGP Extended Message capability to its peers, may
! receive an UPDATE from one of its peers that produces an
ongoing announcement that is larger than 4,096 octets. When
propagating that UPDATE onward to a neighbor which has not advertised
! the BGP Extended Message capability, the speaker SHOULD try to reduce
the outgoing message size by removing attributes eligible under the
"attribute discard" approach of [RFC7606]. If the message is still
too big, then it must not be sent to the neighbor ([RFC4271],
Section 9.2). Additionally, if the NLRI was previously advertised to
that peer, it must be withdrawn from service ([RFC4271],