Regards,
Dan
----- Original Message -----
From: Diego Caviglia
To: neil.2.harrison@bt.com ; Attila Takacs ; tnadeau@lucidvision.com
Cc: ccamp@ops.ietf.org
Sent: Thursday, December 06, 2007 12:27 AM
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Hi Neil,
Yes I totally agree with your analysis.
The is not going to redefine or reinvent the OAM that, as Thomas
as pointed out, is done by IEEE, the ID just specify how to use a
control plane mechanism (GMPLS) set-up at the same time data plane
circuit and the related OAM.
Frankly specking I don't see any layer violation here.
BR
Diego
------------------------------------------------------------------------------
From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: martedì 4 dicembre 2007 22.55
To: Attila Takacs; tnadeau@lucidvision.com; Diego Caviglia
Cc: ccamp@ops.ietf.org
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
I'm puzzled. I read the draft and thought it was excellent. It
is addressing an important operational issue, ie a critical
operational OAM requirement is to ensure that whatever mechanism
(MP or CP) is used to set-up/tear-down a connection (so this only
applies to co-cs or co-ps modes....the cl-ps mode does not have
connections of course) is harmonised to the activation/deactivation
of the OAM.....specifically a CV/CC flow. If we don't ensure this
then there will be obvious operational problems. This is
essentially what the draft is about.
Further, GMPLS is a generic OOB CP technique.....it is not a
specific layer network technology per se (but it is specific in
it's choice of signalling and routing components). So one can
apply a largely similar (GMPLS) CP technique to all co-cs mode
technologies (whether they are partitioning a space, freq or time
resource - see Note) and co-ps mode technologies (which only
applies to partitioning a time resource - see Note) on the
assumption that the technology is correctly architected in the DP
for the mode considered. It's pretty hard not to correctly
architect the co-cs mode, but it's quite easy to incorrectly
architect the co-ps mode, eg one can't violate the rules of a
connection in the co-cs mode but one can in the co-ps mode.
Note - When we partition a time resource in regular time-slices we
create a co-cs mode layer network. When we partition a time
resource in irregular time-slices we create a co-ps mode layer
network. More information on labelling and resource partitioning
can be found in the work on unified modelling (of networks) in G.800.
regards, Neil
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]
On Behalf Of Attila Takacs
Sent: 05 December 2007 02:03
To: Thomas Nadeau; Diego Caviglia
Cc: ccamp@ops.ietf.org
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Hi Tom,
please see inline.
Best regards,
Attila
--------------------------------------------------------------------------
From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Wednesday, December 05, 2007 2:19 AM
To: Diego Caviglia
Cc: Attila Takacs; 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 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
--------------------------------------------------------------------------
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:
Hi Thomas,
Thank you for the comments!
Please see answers inline.
Best regards,
Attila
------------------------------------------------------------------------
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
easier.
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.
The point I am making is that perhaps it should.
--Tom