IETF-80 Routing Area Open Meeting
=================================

http://rtg.ietf.org 
ADs: Stewart Bryant, Adrian Farrel

Scribes: Deborah Brungard, Dan King 

Administriva and Area Status
----------------------------
Reviewed the Note Well. Reminded to try and use Jabber. Reminded about Routing Area
mailing list and wiki.

Routing Area Working Group Reports
----------------------------------

BFD (Dave W) - Not meeting this week, probably meet in Quebec. No documents right now. Some items currently
in pwe3 and mpls, probably will be cc on last calls. All three groups together to discuss bfd how
relates for these purposes. Get mib out and renewed effort on P2MP.
Adrian - we should try to get a revised charter in place.
Dave – yes, progressing well.

CCAMP (Lou) – Met this morning and will again tomorrow afternoon. Full agenda. WSON and OTN big topics,
some MPLS-TP and G709. Had one joint last call with mpls and pwe3 on TP Control Plane Framework. Two rfcs
in queue, TED will be 2nd lc. Have some related documents to other groups (latency). Have some questions on
mpls-tp on control where should be defined – data plane or control plane.
Adrian - Also some extensions to ospf, and need to flag to isis if have interest to progress.
Lou - Had five new RFCs. Another Ethernet one
in pipeline. Couple of documents, almost ready for IESG.

Forces (Jamal) - Met Tuesday. Some issues on drafts. Need to obsolete one RFC, and reissue. Then plan to
shut down.

IDR (John) - Meeting Thursday- very varied agenda. In process of adding a secretary for the WG. A couple of
documents finishing and in WG last call. Have several BGP documents in other WGs in particular SIDR
interested in and should look at.

ISIS (Dave W) - A number of documents. Waiting for IEEE for a normative reference to their draft.

KARP (Brian) - Looking at several design documents. Will be meeting on Friday. Also some individual drafts.

L2VPN (Gilles) - Process of rechartering. Adding ETree. We are trying to complete outstanding work.
 
L3VPN (Ben) - It's been a quiet period and we did not meet face 2 face at this meeting. We have rechartered
which is minor tweaks/clarifications of scope and a couple of extra milestones. We have a couple of drafts
in WG LC (one jointly with OSPF) and 3 in the RFC Editor queue. Our workload is fairly small at the moment.

MANET (Joe) - Number of activites on neighboring discovery protocol, a couple drafts expired as delayed
with work and how to include metrics in draft. Several mib activities. Presentation from community wireless,
presentation online.

MPLS (Ross) - Busy session yesterday, another tomorrow. Two new rfcs, four in editors queue. Number recently
finished wg last call. Need some updates to complete. Alot more documents being progressed.

OSPF (Acee) - Resolved to move forward on OSPF Multi-instance and OSPF Transport Instance Drafts (listed as
informational reference in some drafts). OSPFv3 Authentication Trailer now WG document and is almost ready
for WG last call. RFC 3137 being respun to cover OSPFv3. Several TE Drafts in CCAMP, TE Express Path in OSPF,
Area ID TLV. Proposal to respin OSPF Manet Interface to cover single hop networks. New OSPF authentication
proposal to thwart replay attacks. New proposal for use of OOB synchronization incrementally. Fast Notification
draft aligned with the framework and transport notification drafts in Routing WG. 

PCE (Julien) – One new rfc, historic one on manageability experiment. Four topics: GMPLS extensions, both
generic and WSON, interdomain extensions, proposal on charter reviewing, pcep (5440) discussion on issue
on operating system interaction. On security review comment, doing update, need to discuss with them.

PIM (Adrian) - Met start of week. Couple of documents in editors queue. Three in WG nearly done, opened
PIM spec to discuss approx 100 errata in system to support advancing document to draft standard. Will do
small charter revision.

PWE3 (Matthew) - met Monday, one new rfc. Did deployment PW survey. About 17 users responded. 50% use
control word. Had discussion on control word negotiation. One needs to be reviewed by mpls wg also.
Discussion on extension to support MPLS-TP.

ROLL (JP) - Main spec now in rfc queue, also metrics, others also just published (refer to Routing Area
slides for summary).

