Subject: [GROW] Minutes from GROW @ IETF 104, Prague

From: Job Snijders <[email-masked]>
Date: Tue, 16 Apr 2019 14:25:16 +0200

Dear all,

Attached are the minutes for the GROW meeting at IETF 104 in Prague. I
am very grateful to Massimiliano and Nathalie for their time and
attention during the session!

Kind regards,

Job

----- Forwarded message from Massimiliano Stucchi <[email-masked]> -----

Date: Tue, 26 Mar 2019 17:42:54 +0100
From: Massimiliano Stucchi <[email-masked]>
To: Job Snijders <[email-masked]>, Nathalie Trenaman <[email-masked]>
Subject: Notes from Grow @IETF104

John Scudder:

Administrativa
 - assign jabber scribe (Nathalie Trenaman)
 - assign minute taker (Massimiliano Stucchi)
 Chairs
5 minutes

###################################################################
          * Discuss Current Drafts
            draft-ietf-grow-wkc-behavior WGLC done, move forward
            draft-ietf-grow-bmp-adj-rib-out
            draft-ietf-grow-bmp-local-rib
            draft-ietf-grow-rpki-as-cones
            draft-ietf-grow-bmp-registries-change WGLC?
            draft-scudder-grow-bmp-peer-up Call for Adoption?
            5 minutes
###################################################################

John Scudder invited everyone to read his draft and

###################################################################
draft-szarecki-grow-abstract-nh-scaleout-peering - Rafal Jan Szarecki
###################################################################

Rafal Jan Szarecki presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-grow-draft-szarecki-grow-abstract-nh-scaleout-peering-01

Job Snijders: Is applicatbility within a single administrtative domain ?
Rafal: From the AS perspective we can use it between ASns, but it's
rather one administrative scope.  It should work, but we are not sure.

Ignas Bogdonas: What you describe does not specify the protocol and it's
more about applicability.  What is to standardize here, then ?  Is this
the right format - the RFC - for this kind of info ?  What is the role
of the IETF here ?
Rafal: Is this a question to me ?
Ignas: A loud thought.  We have a similar issue with BGP Pick.  This
probably is in the same direction, and this is just a thought.
Rafal: Thank you.
Ron Bonica: I think informational is the correct category here.

There were no more questions nor comments.

###################################################################
draft-ietf-grow-bmp-local-rib / draft-ietf-grow-bmp-adj-rib-out - Paolo
Lucente
###################################################################

Paolo Lucente presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-grow-draft-ietf-grow-bmp-local-rib-draft-ietf-grow-bmp-adj-rib-out-00

Jeff Haas: When you say FIB do you mean FIB or active routes ?
Paolo: Both.
Jeff: There are use cases considering either one of those, so I think we
should clarify it.
Paolo: If something in the text is not clear, please speak up.
Jeff:  I will send you my notes.
Igor Gashinsky: I think this is overdue.
Paolo: I think at the beginning we were offering limited ways f
Igor: Usually the problems in collecting data is timestamps.  If you can
have one protocol exporting everything, it would be helpful especially
for correlation.  How can we help you move this forward ?
Paolo: We should talk later.
Jared Mauch: I'm also interested in everything discussed by Ivo.
Paolo:  I had another draft in 2014, called BGP Path Marking.  It was an
attempt at describing the problem of understanding which are the active
paths. That draft didn't get enough traction and support.  I also have
interest in what Jeff was saying earlier.
Job: There were no objections in moving the draft along from reviewers.
 John Scudder had some questions, though.  If people could have a look
at the draft, we could move it on.

There were no more questions nor comments.

###################################################################
draft-sa-grow-maxprefix - Job Snijders
###################################################################

Job Snijders presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-grow-bgp-maximum-prefix-limits-00

