Subject: Charter Update (Discussion)

From: "Retana, Alvaro" <[email-masked]>
Date: Thu, 3 Nov 2011 01:13:16 +0000

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

---

From: András Császár <[email-masked]>
Date: Thu, 3 Nov 2011 11:55:36 +0100

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-masked] [mailto:[email-masked]] On Behalf Of Retana, Alvaro
Sent: 2011. november 3. 2:13
To: [email-masked]
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.

---

From: András Császár <[email-masked]>
Date: Thu, 3 Nov 2011 15:56:43 +0100

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-masked] [mailto:[email-masked]] On Behalf Of András Császár
Sent: 2011. november 3. 11:56
To: Retana, Alvaro; [email-masked]
Subject: RE: Charter Update (Discussion)

Hi!

Andras

Hi!

Thanks!

Alvaro.

---

From: Russ White <[email-masked]>
Date: Sat, 05 Nov 2011 09:13:55 -0400

> We’re in the process of updating the WG charter and the list of milestones.

These look fine to me...

:-)

Russ

---

From: Mike Shand <[email-masked]>
Date: Mon, 07 Nov 2011 17:34:16 +0000

That seems to describe what the WG does fairly well.

Fine with me.

     Mike

On 03/11/2011 01:13, Retana, Alvaro wrote:
> 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.
>
> Apr 2013 Submit specification on Advanced IP Fast Reroute mechanism 
> to  IESG for publication as Proposed Standard
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: "So, Ning" <[email-masked]>
Date: Mon, 7 Nov 2011 12:37:57 -0500

Alvaro,

This looks fine to me.

Best regards,

Ning So
Verizon Corporate Technology
(office) 972-729-7905
(Cell) 972-955-0914

Thanks!

Alvaro.

rtgwg mailing list

[email-masked]<mailto:[email-masked]>

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 7 Nov 2011 09:40:18 -0800

This looks good, possibly with the consideration of Andras' first set of comments.

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 7 Nov 2011 09:41:16 -0800

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:

> And also we probably should discuss this part a bit: "A specific goal of fast-reroute mechanisms is to provide up tocomplete coverage".
>

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 7 Nov 2011 12:42:32 -0500

Hi,

With Andras's comments incorporated looks good to me.

Regards,
Jeff

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Shand
Sent: Monday, November 07, 2011 9:34 AM
To: [email-masked]
Subject: Re: Charter Update (Discussion)

Fine with me.

    Mike

Thanks!

Alvaro.

rtgwg mailing list

---

From: Alia Atlas <[email-masked]>
Date: Mon, 7 Nov 2011 12:47:10 -0500

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

---

From: Mike Shand <[email-masked]>
Date: Mon, 07 Nov 2011 18:00:13 +0000

> problem for some networks, or simply to evaluate solutions as they

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.
> should explicitly call out LDP and multicast since the wording isn't
Yes, agreed.

     Mike

>
> Alia
>
> 2011/11/7 John G. Scudder<[email-masked]>:

---

From: Alia Atlas <[email-masked]>
Date: Mon, 7 Nov 2011 13:06:10 -0500

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-masked]> wrote:
> 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.
>>
>>> 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
>>>
>>>> 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".
>>>>
>>>> 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.
>>>>
>>>>
>>>> - 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
>>>>
>>>>
>>>> are officially part of this WG – the main change is contained in the second
>>>> paragraph.  Please take a look below and send your comments.
>>>>
>>>> Apr 2013 Submit specification on Advanced IP Fast Reroute mechanism to
>>>>  IESG for publication as Proposed Standard

---

