RE: Charter Update (Discussion)

[András Császár <[e-mail]>]

I think we should first see if there is a solution which provides full coverage and practical (=reasonable complexity). 

One problem with non-full-coverage solutions is bidirectional coverage. I.e. even if a flow is covered for a failure in one direction it may not be covered in the reverse direction which is, for most applications, equal to not being covered at all. This property is often neglected in coverage estimates. As an example consider the LFA unfirendly sub-topologies like longer-than-triangle rings. In those rings it might seem that the failures on the opposing side to the exit point are covered by the LFA. But they are not covered in the reverse direction. Might be a factor to consider for PQ and co too.

Being involved, I obviously think that there are practical enough solutions for full coverage: draft-atlas-rtgwg-mrt-frr-architecture-01 would be one such solution within the local repair principle, while draft-csaszar-ipfrr-fn-02 would also be such a solution not based on local repair.

Both MRT-FRR and IPFRR-FN can be said to provide full failure coverage(*) and both seem to be more complex at first sight than they really are (including implementation considerations). And both have running code already.

(*):
With MRT-FRR, full failure coverage means all single link and single node failures, and (we strongly suspect) single local SRLG failures. We hope that single generic SRLG failures can be solved, too, but would really welcome ideas and thoughts here.

IPFRR-FN provides coverage for single link and single node failures as well as all single generic SRLG failures and it is even capable to cover a reasonable number of pre-configured multiple failure cases deemed important by the operator.

There are clearly other tradeoff factors besides coverage and complexity such as backup path length, incremental deployability, support of IP or LDP or both, etc.

Regards,
András


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Alia Atlas
> Sent: 2011. november 7. 19:06
> To: Mike Shand
> Cc: [e-mail]
> Subject: Re: Charter Update (Discussion)
> 
> 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 
> <[e-mail]> 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<[e-mail]>:
> >>>
> >>> 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: [e-mail] [mailto:[e-mail]] On 
> >>>> Behalf Of András Császár
> >>>> Sent: 2011. november 3. 11:56
> >>>> To: Retana, Alvaro; [e-mail]
> >>>> 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: [e-mail] [mailto:[e-mail]] On 
> >>>> Behalf Of Retana, Alvaro
> >>>> Sent: 2011. november 3. 2:13
> >>>> To: [e-mail]
> >>>> 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
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/rtgwg
> >>>
> >>> _______________________________________________
> >>> rtgwg mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/rtgwg
> >>>
> >> _______________________________________________
> >> rtgwg mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/rtgwg
> >
> > _______________________________________________
> > rtgwg mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtgwg
> >
> _______________________________________________
> rtgwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg
>