The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Dec> msg00209



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

MPLSOAM BOF meeting draft minutes

  • From: Curtis Villamizar <curtis@workhorse.fictitious.org>
  • Date: Mon, 17 Dec 2001 15:50:09 -0500
  • cc: curtis@fictitious.org, "Cuevas, Enrique G, ALCTA" <ecuevas@att.com>, dave.mcdysan@wcom.com, giles@packetexchange.net, Shahram_Davari@pmc-sierra.com, "Don Fedyk" <dwfedyk@nortelnetworks.com>, Ben.Mack-Crane@tellabs.com, mpls@UU.NET, neil.2.harrison@bt.com


In message <3549C09B853DD5119B540002A52CDD3401267731@zcard0ka.ca.nortel.com>, "
David Allan" writes:
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
> 
> ------_=_NextPart_001_01C1872E.0DE6CF00
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> 
> Curtis:
> 
> You make some reasonable points, but your compare and contrast of the
> different proposals blurs several things together and avoids what I think is
> the real issues in the debate. 
> 
> The original fault management work brought to ITU-T Y.1711 and to the IETF
> back in Pittsburgh involved a one way continuity check and fault
> notification transactions (collectively CV, FDI, and BDI).
> 
> Some of us have proposed some extensions to this in our messaging draft in
> the form of a loopback (for explicit or implicit bi-directional LSPs, either
> for ad-hoc verification and/or RTT measurement) and an initial stab at
> performance measurement and an extensibility framework. IMHO these are
> reasonable extensions. 
> 
> At the present time I don't think consensus can be said to exist for any
> technical proposal. That we don't agree on an explicit solution right off is
> OK. If we cannot agree on the general attributes of a solution we have a
> problem.  I think it would be useful to understand if that's the real
> situation (rather than arguing the minutae of ICMP octet 3 vs. CV octet 7). 
> 
> It should be noted that lot of folks have already given the topic a lot of
> thought. It is not their fault that this group has not been willing in the
> past to entertain this discussion and as a consequence you've not been privy
> to all the details. With that in mind I think there's lots of room for
> constructive dialog.
> 
> rgds
> Dave



Dave,

The original MPLS-OAM work was not accepted as MPLS WG item in the
IETF.  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.

No issue with anything above except:

> At the present time I don't think consensus can be said to exist for any
> technical proposal.

I think GTTP has considerable history and considerable support.  It is
direct response to work called for by the MPLS WG and the IESG.

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.  Solid engineering rarely comes out
of committees which is why running code is such a good requirement.

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.

Curtis