|
Hi
Thomas,
Thank
you for the comments!
Please
see answers inline.
Best
regards,
Attila
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.
The
application of the draft is exactly for what you are calling out: when CFM
is run natively over the Ethernet interfaces. The document focuses on GELS and
Ethernet LSPs. That is, to establish CFM entities for GMPLS controlled
Ethernet LSPs. Hence, I think there is no
layer violation issue.
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?
It is
right that frequent CCMs are not required if the layers below Ethernet handle
protection. However, the ID focuses on Ethernet LSPs where Ethernet is not
just a single hop above a transport LSP. In this case Ethernet
layer (for clarity GELS) may provide protection for Ethernet LSPs. In any
case, the whole point of the ID is to allow for the appropriate
configuration of CFM for Ethernet LSPs with GMPLS.
3) This
document does not cover E-LMI. Why not?
E-LMI
is run over the MEF UNI. The ID focuses on Ethernet LSPs within a
network.
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?
Well, GELS is done in CCAMP...this seems to be the right
place.
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
See the note to
your point #1. There is no relation to the gmpls-LSP-ping
draft.
|