2.5.10 Routing Area Meeting (rtgarea)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-07


Bill Fenner <fenner@research.att.com>

Routing Area Director(s):

Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>

Routing Area Advisor:

Bill Fenner <fenner@research.att.com>

Mailing Lists:

General Discussion:
To Subscribe:

Description of Working Group:

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

RTG AREA meeting - IETF 61

These minutes were reported by Bill Fenner, based upon notes kindly taken by Dimitri Papadimitriou.


Agenda bashing, Administrivia (ADs) [5m]
Announcements (ADs) [5m]
WG reports (ADs/chairs) [15m]
Area plans/milestones (ADs) [10m]
O&M section in RTG Area Drafts (Adrian) [30m]
(G)MPLS change process procedures (Loa) [30m]
Open mike


WG reports (ADs/chairs) [15m]

BFD WG -> no report

- The base spec is waiting to get some security details finish.
- MIB document dependent on the base spec.
- "BFD for MPLS LSPs" doc has to pass cross-WG review

CCAMP WG -> A.Farrel

- 2 RFCs GMPLS Architecture (RFC 3945) and GMPLS for SONET/SDH (RFC 3946)
- Ready to recharter
- MIBs almost done
- Still some work with no milestones attached

IDMR WG -> B.Fenner

- same state as previous meeting, so we plan to shut down the WG like other unproductive groups; the remaining documents will be reclassified as individual contributions.

IDR WG -> Y.Rekhter

- The BGP package is nearly ready; Sue can answer whether all the documents are ready (later found that they were rejected due to boilerplate and they were resubmitted immediately after the meeting so all is well).
- There are several other IDR documents under discussion waiting for two or one valid implementation
- There was a brief discussion about how to meet the RFC 1264 requirements; it's clear that two interoperable implementations is more objective and that's what the IDR WG chairs have decided upon. The ADs were reminded again of the plan of revising RFC 1264.

ISIS WG -> Chris Hopps

- New revision of the MIB - not a lot of function changes with only one issue remaining
- IPv6 draft resurrected and needs to get some implementations - contact Chris
- No other major progress
- Current MT draft does describe exact implementation so needs to be checked


- Working on recharter; pretty close
- Lot of ideas on working items
- Simplified multicast forwarding (get more experience of what people do first)

MPLS WG -> L.Andersson

We have two large work items:
- OAM: requirements + framework (looks pretty)
- P2MP: start discussion with the other multicast-related WG in order to organize the work amount the different working groups P2MP Design Team:
- first version to be send as WG ID
- some requirements are not yet solved to be solved in a couple of month

Other items:
- LDP: coming to Draft Standard but we need responses from the operators on the survey in terms of deployment to know which features are being used.
- We've pulled the bundling draft from the editor queue, since it turns out that it needs a re-spin.

OSPF WG -> A.Lindem

- Detecting inactive neighbors has been approved
- OSPFv3 MT: not taking the TOS based metric field proposal as for OSPFv2; instead OSPFv3 is using a TLV as for IS-IS
- Wireless design team - proper balance to avoid inventing new protocol

PIM WG -> B.Fenner

- PIM Dense mode is done
- PIM Sparse mode has been submitted to the area directors

- couple of potential new items:
one related to L3VPN related to state refresh reduction due to periodic messages - wasteful if we have 10000 of these messages
- some work has been done like RFC 2961 but it didn't go anywhere

- PIM spec needs RFC1264 standardization documentation - so the chairs are looking for implementations to report.

RPSEC WG -> R.White

- The base spec has been submitted (march time frame)
- Generic requirements document seems stalled
- OSPF document is on hold before others are reviewed
- Latest version of the BGP requirements to be presented this time
-> full mailing list discussion
- Generic spec not yet submitted - needs additional work

RTGWG WG -> A.Zinin

- Revision of the GTSM spec for the standard track
- Dave to submit revision and comments
- IPFRR base spec close to be ready for the IESG
- IPFRR DT for microloop prevention has been created - the issue to be solved is to be able to provide service without failure of more than 10ms.
- WG going to meet during this week


