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

Reply via email to