Re: [Idr] AD Review of draft-ietf-idr-large-community-09

Ignas Bagdonas <ibagdona.ietf@gmail.com> Fri, 02 December 2016 14:31 UTC

Return-Path: <ibagdona.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 3A276129FAC; Fri, 2 Dec 2016 06:31:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 JDH-YkdNebC8; Fri, 2 Dec 2016 06:30:57 -0800 (PST)
Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 5C0D1129FA8; Fri, 2 Dec 2016 06:30:57 -0800 (PST)
Received: by mail-pf0-x22a.google.com with SMTP id d2so53129854pfd.0; Fri, 02 Dec 2016 06:30:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=9Dq+o0S0YYg7/nbZyd4lun20R99tHIIJ7a/5uFEwsLs=; b=GUFLBk/wqEOjpc3WOpm8wJfUEecCsphNJoXY7QKIvWmLA9hZTf/g8AzRPcVmLm4h3g dV/VrlYFJnurX6rW55/vN78z3AFFMuW2wiNTrL5zB4YDRCgKrUbsRmiNtWi/UpVtsGBw k7Nb3koyjS9IQ7UwtFtyOgHqQ7a40MwNBcIeQy3cQw8OJmr+a3r+P60803owBTiq+wjQ v1W90/8Ed/Kikfp0jng6NuM3BHHvd6pOlIrynYAH2cygLxQ+Yt5C4tnKRJfUVjFOCMQ9 gLQvTmRIsF+hP29DUzqcovEwFsgeSVutQMscXurg6LKVJBA1r7XtQ/H5beqXF6IybBbV Fh7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=9Dq+o0S0YYg7/nbZyd4lun20R99tHIIJ7a/5uFEwsLs=; b=Yh74nickXadI3aVmfhOBMdFA0oNtveA/Ud/QpQmrdXSVTKaiUCsCBEh6o5wUdFgowW GnbJ/NQnskiKkZQWeFpIlNmZ36Fvg/dC2wvFQAjjxENKI/Fy3Kibvf/TTZS5sI8M6cYe 9dN2ZGYukshvW+77lBtbRocXDORJMp8n9v36wdpojiyw+iYTjPusL9IC3PGFAyQSOdok zdRfTxR9KYTBD6/Y7WNU5bX7qW5vigBpQeemeXClr3x3DQzO+Gnroix4Ajsr7oteh65Q T0pXilLuM9GIFNrFp863/ODnUbp4OO09vUufUdrMJBZ2OfHiGm1s1o5HXX0l6JB5d1BY vKhQ==
X-Gm-Message-State: AKaTC03QnLETAwstXbaHpXgP7dCelc40mlGyk/w0IPccEwaQsqnxgVIfvSQZzYUxDTrmKg==
X-Received: by 10.84.216.20 with SMTP id m20mr97139135pli.126.1480689056678; Fri, 02 Dec 2016 06:30:56 -0800 (PST)
Received: from [172.16.184.157] ([101.100.166.67]) by smtp.gmail.com with ESMTPSA id b71sm8324628pfj.62.2016.12.02.06.30.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Dec 2016 06:30:56 -0800 (PST)
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, "draft-ietf-idr-large-community@ietf.org" <draft-ietf-idr-large-community@ietf.org>
References: <CE1331E4-3ECA-41D7-801F-05519778E8DA@cisco.com> <94f48779-14c8-0ec0-93ef-69eeba49e5be@gmail.com> <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com>
From: Ignas Bagdonas <ibagdona.ietf@gmail.com>
Message-ID: <419db8cd-e4ae-a191-bfd3-8e35ca76b0cd@gmail.com>
Date: Fri, 2 Dec 2016 14:30:52 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <8B6BA07A-D636-4D8C-8B02-A5CB05538AAF@cisco.com>
Content-Type: multipart/alternative; boundary="------------49A8A1F331DCF15197B60807"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/WM6ny_-BytRddof0dNyuSHvxiI4>
Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09
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: Fri, 02 Dec 2016 14:31:00 -0000

Alvaro,


> > The intention is to react on the first instance of the duplicate 
> community - analogous to applying
>
> > RFC7606 to the contents of the large community path attribute 
> itself. Would a following text address
>
> > your comment:
>
> >
>
> > A receiving speaker MUST act on the first instance of duplicate BGP 
> Large Community value, and
>
> > MUST silently ignore any other occurrence of such duplicated values. 
> Duplicate BGP Large
>
> > Community values MUST NOT be transmitted.
>
> >
>
> > This reverses the receive and transmit handling - ignore any 
> subsequent duplicate community values
>
> > and do not send duplicates. Whether an implementation actually 
> removes anything or just ignores is
>
> > an internal matter to the implementation.
>
> Removing and ignoring are obviously different things…  The text above 
> is fine with me, but I would ask: what do the current implementations 
> do?  If they remove (as originally specified), then I would suggest 
> you keep that.
>