From: András Császár <[email-masked]>
Date: Tue, 8 Nov 2011 18:20:54 +0100

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Alia Atlas
> Sent: 2011. november 7. 19:06
> To: Mike Shand
> Cc: [email-masked]
> aspects) and coverage.  I'm concerned that we don't end up 
> with too many different and minimally compatible solutions.
> 
> Alia
> 
> >> 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
> > sense
> > incomplete) from consideration, especially if they are "low cost" 
> >> 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
> >>
> >>> better in a requirements document.  (Did we do one of 
> those, years 
> >>> ago?  It might be worth updating even so.)
> >>>
> >>> --John
> >>>
> >>>> 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
> >>>>
> >>>>
> >>>> - 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.
> >>>>
> >>>> 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?
> >>>>
> >>>> 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
> >>>>
> >>>>
> >>>> 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.
> >>>>
> >>>> 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
> >>>>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 08 Nov 2011 17:54:07 +0000

> 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 mo…
Can you give me an example here?

I would expect a ring to have symmetric properties except when there are 
asymmetric costs, but normally assymetric costs are a configuration 
accident.

Stewart

---

From: András Császár <[email-masked]>
Date: Wed, 9 Nov 2011 11:59:49 +0100

Hi Stewart, this phenomenon occurs with symmetric costs with LFA.

Trying to sketch an example:

       2        2
[Src]-----[A]------[B]
  |                 |
 1|                 |1
  |                 |
 [C]-------------[Dest]
          2

Now for Src->Dest traffic, the link failure of Src-C can be remedied with LFA, as Src may pass the packet to A which is an LFA. For backwards traffic (e.g. TCP Acks) this link failure cannot be solved by C with LFA, so ultimately the Src-Dest traffic is screwed.

András

> On Behalf Of Stewart Bryant
> Sent: 2011. november 8. 18:54
> To: [email-masked]
> > 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.
> I would expect a ring to have symmetric properties except 
> when there are asymmetric costs, but normally assymetric 
> costs are a configuration accident.
> 
> Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 09 Nov 2011 17:56:28 +0000

Hi András

Yes, it is true that for that topology fragment there is no 
bidirectional LFA solution.

However you were talking about rings, and surely it's unusual for a ring 
topology to have non-uniform costs.

If we consider tunnel solution with forced first hop the solution would 
work.

C tunnels to A with forced first hop (C-Dest), decap and A to Src.
Src LFAs to A, A sends to B, B sends to Dest

- Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Gábor Sándor Enyedi <[email-masked]>
Date: Wed, 9 Nov 2011 21:54:31 +0100

Hi Steward,

That's forced first hop won't help; I can always add an extra node against such tricks. :)

        4       4
 [Src]-----[A]------[B]
    |                 |
   2|                 |1
    |                 |
   [C]-----[D]-----[Dest]
        1       3

You cannot solve this without "directed forwarding" (forcing B with some magic to forward packets to A instead of to Dest). Think on that phenomenon like this: until you have only P chance to protect a failure, protecting it in both directions will always be P*P<P until P<1. :)

Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, November 09, 2011 6:56 PM
To: András Császár
Cc: [email-masked]
Subject: Re: Charter Update (Discussion)

Hi András

Yes, it is true that for that topology fragment there is no bidirectional LFA solution.

However you were talking about rings, and surely it's unusual for a ring topology to have non-uniform costs.

If we consider tunnel solution with forced first hop the solution would work.

- Stewart

On 09/11/2011 10:59, András Császár wrote:
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Stewart Bryant
>> 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.
>> I would expect a ring to have symmetric properties except when there 
>> are asymmetric costs, but normally assymetric costs are a 
>> configuration accident.
>>
>> Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Nov 2011 01:14:11 +0000

> You cannot solve this without "directed forwarding" (forcing B with some magic to forward packets to A instead of to Dest). Think on that phenomenon like this: until you have only P chance to prote…
We would have solved that in the original tunnels draft with directed 
forwarding at B.

However you have not answered my point that practical rings (as opposed 
to ring fragments in mesh topologies) normally have equal cost per hop.

Stewart

---

From: András Császár <[email-masked]>
Date: Thu, 10 Nov 2011 10:31:41 +0100

See inline...

