On a side note, since the stable URL point is mentioned multiple times, it
seems to me that the IETF is already capable of providing a stable URL
including for draft. e.g.
https://tools.ietf.org/html/draft-ietf-grow-bmp-adj-rib-out
--Bruno
> -Original Message-
> From: GROW
> From: RFC Errata System [mailto:rfc-edi...@rfc-editor.org]
>
> The following errata report has been submitted for RFC8326,
> "Graceful BGP Session Shutdown".
>
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5402
>
Hi Susan,
Thanks for your time reviewing this document and you below comments.
Please see my replies inline [Bruno]
Note that however fast I'm answering to your review, that document is now in
RFC editor queue, and hence technical changes are much more difficult. (AFAIK,
would require
My 2 cents
> From: Job Snijders
>
[...]
> The AS_PATH attribute serves multiple functions: its length is used as a
> tie-breaker in best path selection, and the contents of the AS_PATH
> itself serves as an (mutable) track record on what administrative
> domains the announcement passed
> From: Smith, Donald [mailto:donald.sm...@centurylink.com]
> Sent: Thursday, December 14, 2017 6:13 PM
>
> I don't see anything around MD5/TCPAO authentication.
This is correct, but this is really not specific to this document and the
comment would apply to any information sent over BGP
Mirja,
Thanks for your review and comments.
Please see inline [Bruno]
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Mirja Kühlewind
> Sent: Thursday, December 14, 2017 2:06 PM
>
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-grow-bgp-gshut-12: No
Hi all,
-13 addresses the comments received so far during IESG review.
> A diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-bgp-gshut-13
Main comment is to change the category to Standard Tracks.
As a side effect, document needs another IETF LC (Std Track is 4 weeks,
Informational was
Hi Alvaro,
Thanks for your review and comments.
More inline [Bruno2]
> From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
> Sent: Thursday, December 14, 2017 3:56 PM
>
> [+Ben Campbell +Warren Kumari] (Explicitly adding Ben and Warren who
> expressed the same
>
[+Ben Campbell +Warren Kumari] (Explicitly adding Ben and Warren who expressed
the same comment)
Hi Alvaro,
Thanks for your review and comments.
More inline [Bruno]
> From: Alvaro Retana [mailto:aretana.i...@gmail.com]
> Sent: Thursday, December 14, 2017 4:28 AM
>
> Alvaro Retana has
Ben,
Thanks for your review and comments.
More inline. [Bruno]
> From: Ben Campbell [mailto:b...@nostrum.com]
>
> Ben Campbell has entered the following ballot position for
> draft-ietf-grow-bgp-gshut-12: Yes
>
> When responding, please keep the subject line intact and reply to all
>
Hi all,
Draft has been updated as per the latest comments and discussions on the list.
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-bgp-gshut-12
Changes are mostly editorial.
Regards,
--Bruno
> -Original Message-
> From:
Job,
> From: Job Snijders [mailto:j...@ntt.net]
> Sent: Tuesday, October 10, 2017 12:06 PM
>
> On Tue, Oct 10, 2017 at 09:56:45AM +, bruno.decra...@orange.com wrote:
> > > Minor issues:
> > >
> > > In Section 4. "EBGP graceful shutdown procedure", it states that 0
> > > can used in all
Hi all,
-11 has just been uploaded.
I believe it address all comments received so far: during WGLC and some private
comments afterward.
There have been significant editorial changes introduced, with a main goal to
put the focus on the Graceful BGP session shutdown itself, and reduce/remove
Hi all,
-10 addresses the comments received so far during the last call, including
off-list comments.
Thanks to John Heasley.
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-grow-bgp-gshut-10
> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-bgp-gshut-10
Hi Susan, all
> From Susan Hares
> Sent: Thursday, July 20, 2017 10:53 AM
>
> Job:
>
> If this solution was good was the best solution, there is no further work.
This is the case.
> If this solution was due to the slow progress of IDR, I'd like to know.
> We've been trying to fast
Hi all,
> draft: https://datatracker.ietf.org/doc/html/draft-ietf-grow-bgp-gshut-09
> diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-bgp-gshut-09
This version is expected to address all comments received.
>From a technical standpoint, the main changes are:
a) g-shut community is not
> From: Jakob Heitz (jheitz) [mailto:jhe...@cisco.com] > Sent: Wednesday, June
> 28, 2017 11:52 PM
>
> You're right Bruno. I misstated it.
>
> Still, node A will ever have no path available.
> Whether Gshut initiator sends gshut or withdraws, the result is the same:
> RR sends the new
> From: heasley [mailto:h...@shrubbery.net] > Sent: Thursday, June 29, 2017
> 8:28 PM
>
> Tue, Jun 27, 2017 at 01:14:34PM +, bruno.decra...@orange.com:
> >
> >
> > > From: heasley [mailto:h...@shrubbery.net] > Sent: Monday, June 26,
> > 2017 7:07 PM
> > > To: DECRAENE Bruno
Jakob,
> From: Jakob Heitz (jheitz) [mailto:jhe...@cisco.com]
> Sent: Wednesday, June 28, 2017 10:13 PM
>
> Bruno,
>
> > > If they are available to the gshut initiating router, then they
> > > are available to the other routers.
> >
> > Why?
>
> The advertising router advertised
Jakob,
> From: Jakob Heitz (jheitz) [mailto:jhe...@cisco.com]
> Sent: Wednesday, June 28, 2017 7:53 AM
>
> Bruno,
>
> To my mind, the purpose of graceful shutdown is to tease out the
> hidden paths before sending the withdraw. In your cases, the
> alternative paths are not hidden. They
Job,
> From: Job Snijders [mailto:j...@ntt.net]
> Sent: Monday, June 26, 2017 5:31 PM
>
> On Mon, Jun 26, 2017 at 02:14:19PM +, bruno.decra...@orange.com wrote:
> > > From: Job Snijders [mailto:j...@ntt.net]
> > > Sent: Thursday, June 22, 2017 10:47 PM
> >
> > [...]
> >
> > > the
Job,
> From: Job Snijders [mailto:j...@ntt.net] > Sent: Monday, June 26, 2017 5:39
> PM
>
> On Mon, Jun 26, 2017 at 01:58:40PM +, bruno.decra...@orange.com wrote:
> > Hi Job, all
> >
> > > From: Job Snijders [mailto:j...@ntt.net] > Sent: Thursday, June 22,
> > > 2017 10:47 PM
> >
> From: heasley [mailto:h...@shrubbery.net] > Sent: Monday, June 26, 2017
> 7:07 PM
> To: DECRAENE Bruno IMT/OLN
> Cc: grow@ietf.org
> Subject: Re: [GROW] draft-ietf-grow-bgp-gshut
>
> Mon, Jun 26, 2017 at 01:57:54PM +, bruno.decra...@orange.com:
> > > Suggestions:
> > >
> >
-08 address the comments received so far.
(minus the 2 technical points been discussed on 2 separate threads).
Thanks for the comments.
Regards,
Bruno
> -Original Message-
> From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of
> internet-
> dra...@ietf.org
>
Hi Job ,all
> From: Job Snijders [mailto:j...@ntt.net]
> Sent: Thursday, June 22, 2017 10:47 PM
[...]
> the place where the low local preference is set
> should move closer to the initiator of the gshut. Instead of setting
> the low LP on Adj-RIB-Out to IBGP neighbors, the low LP should be
Hi Job, all
> From: Job Snijders [mailto:j...@ntt.net] > Sent: Thursday, June 22, 2017
> 10:47 PM
[...]
> I think that the neighbor ASBR should _not_ strip the GSHUT well-known
> community.
I'm personally open to both options.
Discussing this further:
- First of all, stripping the g-shut
Hi Jakob,
Thanks for the comments.
Please see inline [Bruno]
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Jakob Heitz (jheitz)
> Sent: Monday, June 26, 2017 2:16 AM
>
> I agree with Job's proposals.
>
> In particular, the removal of the g-shut community should be carefully
>
Hi Job,
Thanks for the comments.
Please see inline [Bruno]
> From: Job Snijders [mailto:j...@ntt.net]
> Sent: Thursday, June 22, 2017 10:47 PM
>
> Dear working group,
>
> > > BGP g-shut (possible action for Bruno et al)
> > >
> > >
> > >
Hi all,
> From: Job Snijders [mailto:j...@ntt.net]
> Sent: Friday, May 26, 2017 4:05 PM
>
> Hi GROW,
>
> I've compiled a todo list to outline the next steps for the
> draft-ietf-grow-bgp-session-culling document.
>
[...]
> BGP g-shut (possible action for Bruno et al)
>
Hi Job,
> From: Job Snijders [mailto:j...@ntt.net] > Sent: Tuesday, June 13, 2017 1:41
> AM
>
> Dear Bruno, other gshut authors & GROW,
>
> If you'd like help editing draft-ietf-grow-bgp-gshut-06 to reflect the
> proposed changes discussed in the last 3 months in GROW, I'd be happy to
>
From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Friday, March 17, 2017 2:09 PM
To: DECRAENE Bruno IMT/OLN
Cc: Ben Maddison; grow@ietf.org
Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status?
[Bruno] The benefit of using a well-known community is that
Hi Robert,
From: Robert Raszuk
Sent: Friday, March 17, 2017 12:30 PM
Hi Ben & Bruno,
If we all agree community approach is the best for signalling to peer that this
prefix should be avoided why folks just do not do it today already ? Why do we
need IETF draft for that :) ?
If this is about
Hi Robert,
From: Robert Raszuk
Hi Bruno,
[Bruno] The goal was to be able to use gshut even if both EBGP peer are not
enhanced to support it. The benefit of flagging routes with a community is that
gshut may be implemented on vanilla routers using a BGP route map/policy.
Sure thing. However
Hi Robert,
Please see inline [Bruno]
From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Friday, March 17, 2017 9:42 AM
To: DECRAENE Bruno IMT/OLN
Cc: grow@ietf.org
Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status?
Bruno,
BGP session can carry multiple
> From: Job Snijders [mailto:j...@instituut.net] > Sent: Wednesday, March 15,
> 2017 4:37 PM
>
> On Tue, Mar 14, 2017 at 04:55:25PM +0100, Gert Doering wrote:
> > On Tue, Mar 14, 2017 at 04:49:10PM +0100, Job Snijders wrote:
> > > On Tue, Mar 14, 2017 at 04:41:06PM +0100, Gert Doering wrote:
Thanks for the useful feedback.
--Bruno
> -Original Message-
> From: Ben Maddison [mailto:b...@workonline.co.za]
> Sent: Wednesday, March 15, 2017 4:23 PM
> To: Job Snijders; DECRAENE Bruno IMT/OLN
> Cc: grow@ietf.org
> Subject: RE: [GROW] draft-ietf-grow-bgp-gshut status?
>
> I
Hi Job,
Thanks for the feedback.
More inline
> From: Job Snijders [mailto:j...@ntt.net] > Sent: Wednesday, March 15, 2017
> 3:54 PM
>
> Hi Bruno,
>
> On Wed, Mar 15, 2017 at 02:00:37PM +, bruno.decra...@orange.com wrote:
> > > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of
> From: Job Snijders [mailto:j...@instituut.net]
>
> On Tue, Mar 14, 2017 at 02:28:56PM +, bruno.decra...@orange.com wrote:
> > > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of heasley
> > >
> > > Mon, Mar 13, 2017 at 02:07:21AM +0100, Alejandro Acosta:
> > > > What do you
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of heasley
>
> Mon, Mar 13, 2017 at 02:07:21AM +0100, Alejandro Acosta:
> > What do you think in including also some suggestions when bringing up
> > the BGP sessions?. Sometimes it´s good idea to bring them up one by one
> > or something
I support the draft.
I also support Jeff's idea to re-use existing sub-code(s).
1 possible comment: the length of the "Shutdown Communication" field seems
implied from the length of the data field, rather than being explicitly
indicated. If so, it seems that we are closing the possibility to
Hi all,
I've not been following the discussion in all details, sorry for this.
IINM, one comment was that it would be safer to use a non-transitive BGP
community.
In which case, you may be interested in the following draft which proposes to
define "well known" non-transitive communities based
From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Randy Bush Sent:
Friday, June 26, 2015 12:23 AM
hi pierre
I have the feeling you represent the general opinion on this.
in theory, with brownian motion, all the molecules of are can end up in one
corner of the room. it's just
FYI. Might be of interest of IDR GROW WG
-Original Message-
From: IETF-Announce [mailto:ietf-announce-boun...@ietf.org] On Behalf Of
rfc-edi...@rfc-editor.org
Sent: Thursday, February 19, 2015 12:03 AM
To: ietf-annou...@ietf.org; rfc-d...@rfc-editor.org
Cc: op...@ietf.org;
Hello,
Support.
draft-ietf-grow-filtering-threats documents operational issues/surprises that
may happen with route filtering. This is useful to document and be able to
reference.
Nits:
- the document uses, as example, the prefix 10.0.0.0/24 (from rfc 1918) while
IMO it should use a block
Hello,
Support.
Thanks,
Bruno
hello,
I would like to start a call for adoption of
draft-cardona-filtering-threats.
We have had two presentation on the
document, and a positive response at IETF 87 in berlin. Call for
adoption will end august 16, 2013.
If you haven't read the latest document
Hi Rob,
Thanks for your reply. More inline.
From: Rob Shakir [mailto:r...@rob.sh] Sent: Monday, January 28, 2013 7:49 PM
Hi Bruno,
Thanks for the review of this version of the draft. I've added some feedback
in-line as [rjs]. My apologies for the delay in responding.
On 8 Jan 2013, at 10:57,
Hi Rob, all,
Thanks for the updated document.
New version is definitely an improvement. Thanks for the work.
Please find below some comments.
1) Critical error (§3)
IMHO, the term critical error is mixing both technical/protocol
considerations (e.g. can't read the update) and
Robert, Tony,
Please find below some clarification regarding gshut
(draft-ietf-grow-bgp-gshut):
- the g-shut community in itself has no effect on BGP path selection
- when the eBGP session is being g-shut,
- on the iBGP side, routes (from the eBGP session beeing gshut) are
readvertised
Robert,
From: Robert Raszuk Sent: Wednesday, May 09, 2012 11:00 PM
Jeff,
I do not understand why we are not going to re-advertise good routes
with lowest local preference which would not result in holes of some
boxes understanding g-shut community and some not.
What you propose (using
Jeff, Tony,
From: Tony Li Sent: Wednesday, May 09, 2012 10:33 PM
On May 9, 2012, at 3:29 PM, Jeffrey Haas wrote:
Thank you. This seems to indicate that after a g-shut event, the neighbor
would continue to advertise the prefixes to its peers (albeit tagged with the
community). Wouldn't this
Robert,
[Changing the title of the thread to better reflect the subject]
From: Robert Raszuk [mailto:rob...@raszuk.net] Sent: Thursday, May 10, 2012
11:25 AM
Hello Bruno,
Excellent - this is exactly what we discussed in the past. But when I
read the draft before sending email yesterday
Robert,
From: Robert Raszuk [mailto:rob...@raszuk.net] Sent: Thursday, May 10, 2012
3:23 PM
Bruno,
2. On the iBGP side, (re-) advertises the path received over
the eBGP session being shutdown with a low LOCAL_PREF.
Sounds good.
Great.
Btw what is low ?
Low enough such as a backup
Jakob,
Thanks for your example.
For sure, if a router (partially) erase the AS PATH, we can have loops. So far,
I don't see how this is related to BGP error handling, not to mention to Jeff
proposition.
In more details, is B configured to enforce first AS?
- if so, it should detect the
From: Jakob Heitz [mailto:jakob.he...@ericsson.com] Sent: Wednesday, May 09,
2012 12:42 PM
The loop occurs because of an error in the update message:
The AS path was missing.
Well your original text was not that specific. I understood that the AS PATH
attribute was present but its length was
I have not read the new -to be posted- version, but since the draft is said to
be essentially identical, I guess my previously comments still hold unchanged.
http://www.ietf.org/mail-archive/web/grow/current/msg02119.html
Namely:
- As the document targets the use of non-globally- routable
Support.
Please find below some comments:
- As the document targets the use of non-globally- routable addressing
within the core of an SP network, do you think you could extend the
text to also include the use of public IP addresses (allocated to the
SP) not advertised to the Internet (for
Paul, all,
The can-suppress tag itself is an Extended Communities Attribute
[RFC4360] to be assigned by IANA
It seems like you only need a single community value for tagging a route as
can-suppress. But in the draft, it seems like your are requesting the IANA to
allocate a whole extended
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.
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
Hi,
http://www.ietf.org/internet-drafts/draft-ietf-grow-bgp-graceful-shutdow
n-requirements-01.txt
A new version of the BGP graceful shutdown requirement WG doc has been
submitted. No substantial modifications were made in the document,
except some changes in the authors section.
This document
Hi all,
Please find below a requirement draft from some service providers for the
graceful shutdown of BGP sessions.
In short, when a service provider needs to shutdown BGP sessions for
maintenance purposes, BGP behaves as if a failure occurred. During the
subsequent BGP convergence,
61 matches
Mail list logo
