Uma - > -----Original Message----- > From: Uma Chunduri [mailto:uma.chund...@ericsson.com] > Sent: Thursday, April 07, 2016 8:03 PM > To: Les Ginsberg (ginsberg); Acee Lindem (acee); OSPF WG List > Subject: RE: WG Adoption Poll for "Using Operator-defined TLVs for Agile > Service Deployment" > > Les, > > In-line [Uma]: > > -- > Uma C. > > > -----Original Message----- > From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Les Ginsberg > (ginsberg) > Sent: Wednesday, March 16, 2016 9:41 PM > To: Acee Lindem (acee); OSPF WG List > Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for > Agile Service Deployment" > > My opinion of the draft has not changed. > It is defining a way to utilize OSPF to send application information - which > is > not something the protocol should be used to do. > Further, it leaves definition of the new codepoints and formats of the > information advertised completely unspecified - the latest draft revision > states: > > " The meaning of the operator-defined sub-TLV is totally opaque to OSPF > and is defined by the network local policy and is controlled via > configuration. " > > How interoperability is achieved is not addressed at all. > > [Uma]: The whole point of the draft is, not to define the format for the sub- > TLVs so that it can be used as per the sub-tlv type as set by the operator > (for > example service attribute/Label). Sub-TLV has set of attribute length and > attribute value in NBO. > [Les:] Yes - I know. :-) And I think this is a "disaster waiting to happen".
On this point I think we currently have no common ground. Les > IS-IS has taken a much more stringent approach to a similar request. > > [Uma]: .. and hence unfortunately I see no body saw using it- in fact > including > you. For example https://tools.ietf.org/html/draft-ietf-isis-sbfd- > discriminator-02 could have used GENAPP but rather resorted to Router > capabilities (Remember IETF90 discussion around this). > > RFC 6823 (GENAPP) requires that information sent in the generic container > TLV MUST be based on a public specification - and that an application specific > ID for the application using this mechanism be assigned by IANA. This > addresses the interoperability issue. > GENAPP further specifies that such information SHOULD be advertised by a > separate instance of the routing protocol (as specified in RFC 6822(MI)) so as > to minimize the impact of the application information flooding on the > performance of the routing protocol. > > [Uma]: As I indicated earlier [I-D.ietf-ospf-transport-instance] can be > definitely used if the information related to application need to be used > there. If it is used for supporting routing one can use this TLV. > > > > Without addressing both of these issues I cannot support the draft. > > Les > > > > -----Original Message----- > > From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem > > (acee) > > Sent: Wednesday, March 16, 2016 7:09 PM > > To: OSPF WG List > > Subject: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for > > Agile Service Deployment" > > > > We’ve discussed this draft a number of times. In my opinion, it seems > > like a useful mechanism if one envisions a generalized API between > > OSPF and user and third-party applications to convey > > application-specific information learned from other OSPF routers. In > > many respects, this has already been envisioned for OSPF Node Tags. > > Please indicate your opinion on this draft before March 31st, 2016. > > > > 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
