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

[Jakob Heitz (jheitz)]

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.

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.

___
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 05:39:12PM +0200, Job Snijders:
> > 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

+1 for that; and allows it to (possibly) enter the records of routeviews.

& allows other ASes beyond the receiver to take action - even if the receiver
  does not have an alternate path ... which imiho ends this discussion about
  removing the community.

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

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

[bruno.decraene]

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.

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

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

[Jakob Heitz (jheitz)]

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.
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.

Thanks,
Jakob.

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

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

[bruno.decraene]

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 are already available.

The purpose of the graceful shutdown is to reduce, possibly remove, the loss of 
connectivity when an EBGP session is shutdown.
The main contribution is indeed the time taken to learn and install the backup 
paths.
What is needed is an AS global convergence, not just the g-shut initiator.
In this specific case, the alternative path is known to the g-shut initiator. 
That does not mean that it is known by all routers in the AS.

 > If they are available to the gshut initiating router, then they
 > are available to the other routers. 

Why?

> Therefore a withdraw is ok.

If we want to avoid any node to have a lack of path, avoiding withdraw is just 
safer.
Especially considering the wide possibilities of BGP topologies inside the AS.
  
 > Now, consider a not uncommon case:
 > The gshut initiating router has 2 advertiseable paths.
 > Another router has an inferior path.
 > When the gshut is initiated for one path, the inferior path
 > from the other router will be chosen by the network.
 > When gshut is removed, the network will churn a second time
 > when it chooses the second path.
 
Sure.
>From a probability standpoint, there is more chance that the post convergence 
>path be advertised by one of the other (e.g. 100) routers than by this (ingle) 
>g-shut router. Especially assuming that most AS would want to protect against 
>node failure, the backup path would typically be connected on a different node 
>(if available of course).
Note also that your "second churn" is part of IBGP path hunting and may happen 
in any case (i.e. the first alternate path found may not the best/post 
convergence one)
 
 > I think it's better for the gshut initiating router to just
 > advertise its next best path instead of gshut.
 
OK. Thanks for the feedback.
This seems to be the general sense of the GROW WG. I'll wait some more time to 
have a chance to collect all feedbacks, and we'll update the draft.
 
Thanks
--Bruno

 > Thanks,
 > Jakob.
 > 
 > 
 > > -Original Message-
 > > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of 
 > > bruno.decra...@orange.com
 > > Sent: Tuesday, June 27, 2017 6:15 AM
 > > I'm not following you, so I'll provide an example of "not allowed to be 
 > > advertised on
 > IBGP"
 > > Topology:  the g-shut initiator has an IBGP session with another ASBR 
 > > (e.g. ASBR1 in the
 > same POP). This ASBR knows
 > > an alternate path and advertise it over IBGP. (e.g. best external, or 
 > > EBGP>IBGP)
 > > g-shut convergence: If the g-shut initiator applies the low local_pref, it 
 > > will switch to this
 > alternate path. As it
 > > can't advertise over IBGP a path learned over IBGP, it will send a 
 > > withdraw to both its
 > Route Reflector and its own
 > > IBGP peer.
 > > Discussion: May be we could assume that its Route Reflector and IBGP peers 
 > > also have the
 > pre-knowledge of this
 > > alternate path (from ASBR1) in which case this is not a big deal. But in 
 > > theory, it's just
 > safer to never send a
 > > withdraw.

_

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