Agree with Anton that defining capability bits for each and every use-case that the operator comes up with and getting it Standardized and get it implemented by each vendor is going to be a slow process. And we need a generic way of carrying node tags in protocols.
Rgds Shraddha -----Original Message----- From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Anton Smirnov Sent: Tuesday, August 26, 2014 10:33 PM To: Peter Psenak; ospf@ietf.org Subject: Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag Hi Peter, the draft lists about 5 different *example* applications which COULD be addressed by node admin tags. So if you take 1 particular possible scenario out of the draft - you still have 4 possible applications. Examples are there to demonstrate that admin tags is useful general tool, not to require the solution. Sure, each of possible scenarios can be solved by tailored solution. But each tailored solution is required to go via IETF adoption and implementation by vendors. And indeed, in cases where tailored solution brings so much operational benefit that it warrants slow path of IETF adoption, feature development by multiple vendors and network deployment - it will be used and will kill desire to solve the problem with admin tags. And vice verse - tags (when widely supported) will facilitate rapid development and deployment of services which we otherwise can't (or slow) to offer. As for your particular example - operator still has to go to each and every device and enable Remote LFA on it. But we are not trying to solve this operational complexity with OSPF autoconfiguration. So it shouldn't be that complex to enable acceptable node tag at the same time as enabling rLFA itself. Anton On 08/26/2014 10:05 AM, Peter Psenak 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
