----- Original Message ----- From: "Yaakov Stein" <yaakov_s@xxxxxxx> To: "Ross Callon" <rcallon@xxxxxxxxxxx>; "Rolf Winter" <Rolf.Winter@xxxxxxxxx>; "Stephen Kent" <kent@xxxxxxx>; <ietf@xxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf