IETF-84 Routing Area Open Meeting
ADs: Stewart Bryant, Adrian Farrel

Scribe: Deborah Brungard 

Administriva and Area Status
Stewart- Opened the meeting. Adrian and Stewart reviewed the Note Well and agenda for today.Reminded about IPR
process and the need to have ack from each author and contributor.
Martin V- If you are listed in the ack section how applies?
Adrian- Then you have contributed to the document, you are a contributor, so you need to disclose.
Martin V- In MPLS, we are tracking all.
Adrian - In MPLS, applies authors and ALL wg participants, so covers.
Lou - If you sit in a meeting that counts as a contribution?
Scott Bradner - Contributor is if you are awake and say/write something, jester, something that changes the direction
or continuing of the discusssion, you need to disclose. IETF doesn't require sleepers in the room, but we need to
encourage everyone, even those sitting in the room.
Stewart - Lawyers will request blue sheets then you will have to prove your involvement.
Scott - Yes, a couple of cases where someone had to prove they weren't participanting.
Adrian - In my slide, I said present, so Lou asked for more clarification what is "present".
Dimitri - you should also include reviewers.
Adrian and Stewart agreed.
Adrian reminded nomcom nominations still open, volunteer, otherwise you can not complain.

Routing Area Working Group Reports

BFD (Jeff) - met this session, primary work on bfd over Ethernet LAGs, trying to specify the work so as not to make IEEE
unhappy, seems to be going in right direction, will liaison IEEE, and probably then recharter.

CCAMP (Lou)  Meeting 2x this week, good discussion on WSON, how to carry parameter defined by ITU, we will follow ITU.
Another discussion on how to represent OTN multiple hierarchy and we will follow work we did in the past. Today will
cover new topics related to our work. One new RFC, two in WG last call, and several with the IESG.

Forces (Jamal) - Meet Tuesday, primary the two drafts going for completion will go after this meeting. Interop draft will
start going for pub after those two. Have permission from AD to start going for new work, so if have ideas please bring
them in. Hope to recharter soon. Alot of activity on use of forces in several organizations. Had a couple of open flow
presentations (online).

IDR (Sue) -Presentations on a data center use of BGP and private address space. Published an RFC. Several in process.
We are looking for implementations and encouraging for people to come with implementations and let us know if any bugs. 

ISIS (Adrian) - Couldn't make it to meeting, have a new RFC, closely related to trill, quite nice cooperation between
trill and isis to get reviews done in right places. In editors queue will come out soon. ISIS just changed ADs so to
make sure different organization as chairs both from same organization.
Donald Eastlake - Since the ISIS WG is not meeting here and at the suggestion of the ISIS Chairs, I will be presenting
the rfc6326bis draft in the TRILL WG meeting.

KARP (Brian) - One draft waiting for IESG, two soon to go to IESG (in last call). Looking at protocol implementations,
looking forward to consolidation of several ideas.

L2VPN (Gilles) - Two new RFCs since last IETF. Trying to push the EVPN drafts to get done.
L3VPN (Martin) - First new meeting for new chairs. Two new RFCs. We have several multicast with several individual
drafts on (friday). Working with ADs and l2vpn to make sure coordination on topics.

MANET (Joe) - Two new rfcs, multicast forwarding and security. Last call one, another on management neighbor discovery
reviewing. Another on reactive, going slow to ensure what needs to be done. Also router interface one which will be a
new activity in future.

MPLS (George) - We reached 100 rfcs, thanks to ADs and sec. Work going on mostly FRR related. Meeting 2x. Friday on
MPLSTP PMP and deep packet forwarding. Started a review team as we have large backlog of docs to help reviewing.
Have quite a few volunteers and good comments.
Ross - added -Two new RFCs, one on overview of MPLSTP tool set and mibs for MPLSTP. Another on reasons for selecting
a single solution for mplstp. A document on codepoint for ITU (if they decide they want their own codepoint).
stewart - and we wish Loa a speedy recovery.

NVO3 (Matthew) - First meeting - key objective to progress problem statement documents, chairs now have a way forward
and will announce to list. Will meet interim meeting in Amsterdam.

OSPF (Acee) -  We meet today, need a scribe if can do. One problem, we need to finish work we took on and have some
new work. Two Drafts with IESG (Prefix Hiding and the Hybrid OSPF broadcast/P2MP Interface). Two very close to sending
to ADs for publication (RFC 3137 and IPv4 Embedded Routing). First WG meeting focus - Finish existing work: OSPF Transport
Instance, OSPF Enhanced TE Metrics, OSPF MANET versions of Hybrid OSPF Interface (Variants of previous OSPF MANET
Experimental RFCs). Second WG Meeting Focus - Evaluate New Work: Homenet WG Requirements, Scaling enhancements,
optimizations, OSPF Extensions.

