Hi Tiger, Uma, I agree - I just don’t want this to evolve into a standard way to circumvent standardization of various router parameters ;^). Even if there is no way to prevent a vendor for using the mechanism for this purpose, we don’t want to endorse this by claiming it as a use case.
Note that the local application use case ties nicely to the transport instance draft (https://tools.ietf.org/id/draft-ietf-ospf-transport-instance-11.txt). Specifically, with the remote-neighbor capability, one can use an instance only including the nodes running the local application and requiring exchange of flooded information. In conjunction with transport instance, I’d actually considered a similar encoding. Thanks, Acee On 10/20/15, 9:16 PM, "Xuxiaohu" <[email protected]> wrote: >Hi Acee, > >I (as a co-author) feel this draft describes a useful approach for local >applications to flood non-standard parameters opaquely and therefore the >OSPF WG should work on it. > >Best regards, >Xiaohu (Tiger) > >> -----Original Message----- >> From: OSPF [mailto:[email protected]] On Behalf Of Acee Lindem >>(acee) >> Sent: Tuesday, October 20, 2015 4:29 AM >> To: OSPF WG List >> Subject: [OSPF] OSPF Operator-Defined TLVs >> >>(https://www.ietf.org/id/draft-chunduri-ospf-operator-defined-tlvs-01.txt >>) >> >> This draft has been presented at two IETFs and while I don’t agree with >>some of >> the proposed use cases as these applications reference should, if fact, >>be >> standardized, I can see that the use case for local applications could >>be >> compelling. This is the use where OSPF provides an API for local >>applications to >> advertise application-specific information throughout the routing >>domain and >> receive the same parameters from other routers running that >>application. Since >> this is to support local applications generically, one could see the >>reason to allow >> non-standard parameters to be flooded opaquely (i.e., OSPF is used >>solely as a >> flooding mechanism). >> >> Please take a look at the draft and indicate whether or not you feel >>the OSPF WG >> should work on such a solution. If there is enough interest, we will >>adopt it as a >> 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
