Hi Mike, Yes, I certainly agree that it is a tradeoff between complexity (all aspects) and coverage. I'm concerned that we don't end up with too many different and minimally compatible solutions.
Alia On Mon, Nov 7, 2011 at 1:00 PM, Mike Shand <[email protected]> wrote: > On 07/11/2011 17:47, Alia Atlas wrote: >> >> 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. > > While I have always been in favour of complete coverage solutions, I do > think that we need to consider the tradeoff between complexity (not just > computational complexity, but implementation, deployment and operational > complexity) and complete coverage. So I wouldn't like to exclude non > complete coverage solutions (and indeed to some extent all solutions that > cannot deal with arbitrary combinations of failures are in some sense > incomplete) from consideration, especially if they are "low cost" compared > to more complete solutions. >> >> 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. > > Yes, agreed. > > Mike > > >> >> 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 > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