Jared Mauch: Yes, please.  I would be happy to help you with the draft,
and working with the vendors as part of the implementation keys. The
outbound issue has especially bitten us sometimes.
Job: Look forward to working with you.
Kaname Nishizuka: I support this draft.
John Scudder: Based on experience of RFC7606, I would ask you to
reconsider asking the vendor to be creative with the outbound policy.
Job: I suggest the session would be turned down.  And that's the only
thing I want to sufggest.
John: Please, reconsider this.  With inbound we can do it because it's
the most sensible thing.  With outbound there might be better choices.
Job: I look forward to discussing this.
Jared: I agree with John Scudder.
Job: I would prefer to destroy the session because it creates a fault in
the network and makes it visibile as issue.
Igor Gashinsky: I agree with Scudder and Mauch.  We need a set of
options for a vendor to do.  I understand for many networks it would be
best to just tear down the session.  For my network I would prefer not
to do it. Can we make sure that this limit is post-policy if we go ahead
with this ?
Job:  It is.
Igor:  It is not explicitly stated in the slides.
Job: The intention of the document is to make it unambiguous how the
mechanism works.
Igor: We need more options.
Ruediger Volk: What I think should go explicitly on the list is if the
implementation of the session termination on overflow inblund include
the info on what limit was hit.
Job:  You can include the number in the message notification
Ruediger:  You should.  The creativity that was described earlier can
lead down an unexpected path.,  I can imagine people doing weird stuff
or asking for particular stuff.
Thomas Graf: I would like to see in the capability exchange if there is
a prefix limitation.  This can also reused in BMP to have a vew on how
many routes would be expected.
Job:  There is a draft in IDR to communicate prefix limit to other
networks.  You can check that.
Jeff Haas:  This is a potential time to discuss the twitter of BGP that
we've discussed in the past.
Warren Kumari:  This sounds grand.  You should mention this on the IDR
list to make sure they're informed the change is going to happen.
Job: Good feedback.  We can talk about that.
Alvaro Retana:  If we're changing State machine, maybe it should be in IDR.
Job:  I will talk to them.

There were no more questions nor comments.

###################################################################
draft-xu-grow-bmp-route-policy-attr-trace - Yunan Guyunan
###################################################################

Yunan Guyunan presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-grow-xu-grow-bmp-route-policy-attr-trace-00

Jeff Haas: The good thing is that it is good for correlation of logs.
Unfortunately a discussion came up some sessions ago about adding this
to BMP.  The problem is about what you're trying to trace. We probably
don't want to get that giant list of output into BMP itself, though.
Here if you want to keep the interesting things, not in BMP, but we can
move the problem into telemetry.  Telemetry means you can tell your
routers about looking at specific prefixes.  Telemetry might be a better
solution.
Ynan:  Thank you for the suggestion.  I think it's an optional approach
to do that, but I can't really tell which one is better now.  I forgot
to mention, here the policy part, it is not a policy itself, it's just
an indicator.  For the policy you use GRPC to export.
Jeff: This is still useful and it has some use.  Certain providers that
I know, the chain of policy will give you less hints about why and where
something changed.
Ruediger:  There are different questions that come up in the problem
space you're addressing.  Depending on the questions, different tools
and logic are appropriate as solutions.  Tagging information into
regular BMP streams would match very easily and nicely oif you create
additional info for one pass in your egress or ingress policy.  Usually
something happens that will produce a BMP record, and tagging into that,
giving info you are interested in is nice.  Using BMP for doing single
stacking through one policy, which could be big and have plenty of
conditions does not look feasible.  It maybe interesting to ask vendors
to implement this.  I've been asking to try for my use case to scale
things down and give me the opportunity to tag on on the drop
primitives, an optional exit codes that tell me the reason for rejecting
customer routes.  At some point in time I want to create reports for the
customers to tell them what's wrong with what they're announcing.  This
can't go into BMP records.

Susan Hares: Sorry if I repeat my advice.  One of the things for the
actions that Ruediger described, you can use functionalities from
netconf.  I encourage you to look at those options.  We need more eyes
and reviews there.  If you think Yang models are better, please have a
look at them.  It's just another thought to choose between.
Yunan:  Thank you for the suggestion.  We should do a comparison of
different options.
Igor: You are trying to fix two different problems here.  What you are
trying to see and why.  What is simple, why is more complicated.  I
don't know how you would express some of our policies in these messages.
 I don't think you can encode most of this into the BMP messages.  I
