Re: [GROW] draft-iops-grow-bgp-session-culling-00

[Jeffrey Haas]

On Wed, Mar 15, 2017 at 04:37:00PM +0100, Job Snijders wrote:
> I've come to understand that even if the remote party does not support
> gshut, at least in one direction there will be benefit (downpreffing of
> routes received from the BGP neighbor which is about to be shut down). 

This sort of "draining" behavior is pretty common when you can do it.  And
it's worth noting that most of what gshut needed was just a community people
were willing to use for such a depref.

> > Since the title of the draft is "session-culling" it feels somewhat
> > out of scope to go more into detail on gshut, but a reference might be
> > useful.
> 
> Perhaps if the gshut draft is revived, a reference indeed is appropiate.
> I may have been too soon in my dismissal. Ben Maddison aptly pointed out
> that gshut is part of Ben's Current Practices. :-)

Informational references say "go look at this time" not "you require this"
(normative).  You can refer to pretty much anything you want in
informational without impacting publication.

-- Jeff

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[bruno.decraene]

> 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:
 > > > > On Tue, Mar 14, 2017 at 03:07:32PM +, bruno.decra...@orange.com 
 > > > > wrote:
 > > > > > On a side note, I'd be interesting to know why reducing the
 > > > > > impact of the maintenance using gshut is not considered as worth
 > > > > > it, while it is for culling. Especially since the benefit of the
 > > > > > latter is 90 second (and configurable)  while the former is
 > > > > > minutes (and not configurable).
 > > > >
 > > > > How's the IXP operator going to introduce a gshut message into a
 > > > > BGP session between IXP customer A and IXP customer B?
 > > >
 > > > an IXP can't, and I am not under the impression that Bruno was
 > > > suggestion to do so. I took his comments as applicable to section 2.1
 > > >
 > > > this is why the proposed draft contains two angles: one for IXPs and one
 > > > for ISPs, each with their different nuances.
 > >
 > > Indeed, for a direct ISP-ISP link, and the maintenance being
 > > controlled by one of the peering parties, gshut would be a useful
 > > approach (if it's known that the other party has deployed it).
 > 
 > I've come to understand that even if the remote party does not support
 > gshut, at least in one direction there will be benefit (downpreffing of
 > routes received from the BGP neighbor which is about to be shut down).

You are right.
Most network usages are bidirectional, in which case improving one way has 
probably no benefit.
However, this may still be beneficial when:
- routing is asymmetric
- BGP convergence time is different in both directions (which is typically the 
case) and we can improve the slowest direction (typically the one receiving a 
higher number of routes, although hardware/software also plays a significant 
role)

 
 > > Since the title of the draft is "session-culling" it feels somewhat
 > > out of scope to go more into detail on gshut, but a reference might be
 > > useful.
 > 
 > Perhaps if the gshut draft is revived, a reference indeed is appropiate.

We will revive it, probably removing the non-transitive community part. 

Kind regards,
--Bruno

 > I may have been too soon in my dismissal. Ben Maddison aptly pointed out
 > that gshut is part of Ben's Current Practices. :-)
 > 
 > Kind regards,
 > 
 > Job

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[David Farmer]

On Tue, Mar 14, 2017 at 3:01 PM, Gert Doering  wrote:

> Hi,
>
> On Tue, Mar 14, 2017 at 02:29:01PM -0400, Christopher Morrow wrote:
> > we seem to be having quite the discussion on this document, ought it be a
> > WG draft ? should we vote to adopt? :)
>
> Yes, please make this a WG draft.  This is good stuff, it should have
> stronger backing than "individual submission".
>

+1



-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[Christopher Morrow]

err, I should have just mailed an adoption call :) I'll do that and note
that nick/gert/job all already voted 'yes'.

On Tue, Mar 14, 2017 at 4:02 PM, Nick Hilliard  wrote:

> Christopher Morrow wrote:
> > we seem to be having quite the discussion on this document, ought it be
> > a WG draft ? should we vote to adopt?
>
> I'd say it has a place as a wg doc.
>
> Nick
>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[Gert Doering]

