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 to complete 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
