The MPLS WG Archive

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

Title: RE: MPLSOAM BOF meeting draft minutes

Curtis:
>
> The original MPLS-OAM work was not accepted as MPLS WG item in the
> IETF. 

Yes, the proponents were sent away to collect requirements and demonstrate operator support.

> That it was brought to the ITU should not affect what goes on
> in the IETF except that if the IETF supports this the IETF should not
> duplicate work but just reference it and if the IETF sees similar
> requirements but does not support the MPLS-OAM approach the IETF
> should be free to deviate from it or ignore it completely.

I was not suggesting that any proposal had special merit in the context of IETF process (none should), but understanding the thinking behind some of this stuff would be a useful exercise rather than dismissing it out of hand.

<snip>

> LSP Ping is relatively new so I agree that there is no prior consensus
> behind it.  I was not at the meeting so I do not know what measure of
> support it has.  The use of the existing wire rate ICMP processing for
> non-IP LSPs was a very good idea. 

Can you elaborate on the "very" part? I tend to see it as a useful expediency, and that's OK, but it has limitations and does not meet all my customers requirements, and IMHO may not be sufficiently extensible to do so without the "playing field levelling" upgrade everyone is trying to avoid.

> Solid engineering rarely comes out
> of committees which is why running code is such a good requirement.

Implementation experience can make a specification better, but lets not confuse "existence proofs" with "solid engineering".

 
> If the ITU has requested that the IETF consider an OAM label, if there
> is no consensus to adopt MPLS-OAM in any WG the IESG may be in a
> position to respond that they did so in the past and rejected it, and
> did so again and rejected it because they have another means of
> accommodating the functionality that MPLS-OAM would have provided.
> The reason I used the words "if" and "may" is that this is not a
> foregone conclusion.

Sorry, I cannot parse the above.....

cheers
Dave