IETF-73 Routing Area Open Meeting
=================================

http://rtg.ietf.org

ADs: Ross Callon, Dave Ward

Scribe: Deborah Brungard 

Administriva and Area Status
----------------------------
 
Dave opened.


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

BFD (Dave) - went thru IESG review, new version of mib, still some discussion
on what should be included. WG chairs are not allowing multihop submitted until
others done.

CCAMP (Adrian) – CCAMP has two meetings this time. 2 new rfcs, 3 in editors queue
finally, after difficulty in IESG, 5 ready now for last call. Had an informal
meeting for WSON discussing impairments, alot of work needs to be done in
ITU first before we can begin on protocol aspects.

FORCES (Ross) – protocol spec has been updated in response to various comments
including security. On IESG schedule for December.
 
IDR (Yakov) – accepted two new wg documents and put thru last call and IESG review
all in this interval. Will have some discussion on BGP having standardized default
timers.

ISIS (Dave) – New topic is on passing L2 addresses (related to Trill and 802.1aq).
Will mostly go forward with doing extensions.
 
L1VPN (Adrian) – Last draft now in editor's queue. We haven't done some stuff on
our charter. After the draft completes we will poll the group on continuing or
close.

L3vpn (Marshall) - This afternoon will meet. Solved some issues facing the group.
Have ready now the two solution drafts to put thru last call. A considerations
draft (Morin) we have consensus to adapt. And add as editor Maria. We have some
issues in the considerations draft. Hoping the group is ready now to work and progress.

MANET (Ross) - Still progressing drafts.
 
MPLS (Loa) – We had two meetings this week. One document thru last call, another going
in. Four ready to requeuest publication. Two going into last call. MPLS-TP, hope one
is ready for last call. Preparing now for the upcoming SG15 meeting.
 
OSPF (Rao) – 6 rfcs, 3 on manet ready. 4 ready for wg last call. Some
presentations on work in l3vpn on bgp, also lsa correlation. Some controversy on
algorithm of choice but agreed and a new version already out.

PCE (Adrian) – One new RFC finally out. Quite a few in editors queue as have
normative reference to pcep spec which is having a rough ride thru iesg. We
will now have a non-normative reference to pcep and then come back to what
it takes to make it mandatory to implement when it get's thru iesg. We're
looking at interlayer use of pce.
Dave: To followup about the security issue. We talked to the security ADs
and they agree to write a document clarifying what to do for key chain management.
They also agree to write a document explaining when and why we should use
which security technology.

ROLL (Dave) - they still are working thru their various requirements. Some are
ready for me to review. They are claiming they have wg consensus that none of
the existing routing protocols solve their problem.
So they will be updating their charter to include protocol work.
  
PIM (Stig) – Two RFCs completed since last meeting. One draft passed Last Call.
We discussed PIM (?). Not sure what to do with it, feel it needs some security
review. There might be other routing protocols which we should look at on this
too. We used webex to have a remote presentation this time where the author
could not be present. And had some others joining in too and it worked fine.
Dave: if other groups need can use too.

RPSEC (Dave) - asleep

RTGWG (Alia) - expect a last call on framework documents. Looking for some new work.

SIDR (Sandy) – Could of used some more time as had some contenuous items. One in last
call, though as didn't have all changes, need to do it again. Several documents
very mature and ready for last call.

VRRP (Radia) - two documents. Protocol almost finished. Unified mib almost done as
got modified and need some cleanup. subsecond timer draft went away as got folded
in to other document.



Reduced Backus-Naur Form
----------------------------------
(Adrian Farrel)
First version submitted in March. Had many reviews but would appreciate if others
can review. Believe should be standards track.

Eric: question if we need this document. Thinks it's a waste as one will either
read the BFD and not read this anyway.
Adrian: agree but we had real difficulty getting thru a draft in IESG review
because of this.
Ross: Primary reason is to write it rather than not. 
Eric: my worry is it just becomes another document which need to reference.
Ross: good reason for people to look at and see if we should do it.
Dimitri: 2205 has BNF what is the use here to do this.
Adrian: it interprets.
Dimitri: any change to what we have done?
Adrian: No change.
 

BMP
-------------------
(John Scudder)
Presented slides.
BGP Monitoring (BMP) being done in GROW. Response to a request of people
to have a way for a monitoring station to get a complete dump of the routes
received from a router.
First had done a draft in 2005, was too hard and set aside. There's now renewed
interest. We can't use BGP as BGP only gives the active routes on a router,
not all the routes. We've developed this draft on it which progressing.
It's not a routing protocol but looks alike.
Steve: why push rather than pull?
John: convient to have communication one-way. I guess who initiates connection
doesn't really matter. Just want unidirectional communication so router can be 
lazy.
Jeff: Could use Mib also on this.
John: Yes - good.


RAO considered dangerous
-------------------------
(Ashok Narayanan)
IP Router-Alert Considerations and Usage
Presented slides.
There is perception that IP Router-Alert is a security threat. Some routers
don't need to process these packets and that's a high cost on these routers.
So some networks drop it at the edge. And protocols using IP RAO are considered
dangerous. Want to look at when should use it and have some
proposals to discuss.

Dave: We wrote this for the transport area.
Magnus: I understand the concerns. We only did it for the one item. It is good to get
this additional information. One question on including ipv6.
Tony: We've had discussion on the list, I really disagree with all your
recommendations. IETF should not tell router vendors how to do their implementations.
Dave: The draft is directed to protocol designers what could happen. It doesn't tell
you what should be done.
Tony: But this is a packet network. So anything can happen. Raising the awareness
is fine. BUt there is no reason why not use RAO.
Dave: But it's very difficult to do an end-to-end service thru a network with it,
we tried to explain in the draft when and how it could be used.
Ashok: Maybe I wasn't clear at first. This is directed to be a BCP not standard.
Chris: agree with Tony. Should be clear it's for the vendor to implement. Yes, if
it's more than the vendor network, it is dangerous. I'm concerned to ban all uses.
Ashok: What about for end-to-end applications? Do you feel it should not be banned?
Magnus: I don't think those are the only alternatives. Could do tunneling.
Eric: This reminds me of other things have done over the years. Can't believe people
would want to do this.
Dave: We've had to put alot of discusses on documents because of this. Spending alot
of time on explaining how routing works so we put this document in.
Eric: There's nothing new though here.
Ross: As ADs we need to figure out the mailing list to put this on. Another question
is how much do we want to have in this document. It's useful so when someone in
another area does something which does RAs all over the world and we put a discuss in,
we can refer to. Is there anything in the document which changes RAs as currently
defined?
Ashok: If want we could remove the appendix on the extensions.
John: as long as the document is non-normative, I don't have a problem with it. I think
should be non-normative.
Dave: The router implementation BCP gives very poor wording on this.
John: To the extent that this is then an answer to IESG concerns, then I don't have a
problem.
Dave: We wanted to educate that people don't want to use up cycles on their routers for
this.
Magnus: Because the specification was unclear is why these interpretations have been
made in the other areas.
Ashok: 2113 is just too flexible and allows too many options. So we thought to do this.
John: 2113 does lack on clarity. Not against doing a bis. should then do a bis.

Open Mike
---------
Jeff: I went to the OPS group to discuss our issues with them. We've going back and
forth with them on the MIB. They now will change to try and do things simpler instead
of in MIBs. Then people doing MIBs will have an easier time of it.
Ron Bonica (as OPS AD): We apologize if we have been difficult. Maybe the next time
you work on a big MIB, we should do it together from the beginning.