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

Hi Robert,

Please see inline [Bruno]

From: rraszuk@gmail.com [mailto:rraszuk@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 messages. One is UPDATE MSG

Why do you want to nest indicator about session going down in the UPDATE msg rather then just using new NOTIFICATION subcode say "Gracefull shutdown" ?

Clearly it would not be backwards compatible but I guess this is no longer a goal is it ?

[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. Incremental deployment in a benefit, in particular between AS/organisations, and in particular on small/low end routers which are not replaced every 4 years.

The issue with sending it in UPDATE MSG is that you effectively need to re-advertise the entire table just before going down which will in turn could cause more churn in your peer's ASes and beyond.

[Bruno] There is no issue. The goal _is_ to trigger BGP path hunting in search for the back up path, before shutting down the BGP session:
- If the remote EBGP peer is already aware of the back up route, the message/churn is not propagated in the peer’s ASes not beyond
- If the remote EBGP peer is not aware of the back up route, the message/churn is indeed propagated in the peer’s ASes and possibly beyond, but that is the goal and the feature. Note that this is also the case when you perform a vanilla BGP shut. There is no free lunch: you do need to search for the back up paths.
Plus with gshut, you replace “urgent” BGP message by non-urgent BGP messages.

Or do you want to came back to concept of defining a beacon prefix acting as semaphore for entire session :)
[Bruno] No. This is not what is described in the draft.

Cheers,
--Bruno

Cheers,
R.

On Wed, Mar 15, 2017 at 4:26 PM, <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> wrote:
Thanks for the useful feedback.

--Bruno

 > -----Original Message-----
 > From: Ben Maddison [mailto:benm@workonline.co.za<mailto:benm@workonline.co.za>]
 > Sent: Wednesday, March 15, 2017 4:23 PM
 > To: Job Snijders; DECRAENE Bruno IMT/OLN
 > Cc: grow@ietf.org<mailto:grow@ietf.org>
 > Subject: RE: [GROW] draft-ietf-grow-bgp-gshut status?
 >
 > I would be very happy with that outcome.
 > We've been using this for ages, and would like to see it work more widely in our adjacent
 > networks.
 >
 > Although not truly a fix for the transitivity problem, when we match on gshut from a peer, in
 > addition to setting a lower-than-usual LP, we also append no-export, which prevents gshut-
 > ed prefixes from leaking at all.
 > I've never been hugely worried about the security consequences otherwise.
 >
 > Cheers,
 >
 > Ben Maddison
 >
 > Director
 > Workonline Communications (Pty) Ltd
 >
 > Office:     +27 (0) 21 200 9000<tel:%2B27%20%280%29%2021%20200%209000>
 > Mobile:   +27 (0) 82 415 5545<tel:%2B27%20%280%29%2082%C2%A0415%205545>
 > Email:      benm@workonline.co.za<mailto:benm@workonline.co.za>
 > SIP:          benm@workonline.co.za<mailto:benm@workonline.co.za>
 >
 >
 >
 >
 > -----Original Message-----
 > From: GROW [mailto:grow-bounces@ietf.org<mailto:grow-bounces@ietf.org>] On Behalf Of Job Snijders
 > Sent: Wednesday, March 15, 2017 4:54 PM
 > To: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>
 > Cc: grow@ietf.org<mailto:grow@ietf.org>
 > Subject: Re: [GROW] draft-ietf-grow-bgp-gshut status?
 >
 > Hi Bruno,
 >
 > On Wed, Mar 15, 2017 at 02:00:37PM +0000, bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> wrote:
 > > > From: GROW [mailto:grow-bounces@ietf.org<mailto:grow-bounces@ietf.org>] On Behalf Of Job Snijders
 > > > > Sent: Wednesday, March 15, 2017 2:11 PM
 > > >
 > > > I noticed that
 > > > https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06
 > > > expired two years ago. Can anyone offer some insight why it lapsed?
 > >
 > > In order to signal the graceful shutdown over the EBGP session, gshut
 > > uses a "well-know" BGP community. Compared to using a protocol
 > > extension, this allows a vanillia sender/receiver to handle the
 > > information using a regular BGP policy.
 > > So far so good. This is specified, implemented both with BGP policy
 > > and automated by some routers, tested (both options).
 > >
 > > Now, for some deployments, the use of a non-transitive community offer
 > > a better assurance that the community has indeed be originated by the
 > > connected eBGP peer. The issue is that currently there is no
 > > implementation of non-transitive well-known communities.
 > > draft-ietf-idr-reserved-extended-communities is a short draft to
 > > define non-transitive well-known communities. It proposed to re-use an
 > > "existing" non-transitive extended community, defined for four-octets
 > > AS: draft-ietf-idr-as4octet-extcomm-generic-subtype. But it turns out
 > > that this latter draft did not progress and has recently been replaced
 > > by BGP large community. The later do no support non-transitive
 > > community.
 > >
 > > So after waiting for some years for
 > > draft-ietf-idr-as4octet-extcomm-generic-subtype, this path has just
 > > been closed. As of today, the possible options seems:
 > >
 > > - forget about non-transitive community. In particular as during the
 > > BGP large community discussions, the requirement for non-transitive
 > > community has been discussed and explicitly called as not needed. So
 > > let's listen to this and do the same.
 >
 > I'd like to add a small nuance: For the use case of large communities, non-transitivity was
 > considered an undesirable property.
 >
 > To be honest, if the 'gshut' community 'escapes' the adjacent ASN for which it was intended,
 > what is the worst that can happen? That BGP speakers somewhere in the DFZ consider the
 > path less desirable? This aligns with what is expected to happen in the near future anyway:
 > the bgp session will be torn down and the path will cease to exist.
 >
 > In the case where no shutdown event follows (the gshut community is used as a traffic
 > engineering trick), it kind of goes in the same category as intermediat networks prepending
 > ASNs to the AS_PATH to make it less desirable, or fiddling with origin. If I were to consider
 > "permanent use" of the gshut community a violation of my agreement with the adjacent
 > network, this would be easy enough to monitor for and subsequently resolve at layer-8.
 >
 > > - have draft-ietf-idr-reserved-extended-communities use a different
 > > extended community type. This is easy to write, but if this does not
 > > get implemented, the value is limited/null.
 >
 > I concur. A similar consideration could be made whether gshut deserves its own path
 > attribute or not.  Usually the nice thing about well known rfc 1997 communities is their
 > rapid implementation and deployability.
 >
 > > > What implementatations exist? A fellow operator told me that IOS,
 > > > IOS XE has support for graceful shutdown, are there others?
 > >
 > > Same information on my side.  With the restriction that those
 > > implementations only implement the transitive community.
 >
 > ack.
 >
 > I'm somewhat inclined to proceed with the gshut concept as a well-known transitive rfc
 > 1997 community. What do others think?
 >
 > Kind regards,
 >
 > Job
 >
 > _______________________________________________
 > GROW mailing list
 > GROW@ietf.org<mailto: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<mailto: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.