PCE (Julian)  Met on Tuesday afternoon. We have our usual topics - extensions for gmpls, mibs, interdomain. If interested,
please start reviewing as we will be moving forward and beginning stateful PCE work. Asking secretary to resolve our
constant meeting conflict with ?, though now decided not to do anything now.

PIM (Stig) - Progressing several documents. A draft for announcing MTU in PIM Hello's was discussed. We are curious how
other routing protocols handle MTU issues. There was also a draft about extending mpls for PIM being discusssed.
Adrian - the question on MTU discovery is a good one to take cross working groups.

PWE3 (Matthew) - 4 new rfcs, met Tuesday afternoon. Two in RFC Ed Queue. Topics on agenda included: VCCV v2: Effort to
simplify RFC5085 and include support for GAL in PW OAM. Transparent SONET/SDH PW. Openflow control of static PWs.
PW congestion framework: Detailed analysis of the impact of elastic and inelastic PWs on the network.

ROLL (Michael) - Havent met yet - Friday. Progressed the hystersis document, should be RFC soon. Last call on p2p will
writeup for IESG. Have consensus on our security document. Wondering to do applicability statements, looking for

RTGWG (Alvaro) - One new RFC. Two past WG Last Call. Four new WG drafts, two on composite link. And two presentations
on energy awareness of control plane. Discussing where to take the work.

SIDR (Sandy) - Active since last IETF, several interim meetings. thanks to host. Several strong discussions on
confederations and maintaing security inside and outside. Very beneficial discussions. One related to communication
of securtiy and performance aspects. May possibly begin work on alternative protocols for communicating that information.
ADs can expect a flurry of publication requests. See maturity in the base protocol spec. We did poll on interest in interim
meeting in amsterdam, have good interest, so will consider that.

Virtualization & OUI Tiers (Glenn Parsons)
Glenn presented slides. Speaking as role of Chair of Registration committee (RAC) IEEE chair.
Spike in use of addresses - use not only related to hardware (as only one per), it's software - virtual machines/racks.
These use potentially one thousand and transient - come and go. So VM space is
going to critically deplete in next 26 years. Looking at how can do virtural machine (VM) space.
Responses say the addresses can be reusable - so different from hardware space. Have suggested solutions/policies,
would be interested in IETF consideration to see if any impacts to IETF protocols. Had discussion with IAB and IESG last week.
IAB is going to do a study to see if any protocols will be impacted, we are interested if any feedback from you too.
Adrian - where should do feedback?
Glen - individual feeback to rac mailing list (will send link out), also looking for IAB. 
Adrian - so if small - send on mailing list, if big, issue should discuss with AD/IESG/IAB.
Acee - from Layer3 perspective, we look at MAC as giving hint on gloabally unique, but don't rely as sometimes
there are duplication. So I've never totally relied on it being globally unique.

Configuring Routers Using Netmod (Ladislav Lhotka)
Adrian- historically mib done in protocol wg. On netmod have a wg to do router mibs.
Ladislav - presented slides.
Acee - do you advertise routes that not using (that were filtered).
Ladislav - it would be up to implementation to define those rules, for example for ospf would need rules.
This is very general.
Acee - how far on implementations?
LAdislav - my work is not to do implementations, but say router demon is an example.
Acee - ok - I know that.
Ladislav - we are looking at implementations, and looking at current implementations if can use.
Dimitri - why call this core, an access router can use?
Ladislav - yes - it's not just core, any, but the charter just says "core".
Dimitri - how can input - will you have review by the routing directorate?
Ladislav - we already have. I'm a new chair - hope to get reviews.
Adrian - as work gets progressed, we have already done 3 routing dir reviews. we now at a critical time,
to get wide reviews so we want to give this visibility for the community to review.
Jeff - I've been watching this for a couple of years. We've been waiting for a baseline so can do work.
We should really put our effort here, as we know snmp is not the answer, this is better.
? - I think this very interesting work. We should be considering this. For example we know snmp is not the answer.
Ladislav - I agree. We need your help to use and progress. Really interested for your help in collaborating to
try and use.
? - I didn't mean to be negative - it is easy to read - and better.
Ladislav - we need to market.
Dimitri - are you waiting for cases to use?
Ladislav - yes, trying to develop for routing demon use case. Need to try for other cases, need your help.

