IETF-89 Routing Area Open Meeting
ADs: Stewart Bryant, Adrian Farrel, Alia Atlas

Scribe: Deborah Brungard 

Stewart opened. Reviewed slides. Reviewed "Note well", need to say at earliest convenience if any IPR associated
with contributions.

Be sure to say at mike your name. Blue sheets are now scanned and published.

Adrian thanked Stewart for his four years and introduced Alia. Alia will be stepping down from her Chair positions.
There will be a chair swap for I2RS (Jeff Haas) and RTGWG (Jeff Tantsura). Also since last time, Roll, JP stepped
down and Ines Robles steps in. Also since last time, SFC WG formally created.

Administriva and Area Status
For additional information, please refer to posted slides:
(the RTG Area Meeting slides contain updated set for Working Groups) 

BFD (Jeff) - Probably shortest Working Group of any IETF. RFC has been published on BFD over LAGs.
Three vendors implementing,interop completed. Soon expect MIB to be published. In the wings, is seamless BFD.
With that, we'll see if rechartering is appropriate.

CCAMP (Deborah) - Refer to slide. CCAMP will meet two sessions. Currently working on WSON, almost finished. LSP
diversity is hot topic right now, we had a last call on a document. Expected controversy and had no consensus.
Authors and working group are meeting during this week, hopefully will get some agreement. Also, discussing overlay.
And new technology, Flexible Grids and WSON impairments.

Forces (Jamal) - Refer to slide. Didn't meet this week. We've closed on what we were previously chartered. A bit
behind now. About 4 months behind schedule. Five drafts, main core, under discussion.

I2RS (Jeff) - Refer to slide. Behind on most items. Progression going good now. Progressing architecture and problem
statement to last call. Goal of selecting protocol within the next month.

IDR (John)- Refer to slide. New documents roughly equal to those getting finished. Ready to Last call two documents.
This session will cover updates for new routing capabilities, some drafts operational focused, and drafts on add paths
using BGP.

ISIS (Hans) - Refer to slide. New RFC7142, reclassify RFC1142 to historic. Three active working group documents, one in
Last call, one sumbitted for publication. Catch-22 in SPRING, three proposals for label, would like to call for adoption
of one to work on.

Karp (Stewart) - We'll on the agenda later as we need to discuss whether there is actually sufficient interest (and
willingness to participate) to work on AKM.

Stewart- Note, this time, the agenda time for IETF was full. You need to make sure that if you want your working group
to meet, you need to get the request in on-time. Then it will be your AD's problem to ensure you get time. If you don't,
it's your problem.

L2VPN (Giles) - Refer to slide. Multicast taking a while. Three with IESG. Three before next IETF to get in queue. EVPN
main work in Working Group. Thinking to recharter in relation to management stuff (YANG models).

L3VPN (Thomas) - Refer to slide. 1 new RFC, 2 WG Last Called. Two active drafts. We met yesterday with a surprising short
meeting. Two topics of interest to other wgs: mboned and l2vpn.

MANET (Adrian) - Met. Mainly on their process for progressing work. Got thru alot of olsrv2 and a big cluster in editor's
queue should start moving soon on olsrv2. Putting roadmap in place for other work, dlep and aodw2.

MPLS (George) - Refer to slide. Five new RFCs. Five in RFC-Editor's queue. Eight in IESG processing. Only 3 new drafts,
our arrival rate seems to be now decreasing. Loa reviewed the Working Group process in MPLS, hoping to improve quality of
our documents. Adrian also doing a slide set for us on how to write a good RFC. The transport area is having a discussion
on tunneling foo over udp because we have a draft related. On MIBs, will have a discussion on read/write for MPLS-TP.

Adrian - I'm not planning to do for all wgs a lecture on how to write good RFCs, but if you are wondering how ADs review,
you can take a look at the MPLS slide set.

NVO3 (Matthew) - Refer to slide. Problem statement in editor's queue. Almost done with requirements. Alot of deployed
solutions in this space today. Trying to analyze what exists and determine if new protocol work is required. Doing a
gap analysis. May do a rechartering if decide new protocol work is required. Also a problem in documenting the existing
solutions as no standards exist for them.

