|
Hi
Tom,
please
see inline.
Best
regards,
Attila
On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:
Hi
Thomas,
My understanding of the ID was that RSVP-TE can be used to ?piggyback? CFM
set-up, otherwise the scenario is: usage of RSVP-TE to set-up the LSP and
NMS (meaning everything that is not control plane) to enable to CFM for the
LSP.
As I understand it, the
IEEE is working on set-up of CFM (and MEPs), as are some vendors I know.
*)
This to me seems like the right way to do this.
IEEE
specified CFM and MIBs to setup CFM.
Diego's summary is correct: one can use an NMS or a control plane to
setup the data plane. In this case we propose to use GMPLS to setup the
data plane: both forwarding + OAM.
From
your comment I see that you?re not happy with the fact the ID is so
technology specific am I right?
Precisely; its
gluing CFM to RSVP-TE/GMPLS as a transport.
I do
not see your point with gluing. What do you mean by "as transport"? GMPLS is
just controlling OAM, CFM is run solely in the data plane.
If
yes do you agree with the fact that could be useful in general to use the
same signaling ?session? to set-up the LSP and to enable the
CFM?
No, I do not
agree. Again, if CFM is to be set-up e2e, let the IEEE define this.
Leave GMPLS to CCAMP.
Sorry,
I cannot follow.
--Tom
Best
Regards
Diego
On Dec 4, 2007,
at 1:51 PM, Attila Takacs wrote:
Thank you for
the comments!
Please see answers
inline.
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.
This solution
specifically only works for GMPLS ethernet LSPs, right?
What do I do if
I want to set up MPLS ethernet LSPs (i.e.: PWs) and do CFM over those?
Oh,
that is a
different solution, right? Then what do I do if I want to run CFM over
some new type of
ethernet LSP in
the future? More protocol hacks? The point is to use CFM over an
ethernet interface
without the
underlying layers knowing. This is good networking architecture design, that
simplifies
implementations
and makes them more robust, as well as makes using them operationally
much
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
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.
The point I am
making is that perhaps it should.
|