[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Hi Tom.
Good question, but I guess this can already find some pieces of answers. Quoting the BFD base draft: "For example, an OSPF implementation may request a BFD session to be established to a neighbor discovered using the OSPF Hello protocol."
Personally, I believe it is useful to have a signaling mechanism to configure OAM in a distributed environment. Considering a GMPLS context, RSVP-TE is just there between end points. What is more, when establishing an LSP, I am concerned with recovery aspects (already there thanks to the Protection object) and obviously with the OAM allowing this recovery to happen (and OAM is not implicit in case of packet-switched connection).
Regards,
Julien
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Thomas Nadeau
What do we do for the other signaling protocols outside of CCAMP?
Do we now extend BGP, RSVP-TE (for MPLS), and LDP to control OAM there
as well?
--Tom
> 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
>
>