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