[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
yes - that was what I asked :)
/Loa
neil.2.harrison@bt.com wrote:
> Loa,
>> With that it we should just go ahead and accept this as a
>> ccamp work item.
> If you are asking whether this should be adopted as a WG item then I am in favour.
>
> regards, neil
>
>
>> -----Original Message-----
>> From: Loa Andersson [mailto:loa@pi.se]
>> Sent: 05 December 2007 20:37
>> To: Dan Li
>> Cc: Diego Caviglia; Harrison,N,Neil,DMN R; Attila Takacs;
>> tnadeau@lucidvision.com; ccamp@ops.ietf.org
>> Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>
>>
>> All,
>>
>> I'm normally a bit careful with models "layer networks" that
>> seems to be a rather cumbersome way of explaining the
>> obvious; however in this case when it is used demonstrate
>> that no layer violation is at hand I is inclined to accept
>> that result.
>>
>> I also agree with Dan that it seems to be a good idea to use
>> RSVP-TE to provision OAM functionality is a good idea.
>>
>> With that it we should just go ahead and accept this as a
>> ccamp work item.
>>
>> /Loa
>>
>> Dan Li wrote:
>>> MessageHi,
>>>
>>> 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'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
>>>
>>>
>>>
>>
>> --
>> Loa Andersson
>>
>> Principal Networking Architect
>> Acreo AB phone: +46 8 632 77 14
>> Isafjordsgatan 22 mobile: +46 739 81 21 64
>> Kista, Sweden email: loa.andersson@acreo.se
>> loa@pi.se
>>
>> This email was Anti Virus checked by Astaro Security Gateway.
> http://www.astaro.com
>
>
>
--
Loa Andersson
Principal Networking Architect
Acreo AB phone: +46 8 632 77 14
Isafjordsgatan 22 mobile: +46 739 81 21 64
Kista, Sweden email: loa.andersson@acreo.se
loa@pi.se
This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com