[GROW] RFC 8195 on Use of BGP Large Communities

2017-06-30 Thread rfc-editor 
A new Request for Comments is now available in online RFC libraries.


RFC 8195

Title:  Use of BGP Large Communities 
Author: J. Snijders, 
J. Heasley,
M. Schmidt
Status: Informational
Stream: IETF
Date:   June 2017
Mailbox:j...@ntt.net, 
h...@shrubbery.net, 
martijnschm...@i3d.net
Pages:  15
Characters: 33281
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-grow-large-communities-usage-07.txt

URL:https://www.rfc-editor.org/info/rfc8195

DOI:10.17487/RFC8195

This document presents examples and inspiration for operator
application of BGP Large Communities.  Based on operational
experience with BGP Communities, this document suggests logical
categories of BGP Large Communities and demonstrates an orderly
manner of organizing community values within them to achieve typical
goals in routing policy.  Any operator can consider using the
concepts presented as the basis for their own BGP Large Communities
repertoire.

This document is a product of the Global Routing Operations Working Group of 
the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

Re: [GROW] draft-ietf-grow-bgp-gshut

2017-06-30 Thread heasley 
Fri, Jun 30, 2017 at 03:26:08PM +, bruno.decra...@orange.com:
> > 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 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:
>  > >  > >  >
>  > >  > >  > OLD Abstract:
>  > >  > >  >This draft describes operational procedures aimed at reducing 
> the
>  > >  > >  >amount of traffic lost during planned maintenances of routers 
> or
>  > >  > >  >links, involving the shutdown of BGP peering sessions.
>  > >  > >  > NEW Abstract:
>  > >  > >  >This draft describes operational procedures aimed at reducing 
> the
>  > >  > >  >amount of traffic lost during planned maintenances of routers 
> or
>  > >  > >  >links, involving the shutdown of BGP peering sessions. 
> Additionally
>  > >  > >  >this document describes the use of a well-known Border Gateway
>  > >  > >  >Protocol (BGP) community to signal that a graceful shutdown 
> has been
>  > >  > >  >initiated for the tagged prefix.
>  > >  > >
>  > >  > > [Bruno] OK. Slightly reworded as "It defines a well-known BGP 
> community, called
>  > gshut, to
>  > >  > signal the graceful shutdown of paths to other Autonomous Systems."
>  > >  >
>  > >  > s/paths to other Autonomous Systems./a path in the presence of other 
> paths./
>  > >  >
>  > >  > ie: it does nothing when there is no other path and it may not move to
>  > >  > anoter AS, just to another path.  it is per-session, not per-AS.
>  > >
>  > > My sentence was misleading. Changing to: "It defines a well-known BGP 
> community,
>  > called g-shut, to signal over the EBGP session to be shutdown, the 
> graceful shutdown of
>  > paths."
>  > 
>  > As Jakob mentioned, its not ebgp-only, as it also addresses shutting an
>  > ibgp or an entire speaker.
> 
> The procedure is not limited to ebgp. However the BGP community is defined in 
> order to perform the signaling specifically over EBGP.
> Over IBGP, we use LOCAL_PREF to lower the preference of the route. Even if 
> the community may be kept for information.

you would still want to add the community; if you have no other path, you
still want the community to be on routes to remote eBGP peers, if you have
any in-bound iBGP policy that might affect the LP, you still want/need to
communicate to the ibgp peers.

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

Re: [GROW] draft-ietf-grow-bgp-gshut

2017-06-30 Thread bruno.decraene 
> 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 path to Node A.

In the end, yes.
But if the gshut initiator sends a withdraw to its RR, and its RR does not have 
the pre-knowledge of a backup path, the withdraw is first propagated to the RR 
clients.

However this is a corner case as it would assume the gshut initiator to know 
more IBGP paths than its RR.

Given that most people would prefer applying the low LOCAL_PREF on the gshut 
initiator itself, let's do this. Hopefully I'll upload a new version before the 
deadline (Monday)

