The MPLS WG Archive

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

Hi Curtis:

I wouldn't describe it as a ringing endorsement ;-). More a reflection of
the schimsm that the MPLS WG was not going to reach any sort of consensus on
OAM at the time as most folks considered it to be not required, did not
necessarily like the solutions etc. etc. etc. Now this topic seems to have
come forward to some degree and the question is what do we do.....

IMHO 1711 and 17fec-cv should be useful candidates. I understand some
concerns with the dataplane, and it would be useful if some of those issues
could be addressed. The key issue being primarily on how payload is
identified. The PW PID is an example of how this can be addressed without
fundamentally undoing the work, IMHO other options exist. 

cheers
Dave

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] 
> Sent: Sunday, November 16, 2003 5:41 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'neil.2.harrison@bt.com'; kireeti@juniper.net; loa@pi.se; 
> mpls@UU.NET; swallow@cisco.com; zinin@psg.com
> Subject: Re: on the mpls oam framework 
> 
> 
> 
> In message 
> <FFFC48AEAA5F7447929F4F0D93FCC12D02B927CE@zcard031.ca.nortel.c
> om>, " 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
>