The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Whoa, meme merde, autre jour ;-)

One of the goals of the framework draft we brought forward was to facilitate
understanding of the implications of particular aspects of the architecture
when it came to measurement and fault detection. Some things were
impossible...end of story. We can enumerate this individually by solution if
we want to go down that route, but ultimately that analysis in some form is
required if the document is to have any semblance of intellectual and
practical honesty and be useful to the industry. Those particular aspects in
whatever form they take are important to bring forward, as simply
enumerating the solution space without "criticism" is useless. To also
pretend these things do not have impact because an extra million lines of
code, a few generations of Moores law and protocol design can sort it out is
also IMO not useful.

I have an idea of what consitutes data plane OAM, and thought that had been
delegated to the ITU with RFC 3429. I also thought Scott had a pretty clear
demarcation in viewing ping and traceroute as IETF balliwack but the other
"telco" stuff out of scope. Clearly that has changed and what that means
needs some elucidation. That the can of worms has been reopened at the IETF
is clear, and it behooves me to chime in, but I'm not clear on precisely why
it has been reopened.

We already have LSP-PING, LSR-SELF-TEST (a ping derivative), VCCV (a ping++
derivative) none of which so far would appear to have required charter
changes by the previous operating definition. We also now have BFD which is
more in the 1711 class of tools. On the other side of the house we have
Y.1710/11/12/20/fec-cv. With the exception of perhaps wrapping this stuff in
a bit of context, what extra needs doing?

cheers
Dave