Thanks for the feedback
--Bruno


 > Thanks,
 > Jakob.
 > 
 > 
 > > -Original Message-
 > > From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
 > > Sent: Wednesday, June 28, 2017 1:56 PM
 > > To: Jakob Heitz (jheitz) 
 > > Cc: grow@ietf.org
 > > Subject: RE: [GROW] draft-ietf-grow-bgp-gshut
 > >
 > > 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 it.
 > >  > Your example is iBGP. When one speaker advertises, the whole AS 
 > > receives it.
 > >
 > > If you assume an IBGP full mesh, I agree.
 > > If you have a Route Reflector topology, without add-path, I disagree.
 > > Only one path is advertised by the RR. We can always find a node A, in the 
 > > Initiator AS,
 > which uses the g-shut
 > > initiator as best path/Next Hop (otherwise, nobody uses the path 
 > > advertised by the g-
 > shut initiator, and there is no
 > > need for g-shut). That node A received a single path from its RR (the path 
 > > from the g-shut
 > initiator), hence it does
 > > not know an alternate path. Even if another node B advertises an alternate 
 > > path thanks
 > to best-external or by
 > > preferring its EBGP path over an IBGP path (both paths having the same 
 > > LOCAL_PREF,
 > aspath length, origin, MED)
 > >
 > >
 > >  > Now suppose because of some weirdness, not every speaker in the AS 
 > > receives it.
 > >  > Then even a gshut community isn't going to make a difference.
 > >  > Even after the gshut, this iBGP route isn't going to get any further.
 > >
 > > I'm not sure to follow your point.
 > > The route being gshut has a low local_pref hence the alternate route with 
 > > become best
 > and propagated across the AS.
 > >
 > > Thanks
 > > --Bruno
 > >  >
 > >  > Thanks,
 > >  > Jakob.
 > >
 > >
 > >
 > _
 > ___
 > > _
 > >
 > > 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.


_

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.

Re: [GROW] draft-ietf-grow-bgp-gshut

2017-06-30 Thread bruno.decraene 
> 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 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:
 > >  > >  >
 > >  > >  > OLD Abstract:
 > >  > >  >This draft describes operational procedures aimed at reducing 
 > > the
 > >  > >  >amount of traffic lost during planned maintenances of routers or
 > >  > >  >links, involving the shutdown of BGP peering sessions.
 > >  > >  > NEW Abstract:
 > >  > >  >This draft describes operational procedures aimed at reducing 
 > > the
 > >  > >  >amount of traffic lost during planned maintenances of routers or
 > >  > >  >links, involving the shutdown of BGP peering sessions. 
 > > Additionally
 > >  > >  >this document describes the use of a well-known Border Gateway
 > >  > >  >Protocol (BGP) community to signal that a graceful shutdown has 
 > > been
 > >  > >  >initiated for the tagged prefix.
 > >  > >
 > >  > > [Bruno] OK. Slightly reworded as "It defines a well-known BGP 
 > > community, called
 > gshut, to
 > >  > signal the graceful shutdown of paths to other Autonomous Systems."
 > >  >
 > >  > s/paths to other Autonomous Systems./a path in the presence of other 
 > > paths./
 > >  >
 > >  > ie: it does nothing when there is no other path and it may not move to
 > >  > anoter AS, just to another path.  it is per-session, not per-AS.
 > >
 > > My sentence was misleading. Changing to: "It defines a well-known BGP 
 > > community,
 > called g-shut, to signal over the EBGP session to be shutdown, the graceful 
 > shutdown of
 > paths."
 > 
 > As Jakob mentioned, its not ebgp-only, as it also addresses shutting an
 > ibgp or an entire speaker.

The procedure is not limited to ebgp. However the BGP community is defined in 
order to perform the signaling specifically over EBGP.
Over IBGP, we use LOCAL_PREF to lower the preference of the route. Even if the 
community may be kept for information.

Thanks,
Regards,
--Bruno

_

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