After reading this draft, I have some questions/comments.
1) Overall, I am concerned that the definition of a new TLV and these procedures represent
what amounts to a laying violation and ask that the ADs take a look at this
approach closely. This is similar to the now-rejected approach that was proposed
in the l2vpn WG about munging CFM + PWs. To my reading, this is essentially
the same thing. If you want to run CFM, run it natively over the ethernet interfaces and
have no regard for the underlying topology (GMPLS, PWs, etc...) otherwise you
will be creating a mess for implementations and interoperability.
2) The introductory sections in this draft give a lot of discussion about fast fault detection. I
am puzzled by this given that GMPLS networks tend to run over quickly self-healing
optical infrastructures. Is it therefore truly necessary to motivate this work by
requiring fast CFMs?
3) This document does not cover E-LMI. Why not?
For the purposes of this document, we only discuss Ethernet OAM
[IEEE-CFM] aspects that are relevant for the connectivity monitoring
of bidirectional point-to-point PBB-TE connections.
4) Is this the right place to define this document or should this be done in GELS?
5) In section 2 you make the following statement:
2. GMPLS RSVP-TE Extensions
To simplify the configuration of connectivity monitoring, when an
Ethernet LSP is signalled the associated MEPs should be automatically
established. Further more, GMPLS signalling should be able to
enable/disable connectivity monitoring of a particular Ethernet LSP.
To my point in #1 above, you should use the native CFM functionality over the ethernet interface and signal
those capabilities to the bridges at both ends using the IEEE CFM signaling procedures (when and if they
are created). If you want to test the underlying GMPLS LSP(s), then you should use some
other mechanism defined for that layer such as the work stated in draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt