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

Peter Hessler <phessler@theapt.org> Fri, 21 October 2016 16:20 UTC

Return-Path: <phessler@theapt.org>
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 A775812965F for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 09:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.332
X-Spam-Level:
X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001] autolearn=ham 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 hR1GpeLCA5aT for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 09:20:20 -0700 (PDT)
Received: from gir.theapt.org (gir.theapt.org [IPv6:2001:470:1f0b:8b2::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C76129664 for <idr@ietf.org>; Fri, 21 Oct 2016 09:20:19 -0700 (PDT)
Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 37AC57891A; Fri, 21 Oct 2016 18:20:18 +0200 (CEST)
Date: Fri, 21 Oct 2016 18:20:16 +0200
From: Peter Hessler <phessler@theapt.org>
To: Robert Raszuk <robert@raszuk.net>
Message-ID: <20161021162016.GS27221@gir.theapt.org>
References: <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> <CA+b+ERmrzCtFLP98D0YzRc-BJNbBWp3Ce6yKZr2cg1_QS0Oz5w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+b+ERmrzCtFLP98D0YzRc-BJNbBWp3Ce6yKZr2cg1_QS0Oz5w@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/CwVfHAU3Ix643Vjs_NSzuclkFdA>
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:20:21 -0000

Hi Robert

On 2016 Oct 21 (Fri) at 18:03:09 +0200 (+0200), Robert Raszuk wrote:
: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
:

Ahh, I see the misunderstanding.

The GA field is normally the ASN of the _entity defining that
namespace_. aka, DEFINING_ASN:ACTION:DST_ASN.

Sec 1
   To address these shortcomings, this document defines a Large BGP
   Communities attribute encoded as one or more twelve-octet values,
   each consisting of a four-octet ASN and two four-octet operator-
   defined values, each of which can be used to denote properties or
   actions significant to that ASN.

Sec 2:
   Global Administrator:  A four-octet namespace identifier.  This
      SHOULD be an Autonomous System Number.
...
   The Global Administrator field is intended to allow different
   Autonomous Systems to define Large BGP Communities without collision.

To me, that means that 5678 has defined some values that they want me to
use.  The LD1 and LD2 values of them are opaque, and are defined by the
operator who defined them.  Critically, not by the one who sent it.



: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.
:>

:_______________________________________________
:Idr mailing list
:Idr@ietf.org
:https://www.ietf.org/mailman/listinfo/idr


-- 
Rules:
	(1)  The boss is always right.
	(2)  When the boss is wrong, refer to rule 1.