Subject: draft-bryant-shand-lf-applicability-00

From: Alia Atlas <[email-masked]>
Date: Wed, 6 Jul 2005 10:42:13 -0400

Stewart & Mike,

In general, I think that the idea of clearly specifying the
applicability is good.  What I think would also still be good to
capture is the set of cases that are NOT applicable.  This is within
the context of the IGP as well as, possibly, without.  For instance,
traffic micro-loops to a new prefix will not be handled.  Similarly,
clarifying when & whether the single failure assumption needs to apply
& how this interacts with the multiple areas would be useful.

The interactions of other protocols with the IGP may be usefully
discussed as well.  For instance, the IGP controlled convergence may
prevent (or reduce) micro-loops for BGP destinations as long as BGP
itself doesn't need to make a new policy decision.

On a slightly more detailed note, in the draft, you discuss the
possible use of the incremental cost update mechanism for the
management withdrawal of a component.  I'm curious why you thought
this was more applicable here.  One of the issues with the incremental
cost update mechanism was how long it left the network vulnerable to
another change.  I don't see that the cause for that change reduces
the problems with a long vulnerability window.

Alia

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

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 06 Jul 2005 16:28:21 +0100

Alia Atlas wrote:

> applicability is good.  

Yes and in particular I think that we need to raise awareness
in the MPLS WG and the OPS area.

> What I think would also still be good to
> traffic micro-loops to a new prefix will not be handled.  

Surely a new prefix is good news and the good news mechanism
can be applied to that prefix without disrupting other traffic?

Perhaps we need a number of classes of service

Catastrophy - what IPFRR has addressed today
External change - prefixes come and go outside our area, or AS
Management action - human induced changes

Clearly Catastrophy trumps everything else, but for example
manual change can be more leasurely, and aborted in the face
of catastrophy.

> Similarly,

OK

> itself doesn't need to make a new policy decision.

Yes

> this was more applicable here.  

Incremnental cost is universal. It always works with a component
of any age. You rarely want to take a component out instantly,
and if you are too impatient you can always abort.

If a failure occurs, you suspend the incremental changes until
the network has recovered from the failure, and thenm carry on
where you left off.

> One of the issues with the incremental

This is an area than need some thought, but I thnk that the
vulnerability window is quite short because the incrementer will not
issue an inc LSP during a failure. This needs a bit more time
than I have this PM to work through all the cases.

Stewart