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, "[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), 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
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
