[email protected]
[Top] [All Lists]

Re: Adopting draft-francois-ordered-fib-00.txt as a WG document

Subject: Re: Adopting draft-francois-ordered-fib-00.txt as a WG document
From: Alia Atlas
Date: Tue, 22 Nov 2005 00:18:09 -0800
On 11/22/05, Stewart Bryant <[email protected]> wrote:
> Joel M. Halpern wrote:
>
> > I am really uncomfortable with changing the general convergence
> > behavior of the routing protocols to handle the case when the human
> > knows he will shut things down.  If this were only triggered by a
> > special advertisement that indicated orderly shutdown, that might be
> > less bothersome.
> > Particularly, it seems strange to be talking about slowing convergence
> > when we are repeatedly being asked to speed up convergence.
> > Yours,
> > Joel M. Halpern
> >
> Please can we be clear that PLSN (which is of course a WG draft)
> has very similar properties -
>
> 1) It slows convergence to some extent (with as far as I can see
> - no mechanism to use signalling to accelerate)

true, but we are having discussions on how to handle the case where
there isn't an alternate. The added delay is substantially less than
what the Ordered FIB install would provide.  This affects the window
of vulnerability to another event happening.

> 2) Needs to be applied to all routers in the network

If one is looking for as full micro-loop protection as possible, then
it needs to be applied to all routers in the network.  It is, however,
very possible to do limited deployments and safely see the effects. 
Deploying PLSN on a router affects that router & its neighbors.  It's
more limited.  I don't see a similar incremental
deployment/functionality scenario with Ordered FIB.

> It therefore changes the convergence properties of the whole
> network, but it does not provide complete protection against
> all loops.
>
> If we have doubts as to whether we wish to change the convergence
> process,  maybe we should put the PLSN draft on hold?

Didn't we have this discussion a year ago?  What has changed?  Is it that you
have a greater level of confidence/understanding/experience with Ordered FIB?
Is it that because this is being proposed for maintenance, that the rather long
(diameter of the network x FIB install-time) convergence delays seem acceptable?
Is it that you've got a clearly written and articulated algorithm &
signaling changes
that consider the various corner cases?  Is it that you feel this is a
better complement
to not-via than PLSN & you only want to see one deployed?

Without new/additional information, I think this is going to head the same way
that the previous discussions have.  Could you provide a bit more insight into
your reasoning?

Alia

> Convergence dynamics can be safely modified when we are sure that
> that all traffic will continue to be safely delivered during the
> process. This is true IFF the old path is still functional or
> when ALL traffic that was previously using  it is protected.
>
> - Stewart
>
>
>
> > At 04:17 PM 11/21/2005, Olivier Bonaventure wrote:
> >
> >> Dear All,
> >>
> >> We would like to propose to consider draft-francois-ordered-fib-00.txt
> >> as a working group document. This draft was presented in Paris and no
> >> objections were raised. It proposes techniques to order the FIB updates
> >> in an IP network using a link state routing protocol to avoid transient
> >> forwarding loops. We believe that this draft is important for the fast
> >> reroute work done within this WG, but also as a standalone document.
> >> Measurements performed in IP networks show that planned topology changes
> >> are very common. For example, [1] reports that in the Sprint network,
> >> 20% of the topology changes are due to maintenance operations. We
> >> discussed this issue with several ISPs that confirmed that correctly
> >> handling the non-urgent topology changes was an important problem to be
> >> solved.
> >>
> >> You can find the current version of the draft on the IETF web site
> >> http://www.ietf.org/internet-drafts/draft-francois-ordered-fib-00.txt
> >>
> >> [1] Athina Markopoulou and Gianluca Iannaccone and Supratik
> >> Bhattacharyya and Chen-Nee Chuah and Christophe Diot (2004).
> >> Characterization of Failures in an IP Backbone.
> >> In: IEEE Infocom. Hong Kong. March 2004.
> >> http://ipmon.sprint.com/pubs_trs/trs/failure-characterization.pdf
> >>
> >> Best regards,
> >>
> >>
> >> Olivier Bonaventure
> >>
> >>
> >> --
> >> CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/
> >>
> >> _______________________________________________
> >> Rtgwg mailing list
> >> [email protected]
> >> https://www1.ietf.org/mailman/listinfo/rtgwg
> >
> >
> >
> > _______________________________________________
> > Rtgwg mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/rtgwg
> >
> >
>
> _______________________________________________
> Rtgwg mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rtgwg
>

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

<Prev in Thread] Current Thread [Next in Thread>