RE: Last Call <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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?

 
Y(J)S


_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]