Minutes IETF103: grow
minutes-103-grow-00

############################
* 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 weay 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 LC 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.