The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] on the mpls oam framework
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
|
|