Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-large-community-11: (with COMMENT)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Mon, 02 January 2017 13:42 UTC

Return-Path: <ietf@kuehlewind.net>
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 0AC2E1295EF for <idr@ietfa.amsl.com>; Mon, 2 Jan 2017 05:42:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.002
X-Spam-Level:
X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 1TXR_iIykCdg for <idr@ietfa.amsl.com>; Mon, 2 Jan 2017 05:42:34 -0800 (PST)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CF93129459 for <idr@ietf.org>; Mon, 2 Jan 2017 05:42:34 -0800 (PST)
Received: (qmail 17668 invoked from network); 2 Jan 2017 14:42:31 +0100
Received: from p5dec2761.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.39.97) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 Jan 2017 14:42:31 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <20170102132535.GE60639@Vurt.local>
Date: Mon, 2 Jan 2017 14:42:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <99BB7D9F-1715-422B-86E5-9C01F0D6C35B@kuehlewind.net>
References: <148336287139.21869.17056871012280815893.idtracker@ietfa.amsl.com> <20170102132535.GE60639@Vurt.local>
To: Job Snijders <job@instituut.net>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/rgv0hdvDDZL2ABeFljjabgCOlIg>
Cc: idr@ietf.org, draft-ietf-idr-large-community@ietf.org, The IESG <iesg@ietf.org>, idr-chairs@ietf.org
Subject: Re: [Idr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-idr-large-community-11=3A_=28with_COMMENT=29?=
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, 02 Jan 2017 13:42:37 -0000

Okay, thanks for your clarification. Was reading this part in section 5 and therefore wondering if any action should follow. But if that was discussed that’s fine.


> Am 02.01.2017 um 14:25 schrieb Job Snijders <job@instituut.net>;:
> 
> Dear Mirja,
> 
> On Mon, Jan 02, 2017 at 05:14:31AM -0800, Mirja Kuehlewind wrote:
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-idr-large-community-11: No Objection
> 
> Thank you for your review.
> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> One question: Since the Global Administrator field could also be not an
>> ASN, would it be useful to say something about what should be done if an
>> unknow value is received (ignore, remove, log an error...)?
> 
> Section 5 states:
> 
>    """
>    The BGP Large Communities Global Administrator field may contain
>    any value, and a BGP Large Communities attribute MUST NOT be
>    considered malformed if the Global Administrator field contains an
>    unallocated, unassigned or reserved ASN.
>    """
> 
> Further more, based on our experience with the current implementations
> [1], [2] there was no perceived ambiguity amongst the implementers what
> to do with non ASN values in the Global Administator field. The global
> administrator field contains just an unsigned 32-bit integer.
> 
> The consensus on the mailing list was to treat the non ASN values
> exactly the same as normal values. As such it would not be correct to
> ignore, remove, or log an error.
> 
> In other words, the ability to put a non-ASN values in the Global
> Administrator field is by design.
> 
> Kind regards,
> 
> Job
> 
> [1]: http://largebgpcommunities.net/implementations/
> [2]: https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-large-community%20implementations
>