The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B927CE@zcard031.ca.nortel.com>, "
David Allan" writes:
> 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


Dave,

I never understood RFC3429 to be an endorsement of Y.1711 by the IETF
but rather an individual Informational RFC informing the community of
the ITU work and the IANA assignment only indicates that the IETF
would not stand in the way of the ITU work by failing to assign a
number.  You do recall that there was significant opposition to the
ITU approach which is why the original authors took the work out of
the IETF to the ITU and then later considerable discussion as to
whether to assign the reserved label number at all.

Curtis