RTGWG (John) - Already met this week, we are the home for routing items with no home. Composite link, we
have the requirements completed last call, authors rolling in comments. We have started discussion with
chairs of ccamp and mpls, to find a home there, or rtgwg. About to last call LFA applicability. Last couple
of meetings had a couple submissions on fast notifications. Again, need to go to mailing list for discussion.

SIDR (Sandy) - More than a dozen finished last call and seven passed IETF Last Call. Core set finishing.
Couple of updates on existing. Most of discusion will be new drafts. Some on implementing the
drafts. And discussing charter.

VRRP (Adrian) - Not meeting. VRRP unified MIB, AD review is done, updating. Three individual drafts
submitted, no discussion yet (refer to Routing Area slides for summary).


Heads-up: Learning Capable Communication Networks (Dimitri)
-----------------------------------------------------------
Reviewed slides. Will have IRTF pre-BoF this week.


Running WG Meetings (Stewart Bryant)
------------------------------------------------------
Reviewed slides (refer to Routing Area slides). Ops Area WG Chairs are discussing ideas for running meetings.
Agenda time is getting really squeezed. Need to make efficient use of meeting time vs. presentations.

Discussion:
La Guerre (?): Can I get 10 min back - this is a Routing Area WG, not admin group.
Luca – I agree we are in marketing powerpoint mode, I can try this – put up one slide – but most are
watching baseball game (wifi), not listening.
Dimitri – Maybe help to make agenda with a couple of docs to read and this will be discussed in meeting.
Stewart - Yes, we should use meeting time for high bandwidth discussions.
Dimitri – How do we then get consensus on these discussions, I rememnber in past, one of the modes was make
crisper the presentation, have a couple of questions, and a target defined. Need to make disucssions
effective – mobilize the community.
Stewart – Yes, exactly should use to mobilize.
JP – Yes, agree. 80% time on presentations, we then need to do conference calls for discussions.
Adrian – you set the agenda in your wg as chair, that’s the purpose of these slides is to say for the WG
chair to take control the benefit of IETF.
Aaron Falk – Not active in routing area, I can share a method we have tried. I’m leading a discussion of
200+ people. We figured out topics (not necessarily drafts), get peopole who most likely will disagree to
talk before hand, and then do a proposal resolving, use meeting for fine tuning. So good use this way.
Julien – In Ops Area, ADs are doing a stronger enforcement – any feedback?
Scott Bradner – In Ops Area WGs, we required each only two slides, and assume the audience has read the
draft. It was semi-successful. First slide, not high points, but summary. It worked pretty well for the
first go around. Did speed up.
Spencer Dawkins – Let me understand, you are saying powerpoint disease is not just up to wg chairs but each
person. I’ve been saying get items cleared out on mailing list, so meetings only high bandwidth items,
no agreement on. When see requests, also see items presented in more than two wgs – this means items not easily
chartered either. In rye wg, ofter have dispatch wg which is area wide where people can give one slide with
summary so everyone knows point of contact for discussion items. I also wanted to flag BOFs, having a wide
range of issues to discuss in a BoF is a bad thing.
Dimitri – Suggest trying in one wg and seeing what they think. Probably depends on topics discussing and
level of detail. Should do a trial.
Stewart - The headline for this is to experiment and see what would be more efficient.
Richard Grave – Suggest an alternative – have a few wgs with smaller charters that don’t last so long. Ipsec
had multiple spanned wgs that came and went.
Sasha – These guidelines, do they include why we need a mandatory presentation of wg status which can be
found on the wiki?
Adrian – Yes, they could apply to that also.
Jphn Scudder – The two slides are contradictory – say don’t use slides at all, then say but post early. I confess
I get useful information from slides as I can’t look at all drafts.  Suggest when post a -00 also post a
slide deck summarizing.
Stewart – But isn’t that the abstract?
John - But to be decent, needs to be longer – powerpoint can be a valuable way to communicate. Good to post
to list early a presentation.
Thomas – Powerpoint is a sympothm, not the problem. Need to change the culture. Takes a buyin of everyone.
This is a management problem – ADs, Chairs – they are in best position to fix. Spend time with chairs and
try to address this. So not random experiments. Develop working practices.
Ross – I find the summaries here in meetings useful as can’t go thru all drafts in all wgs. I think you are
asking people to think about what they want to get out of presenting. We should take into consideration
these ideas for presentations at meetings.
Stewart – We will look at the minutes discussion and decide what we (ADs) want to do with this.


