We do have framework RFCs, but not requirements documents. A question that we're actively looking for feedback on is whether the WG wants to focus first on complete coverage solutions in the hope of having a small set of solutions, on solutions that solve pieces of the problem for some networks, or simply to evaluate solutions as they come up.
Since a part of this re-chartering is to clarify that the design focus for hop-by-hop fast-reroute activity is in RTGWG, I agree that we should explicitly call out LDP and multicast since the wording isn't as assertive about that. Alia 2011/11/7 John G. Scudder <[email protected]>: > Some of this seems too detailed for a charter, and like it might go better in > a requirements document. (Did we do one of those, years ago? It might be > worth updating even so.) > > --John > > On Nov 3, 2011, at 7:56 AM, András Császár wrote: > >> Some further comments: >> >> We probably shoud define "failure" a bit more clear. Single link, single >> node, SRLG (local or remote), multiple failures. >> >> And also we probably should discuss this part a bit: "A specific goal of >> fast-reroute mechanisms is to provide up tocomplete coverage". >> >> In my view, the target solution, while being practical, should be able to >> provide >> >> 1. Complete coverage for all single link, single node and single SRLG (local >> and remote) failures and for a reasonable number of pre-configured multiple >> failure cases deemed important by the operator. >> >> >> If we can't find such a practical solution then we can fall back to a >> solution, which provides >> 2. Complete coverage for all single link, single node and single SRLG (local >> and remote) failures. >> >> If we can't find such a practical solution then we can fall back to a >> solution, which provides >> 3. Complete coverage for all single link, single node and single local SRLG >> failures. >> >> If we can't find such a practical solution then we can fall back to a >> solution, which provides >> 4. Complete coverage for all single link and single node failures. >> >> Only if we can't find such a practical solution, should we fall back to a >> solution, which provides >> 5. Coverage higher than LFA for many/most single link and single node >> failures. >> >> András >> >> >> From: [email protected] [mailto:[email protected]] On Behalf Of >> András Császár >> Sent: 2011. november 3. 11:56 >> To: Retana, Alvaro; [email protected] >> Subject: RE: Charter Update (Discussion) >> >> Hi! >> >> I think the proposed charter text is OK. >> Comments: >> >> - I have the feeling that we should add LDP-MPLS explicitly. I know that >> implicitly we mean IPFRR for IP and LDP, too. And I also see that we have >> the "enhancements to hop-by-hop distributed routing related to fast-reroute" >> portion in the proposed charter, which includes LDP. But still maybe saying >> LDP-MPLS explicitly would be good for clarity. >> >> - The same goes for multicast. I see the last milestone is for multicast, >> that's OK, but maybe we should add it explicitly to the charter text. >> >> - Another thought regarding LDP, again: Do we have a position on whether an >> LDP-only FRR solution (i.e. which would not work for plain IP) but provides >> 100% coverage is of interest? Or do we want to have a solution that is >> applicable to both plain IP and LDP-MPLS? >> >> Maybe we should add something like this to the charter text: "...A specific >> goal of fast-reroute mechanisms is to provide up to complete coverage when >> the potential failure would not partition the network. The RTGWG seeks FRR >> solutions for both unicast and multicast on pure IP and LDP/mLDP-MPLS >> networks." >> >> - With some folks we were discussing in the background that the WG might >> profit from an informational doc which lists/overviews and compares >> objectively all the proposed solutions. There is a pletora of proposals out >> there, some might have not even appeared at the IETF. Of course, we don't >> necessarily need to state such a doc explicitly as a milestone, I don't know. >> >> - If the multicast milestone is Apr 2012, then it should be earlier. Or if >> it was meant for Apr 2013, then the year needs to be corrected. >> >> Andras >> >> >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Retana, Alvaro >> Sent: 2011. november 3. 2:13 >> To: [email protected] >> Subject: Charter Update (Discussion) >> >> Hi! >> >> We’re in the process of updating the WG charter and the list of milestones. >> >> The main objective of the update is to clarify that FRR-related topics are >> officially part of this WG – the main change is contained in the second >> paragraph. Please take a look below and send your comments. >> >> For reference, here’s the current charter: >> http://tools.ietf.org/wg/rtgwg/charters >> >> Thanks! >> >> Alvaro. >> >> >> >> >> 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 yet rise to the level where a new working group is >> justified, yet the topic does not fit with an existing working group, >> and it is either not ready for a BOF or 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 also focuses on enhancements to hop-by-hop distributed routing >> related to fast-reroute and loop-free convergence. A specific goal of >> fast-reroute mechanisms is to provide up to complete coverage when the >> potential failure would not partition the network. All work in this >> area should be specifically evaluated by the WG in terms of practicality >> and applicability to deployed networks. >> >> 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. >> >> >> Apr 2012 Submit Composite-Link Requirements to IESG for publication as >> Informational >> Apr 2012 Submit Ordered FIB architecture to IESG for publication as >> Informational >> Nov 2012 Submit Composite-Link Framework to IESG for publication as >> Informational >> Apr 2013 Submit specification on Advanced IP Fast Reroute mechanism to IESG >> for publication as Proposed Standard >> Apr 2012 Submit initial Internet Draft on Multicast IP Fast Reroute >> Architecture >> >> _______________________________________________ >> rtgwg mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/rtgwg > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
