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

["Black, David" <[e-mail]>]

Rob,

> 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”.

Perhaps, I'm not understanding something, but I thought I saw an unreachability
problem in the example in Section 4.5/Figure 3:

- The following example of an explicitly routed policy:

      - Traffic from A nodes to I nodes must not go through R and T
      	nodes

    prevents the leftmost pair of A nodes from sending traffic to the
    I nodes.  Was this "black hole" intended as part of the example?

Was that a mistake, and at least one path from the leftmost pair of A nodes
to the I nodes will be selected despite that "explicitly routed policy"?

Thanks,
--David

> -----Original Message-----
> From: Rob Shakir [mailto:[e-mail]]
> Sent: Tuesday, October 06, 2015 11:23 AM
> To: [e-mail]; Black, David; [e-mail]; [e-mail];
> [e-mail]; General Area Review Team ([e-mail])
> [e-mail]
> Cc: [e-mail]; Black, David; [e-mail]; [e-mail]
> Subject: Re: Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06
> 
> 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.
> 
>