I support making this draft a WG item - but I do think a much more complete discussion regarding the tradeoffs between using node tags vs capability identifiers needs to be included - if for no other reason than if/when this draft were to become an RFC we would have two mechanisms and it is not so clear when it is more appropriate to use one over another.
We don't have to come to a conclusion on that issue in this thread - nor should it preclude making this a WG item - but it is definitely an important issue to be discussed. Les > -----Original Message----- > From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Peter Psenak > (ppsenak) > Sent: Tuesday, August 26, 2014 9:40 AM > To: Hannes Gredler > Cc: ospf@ietf.org > Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin- > tag > > 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)" > <ppse...@cisco.com> 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 > > | >| >>>OSPF@ietf.org > > | >| >>>https://www.ietf.org/mailman/listinfo/ospf > > | >| >>> > > | >| >> > > | >| >>_______________________________________________ > > | >| >>OSPF mailing list > > | >| >>OSPF@ietf.org > > | >| >>https://www.ietf.org/mailman/listinfo/ospf > > | >| > > > | >| >. > > | >| > > > | >| > > | >| _______________________________________________ > > | >| OSPF mailing list > > | >| OSPF@ietf.org > > | >| https://www.ietf.org/mailman/listinfo/ospf > > | >. > > | > > > | > > . > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
