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