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:29 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 98273129531 for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 09:29:53 -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 GAB9DmnExnQb for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 09:29:51 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 326E0129413 for <idr@ietf.org>; Fri, 21 Oct 2016 09:29:50 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id c78so25865wme.0 for <idr@ietf.org>; Fri, 21 Oct 2016 09:29:50 -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=Y/0YSwmN1SAApcC791FRtNEr8qkAGvj/05DHHF1kh58=; b=PB5hujPWdpU/MpPTaUZkydkiAxSIuwdoPdYLAu8e2DjrRtlQu5hxcCjNPFtBcRi/P5 zaKkWALoj7HzsDM/dshpVOzR4uZ5BXifEDfvGyKV2yI0ZWjXQ93vMoJoWgZS3bkLrbHw imzbRP36zmZ/bkf8HUt1pDU+Bu1G2gTz35g0dbof79dXxyMYjmjLvAwVzRolFBvtoQao jNIGsAGdoFtz/Z5lTF/P8rNShYMtOaafCaic6mmvyFxC+K4xSSe6PnzUqHmP65o4LTGL m8S7wTeORvlPtDsQ/Z3IuDsOHiiLQsVpwL5lz+iJLmyf72CX4DC3d4mSLyvYyufGMWkg g8VA==
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=Y/0YSwmN1SAApcC791FRtNEr8qkAGvj/05DHHF1kh58=; b=CCqDwtVYg4jyfw+gQAG3Wo/5mLEz+U12BDG3haWbqg5c8eH847qHS0u4h88KBz4l5B Dd4yJCFhz4tCU/AmB9Xrv1VtW43ilYzV0neO+6P1yJtkE2n4lKbmoKS6GyoOo9Wl2258 3FO/zufjbQ8xy0Z+f2yns4KwoAqgEzVR7pOH4FvZsir21VdZN5Ty/xx+eRPI9Qrw5iPz ZlsqHwq4GQUrP5jIBut6dI8kokmjVJLokmpx4DSxdYC633Ph10fJ5MVyGC+mBVOHwdtF 2xVU4Az6bzg+n+yMSWzyg5FktkBZLl3uu88DuRnha7YnHGSZdzeRbhbhwKvPzefhSDjQ uJSQ==
X-Gm-Message-State: AA6/9RlM3cGeEqBSaSvtWPgfL33dkSqJlaLQcULMrl+8qxRFEcBU+faU9c/IcDxG4TelripcXZ6/tGwxtvLobg==
X-Received: by 10.28.163.196 with SMTP id m187mr10464015wme.73.1477067388697; Fri, 21 Oct 2016 09:29:48 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.182.155 with HTTP; Fri, 21 Oct 2016 09:29:46 -0700 (PDT)
In-Reply-To: <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net>
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> <CA+b+ERmrzCtFLP98D0YzRc-BJNbBWp3Ce6yKZr2cg1_QS0Oz5w@mail.gmail.com> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 21 Oct 2016 18:29:46 +0200
X-Google-Sender-Auth: H5-94HhHuErYKcdHOA38fho3lqU
Message-ID: <CA+b+ERn6dG+R8+UV-jaRXAV7eWQBygqEQp4VY4x1yKukpVKhTA@mail.gmail.com>
To: "i3D.net - Martijn Schmidt" <martijnschmidt@i3d.net>
Content-Type: multipart/related; boundary="001a114cd9a203b390053f628d1c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/C7L1xgajMuioiFZv520sduHS9vQ>
Cc: IETF IDR WG <idr@ietf.org>, Peter Hessler <phessler@theapt.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:29:53 -0000

Martijn,

> I think you're missing the point.

I don't think it's me :)

> Peter already explained that not every ASN we're trying to signal is
necessarily a direct neighbor.

I never made any such assumption.

> So you've suggested to take a look at the BGP table instead to see if the
ASN appears in any AS_PATH which is in the table.


Nope ... not at all.

The policy example was nothing to do with BGP table. If I am receiving
BGP_UPDATE it comes with AS_PATH and may contain LC. So if I want very
simple policy to filter trash of LCs I can set it to match first 4 octets
to any ASN present in the same UPDATE MSG AS_PATH attribute. If it there I
do not drop LC.

For stub ASes we could treat their AS_NUMBERS in LCs exactly in the same
way we treat them in AS_PATH today.

Cheers,
R.





On Fri, Oct 21, 2016 at 6:21 PM, i3D.net - Martijn Schmidt <
martijnschmidt@i3d.net> wrote:

> Hi Robert,
>
> I think you're missing the point. Peter already explained that not every
> ASN we're trying to signal is necessarily a direct neighbor. So you've
> suggested to take a look at the BGP table instead to see if the ASN appears
> in any AS_PATH which is in the table. But many routers participating in the
> DFZ don't carry a full table, only a default route, so that information is
> not available to them. Nevertheless operators of those default-only
> networks frequently send communities to their upstream for inbound routing
> manipulation (prepends, localpref, RTBH, etc) to achieve a variety of
> goals; your suggestion would severely limit the draft's usefulness.
>
> Summarizing, any restrictions which can not be enforced don't belong in
> the IDR document because they're irrelevant to implementors. Arguing about
> it doesn't change the fact that such recommendations belong in a BCP/GROW
> document. It is that simple.
>
> Best regards,
> Martijn
>
>
> On 10/21/2016 06:03 PM, 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
>
> 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 listIdr@ietf.orghttps://www.ietf.org/mailman/listinfo/idr
>
>
> --
> Met vriendelijke groet / Kindest regards,
> Martijn Schmidt
>
>
> [image: i3D.net performance hosting]
> *Martijn Schmidt | Network Architect*
> Email: martijnschmidt@i3d.net <//martijnschmidt@i3d.net> | Tel: +31 10
> 8900070
>
> *i3D.net B.V. | Global Backbone AS49544*
> Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands
> VAT: NL 8202.63.886.B01
>
> Website
> <http://www.i3d.net/?utm_source=emailsignature&utm_medium=email&utm_campaign=home>
> | Case Studies
> <http://www.i3d.net/partners/?utm_source=emailsignature&utm_medium=email&utm_campaign=case-studies>
> | LinkedIn <https://www.linkedin.com/company/i3d-net>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>