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

David Farmer <farmer@umn.edu> Thu, 27 October 2016 05:10 UTC

Return-Path: <farmer@umn.edu>
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 2C77B129B29 for <idr@ietfa.amsl.com>; Wed, 26 Oct 2016 22:10:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.231
X-Spam-Level:
X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 hXi5I-s3uvMk for <idr@ietfa.amsl.com>; Wed, 26 Oct 2016 22:10:34 -0700 (PDT)
Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F6C129B27 for <idr@ietf.org>; Wed, 26 Oct 2016 22:10:34 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 3BDC373B for <idr@ietf.org>; Thu, 27 Oct 2016 05:10:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbIs13In8Ik7 for <idr@ietf.org>; Thu, 27 Oct 2016 00:10:34 -0500 (CDT)
Received: from mail-qt0-f198.google.com (mail-qt0-f198.google.com [209.85.216.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 09F746CD for <idr@ietf.org>; Thu, 27 Oct 2016 00:10:33 -0500 (CDT)
Received: by mail-qt0-f198.google.com with SMTP id p53so15195431qtp.1 for <idr@ietf.org>; Wed, 26 Oct 2016 22:10:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MO7IBHJd62kRysl0AKCH14oBgLVppzc1pdwGfhaX0jk=; b=io+ff3QRA/GLrxnRzKzG4wGeAxJwHTeAggHZLOHhyPU8gQEDfYFxFId7nu8hXwJWsY HgEMpnz8VVcuvmLjTw9mzdFY+0aswdrUOP6yvrMWXd0dIXwOU+AueNOSMAZ5hoan7T83 lEwoaCl3qCvxeWN+yg7Shur3ZJVNNvZ3FT9z2Z8Zv2DWwC7Dmo4jU6J0TPjWA1pXrZ9v BqqQijFdo+Buz7OKqgiwpzEUJXIHYh2FLUELFp7KhMCb63YR1mezuYVlgc3OVZcLkBc+ MFLisHCqCz21nETxzESWVLBwNXRKyf5g+22MFu+DRv0gHLZo+RT858FNORxTDGFfyTc5 Yjuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MO7IBHJd62kRysl0AKCH14oBgLVppzc1pdwGfhaX0jk=; b=hMk+e7SYGNqRoa7QtqNPwB7efaLYU2uBHrUaJki0C8J8Qd/6hj5DHfuupLa2PIPVyY aVKFqjxUrXmPlS1/yRudLRj8DSc1T1+eZTXxkaIEGIcAppf2WxyZx5E8kz/XreLrBiQg lwqr2KgSzwTS8+xbsvvJQNZhj5OgupKywWCLWimh07nXGLLYwdu9FPxYN4+cF16i3sA7 EEIOyZhOGuM/9rrWiPA1c1vKeIkjPmM/Nyon4MoonLIcBoqFEFtMhjAIt7AWO6bbk4Oa EooGNyIsYy7G6yRK8UCybZy3fTWxy6bj2iDq0JhhmutB4fzhqLMf5tWVI23Ax1rVm0nk tKkg==
X-Gm-Message-State: ABUngvcM40kPdYMyoRO+in8yAp0yxfU2EmawG2DilGvcax7sZ/6s4e63ZB/zETsws2sJMIrxwzTf9kd1trHioyW8E/q64e8VLC5t1oMSgh9cVjkrImUcr3x18JYS0ZmChfcP3AJKIe9e/rlCsw==
X-Received: by 10.200.35.229 with SMTP id r34mr4862985qtr.22.1477545033433; Wed, 26 Oct 2016 22:10:33 -0700 (PDT)
X-Received: by 10.200.35.229 with SMTP id r34mr4862974qtr.22.1477545033263; Wed, 26 Oct 2016 22:10:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.41.230 with HTTP; Wed, 26 Oct 2016 22:10:32 -0700 (PDT)
In-Reply-To: <DF2B3771-7186-43D9-AAD4-3F6D92DDBFA4@juniper.net>
References: <20161020215938.GE1074@Vurt.local> <adb00bcd7b8e45db857eae7019c646fc@XCH-ALN-014.cisco.com> <ae5da282-201c-f745-9f26-67ce73826bd5@i3d.net> <CA+b+ERkV2PBtzzx=uoygDzvTyJzunROCNX=0Y4phvGdn=oK5Xw@mail.gmail.com> <20161021154958.GR27221@gir.theapt.org> <CA+b+ERmrzCtFLP98D0YzRc-BJNbBWp3Ce6yKZr2cg1_QS0Oz5w@mail.gmail.com> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <CA+b+ERn6dG+R8+UV-jaRXAV7eWQBygqEQp4VY4x1yKukpVKhTA@mail.gmail.com> <20161021164241.GC32387@Vurt.local> <20161022123423.GD79185@Space.Net> <20161023233431.GA76131@gweep.net> <DF2B3771-7186-43D9-AAD4-3F6D92DDBFA4@juniper.net>
From: David Farmer <farmer@umn.edu>
Date: Thu, 27 Oct 2016 00:10:32 -0500
Message-ID: <CAN-Dau3ABDgjkYYtzmVgC7xcE4ODTV8tu5S2x9No7f3g-T=kOQ@mail.gmail.com>
To: "John G. Scudder" <jgs@juniper.net>
Content-Type: multipart/alternative; boundary=001a1142bb38d901c1053fd1c24e
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/y8nKAJJd9aI7gXThVsvpye8IZvA>
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: Thu, 27 Oct 2016 05:10:36 -0000

On Mon, Oct 24, 2016 at 12:10 PM, John G. Scudder <jgs@juniper.net>; wrote:

> Hi Everybody,
>
> There has been a fair amount of debate about this sentence in the draft:
>
> "   Global Administrator:  A four-octet namespace identifier.  This
>      SHOULD be an Autonomous System Number."
>
> Many of the objections can be summed up by saying "I can't program a
> router to enforce this rule". This is true, but as Brian has pointed out,
> it's hardly the first example of such a thing in a BGP spec. (Indeed, RFC
> 1997 says the equivalent community field "shall be encoded using an
> autonomous system number" but of course provides no enforcement mechanism.)
>
> Other objections seem to be pursuing the question of whether it might be
> possible to revise the proposal to make the rule enforceable. Whether or
> not this is possible in principle seems beside the point since it would
> violate the "small and simple" 1997-equivalent goal of the proposal that
> was part of the consensus when the WG accepted it.
>
> After reviewing the mailing list discussion to date, it's the chairs'
> sense that consensus is trending towards keeping the text as written. As
> always, if you disagree with that consensus and feel you have something new
> to add to the discussion, please do.
>
> Thanks,
>
> --John and Sue
>

I support the consensus as described. However, maybe an alternative to at
least partially address some of the concerns is to discuss the consequences
of the Global Administrator and Local Data Part fields being used
differently than intended. How about something like the following;

   The Global Administrator field SHOULD be an Autonomous System Number
   and is intended to allow different Autonomous Systems to define Large
BGP
   Communities without collision. The meaning associated with the Local
Data
   Part fields are locally defined by each Autonomous System.  Operational
use
   of Large BGP Communities inconstant with this intent could result in
   undesired routing behavior. Implementations MUST allow the operator to
   specify any value for the Global Administrator and Local Data Part
fields.

Thanks.

===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================