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 |