Hi David,
On October 6, 2015 at 00:37:42, Black, David (david.bl...@emc.com) wrote:
> > As an OPS-Dir member, I'm concerned by the above RFC 5706 answers,
> and in particular treating all operational issues as vendor-
> and/or
> operator-specific. One possible alternative would be to scope
> the
> draft down to interoperably specify what's needed for LFA
I’ll quote this part of your mail, but respond to the general question around
whether this draft should be tighter scoped (and the operational considerations
of what one can do with the mechanism).
In general, this mechanism is meant to give ways for an operator to add their
own logic on-top of the routing protocol selection of the OSPF protocol.
Specifically, this is for the case where there are sets of paths that OSPF
considers valid, but the operator has a particular preference for a particular
subset to be included or excluded. To this end, the harm that one can do by
preferring paths with a particular admin tag (or set of admin tags) on them is
simply to select a subset of the paths that would have been used anwyay.
So, from the examples in the document, the admin tag lets one:
* Prefer a specific LFA from a set of valid LFAs. The operator has a
business reason to prefer specific ones (e.g., OSPF metric is set based on
bandwidth, but we want to minimise latency, or we only want to capacity plan
for FRR between P nodes never transiting a PE). There are many different
reasons that one might have this preference, and they will be different by
operator - so, removing the ability of an operator to specify arbitrary tags
will make this mechanism ineffective. Whilst there could be unintended
consequences of preferring specific LFAs, actually there are probably worse
consequences of NOT preferring particular LFAs, such as traffic going via a PE
in another country such that latency is increased over all other LFAs. Bruno
and Stephane from FT have given many examples of this in the LFA manageability
drafts presented in RTGWG. The admin tag will never result in a new LFA that
would never have been selected via the standardised mechanisms being selected -
so, in my view, has little potential to cause new ‘harm’.
* Prefer a specific path from a set of paths. This is similar to the
case above. No new candidate path is being added to the routes that could be
used by the admin tag mechanism. It simply says that when a device that must
select N ECMPs to install from M candiates (N < M), then the operator can
influence which based on the admin tag. All are still valid ECMPs - so new risk
is created. Again, selecting a particular subset of that M without any
consideration may be more harmful than doing the operator-specific selection.
Again, the logic of which are ‘OK’ PEs and which are not is something that is
operator specific, and may only apply to a subset of applications using OSPF to
select paths (an example of this is devices that do not scale well as MPLS-TE
midpoints, but are OK for transit IP traffic - at this point, we may want to
influence CSPF to stay away from them, but not IP - the fact that these devices
are ‘not-OK-for-transit-MPLS-TE’ is not something that we can easily enumerate
and standardise).
Given that we are really selecting candidates from within a set of paths that
have already been selected by OSPF as valid, and usable - then I’m not sure
that I can understand the logic behind this sentence from your review: "There
appears to be more than enough enabled by this draft to wreak serious
operational havoc”.
I strongly disagree with the idea that we should try and enumerate what the
tags should be, rather than maintain the ability of an operator to add their
own specific logic with these tags. This is what is done today with link
affinity, or tags elsehwere in the IGP protocols.
Re-reading the draft, perhaps we need to clarify that this does not change the
underlying SPF process that OSPF uses today - would this address your concern?
Regards,
r.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
