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

[Jakob Heitz (jheitz)]

Local pref should be reduced when the route is received.

Consider router that learns a route on 2 interfaces.
The best path is on the interface that will go down.
The right thing to do is to change the best path to the other one.
Lowering local pref at the incomming interface will do that.

Thanks,
Jakob.


> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders
> Sent: Monday, June 26, 2017 8:31 AM
> To: bruno.decra...@orange.com
> Cc: grow@ietf.org
> Subject: Re: [GROW] draft-ietf-grow-bgp-gshut
> 
> 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 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 set
> >  > during application of the local policy on the relevant Adj-RIB-In.
> >
> > Current version of the draft changes the LOCAL_PREF on the Adj-RIB-Out
> > and not on the Loc_RIB.
> 
> Yes, that should change.
> 
> > This has a technical benefit as otherwise, the router may (locally)
> > select a backup route which it is not allowed to advertise, which
> > would trigger the sending of a withdraw of the original route. i.e.
> > not a g-shut.
> 
> Sure, but the reverse is true too. It may select a path that it is not
> allowed to advertise and with the gshut community select something else.
> This is not a strong argument.
> 
> > This may be considered as a corner case, but I don't see why we would 
> > choose not cover it.
> > I suppose that one can also see some operational drawbacks:
> > a) seems less intuitive.
> > b) traffic received from external interfaces on this specific g-shut
> > router (the egress in the AS) are forwarded on the "nominal"/g-shut
> > path, rather than on the backup path.
> 
> Yes, and avoiding the nominal path (using a backup path) has great
> benefit that the operator can monitor whether convergence is finished,
> which can be used in the decision making process when to proceed with
> the maintenance.
> 
> Operational expectation is that when one initiates a process to drain
> traffic from a node or a link, that traffic is actually, visibly drained
> away from a link.
> 
> > IMO:
> > - "a" is not a big concern as the related configuration is
> > pre-configured once for all on the router. We are not discussing the
> > configuration applied at maintenance time.
> > - "b" has no impact on the customer loss of connectivity as this
> > traffic may be locally rerouted in no time (up to zero packet loss) by
> > the router which needs to update its FIB "in place". i.e. the
> > destination IP prefix is never removed from the FIB. Only the outgoing
> > interface is changed, and during this change, both outgoing interfaces
> > are valid (both the old and the new).
> 
> This assumes that all parties involved can actually locally reroute
> without packetloss. One cannot know this. Also, what of the case where a
> single ASN is composed of a single router (or a network is operated
> without the concept of IBGP as defined by IETF).
> 
> > So although some may see a tradeoff, I'd rather favor the generality
> > of the mechanism. Specifically as not covering the corner cases may
> > surprise the operator.
> 
> Also, as it currently stands operators, are implementing it on Loc-RIB.
> 
> Another argument in favor of adjustment on Loc-RIB rather then "On
> Adj-RIB-Out but only for IBGP sessions", is that it is much easier to
> explain to people: "When you attach the GRACEFUL_SHUTDOWN, everyone is
> expected to lower LOCAL_PREF as low as possible" (and simply forgo
> explaining the particular conditionals of the current draft).
> 
> Kind regards,
> 
> Job
> 
> ___
> 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

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

[Jakob Heitz (jheitz)]

It works for iBGP links too. An iBGP link is not to another AS.

Thanks,
Jakob.


> -Original Message-
> From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of heasley
> Sent: Monday, June 26, 2017 10:07 AM
> To: bruno.decra...@orange.com
> 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.
> 
> ___
> 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

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

[heasley]

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.

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

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

[Job Snijders]

On Mon, Jun 26, 2017 at 01:58:32PM +, bruno.decra...@orange.com wrote:
>  > I think section 6 for link up should stay.
>  > The cases desctibed are real, whether corner or not.
> 
> [Bruno] agreed.

I agree it is valuable text, but the draft is about "SHUTDOWN" - not
about "Link Up". Perhaps spin it off into a more complete draft
focussing specifically on this topic?

Kind regards,

Job

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

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

