[GROW] Meeting notes GROW session @ IETF 103

Job Snijders <job@ntt.net> Fri, 09 November 2018 13:58 UTC

Return-Path: <job@instituut.net>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89ECB130DFF for <grow@ietfa.amsl.com>; Fri, 9 Nov 2018 05:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.65
X-Spam-Level:
X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, TO_NO_BRKTS_PCNT=1, UNPARSEABLE_RELAY=0.001] autolearn=no 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 osVIYRt9a_5h for <grow@ietfa.amsl.com>; Fri, 9 Nov 2018 05:58:22 -0800 (PST)
Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (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 5307D1277C8 for <grow@ietf.org>; Fri, 9 Nov 2018 05:58:22 -0800 (PST)
Received: by mail-wr1-f45.google.com with SMTP id b13so1974119wrx.6 for <grow@ietf.org>; Fri, 09 Nov 2018 05:58:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=uZeQR7D0yXQf6Q/zt/37fQldjJqz251q3tO5m5RLOx0=; b=KM+wR/PX+ihIqxvC1hHgcRjHjhNLfyBVTbjPP8Ob2LWz3rzQsqyyRRuaHlWfdQJIKQ OkAgfyvV5Yek3/ChIn7Sa93j+MdMCtKZHnXFKLXd9BSu/QH9SXggkFTX1IU8bSaT+hFL WQlUL2AxbBLLGfBefU4h41RhuksyfOyZrWG4im6hpP2tspoQ4OT/Vh+neac2PD0DhBov fz2uBp8LcrsbGC4ReOzjw/oiyycb3Tpoc2v6Ig9xzPKDadYfmcvq/MMnJ2khGJsdkiz6 dqYHlPqE8dZEtJKcFX5VcxapzE+Gzx01e6xxIhTSEaBba3FYNwJSFDlUiap9kgVll1/S IeNg==
X-Gm-Message-State: AGRZ1gJCVB7fv29ow3MwdLnX/Lq01tTpR+UCwF9K09+m9sLJx92Yv3ur EvkrU/bSD37cSJuk0EhDzsjxOKFfbbl80A==
X-Google-Smtp-Source: AJdET5eAwkdPXGeIl3vhEYD8SxTLRXscLvg/Hew/ivWo2C21Mv0iOeZ7SXHRPQuceMy14Rz4/OlRUA==
X-Received: by 2002:adf:ce0f:: with SMTP id p15-v6mr8707012wrn.324.1541771900092; Fri, 09 Nov 2018 05:58:20 -0800 (PST)
Received: from vurt.meerval.net ([192.167.174.91]) by smtp.gmail.com with ESMTPSA id s206-v6sm1104231wms.29.2018.11.09.05.58.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 09 Nov 2018 05:58:19 -0800 (PST)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 021cf90f; Fri, 9 Nov 2018 13:58:08 +0000 (UTC)
Date: Fri, 09 Nov 2018 13:58:07 +0000
From: Job Snijders <job@ntt.net>
To: grow@ietf.org
Message-ID: <20181109135807.GC18842@vurt.meerval.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/mU09gFZxZFI_CdrPhT0kz9dXlso>
Subject: [GROW] Meeting notes GROW session @ IETF 103
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Nov 2018 13:58:24 -0000

Dear all,

Massimiliano Stucchi from RIPE NCC was kind enough to make notes during
the GROW session at IETF 103. Many thanks!

Original minutes here https://etherpad.tools.ietf.org/p/notes-ietf-103-grow?useMonospaceFont=true

-----------------------------------------------------------------------

############################
* Discuss Current Draughts
draft-ietf-grow-bmp-adj-rib-out
draft-ietf-grow-bmp-local-rib
draft-ietf-grow-rpki-as-cones
draft-ietf-grow-wkc-behavior
draft-scudder-grow-bmp-registries-change
#########################################

Randy Bush: I suggest to the people working on AS-Cones to talk to
someone who knows security to have some guidance.

There were no more questions nor comments

#########################################################
* Solution for Route Leaks Using BGP Communities - sriram
#########################################################

Sriram 

Ruediger Volk: This looks easy. Large communities can do it. Other
    things are complicated and we don't like it. For Large communities
    to make sure the propagation works the right way, we will need
    documentation giving advice on how to handle this in the local
    policy configurations. Without this advice, you are not getting an
    idea on how it's going to be handled. With Large commiunities
    available for things like this, I think providing some advice on how
    to handle it in policies is good. Consider also what Randy Bush is
    going to discuss later. It's a matter of time that 100% of the
    networks will be able to deal with them. Everything done to add
    features to large communities will take more time.

Jacob: Someone will have to configure large communities for them to
    work. If you're relying on standard software to pass on large
    communities, things might be tricky.

Sriram: We are hoping that the leaking ASn would let large communities
    pass.

Job: There's still no way for IANA to register well known large
    communities numbers. We will need a document for that.

Ruediger Volk: The IDR chairs can request the global administrator AS.
    That will go into the registry then. My take is that working more
    with LC we will need it more and more.

Job: Thank you.

Sriram: Thank you. Please send feedback on the list.

There were no more questions nor comments.

###################################
* Communities Are EveryWear - Randy
###################################

Randi Bush presented the slides.

Jared Mauch: I'm curious about Large Communities seeming to propagate
    much further than normal communities. Did you study it ?
Randy: No
Jared: Iss there any recommendation in the document about it ?
Randy: No

Chris: Are you asking Randy to write a document with recommendations ?
Jared: Shall we align the behaviour with normal , extended large
    communities? do we want to make recommendations on how to strip
    communities? Juniper has the ability to do so, arbitrarily matching
    routes with a value in the TLV. Maybe we should give guidance to
    operators on what options to have.
Randy: Good idea.
Ruediger: I think some documentation about good practice on what BGP
    information is adequate would be a good thing. My view would be that
    there might be agreement on what to exchange between operators, but it's
    someone's responsibility (mic was cut.)

Time was out. No more questions nor comments allowed.

############################################################
* Draft-ietf-grow-bmp-(local|adj)-rib(?:out) - Paolo Lucente
############################################################

Paolo Lucente presented the slides.

Humming for last call was considered successful.

(I missed the person who talked at this point and what he said. My
etherpad session disconnected.)

There were no more questions nor comments.

###################################################
* draft-gu-grow-bmp-route-leak-detection - Yunan Gu
###################################################

Yunan Gu Presented the slides.

Jared Mauch: We are using BMP to validate our routing policy decisions
    and validate when we're leaking routes where it's not intended.
    You're trying to catch what Qrator labs have suggested to look at.
    There are cases where we route space internally, but we don't want
    it to leak outside. A document like this is incredibly valuable for
    us.

YUnan: Thanks

Alexander Azimov: What are you getting in advance in terms of BGP leak
    prevention? You can detect but not prevent leaks with this method.
Yunan: Correct.
Alexander: You could have policy configured in your router. With this
    document, you have to configure all your peering in your system.
    This does not simplify the work of preventing route leask.
Yunan: Correct.

There were no more questions nor comments.

########################
* Living Documents - Job
########################

(can't figure out the name): This is a good idea. I was asked to look at
the IGPs, and we were 

    Can you start the ball rolling on this ? It would be immensely
    helpful. People could draw and add content. Valid security issues
    could be presented there.

Alvaro Retana: I think this is a great idea. I wish more people would
    look at living documents because they are more useful. What more
    than a draft do you need ? A draft could be considered as the way of
    achieving this. 

Job: If you look at the optics of a draft, they're different from an
    RFC. The logistics of a draft are different. The URLs change, but we
    want something stable. We want something slightly different.

(Didn't get the name): I would be in favour of having something
    long-lived as a standard.

Tim Bruijnzeels: I worked on documents explaining how the RIPE NCC
    Validator and implementation works. I'd like to see this.

Jeff Tentsura: I would like to be able to normatively reference this
    document. It wouldn't work if we keep it as a draft. 

Joel Jaeggli: I think We don't have a way to discuss about consensus for
    a document with. It seems the only requirement we have here is to have
    metadata to reference the document.

Warren Kumari: I've heard people wanting something that's an RFC but
    that is not an RFC. Something in-between. You could do it as a WG
    document, calling last-call every now and then, but that would be
    strange.

Ruediger Volk: It seems to me that considering consensus every now and
    then could be a broken idea. Having a precise versioning of official
    points could and should be done. I have the concern that there are
    things that are fundamental and never change, while there are things
    that are currently discussed and are moving. I think going for a
    living document will tend to expose what is being discuss, while the
    fundamental stable long-term things will not be presented the right
    way for newcomers, which should be focusing on them first.

Job: Thank you for your feedback. We are attacking two problems at the
    same time: exploring live documents as a concept, and routing
    security explained to newcomers. Let's face these one at a time. We
    will meet tomorrow and then report to the list. We should start with
    a document soon.

Jeff Tentsura: We started an effort a year ago to be able to reference
    non-IETF documents in IETF drafts. This could be interesting for
    this live document.

Job: Please, email me the link.

The session ended.