> From: Stewart Bryant [mailto:[email-masked]] 
> Sent: 2011. november 10. 2:14
> To: Gábor Sándor Enyedi
> Cc: András Császár; [email-masked]
> > You cannot solve this without "directed forwarding" (forcing B with 
> > some magic to forward packets to A instead of to Dest). 
> Think on that 
> > phenomenon like this: until you have only P chance to protect a 
> > failure, protecting it in both directions will always be 
> P*P<P until P<1. :)
> >
> >
> > Gabor
> >
> We would have solved that in the original tunnels draft with 
> directed forwarding at B.
> 
> However you have not answered my point that practical rings 
> (as opposed to ring fragments in mesh topologies) normally 
> have equal cost per hop.

Well, yes, you can of course substitute the above costs with hops, resulting in a long cycle.
Then of course we can say that such long cycles normally don't exist.

But then, this brings back to question No 0. :-) Do we need a solution that works in arbitrary cases?

One point I tried to have is that the normal coverage metrics used until now (e.g. for LFA coverage tests) let things show up a little nicer than they really are. I.e. coverage p vs p^2 as Gabor wrote.

We gave the operators one tool (LFA) already which they can try to switch on but with which they cannot be sure if it really works or for which prefixes it actually work. We say instead, tune your network topology a little bit, play with your link costs than you might get it to work better but even then it still might not work without getting close to full-mesh topo :-).

Do we want to give them yet-another tool with which they can again just hope for "good luck" for their existing topologies and existing link metrics? (I know this is a little exaggerated...)

Andras

> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Stewart Bryant
> > However you were talking about rings, and surely it's 
> unusual for a ring topology to have non-uniform costs.
> >
> >> Now for Src->Dest traffic, the link failure of Src-C can 
> be remedied with LFA, as Src may pass the packet to A which 
> is an LFA. For backwards traffic (e.g. TCP Acks) this link 
> failure cannot be solved by C with LFA, so ultimately the 
> Src-Dest traffic is screwed.
> >>
> >>
> >> András
> >>
> >>
> >>> 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.
> when there

---

From: Gábor Sándor Enyedi <[email-masked]>
Date: Thu, 10 Nov 2011 11:11:21 +0100

This discussion on rings and costs is worthless: first, you cannot force a customer to use uniform link costs, so there will be such rings; second, András only showed you an example, but the phenomenon is not bounded to rings, you can find it in other networks as well.

Gabor

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Thursday, November 10, 2011 2:14 AM
To: Gábor Sándor Enyedi
Cc: András Császár; [email-masked]
Subject: Re: Charter Update (Discussion)

On 09/11/2011 20:54, Gábor Sándor Enyedi wrote:
> some magic to forward packets to A instead of to Dest). Think on that 
> failure, protecting it in both directions will always be P*P<P until 
> P<1. :)
>
>
> Gabor
>
We would have solved that in the original tunnels draft with directed forwarding at B.

However you have not answered my point that practical rings (as opposed to ring fragments in mesh topologies) normally have equal cost per hop.

Stewart

>>> which is, for most applications, equal to not being covered at all. 
>>> 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

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 15 Nov 2011 13:36:55 -0800

Hi,

I agree that having a solution with full coverage is very useful
because it removes the need for complicated analysis to determine what
is protected versus what is not (and worse, how that changes as the
topology change). But the solution has to be simple for it to get
deployed.

One approach using MPLS that solves this using extensions to a single
protocol (LDP) is given in draft-kini-mpls-frr-ldp.

-- 
- Sri

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 15 Nov 2011 22:14:05 +0000

> protocol (LDP) is given in draft-kini-mpls-frr-ldp.
It the approach extensible to an IP context?

Stewart

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 15 Nov 2011 14:29:52 -0800

IP is addressed via MPLS. If IP forwarding were to be used
exclusively, then it becomes complicated. With MPLS being extended to
more parts of the network than just the core, it seems that is not as
much of a concern.

-- 
- Sri

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 15 Nov 2011 23:08:34 +0000

