Minutes IETF97: grow
minutes-97-grow-00

Meeting starting.

1 - Admin data / Draft Status                        10 min

Note well applies.
Agenda bashing.
Job Snijders: Please add BGP reject to the agenda.

2 - Default propagation behaviour without policy. draft-ietf-grow-bgp-reject

Job presenting

[discussion]

Jakob Heitz: You mentioned IOS and we are well aware of the problem, we
designed IOs-XR that fixed that problem. We cannot change it as that will break
the existing configurations. Job: That can be configured as a global knob.
Jakob: We will not comply with it (IOS) unless you fix that sentence. Jared
Mauch: I am concerned by vendors not providing secure software for the
internet. Job: My personal motivation - at least going forward we have
something to document that this is an expected behavior. ?/Cisco: I have a
different perspective on the datacenter operators - this may be additional work
for them. Jeff Haas: BGP is used in many places. It is for operators to decide
on the packaging of the default parameters. We would comply with this document
if there was a knob to change the defaults. Job: How we ship this in products
and how we agree how this exists as a specification are two separate topics.
Jeff Haas: Any change in behavior will be […] Job: What about v4 and v6? Jeff:
Anything. What I am concerned is a blast radius. There are different scopes for
VPN and global routing families. Jen Linkova: We need to think about migration
here too. We should not break the internet by introducing it. Jon Mitchell: It
seems that the current draft as it is is fine if focused on IPv4 and IPv6.
Another point on the vendors - there are major changes going in in different
versions, and it is surprising for me to see that vendors would not do this.
Chris Morrow: Who in the room feel that this is ready for LC? Job: There was a
comment on deployability - we can work on that. Peter Lothberg: If you make a
change - it is better if it behaves the same for all address families. Doing it
separately would add confusion in. Consistency is good here, and it is up to
the vendors to do the different implementations. The install base problem -
IETF has just to listen and say that we are very sorry that you have customers.
Bringing in a box into a network should do nothing unless you explicitly tell
it to do so. Jen Linkova: Support the consistency. Jared Mauch: Support Peter
Lothberg’s comment - this is a well defined problem, this is a real problem,
and it worries me that if it is such a big problem for vendors to support it.
Job: Is anyone objecting for all address families? Jon Mitchell: I only object
if you have no differentiation between internal and external BGP. Job: Does
anyone object to include internal? Peter Schoenmaker: We need to confirm on the
list, this seems to be a small issue. Jeff Haas: It could be observed that the
real thing worked here is about the profiles for the software that is already
existing. Peter Schoenmaker: We need to discuss those outstanding issues on the
list.

2 - Large-Communities - job                          15 min

Large communities usage.

Job presenting.

[discussion]

Joel Jaeggli: As a consumer of these provider communities as someone who buys a
lot of transit - today we have a rosetta stone in our routing management system
we need to abstract away from the interpretation of different interpretations
of different providers. It would be good to move to something better than a
proprietary format of signaling. This seems like a huge improvement even if you
do not standardize the expression of the intent completely. This is a radical
improvement as a consumer. The audience for this signaling are not large
transit providers but people who buy transit, who are not necessary in this
room. This is an improvement for mid level organizations. Peter Schoenmaker:
Who thinks we should adopt this draft? We will take to the list. Peter
Lothberg: Does that mean that community functions will be IANA registration
thing? Job: No.

3 - Why doesn't IDR know about Ops Requirements?     10 min

Chris Morrow presenting.

[discussion]

Job: I have two comments about the communities when the transition was done
from 2 byte to 4 byte AS - I think an incomplete inventory was done at that
time. Another risk that I have seen - when a relatively simple idea from GROW
goes into IDR it suffers from the feature creep. Some proposals were completely
out of hands. Could GROW put brakes on things sometimes by saying that we need
this tool to be as it should be? Maybe we could agree that extensibility is
something that we not always need? Bill Fenner: Rather than not taking things
into account IDR was expecting that it will be subsumed by other work, and that
work took over 10 years to complete. It is not that we need to solve those
problems at once. Chris: To be fair - 4 byte as document says that there are
use cases that will be addressed by the wide communities draft but that draft
says nothing about this particular use case. Bin Fenner: The approach was to
stick that to flexible communities and expect that it will be solved. Joej
Jaeggli: I think it is second system problem here. Part of the reason that this
system still works is that people are not able to build new shit into it. We
need to look into what is the minimum necessary thing to go in. Any debate that
looks at the system as relatively flexible misses the point on how it is
deployed and how it can be changed. Randy Bush relying Jabber: This has been a
long standing problem - and a burden of us not doing it is a lot of crap. Keyur
Patel: AS4 was standardized long time ago, and when IDR progresses standards it
could look at what else will be needed. John Scudder/IDR cochair: in ideal
world when we did AS4 we would have done gap analysis and obviously this
deployment case would need to be fixed. In reality everyone is constrained and
optimistic approach took too long. My point is - we are using all of our
bandwidth for discussion on this in IDR. IDR gets used on internet routing and
also all other Swiss knife things, this room (GROW) is focused on internet
routing. You could have more focus here and could help us focus too. Sue
Hares/IDR cochair: If you see a situation where administrative wheel for IANA
needs to be turned don’t be shy and come see us chairs, send us mail and we
will discuss the process with you. Jeff Haas: Several points. One - RFC 4360
4octes AS numbers - that would not work for AS4 scenarios. The discussion on
AS4:AS4 did not happen until a couple of years ago. The limitations of extended
communities were known for a while. Interesting observation is that 4:4
discussions were coming in in private meetings, it did not come here in IETF.
The requirements to an extent overrode the solution. Chris: Take to the list.
Jared Mauch: One of lessons of this - I went to vendors as a proxy to reach IDR
group and that message did not go through the IDR group. It is not that
operators did not approach people - I remember approaching Jeff and saying this
is a problem and we need to fix this. We have tried for years to address this
directly via vendors but the message did not go through. Now it became a fire
drill. Peter Lothberg: This may be a typical Peter comment - i think it is time
to look at what we replace BGP with, instead of adding in all those small
things in. Maybe we need a new BGP for the future of the internet.

4 - opsec-urpf-improvements - sriram                 15 min

Sriram presenting.

[discussion]

Keyur Patel: What you are saying that instead of it being nice, you need origin
validation for this to work. Sriram: Yes. Barry Greene/Akamai: I am glad that
you are looking at this. We need to reevaluate the assumptions where URPF
strict mode fits, why do we use loose mode, why was VRF mode created, and why
flowspec was created, you also need to look at why jtree vs CEF was done.

Peter Schoenmaker: We are out of time.
Meeting concluded.