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

"Susan Hares" <shares@ndzh.com> Tue, 30 July 2019 16:22 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 043371201C7; Tue, 30 Jul 2019 09:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.949
X-Spam-Level:
X-Spam-Status: No, score=0.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, 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 hHw-UNdgUOFg; Tue, 30 Jul 2019 09:22:11 -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 7673312016F; Tue, 30 Jul 2019 09:22:11 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.25.161.218;
From: Susan Hares <shares@ndzh.com>
To: 'Alvaro Retana' <aretana.ietf@gmail.com>, 'Mirja Kühlewind' <ietf@kuehlewind.net>, 'The IESG' <iesg@ietf.org>
Cc: idr-chairs@ietf.org, draft-ietf-idr-bgp-extended-messages@ietf.org, idr@ietf.org
References: <156449387998.2643.18137174091685834097.idtracker@ietfa.amsl.com> <CAMMESsz6gDtk=CytjQPDRSPiWvRB0X-R4MP2fZeiTRH_Z-2c_w@mail.gmail.com>
In-Reply-To: <CAMMESsz6gDtk=CytjQPDRSPiWvRB0X-R4MP2fZeiTRH_Z-2c_w@mail.gmail.com>
Date: Tue, 30 Jul 2019 12:22:02 -0400
Message-ID: <003b01d546f2$ebf946f0$c3ebd4d0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01D546D1.64EA17F0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHOmb0+S0HtjOtDEV+BauB+7nkX8wMOHf7upthAjLA=
Content-Language: en-us
X-Antivirus: AVG (VPS 190730-0, 07/30/2019), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/TG45nKZOY3DwwQd4G4kepILf28M>
Subject: Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)
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: Tue, 30 Jul 2019 16:22:13 -0000

Alvaro:

 

On #3, I’ve not seen the separate thread you’ve started with the authors.  Did I miss something as the shepherd? 

 

On #2, the Discussion from the WG (over long period of time) suggested that this exact statement was not clearly stated in RFC4271.   

 

Given that point, we allowed the normative case.  It is a judgment case.  Do you want to engage in an argument pro/con with Mirja on the WG list or do you want to determine at AD level that the text should be non-normative? 

 

Sue Hares

Shepherd 

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Alvaro Retana
Sent: Tuesday, July 30, 2019 10:39 AM
To: Mirja Kühlewind; The IESG
Cc: idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; idr@ietf.org
Subject: Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

 

On July 30, 2019 at 9:38:01 AM, Mirja Kühlewind via Datatracker (noreply@ietf.org) wrote:

 

Mirja:

 

Hi!

 

Thanks for your review.

 

...

--------------------------------------------------------------------- 
COMMENT: 
---------------------------------------------------------------------- 

Some comment on use of normative language: 

1) I know what the intention is here but this normative language is not used correctly (sec 4): 
"A BGP speaker 
MAY send Extended Messages to a peer only if the Extended Message 
Capability was advertised by both peers." 
This should be a MUST anyway (and moving the "only"): 
"A BGP speaker 
MUST only send Extended Messages to a peer if the Extended Message 
Capability was advertised by both peers." 
Or you go for the MUST NOT (and maybe even two sentence) to make it crystal clear, e.g. 
"A BGP speaker 
MUST NOT send Extended Messages to a peer if the Extended Message 
Capability was not advertised by both peers. A BGP speaker 
MAY send Extended Messages to a peer if the Extended Message 
Capability was advertised by both peers." 

This point (and your last one) should be clarified in light of clarifications to rfc5492 (Capabilities Advertisement) that were discussed in Montreal last week.  I’ve started a separate thread with the authors.

 

2) sec 4: 
"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 MUST treat this as a malformed message, and 
MUST generate a NOTIFICATION with the Error Subcode set to Bad 
Message Length (see [RFC4271] Sec 6..1)." 
If this is specified normatively in RFC4271, you should not use normative language here as well. 
I suggest s/MUST/will/ 

3) sec 4: 
s/then it must NOT be sent to the neighbor/then it MUST NOT be sent to the neighbor/ 
and 
s/it must be withdrawn from service/it MUST be withdrawn from service/ 

All the actions on these two points are in fact normatively specified in rfc4271 (which is the reason for the specific references)…so we should use non-Normative text in both cases.  

IOW: your point in #2 is accurate, but the changes suggested in #3 should not be applied.

 

Thanks!!

Alvaro.

 

4) sec 4 
"In an iBGP mesh, if BGP Extended Messages are to be advertized, all 
peers MUST advertize the BGP Extended Message capability." 
Which action(s) should be taken if that is not the case?