Unfortunately whether MPLS is used in a particular
network segment or not is a complex and sometimes
emotive issue.

If we decide that the best solution is to use MPLS
we then face the issue of what to do about networks
that decline to support MPLS. Do we declare
non-MPLS networks out of scope for IPFRR, or do
we work on another non-MPLS solution?

- Stewart

On 15/11/2011 22:29, Sriganesh Kini wrote:
> On Tue, Nov 15, 2011 at 2:14 PM, Stewart Bryant<[email-masked]>  wrote:

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 15 Nov 2011 18:20:15 -0600

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stewart Bryant (stbryant)
> Sent: Wednesday, November 16, 2011 7:09 AM
> To: Sriganesh Kini
> Cc: [email-masked]
> Unfortunately whether MPLS is used in a particular network segment or
not
> is a complex and sometimes emotive issue.
> 
> If we decide that the best solution is to use MPLS we then face the
issue of
> what to do about networks that decline to support MPLS. Do we declare
> non-MPLS networks out of scope for IPFRR, or do we work on another
non-
> MPLS solution?

I think you also have to wrestle with the opposite problem.  If you
declare that convergence schemes which require MPLS to provide 100%
coverage are within scope, what exactly is out of scope?  

eric

> >>> because it removes the need for complicated analysis to determine
> >>> what is protected versus what is not (and worse, how that changes
as
> >>> the topology change). But the solution has to be simple for it to
> >>> get deployed.
> >>>
> >>> One approach using MPLS that solves this using extensions to a
> >>> single protocol (LDP) is given in draft-kini-mpls-frr-ldp.

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 15 Nov 2011 21:24:46 -0500

I believe we are looking for a solution providing 100% coverage for both IP only and IP/MPLS networks with emphasis on full coverage.

Regards,
Jeff

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 16 Nov 2011 02:28:47 +0000

... in which case we have to be careful not to force MPLS

Stewart

On 16/11/2011 02:24, Jeff Tantsura wrote:
> On Nov 16, 2011, at 8:20 AM, "Eric Osborne (eosborne)"<[email-masked]>  wrote:
>
>>

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 16 Nov 2011 11:11:10 +0800

Solutions that use exclusively IP have been seen to run the risk of
issues such as incomplete coverage or complexity (or both), ...etc.
Networks that decline to support MPLS would be similarly affected.
Solutions that use MPLS and have full coverage and are deployable seem
possible. If we declare non-MPLS(read as IP) networks out of scope of
IPFRR that would be quite confusing :-). IMO there is value in an IP
only solution that is simple and has full coverage. If there isn't one
then MPLS based solutions seem a better option.

-- 
- Sri

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 15 Nov 2011 21:27:17 -0600

> Of Sriganesh Kini
> Sent: Wednesday, November 16, 2011 11:11 AM
> To: Stewart Bryant (stbryant)
> Cc: [email-masked]
issues such
> as incomplete coverage or complexity (or both), ...etc.
IPFRR
> that would be quite confusing :-).

Perhaps...but so would declaring that 'IPFRR' contained MPLS.  I always
looked looked at it as:

- first we had MPLS FRR, which we just called FRR.
- then, for those that were not interested in MPLS FRR, IPFRR was
introduced.  Implicitly the name 'IPFRR' excludes MPLS.

To now redefine IPFRR to say that the 'IP' part refers to client traffic
rather than the forwarding technology which builds your protection is
revisionist and probably contentious.

> IMO there is value in an IP only solution
> that is simple and has full coverage. If there isn't one then MPLS
based
> solutions seem a better option.
> 

But we're not debating value of various solutions, we're debating
charter and thus where those solutions come from.

eric

> > not is a complex and sometimes emotive issue.
> >
> > issue of what to do about networks that decline to support MPLS. Do
we
> > declare non-MPLS networks out of scope for IPFRR, or do we work on
> > another non-MPLS solution?
> >
> > - Stewart
> >
> >
> >>>> as the topology change). But the solution has to be simple for it
> >>>> to get deployed.
> >>>>

