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

Robert Raszuk <robert@raszuk.net> Fri, 21 October 2016 16:03 UTC

Return-Path: <rraszuk@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 C561B129667 for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 09:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 PNd7QiSmL0o9 for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 09:03:13 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 D6328129655 for <idr@ietf.org>; Fri, 21 Oct 2016 09:03:12 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id c78so421209wme.0 for <idr@ietf.org>; Fri, 21 Oct 2016 09:03:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4SQME5bzbuOEKldHxQSLx8+cBsZKhenOjQol7FeLLiY=; b=d6BfErBxJDXL2C+5ljRPCofAkP/STLcgreLZqtclJyV+zatdbhurFQEFPwvnK77wyB iU898/aJTm0DIVhNj9P0DzdoIO78T9TuuKfLbb4Vyu/rEyPb93N51aQ5jCRDgToW8XmZ 4+JWBSxFiHbgas9QYxREuddbz5vj6aH5sjcmh/uJaD+NlcLbBxmo1b+kpcV0wtZ5cyoI 8gVtf7cFm+ou9en3YqXUcm4FmT5m4CCNKkP0E89IgeMvP+4tdKxOdIFDka6cTVZJvxQf LZ4yElw9V8QbeFa97CAJVKGn7hsZ5zJ9/iWT3xK6WEDCYOQxttUBeAxmjPo92vm2w3Q0 i0cA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4SQME5bzbuOEKldHxQSLx8+cBsZKhenOjQol7FeLLiY=; b=iXt9xHpDJwu20wJexwP1gJsoateLWQHAJFrXNji6rHb2dfS+cX6ID8JREoeznmiA2U +hvOPS01eVNs4jWBTT0v+e3Rq141PLlWhPr69dK33ne2jOj2s4HJzox5S/EJZjiTJKcs St3Gt61oEexC1vQhw9mjdvlNd58o7grDmi5gJ3ThfOtDo0apBXQFNoYiLuyRsfo8SnTv QVnZrioIm84Lppnlu7QL8nY7Cam5i4c8XczJrE02V7WjzhYYjvShP/deReNSe41b0bpQ PsJ2vnnLvTpESubbX8KOLrW8E6vJlfIwZikB1jsm26gVAQ5U9czv8hBG0+1QVZ3VnS1F XSCw==
X-Gm-Message-State: ABUngvdL49Jc9O12dDHdGI3qJ32XAR7IVy7lw8BkhUPhw4zQyxtniPVy6tz1nHu5B+ENvqJsZZgp2ywPhWxSFQ==
X-Received: by 10.194.94.232 with SMTP id df8mr1289355wjb.227.1477065791344; Fri, 21 Oct 2016 09:03:11 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.182.155 with HTTP; Fri, 21 Oct 2016 09:03:09 -0700 (PDT)
In-Reply-To: <20161021154958.GR27221@gir.theapt.org>
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> <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>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 21 Oct 2016 18:03:09 +0200
X-Google-Sender-Auth: Oyf8y2TXyt0zvcYr6Bbezmhdgjw
Message-ID: <CA+b+ERmrzCtFLP98D0YzRc-BJNbBWp3Ce6yKZr2cg1_QS0Oz5w@mail.gmail.com>
To: Peter Hessler <phessler@theapt.org>
Content-Type: multipart/alternative; boundary=047d7bb03aaecd9583053f622d4c
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/eFJExRHX6gWKwT2x3MdXToxRUZg>
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: Fri, 21 Oct 2016 16:03:15 -0000

Peter,

Who you control (who is the target of LC - can be expressed in the second 4
octets). And as such at least original discussions were about it.

So if you inject a large community it would have format:
SRC_ASN:DST_ASN:ACTION

In your specific case it would be: 1234:5678:ACTION

The comment was made that there is no way for implementation to insert
valid SRC_ASN .. well it clearly is.

But I am not suggesting spec should enforce it as it does limit use cases
for LC by not allowing to overload first 4 octets. On the other hand it
does provide more responsibility to whoever is injecting LCs so does
improve on BGP clarity and stability from protocol point of view.

Fixing on meaning on first 4 octets also provides very good tool to policy
filtering rules as you know what to expect there. For example you may have
policy allowing to pass any LC where first 4 octets contain any ASN also
listed in your AS_PATH - otherwise drop it. That may effectively help to
support LC global deployment much easier including the N-hops away
destinations.

Thx,
r.


On Fri, Oct 21, 2016 at 5:49 PM, Peter Hessler <phessler@theapt.org>; wrote:

> On 2016 Oct 21 (Fri) at 17:42:37 +0200 (+0200), Robert Raszuk wrote:
> :Hi Martijn,
> :
> :> Secondly, there's literally no way for the vendor to check whether an
> :> ASN belongs to "the entity that defines the meaning of the rest of the
> :> Large Community"
> :
> :Why not ?
> :
> :If you do not make those 4 octets configurable by spec and always fill it
> :with AS number defined in your BGP instance you will have assurance it
> :is ASN of the entity that defines the rest 8 octets of the LC as otherwise
> :you will likely not establish any EBGP sessions to your peers.
> :
> :So there is very easy way to enforce it today in any BGP implementation.
>
> Say I am AS 1234, and I want to control AS 5678.  My transit ISP is AS
> 9876.
>
> If I set
>
> local-as 1234
> peer-as 9876
> set large-community 5678:666:1
>
> How is the implementation supposed to know to allow it?
>
> Limitations in the implementation completely defeat the purpose of this
> spec.
>
>
> :However the question is should it be enforced at all ?
> :
>
> MUST NOT is a very important part of this spec, and is enforced a few
> times in the document.
>
>
> :Best,
> :R.
> :
>
>
>
>
> --
> The moving cursor writes, and having written, blinks on.
>