[Job Snijders]

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
> [...]
> 
> > 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 well-known community fits the
> goal of the document and its requirements (RFC 6198). The main
> motivation is to have a g-shut solution with no required BGP protocol
> extension, and where the backup path is known to the AS. i.e. we are
> not looking for an Internet wide convergence/g-shut. We are primarily
> interested in a g-shut within the responsibility of the AS. IOW, when
> it's "my fault" if my customer experiences a packet loss. In this
> case, there is no need to propagate the g-shut community further.
> 
> - removing the g-shut community reduces Internet wide churns,
> including compared to when g-shut is not used.
> Here are the 3 cases, focusing on the first step of the BGP
> convergence (searching for the backup path)
>   - No g-shut: a WITHDRAW is propagated to other ASes
>   - g-shut propagating the community: an UDPDATE is propagated to
>   others ASes (same path, adding the community)
>   - g-shut removing the community: no BGP messages propagated to
>   others ASes (same path, same communities/attribute)
> 
> In general, reducing the BGP churn is considered as a feature. By
> removing the g-shut community, we are at the same time:
> a) g-shut in both affected ASes
> b) reducing Internet churn.
> 
> Now if we choose to not remove the community, we improve "a" by
> covering the cases where the backup path is unknown to the AS. And we
> keep "b" unchanged compared to today (but degrade it compare to
> current g-shut draft).

I don't think we really have a say in whether BGP Communities are
removed or not. This is outside our control. If we remove the hard
requirement to remove the community, the behaviour falls back to
https://tools.ietf.org/html/rfc7454#section-11 which imho is fine: leave
the choice with the operator. Perhaps the draft does not need to define
whether to strip or not.

I have to admit that the first time I used a a 'g-shut -06 compliant'
automated process, I was surprised that that I didn't see the community
on the IBGP outbound announcements. Removing the community somewhat
reduces visibility to those involved with the operation.

> As for my requirements, I'm considering that our ASes have the
> knowledge of the backup path. Hence I don't need for the extra
> coverage. Regarding the extra cost, I agree that one can hardly
> consider this unacceptable since this is the current behavior.
> 
> TL;DR: it's a tradeoff between 2 secondary objectives:
> - reducing Internet churned (compared to today)
> - improving the g-shut coverage when the AS does not know the backup path

+ improve visibility into the operation

> Draft can possibly discuss both options, at the cost of additional
> reading complexity. But this possibly could be discussed in a
> different section.
>
> I'd welcome more opinion, before choosing the main text.

Bruno, perhaps my interpretation of the above sentence's phrasing is
somewhat mangled because neither of us are a native speaker, but keep in
mind this is a GROW working group document. :-)

Kind regards,

Job

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

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

[Job Snijders]

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 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 set
>  > during application of the local policy on the relevant Adj-RIB-In.
> 
> Current version of the draft changes the LOCAL_PREF on the Adj-RIB-Out
> and not on the Loc_RIB.

Yes, that should change.

> This has a technical benefit as otherwise, the router may (locally)
> select a backup route which it is not allowed to advertise, which
> would trigger the sending of a withdraw of the original route. i.e.
> not a g-shut.

Sure, but the reverse is true too. It may select a path that it is not
allowed to advertise and with the gshut community select something else.
This is not a strong argument.

> This may be considered as a corner case, but I don't see why we would choose 
> not cover it.
> I suppose that one can also see some operational drawbacks:
> a) seems less intuitive.
> b) traffic received from external interfaces on this specific g-shut
> router (the egress in the AS) are forwarded on the "nominal"/g-shut
> path, rather than on the backup path.

Yes, and avoiding the nominal path (using a backup path) has great
benefit that the operator can monitor whether convergence is finished,
which can be used in the decision making process when to proceed with
the maintenance.

Operational expectation is that when one initiates a process to drain
traffic from a node or a link, that traffic is actually, visibly drained
away from a link.

> IMO:
> - "a" is not a big concern as the related configuration is
> pre-configured once for all on the router. We are not discussing the
> configuration applied at maintenance time.
> - "b" has no impact on the customer loss of connectivity as this
> traffic may be locally rerouted in no time (up to zero packet loss) by
> the router which needs to update its FIB "in place". i.e. the
> destination IP prefix is never removed from the FIB. Only the outgoing
> interface is changed, and during this change, both outgoing interfaces
> are valid (both the old and the new).

This assumes that all parties involved can actually locally reroute
without packetloss. One cannot know this. Also, what of the case where a
single ASN is composed of a single router (or a network is operated
without the concept of IBGP as defined by IETF).

> So although some may see a tradeoff, I'd rather favor the generality
> of the mechanism. Specifically as not covering the corner cases may
> surprise the operator.

Also, as it currently stands operators, are implementing it on Loc-RIB.

Another argument in favor of adjustment on Loc-RIB rather then "On
Adj-RIB-Out but only for IBGP sessions", is that it is much easier to
explain to people: "When you attach the GRACEFUL_SHUTDOWN, everyone is
expected to lower LOCAL_PREF as low as possible" (and simply forgo
explaining the particular conditionals of the current draft).

