[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

Hi Wataru,
 
Just adding to Adrian's points...
 
I think it is useful to separate A and M bits. When the LSP is put in administratively down, e.g.,  to avoid it is carrying traffic for any reason, it would be still useful to run data plane OAM so one knows the data plane is in tact when the LSP is put back operational. That is,  A=1, M=0. On the other hand, e.g., in the case of planed maintenance, one might want to turn data plane OAM off as well, having A=1, M=1.
 
Regarding the I bit, I think even if GMPLS alarm communication is disabled, the actual monitoring of data plane connectivity is needed, again to have the up to date status of the data plane.
 
In summary, I think having a separate M bit is useful, and accounts for flexibility.
 
Best regards,
Attila
 
 

From: Wataru Imajuku [mailto:imajuku.wataru@lab.ntt.co.jp]
Sent: Wednesday, December 05, 2007 9:53 PM
To: Attila Takacs
Cc: ccamp@ops.ietf.org
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

Hi, Attila

 I understand this proposal automates manual configuration to set CFM interval in data plane.
 Control of CFM interval is new issue which GMPLS signaling mechanism has not covered.
 Although you outline Ethernet OAM functionality in section 2, I think it is better to describe what is difference and what is common in OAM functionality compared to circuit switched technologies
which GMPLS has been covered.

 On the other hand, I could not understand why do you need M bit in Admin Status Object.
 Why do not use A=1 ?
 Is the objective of M bit to stop sending CCM temporally ?

Best Regards
Wataru

At 04:37 07/12/06, Attila Takacs wrote:
"urn:schemas-microsoft-com:vml" xmlns:o = "urn:schemas-microsoft-com:office:office" xmlns:w = "urn:schemas-microsoft-com:office:word" xmlns:st1 = "urn:schemas-microsoft-com:office:smarttags">
Hi all,
 
Neil's and Dan's summary are exact. Thanks for your comments!
 
Maybe the title of the ID caused the misunderstanding, it would say more if it would read: "GMPLS RSVP-TE Extensions to *Control* Ethernet OAM".
Nevertheless, when updating the ID we will clarify our point even more.
 
Best regards,
Attila

From: Dan Li [mailto:danli@huawei.com]
Sent: Wednesday, December 05, 2007 6:01 PM
To: Diego Caviglia; neil.2.harrison@bt.com; Attila Takacs; tnadeau@lucidvision.com
Cc: ccamp@ops.ietf.org
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

Hi,

 
I think there is a misunderstanding with respect to the objective of this draft.

 
As I read this draft, it describes how to extend the RSVP protocol to support the configuration/enable the OAM function of Ethernet LSP, which I think is a good thing to do, it is not saying to use signaling protocol to do the OAM work. But anyway, it may be necessary to clarify the objective at the beginning of this draft.

 
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稚 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 叢iggyback？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池e 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 壮ession？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

 

-------------------------------------
Wataru Imajuku, Ph.D.@NTT Network Innovation Labs
TEL: +81-46-859-4315
FAX: +81-46-859-5541