OSPF (Acee) - Met Monday morning. Finished MANET single hop extensions, both the experimental and the Cisco work.
We are additionally close to respin of RFC 6506 being finished, which meets KARP requirements without using IPsec.
For new work, this is most important work since v3, is on extensions to LSAs, as important for backward compatibility.
Had new proposals for enhancements for satellite networks. Proposal for dual stack TE work.
Also have TE metric extensions. Also MRT draft, now that routing wg has accepted.

PCE (Julien) - Refer to slide. One new RFC. Two on the way. Four in last call. Discussing stateful PCE. Most documents
progressing pretty well. Other topics coming are DNS-based discovery and path diversity.

PIM (Stig) - PIM has a handful of active documents. Only 2 updated for this IETF and only one of them was presented. That
was DR Load Balancing. Publication requested for 2 documents. The PIM explicit tracking was returned to the WG after review
by IESG. Expect to send it back to the IESG soon once the author has improved the document and the WG has no issues.

PWE3 (Andy) - Refer to slide. One RFC, one draft in editor's queue, three with IESG. This meeting, new ICCP applications,
e.g. PON. MAC address withdrawal for static PWs. Discussion on completing outstanding milestones.

Roll (Adrian) - Refer to slide. Chairs can't make the RTGArea meeting. Will meet Thursday pm. Status on their slide.
They are winding down. Looking at security. Significant piece of work, but making progress and hoping to finish soon.

RTGWG (Alvaro) - Reviewed slide. Have new chair, Jeff. Thanks to Alia. On advanced Multipath, finishing. Meeting agenda,
two of seven items on FRR. New work on DPS and Data Center Networks.

SFC (Tom Narten) - Reviewed slide. First working group meeting. good attendance. Twice as many drafts as could do slots for
meeting. We're doing requirements, but also looking at the header and how to do. Received a liaison from BBF, don't see any
conflict with what they are doing. We can support what they are doing.

SIDR (Sandy) - Reviewed slide. Met on Tuesday. Two working group documents pasted last call. Several waiting for publishing
requests. Two discussions that will result in bis versions of two RFCs. Energetic discussion of a change that if adopted
will have a large impact on technology. Looking at the choice of using rsync, may revisit that choice.

SPRING (John) - We're still new, don't have any working group documents. We are discussing our milestones, and so as new
haven't missed any milestones. Talking about how to come to consensus and progress our problem statement drafts so can begin
discussing architecture documents at the next meeting. Anyone that cares about spring should be on the mailing list and
contributing to use cases. The ADs have given us guidance about the plethora of drafts in other working groups that are
related to spring and asking for codepoints. I can say that if those working groups adopt the drafts, they need to
coordinate with us, spring. Those drafts won't progress unless we get use cases and arch done. To progress those drafts,
need to answer - do they support spring objectives.

Adrian - nicely summarized, we need to ensure there is coordination.
Alia - and should have a use case in spring that describes that solution that they are working on in other wgs.
John - I do prefer codepoints handled by IANA vs. people hardcoding in draft/implementations without coordination.

Homenet Routing Advisor (Acee) - Reviewed slide. They have working group consensus on preceding with work on home network
control protocol (HNCP). It's based on trickle, minmal state flooding protocol. Used in roll too. Will be used to bootstrap
the home network. Internet of things, trickle is deployed. I like the way it is built, leaves alot
of flexibility in how can specify the rules. Wanted to do auto prefix configuration, it's moving forward that protocol.
Also working group consensus to recommend single IGP for routing. Not chosen yet. Another piece of work that needs to be
added is source destination routing (may haven seen presentations in other wgs).

Other business
Adrian - Reviewed AOB slide. On VPN scaling, a BoF was proposed but it fizzled. There is a draft, should take a look and see
if there are enough issues to merit discussion. Can look at it if interested. The mailing list is still open if doesn't seem
to fit in l2vpn or l3vpn.

Open Discussion

KARP (Joel and Brian)
(scribe: This is a summary of the discussion, for detailed comments, refer to audio for session)

