Last Modified: 2005-03-01
|
Routing Area Meeting - IETF 62
These minutes were taken by Alia Atlas and edited by Bill Fenner Announcements ============= IDMR closed; multicast traceroute & DVMRP moved to individual drafts PCE approved as a WG Bill is still a Routing AD WG Status ========= BFD(Jeff): Running a bit late; base draft just undergone some revisions. Some state machine problems have been found and being resolved; base mechanisms looking pretty well defined. Some discussion on including more stuff into the protocol - but WG is planning to hold firm & keep protocol simple. Hopefully be last calling the base draft soon. Security mechanisms require some input from security groups - and haven't heard anything. CCAMP (Adrian Farrell): 1 new RFC; a lot of drafts just about through last call. There a few drafts to clean up before ready to re-charter. Been doing some work with ITU to try to relate GMPLS terms and concepts to ASON ones; that's showing some quite good cooperation. FORCES: IDR (Yakhov Rekhter): Base spec is on RFC Editor queue. Extended communities has some IESG comments, hopefully to be resolved in reasonable time frame. 5-6 more drafts awaiting AD & IESG review. WG reduced to discussing implementations. ISIS (Chris): No agenda posted; just an update on doc status. There'll be a presentation of Ward et. al's draft on endpoints. Chris will do a short presentation on a draft to add for BFD to handle fate-sharing. WG last called 4 drafts - admin-tags, attributes, etc. Initial MIB doctor review with many comments. MANET (Joe): Rechartered & had first successful meeting post-recharter. Have a -00 draft for dynamic on-demand routing, with other follow on drafts expected in about 6 weeks or so. There was an autoconf BOF; the good news is that it got out of routing. There'll be a joint OSPF/MANET design team meeting tomorrow. MPLS (George Swallow): Main thing being worked on is p2mp; there are 3 drafts on that. There are some on OAM. There's also one on fast-reroute, that may be referred back to rtgwg. Bunch of RFCs waiting to be published, including RSVP-TE Fast-Reroute draft; it's only been 7 years since I wrote the first draft; good to see we can get stuff done. OSPF (Acee Lindem): Most of the drafts that were in progress when I took over are being finished or in RFC Editor queue. There's the OSPFv2 MIB and the OSPF Scaling Recommendations; have subset that everyone agrees on, but hard b/c borders on implementations. OSPFv3 MIB is sort of waiting until OSPFv2 MIB is done. OSPFv3 TE close to WG last call. OSPFv3 Auth is in 2nd WG last call. OSPF capabilities needs an author discussion; it did go to last call. Bill Fenner: I did review the OSPFv2 MIB & MIB Dr comments and checked that they were all fixed. It needs a new MIB Dr review or confirmation it's ok. There's invisible progress being made. Acee: Good. New Work for the OSPFv2 MTR close to last call, with agreement to reuse the ToS field. OSPF Wireless DT progressing towards consensus on flooding. Future OSPF Extension needs WG discussion; we're at a crossroads for deciding what we're going to do for extending the protocol up through the 21st century. OSPFv3 Update needs good review. Graceful restart needs more discussion as to what should be documented. OSPFv3 AF will proceed. IANA draft needs to proceed. Bill Fenner: It's good to get the IANA draft along. Otherwise, someone has to decide what happens to the number space. If we have to decide after the fact, it tends to slow things down a lot. PCE (JP Vasseur): Met for first time today. Have a PCE Architecture draft. Also, DT to work on protocol & requirements; have draft discussing requirements. PIM (Tom) : Dense mode has reached Experimental RFC status. Sparse mode draft is out of WG hands & now in AD & IESG hands; hope to see some movement as a proposed standard. Adopted a few drafts dealing with PIM encoding; most interesting is on dealing with PIM refresh reduction. There was a request from the L3VPN last time to handle this. A DT was formed & has some ideas primarily dealing with Join/Prune. There's renewed progress on the PIM MIB draft after not much for a few years. RPSEC (Alex Zinin): Finished with the general routing security analysis; working on general routing security requirements. Russ White: Blaine just published new IDR requirements draft. Already accepted attack tree as a WG draft. Been waiting on the IDR reqs to do more. Also expecting some IGP stuff. RTGWG (Alex Zinin): Base IPFRR draft is reaching solid state. Hope to have a micro-loop mechanism recommended pretty soon. Work going on on advanced micro-loop prevention and FRR mechanisms. GTSM expected for next mtg. SSM (Bill Fenner): Not much going on. Architecture draft needs minor updates then IETF Last Call. VRRP (Mukesh Gupta): Submitted implementation report 3 weeks back. Once that shows up, then Alex promised he will review it. MIB is in WG last call; received some comments, but mostly editorial. Sub-second draft also received a comment; making progress. =================== GMPLS change process (Loa Andersson): Continue discussion we had in DC on draft-andersson-rtg-gmpls-change-01, a routing area draft. This process is kind of simple; it describes what the IETF does and how it actually produces a standard - or the piece of it that is relevant to the MPLS & GMPLS technologies. The reason we wrote this document (authors are ADs, the CCAMP WG chairs, etc) is to manage what we have in MPLS/GMPLS so that in 10 years we still have a technology that is coherent and compatible. The root problem is quite nice; it's popularity. Have new version of draft from last time; updated pretty much based on input from two sources; one is discussions on different IETF mailing list & also liaisons from ITU study groups 14/15. I just learned the ITU is going to come up with a more consolidated response next week; group is called TTSAG. Then we hope we'll have at least this round all the input. ITU SGs have already come up with a number of concerns. Concern 1: Process appears to override the Liaison Statement process Addressed: impression may be because the change process has slightly larger scope. Have put clarification into doc. Concern 2: If all ITU contributions needs to be IDs & then ITU finds it is hard to get a review of what's going on in the IETF; there are people in the ITU who aren't in the IETF. The change process describes in part how the IETF works; If there's a need for the ITU to have a more frequent communication, then the liaison mechanisms are still there; there's an obligation to respond within a certain period. Concern 3: Not considering a ITU-T consensus, all work is IDs. True, work starts as IDs in the IETF. If there is a need for any organization that has a liaison relationship with us, there's always a possibility to do communication through this process & find out what's going on. There are agreements (see RFC3056 and "ITU-T A-Series of Recommendations Supplement 3"). It actually says what is said in the draft; what work is done here is via internet-drafts & that must be done via internet-drafts. ITU can appoint a point person to come here and give the view of the ITU, but when we start working on that, it must be in an internet-draft. Concern 4: It's hard to predict the reaction of IETF ( I think this is true), but in this case, what I don't want to do is spend a lot of energy to write an ID and then get NAKed when it comes it. Again, the change process describes how the IETF works. We created something that Bill calls "the preliminary process". There is a possibility for the ITU to actually give us a hint on what they want to do and have a response on that interaction, as if we'd had an ID with this content. It opens up a possibility to be rather quick with the turn-around. Bill Fenner: There's actually one other point, which I didn't know until I read the RFC earlier. They are allowed to submit an ID saying see the referred document. That's an established process between them and us, so there can be 0-overhead in this process. Loa: Ok. Then that's fine. Then the ITU can write an ID (well anyone can try, but the ITU can succeed). It's only when we get into this stuff that it needs to come into an ID and the URL isn't sufficient. Concern 5: Adrian found 6 concerns; I found 5 (and then 4) and then Bill said there must be 5, b/c that's what you liaisoned. The last concern is that the change process could be time-consuming & it is open up for malicious attacks. Someone could actually delay by feed-back into this process over and over again. We don't think it's that way, but we need to test it. There are also no deadlines; this is true, but the goal is to describe what we need to do so we can do it as quickly as possible. Once we understand that, it is easy to use the liaison process to say in ref to the work you're doing, we need a response within a certain time. Then we can say yes for this part and maybe not for that. Next steps will be more info from ITU. After that, we will start work and include the info from that into the process as much as we think we need to. We're inviting discussion on the routing-discussion@ietf.org; take those concerns to the list. The intent here is to create consensus - not only here but that flows into the agreement that we have in the liaison statement process we have with the ITU on how we do this in as standard a fashion as possible. Questions? Acee Lindem: This is getting some much focus is b/c this started for MPLS & GMPLS, this could be applied to any liaisoning between IETF & ITU? Loa Andersson: There are a couple openings in the draft. This is for the MPLS and GMPLS and the study groups in the ITU that more or less works on the same topic. Idea is to open up an incoming channel from the ITU into the IETF on new topics, so we can do the work here. The draft mentioned a couple other WGs that will be affected by the process, which are more or less the old sub-IP WGs. Other than that, I don't see, unless a WG in the routing area has the intention and wants to be included, then it could be. That's not the intention really. Don Fedyk: What's the next step? Are you waiting for the liaison from the ITU? Loa Andersson: One thing - you reminded me. They actually sent yet another liaison to the ITU today; it's actually an updated version, so the SSTAG can discuss it and in parallel we'll have the same discussion on the routing-discuss mailing list. Did that answer the question? Don Fedyk: Are you waiting for someone from the ITU to come here or are you just waiting for a liaison statement... Bill Fenner: In my opinion, things work a lot better when we have people participating together rather than doing the formal back-and-forth rather than having a discussion. We want the discussion to happen in the routing-discuss so that everyone sees the same discussion. That's also the spirit of the RFC that we keep mentioning; a lot of the work is done and the best Steve Trowbridge: After SG 14/15 provided the concerns, we came up with the list of concerns and suggestions for how those might be resolved. I think about 1 1/2 of the things on the list that have been rolled in and some of the ways that Adrian suggested still aren't in the draft. Next week, there's a chance to come up with a unified response. Bill Fenner: Right. I did the revisions & thought that I'd done about 3 of the concerns. The revision happened fairly quickly and some of the other ones required discussion; that's why I didn't make a change just to make a change. I think they need more discussion. It's my responsibility to start the discussion on the mailing list about these are the things I didn't change and here's why. Alex Zinin: Do those of you who've been participating from the ITU side have an opinion on whether what Loa said made sense? Don Fedyk: I think we have a delay now b/c people are trying to process the liaisons and the changes. Loa: First, I got a mail from Steve saying how do you want to respond. I said, oh you've the mtg the week after IETF; we can go for that. Then we got SG 14's comments & they were good. On the issue of people speaking up here, I know that people can speak for themselves, if not the ITU, here. Otherwise, we're working to create consensus & willing to take whatever action within reason to make it happen. Steve Trowbridge: The type of negotiation for whether work will go to ID and RFCs requires the liaisoning to occur. The ITU is much more meeting based and needs response. There's concern that the ITU could only communicate via ID, but couldn't just send a doc over for comment. Bill Fenner: Right. That wasn't intended to delay the progress; we always think in terms of IDs. Don Fedyk: Is there any intent to track a doc under this? I think the intention of the draft is fairly good - but it's all in the execution. But how do you tell without tracking? Bill Fenner: I think the WG chairs will hopefully be motivated to see the process work once it gets invoked. Alex Zinin: I think we will try to use the processes that already work within the IETF to provide timely communication. I doubt that we're going to create another process or tracker just for the IETF/ITU liaison interaction. Loa Andersson: How many WG chairs are here? (several hands) How much of your work as a WG chair is actually correcting documents? (very very few hands) Most is keeping track of drafts. We have the ID tracker - but that only works when it is submitted to the IESG. Now we have another tracker to apply to each WG. We are creating tracking tools for people who track IDs for a long time; it's nothing new. The process here actually describes more or less how we work. The only thing that hasn't been explicit earlier has been that, ok, if you want to change anything within this technology, you have to come with requirements. Alex: Don could you explain what you're looking for? Don: Well, for instance, UNI was a contentious issue & you couldn't speak that here. Eventually, people decided UNIs could be necessary & could be discussed again. I don't see anything in this draft to make this sort of thing easier or harder. Does this really change anything? It may be an education for those outside? Alex: I think you're trying to find an answer, but I don't know what you're looking for. Can you describe it? Don: I'm not really sure, but from reading this doc, I'm not sure it solves a problem. Alex: Do you expect the core-IETF process (consensus-based, etc.) to change? Don: No, I don't. But there is a perception from some people that a requirement coming from an SDO should be considered. Bill: I think the way to get a response in a time frame is a liaison. If an ID is submitted & is discussed on a mailing list & it doesn't seem to terminate or resolve clearly, then you send a liaison asking what the results of the mailing list discussion was. Then the WG chairs determine that. There is a process to get the response back to the organization that requested it. I know that's not exactly your point. Adrian: I think I heard two concerns. One, what happens if a set of reqs are brought and the IETF doesn't believe that those reqs are real to the IETF. Second, what happens if the IETF process, willfully or via negligence, fumbles. The first case I think is handled gracefully in this document. In the case of the fumbling, the possibility is clear but there's no mechanism related to the responsibility. Don: Yes, I think you've captured the points. Some would disagree that it's a dead-end if IETF doesn't agree with the req. It's hard to do hypothetical Alex: I think I heard that you want to give ITU reqs different priority through the IETF. Don: Well, there's a group of people that build standards and they came to an agreement on it. That's what I've heard; I can see both points. Alex: The question is should we give different docs from different organizations different priorities in a consensus-based organization. If anyone is interested in that, they should bring it up at the plenary. In this forum, we operate on the assumption that consensus, WG consensus & within the community is what's important. Tony Li: I think that the IETF should consider reqs from the ITU just as any others. I also think that the ITU can react just as an individual contributor & throw a hissy fit. If there's not a doc being move along, then I think the ITU has the responsibility to go throw a hissy fit at the WG chair, just as any ID author does. This is part of the basic process & how we get things done. You can argue that the IETF doesn't do well enough tracking - which is true, but the ITU is getting the same treatment as everyone else. Steve: Usually if another SDO has come to an agreement on reqs, that means the reqs are valid in that SDO's context. If it doesn't fit in the IETF's context, then the IETF can respond with a liaison and advice. The main difference is that another SDO has other options on what it can do if the IETF doesn't want to be involved or work on something. It doesn't mean the IETF has to do something the ITU says; of course not, but they're owned a response. Scott Brim: Tony says a doc from outside should have the same status as any other doc, except that in this case, the doc isn't from one individual. The several hundred people can't come to the WGs, join mailing lists. It shouldn't be given just the same consideration. Alex: The members of the SDO need to talk to the WG & persuade them that this is the right thing to do. I see no other way to do this & maintain the consensus-based organization. Scott: Can they say they speak for 200 people? Alex: Can I do that? No. Let's take this discussion to the plenary, b/c I want this to happen there. Adrian: The number of people doesn't matter; what matters is the WG chairs' judgment of the consensus. Why do we have WG chairs? Alex: I'm questioning that we're judging the consensus within the WG or IETF community, not adding virtual people from other SDOs. Adrian: Scott said that we can't expect people to turn up at mtgs, but we don't expect that here either. We expect mailing list participation. Alex: We're all reasonable people. If an idea has merit, it will gain some support.... Loa: When we get some communication from the ITU, we know it has some approval, we know where to go to to ask the right questions. When we get an -00 draft, we have to sit down, read the draft, and figure out what the problem is. With the ITU, we can invite someone to come and present. When we do consensus, we don't count numbers. Once WG chairs or ADs lose the ability to judge where the consensus is, then they're done. Steve: I'm not sure you want 200 people to stand up whenever they hear something they want to support or to chime in on the mailing list. We're trying to distill down the discussion. What strikes me as a little bit odd is to pretend that that distillation and consensus-building hasn't happened. We're letting you work more efficiently by distilling down a unified answer and then letting you decided whether to work on it. Bill Fenner: I think that Adrian's point was that the WG chair can consider the consensus of the other SDO as well... The WG chair should be taking into account of the SDO. Steve: That sounds great. Is it possible to put a sentence like that in the draft? Alex: Let's take this discussion about judging the consensus and taking other organizations into account to the plenary. This is very important. The intent of the draft is not to change. Mike Rowscowski: A simple question. Who owns the technology? If it's published as an RFC. The ITU charges for standards. We don't. Bill Fenner: Certainly to be on the standards track, the IETF has to own the technology. There's this IETF/ITU RFC cooperation that we keep talking about which allows a doc to be simultaneously published, but if it is an RFC on the standards track, then the IETF has editorial control. Jon Sadler: Two data points. There's not an interest in having the ITU come and stomp on things, so much as that when the ITU comes in, that the work is given consideration. Also, the liaison between ITU and ISO allows the ITU to fast-track things there. One thing in the ASON architecture is support for hierarchical routing; when it's been brought to what is the interest, the interest isn't there. This is probably due to the fact that the scale & scope of the networks operated by the transport as opposed to the IP networks is different. Does that mean the IETF should say "no, that isn't interesting work". I don't think so. Eric Rosen: We've spent a long time discussing what can be summarized as "the ITU wants special treatment and we can't give it to them". Scott Brim: Except that we can give it to them; we just don't want to. The question is can we find a way to that keeps the IETF intact? ================================== Routing Area Direction ====================== Alex: This part of the discussion today is to try and step back from the day-to-day and consider whether we're spending time where we should be. Major work "currents": explicitly routed traffic-engineering, fast-reroute, graceful restart, IPv6/AF, VPN-related technology, multi-topology This is a quick summary, so I may have forgotten something, like MIBs. RTG Area Plans: BGP security & L1 VPNs (hope to put in CCAMP or new WG, depending on which way we go) Here are the main questions for discussion: Are we spending our cycles on the right tasks? Covering the most important areas? Do we lack something obvious? Do we have the right processes? If you have some thoughts - anything, as to how we're doing as an area in the IETF, please come up. ??: I don't think it's something specific to routing, it's related to other areas, but it's the autoconf. The main thing that we tend to gloss over is that the addressing architecture has an effect on the routing arch and vice versa. I think it's important that the routing area keeps up on it. Alex: We had this autoconf BOF about automatically configuring addresses in MANET networks; there's definitely interactions. Dimitri: There's one point, which is the MPLS-GMPLS migration. Alex: Last night, there was a discussion about this. We're going to be putting it into the revised charter for CCAMP. Dimitri: In ref to the process, would it be possible to say "now is the time to have this draft as a WG item" To be sure this is the correct protocol Alex: If I understand, it is so difficult to add a new item to the charter that we're not in time. Dmitri: Would like to have doc added to draft and have chance to challenge/change the protocol & not so close to WG last call. Alex: So, bring the work to the WG early so that it is flexible, but late enough to have right scope. The fact that something isn't on the charter doesn't mean that you shouldn't be working with the authors and bringing things to consensus. Tony Li: I'd like to pick up on the BGP security. We've been chasing this for about 10 years. There was a recent paper that said doing this properly would only take a few super-computers. We have several other proposals that were admittedly half-measures, but provided some benefits. I would strongly suggest that we consider doing something that is a pragmatic half-measure. Alex: Here's where we are. RPSec's been having a good discussion on the terms. Hopefully the WG will agree on something. If there is not enough progress there, then we do have the back-up plan and we're not going to wait forever. We wanted to actually do this last year, but we started to see some progress on rpsec, so we wanted to push it a bit further. Tony Li: I've been watching for the last 10 years and haven't seen much difference. Yakhov: In order to answer the first question, who is to determine what tasks? Alex: The reason I like the IETF so much is b/c even in the lack of objective criteria, we can still form consensus based on subjective opinions. Yakhov: I make my determinations based on dollars. JP: Well, I agree with Yakhov. no just a joke, actually. I don't have anything to add... Dmitri: Question is related to the work on the pseudo-wire signaling going on today. Who's going to review whatever they come up with? Alex: LDP would go to MPLS. RSVP would go to CCAMP. The right answer is that enough community review should happen. |