On 12/10/15, 8:03 AM, "Stewart Bryant" <[email protected]<mailto:[email protected]>> wrote:
[Still speaking as an individual.] Stewart: Hi! My experience of the IETF is that it tries quite hard to get to a single solution per problem domain on the standards track. Now maybe the IESG position on this has changed but the expectation is that normally there would only be a single ST RFC. Also ST normally expresses a view that the solution is the best we currently have and I do not believe there is consensus in the WG for that position. Are you making a definitive statement that publishing this as ST will not preclude the publication of other competing solutions at the same level? As I wrote below, my statements were made as an individual. As I also wrote below, "(given that there's nothing wrong with "a"), a WG may decide on a specific Status based on the fit of the technology to the deployment case(s), the existence (or not) of other solutions, etc.". To specifically answer your question. My statement is as definitive as my personal opinion is right now. I don't see anything in the current rtgwg charter that precludes the publication of other solutions into the Standards Track - with the caveat of course that the WG should follow the normal process and make the decision itself. Alvaro. - Stewart On 09/12/2015 16:52, Alvaro Retana (aretana) wrote: On 12/8/15, 9:49 AM, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> wrote: [Speaking as an individual.] [This is a little bit off the topic of draft-rtgwg-mrt-frr-architecture. But worth discussing.] As a general comment, we indeed have multiple FRR solutions ( e.g. TI-LFA, RLFA, RLFA node protection, TI-FRR, MRT, TI-LFA, RSVP-TE 1 hop link protection, end to end RSVP-TE FRR (multiple flavors and new additional extensions discussed in MPLS WG), some mid point to some other mid points RSVP-TE...) plus discussed in multiple WG (RTGWG and MPLS, a priori TI-LFA would be discussed in RTGWG rather than SPRING (although TI-FRR could possibly also be discussed in RTGWG rather than MPLS)) So there may be a question whether the IETF: a) is fine with documenting multiple/many, independent solutions, b) is fine with many solutions but want to evaluate them to see which one is the best fit depending on the deployment case c) whether we need to choose N solutions based on technical merits Even if we reduce the scope of the question from the IETF to the Routing Area or even a specific WG, the answer is probably going to be in line with your thoughts: Personally, I don't really have a strong preference, but they seem ranked from faster/easier to longer/harder. So far I assumed that "a" had been chosen. May be "b" would make sense, assuming I'm not the one doing the job ;-) . I'm afraid "c" would burn many times, for limited benefits. (I can already foresee some lengthy discussions just to pick the "right" value for N, before even starting the technical evaluation) I agree. "c" opens a can of worms that no one wants. My personal opinion is that there's nothing wrong with "a" [*]. While you didn't explicitly say so, "b" could be interpreted as related to the Status (Standard, Experimental, Informational) of the work. It may be interesting to evaluate which solution is the best fit [**], but then again, I don't see anything wrong with "a". Even if a document is published as a Proposed Standard, it should never make it to an Internet Standard is people don't use it. Having said that, I also think that (given that there's nothing wrong with "a"), a WG may decide on a specific Status based on the fit of the technology to the deployment case(s), the existence (or not) of other solutions, etc. Just a personal opinion.. Alvaro. [*] Unless a WG is explicitly chartered to provide a single solution, of course. [**] That is probably another can of worms. :-( _______________________________________________ rtgwg mailing list [email protected]<mailto:[email protected]>https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
