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 LOCAL_PREF value.
‘Maintained’ (in ‘maintained EBGP session’) is not a useful word
to use here, since ultimately the session is not to be maintained at
all! Perhaps “eBGP session” is clear enough, or use ‘impacted’
or ‘relevant’.
I have a further comment on section 6. Link Up cases. I rather feel this
is a separate body of work, and belongs in some sort of ‘gshut-bis’
where we can extend on this technique. Certainly there is nothing in the
rest of the draft which prevents the use of gshut technique to improve
link-up behaviour, so I would remove sections 6/6.1/6.2 for clarity.
Behaviour in relation to next-hop reachability across a multi-access
network is of particular interest to me as an IXP operator, and is
probably a whole topic of its own.
--
Will Hargrave
Technical Director
LONAP Ltd
+44 114 303 4444
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
