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.
From your comment I see that you’re
not happy with the fact the ID is so technology specific am I right? 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?
Best Regards
Diego
From:
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Thomas Nadeau
Sent: martedì 4 dicembre 2007
11.30
To: Attila Takacs
Cc: ccamp@ops.ietf.org;
balazs.gero@ericsson.com
Subject: Re:
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:
Thank you for the comments!
Please see answers inline.
From: Thomas
Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Tuesday, December 04, 2007
2:58 PM
To: ccamp@ops.ietf.org
Cc: Attila Takacs; balazs.gero@ericsson.com
Subject:
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
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.
|