Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

"Susan Hares" <shares@ndzh.com> Wed, 07 August 2019 15:12 UTC

Return-Path: <shares@ndzh.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 4FA1C120305; Wed, 7 Aug 2019 08:12:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.948
X-Spam-Level:
X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 nZcOH5kkSv2Y; Wed, 7 Aug 2019 08:12:09 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 5C599120173; Wed, 7 Aug 2019 08:12:09 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=97.112.26.170;
From: Susan Hares <shares@ndzh.com>
To: "'Enke Chen (enkechen)'" <enkechen@cisco.com>, 'Jeffrey Haas' <jhaas@pfrc.org>, 'Alvaro Retana' <aretana.ietf@gmail.com>
Cc: "'idr@ietf. org'" <idr@ietf.org>, draft-ietf-idr-bgp-extended-messages@ietf.org, idr-chairs@ietf.org
References: <CAMMESsyvuU8_dBOeoOXPBt=-HwoF0eHvYgm5d8CgF-4o_oiP=g@mail.gmail.com> <20190731211602.GA31271@pfrc.org> <119404A5-8384-456B-9677-0445899B008F@cisco.com>
In-Reply-To: <119404A5-8384-456B-9677-0445899B008F@cisco.com>
Date: Wed, 07 Aug 2019 11:12:02 -0400
Message-ID: <013f01d54d32$7839dfe0$68ad9fa0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQGpIDFBzkOoouXytnStx3gjANvuAAE2Sc/TAeOSk7unL1UogA==
X-Antivirus: AVG (VPS 190807-0, 08/07/2019), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Y3FNlCMmlM6ykVCoiTzozXyWh2s>
Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages
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, 07 Aug 2019 15:12:12 -0000

Enke:

I apologize for the delay in responding to you, but  I am confused by your response.   
Are you also stating that this portion of the text is incorrect. 

> “A peer which does not advertise this capability MUST NOT send BGP
    >    Extended Messages, and BGP Extended Messages MUST NOT be sent to it.”

Thank you for your review of this important addition. 

Cheerily, Sue

-----Original Message-----
From: Enke Chen (enkechen) [mailto:enkechen@cisco.com] 
Sent: Wednesday, July 31, 2019 5:50 PM
To: Jeffrey Haas; Alvaro Retana
Cc: idr@ietf. org; draft-ietf-idr-bgp-extended-messages@ietf.org; Susan Hares; idr-chairs@ietf.org; Enke Chen (enkechen)
Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

Hi, Jeff:

>>  Note that RFC 6793 (4-byte ASes) require bi-directional advertisement.

No, this statement is not correct. It is fundamental (in transition) for a BGP  speaker to be able to talk to both NEW speakers (that have advertised the capability), and OLD speakers (that have not advertised the capability).  Different encodings are used in the UPDATE message depending on whether the 4-byte AS capability is received from a neighbor.

Thanks.  -- Enke

-----Original Message-----
From: Idr <idr-bounces@ietf.org> on behalf of Jeffrey Haas <jhaas@pfrc.org>
Date: Wednesday, July 31, 2019 at 2:16 PM
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: "idr@ietf. org" <idr@ietf.org>, "draft-ietf-idr-bgp-extended-messages@ietf.org" <draft-ietf-idr-bgp-extended-messages@ietf.org>, Susan Hares <shares@ndzh.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

    On Wed, Jul 31, 2019 at 01:06:04PM -0700, Alvaro Retana wrote:
    > During the IESG Evaluation, Sue pointed out that we removed the piece of
    > text below:
    > 
    > Just to let you know that the text below:
    > 
    > “A peer which does not advertise this capability MUST NOT send BGP
    >    Extended Messages, and BGP Extended Messages MUST NOT be sent to it.”
    > 
    > was added due to comments on the IDR WG list from reviewers and operators.
    > 
    > Given that Extended Messages is a very important extension to BGP, and even
    > though I didn’t see objections in the thread mentioned above, I want to
    > confirm one more time that the current text is ok with the WG. 
    
    I am fine with the current text, although my opinion is nuanced.
    
    By requiring bi-directional advertisement of the capability, UPDATEs sent
    from one can have NOTIFICATIONs of similar size.  This avoids some ugly edge
    conditions that would result from uni-directional advertisement of the
    capability.
    
    The converse argument, which I'm not supporting, is that uni-directional
    advertisement intentionally lets peers opt-out of receiving extended
    messages, even it understands them.
    
    Let the bi-directional requirement stand.
    
    Note that RFC 6793 (4-byte ASes) require bi-directional advertisement.
    
    -- Jeff
    
    _______________________________________________
    Idr mailing list
    Idr@ietf.org
    https://www.ietf.org/mailman/listinfo/idr