[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
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