MPLS-TP Codepoints: draft-tsb-mpls-tp-ach-ptn
---------------------------------------------
Adrian reviewed slides (refer to Routing Area slides). Summarized the history and that the codepoint being
requested by the ITU falls under the RFC4929 process.
Malcolm Betts reviewed the liaison and draft (refer to slides). Commented communication between Russ and TSB,
that interpreted as Russ saying to write a draft. But when I read it again it doesn't exactly say that.
This part of the problem – there’s a communication gap on assumptions. We want more productive use of time
instead of continuing to argue. ITU intends to comply with mpls archecture, not do something on their on.
At the Feb ITU meeting, a significant number of network operators (8 from Europe and Asia), with vendors
along for ride, as its driven by network operators, requested this. ITU plans to produce Recommendations 
with both IETF and ITU OAM solutions. The differences are in detail of equipment behavior not really in
requirements. Draft will be updated to more clearly say this. We are at a deadlock as one group is saying
IETF solution does not meet their requirements. Noted should update protocol registry to clarify this not
an address but a protocol identifier. Going back to requirements will not help. Next steps. Clarify code
point is a protocol identifier and not an IANA number/address.
Nurit – A clarification issue – who do you represent here?
Malcolm – I’m representing this as an individual as we don’t have an official liaison to IETF from ITU on
MPLS-TP. I ran the presntation by TSB and management team.
Nurit - So this is as individual that was presented to management team. I have a few comments. You said
some operators not satisfied by solution in IETF. It’s important we understand why they are not satisfied.
You need to indicate why the requirements not satisfied. You indicated differences are close to invisible
at the requirements level. And you say only apparent at protocol behavior in equipment – deployments, so
how do know doesn’t satisfy requirements?
Malcolm – Nurit, you spent those many days in Geneva and you went thru discussions. One group said clearly
a different application and other group said no difference. We can do three more days of discussion.
Nurit – Not to say what discussed in Geneva. Just buzzwords. I would like a single, global solution. For both
vendors and operators. I’m surprised you bring in about member states. You should discuss that with them,
not in IETF.
Malcolm – Member States did make strong statements that this registry is on numbering so I think should
clarify.
Nurit – Need to bring technical justification – requirements to satisfy for IETF to determine why doesn’t
meet.
Rahul – You are asking for a codepoint for bhh draft. Mpls rejected bhh. That’s work under the bridge. You
need to bring this to MPLS WG, this is an end run around WG process.
Eric Gray - Alot of people would like to see this resolved. To help us do that – you need to explain what
name and numbering means in ITU context. You mentioned you did a deeper analysis and have additional
requirements, we need you to be explicit what those are.
Alessandro (?) – First, it's not true that there is not knowledge on this technology. There are deployments.
I’ll repeat from the meeting. We see the approach being used by IETF is very strictly related to the legacy
MPLS networks, so when IETF thinks to develop new tools for MPLSTP, should look at improving those tools.
Operators with OTN and Ethernet then need to introduce these new tools that are very destructive in these
environments. Want IETF to take this into consideration of this impact when introduce tools which are
MPLS-based in our networks.
Dave Allan – JWT report had two options – work together or ITU can get its own codepoints. Only when we reached
this impass, now want this. I’m curious why option 2 wasn’t pursued before. This is ITU getting to violate
IETF copyright on MPLS.
Curtis  - Before, prestandard was always expected to convert to standard. 
Luyann – ATT had prestandard LDP, then told vendors to convert to standard.
Sasha - What does ITU mean by this numbering, I don’t understand, I assume these 200k nodes are using
prestandard so they can continue to do so, and then need to decide to go standard. What is the rush?
Adrian – On numbering, don’t want to insert myself between USA and United Nations. If we get precise questions
on this from the bodies concerned we would answer them.
(?) – I don’t think any difference in solutions –one available a couple of years. If want to sell to
China then do it. I suggest give them the codepoint.
Nurit – I have questions on code point. Two solutions solving same issue. Instead of trying for alternative,
do one solution. Need technical discussion on why the solution doesn’t meet requirements. Deployments, are
these MPLSTP or TMPLS?
Malcolm – As was explained in Geneva, 40k have migrated to G8113.1. 200k can not say -high proportion in
China, can’t say others.
Igor – I'm asking RA ADs, if I have a tool set at home, two screwdrivers with different handles. Why
is it so important not to allow OAM tools?
Adrian – ADs bound by IETF process.
Igor – Difference to developing new protocols vs. oam tools. With protocols, we have isis and ospf. If I
want to use Y1731 based tool, why can’t do that?
Stewart – If you want to develop a bis, then you know how to do that.
Russ – This question has been answered by IESG. We shouldn’t waste our time. We decided to develop one
solution, we saw no need to develop two solutions and we still don’t.
Luyann – Malcolm, thanks for confirming, this deployment is TMPLS.
Adrian – Malcom should have said MPLSTP.
Malcolm - 40k TMPLS have been migrated to g8113.1 MPLS-TP.
Luyann – What codepoint?
Malcolm – Experimental codepoint. 
Luann – So in production, this has risk. What is 200k in press release? What are they running?
Fu Wan – We have discussed requirements for two years. All service provider requirements need to be satisfied.
Yaacov - What’s missing on Malcolm’s slide is that there was no consensus at the Geneva meetings. Some
demanded vote. It then became a political issue. It’s not for here to discuss that.  There’s no technical
justification for this – just commercial. So suggest actions, we reject first this one, as not for IETF to
be involved in political discussions of ITU, authors of this draft need to justify why they are requesting
another codepoint.
Malcolm – This slide doesn’t say no difference – just that they are not at the right level.
Alessandro – People claiming that silicon costs, complaining about two solutions. People from these
companies should come to mike. People are saying already deployed IETF solution but those vendors not
operators. Operators already deployed ITU solution and they are not saying bad for internet. Implications
on operational aspects, it’s not only a commercial requirement. In pwe3, discussed having multiple solutions
for other items. Don’t understand why only need one solution here.  If can say why, come to mike.
Adrian – I shut the mike line already.
Yoshironi – Want to support bhh codepoint as think efficient for tp development in future. On difference,
two solutions same for MPLSTP requirements, but from operator perspective clear difference. Example, need
to consider vccv and new ach in case of bfd diagnostic code, etc. These requirements not included in MPLSTP
OAM. So there are clear differences. Today some operators have two layers – cxt based and ip based. Most of
case, networks are separated. So need two approaches for MPLSTP. Need to consider two scenarios and which
solutions best for two environments. Seems easy for mpls based to migrate to MPLSTP. I don’t say the IETF
solution won’t be used, but operators need other one also.
George Swallow – If you want clear separation in a technology, then best way is to get a separate ethertype.
But I came to mike as your slide seems to say no layer interaction for client/server but AIS and lock do
depend which OAM running for layer so it is appropriate. Transport networks are very robust so require the
layer below provides everything for the layer above.
Adrian – Maybe it would be better to get other opinions at mike.
(China Mobile) – By assigning codepoint to ITU, will make internet work better. Best for operators and
vendors.
Nurit – Your slides say no new requirements, but you mention now that differences in requirements, so ask
you document this so we can discuss how to resolve. On two solutions, we have had multiple solutions,
but confusion, and capital and operational expenses associated. IETF sent a liaison to ITU on MPLSTP OAM
and this liaison was not even discussed at the last meeting.
Curtis – The reason for an experimental codepoint is that we don’t want to encourage someone else to
implement. We know the outcome here.
Adrian – Wrap up. A decision was made to use the IETF process, we are limited by the process, to do only one soln
for a problem. We have now that this is a different problem or something else. So the ADs will clarify the
process and encourage anyone with requirements to bring them into the process. 
Stewart – They need to be technical requirements so we can understand from a protocol design how the protocols
are technically deficient.
Adrian – We will not only clarify to ITU the process, but also what consensus means and “technical”. Thanks
to all, you are free to talk to us offline.


Open Discussion
---------------
No discussion