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:r...@rob.sh]
> Sent: Tuesday, October 06, 2015 11:23 AM
> To: a...@cisco.com; Black, David; bruno.decra...@orange.com; ops-...@ietf.org;
> shrad...@juniper.net; General Area Review Team (gen-art@ietf.org);
> lizhen...@huawei.com
> Cc: a...@cisco.com; Black, David; o...@ietf.org; i...@ietf.org
> 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 (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