Kind regards,

Job

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

Re: [GROW] I-D Action: draft-ietf-grow-bgp-gshut-08.txt

[bruno.decraene]

-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
 > Sent: Monday, June 26, 2017 4:21 PM
 > To: i-d-annou...@ietf.org
 > Cc: grow@ietf.org
 > Subject: I-D Action: draft-ietf-grow-bgp-gshut-08.txt
 > 
 > 
 > A New Internet-Draft is available from the on-line Internet-Drafts 
 > directories.
 > This draft is a work item of the Global Routing Operations of the IETF.
 > 
 > Title   : Graceful BGP session shutdown
 > Authors : Pierre Francois
 >   Bruno Decraene
 >   Cristel Pelsser
 >   Keyur Patel
 >   Clarence Filsfils
 >  Filename: draft-ietf-grow-bgp-gshut-08.txt
 >  Pages   : 11
 >  Date: 2017-06-26
 > 
 > 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.  It defines a
 >well-known BGP community, called g-shut, to signal the graceful
 >shutdown of paths to other Autonomous Systems.
 > 
 > 
 > The IETF datatracker status page for this draft is:
 > https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-gshut/
 > 
 > There are also htmlized versions available at:
 > https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-08
 > https://datatracker.ietf.org/doc/html/draft-ietf-grow-bgp-gshut-08
 > 
 > A diff from the previous version is available at:
 > https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-bgp-gshut-08
 > 
 > 
 > 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

_

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

[GROW] I-D Action: draft-ietf-grow-bgp-gshut-08.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Global Routing Operations of the IETF.

Title   : Graceful BGP session shutdown
Authors : Pierre Francois
  Bruno Decraene
  Cristel Pelsser
  Keyur Patel
  Clarence Filsfils
Filename: draft-ietf-grow-bgp-gshut-08.txt
Pages   : 11
Date: 2017-06-26

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.  It defines a
   well-known BGP community, called g-shut, to signal the graceful
   shutdown of paths to other Autonomous Systems.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-gshut/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-08
https://datatracker.ietf.org/doc/html/draft-ietf-grow-bgp-gshut-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-bgp-gshut-08


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/

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

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

[bruno.decraene]

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 set
 > during application of the local policy on the relevant Adj-RIB-In.

Current version of the draft changes the LOCAL_PREF on the Adj-RIB-Out and not 
on the Loc_RIB.
This has a technical benefit as otherwise, the router may (locally) select a 
backup route which it is not allowed to advertise, which would trigger the 
sending of a withdraw of the original route. i.e. not a g-shut.
This may be considered as a corner case, but I don't see why we would choose 
not cover it.
I suppose that one can also see some operational drawbacks:
a) seems less intuitive.
b) traffic received from external interfaces on this specific g-shut router 
(the egress in the AS) are forwarded on the "nominal"/g-shut path, rather than 
on the backup path.

IMO:
- "a" is not a big concern as the related configuration is pre-configured once 
for all on the router. We are not discussing the configuration applied at 
maintenance time.
- "b" has no impact on the customer loss of connectivity as this traffic may be 
locally rerouted in no time (up to zero packet loss) by the router which needs 
to update its FIB "in place". i.e. the destination IP prefix is never removed 
from the FIB. Only the outgoing interface is changed, and during this change, 
both outgoing interfaces are valid (both the old and the new).

So although some may see a tradeoff, I'd rather favor the generality of the 
mechanism. Specifically as not covering the corner cases may surprise the 
operator.

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

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

[bruno.decraene]

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 well-known community fits the goal of the 
document and its requirements (RFC 6198). The main motivation is to have a 
g-shut solution with no required BGP protocol extension, and where the backup 
path is known to the AS. i.e. we are not looking for an Internet wide 
convergence/g-shut. We are primarily interested in a g-shut within the 
responsibility of the AS. IOW, when it's "my fault" if my customer experiences 
a packet loss. In this case, there is no need to propagate the g-shut community 
further.

- removing the g-shut community reduces Internet wide churns, including 
compared to when g-shut is not used.
Here are the 3 cases, focusing on the first step of the BGP convergence 
(searching for the backup path)
  - No g-shut: a WITHDRAW is propagated to other ASes
  - g-shut propagating the community: an UDPDATE is propagated to others ASes 
(same path, adding the community)
  - g-shut removing the community: no BGP messages propagated to others ASes 
(same path, same communities/attribute)

In general, reducing the BGP churn is considered as a feature. By removing the 
g-shut community, we are at the same time:
a) g-shut in both affected ASes
b) reducing Internet churn.

Now if we choose to not remove the community, we improve "a" by covering the 
cases where the backup path is unknown to the AS. And we keep "b" unchanged 
compared to today (but degrade it compare to current g-shut draft).
As for my requirements, I'm considering that our ASes have the knowledge of the 
backup path. Hence I don't need for the extra coverage. Regarding the extra 
cost, I agree that one can hardly consider this unacceptable since this is the 
current behavior.

TL;DR: it's a tradeoff between 2 secondary objectives:
- reducing Internet churned (compared to today)
- improving the g-shut coverage when the AS does not know the backup path

Draft can possibly discuss both options, at the cost of additional reading 
complexity. But this possibly could be discussed in a different section.
I'd welcome more opinion, before choosing the main text.

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

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

[bruno.decraene]

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
 > considered. On the one hand, the g-shut community may not be originated
 > by the neighbor and is valid wherever the route may be advertised.
 > On the other hand, in the IPv4 and IPv6 address families, if an alternate
 > route is not available, the g-shut community can be spread throughout
 > all routers in the world, causing excessive churn.
 > I understand that this issue has been discussed in the working group,
 > but the concerns should be written into the RFC.

[Bruno] I'll initiate a thread to rediscuss this point. Then we'll see the 
outcome to update the draft.
 
 > I think section 6 for link up should stay.
 > The cases desctibed are real, whether corner or not.

[Bruno] agreed.

 > It does not even need route reflectors to happen.
 > All that is required is for a withdraw message to be processed by a router
 > before the new announcement.
 > 
 > Consider:
 > R2 is announcing the best-path.
 > R1 was under maintenance and is coming up.
 > R1 advertises the new path to R2.
 > R2 withdraws its path.
 > R1 advertises the new path to R3.
 > R3 receives or processes the withdrawal from R2 before the advertisement 
 > from R1.
 
[Bruno] Indeed. In the draft, we presented the IBGP Route Reflector case, as we 
though that RR is more common than full mesh.
Note that both cases are essentially the same:
- IBGP full mesh between ASBR in your example
- IBGP full mesh between RR in the draft
 
In both cases, we have:
- a distributed convergence with 2 nodes involved,
- multiple/many IBGP sessions, creating multiple signaling paths, where a BGP 
UPDATE flowing along a 'long' path (2 sessions) may arrive after a BGP session 
flowing along a 'short' path (1 session).

(Unfortunately) I agree that this is not theoretical.

 > "4.2.3 Router g-shut" should make it clear that the behavior is in addition
 > to the behavior of the links being shut down. Shutting down a router means 
 > all its
 > links are going down too. In addition, the gshut community should be tagged
 > onto the originated routes.
 
[Bruno] Agreed. Proposed text:
OLD:
   In the case of a shutdown of a router, a reconfiguration of the
   outbound BGP route policies of the g-shut initiator SHOULD be
   performed to set a low LOCAL_PREF value for the paths originated by
   the g-shut initiator (e.g, BGP aggregates redistributed from other
   protocols, including static routes).

   This behavior is equivalent to the recommended behavior for paths
   "redistributed" from eBGP sessions to iBGP sessions in the case of
   the shutdown of an ASBR.

NEW:
In the case of a shutdown of the whole router, in addition to the g-shut of all 
EBGP sessions, there is a need to g-shut the routes originated by this router 
(e.g, BGP aggregates redistributed from other protocols, including static 
routes).  This can be performed by tagging such routes with the g-shut 
community.

 
Thanks,
Regards,
--Bruno

 > Thanks,
 > Jakob.
 > 
 > 
 > > -Original Message-
 > > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Will Hargrave
 > > Sent: Saturday, June 24, 2017 3:46 AM
 > > To: Job Snijders 
 > > Cc: grow@ietf.org
 > > Subject: Re: [GROW] draft-ietf-grow-bgp-gshut
 > >
 > > On 22 Jun 2017, at 21:47, Job Snijders wrote:
 > >
 > > Hi all, a few comments below:
 > >
 > > > NEW (in Pre-configuration):
 > > >On each ASBR supporting the g-shut procedure, an inbound BGP route
 > > >policy is applied on all BGP sessions of the ASBR, that:
 > > >o  matches the g-shut community
 > > >o  sets the LOCAL_PREF attribute of the paths tagged with the
 > > > g-shut
 > > >   community to a low value (a value of zero is recommended).
 > >
 > > Since we define some terminology in 2., we should use it:
 > >
 > > On each g-shut neighbor ASBR, an inbound BGP route policy is applied on
 > > all BGP sessions of the ASBR, that:
 > >
 > >
 > > I don’t think the ‘neighbor’ / ‘initiator’ terminology is very
 > > clear, but I struggle to find more appropriate terms right now.
 > > ‘g-shut receiver’?
 > >
 > > > NEW (in Operations at maintenance time):
 > > >On the g-shut initiator, upon maintenance time, it is required to:
 > > >o  apply an outbound BGP route policy on the maintained EBGP
 > > > session
 > > >   to tag the paths propagated over the session with the g-shut
 > > >   community. This will trigger the BGP implementation to re-
 > > >   advertise all active routes previously advertised, and tag them
 > > >   with the g-shut community.
 > > >o  apply an inbound BGP route policy on the maintained EBGP session
 > > >   to tag the paths received over the session with the g-shut
 > > >   community and set a low 

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

