Re: WGLC for draft-rtgwg-mrt-frr-architecture

[Stewart Bryant <[e-mail]>]

Alvaro

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?

- Stewart


On 09/12/2015 16:52, Alvaro Retana (aretana) wrote:
> On 12/8/15, 9:49 AM, "[e-mail] 
> <mailto:[e-mail]>" <[e-mail] 
> <mailto:[e-mail]>> 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), somemid pointto
>     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)isfine with documenting multiple/many, independent solutions,
>
>     b)isfine with many solutions but want to evaluate them to see
>     which one is the best fit depending on the deployment case
>
>     c)whetherwe 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg