Subject: Re: [GROW] Working group last call for:draft-ietf-grow-bgp-graceful-shutdown-requirements

From: <[email-masked]>
Date: Thu, 8 Apr 2010 12:41:42 +0200

Hi all,

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 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.

2 - For the topologies used as examples, it is stated for e-BGP topologies that "The requirements of section 5 should be applicable to:" and for i-BGP topologies that "some frequent i-BGP topologies that SHOULD be supported". I am uncomfortable with the use of SHOULD here as, as far as I understand it, it makes all the requirements expressed in section 5 not so "mandatory" any more. Is my understanding wrong or shall we strengthen the verb ?

Regards,

Greg

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de Christopher Morrow
> Envoyé : mercredi 24 mars 2010 02:30
> À : [email-masked] [email-masked]
> Objet : [GROW] Working group last call 
> for:draft-ietf-grow-bgp-graceful-shutdown-requirements
> 
> Howdy,
> This came up at the Hiroshima meeting, there was minimal/no 
> conversation on the list about it, seemingly this means folks 
> don't disagree, so...
> 
> This is to start the GROW WG Last Call on advancing 
> draft-ietf-grow-bgp-graceful-shutdown-requirements-01.txt as 
> an Informational RFC. The deadline for comments is April 14, 2010.
> 
> A URL for the draft is:
> <http://tools.ietf.org/html/draft-ietf-grow-bgp-graceful-shutd
> own-requirements-01>
> 
> --chris and Peter
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: Rob Shakir <[email-masked]>
Date: Thu, 8 Apr 2010 12:44:14 +0100

Hi All,

> 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 b…

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.

> 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 provid…

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'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                      <[email-masked]>
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

---

From: <[email-masked]>
Date: Fri, 30 Apr 2010 18:28:29 +0200

Hi Rob,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rob Shakir
> Sent: Thursday, April 08, 2010 1:44 PM
> 
> Hi All,
> 
> On 8 Apr 2010, at 11:41, <[email-masked]>
> <[email-masked]> 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.
 
> > 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.

---

From: <[email-masked]>
Date: Fri, 30 Apr 2010 18:28:52 +0200

Hi Gregory,

> Hi all,
> 
> 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").

Thanks for your support.
 
> 1 - Unlike the problem statement section, I find the introduction section
> a little bit unclear. I would suggest to rephrase it with a simple

Ok. I changed the 4th paragraph of the introduction accordingly:

"   Currently, [BGP] and [MP-BGP] do not include any operation to 
   gracefully withdraw a prefix while traffic toward that prefix could 
   still be correctly forwarded. When a BGP session is taken down, BGP 
   behaves as if it was a sudden link or router failure and withdraws 
   the prefixes learnt over that session, which may trigger traffic 
   loss. There is no mechanism to advertise to its BGP peers that the 
   prefix will soon be unreachable, while still being reachable. When 
   applicable, such mechanism would reduce or prevent traffic loss. It 
   would typically be applicable in case of a maintenance operation 
   requiring the shutdown of a forwarding resource. Typical examples 
   would be a link or line card maintenance, replacement or upgrade. It 
   may also be applicable for a software upgrade as it may involve a 
   firmware reset on the line cards and hence forwarding interruption."

> 2 - For the topologies used as examples, it is stated for e-BGP topologies
> that "The requirements of section 5 should be applicable to:" and for i-
> BGP topologies that "some frequent i-BGP topologies that SHOULD be
> supported".

I rephrased the introduction sentence for the e-BGP and i-BGP topologies.
They are now more homogeneous:

" 6.1. E-BGP topologies 
    
   We describe here some frequent eBGP topologies that SHOULD be 
   supported by the solution. "

" 6.2. I-BGP topologies 
    
   We describe here some frequent iBGP topologies that SHOULD be 
   supported by the solution. "

> I am uncomfortable with the use of SHOULD here as, as far as I
> understand it, it makes all the requirements expressed in section 5 not so
> "mandatory" any more. Is my understanding wrong or shall we strengthen the
> verb ?

 I think "SHOULD" is more appropriate than "MUST":
 - Most people would prefer a lightweight solution even if it does not 
 address all requirements or BGP topologies.
 - A given ISP may be interested by only a subset of the topologies (e.g.
 not using BGP confederation)

Following your comment, I added the following last 2 sentences in the draft:

"6.	Reference Topologies

[...]

However, solutions SHOULD be applicable to all possible BGP topologies and not only to these below examples. Note that this is a "SHOULD" rather than a "MUST" as a partial lightweight solution may be preferred to a full but more complex solution. Especially since some ISP may not be concerned by some topologies (e.g. confederations)."

Next version of the draft (-02), submitted today, reflect the above change.

Thanks,
Best regards,
Bruno