> 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) <jhe...@cisco.com>
 > > 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.

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

Reply via email to