The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Nov> msg00100



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

on the mpls oam framework

  • From: "David Allan" <dallan@nortelnetworks.com>
  • Date: Mon, 17 Nov 2003 11:11:39 -0500

Hi again:
<snipped>
> >I'm not. I'm sure I'm not the only person who has noted the oxymoron 
> >inherent to the requirement "must support undocumented proprietary 
> >feature". I'm suggesting it MUST be documented in order to proceed.
> 
> 	I am suggesting that doing so is not a scalable
> problem to solve.  

Not parsing?

> Also practically speaking, I doubt
> that anyone is going to divulge their exact algorithm.
> It might be an interesting informational draft to 
> produce such a compendium from anonymous sources, but
> this always leaves open the door for one more algorithm.

Then that's tough for those who do not share. If you want interoperable OAM,
you have to play. IMHO the minimum requirement is exact what fields are
examined, how much of the stack, interface IDs etc. I'm less concerned about
whether it is CRC-32 or BIP-16 or whatever. 

<snipped>
> >That's not the suggestion. The suggestion is that we only
> >support what we can see. 
> 
> 	That sounds like you want connection-oriented
> constructs only too. *)

Is this comment relevant?

<snipped>
> 	While I would of course agree that knowing all of the 
> algorithms would make things easier, I disagree that we 
> cannot move forward with solutions today. I think that 
> solutions can be 
> created to manage what is deployed today. There is clear 
> evidence of this already.

As I say, we all need to be able to innovate in this space. At the moment
the majority of the list is disenfranchized. This is a problem. Either the
WG sticks with the decision that this is not specified and recognizes that
the quality of what it gets for interoperable OAM is unknowable, or people
at least 'fess up informationally and we can all participate. Which version
do you think is the IETF way....

BTW, would be nice to get some other opinions, IMHO this is rather
fundamental....

cheers
Dave