Re: [OSPF] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06

[Rob Shakir <[e-mail]>]

Hi David,

On October 6, 2015 at 00:37:42, Black, David ([e-mail]) 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.