Hi all, Comments in-line [BM]
On Mon, 2017-06-26 at 17:30 +0200, Job Snijders wrote: > On Mon, Jun 26, 2017 at 02:14:19PM +0000, 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. [BM] Agreed. The semantics of the community are: "this path will go away soon, please stop using it". This hint seems to me to be applicable to any receiving speaker. > > > 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. > [BM] Additionally, other things being equal, surely that withdraw is going to be sent at shutdown time anyway? Triggering it early seems to be harmless at worst. > > 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). [BM] We should also consider the outcome of the parallel discussion regarding the removal of the gshut community (for the record, i'm in favour of propagating by default and putting the operator in charge of overriding that behaviour). In the extreme case where all adjacencies are EBGP, if community propagates everywhere, but no speaker ever acts on it, you get all the churn for none of the benefit. > > > > 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). > [BM] Also agreed. Although calling out corner cases that may warrant attention is also valuable for those deploying new features. For me, these should live in a "deployment considerations" section, if at all. Cheers, Ben > Kind regards, > > Job > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow -- Ben Maddison Director Workonline Communications (Pty) Ltd Office: +27 (0) 21 200 9000 Mobile: +27 (0) 82 415 5545 Email: b...@workonline.co.za SIP: b...@workonline.co.za _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
