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

From: Igor Bryskin <[email-masked]>
Date: Thu, 6 Dec 2007 06:58:03 -0800 (PST)

Hi Watatru,

Although I understand, I think, your point - Enabling/disabling  of alarm reporting and enabling/disabling of OAM for a given connection may seem similar in spirit - I agree with Attila and Adrian: the two   functions are very distinct and we certainly don't want to overload the A-bit.

Cheers,
Igor

----- Original Message ----
From: Attila Takacs <[email-masked]>
To: Wataru Imajuku <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, December 5, 2007 10:07:37 PM
Subject: 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:[email-masked]] 
Sent: Wednesday, December 05, 
  2007 9:53 PM
To: Attila Takacs
Cc: 
  [email-masked]
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:[email-masked]] 

      Sent: Wednesday, December 05, 2007 6:01 PM

      To: Diego Caviglia; [email-masked]; Attila Takacs; 
      [email-masked]

      Cc: [email-masked]

      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: [email-masked] ; Attila Takacs ; [email-masked] 

      Cc: [email-masked] 

      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: [email-masked] [mailto:[email-masked]] 

      Sent: marted・4 dicembre 2007 22.55

      To: Attila Takacs; [email-masked]; Diego 
      Caviglia

      Cc: [email-masked]

      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: [email-masked] [mailto:[email-masked]] On Behalf Of 
      Attila Takacs

      Sent: 05 December 2007 02:03

      To: Thomas Nadeau; Diego Caviglia

      Cc: [email-masked]

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

      Hi Tom,

      please see 
inline.

      Best regards,

      Attila

      

      From: Thomas Nadeau [mailto:[email-masked]] 

      Sent: Wednesday, December 05, 2007 2:19 AM

      To: Diego Caviglia

      Cc: Attila Takacs; [email-masked]; 
[email-masked]

      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: [email-masked] [mailto:[email-masked]] 
      On Behalf Of Thomas Nadeau

      Sent: marted・4 dicembre 2007 11.30

      To: Attila Takacs

      Cc: [email-masked]; [email-masked]

      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:[email-masked]] 

      Sent: Tuesday, December 04, 2007 2:58 PM

      To: [email-masked]

      Cc: Attila Takacs; [email-masked]

      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

      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping