Subject: ops reqs on IP FRR

From: Pekka Savola <[email-masked]>
Date: Fri, 11 Nov 2005 18:10:56 +0200 (EET)

Hi,

After watching the IP FRR discussion at rtgwg, I though I should try 
to highlight a few operational perspectives:

  1) the solution should not require any configuration of topology, 
backup paths or in the topology; more specifically,

   1.a) the solution must not require configuration of any parts of 
topology which are not adjacent to the router.

Discussion: topological/routing changes happen frequently.  Having to 
reconfigure the otherwise-unaffected routers so that IPFRR doesn't get 
messed up is a non-starter.

  2) the solution should "just work" without any config (apart from 
toggling it on if need be)

  3) the solution, when enabled, must not have a failure mode where the 
result would be blackholing or duplicating traffic for a noticeably 
longer period than non-IPFRR would ("optimizations must not make 
corner cases worse")

HTH in choosing a deployable and manageable solution,

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Rtgwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg

---

From: Alia Atlas <[email-masked]>
Date: Fri, 11 Nov 2005 11:47:43 -0800

> messed up is a non-starter.

I strongly agree with this.  Certainly, that is how I've seen LFAs and
U-turns implemented.
The one caveat with PLSN is that it can only help prevent loops when
the affected routers have implemented it.

> toggling it on if need be)

Absolutely, for the default.  One can picture a few simple policy
control knobs - such as don't use this link as an alternate.

> longer period than non-IPFRR would ("optimizations must not make

Does this mean that you think, in ref to PLSN, that if the repairing
router S doesn't have an appropriate alternate, then S should switch
to its new primary immediately?  That introduces the
possibility/probability of loops until the new primary has updated to
either a safe neighbor or its new primary.  This is similar to the
micro-forwarding loop that would exist today.

If the new primary (NP) is type A, then it would update almost
immediately (in the first update period) to its new primary.  The loop
duration is extended only by the period of time necessary to wait to
receive all of the correlated updates.  Depending on the failure, this
may (p2p link failure where either update is sufficient) or may not
(node failure where only 1 of last 2 updates provided relevant info)
extend the actual duration.  If NP is type B, then the safe neighbor
will not go through S, so the scenario is the same.

If the NP is type C, then a longer delay would occur because NP
wouldn't update its FIB until after DELAY_TYPEC.  This is the same
delay where packets would be dropped if S waited to switch to NP until
DELAY_TYPEC.

This brings up two questions.  First, can we ignore the extra delay to
collect all relevant advertisements?  This delay is important for
identifying broadcast link, SRLGs or node failures.  I think we've
tossed around delay times of 50ms or so.

Second, how much benefit do we get from type C routers delaying?  This
delay means that PLSN only fails to repair type C <-> type C loops.
Without that delay, any type C would introduce a potential micro-loop.
 Of course, the number of type Cs is relatively small; perhaps Mike
has his simulation results to hand?

Is it better to have a technique that keeps the current behavior for
all cases but is less effective?  How corner-case does a case have to
be before it isn't a concern?

Alia

---

From: Pekka Savola <[email-masked]>
Date: Fri, 11 Nov 2005 22:01:17 +0200 (EET)

> > longer period than non-IPFRR would ("optimizations must not make
...
> be before it isn't a concern?

(As a bit of context, we're a traditional IP-only (v4/v6, 
uni/multicast) NREN without MPLS, VPNs, or TE -- and no desire to get 
any of that. The goals might or might not be different esp. for those 
which use TE but that seems to imply MPLS as well.)

These are good questions, and I can't give a good answer because I 
haven't been able to study the specs in detail (and in any case 
different operators' MMV).  That's why I wrote "should" and 
"noticeably longer period". (e.g. over 10% increase for times above 
half a dozen seconds might qualify as "noticeable").

The key point IMHO is that the vendors and operators could just turn 
this on without fear that it would have (too) bad effects.

On the other hand, as you write, there may be a real cost associated 
with too much conservatism for corner cases.  One potential approach 
would be specifying non-default behaviour w/ config knob which the 
operators could toggle on after they've studied the potential 
tradeoffs, impact on their particular topology and accepted them.

---

From: Alia Atlas <[email-masked]>
Date: Fri, 11 Nov 2005 19:52:35 -0800

> > tossed around delay times of 50ms or so.

If you figure network convergence might take 2-3 seconds, then we're
talking about the possibility of doubling it, b/c the DELAY_TYPEC
would be after that.  So, if could be
quite noticable.

> tradeoffs, impact on their particular topology and accepted them.
This seems to argue for 2 things.  First, that if S doesn't have an
alternate, it should prefer to loop rather than drop (since this will
get the "same" behavior in most cases).  Second,
that by default, DELAY_TYPEC should be 0 - and then then knowledgable
operator could adjust it.  This would impact the effectiveness, but
give the original behavior (modulo the small % extra delay to collect
advertisements).

Alia

---

From: mike shand <[email-masked]>
Date: Mon, 14 Nov 2005 14:30:22 +0000

Pekka,
         Thanks for this contribution. I strongly agree with all your 
points. This is pretty much the design principles we have been working to.
At 16:10 11/11/2005, Pekka Savola wrote:
>Hi,
>
>After watching the IP FRR discussion at rtgwg, I though I should try to 
>highlight a few operational perspectives:
>
>  1) the solution should not require any configuration of topology, backup 
> paths or in the topology; more specifically,

Yes. In particular it should not be necessary to modify the topology so 
that the IPFFR works better (or works at all).

> topology which are not adjacent to the router.

By "configuration" I assume you mean something other than deploying the 
software and turning it on. Or are you saying that ONLY the routers 
adjacent to the protected link should need updated software. That is fairly 
restricting.

>messed up is a non-starter.

Exactly. If the IPFRR coverage is topology dependant it is easy for a 
"good" topology to be degraded to a "bad" topology by one or more changes.

> toggling it on if need be)

Yes.

> longer period than non-IPFRR would ("optimizations must not make corner 
> cases worse")

Yes. This is critical. "Do no harm". This why I have a problem with IPFRR 
solutions which have less than 100% coverage. IPFRR and loop prevention 
must go together. One without the other is not useful (for failure 
protection.... loop prevention on its own is useful for management invoked 
topology changes). ALL known loop prevention schemes delay convergence 
(some more than others). This is not intrinsically a problem, since the 
fast repair will be carrying the traffic for this time. However, that is 
only true if the repair is able to repair 100% of the traffic. For any 
fraction of the traffic which cannot be repaired, the delay introduced by 
the loop prevention mechanism will result in that traffic receiving worse 
service than for normal routing convergence.

Multiple uncorrelated failures may be difficult of impossible to deal with. 
For those cases, the proposed action is to abandon the IPFRR/loop 
prevention and fall back to normal convergence. This can be actioned when 
multiple conflicting LSP/LSA s are received. This may take marginally 
longer than normal convergence, owing to propagation delays, but it is a 
small difference.

This "fall back" seems an important safety property.

         Mike

---

From: mike shand <[email-masked]>
Date: Mon, 14 Nov 2005 14:38:19 +0000

At 03:52 12/11/2005, Alia Atlas wrote:
>  Second,

Alia,
         Maybe I'm misunderstanding what you are proposing here, but 
doesn't that just reduce to no loop prevention?

         Mike

---

From: Alia Atlas <[email-masked]>
Date: Mon, 14 Nov 2005 08:30:17 -0800

Mike,

> doesn't that just reduce to no loop prevention?

No,  I don't think so.  DELAY_TYPEB is still non-zero.  It means type
A and type C change to their new next-hops immediately.  Type As (of
course) and type B are still protected.  What wouldn't be protected
would be the type C to anything loops.  That would definitely reduce
the coverage of PLSN, which is quite unfortunate & not the normal
recommendation.  On the other hand, it's the only way I see of
ensuring that the use doesn't cause additional traffic losage when S
doesn't have an alternate.

If you have the time, could you take a look at your simulation results
& see what this does to the coverage?  (% of potential micro-loops)

Alia

---

From: mike shand <[email-masked]>
Date: Mon, 14 Nov 2005 16:44:11 +0000

At 16:30 14/11/2005, Alia Atlas wrote:
>No,  I don't think so.  DELAY_TYPEB is still non-zero.

Oh I see. I sort of assumed you were leaving out type B's as well.

>It means type

OK. I'll have a go. So we treat type As and type Bs as normal, but change 
type Cs at the same time as type As. Is that right?

i.e. as you said originally, just change the type C delay timer to zero.

         Mike

---

From: Alia Atlas <[email-masked]>
Date: Mon, 14 Nov 2005 08:54:57 -0800

> Oh I see. I sort of assumed you were leaving out type B's as well.

Ah, well, that would reduce it to meaningless with no loopprevention :-)
> i.e. as you said originally, just change the type C delay timer to zero.

Exactly.

Thanks!

Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 14 Nov 2005 09:14:27 -0800

Mike,

I think that there is a difference between configuration and coverage
concerns.  IP FRR must be easy to turn on; I believe that this applies
to how many boxes need to be touched, how much configuration must be
detailed, how easy it will be to troubleshoot, etc.

As you know, I tend to view the coverage issue as more of a network
architecture problem.  While it would be lovely if a simple (to
configure, to understand, to troubleshoot, etc.) mechanism existed
that gave 100% coverage, at this point it seems clear that such does
not.  Not-via has a great deal of potential, but it is not likely to
be simple to configure, possibly to troubleshoot, etc.  Certainly, the
trade-offs required in terms of decideing for/against
computation/complexity vs. coverage will need to be understood,
configured, and managed.  It also, of course, imposes the requirement
for substantial more computation on ALL nodes in the network.  That's
unfortunate.

My view is that turning on IP FRR (certainly LFAs) without much
thought/configuration should do no harm - and do some good, but it
won't just give you everything without more thought.  Certainly, when
you say 100% coverage, you are making certain assumptions about the
network (like it remains at least 2-connected regardless of topology
changes) that are not certain to be true.

The safe fall back, as you know, I completely agree with.

Alia

---

From: Rajeev Manur <[email-masked]>
Date: Mon, 14 Nov 2005 15:06:40 -0800 (PST)

All:

I wanted to bring up this question in the Vancouver meeting, but never got the right context. At this point in time do have a consensus in the WG on data-path requirements needed to support IPFRR. I am sort of trying to see if there is a way to de-couple the data-path requirements and make them independent of the which approach we use in control plain to build the alternate routes. I see that some control plane solutions propose the use of tunnels to route the traffic around the failure point. Some appraoches suggest use of MPLS tunnels, while not-via suggests IP-in-IP etc...

Is it a good idea to de-couple the data-path reqs and pubish them in a seperate dratf. This will help people working on next gen HW to make their HW compilant to future IPFRR solutions.

With regards,
Rajeev Manur

Force10 Networks Inc
Milpitas, CA - 95035

Work : (408)-571-3511
Mob  : (408)-718-7370
		
---------------------------------
 Yahoo! FareChase - Search multiple travel sites in one click.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 14 Nov 2005 15:43:47 -0800

Rajeev,

This would have been a good question to discuss in person.  I'm sorry
you didn't bring it up.

For IP FRR in general, a basic requirement is the ability to update
the associated next-hops of all affected prefixes in the required (<
50ms) timeframe.  One has to consider ECMP as well as the need to
store an alternate as close to the forwarding plane as possible.

For LFAs, that's basically all that is needed.

For U-turn alternates, one requires the ability to determine that a
packet has come in the same interface that it would normally be sent
out (probably triggered based on a U-turn label), and then based on
that, to select which next-hop to use.  Clearly, if one is using the
tagged mode, then a standard MPLS out-segment is required to tag the
outgoing u-turn packets.

For not-via, I believe that the idea is to support both LDP tunnels &
some form of IP-in-IP tunnels.  Mike & Stewart will, no doubt, have
more comments on that.  To support not-via requires, of course, a
large (depending on network size) number of additional /32 prefixes to
be handled.   Those prefixes must not be repaired in the event of
another failure, so the number of next-hop sets might increase a bit
(depending on your indirections).

Another complication currently suggested with not-via is the handling
of multi-homed prefixes where the locally attached prefix is more
expensive than going through the network, via the failed link, to
another router.  The not-via draft currently suggests recognizing the
encapsulated repair traffic & directing it to the locally attached
prefix.  Personally, I'm quite unclear on how the hardware might
recognize it (particularly when not destined to a not-via address) &
on the handling of the inter-area prefixes, because whether a prefix
is locally attached would then depend on what interface it was
received on.  Realistically, I'd expect this to be clarified or
removed at some point - although that would affect the 100% coverage
claim.

To summarize, I think that the work for LFAs is minimal & reasonably
well understandable from the draft.  I'd be happy to expand it if,
after discussion, you think there are parts that could be better
clarified.  For the advanced method, I believe it largely depends on
the advanced method, if any, that is finally selected.

Alia

On 11/14/05, Rajeev Manur <[email-masked]> wrote:
>
>
>
>
>
> All:
>
>
>
> I wanted to bring up this question in the Vancouver meeting, but never got
> the right context. At this point in time do have a consensus in the WG on
> data-path requirements needed to support IPFRR. I am sort of trying to see
> if there is a way to de-couple the data-path requirements and make them
> independent of the which approach we use in control plain to build the
> alternate routes. I see that some control plane solutions propose the use of
> tunnels to route the traffic around the failure point. Some appraoches
> suggest use of MPLS tunnels, while not-via suggests IP-in-IP etc...
>
>
>
> Is it a good idea to de-couple the data-path reqs and pubish them in a
> seperate dratf. This will help people working on next gen HW to make their
> HW compilant to future IPFRR solutions.
>
>
>
>
>
> With regards,
> Rajeev Manur
>
> Force10 Networks Inc
> Milpitas, CA - 95035
>
> Work : (408)-571-3511
> Mob : (408)-718-7370
>
>  ________________________________