The implementations that I am familiar with do interpret first instance 
of the community value and do not react (=ignore) any other instances of 
the same community value on the receive side. Whether it is truly first 
instance as it appears on the wire or the first instance of the sorted 
received community is an implementation detail, the outcome is that 
single community value is interpreted only once. Therefore on the 
transmit side there are no duplicate values. This is based on decoding, 
processing, and then encoding the community attribute and not forwarding 
it as a binary object only - I am not aware of any implementation that 
does that. Could anyone familiar with implementations that behave 
differently please speak up?


> > > C2. There seems to be a contradiction in the expected use of 
> reserved Global Administrator
>
> > > values.  Section 2 says that the “Global Administrator 
> field…SHOULD either be one of the reserved
>
> > > values as defined below, or an Autonomous System Number (ASN)”, 
> but later Section 5 says: “The
>
> > > following Global Administrator values are reserved: 0, 65535, and 
> 4294967295.  Operators SHOULD
>
> > > NOT use these Global Administrator values.”   IOW: “SHOULD use one 
> if the reserved values” and
>
> > > “SHOULD NOT use the reserved values” contradict each other.  It 
> seems to me that because 0,
>
> > > 65535, and 4294967295 are already reserved ASNs, *and* that “the 
> Local Data Parts are to be
>
> > > interpreted as defined by the owner of the ASN”, then only 
> assigned ASNs should ever be used ---
>
> > > *and* given that it is not an error to use an value, then there is 
> no real advantage in reserving
>
> > > anything (again!). Suggestion: reference the RFCs where 0, 65535, 
> and 4294967295 are reserved
>
> > > and just say that those numbers SHOULD NOT be used because if a 
> Special Use Large Community is
>
> > > ever defined, those values may be used.
>
> >
>
> > For section 2: Global Administrator field SHOULD be an Autonomous 
> System Number (ASN) or one of
>
> > the reserved values defined in Section 5.
>
> >
>
> > For section 5: Global Administrator values corresponding to reserved 
> use Autonomous System
>
> > Number values of 0 [RFC7607], 65535 [RFC7300], and 4294967295 
> [RFC7300] are reserved.
>
> >
>
> > Would this work?
>
> Question for you:  do you want the operators to use 0, 65535, and 
> 4294967295 whenever they want (which is what the new text says), OR, 
> do you want them not to use them because they could be used later for 
> a special purpose (which is what the original text seemed to indicate)??
>

Communities - any type, standard, extended, large, wide - for practical 
cases are aligned with AS numbers. As there are reserved AS numbers that 
potentially could be used for some future extensibility functionality, 
in the same way community values equal to those AS numbers are reserved 
for potential future extensibility - it is a mechanism to ensure 
functional parity of the namespaces for AS numbers and community values. 
My personal interpretation of the new text for sections 2 and 5 is that 
reserved values could be present in the global administrator field but 
then in that case local parts have specific, predefined meaning and are 
not used for arbitrary values (that meaning is not defined today 
though). Therefore as AS number values of 0, 65535 and 0xffffffff are 
reserved and should not be used as defined today (this is the key part - 
today), corresponding community values should follow the same procedure.


> I’m having a hard time with this document “reserving” any value 
> because the number space is not really one where values are assigned 
> (in the typical IANA sense: create a registry, etc. – and I doubt you 
> want to make it that way)…but the contents can be (SHOULD) what is 
> contained in an already existing registry (ASNs) that has distributed 
> control.
>
Indeed the intention is not to define a new registry if that can be 
avoided. Community values follow AS number values (technically it is 
just an uint32_t number that has an interpretation of AS number value).



> Assuming that you would prefer the operators NOT to use 0, 65535, and 
> 4294967295, then here’s my suggestion:
>
Yes, the intention is exactly that - reserved values should not be used.

> OLD> (Section 2)
>
>    The Global Administrator field is intended to allow different
>
>    Autonomous Systems to define BGP Large Communities without collision.
>
>    This field SHOULD either be one of the reserved values as defined
>
>    below, or an Autonomous System Number (ASN).  If it is a reserved
>
>    value, then the Local Data Parts are as defined by the reserved
>
>    value.  If it is an ASN then the Local Data Parts are to be
>
>    interpreted as defined by the owner of the ASN.
>
> NEW>
>
>    The Global Administrator field is intended to allow different
>
>    Autonomous Systems to define BGP Large Communities without collision.
>
>    This field SHOULD be an Autonomous System Number (ASN).  The use of
>
>    Reserved ASNs (0 [RFC7607], 65535 and 4294967295 [RFC7300]) is NOT
>
>    RECOMMENDED.
>
> …and then eliminate Section 5…
>
> If you really want operators not to use the Reserved ASNs ever because 
> a special use may be though up later, then use “MUST NOT” above.
>

Personally I agree with this text.


Ignas