hi peter,
the question is not so much which registry is better;
we have existing proof-point (rlfa-spec not containing any capabilities)
that there may be the possibility that:
- a well-known, protocol specific tag does not exist
- the operator problem (excluding/including certain nodes
from PQ capability) still does exist
so it looks like we have a practical case in favor of bruno's argument.
let me draw also some analogy to tagging of IP prefixes here:
draft-hegde-ospf-node-admin-tag is a generic vehicle just as
http://datatracker.ietf.org/doc/rfc5130/ has been conceived for
IP prefixes. - it is correct for the problem described in
RFC5130 we could have been applying application-specific
bits in IP prefixes that control the leaking behavior.
however a different model has been chosen:
1) use generic, application-context-free tags for a prefix
2) write the leaking policy which refers to those tags.
i find the flexibility of that model appealing and i'd
like to have something similar for "nodes" on link-state
graphs.
/hannes
On 9/3/14 12:32, Peter Psenak wrote:
I agree as a general rule. Yet IMHO we should not kill this
possibility. In particular for feature allowing incremental deployment
& interaction with non-compliant nodes.
One example would have been Remote LFA (RLFA):
- the PLR (FRR node) needs to be RLFA compliant. Therefore (potential)
communication between PLR regarding their capabilities can be done
using IANA/implemented code point.
- the PQ node (Merge Point) does not need to be RLFA compliant. And we
should keep this property to ease incremental deployment. Therefore
communication between PQ and PLR regarding PQ capabilities should/may
be done using node tag. RLFA spec could have defined an IANA
registered node tag to be used by PQ (configured by the network
operator) to exclude them as PQ candidate. e.g. for PQ node not
accepting T-LDP session or nodes which should not be used as PQ per
policy.
why is "IANA registered node tag" any better then IANA registered
capability bit in the above case?
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
