Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Wed, 19 October 2016 17:37 UTC

Return-Path: <jheitz@cisco.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 1ACB91296B7 for <idr@ietfa.amsl.com>; Wed, 19 Oct 2016 10:37:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.953
X-Spam-Level:
X-Spam-Status: No, score=-14.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 cF5G-x3DQyWb for <idr@ietfa.amsl.com>; Wed, 19 Oct 2016 10:37:39 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F69129595 for <idr@ietf.org>; Wed, 19 Oct 2016 10:37:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5752; q=dns/txt; s=iport; t=1476898659; x=1478108259; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/T0QL13JwSU6iNX/LFm8Wr7Uo1KVJcjSO7VsnSGnlS0=; b=bJoGgLBdAarM/F/7Xmm24C7unbcA4Ap1byOmJrMczZ7cr8nsMezmI8Gu /SdGNPtkxjsiQbhs3M0mkagsHJp7HshxpCLMnsAiPRE1uFRkz82LHWkFt VI3yxFmKQtONnARM8S6lMBpy+ZZn8x2TpD6XoK/ormIOTyqHxjXy0d0bx Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A0AQDcrgdY/5hdJa1cGQEBAQEBAQEBAQEBBwEBAQEBgz4BAQEBAR1XfQcBjSyWe5Q7gggcC4JEgzYCgXw/FAECAQEBAQEBAWIohGIBAQEEAQEBNzQLDAQCAQgRBAEBAR4JBycLFAkIAgQOBQgMiD4Ow3ABAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYY9hFWEKgEBhXoFmg0BkAKBdYRpgzeFa4x+g38BHjZVgwA6gTpyhh2BIAF/AQEB
X-IronPort-AV: E=Sophos;i="5.31,367,1473120000"; d="scan'208";a="337813751"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2016 17:37:38 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u9JHbcM5027911 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Oct 2016 17:37:38 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Oct 2016 12:37:37 -0500
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Wed, 19 Oct 2016 12:37:37 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: "t.petch" <ietfc@btconnect.com>
Thread-Topic: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
Thread-Index: AdIotF10Qx6LizvwQ9uItB9ryESdDgANiv0AACybzYAAADoegAAC4vMAABNp+sQADVTs8A==
Date: Wed, 19 Oct 2016 17:37:37 +0000
Message-ID: <df2e7d4669d64fa59b1e1cfcb188dbbb@XCH-ALN-014.cisco.com>
References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net>
In-Reply-To: <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [128.107.151.84]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/lsBIrML8ZlL6egIstvWSYjY_eBM>
Cc: IETF IDR WG <idr@ietf.org>
Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
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: Wed, 19 Oct 2016 17:37:42 -0000

1. Router software cannot check whether a number is an ASN.

2. Any numbers should be allowed between consenting adults. That is within an AS or between adjacent ASes.

3. "Reserved" means reserved for use. So router software cannot disallow these either.

I can see how the existing text is a little terse:
   The Global Administrator field is intended to allow different
   Autonomous Systems to define Large BGP Communities without collision.

The best we can do is explain the situation:

A Large Community that
is intended to be sent to multiple ASes SHOULD contain an ASN
in the Global Administrator field. The ASN SHOULD be one that
is assigned to the entity
that defines the meaning of the rest of the Large Community.
This allows a route to carry multiple Large Communities, the meaning
of each being defined by different independent entities.

Tom, will this text satisfy you?


Thanks,
Jakob.


> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch
> Sent: Wednesday, October 19, 2016 3:47 AM
> To: Jeffrey Haas <jhaas@pfrc.org>
> Cc: IETF IDR WG <idr@ietf.org>; Sue Hares <shares@ndzh.com>
> Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
> 
> I remain unhappy with this I-D.
> 
> I find it ironic that the messages for this Last Call should be
> interspersed with those relating to what goes wrong when someone
> somewhere else in the world uses a field in an unexpected way.  This
> reinforces my belief that this I-D should be more forceful in calling
> out the dangers (eg MUST instead of SHOULD).
> 
> I think that this I-D is factually incorrect, or at least open to
> misinterpretation,  when it says
> '[RFC1997] BGP Communities attributes are four-octet values split into
>    two two-octet words.  The most significant word is usually
>    interpreted as an Autonomous System Number (ASN) '
> 
> RFC1997 says
> 'The community attribute values ranging from 0x0000000 through
>    0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved.
> 
>    The rest of the community attribute values shall be encoded using an
>    autonomous system number in the first two octets.  '
> 
> Note the use of 'shall'.  Had that been written after RFC2119 then it
> would have been IMO 'MUST' or 'SHALL' not the weasily 'SHOULD' so this
> I-D is weakening the meaning compared to RFC1997.
> 
> If this I-D were to say that RFC1997 specified a 'MUST' (in effect) but
> that 20 years of experience showed that it need not be that strong, that
> ambiguities of interpretation have never been a problem for routing,
> pehaps by adding a note in the Security Considerations, then I would
> accept that.  As it stands, I think that this I-D is risky (and would be
> even if everyone who reads it knows what the IETF means by 'SHOULD' - I
> think that this is not the case and that those outside the IETF will
> read 'SHOULD' as a stronger enforcement than it is).
> 
> So, interspersed with those e-mails about other fields that have
> unexpected values, I oppose this going forward just yet.
> 
> The question of reserved values is another can of worms.  If they are
> not reserved, then clearly they are an example of 'SHOULD' not meaning
> 'MUST' so they need reserving, but then, as Jeff is pointing out, you
> open up the question of translation (something I flagged earlier as an
> open issue).
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Jeffrey Haas" <jhaas@pfrc.org>
> Sent: Tuesday, October 18, 2016 9:38 PM
> 
> > On Oct 18, 2016, at 3:15 PM, Job Snijders <job@ntt.net> wrote:
> >
> >> Part of the idea behind reserving 65535:*:* was to reserve a space
> that
> >> could later be used for well-knowns, if that was desired - but to not
> >> spend time now arguing about details of what well-knowns are
> necessary.
> >>
> >> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs.
> >
> > Jeff argues that a justification should be added. Maybe someone can
> > pitch in one or two sentences that explain why these are reserved?
> 
> That's certainly part of it.  While I think many people can see the
> reason why you might want to do such a reservation, to do so you should
> have a practical reason in the document.
> 
> For the 65535:*:* case, for symmetry with RFC 1997, you'd probably want
> to note that if it's used for that symmetry that either the existing
> well known community registry is used at IANA or that a new one would
> need to be created.  Alternatively, you just say the work is expected
> and defer to a future document.
> 
> Note by doing this, you're setting up some expectations about
> translation of communities from one space to another.  FWIW, I don't
> recommend this and simply suggest that you recommend *not* using these
> for common use in case someone decides that they want to do so.  I know
> your organization and others such as Deutsche Telecom have some thoughts
> about what translation infrastructure might look like, and such
> mechanisms would have impact.
> 
> With regard to the 0: and max-uint32: cases, after dealing with the
> headaches associated with helping with documents such as the as0 and RFC
> 7300 and putting in some restrictions in the configuration... followed
> by having to take them away, I'm very reluctant to put in anything
> beyond "we think it's a bad idea to use these, so pretty please don't"
> 
> -- Jeff (ask me about my RFC 7300 hate mail over beer...)
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr