Hi Rob,
On 9/3/14 10:08 , Rob Shakir wrote:
Hi Peter.
On 26 Aug 2014, at 16:43, Peter Psenak <[email protected]> wrote:
On 8/26/14 17:32 , Hannes Gredler wrote:
operators want to assign node-tags as per router function (ABR, PE, core) and
then
the LFA-selection becomes much easier to specify. - e.g.
- only pick a LFA that does not cross another PE router.
similarily it is desirable for "LFA tunnel termination"
to put out a constraint which says
- only pick a PQ neighbor which has node tag 'X'
my point is that with the above approach you have to:
1. On candidate PQ nodes configure the tag X
2. on all other nodes configure "only pick a PQ neighbor which has node tag 'X'"
It's (2) which makes me feel uncomfortable, as it's a config to be applied to
many nodes.
I’m unclear on how one would solve this — the key thing is that there are
number of scenarios where it is *operator* preference rather than node
capabilities that mean that we want to select a particular node for some
certain application. This preference may be on a per-calculating node basis. If
this is the case, then a single capability that says that a particular target
node is capable of acting in a particular role is not sufficient.
(Consider this scenario:
- rtr-A is in country 1.
- rtr-B is in country 2.
- Both rtr-A and rtf-B are capable of acting as PQ nodes,and need to
act as such for ‘local’ nodes (i.e., those in the same country as them).
- rtr-A should never select rtr-B as a PQ.
In this case, we need some tag that specifies country, as well as some tag that
specifies that it is a valid PQ node. We then need specific policy on rtr-A and
rtr-B to implement this policy.)
It is very typical that where we have such policy implementations, then we need
to configure the behaviour on a per-node basis. This is especially true where
policies must consider characteristics of the topology.
i found it always strange that we for TE (as an example for
constraining paths) we have got ways to tag links, but
not way to tag nodes - that draft aims to fix that.
I'm not against tagging nodes as such. What worries me if we end up using node
tags for signalling capabilities of node.
As per the above, I do not think that this mechanism replaces any capability,
it just gives an operator a means to be more granular than the binary
“supported”/“not supported” view that a flag indicating capabilities does.
I understand. My point was that admin tags should not be used in cases
where only a binary capability is signaled.
thanks,
Peter
I, of course, support the adoption of this draft as a co-author.
Cheers,
r.
.
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