don't see how useful it could be to put all this into BMP.  One use case
would be Ruediger's log message.
Ruediger:  We are not doing that much complexity.  If you get the chance
for marking the points with something that will be meaningful for you,
it may change some of your policy to emit the specific reason where now
it's all the same.  You want to know the reason for a drop, and you
might end up with a split.
Igor: An example of policy:  We have a chain that strips communities,
blocks route, sets local pref.  Block that route is divided into areas
about bogons, and others.  Block bad might stop because of some issues.
 Do you want logs to specifically tell you this data and where the issue
was ?  Some people need that, some others don't.  I'm not sure this
belongs to BMP.
Yunan:  I'll explain how the policy works for us.  We don't use
recursion under route policy.
Job:  This is very interesting.  My concern is that it might be
challenging to correlate the BMP messages with the policy that existed
at the time on the routers.
Yunan:  Can you explain slower.
Job:  When you send the BMP message to the collector, it might be hard
to correlate what the policy was.  If I update the policy every few
seconds, I can't know what version of the policy was at the moment the
BMP message happened.  I don't have a solution for this. I however
encourage you to contibue working on this.

Thomas Graf: I also think it's important.  With adj-rib-in and
adj-rib-out we know exactly what we have and where, and with this we
know which policy at which time. I think the yang policy configuration
should not be part of BMP.
Yunan:  We will do that. Thank you.

There were no more questions nor comments.

###################################################################
draft-chen-grow-enhanced-as-loop-detection - Yunan Guyunan
###################################################################

Yunan Guyunan presented:
https://datatracker.ietf.org/meeting/104/materials/slides-104-grow-chen-grow-enhanced-as-loop-detection-00

Ruediger Volk:  I saw the emails on the list about it, but didn't read
them.  I wonder wether you are aware of the ASPA being developed in sidrops.
Yunan:  I don't know the details.
Ruediger: It's for doing AS-path filtering,  Have a look there, as it
might be a good source for feeding into the policies you want to run.
ASPA is a very solid concept and the information base you could get from
it could be trustworthy and certainly should not be ignored.
Job Snijders: Very interesting.  If we know it's not an as-poath coming
from a route leak, then what ?  Normally I would not accept such a route
anyway.
Yunan: Very good suggestion.  I think I might check policy records to
see what happens.
Job: This could empower networks to figure out they're being victimised.
John Scudder: Do I correctly understand that youre identifying path
poisoning attacks ?
Christopher:  That's one thing she showed.
John: It seems like a lot of this could be addressed today by looking in
the routing table to see all the looped paths that were not selected.
In an ideal world you should be able to take it and analyse it offline.
 I don't thhnik it would be needed to change the protocol for this.
Yunan: We are not changing any protocol.  I agree there have been work
done on this.
Jeff Haas: Our implementation shows what route are installable.  Being
able to identify what kind of loops you see is a useful thing.
Christopher: I think I agree with Job's comments. Also with Jeff's
comments.  But I haven't seen much of this in th edraft.
Yunan:  The goal is to understand what's going on.
Alexander Asimov:  It's a good thing to have internal paths you're
receiving with your own as.  The problem though are IXes, which are not
visible in your path and there's no way to retrieve them.
Yunan: We can discuss it offline.

There were no more questions nor comments.

###################################################################
AOB
###################################################################

No AOB reported.

----- End forwarded message -----

---

From: tom petch <[email-masked]>
Date: Fri, 19 Apr 2019 08:25:43 +0000

--- Original Message -----
From: "Job Snijders" <[email-masked]>
Sent: Tuesday, April 16, 2019 1:25 PM

> From: Massimiliano Stucchi [email-masked]
>
> John Scudder:
>
> Administrativa

what happened next?  The suspense is killing me:-)

Tom Petch

<snip>

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 19 Apr 2019 11:02:39 -0400

(I uploaded these to the meeting-material-site)

> what happened next?  The suspense is killing me:-)

there was a great party, you missed it ;( we were sad you missed it,
come  next time with your party hat?