IETF-74 Routing Area Open Meeting
=================================

http://rtg.ietf.org

ADs: Ross Callon, Dave Ward

Scribe: Deborah Brungard 

Administriva and Area Status
----------------------------
 
Ross opened. Noted we will have a new AD, Adrian Farrel. Thanked Dave for all his work.


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

BFD (Dave) - Down to one discuss from the transport ADs, requesting a fast detection mechanism,
will probably run into this again for other work in RA.

CCAMP (Adrian) – I'm stepping down after this. 5 new RFCs. We had a meeting with ITU's Q6/15 on
Friday (this past Friday) on optical impairments. Was very productive.

FORCES (Joel) – Made good progress. 3 of 5 of core set now approved, on RFC editor queue,
waiting for 4th on transport mechanism. Should be done before next meeting.

IDR (Yakov) – Met on Monday. 3 new RFCs published. Accepted several new WG drafts. Several
individual submissions, several will probably be accepted as WG by next meeting. And had a
presentation on IPR by Dave.

ISIS (Dave) – Not meeting. On list, discussing with trill on passing addresses.
 
L1VPN (Adrian) – On last draft, it has gone to RFC Editor. Dave is discussing with
management to close group when published.

L3VPN (Dave) - Specification of multicast considerations and protocol drafts moving forward. Some
comments from AT&T need to be incorporated yet.

MANET () - no one here.

MPLS (Dave) – Met once on Monday, will meet again tomorrow. Mostly on MPLS-TP.

OSPF (Roy) – Meeting tomorrow. Published one rfc. Another in queue. Another in IESG review.
A few presentations - one on WSON, one on IGP sync, one on transport instances.

PCE (JP) – PCEP is now an RFC. Path key in editor's queue. One discuss hoping to clear. So alot
of progress since last meeting.

PIM (Stig) – Meet later today. One in last call. Interest in looking at 
multicast. An existing wg draft on building multicast trees will be discussed.

ROLL (JP) - Just got the new charter. Beginning the solution. Ready to roll.

RPSEC (Dave) - Closed.

RTGWG (Dave) - Discussion on virtual aggregation and CTG. Discussion will continue on those two
topics.

SIDR (Sandy) - Met this morning. Several presentations on updates to drafts. Drafts getting mature.
One contentous issue was separated and made as a separate draft. Debating how the data will be put
to use in routers.

VRRP (Dave) - MIB is delayed. Didn't meet since Minneapolis.




IPR
----------------------------------
(Ross Callon)
Want to remind people that contributors are required to disclose IPR that is known about.
The requirement is an individual requirement. Don't rely on your company lawyers, need to
ensure done in timely fashion. Third party disclosures are permitted. We all have a requirement
to understand IETF IPR rules. There will be a Plenary talk on this and also it will be discussed
at the WG Chairs lunch. 
 

Router Alert Option Processing
------------------------------
(Francois Le Faucheur)
Presented slides.
RAO security concerns and solutions not documented well. Different opinions on documenting.
Need to understand first several questions on it as to what an operator can do and
IETF development on RAO. Have split original document to two documents: Rahman and Narayanan.
On Rahman draft, summarizes current approaches and provides guidelines for new e2e applications.
Recommends that new end to end applications or protocols be developed without using IP router
alert (as currently specified). It recommends use of RAO and how to implement RAO protection.
RAO can be used safely in Controlled environments or provided the operator can protect
themselves (e.g. by tunneling). Currently revising the draft.
Stig - It would be good not to just drop, be good to send a message to the sender and say can
not do it.
Francois - See your point, but generating ICMP requires punting packet to CPU which is what
"dropping" is trying to avoid - need to think about it.
Tony - But opens up to DOS attacks. Better to count/log and move on. I feel ICMP should
be banned.
? - Agree shouldn't use router alert. Not just e2e. Should do it in general. Half of systems with
ipv6 don't support.
Francois - Should drop an email on your concerns.
Yokonara (?) - Think also not only for new applications, should extend to older applications also.
Francois - We are saying in controlled environments could use e2e.
Yokonara (?) - What are e2e - there's not anything using.
Tony - No, there is - there's much RSVP TE using. Much more than enterprise. It's closed in.
Magnus - Yes, inside an AS it does exist.
Francois - That's what we are saying. Can use it today.
Tony - If give up on router alert, then throwing out many signaling protocols.
Magnus - Think if can not use this, we do need the capability and a new way to do.

Presented 2nd document (Narayanan)
Investigates how could support and requirements for what would be needed.
Proposes a solution which think is backward compatible.
Next steps are to add the enhancement for the RAO flag.
Kireeti - What are we trying to do here? I think we should just kill RAO.
RA means every router on the path should process, but now we are saying some
should and some not?
Francois - I think it would be useful if want a solution then we should have a flag.
? - 
Kireeti - From the point of DOS attacks - can still do. So doesn't help.
Francois - Without the "flag", DOS attacks are still possible as pointed out in the
slides. With the "flag", attacks are prevented.
Kireeti - Need to think about this.
? (nsis co-chair) - I like this.
Dave - We'll find a wg for this. Don't have to decide right now.
? (nsis co-chair) - Belongs in ipv6.
Dave - It's also ipv4.

Default Router and Prefix Advertisement Options for DHCPv6 
----------------------------------------------------------
(Ralph Droms)
Presented slides.
Purpose of this talk is to discuss some considerations in the use of DHCP and
other protocols in device configuration. 

Dave Oran - Another aspect to consider is security.
Ralph - Yes, that's true. Continued presentation.
Dave Oran - There's two aspects of scale. How many devices and how much info need to send.
Dave Thaler - Two aspects to changes. Liveness - which is very dynamic. Policy
changes are not so dynamic.
(Continues presentation)
Would like to ask the community if
believe that using DHCP for this functionality is inappropriate and do we
have an internet architectural issue to solve?
Dave W. - What about information today its passing?
Ralph - There's a difference between IPv4 and IPv6. IPv4 has many options, IPv6 quickly
starting to add.
David Hankins - At the begining of the presenation, saw current work going on. Think
it depends. If for example a default router, then could be appropriate.
Bob Hinden - The general answer is that dhcp is for configuration so for configuration it
is appropriate but for routing which is more dynamic than would be inappropriate.
Ralph - the H is somewhat misleading. Think if a large amount information than probably
should be routing.
Bob Hinden - If configuration knob, something just a bit more than static, it is appropriate.

KMART
-----
(Gregory Lebovitz)
Presented slides.
Tony - Are you trying to address replay attacks?
Greg - Trying to address some interconnection. Can not do all. So yes.
Continued presentation.
Ran - Observation, none of what we have today can provide for replay protection.
We will need new mechanisms. Encourage us not to spend alot of time updating
old mechanisms.
Continued presentation.
In the document, we classify what we need to change. Then we look
at what it would take to add a key management protocol as this will prevent
needing to do frequent key rotation.
Step 1 - clean up what's there. Step 2 - add new mechanisms to improve.
? - Agree should have stronger mechanisms. One thing need to consider for
the last slide, is how to hook to configuration server for key management.
Dave W. - Where will this draft be discussed?
Greg - Will discuss in KMART. The new draft is in the queue
now - draft-lebovitz-kmart-roadmap-01.txt.