Minutes IETF117: grow: Tue 22:00
minutes-117-grow-202307252200-00

Grow 7/25 - 15:00-16:00

1) Opening (note well/etc) - 1 min
Note-Well read and indicated.

2) Administrivia - 5 min
[Discussion]:
Job: BGP well-known community in a WG
Authors: want to go to WG LC
Concern about what to do with the community.

review the yang.

issues.

4) Draft Status - 10 min
[Discussion]:
Job: Any status updates?
[room]: no comments.

5) Paulo Lucente - draft-ietf-grow-bmp-tlv - 15 min
[Discussion][1]: I would like feedback from WG and the chairs on whether
we should bump to version 4.
Job: Since there is no difference between
current version and version 4.
Jeff: I would like to version change
when:
a) change of rules,
b) causing a procedural change to the rules.

One of the success criteria, review the
entire BMP specifications. Did I have
the features so that we can

version number?

bumping the protocol version in the tet.

This is fundamental change so a version bump
is good.

for change versions is clearly specified in
the text. (chairs should review this line)

the version point based on the format changes.
It seems that people are in favor in
bumping the version.

in the previous versions?

The messages types will be clearly specified by version.

WG adoption for draft-francois-grow-bmp-loc-peer-01 (Chairs should check
this name.)

6) Jeff Haas - draft-haas-idr-bgp-attribute-escape - 10 min
Jeff Haas:
Job: Related to this topic,
I was talking to european providers.
We have a history of communities
(communities, extended communities,
large communities) which leads to
unwieldy policy.

We would like to get rid of extended
communities. We noticed that deployments
have moved to large communities.
We are thinking of creating a best
practices.

about BGP error handling being
on by default to have specific filtering
[? of communities].

My company does not want to change defaults.
Do you support 7606 if you support by
default or configuration?

localized route exchange.
Therefore, contracts should specify
the limits of the route server

discussion. In its current form,
it does not have actual BGP protocol.
It is really an operational guide.

are advice to protocol changes.
It depends on the future of the
draft

of attributes is a bit overloaded.
The useful solution is to partition
the attribute into spaces that
can be passed freely or

attribute space requires
registry and (?) protocol changes.

[xxxx], I am the very conservative
portion of the community.
Having something that hits the
protocol issue should be check for
security (bad actor (KGB) or an error).
It is important to detect something change.

your protocol to prevent the KGB.
Second point, if your code is going through
RFC7606 - is your attribute of doom:
a) getting tossed or kept,
b) sending errors.

This issue is about bgp policy

1) attribute space split - may not work
due difference in networks.
2) You did not provide a solution.
to this problem.
3) Yang model extensions is that
tracks attributes that were leaked
that should not be. History

not limit the problems.
Telemetry issue is helped by Yang module.
No solutions: I provided 3 solutions to these
problems. Additional solutions can be added.

8) Pierre Francios - draft-francois-grow-bmp-loc-peer - 15 min
question: Shall I cancel the idea of
RFC9069 Peer Address field.
[person]: What you want to add to the whole
rib, the collector may or may not have enough
information about the peer. A TLV might be nice
[person2]: It would be nice to have it there.
It might be not good for BMP. It might be
good for just BMP v4, and BMPv3.
You can add TLVs.

one. We should choose for the version 4.
Do not overloading messages, but fixing it
would be nice.

You have a difficult task. How do the
different implementations handle the VRF.

Jeff Haas One way to view the
leakage for
this BMP is to examine traceability through the
tables. You should work through this before
you design this feature.

Having this information makes it easier to debug
when things go wrong.

a
Jeff: We had fields that were overload
in version 3. In future versions, ask
yourself what helps the traceabiity of the errors.
What Gargi indicated is correct.

You are asking about traceability for any
BGP peer session to any other session (or table).
You will get into RIB-IN, RIB-OUT, or
Active route.

information about intended flow of routes
and actual flow of routes.

none? Please give a comment.

10) Maxence Younsi - Implementation Report bmp extensions - 15 min

FRRouting - support Basic BMP (all RFCs)
status: (see slides)

11) Done?
[This concludes the grow meeting at IETF-117]

Scribe: Susan Hares (send changes to Grow chairs)

[1]: (?) missed