Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

[Peter Psenak <[e-mail]>]

Hi Hannes,

On 9/3/14 13:01 , Hannes Gredler wrote:
> 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.

well, a more practical solution for the above _capability_ case would be 
to define a bit in OSPF Router Informational Capabilities TLV. The 
reason is that the meaning of the bit is defined and as such no other 
configuration is required on any other nodes except the PQ ones.

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

as I expressed multiple times, I have no issue with the node admin tags 
draft as such. My concern is related to the usage of the admin tags for 
signaling capabilities for which there is a better existing solution 
available.

thanks,
Peter

>
> /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?
> .
>