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
