2.5.13 Routing Area Working Group (rtgwg)


In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://psg.com/~zinin/ietf/rtgwg -- Additional RTGWG Web Page
NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-24

Chair(s):
Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>
Routing Area Director(s):
Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>
Routing Area Advisor:
Alex Zinin <zinin@psg.com>
Mailing Lists:
General Discussion: rtgwg@ietf.org
To Subscribe: rtgwg-request@ietf.org
In Body: subscribe email_address
Archive: http://www.ietf.org/mail-archive/web/rtgwg/index.html
Description of Working Group:
The Routing area receives occasional proposals for the development and publication of RFCs dealing with routing topics, but for which the required work does not rise to the level where a new working group is justified, yet the topic does not fit with an existing working group, and a single BOF would not provide the time to ensure a mature proposal. The rtgwg will serve as the forum for developing these types of proposals.

The rtgwg mailing list will be used to discuss the proposals as they arise. The working group will meet if there are one or more active proposals that require discussion.

The working group milestones will be updated as needed to reflect the proposals currently being worked on and the target dates for their completion. New milestones will be first reviewed by the IESG. The working group will be on-going as long as the ADs believe it serves a useful purpose.

Goals and Milestones:
Done  Submit draft on calculation of IGP routes over TE tunnels to IESG for publication as Informational RFC
Done  Submit initial Internet Draft on IP Fast Reroute Framework
Jun 04  Submit initial Internet Draft on Basic IP Fast Reroute mechanism
Aug 04  Review various mechanisms for Advanced IP Fast Reroute
Oct 04  Submit IP Fast Reroute Framework to IESG for publication as Informational RFC
Oct 04  Submit specification on Basic IP Fast Reroute mechanism to IESG for publication as Proposed Standard
Nov 04  Select the Advanced IP Fast Reroute mechanism
May 05  Submit specification on Advanced IP Fast Reroute mechanism to IESG for publication as Proposed Standard
Internet-Drafts:
  • - draft-ietf-rtgwg-rfc3682bis-02.txt
  • - draft-ietf-rtgwg-igp-shortcut-01.txt
  • - draft-ietf-rtgwg-ipfrr-framework-01.txt
  • Request For Comments:
    RFCStatusTitle
    RFC3682 E The Generalized TTL Security Mechanism (GTSM)

    Current Meeting Report

    Minutes from the RTGWG - IETF60
    2004-08-05 15:30-17:30


    This is the first meeting of this WG.


    Alex Zinin went through the Document Status:


    draft-ietf-rtgwg-rfc3682bis-02.txt (GTSM revision)
    - revision needed, standards track.
    draft-ietf-rtgwg-igp-shortcut-01.txt
    - in RFC editor queue.
    IPFRR:
    - This is the main work of this group right now.
    - These documents are required for this work:
    - Framework
    - Basic IPFRR - draft-atlas-ip-local-protect-loopfree-00.txt
    This is intended to be an easy method to understand and implement.
    Partial coverage for this method is okay. There is general agreement on this document.


    Alia Atlas presented the basic draft (draft-atlas-ip-local-protect-loopfree-00.txt). She is going to update the draft to:
    - Update the Local Alternates and the Downstream Alternates section.
    - Update Link, Node and Link & Node Protection section.
    - General revisions to clean up language, examples, and scenarios for the working group draft revision.


    There are now 3 presentations on differnet advanced methods, which attempt to provide better coverage than the basic method.
    - U-Turns (Alia)
    - Tunnels (Mike/Stewart)
    - Alternative SPF (Albert)


    Alex stated that it is a NON-GOAL to decide among these at this point.


    ============================================================================


    Alia presented on the U-TURN draft. This method allows average coverage of s/d pairs from 79.5% to 98.4%. This method allows routers that support u-turn alternates to assist their peers in finding an alternate path. This metod requires an IGP extention to allow routers to tell each other that they are capable of supporting this method. A new Link Capabilities TLV in IGP which carries at least 1 bit indicating u-turn capable recepient, and 1 bit indicating that it has an eligible alternate.


    This draft represents what the author believes is the correct tradeoff between computational complexity and coverage. You could get greater coverage at the expense of computational complexity by extending uturn further upstream.


    Goal is to simplify operations but still provide a high degree of fast reroute.


    Please see the presentation in the full proceedings for much more information.


    o There was a question from the floor on how many additional forwarding entries would be required to handle this.
    -- Alia responded that it is somewhat implementation dependent, but that the implementation overhead should be manageable.


    o Acee asked if you would need an additional LSA, rather than just the node LSA.
    -- Alia responded that although the draft was unclear, her intent was to put the sub-tlv into the TE LSA.


    o There was another question from the floor that asked if the author had any information as to which topologies are favorable to this method and which topologies do poorly.
    -- Alia responded that her analysis was based on real networks whose topologies she was given. She acknowledged that one could construct a topology, such as a very large ring, where coverage would drop.
    --- Alex responded that the point being made was that the


    o Kireeti said that "this is a solution looking for a problem" stating that this is approprate only for 1) For people who don't want to use MPLS, 2) For people who don't want to use end-to-end RSVP-TE. And mentioned an alternate solution saying you could use RSVP bypass and tunnel traffic over this. And if you don't want to do this you can do IGP with RSVP bypass.
    -- Alex responded that there was a consensus that this was something that we wanted to work on.
    --- Alia said that this was a solution she came up with when presented with a problem, and not vise-versa. And said this is something that helps end-to-end protection while also being operational much less complex.


    o Albert opined that he thought that this would be incompatable with the BFD echo mode.
    -- Dave Ward said that even if this was the case, then that BFD mode was optional.


    o Alex asked that there was some mention of a second lookup, and wanted some claification.
    -- Alia responded that it was just another memory lookup, and not another tree lookup.


    o Albert asked what the "100%" refered to. And asked how this would work across areas.
    -- Alia responded that the draft deals with one area, but that you could set this up to provide inter-area protection.


    o Albert also asked about the complexity, which was asserted as being O(n), and asked if that meant that you had to do n SPFs.
    -- Alia responded that at the worst case it was an n * SPF complexity.


    o Suresh asked that the check was on that interface and to see if it came from that specific neighbor. If that is the case, how is it done on a LAN?
    -- Alia responded that there is a section in the draft that deals with that.
    --- Suresh & Alia clarified that you are getting the information from the ingress interface, and not from the packet itself.


    o Yakov asked how you handle the case with no IGP on the link.
    -- Alia said that with this method, no IGPs was out of the scope, but that you could statically configure something.


    o Pedro asked for more clarification on the 1.5% that is not covered, and if that is a deterministic value, and said that more information on what was not covered would be useful in the draft.


    o There was a confirmation question from the floor asking if the 1.5% was links or destinations.
    -- Alia responded that it was for the number of s/d pairs.


    ============================================================================


    The second presentation was Tunnel Based FRR


    This is a long-reach repair mechanism to complement ECMP and downstream routes. This works by tunneling the packet to a router in the network that is reachable by the sender and has a natural path to the destination.


    The draft and presentation also discuss a variety of methods beyond the basic tunneling method to provide full coverage for a variety of situations. The draft advocates a rapid detection method. And three encaps methods: 1) Encapsulate to MHP, 2) Encaps to secondary repair 3) Encaps to P. Any IP tunneling mechanism could be used (IP in IP, GRE or L2TPv3). This would reqire a new sub-TLV containing a capability bit, a link protected bit and a DF vector. This solution requires tunnels and nested tunnels. This method, in symmetric networks, or non-pathological asymmetric networks, provides 100% coverage. There is a slide at the end which provides a couple of network coverage percentages as % of links.


    Please see the presentation in the full proceedings for more information.


    o Pedro asked if you have the assumption that if you know where the BGP traffic is going to be routed to would that change the calculation.
    -- Stewart responded that all the solutions we're looking at are IGP based and that the BGP gets its NH from the IGP. This covers all failures except of the BGP edge node, which is another problem.


    o Alia asked about the computational complexity.
    + The discussion got fairly deep and it was agreed to take it offline.


    o Don said it would be useful to dicuss not only the computational complexity, but the scope of that complexity. He noted the timers as an example.
    -- Stewart replied that the timers are a local matter.
    -- Mike added that the horizons and timers are something that this solution does and other solutions do not.


    o Don also asked about the deployablity with loop-free.
    -- Mike said that for that particular scenario all the nodes need to cooperate.
    -- Stewart pointed out that there are other scenarios where all the nodes do not have to have this capabilty.


    o Albert said that this method is similar to the draft that the guys from Redback have proposed.
    -- The authors agreed that there were similar solutions that had been reached from different starting points.
    --- Albert and the authors agreed to talk more offline about some of the pathological topologies.


    o Acee asked what the advantage of this method was as opposed to a brute-force method of computing SPFs from all nodes perspectives.
    -- Stewart replied that it didn't matter how you compute the P and Q space, just that both were computed.


    ============================================================================


    The third presentation was by Albert called FRR Using Alternative Shortest Paths.


    Propose a method to provide 100% coverage. Different methods are proposed for link protection (nexthop), and for node protection (next-nexthop to start and 3 others if next-nexthop fails). The authors are using a stripped-down version of CSPF to do this. This method provides alternates for both Pure IP (draft-shen-ip-te-rsp-01.txt), and for MPLS based solutions. Complexity does vary if metrics are symmetric or asymmetric.


    Please see the presentation in the full proceedings for more information.


    o Dave Ward said that Albert did have drafts in other wg's that extended the IGP's to address this issue.
    -- Albert did acknowldge this.


    o Dave also commented that what he saw from the drafts, it looks like the parties are all starting from different places. So we need to decide exactly what we are aiming for (a framework/requirements/architecture document).


    o Kireeti opined that there were two differnet problems are being solved,
    1) if there is a failure what to do and 2) how to handle loop-free reconvergence.
    -- The authors of the drafts agreed on this.


    o Kireeti said that Albert's and Stewart's solutions are differnet, which is contrary to a previous commenter.
    -- The authors disagreed and said that there is a similarity between the drafts.


    o Pedro came back and elaborated on his earlier comment that there was a BGP element for external routing information that should be considered.
    -- Mike asked Pedro to clarify, since it seemed that IGP didn't work for BGP information either.
    + There was some confusion on this issue, and it was agreed that this was better hashed out on the mailing list.


    o Dave asked that if traffic matricies were required, as was implied by the drafts. And if there was a TE consideration to this model.
    -- Stewart said that there was an advantage to adding a traffic-based aspect to all of these.


    o Rudiger Volk said that a correlary to this was that even the approaches that claim 100%, don't deliver it because they would result in an overload on the network.
    -- Albert said that if you use RSVP you could perhaps take that into account.


    o Alex asked the presenters how they would address Multicast.
    -- Mike replied that they had given it some thought, and that the solution may be to encapsulate to the node on the tree directly downstream of the failure.
    --- Tony Li said that doing that would be suboptimal, since it could result in additional replication, and that the tree would move by the time the repair was created.
    ---- Mike and Stewart disagreed.


    o Tony Li pointed out that when RSVP is doing bw allocation, that it is, at best, a ROUGH approximation. eg. if you expect an LSP to have 10 Mbps on it, in reality it is somewhere between 7 and 12 Mbps. This results in some interesting tricky things.

    Slides

    Agenda
    U-Turn Alternates for IP/LDP Local Protection
    Tunnel based FRR
    Fast Reroute Using Alternative Shortest Path