[bruno.decraene]

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)
 > >  > 
 > >  >
 > >  > Bruno promised a new, fresh version of draft-ietf-grow-bgp-gshut which
 > >  > would focus on the rfc1997 well-known community 65535:0 - I would
 > >  > appreciate if this is posted at some point so we can make an Informative
 > >  > reference to a non-zombie draft.  NTT (as2914) & Coloclue (as8283)
 > >  > implemented experimental rfc1997 gshut support for customers and it
 > >  > appears to work as advertise (no pun intended ;-).
 > >
 > > https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-07 has just been 
 > > posted and
 > addresses the above point.
 > >
 > > As previously discussed on the list, the main technical change is the
 > > focus, for the eBGP signaling, on the use of a well-known BGP
 > > community.  In other word, the alternative option to use a
 > > non-transitive community has been removed, following latest IDR
 > > discussion on community and the lack of implementation (hence IDR WG
 > > progress) of draft-ietf-idr-reserved-extended-communities /
 > > draft.ietf-idr-as4octet-extcomm-generic-subtype.  As a benefit, this
 > > draft is now aligned with: - the BGP gshut/planned maintenance
 > > implementations disclosed on this list
 > > https://mailarchive.ietf.org/arch/msg/grow/ReJtavkJDlyrDo5qoD7u9iJDLXs
 > > - the deployed usage
 > 
 > fantastic!
 > 
 > I have some comments:
 > 
 > Summary:
 > 
 > I think that the neighbor ASBR should _not_ strip the GSHUT well-known
 > community, additionally, 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 set
 > during application of the local policy on the relevant Adj-RIB-In.

[Bruno] Will answer these technical points in separate threads.

 > The above changes would align with current operational practises, i've
 > learned from numerous people that they use AS-specific "lower LOCAL_PREF
 > as low as possible" communities from their peers and upstream providers
 > to trigger path hunting. In current deployments those communities are
 > often not stripped (in context of IBGP), and the lower LOCAL_PREF is set
 > on "ebgp-in" rather then "ibgp-out".
 > 
 > Optionally an appendix with an actual router configuration can be
 > supplied, if there is interest in this I am happy to provide that.
 
[Bruno] I think this would be useful. (although CLI change over time)
 
 > -
 > 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."
 
 > OLD (in introduction):
 >Still, it explains why reserving a community value for the purpose of
 >BGP session graceful shutdown would reduce the management overhead
 >bound with the solution.  It would also allow vendors to provide an
 >automatic graceful shutdown mechanism that does not require any
 >router reconfiguration at maintenance time.
 > NEW (in introduction):
 >This document defines a well-known community value for the purpose of
 >reducing the management overhead of gracefully shutting down BGP
 >sessions. The well-known community allows implementers to provide an
 >automated graceful shutdown mechanism that does not require any
 >router reconfiguration at maintenance time.

[Bruno] OK.

 
 > OLD (in Make before break convergence: g-shut):
 >This section describes configurations and actions to be performed for
 >the graceful shutdown of eBGP sessions, iBGP sessions or a whole BGP
 >speaker.
 > NEW:
 >This section describes configurations and actions to be performed for
 >the graceful shutdown of BGP sessions.
 
[Bruno] OK.

 
 > OLD (in Pre-configuration):
 >On each ASBR supporting the g-shut procedure, an outbound BGP route
 >policy is applied on all iBGP sessions of the ASBR, that:
 >o  matches the g-shut community
 >o  sets the LOCAL_PREF attribute of the paths tagged with the g-shut
 >   community to a low value
 >o  removes the g-shut community