---

From: Russ White <[email-masked]>
Date: Tue, 15 Nov 2011 22:28:23 -0500

> then MPLS based solutions seem a better option.

I would argue that we strive for a solution that's all IP, no MPLS.
Let's not give up the hunt because the problem is hard.

BTW, there are simple solutions with little additional state, but they
don't provide anything like optimal paths. The problem isn't finding the
second topology, it's in finding a second topology that's anything like
acceptable.

:-)

Russ

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 15 Nov 2011 23:19:13 -0500

IMHO it just wouldn't make sense to do "IP or MPLS only" FRR.
While majority uses MPLS we can't ignore those who can't / won't do so.
I think we should clearly separate between full coverage but more complex to implement  solutions ie MRT or FN vs partial coverage but relatively easier to implement solution - LFA as an example

Regards,
Jeff

---

From: Alia Atlas <[email-masked]>
Date: Wed, 16 Nov 2011 00:33:24 -0500

IPFRR has always included LDP-FRR as well.   Both are clearly
hop-by-hop distributed routing - hence the wording in the charter.

There's RSVP-TE FRR and that is clearly for explicitly routed paths -
which is clearly not hop-by-hop distributed routing.

Since an RSVP-TE LSP can be a forwarding adjacency that appears as a
link in the IGP, of course there is the potential for an IP/LDP FRR
solution to use a TE LSP as a link.

Solutions that require explicitly routed paths to be computed in a
non-distributed fashion seem out of the problem scope to me.

Alia

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 16 Nov 2011 14:00:14 +0800

Inline

- Sri

Sent from my iPad

> Perhaps...but so would declaring that 'IPFRR' contained MPLS.  I always

The IPFRR LFA RFC refers to protecting LDP LSP traffic. Maybe that is
the source of the confusion ?

> introduced.  Implicitly the name 'IPFRR' excludes MPLS.

Are you saying that RFC 5286 should have left out MPLS ? But that is
not the point. LFA should not be interpreted as IP only protection
mechanism. Rather it should be viewed as a technology that can protect
traffic along shortest paths. This may be IP or LDP LSP traffic.

> charter and thus where those solutions come from.

I agree. I was just responding to Stewart on where the work is.

---

From: András Császár <[email-masked]>
Date: Wed, 16 Nov 2011 07:05:49 +0100

> hop-by-hop distributed routing - hence the wording in the charter.

Are we also considering FRR for Ethernet/SPB? ;-) ;-) It is hop-by-hop distributed routing.

So I still hold on to my first email in this thread: we should be explicit in the charter. Writing LDP and IP specifically, unicast and multicast, ASBR protection, and all the things we target.

> There's RSVP-TE FRR and that is clearly for explicitly routed 
> paths - which is clearly not hop-by-hop distributed routing.
> 
> Since an RSVP-TE LSP can be a forwarding adjacency that 
> appears as a link in the IGP, of course there is the 
> potential for an IP/LDP FRR solution to use a TE LSP as a link.

Agree, and since there is already an MPLS-only solution, I don't see to work on yet another (even if it's LDP).

I argue that working on an LDP-only solution is only justified if we do not find a full-coverage IP&LDP concept that is practical enough. (A side-note, though: even if the concept is the same for IP and LDP, the lower-level details will be of course different for the two.)

András

---

From: Mike Shand <[email-masked]>
Date: Wed, 16 Nov 2011 06:15:39 +0000

I agree. We should be working on pure IP solutions which can also be 
used with LDP.

Mike

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Wed, 16 Nov 2011 00:27:12 -0600

