The MPLS WG Archive

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

Bonjour Monique:

> "Whoa, meme merde, autre jour ;-)"
> 
> C'est quoi comme langage cher David??

Comes from a long Euro-travel cycle ;-)


> One minor nit:  y.1712, fec-cv are currently draft ITU-T 
> recommendations and have not yet attained approved 
> recommendation status yet as these are still being discussed 

Still up in the air like everything else on the list ;-)

> certainly shall be this week at the interim ITU-T meeting in Geneva

I'm already there....

rgds
Dave


> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf 
> Of David Allan
> Sent: 15 November 2003 23:03
> To: 'neil.2.harrison@bt.com'; kireeti@juniper.net; loa@pi.se
> Cc: mpls@UU.NET; George Swallow (swallow); zinin@psg.com
> Subject: RE: on the mpls oam framework
> 
> 
> 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
> 
> 
>