A Proposal for an Interface to the Routing System (Alia)
Alia presented the slides.
Wes George - on slide 4, you make good points, no. 2 and 3 - applications aren't routers. There's a black box view.
I send out and don't care what's going on inside. But this discussion drives us to understand better how they
interact. There's a need to educate how they interact, network 101. There's a huge gulf - it's not just protocols.
For example, identity mechanisms. If operations under our control vs. extending beyond our span control. Then
need security trust model. there's alot of hand waving on what can do but need also to consider these aspects.
Alia - as any new item, need feedback from others.
Dave - this idea has been around for years so good getting vetted. My question is on control theoritical interactions.
There is a new open loop introduced now. There's a human that wrote the code to inject. How does this open
loop impact scalability etc
Alia- I wouldn't describe it as an open loop, I'm trying to describe as a feedback loop. When we define the model,
need sufficient policy safety knobs.
Dave - you can't really do what you just said as you don't know code.
Alia - love to hear more thought.
? - do you know where you will begin - layer one, two, three?
Alia - Layer 3 is obvious for link state data base but that doesn't accomplish so much. More interesetd in solving
topology display for different abstraction layers.
Tina - as Ethan said on mailing list, for orchestrator there are three layers. Why need several interfaces?
Alia - I think to have reasonable scope, left out orchestration layer etc as interesting to discuss, but for
us to progress need to constrain. This is bottom up design. In research or other forums may be interest to look
at top down, but not initially for us.
Tina - why not let irs give to upper layers and use one clean interface for upper layer to application.
Alia - many different ways can do.
Tina - when need irs vs. use api?
Alia - I'm in favor of reusing any existing protoco. I'd be happy to discuss that more and if people can evaluate
existing protocols
Acee - obvious YANG doesn't include all information, starting with configuration. what do you think?
Alia - I haven't reviewed but will after this week.
Tom - we don't want to just focus on configuration, also feedback look, reading info
Shane - yes, this is important for operators. Details we can debate. What you described as potential use cases,
it's critical to narrow down to focus. I think the topology model and getting it correct is really important.
Alia - I agree getting the topology right is important. Welcome help.
Shane - I'm more than happy to contribute. Topology is not just layer 3, critical to focus on multiple layers.
Problems of optimization require layers of detail.
Alia - we want to think about multiple physical layers and abstraction layers
? - should look at netmod work and avoid duplication. Should look at network wide state - opportunity there.
Not just do an off-line.
Scott - I couldn't get a vendor to give me shell scripts to run on a router. So this intersting but a bit late.
Need that this functionality is not just an interface to talk to router but need rib interface. Need maintain division.
Dino - Internet archecture did a good model of abstracting boundaries. Don't want us to go now on a slippery scope.
This more within a domain, not interdomain.
Alia - agree - as said yesterday if want to kill an effort start talking interdomain. Agree, need then authorization etc.
Ning - this valuable work. Suggest 3GPP has done alot of control/policy work, we can use some of it here. In my company,
we are doing use cases we can contribute. Carriers are looking at this for wireless, data centers.
Edward (Google) - suggest try to limit - not try for everything for all people. Have you considered how you will encapsulate?
Alia - we will try not to do that - there's a clear defined focus on defining use cases. On the encapasulation
types will depend on the router capability. We need data models that are general.
? - key requirement. I think is multi-layer
Chris - I think this is interesting. To me, this will be used by a service operator. This is an application for
them to provide more control.
Alia - we need use cases
Dimitri - nice presentation. On the multiple applications, if put together, need to look at aspects, then using together.
Is it the intention to pass information up to a system which will use the info?
Alia - for multiple applications - yes, need to consider the priority etc. for providing info, it will not cover all
the info needed, irs will allow filtering. so another application will need a different interface for their information.
Dimitri - will be two stage to analyze information is the question. The associations can have internally should also
consider as may not represent what actually want. Are you going to only use topology information or will also e.g.
Alia - yes will be combination of different information together is what's needed.
Dimitri - will have other sources for info that can consider?
Alia - we need to discuss more. irs doesn't just have to talk to routers.
Ben - this is interesting. I have a network product fits in your application space. Concerns of multilayer and
interdomain. I have a couple of use cases for single layer, single domain i will give you.
Adrian - so no one screamed against this. Heard quite alot of interest and some expressions of caution. And heard
some boiling ocean so need to be careful there. The word application is confusing as different views. So authors
need to be clearer. This is a discussion lis, not working group. I'd like to see more discussion, just remember,
IPR rules apply. If drafts/discussion focus, then we looking for a BOF in Atlanta.
Alia - this is a good start.
Adrian - there is a mailing list and draft so get on with it.

Open Discussion
Adrian - someone came to me they have a draft that they wanted to talk about.
Outgoing link selection with LISP-
Damen Saucez presented. Says any interest would be helpful.
? - in the DHCP WG, there is a draft where the BRAS server snoops on the routers. Is there any objection from
us doing this work.
Adiran - is there a draft?
? - yes 
Adrian - ping it to me and I'll circulate to see.
Acee - why?
? - I don't have a clue why they are doing it their way, you should discuss with them.