> From: Alia Atlas [mailto:[email-masked]]
> Sent: Wednesday, November 16, 2011 1:33 PM
> To: Eric Osborne (eosborne)
> Cc: Sriganesh Kini; Stewart Bryant (stbryant); [email-masked]
> There's RSVP-TE FRR and that is clearly for explicitly routed paths - which is
> clearly not hop-by-hop distributed routing.
> 
> Since an RSVP-TE LSP can be a forwarding adjacency that appears as a link in
> the IGP, of course there is the potential for an IP/LDP FRR solution to use a TE
> LSP as a link.
> 
> Solutions that require explicitly routed paths to be computed in a non-
> distributed fashion seem out of the problem scope to me.

OK, so solutions which use TE LSPs as FAs for FRR are OK but computing the paths and destinations for those LSPs is not?

eric

> >> Behalf Of Sriganesh Kini
> >> Solutions that use MPLS and have full coverage and are deployable
> >> seem possible. If we declare non-MPLS(read as IP) networks out of
> >> scope of
> > IPFRR
> > Perhaps...but so would declaring that 'IPFRR' contained MPLS.  I
> > always looked looked at it as:
> >
> > To now redefine IPFRR to say that the 'IP' part refers to client
> > traffic rather than the forwarding technology which builds your
> > protection is revisionist and probably contentious.
> >
> >> IMO there is value in an IP only solution that is simple and has full
> >> coverage. If there isn't one then MPLS
> > based
> >> >> On Tue, Nov 15, 2011 at 2:14 PM, Stewart
> >> >> Bryant<[email-masked]>
> >> >>  wrote:
> >> >>>
> >> >>>> because it removes the need for complicated analysis to
> >> >>>> determine what is protected versus what is not (and worse, how
> >> >>>> that changes as the topology change). But the solution has to be
> >> >>>> simple for it to get deployed.
> >> >>>>

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 16 Nov 2011 15:02:40 +0800

We need to clearly distinguish between path type of the protected
traffic versus that of the backup. I agree that protected traffic in
IP as well as MPLS (LDP) is hop-by-hop routed.

What possibly makes it confusing is that the backup path may contain
parts that are explicitly computed and other parts that are not. Even
in LFA the first hop of backup path is explicitly routed, and to
protect that direction of traffic does not even need distributed
backup computation (since the next hop from PLR is using a normal
routed path) !

- Sri

Sent from my iPad

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Wed, 16 Nov 2011 19:08:25 -0600

Self-replying....what if the charter said something like "RTGWG focuses
on IGP-based protection mechanisms which require no multihop explicit
routing and which attempt to provide 100% failure coverage" or something
along those lines?  

'no multihop explicit routing' is deliberately  intended to exclude not
just TE LSPs but also static TP LSPs and whatever other explicit path
steering mechanisms we come up with (IP Options?  A zombie outbreak of
CR-LDP?).  It allows for the small bit of explicit routing that LFA
does, picking an OIF not in the RIB.  

"attempts to provide 100% coverage" is to recognize that there are
multiple solutions to the problem (LFA, MRT, whatever we come up with
next).  All can provide 100% coverage in the right topology, but some
can't cover all scenarios; it may be that the scenarios which can't be
100% covered are not of interest to those who wish to deploy a
particular technology.

Language lawyering aside, does this seem like a reasonable approach?

eric

> From: Eric Osborne (eosborne)
> Sent: Wednesday, November 16, 2011 8:20 AM
> To: Stewart Bryant (stbryant); Sriganesh Kini
> Cc: [email-masked]
Behalf
we
> > another non- MPLS solution?
> 
declare
> that convergence schemes which require MPLS to provide 100% coverage
> are within scope, what exactly is out of scope?
> 
> 
> 
> eric
> 
> >
> > - Stewart
> >
> >
> > > exclusively, then it becomes complicated. With MPLS being extended
> > > to more parts of the network than just the core, it seems that is
> > > not as much of a concern.
> > >
> > >>> because it removes the need for complicated analysis to
determine

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 16 Nov 2011 20:33:48 -0500

Eric,