Adrian - if you care about routing - don't leave the room now.

Joel - We have alot of work in the working group but the work is not getting done as folks are just pointing fingers at who
should do the work.
Brian reviwed the slides. We have some small documents which give some guidance. Several gap analysis documents
have been published,in progress, or just starting. Operations model for router keying is in the RFC editor queue. Also
database is in the editor's queue.
What have we achieved? Security and interoperability have been improved for manual configured keys. Now, looking at manual
keys vs. AKM. Manual keys is operationally more a burden and also sometimes the keys are not as good. SIDR is also doing a
lot of work on distributing keys for BGP. There are tradeoffs for AKM vs. manual, maybe the cost of AKM not worth it.
And the complexity of AKM brings its reliability into question. Newer AKM has better DoS protections. Been reviewing
AD questions on whether KARP should continue with AKM work. There doesn't seem to be sufficient support to adopt some of
the drafts that have been discussed. Would like to ask the question in this broader audience. Should the work be abandoned?
Should it be moved to the security area?

Ren - a couple of clarification comments. For an IGP, all the routers are in a single AS domain. So many use provisioning as
they control all their routers. That solution not so obvious when discuss interdomain,as then have two different provisioning
systems provisioning the two domains so not so straight forward to coordinate. Also these are using multicast for BGP, not
so good. It might be productive when you ask the questions, to scope the questions for the two distinct problems (inter/intra).
Brian - yes, two distinct efforts. Been doing EBGP. Some multicast. But for multicast protocols, do have problems, nasty
problems. TCP based pretty far along, for automated keying. So would be good to separate the efforts.
Curtis - not sure what proposing for IGP. For SIDR can use PKI. But for IGP can not use PKI. It's a chicken and egg problem.
Two separate issues, picking a key and distributing a key. From what I know, service providers don't pick keys by hand.
Because these are used by routers, so machines can pick. So it's distributing that is needed for the keys. Would hope by
now ISPs know how to do that by now. So not sure configuration is a problem to solve except maybe for new players on the block.
Joel- Now we come to the problem we have, we need people to do the work, the expertise.
Ross - I'm not saying I have the expertise. I'm commenting on the last bullet, should it be moved to the security area? I think
there is so much specific to the routing protocol, that if we just gave a list to the securtiy area, something would go wrong.
Yes, we do need security experts to participate here with us on this in the routing area. I don't know if there is a concept
of a working group in two areas. But we sort of need it to be half done in the routing area and some in the security area.
Brian - that's why we have been doing it in the routing area. We've had security experts participating, but not enough
non-authors participating so far that are interested.
Ruediger - I'm not able to do the automated key management. I can provide hints and some requirements. People are sitting,
waiting for solutions, but not effectively producing text. For me, I viewed as it was experts, not me, doing the work.
Not sure how to tackle that problem. On what would like to see, I can remark
on interdomain. My focus, the actual problem is authenticating between ASs. For that we are building on how we are doing.
As for intradomain, I'm not so comfortable with relying on my provisioning systems. Having a roll over once in a while may
be the way. My take on the question, are current operators satisfied, yes, we know ways to operate but we probably are not
so happy on it. But there is so much elso to do, why bother on this one. If security becomes a problem, then will be interest.
Acee - my comments on the intradomain, unless people want it and want to spend money, I don't want to spend time on it.
Delegating it to the security area, I'd be concerned it could be developed with the premise that security is the main premise
vs. routing.
Sam - I found we have alot of expertise. I've gotten good answers e.g. from Acee. We've gotten it pretty close. I hope
whatever we do, we do it as needed from both sides. Maybe we can get more security experts over there (security) if we do it
there. I want to speak on trust and respect and in the IETF community. we did do some security requirements on automated
key management and we discussed in the community. Alot of people built up trust and wanted to support the routing community.
We had to make hard choices to give priority to supporting the routing community and made compromises. If now give up, it
will damage the community's trust. I'd hate to see that happen. I ask, if we think the work is valuable, then let's do the work.
If automated is not the answer, then we can revisit and do provisioning. If want to do provisioning, should do so as
interoperable vs. using one vendor's provisioning system. Let's not go against agreements we have made. Let's have a broader
discussion and rework our agreements and writeup why. But if don't want to do now as don't have enough people, then don't
stop people from those that want to do it in the future.
Wes George- On Acee, the cost of implementing. That's true of most security things, we've been lucky it hasn't bitten us. Yes,
operators have been using the same MD5 values for many years. We have been very lucky, but not a reason not to do it. As we
have not been bitten, money is not going to be the primary driver. It will be because it's the right thing to do.
Jeff - the problem with security in IETF is that the older stuff is "good enough". Things do evolve. And when figure out will
need it, it will be too late. We need to start now. That's what this working group is trying to do. Where's the money for it?
Because it hasn't been a problem, the money is not there. Can either proceed ahead and document so when it is needed it's
ready. Or say that effort is too much. Then stop the work for now, free up the people working on it, and when need it, can
pick up.
Curtis - Two problems, the one Jeff brought up. Never changing a key. So one problem is - changing a key, key generation. Do
you ever do it? Second problem goes with what Sam was saying. There is now a standard mechanism how can do - NETCONF. So now
the CLI that NETCONF represents differs by vendor. So maybe can built a yang module for that. I think that's about all that
can be added now to current practice.
Doug Otis - there is another protocol used for cell towers. That technology is very fast, very reliable. If do over tcp, may not
be as robust. So do have technology, if want to apply it.
Joel - some use it, some do not.
Doug - that's not it - I can not say what it is.
Tim Polk- We put this in the routing area as we thought security folks would come and help. I don't think we can punt it to
security area and expect it to get done. While I would prefer automated key management in-band in the security protocols for
the future, you could use like yang for outband. So not manual. I would like to see even that incremental effort. Let's
think though what is it that we really need. My view, the security tool kit in the routing area is very thin, so if we need it
in the future, we should be progressing now as we are a long way from deploying code.
Acee - I was refering to interdomain before. I think this work on tcp, for not only service providers but also content providers
will need a RPKI solution. And it doesn't have the chicken and egg problem. Need to do right as there will be consequences if
don't. I think KARP has done good work, especially for IGPs, now need implementations and deployment. On the yang model, we
have the key table draft could be mapped to the yang model. And implementations could map to their internal.
Sam - clarification, the intradomain, it doesn't have a chicken and egg problem, unless you create it. All our proposals
could be said to cover that.
Curtis - there's a third community should have been involved - the operational community, ops as they will give input if
anyone wants to deploy this.
Brian - we have had a few ops folks involved.
curtis - these are all operational practices that people know the proper pratice here in IETF - if people use them that's
the question.
John S. - I can say this is great, but unless you give me a business case for it, I can't say it's worth it. Some of the other
comments have convinced me it is good to go forward with the work now and not when our hair is on fire. 
Curtis - is this encryption?
Joel - no, we're not doing encryption, this is authentication. Would like to see if interest, will confirm later on the list. 
Joel - how many people here would like to see work go forward on auto managed keys for interdomain? Good show of hands.
On intra domain? Less hands.
How many would do work on interdomain? - only 6 hands. Intradomain? - only 6 hands. So this is the problem. Lots of people
want the work, but not do work. So again, how many would help do the work with interdomain - this time a few more hands.
For intra domain? only again about 7.
Thank you - we will try and figure out what to do with this.
Curtis - this discussion would have benefited if we had a heads up on this before.
Ren - one suggestion, may be worthwhile to do a yang module, can you ask?
Steven - interdomain seems some interest maybe ask.
Sam - I'm hesitant to do that - I'm hesitant to change direction now. Let's ask both the interest question and the willing to do.
Ruediger - I think we should look at the question - do we want explicit description of the model, or not to do that as it 
would be percieved as changing direction.
Sam - It's not about changing direction that concerns me, let me rephrase - I want something deployable and interoperable.
Joel - how many would work on the model for an interface for key management? About seven people. Thanks, we'll talk more on
the list on what to do.