Hi,

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:
> > On Tue, Mar 14, 2017 at 03:07:32PM +, bruno.decra...@orange.com wrote:
> > > On a side note, I'd be interesting to know why reducing the impact
> > > of the maintenance using gshut is not considered as worth it, while
> > > it is for culling. Especially since the benefit of the latter is
> > > 90 second (and configurable)  while the former is minutes (and not
> > > configurable).
> > 
> > How's the IXP operator going to introduce a gshut message into a BGP
> > session between IXP customer A and IXP customer B?
> 
> an IXP can't, and I am not under the impression that Bruno was
> suggestion to do so. I took his comments as applicable to section 2.1
> 
> this is why the proposed draft contains two angles: one for IXPs and one
> for ISPs, each with their different nuances.

Indeed, for a direct ISP-ISP link, and the maintenance being controlled
by one of the peering parties, gshut would be a useful approach (if
it's known that the other party has deployed it).

Since the title of the draft is "session-culling" it feels somewhat
out of scope to go more into detail on gshut, but a reference might
be useful.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[Job Snijders]

On Tue, Mar 14, 2017 at 04:41:06PM +0100, Gert Doering wrote:
> On Tue, Mar 14, 2017 at 03:07:32PM +, bruno.decra...@orange.com wrote:
> > On a side note, I'd be interesting to know why reducing the impact
> > of the maintenance using gshut is not considered as worth it, while
> > it is for culling. Especially since the benefit of the latter is
> > 90 second (and configurable)  while the former is minutes (and not
> > configurable).
> 
> How's the IXP operator going to introduce a gshut message into a BGP
> session between IXP customer A and IXP customer B?

an IXP can't, and I am not under the impression that Bruno was
suggestion to do so. I took his comments as applicable to section 2.1

this is why the proposed draft contains two angles: one for IXPs and one
for ISPs, each with their different nuances.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[Gert Doering]

Hi,

On Tue, Mar 14, 2017 at 03:07:32PM +, bruno.decra...@orange.com wrote:
> On a side note, I'd be interesting to know why reducing the impact
> of the maintenance using gshut is not considered as worth it, while
> it is for culling. Especially since the benefit of the latter is
> 90 second (and configurable)  while the former is minutes (and not
> configurable).

How's the IXP operator going to introduce a gshut message into a BGP
session between IXP customer A and IXP customer B?

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[Job Snijders]

On Tue, Mar 14, 2017 at 03:07:32PM +, bruno.decra...@orange.com wrote:
> > 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 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 like that, the idea is to make the device to fill out 
> the
>  > >  > > forwarding table, create cache, perform ARP lookups, ND, and so on. 
> To
>  > >  > > bring up all the session at once many times is not that good.
>  > >  >
>  > >  > I'd expect this to prolong and exacerbate the 'path hunting', while 
> the
>  > >  > min-advert-timer might help to squelch it if all sessions are enabled
>  > >  > at the same time - after the IGP settles, which is automatic in some
>  > >  > impl..
>  > >  >
>  > >  > randy, link to path hunting paper?  i can't seem to find it.
>  > >
>  > > For the BGP shut, in section 2.1. " Voluntary BGP Session Teardown
>  > > Recommendations" you could propose or at least reference BGP Graceful
>  > > shutdown https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06
>  > > In very short, it initiates the path hunting for the backup BGP path,
>  > > _before_ the withdraw of the nominal path. Tests have shown that 0
>  > > packet loss is achievable (assuming that within the AS, tunneling is
>  > > used in order to avoid micro-loops during iBGP convergence). But if
>  > > one is not targeting 0 packet loss, which is typically the case in the
>  > > Internet ecosystem, there is no requirement for tunneling.
>  > >
>  > > In short, over eBGP, routes to be withdrawned are tagged with a "well
>  > > known" community, in order to be de-preferred on the receiving side.
>  > >
>  > > Some vendors have automated this. But one may also do it manually
>  > > using BGP policies.
>  > 
>  > I appreciate the effort and thought that has gone into gshut, but I am
>  > not aware of actual deployments and as scuh certainly cannot vouch for
>  > using this method as a 'best current practise'. it may be a 'future best
>  > practise' - but that is not now.
> 
> Referencing does not necessarily imply recommending as BCP.
> 
> On a side note, I'd be interesting to know why reducing the impact of
> the maintenance using gshut is not considered as worth it, while it is
> for culling. Especially since the benefit of the latter is 90 second
> (and configurable)  while the former is minutes (and not
> configurable).

well, to be frank: because one is an existing practise, the other isn't?

But I'm not closing the door: BCPs can be enhanced over time, which
makes them a very useful vehicle for such ongoing betterment of
interconnection maintenance strategies. Perhaps when gshut is either a
commonly accepted practise, and maybe has a different document status it
would be good to add it to the toolbox.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[Job Snijders]

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 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 like that, the idea is to make the device to fill out the
>  > > forwarding table, create cache, perform ARP lookups, ND, and so on. To
>  > > bring up all the session at once many times is not that good.
>  > 
>  > I'd expect this to prolong and exacerbate the 'path hunting', while the
>  > min-advert-timer might help to squelch it if all sessions are enabled
>  > at the same time - after the IGP settles, which is automatic in some
>  > impl..
>  > 
>  > randy, link to path hunting paper?  i can't seem to find it.
> 
> For the BGP shut, in section 2.1. " Voluntary BGP Session Teardown
> Recommendations" you could propose or at least reference BGP Graceful
> shutdown https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06
> In very short, it initiates the path hunting for the backup BGP path,
> _before_ the withdraw of the nominal path. Tests have shown that 0
> packet loss is achievable (assuming that within the AS, tunneling is
> used in order to avoid micro-loops during iBGP convergence). But if
> one is not targeting 0 packet loss, which is typically the case in the
> Internet ecosystem, there is no requirement for tunneling.
>
> In short, over eBGP, routes to be withdrawned are tagged with a "well
> known" community, in order to be de-preferred on the receiving side.
> 
> Some vendors have automated this. But one may also do it manually
> using BGP policies.

I appreciate the effort and thought that has gone into gshut, but I am
not aware of actual deployments and as scuh certainly cannot vouch for
using this method as a 'best current practise'. it may be a 'future best
practise' - but that is not now.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[bruno.decraene]

> 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 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 like that, the idea is to make the device to fill out the
 > >  > > forwarding table, create cache, perform ARP lookups, ND, and so on. To
 > >  > > bring up all the session at once many times is not that good.
 > >  >
 > >  > I'd expect this to prolong and exacerbate the 'path hunting', while the
 > >  > min-advert-timer might help to squelch it if all sessions are enabled
 > >  > at the same time - after the IGP settles, which is automatic in some
 > >  > impl..
 > >  >
 > >  > randy, link to path hunting paper?  i can't seem to find it.
 > >
 > > For the BGP shut, in section 2.1. " Voluntary BGP Session Teardown
 > > Recommendations" you could propose or at least reference BGP Graceful
 > > shutdown https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06
 > > In very short, it initiates the path hunting for the backup BGP path,
 > > _before_ the withdraw of the nominal path. Tests have shown that 0
 > > packet loss is achievable (assuming that within the AS, tunneling is
 > > used in order to avoid micro-loops during iBGP convergence). But if
 > > one is not targeting 0 packet loss, which is typically the case in the
 > > Internet ecosystem, there is no requirement for tunneling.
 > >
 > > In short, over eBGP, routes to be withdrawned are tagged with a "well
 > > known" community, in order to be de-preferred on the receiving side.
 > >
 > > Some vendors have automated this. But one may also do it manually
 > > using BGP policies.
 > 
 > I appreciate the effort and thought that has gone into gshut, but I am
 > not aware of actual deployments and as scuh certainly cannot vouch for
 > using this method as a 'best current practise'. it may be a 'future best
 > practise' - but that is not now.

Referencing does not necessarily imply recommending as BCP.

On a side note, I'd be interesting to know why reducing the impact of the 
maintenance using gshut is not considered as worth it, while it is for culling. 
Especially since the benefit of the latter is 90 second (and configurable)  
while the former is minutes (and not configurable).

Kind regards,
--Bruno

 > Kind regards,
 > 
 > Job

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[bruno.decraene]

> 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 like that, the idea is to make the device to fill out the
 > > forwarding table, create cache, perform ARP lookups, ND, and so on. To
 > > bring up all the session at once many times is not that good.
 > 
 > I'd expect this to prolong and exacerbate the 'path hunting', while the
 > min-advert-timer might help to squelch it if all sessions are enabled
 > at the same time - after the IGP settles, which is automatic in some
 > impl..
 > 
 > randy, link to path hunting paper?  i can't seem to find it.

For the BGP shut, in section 2.1. " Voluntary BGP Session Teardown 
Recommendations" you could propose or at least reference BGP Graceful shutdown 
https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06
In very short, it initiates the path hunting for the backup BGP path, _before_ 
the withdraw of the nominal path. Tests have shown that 0 packet loss is 
achievable (assuming that within the AS, tunneling is used in order to avoid 
micro-loops during iBGP convergence). But if one is not targeting 0 packet 
loss, which is typically the case in the Internet ecosystem, there is no 
requirement for tunneling.

In short, over eBGP, routes to be withdrawned are tagged with a "well known" 
community, in order to be de-preferred on the receiving side.

Some vendors have automated this. But one may also do it manually using BGP 
policies.

Regards,
--Bruno
 
 > ___
 > GROW mailing list
 > GROW@ietf.org
 > https://www.ietf.org/mailman/listinfo/grow

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[Nick Hilliard]

Job Snijders wrote:
> At this moment I'm inclined to consider such 'staggered gradual
> restoration' recommendations out of scope for this BCP. Mainly because I
> am not aware of a generic, currently in-use recommendations and the
> problem space might be somewhat undefined.

I'd suggest that ixp operators are able to make this sort of decision by
themselves.

Nick

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[Job Snijders]

On Mon, Mar 13, 2017 at 02:07:21AM +0100, Alejandro Acosta wrote:
> Excellent idea to write this down.  Congrats to the authors.

Thanks!

> 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 like that, the idea is to make the device to fill out the
> forwarding table, create cache, perform ARP lookups, ND, and so on. To
> bring up all the session at once many times is not that good.

At this moment I'm inclined to consider such 'staggered gradual
restoration' recommendations out of scope for this BCP. Mainly because I
am not aware of a generic, currently in-use recommendations and the
problem space might be somewhat undefined.

While I do know that staggered restoration was sometimes applied back in
the day (when the majority of backbone routers was cisco 7100-style
devices), and usually arranged manually through phonecalls, I'm not so
sure whether this still is in vogue.

Kind regards,

Job

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[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 like that, the idea is to make the device to fill out the
> forwarding table, create cache, perform ARP lookups, ND, and so on. To
> bring up all the session at once many times is not that good.

I'd expect this to prolong and exacerbate the 'path hunting', while the
min-advert-timer might help to squelch it if all sessions are enabled
at the same time - after the IGP settles, which is automatic in some
impl..

randy, link to path hunting paper?  i can't seem to find it.

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[Gert Doering]

Hi,

On Mon, Mar 13, 2017 at 09:33:45AM +0100, Mikael Abrahamsson wrote:
> Also, do we know why still so few use BFD on IXPs? Since all other 
> mechanisms apart from BFD lacked consensus (there were L2 reporting 
> protocol proposals I remember from 10+ years back), it would be great if 
> BFD was actually deployed more.

Right.  Speaking for ourselves: until not so long ago, our routers
were just not capable of sustaining 100+ BFD sessions with usefully
short timers - we now have better peering boxes, so maybe it's time
to start talking to peers and spread the word.

That's the other part - knowledge of the peer operators at a typical
IXP is reaching new all-time lows every year, so having something that
will do the right thing on the fabric operators's side is much less work
than negotiating anything exceeding basic BGP setup with 100+ peers...


Gert Doering
   "disgruntled old fart..."
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[Mikael Abrahamsson]

On Mon, 13 Mar 2017, Gert Doering wrote:


Hi,

On Sun, Mar 12, 2017 at 11:16:55PM +0100, Job Snijders wrote:

With this BCP Internet-Draft we hope to draw some attention to good
practises which can be applied by IP networks or IXPs to mitigate
negative impact caused by maintenance operations on lower layer
networks. The idea is to promote the concept of breaking the
control-plane in a controlled fashion, before actually breaking the
data-plane.


I like the concept.

Wording-wise, there is room for misunderstanding in the current version,
2.2.1:


2.2.1.  Packet Filter Considerations

  The packet filter should be designed and specified in a way that:

  o  only affect link-local BGP traffic i.e. forming part of the
 control plane of the system described, rather than multihop BGP
 which merely transits


it says "link-local", but what it wants is not "fe80::" but "the prefixes
the intermediate network uses for on-link peering" (plus, maybe, fe80::).

So maybe "only affect *on-link* BGP traffic"?


Good catch. Perhaps "intra on-link subnet BGP traffic" or something like 
that? "link-local" should not be used as a term though, I agree that might 
cause confusion.


Great work writing this down, hope more operators and IXPs implement these 
procedures.


Also, do we know why still so few use BFD on IXPs? Since all other 
mechanisms apart from BFD lacked consensus (there were L2 reporting 
protocol proposals I remember from 10+ years back), it would be great if 
BFD was actually deployed more.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[Gert Doering]

Hi,

On Sun, Mar 12, 2017 at 11:16:55PM +0100, Job Snijders wrote:
> With this BCP Internet-Draft we hope to draw some attention to good
> practises which can be applied by IP networks or IXPs to mitigate
> negative impact caused by maintenance operations on lower layer
> networks. The idea is to promote the concept of breaking the
> control-plane in a controlled fashion, before actually breaking the
> data-plane.

I like the concept.

Wording-wise, there is room for misunderstanding in the current version,
2.2.1:


2.2.1.  Packet Filter Considerations

   The packet filter should be designed and specified in a way that:

   o  only affect link-local BGP traffic i.e. forming part of the
  control plane of the system described, rather than multihop BGP
  which merely transits


it says "link-local", but what it wants is not "fe80::" but "the prefixes
the intermediate network uses for on-link peering" (plus, maybe, fe80::).

So maybe "only affect *on-link* BGP traffic"?

[..]
> ps. Some may point out that this is a rampant layering violation, to which I
> will say: "yes". ;-)

And a useful one :-)

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] draft-iops-grow-bgp-session-culling-00