Self-rephrasing - if a solution to provide 100% coverage is topology dependent then it simply doesn't provide 100%, there's no "right topology" to apply to every network. 
However - if you look at rtgwg agenda - there are at least 2 proposals to provide 100% coverage in virtually any topology (given there's a backup)

Regards,
Jeff

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Wed, 16 Nov 2011 19:44:54 -0600

> From: Jeff Tantsura [mailto:[email-masked]]
> Sent: Thursday, November 17, 2011 9:34 AM
> Cc: Stewart Bryant (stbryant); Sriganesh Kini; [email-masked]
> Self-rephrasing - if a solution to provide 100% coverage is topology
> dependent then it simply doesn't provide 100%, there's no "right
topology"
> to apply to every network.

No, and I don't think we need to be in the business of standardizing
topologies.  But look at it the other way.  If a technology provides
100% coverage in some real-world technologies that people are using
today but provides 98% in other topologies that are also in use, that
technology seems appropriate for the first case.  Whether it's
appropriate for the second is up to the operator of the second.

Right?

> However - if you look at rtgwg agenda - there are at least 2 proposals
to
> provide 100% coverage in virtually any topology (given there's a
backup)

I admit I have not read them.  But I think the nuance here hinges on
'*virtually* any topology'.  If a technology provides 100% in many cases
and 98% in many others, is that not 'virtually' all?

eric

> > Self-replying....what if the charter said something like "RTGWG
> > focuses on IGP-based protection mechanisms which require no multihop
> > explicit routing and which attempt to provide 100% failure coverage"
> > or something along those lines?
> >
> > 'no multihop explicit routing' is deliberately  intended to exclude
> > not just TE LSPs but also static TP LSPs and whatever other explicit
> > path steering mechanisms we come up with (IP Options?  A zombie
> > outbreak of CR-LDP?).  It allows for the small bit of explicit
routing
> > that LFA does, picking an OIF not in the RIB.
> >

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 16 Nov 2011 21:08:21 -0500

Eric,

What I meant with "virtually" is that there must be a backup in order to use one, there is no uncovered 2%.

Regards,
Jeff  

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 17:45
To: Jeff Tantsura
Cc: Stewart Bryant (stbryant); Sriganesh Kini; [email-masked]
Subject: RE: Charter Update (Discussion)

topology"

Right?

to
backup)

eric

routing

---

From: András Császár <[email-masked]>
Date: Thu, 17 Nov 2011 03:43:19 +0100

> No, and I don't think we need to be in the business of 
> standardizing topologies.  But look at it the other way.  If 
> a technology provides 100% coverage in some real-world 
> technologies that people are using today but provides 98% in 
> other topologies that are also in use, that technology seems 
> appropriate for the first case.  Whether it's appropriate for 
> the second is up to the operator of the second.

Well, certainly we should not standardise topologies. :-) Maybe providing guidelines on how to build/extend topologies to be more suitable for non-full coverage solutions. Work has already been done on this e.g. for LFA.

Up to now, concerns regarding non-full-coverage solutions are the following:

1. bidirectional coverage (i.e. when a solution claims e.g. 90% coverage, it could be closer to 80% in reality for practical traffic).

2. Potential struggle by the operator on knowing which of the traffic flow/failure cases are covered and which are not covered.

3. Potential struggle by the operator on knowing how exactly coverage changes after topology changes.

4. This has not been mentioned yet, but I do feel that if a proper 100% solution gets standardised and gets trusted by operators, then in a couple of years operator topology design guidelines could be relaxed *somewhat* towards a *little* less-dense connectivity, as to rely a little bit more on network layer redundancy instead of parallel or near-parallel links close to each other and quite dense mesh. So it could result in some cost reduction in the future.

5. There is talk on pushing IP/MPLS (LDP) down towards access, where topologies are not so meshy but a full-coverage solution could work with a few cross-links.

Background for 4 and 5: non-full-coverage solutions perform the better, the more densly meshed the topology is, while a 100% solution could work also on a relatively rare topo.

Andras