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

"i3D.net - Martijn Schmidt" <martijnschmidt@i3d.net> Fri, 21 October 2016 19:30 UTC

Return-Path: <martijnschmidt@i3d.net>
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 12B12129584 for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 12:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 x8YCyLym7t7k for <idr@ietfa.amsl.com>; Fri, 21 Oct 2016 12:30:11 -0700 (PDT)
Received: from mail.i3d.net (mail.i3d.nl [213.163.77.240]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38EFA12946B for <idr@ietf.org>; Fri, 21 Oct 2016 12:30:10 -0700 (PDT)
X-Footer: aTNkLm5s
Received: from localhost ([127.0.0.1]) by mail.i3d.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)); Fri, 21 Oct 2016 21:30:06 +0200
To: Robert Raszuk <robert@raszuk.net>
References: <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> <CA+b+ERn6dG+R8+UV-jaRXAV7eWQBygqEQp4VY4x1yKukpVKhTA@mail.gmail.com> <20161021164241.GC32387@Vurt.local> <CA+b+ERkAJDFPwmiNr7_UiaKfRQnt=8h9d9JM6B4oFgU_P1S1cQ@mail.gmail.com> <711ba725-7304-5122-cfb2-2a40c2d76ca9@i3d.net> <CA+b+ERmrEtSYTc2PN8fu3VogbMPK7yQR_GM3yJwuFF-zeO0u0Q@mail.gmail.com>
From: "i3D.net - Martijn Schmidt" <martijnschmidt@i3d.net>
Message-ID: <c3fc9f46-fb66-76a0-0efd-9669207729b9@i3d.net>
Date: Fri, 21 Oct 2016 21:29:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CA+b+ERmrEtSYTc2PN8fu3VogbMPK7yQR_GM3yJwuFF-zeO0u0Q@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------617B844939519B362E69EAA9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/NjnccdC4GkuaPS7KE_EoKIiKRV8>
Cc: 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 19:30:14 -0000

Hi Robert,

I haven't been "sold" on anything, I'm perfectly aware of the collision
issues I encountered while implementing RFC1997-based communities in our
real-world network and the protocol outlined in this draft alleviates them.

Of course stub networks can't *receive* LC's, but they can still
*transmit* them on the prefixes which they announce to the DFZ via
non-stub networks. The private AS which I mentioned in my previous
message was just an example so I wouldn't have to name a random
real-world network, but please feel free to replace every mention of
AS65500 with AS3333 if that makes it easier to understand the argument.
The same principle applies.

What operators want from their vendors are three completely opaque
4-octet fields, which is exactly what this draft specifies. Please let
operators worry about their own filtering policies (or lack thereof) and
leave such recommendations to the BCP/GROW document.

Best regards,
Martijn

On 10/21/2016 08:55 PM, Robert Raszuk wrote:
> Martijn,
>
> First I think you need to know that all original authors of LC agreed
> that the proposal does not solve the community values overload issue.
> If you and others were sold on something different then perhaps there
> is some disconnect. That is also why some time back I proposed for LCs
> to have 4x4octets such that today's necessity to overload 1997 can be
> relaxed. 
>
> For stub networks if they get only default route there is no issue as
> they will not be getting any LCs. 
>
> For ASes which use private_ASes as I already mentioned it is trivial
> to treat it in the same way as it is treated in the AS_PATH today.
> Basically you would replace your customer private AS with your public
> AS both in the AS_PATH and in the first 4 octets of LC.
>
> To conclude ...
>
> There is simply two ways 
>
> -A- your 3x4 octets are completely unstructured and you use them as it
> seems fit 
>
> or 
>
> -B- It is structured and draft/rfc specifies what goes into first 4
> octets (say SRC_ASN) and what goes into second 4 octets (say
> TARGET-ASN) leaving rest for ACTION+PARAMETERS
>
> Rgs,
> r. 
>
>
> On Fri, Oct 21, 2016 at 8:01 PM, i3D.net - Martijn Schmidt
> <martijnschmidt@i3d.net <mailto:martijnschmidt@i3d.net>> wrote:
>
>     Hi Robert,
>
>     Briefly continuing the earlier discussion for originating routers
>     - stub networks which exclusively receive a default route from my
>     full table router don't have complete AS_PATH information. That
>     means the device won't be able to determine whether or not the
>     configured GA field corresponds to an ASN in the DFZ.
>
>     If we decide (on a protocol level) to filter the LC information on
>     the receiving LC-speaking BGP router instead of the originating
>     router you'd limit the transitivity and therefore the usefulness
>     of the Large Community feature. Let's say that AS65500 wants to
>     send a community via AS49544 to AS2914. Upon receipt of the
>     BGP_UPDATE, the AS49544 router will check the Large Community
>     attribute and notice that 2914:x:y is attached while AS2914 is not
>     in the AS_PATH. It would then have to strip the Large Community
>     and AS2914 would never receive the Large Community attribute.
>
>     Simply stating that "implementations MUST allow the operator to
>     specify any value for the Global Administrator field" is the
>     correct way forward, the suggested SHOULD wording either can't be
>     enforced by vendor-side checks (and therefore belongs in a
>     BCP/GROW document), or is - in the way you've suggested it - in
>     direct conflict with the intended use of the Global Administrator
>     field.
>
>     Best regards,
>     Martijn
>
>     On 10/21/2016 06:49 PM, Robert Raszuk wrote:
>
>>     Hey Job,
>>
>>     That's what I thought ... but if so I do not get why there are so
>>     many discussions of any MUSTs/SHOULDs/MAYs operators are expected
>>     to follow on in the fields LCs provides. 
>>
>>     If they are opaque that means there is zero structure in place
>>     and everyone is free to put whatever he/she likes in it .. even
>>     hex encoded Morse (https://goo.gl/rHcGeV)
>>
>>     We either allow all opaque and free style or we structure fields
>>     such that for example they may be used in simple parametrized BGP
>>     in/out policy example I provided. 
>>
>>     And the excuses type "oh we can not structure it as there is no
>>     way to insert valid ASN" are wrong as there is a way as proven :)
>>
>>     Cheers,
>>     R.
>>
>>
>>
>>     On Fri, Oct 21, 2016 at 6:42 PM, Job Snijders <job@instituut.net
>>     <mailto:job@instituut.net>> wrote:
>>
>>         On Fri, Oct 21, 2016 at 06:29:46PM +0200, Robert Raszuk wrote:
>>         > 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.
>>
>>         A clever trick, but not a good fit for Large BGP Communities.
>>         Large BGP
>>         Communities are opaque, by definition and design.
>>
>>         We want routing policy in which networks can send 2914:X:Y to
>>         us, and we
>>         can send 2914:A:B to them - very much like RFC 1997
>>         communities. The
>>         Global Administator field does not necessarily contain the
>>         ASN of the
>>         sending party.
>>
>>         Kind regards,
>>
>>         Job
>>
>>         _______________________________________________
>>         Idr mailing list
>>         Idr@ietf.org <mailto:Idr@ietf.org>
>>         https://www.ietf.org/mailman/listinfo/idr
>>         <https://www.ietf.org/mailman/listinfo/idr>
>>
>>
>>
>>
>>     _______________________________________________
>>     Idr mailing list
>>     Idr@ietf.org <mailto:Idr@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/idr
>>     <https://www.ietf.org/mailman/listinfo/idr>
>     _______________________________________________ Idr mailing list
>     Idr@ietf.org <mailto:Idr@ietf.org>
>     https://www.ietf.org/mailman/listinfo/idr
>     <https://www.ietf.org/mailman/listinfo/idr> 
>