[Alejandro Acosta]

Excellent idea to write this down.  Congrats to the authors.

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 like that, the idea is to make the device to fill out the
forwarding table, create cache, perform ARP lookups, ND, and so on. To
bring up all the session at once many times is not that good.


Alejandro,


El 12/3/17 a las 11:16 p.m., Job Snijders escribió:
> Dear GROW,
>
> With this BCP Internet-Draft we hope to draw some attention to good
> practises which can be applied by IP networks or IXPs to mitigate
> negative impact caused by maintenance operations on lower layer
> networks. The idea is to promote the concept of breaking the
> control-plane in a controlled fashion, before actually breaking the
> data-plane.
>
> Regarding the "Voluntary BGP Session Teardown Recommendations" - we all
> too often see operators do the equivalent of 'yanking the cable out of
> its socket' while not allowing any time for reconvergence. As far as I
> am aware, there is no documentation which recommends to shutdown BGP
> sessions and allow for some time for the traffic to subside due to
> rerouting, and then commence with the maintenance.
>
> Some background on the "Involuntary BGP Session Teardown
> Recommendations": a number of years ago an (at the time novel) approach
> was presented on how to reduce the negative impact of IXP maintenance.
> Since then the idea gained popularity and is applied at more and more
> IXPs. The video + pdf are available here:
> https://ripe67.ripe.net/archives/video/116/
>
> The approaches outlined in this document may not be required in every
> network topology, for instance some IXPs have fantastic 'make before
> break' methodologies accomplished through a layer of photonic switches.
>
> I'd like to ask the chairs for a 10 minute slot in GROW's session at
> IETF 98 to present on this draft.
>
> Kind regards,
>
> Job
>
> ps. Some may point out that this is a rampant layering violation, to which I
> will say: "yes". ;-)
>
> - Forwarded message from internet-dra...@ietf.org -
>
> Date: Sun, 12 Mar 2017 14:00:18 -0700
> From: internet-dra...@ietf.org
> To: i-d-annou...@ietf.org
> Subject: I-D Action: draft-iops-grow-bgp-session-culling-00.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
> Title   : Mitigating Negative Impact of Maintenance through 
> BGP Session Culling
> Authors : Will Hargrave
>   Matt Griswold
>   Job Snijders
>   Nick Hilliard
>   Filename: draft-iops-grow-bgp-session-culling-00.txt
>   Pages   : 9
>   Date: 2017-03-12
>
> Abstract:
>This document outlines an approach to mitigate negative impact on
>networks resulting from maintenance activities.  It includes guidance
>for both IP networks and Internet Exchange Points (IXPs).  The
>approach is to ensure BGP-4 sessions affected by the maintenance are
>forcefully torn down before the actual maintenance activities
>commence.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-iops-grow-bgp-session-culling/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-iops-grow-bgp-session-culling-00
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> - End forwarded message -
>
> ___
> 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