- Comments from the IESG on the ssm-arch draft to be addressed by the document authors

VRRP WG -> R.Perlman

No meeting since there aren't any burning issues

- VRRPv3 IPv6 is nearly done and is going to be submitted to the ADs
- Decided upon one MIB for both v4 and v6; there's a draft but it missed the deadline so you'll see it soon.
- New work on sub-second timers is waiting for a draft to be submitted.


O&M section in RTG Area Drafts (Adrian) [30m]

o) Issues to be addressed:

- Manageability is often omitted from initial specifications
. Often not in requirements, architecture or solutions
- Requires retrofitting
. Sub-optimal development process
. Sub-optimal solutions
- Need to ensure that manageability is considered at all stages of the process
. Issue applies across the whole Routing Area

o) Proposal: All new Routing Area Internet-Drafts include a
"Manageability Considerations" section.

o) Current status of the document

- Initial stake in the ground
. Describes issues
. Outlines solution
. High-level suggestions of information to include
. Information and data models, e.g. MIB module
. Liveness Detection and Monitoring
. Verifying Correct Operation
. Requirements on Other Protocols and Functional Components
. Impact on Network Operation
- No details
- Open for discussion and input

o) Questions and Next steps

- Questions
. Is this something we want to pursue?
. Should we replace "Manageability" with "Operations and Management (O&M)"?
. What other subsections should be listed?
. Should this be wider than the Routing Area?

- Next Steps
. Fill in details
. Contributions welcome
. Liaise with O&M ADs


- Chris Hopps: shouldn't O&M work on requirements (instead of routing)? like IANA section is for IANA?
- Adrian Farrel: if this is something that the routing Area wants to achieve we have to drive it
- Chris: does this mean that O&M does not need / want to have this
- Alex Zinin: it doesn't strictly matter where it starts ... if we are interested we can drive, as it is OAM for protocols there is a co-responsibility - so the co-operation is key
- Avri: I would like to see a manageability section in each area, here I got the feeling with the GROW WG discussions that by looking at the management of the network that it does not seem to be sufficient enough to address current problems so we have to work with the O&M to solve these issues
- Chris: suggesting that another group to provide the requirements for writing this section
- Bill Fenner: I'm not sure that the presence of the section will actually make people think about the problem.
- Adrian: But absence of the section encourages to not think about it
- Bill: It's been difficult to educate the community on what is desired in the security considerations section; this has resulted in a tutorial and some RFCs on how to write them. This kind of support may also be required before we start getting good operational considerations sections.
- Adrian: this draft uses some guidelines with an rfc as an example
- and the condition of having "no operational considerations" may be to explain *why* there aren't any.
- Mark Handley: It's good idea but we have to think about the practice - normally, protocol specs try to be implementation independent; this may accidentally create a dependency
- Adrian: take is as a voluntary section
- Russ White: - a management section makes sense to me, since it may make people think about what needs to happen
- Alex: expressing concerns: first looking at the issue with the security section is not sufficiently good so need someone to bring them here - do we have enough people to cover all these issues ? other concern (but more theoretical) the way we operate at IETF - before three steps: we implement, get operational experience and then evolve however in this case we are going to predict what effect this or that technology is going to impact - so this is going to change the way we manage the IETF process or would constrain it
- Richard: good idea - but want to be incubation period into the working groups that are interested, for instance the CCAMP WG can be interested to be incubated
- Arian: need to be prototyped
- Richard: and then see what happened from vendors ... let's say in a period 6 months we can then evaluate
- Adrian: 6 months is too short ... and then probably through it out
- Kireeti: good idea for a draft standard not a proposed standard
- Bill: same problem sometimes shorter to provide such considerations during the write up instead of addressing at the end of the process
- Kireeti: Implement first and deploy (and so manage) after this is how the current process works - so this against our operational mode
- Alex: DS and PS (per RFC 1264) already states need to document the operational experience
- Dave: This is a good idea, but could potentially be a palliative for some of the robustness issues of the protocols specifications itself
- Adrian: need for a separate section because not addressed in other documents - mpls oam for instance is a good example
- Acee: Such a section does not need to have all details, but some of the requirements - I would not want to have everybody defining all the MIB variables, for example.
- Kireeti: What do you mean by management? Referring to with MPLS OAM, taking as example LSP Ping or Y.1711, this is not management - so before we go a step beyond we have to state what it is
- Adrian: This is the point of the document
- Scott: Agrees OAM does not mean management
- Adrian: Choice of Manageability vs Operation and Management for the name of this section
- Sharon Chisholm: Speaking as someone who works mainly in the management area, think that all document should have a manageability section, since it's always good for people to think about
- Alex: in general to think about O&M it is a good but have concerns on the specifics with this sort of document, so it might be useful for going to draft standard, for example.
- Scott: we may want to delay considerations on that since they may become obsolete


