IETF-75 RTG Working Group Minutes
Wednesday, July 29, 2009.
1. Agenda, administrivia and document status
- No comments on agenda
John Scudder: For future WG meetings we will implement a no draft, no agenda slot rule.
John Scudder: Is this a routing area WG item or PIM WG item? From what I have seen this is a PIM item.
Dimitri Papadimitriou: It's slightly complicated. FRR started here. So it might be worth starting this here.
John Scudder: The FRR items in this WG are either frameworks that do not apply to a specific protocol or LFA that requires no protocol extensions. Anything that is specific to a protocol should be in the relevant WG. Right now this looks like the PIM WG.
Ross Callon: I agree with John this looks like a PIM WG item. Also, in unicast either a packet loops or gets delivered, it does not do both. In multicast it's possible for a packet to loop and get to some destinations. That could be disruptive. We need to make sure this does not happen.
Dimitri Papadimitriou: The loops are more impacting in multicast. We need to document unusual conditions. Moving forward I suggest that the framework is performed here. The PIM protocol specifics can be done in the PIM WG.
John Scudder: That sounds good. How many people have read the draft? [A few response]
Dimitri Papadimitriou: I am surprised. In the PIM WG many more had read the document.
John Scudder: It makes sense to have a framework document and take solutions to PIM. We will take this to the list.
Albert Tim: There are two things to consider. One is the procedures, the things that can be done within the existing protocol specifications. The second are the changes that need to happen. If you can distinguish this it would help the audience.
Dimitri Papadimitriou: Yes. I will make this clear in the framework document.
John Scudder: Please also divide the FRR and control-plane failure (grace-full restart) in the document.
3. IP Fast Reroute Using Tunnel-AT
John Scudder: What’s your intention, with the draft?
Mingwei Xu: Maybe an informational draft.
John Scudder: We do not have all the relevant people here due to the MPLS conflict. I suggest we take this offline and discuss how to move forward.
4. Framework and Requirements for MPLS over Composite Link
[Slide 4 - CTG Base
Framework]
Dimitri Papadimitriou: Do you have design constraints?
Dave McDysan: We are documenting the framework and requirements. Design constraints could be specific requirements, such as scaling and interoperability.
John Scudder: Maybe Dimitri is asking "Is there a solution we are trying to back the requirements into?"
Dave McDysan: I do not think there is a detailed solution. We have a set of operational problems that service providers are bringing to the IETF for a solution.
[Slide 5 - CTG
Multiple Routing Instances]
Dimitri Papadimitriou: A clarification, how does the routing instance see the component bundled link, does it see multiple instances and sets up multiple adjacencies on each component link.
Dimitri Papadimitriou: You’re presenting a single logical interface for the routing instance.
Dave McDysan: A link bundle a composite transport group.
[Slide 8 - Single Routing Instance Exterior Functions]
John Scudder: A question regarding the "parameter ranges". Are ranges going to be enough or will you need to specify and signal all the required latencies and bandwidths?
Dave McDysan: Right now we wrote this as a range, the thinking is you can signal the established latency. When you setup the LSP you can consider what latency you have. If your minimum latency is outside your budget you can exclude. If its inside your budget you can signal and see if the composite transport group gives you it. Maybe we need to describe the outcome in more detail.
[General Comment]
Dimitri Papadimitriou: You are specifying a lot of requirements. What is the minimum functionality that you would require to make this solution useful for you?
Dave McDysan: That’s a fair question. We are presenting the problem. We think the TE is the priority, single routing instance only and RSVP-TE sing instance. There is reusable work for multi-instance. Multi-layer is also important too.
Lou Berger: I like the discussion and you response. My previous discussions were trying to find out what are the functional behavior requirements in order to address your issues. More than what are the requirements for your solution. The document discusses everything and embodies the solution as a CTG. As opposed to stating the fundamental problems and requirements of those problems, what functions do you need? The document discuss these problems as an aggregate solution, is it possible to address your requirements using multiple solutions? Or do you have to have a single unified solution?
Dave McDysan: We are going to change the name and we will refer to "a solution", rather than, "the solution.
Lou Berger: Can you refer back a few slides [Slide 4]. It seems you have a single block [green CTG block] that is going to solve all these things. Do you really want a single block to solve all these things or can you have multiple blocks to solve these problems.
Dave McDysan: Maybe this is a source for confusion. CTG is a much more generalized definition. The green block could be an RSVP-TE control plane and an LDP control plane and they would operate separately but there would be a need to show how these operate jointly over a composite link. We could serialize the solutions; I think that would be ok.
Lou Berger: I would say that the separate mechanisms would work nicely together. I am not sure how multiple instances would work over a composite link. I understand how this works from a vendor standpoint, I am not sure how this works from a standards perspective.
Dave McDysan: We try to sanitize the details. We want to keep these scenarios in single draft so people can consider the scenarios.
Lou Berger: I am not saying a single solution is the wrong way. I just think the work should be open to solving the problem with multiple solutions.
Dave McDysan: I do not think this is the intent. We rewrote text to avoid this. If you can specify text or highlighted words that need replacing it would be useful.
Lou Berger: I am happy to work with you offline.
Lucy Yong: The single CTG block described here, you feel like these scopes the solution?
Lou Berger: Yes.
Dave McDysan: We could call this requirement set (CTG).
John Scudder: I think that this would have been less contentious if you instead of having one CTG block you had an RSVP-TE block, LDP block, IGPO block, etc.
Dave McDysan: The requirements may need to be parsed out; there are RSVP-TE and LDP requirements.
Lou Berger: The CTG block may or may not be specified. You may want to have blocks that specific behavior instead, traffic control and aggregate control for example.
Dave McDysan: You want to see this single block decomposed into functions and how they relate. Then structure the requirements accordingly. The problems can be prioritized and solved in order.
Lou Berger: Yes. Consider the requirements for your traffic types as well. What's the behavior on the wire for TE, IP and what the management is like?
Dave McDysan: We focused, for this WG at least, on the exterior functions.
[Slide 8 - Single Routing Instance Exterior Functions]
John Scudder: Is this the first IETF document that specifies behavior of multi-instance routing?
Dave McDysan: No, it would be the second. The LSP hierarchy document is the first. Kireeti also acknowledge this.
[End Comment]
Dimitri Papadimitriou: I suggest you look at OSPF QoS routing specification. It already incorporates delay in the metrics but it has never been used. You need heretics for multi-constraint computation. Also consider the impact of using these metrics.
Dave McDysan: That’s a good suggestion.
Daniel King note: Ruediger made a comment during the CTG presentation but for some reason I could not find it in my notes.