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

Robert Raszuk <robert@raszuk.net> Sat, 22 October 2016 16:07 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 B46DB129567 for <idr@ietfa.amsl.com>; Sat, 22 Oct 2016 09:07:55 -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 sETE5Ye55gtA for <idr@ietfa.amsl.com>; Sat, 22 Oct 2016 09:07:53 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 37C2712945D for <idr@ietf.org>; Sat, 22 Oct 2016 09:07:53 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id b80so34329700wme.1 for <idr@ietf.org>; Sat, 22 Oct 2016 09:07:53 -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=QuNHIdLkZu5bQC5NtbPz3vUaS4bxSQC8UnN+zfeW5aE=; b=o7YTxAX3wzaYsConT/2/knKB9PaEhIRA7j6yHryI9sGPh6HSbJdWgO8kJwZQkEbrOh cnDFnXD+TzdhK+dPDEGflLpONMlFcMUNHI0JtfMU2QPgOy/gBmXES38q+be3yZeAIdOh 1icS41dl9J4H+++kNlfjkKLlz/0ZdQcm0PL7mUFjcTlUBgh3w7081x/B3X3r4F3WhCWg Q5rqmEWgz4oU8Dnmv66g1odgQyL+4alB1Km2DjCBrDZSUc2YEA34FrKbNaC1RrAhvIv5 FLnsJ58wezma9ODi8JZr3gF/Z16vlKJ0T2Cj7eUT39m72WVIuzCp+obEiun4i/mOWDy+ BnXA==
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=QuNHIdLkZu5bQC5NtbPz3vUaS4bxSQC8UnN+zfeW5aE=; b=SbzgBTSSfmWAPTpDA/c9++/igJzdLgTvk8RD2rfgHLWiMB3PV9mfEIC4Nh4+iC7ds0 rzJOPkW0qy7hW8RlC0mg7E7bNpsB0O4/gRHVVqv+E8HLHnI3ZK4jGLX3NkGFzCW4S4ad tPHfZqg7xlSKHiiGzJM70cC/Q2ph0dQUE2PB9Q76yRqkhOdQBYtyQNKsbD5XkDbWlgEi uIRGUioZYo/kO0dAQg6g+ZiaJ0h39a0yklt4v7CSZRbxOAl4SYamh3wwkePUuRvXoT61 ggie62+5tznUvEg1OvkXewSbNHXNlB51schmUseVFdTuFfjF5At9eEg+8Xo5MVBhvTu4 S5YQ==
X-Gm-Message-State: AA6/9RnfmSstg9T/A5J/RZDRpLITm38Xx98Jv8cYnccNZ41R6ogqWaU0lMIge9HAd/MjZthTnpv+NIAwp1l/5A==
X-Received: by 10.28.167.148 with SMTP id q142mr15197222wme.17.1477152471628; Sat, 22 Oct 2016 09:07:51 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.182.155 with HTTP; Sat, 22 Oct 2016 09:07:48 -0700 (PDT)
In-Reply-To: <D6D63A9E-3AF2-40F7-B3FB-923BEC0EBB8F@juniper.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> <20161022122735.GC79185@Space.Net> <CA+b+ERkEMuV7yNKMG-EBUruMEC2E1zSd-ouAaGYaeuMwzpv2SQ@mail.gmail.com> <D6D63A9E-3AF2-40F7-B3FB-923BEC0EBB8F@juniper.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 22 Oct 2016 18:07:48 +0200
X-Google-Sender-Auth: NoNpPltM7fvYjt32fX-ojpV-YEA
Message-ID: <CA+b+ERmgPcGj4=yuCtdtbY9n657B1at5T8JBnEOF7137e+1nqw@mail.gmail.com>
To: John Scudder <jgs@juniper.net>, Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary=001a114ba91e59c0d5053f765c29
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/cnJ-7lROaa_55z40jCqDI8WxCQk>
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: Sat, 22 Oct 2016 16:07:55 -0000

Hi John,

Thank you for your message.

As I have indicated in one of the resent emails I also was under complete
impression that Large Communites are to be completely unstructured with
full freedom given to those who are to use them. And that is regardless if
I would agree with that or not.

However recently there was number of emails exchanged (excluding any of my
own messages) enforcing use of ASN within one of the fields of LCs (without
even defining which field would that be or what that ASN is meant to
indicate). Moreover authors of LC took number of actions to accomodate such
requests in the text of the draft.

That was the reason why within last few days I brought back suggestion to
specify meaning of first 4 octets to indicate the src asn. In addition I
also replied to claims that technically it is impossible to make sure that
LC is send with valid src ASN.

And while GROW may define BCP of any sort unless the protocol spec mandates
so no implementation will support it nor policy can be delivered which
automates such validation/filtering.

RFC1997 was defined 20 years ago and via those two decades internet has
changed significantly. In my opinion today BGP protocol should not allow
anonymous injection of free style messages into BGP UPDATE MSG without
having built in mechanism to determine who is the original author of it nor
without having structured fields to simplify creation and maintenance of
eBGP policies.

So for the reasons stated above (as well as those discussed before) I do
not support progressing this draft to RFC in the current form.

(And I completely realize that my opinion is just for the record here and
folks used to RFC1997 style of communities will push it through as well as
vendors who like to have customers will support it :).

Best regards,
Robert.



On Sat, Oct 22, 2016 at 4:11 PM, John Scudder <jgs@juniper.net>; wrote:

> Robert,
>
> "Yes RFC1997 works like that but here we have opportunity to improve it."
>
> When the working group accepted the draft as a work item, I think it was
> pretty clear from the extensive conversation at that time, that the intent
> was to replicate RFC 1997, not to improve it. In fact, improving it was an
> explicit nongoal if I remember right. One might argue that was a bad goal
> have, and I think you did make that argument at the time, but the working
> group consensus was otherwise.
>
> Of course, consensus can shift over time, and WGLC is a good time to test
> whether such a shift has occurred, so I don't think it's inappropriate for
> you to have raised the question again. However, at this point it appears to
> me that consensus has not changed.
>
> If you feel further conversation would be productive, I don't mean to
> foreclose on that, but I thought it might be helpful to provide an update
> about where it appears to me the consensus is trending at present.
>
> --John
>
> On Oct 22, 2016, at 9:53 AM, Robert Raszuk <robert@raszuk.net>; wrote:
>
> You are mixing SRC_ASN with TARGET_ASN in the same field.
>
> Yes RFC1997 works like that but here we have opportunity to improve it.
>
> Thx
> R.
>
> On Oct 22, 2016 2:27 PM, "Gert Doering" <gert@space.net>; wrote:
>
>> Hi,
>>
>> On Fri, Oct 21, 2016 at 05:42:37PM +0200, Robert Raszuk wrote:
>> > > 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.
>>
>> But that is only half the intended usage of communities - one is
>> "I tag it with <myas>:<some meaning>" to signal something to my own
>> routers or my customers.
>>
>> The other one is "I tag it with <jobs as>:<some meaning>", and there is
>> no way for my router to validate that "<jobs as>" is indeed the one
>> who defined "<some meaning>".
>>
>> So, how exactly is the vendor to check variant B?
>>
>> (And if you do not understand what people use communities for, today,
>> maybe you should not be argueing these points, sorry)
>>
>> > So there is very easy way to enforce it today in any BGP implementation.
>>
>> No.
>>
>> Gert Doering
>>         -- NetMaster
>> --
>> have you enabled IPv6 on something today...?
>>
>> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
>> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A.
>> Grundner-Culemann
>> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
>> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
>>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>