(G)MPLS change process procedures (Loa) [30m]

o) Background:
- Scott three years ago suggested to have a change process for the SUB-IP area and then the area went away
- However, the CCAMP working group don't have the all the work item in the working group ... and the problem remains

o) Status of the document:

- old draft that was discussed on the MPLS mailing list from ADs and co-chairs at that time
- the current drafts is available at <http://www.tla-group.com/> however it dot not make the cutoff
- received outstanding comments and will be updated shortly
- Is it (G)MPLS only ? -> protocols/technology specific per CCAMP and MPLS WG

o) Issues to be addressed

- defined process for changing (G)MPLS protocols
. interoperability
. make the process known to other parties
- basic idea: existing ietf process: requirements -> wg charter
-> solution -> standard
the only extra thing is the entry point to if we want to do or not in the IETF
- applicability: is it specific to the protocols developed by the MPLS and CCAMP working groups or would be possible to run this within the whole RTG Area

o) Questions and Next Steps

- Questions:
. do we need this ?
. should this be (G)MPLS only

- Next steps:
. fill in the details


- Scott: Follows a similar process than for SIP but here for the MPLS working group to be sure to not have changes being performed outside the IETF - and so avoid case where this is not an IETF protocol and then call something like MPLS or GMPLS - so this is an important thing to do for the future to be able say this is what to have to be GMPLS - an incomplete understanding of the protocols can lead to interoperability problems, etc ... so this also forces people to come to the IETF and ask - if you want to do it we will have probably to tell how to do it
- Kireeti: This is an important thing to do - important to bring people to the IETF but not important to detail the process we have - as the requirements come before or after - the details are not important, the important is thing is to have the review be made by the IETF - points to the example of RSVP with IANA considerations section -
- Loa: Needs someone to bring the details on IANA section
- Scott: These requirements were meant to say: "folks, this what we want to see you do," but they were not understanding so we need a set of requirement that we are going to meet
- Alex: I question the rationale anytime requirements and framework document (I don't want every draft to have to be accompanied by a requirement document) - but I do see Scott's point, so we have to see depending on the source of the proposal and have various procedures
- Loa: Starting with requirements and then assign the work within the charter - it may stop us depending on whether we want to do this or nor
- Scott: I agree and this applies for folks coming from the outside world that do not understand (but this is not for them but for us to be addressed)
- Russ: The WG has the right to ask for requirements
- George: We need to find what people want to solve - hard to do when we are presented with a mechanism without understanding how to solve the problem - example code-points that do nearly the same thing so then need another document to write how they work together
- Chris: the WG should decide
- George: Any liaison should have a crisp requirement section that describes what is the problem to be solved.



o) Creation of the WG for security for inter-domain routing

We are not yet there but do not have to have a BoF to create the WG, we need a discussion with the RPSEC WG chairs and understand where the requirements document is.



No topics.


Requirements for Manageability Sections in Routing Area Drafts
A process to change protocol specification in the (G)MPLS area