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.
> 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.
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
> Regards,
>
> Greg
>
> > -----Message d'origine-----
> > De : grow-boun...@ietf.org [mailto:grow-boun...@ietf.org] De
> > la part de Christopher Morrow
> > Envoyé : mercredi 24 mars 2010 02:30
> > À : grow@ietf.org grow@ietf.org
> > 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
> > GROW@ietf.org
> > https://www.ietf.org/mailman/listinfo/grow
> >
> _______________________________________________
> 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
