----- Original Message -----
From: "Yaakov Stein" <yaakov_s(_at_)rad(_dot_)com>
To: "Ross Callon" <rcallon(_at_)juniper(_dot_)net>; "Rolf Winter"
<Rolf(_dot_)Winter(_at_)neclab(_dot_)eu>;
"Stephen Kent" <kent(_at_)bbn(_dot_)com>; <ietf(_at_)ietf(_dot_)org>
Sent: Sunday, October 16, 2011 5:09 PM
The IETF has a very long history of pushing back on multiple redundant
solutions to the same problem.
There are a great many cases of ADs, working group chairs, and others
pushing quite hard
to prevent multiple solutions when one would work fine.
I haven't seen this in the OAM work so far.
PWE's VCCV has 3 or 4 different channels (code named CC types)
and 3 or 4 different OAM mechanisms (code named CV types).
And each of these has several variants and most have several possible
encapsulations.
Similarly in the MPLS-TP work we have a large number of options.
For example, draft-ietf-mpls-tp-on-demand-cv has 3 different encapsulations
(LSP-ping UDP/IP packet in MPLS, LSP-ping packet in UDP/IP in GACh,
and "raw" LSP-ping packet in GACh with a new channel type).
Why is it that no-one seems to object to a plethora of possible options for
anything
except the inner-most payload format?
Yaakov
Because MPLS-TP is not really IETF work:-)
The processes of MPLS-TP have been IETF-like but diverging from IETF in a number
of small ways and it is this that has, for me, allowed the many different
solutions that you refer to to emerge. Outside MPLS-TP, I rarely see this
occurring except in a very generic case of a protocol running over both UDP and
TCP, or TCP and SCTP.
Tom Petch
In other fields,
Y(J)S
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf