Hi Hannes,
On 8/26/14 17:59 , Hannes Gredler wrote:
hi peter,
understood - so what about simply reserving a certain range of the tag space
for well-known applications (+IANA registry etc.) such that
for 2) we can avoid distributing policies ?
we have an existing mechanism for advertising capabilities - RFC4970,
section 2.3 and 2.4. We can reserve a bit for each well-known application.
thanks,
Peter
/hannes
On Tue, Aug 26, 2014 at 05:43:48PM +0200, Peter Psenak wrote:
| Hi Hannes,
|
| On 8/26/14 17:32 , Hannes Gredler wrote:
| >hi peter,
| >
| >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.
|
| If we instead define a capability bit which would mean "PQ candidate", we
| would avoid (2).
|
| >
| >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.
|
| thanks,
| Peter
|
| >
| >HTH,
| >
| >/hannes
| >
| >On Tue, Aug 26, 2014 at 04:30:26PM +0200, Peter Psenak wrote:
| >| Hi Acee,
| >|
| >| On 8/26/14 15:45 , Acee Lindem (acee) wrote:
| >| >Hi Peter,
| >| >This is a valid concern and one that we¹ve discussed previously with
| >| >respect to routing behavior based on policies. I think that accepting this
| >| >draft as a WG document should not preclude standardization of capabilities
| >| >advertisement for popular applications.
| >|
| >| sure. Just that the draft mentions applications like "Controlling Remote
LFA
| >| tunnel termination", which I'm not sure the node tag is the best approach
| >| for.
| >|
| >| thanks,
| >| Peter
| >|
| >| >Thanks,
| >| >Acee
| >| >
| >| >On 8/26/14, 4:05 AM, "Peter Psenak (ppsenak)" <[email protected]> wrote:
| >| >
| >| >>On 8/25/14 23:18 , Acee Lindem (acee) wrote:
| >| >>>There are situations where node level policy is required and an OSPF
| >| >>>advertised admin tag simplifies this. For example, advertisement of
| >| >>>remote-LFA eligibility.
| >| >>
| >| >>my concern with the generic use of admin tags for signaling capability
| >| >>is that it's operationally unfriendly compared to explicit signaling of
| >| >>the capability (e.g. using a bit or a TLV). The reason is that you have
| >| >>to configure the tag meaning on all receiving routers.
| >| >>
| >| >>thanks,
| >| >>Peter
| >| >>
| >| >>>
| >| >>>Please indicate your support or objections to adopting this draft as an
| >| >>>OSPF WG document.
| >| >>>
| >| >>>Thanks,
| >| >>>Acee
| >| >>>
| >| >>>
| >| >>>_______________________________________________
| >| >>>OSPF mailing list
| >| >>>[email protected]
| >| >>>https://www.ietf.org/mailman/listinfo/ospf
| >| >>>
| >| >>
| >| >>_______________________________________________
| >| >>OSPF mailing list
| >| >>[email protected]
| >| >>https://www.ietf.org/mailman/listinfo/ospf
| >| >
| >| >.
| >| >
| >|
| >| _______________________________________________
| >| OSPF mailing list
| >| [email protected]
| >| https://www.ietf.org/mailman/listinfo/ospf
| >.
| >
|
.
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
