Hi Rob, > From: grow-boun...@ietf.org [mailto:grow-boun...@ietf.org] On Behalf Of > Rob Shakir > Sent: Thursday, April 08, 2010 1:44 PM > > Hi All, > > On 8 Apr 2010, at 11:41, <gregory.cauc...@orange-ftgroup.com> > <gregory.cauc...@orange-ftgroup.com> wrote: > > > I want to express my support to this draft. In a provider's life, > planned maintenance operations on routers impacting BGP sessions is a > common thing. As a consequence, we (providers) will clearly benefit from a > solution able to lower as much as possible the impact of such operations > on our clients' traffic (and not to mention the smarter behaviour of make- > before-break requirements instead of the actual "shouting on one-self's > foot"). > > I'd like to express support too -- the discussion of this type of > mechanism is definitely something that would provide a benefit to > operators during maintenance events.
Thanks for your support. > > I however have two comments regarding this draft: > > > > 1 - Unlike the problem statement section, I find the introduction > section a little bit unclear. I would suggest to rephrase it with a simple > description of what is a "planned maintenance" in providers life, why/when > this is performed, and then talk about the consequences of such event on > traffic as BGP does not offer today any "make-before-break" tool. Most of > this is already in the draft but in the background, so I would like this > doc to make clear that we provoke the loss of traffic when performing > maintenance operations and that's why we need a smarter behaviour _à la_ > make-before-break for the whole duration (ie session down and up event) of > the operation. > > Is there a requirement to describe why/when maintenance is required? The > mere statement that there is a requirement to shut down a BGP session > should be enough to give some background to there being a M-B-B type > requirement. I tend to agree with your point. Yet, during discussions around this draft, there has sometimes been a need to provide some additional context. For example to stress that some maintenance do require the shutdown of a BGP session and hence Graceful Restart / Non Stop Routing / In Service Software Upgrade does not address the requirement. Or that the shutdown or even the establishment of a BGP session may triggers traffic loss (even if for some Internet traffic this may not be an issue and hence is not noticed). So I slightly reworded and expanded the 4th paragraph of the introduction to better express these 2 points and address Gregory's point for a clearer introduction. I hope this is fine for you. Thanks, Best regards, Bruno > I'm not entirely sure that there's value in expanding the > introduction to include this kind of detail, that is not necessarily of > direct relevance to the problem at hand. > Kind regards, > Rob > > -- > Rob Shakir <r...@eng.gxn.net> > Network Development Engineer GX Networks/Vialtus Solutions > ddi: +44208 587 6077 mob: +44797 155 4098 > pgp: 0xc07e6deb nic-hdl: RJS-RIPE > > This email is subject to: http://www.vialtus.com/disclaimer.html > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow