[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,
You asked 05 December 2007 22:12
> 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
The principle I gave stands....this behaviour is required irrespective of what mechanism (CP signalling or MP provisioning) is responsible for setting-up/tearing-down a *connection*. This is not a new requirement. I've mentioned this requirement several times in posts to various WGs over the years and you will find this requirement mentioned in Y.1711. We also stated this as a requirement in the now expired draft 'draft-willis-pwe3-requirements-00.txt (which can still be found at http://www2.tools.ietf.org/html/draft-willis-pwe3-requirements-00) when attempting to provide guidance to PWE3 on OAM requirements back in 2004. In section 1.2 therein we gave some background wrt to the different OAM required for the 3 network modes of cl-ps, co-ps and co-cs (as the OAM required is not the same in all 3 cases)....here is the relevant extract wrt to the activation/deactivation topic of this thread:
".....the OAM activation/deactivation must be harmonized with the set-up/tear-down of the path. Failure to harmonize OAM activation/deactivation with PW set-up/tear-down will lead to either:
- lack of OAM protection when the PW is set-up, or false alarms
when the PW is torn-down; or
- OAM being activated prior to PW set-up and significant problems due
to operator error."
You'll note I highlighted the word *connection* above....this is rather important. One can't activate/deactivate OAM in concert with connection set-up/tear-down if one does not have a connection, eg cl-ps mode. There are also no problems when dealing with the co-cs mode as this is forced to respect the requirements of a connection (which, to summarise are: (i) single source (ii) no re-ordering of traffic units). However, the LDP form of MPLS does not respect the requirements of a connection as it creates a mp2p merging construct.....PHP has a similar merging behaviour on the last hop on an LSP. So the activation/deactivation of OAM in concert with such constructs has no meaning.....indeed, one can't even say we have a proper layer network here, and this is not simply due to violating the rules of a connection but results from the fact that an MPLS traffic unit does not provide consistent characteristic information, eg the label field can take on at least 4 different semantics (and this list is still growing, eg fat PWs). If not obvious what the problem is here, if traffic gets misdirected then the receiving node could misinterpret the meaning of the label.
So, we can't apply the requirement MPLS LDP/PHP networks.....these can only use 'on-demand' OAM mechanisms.....just the nature of the beast.
However, when we have a co-cs or co-ps mode network that does respect the requirements of a connection then it makes a huge amount of operational sense to make sure one activates/deactivates the OAM in conjunction with the connection set-up/tear-down.
And this is not simply a matter of 'good housekeeping' for the service provider, including things like the ability to provide a protection-switching capability, there is a security issue here......which is especially germane in the case of a co-ps mode technology based on label-swapping. That is, if one has a defect that causes misdirected traffic it is important to be able to proactively detect such a case and take appropriate action, eg squelch the traffic, in order to protect the integrity of the affected client traffic.
This issue is not a problem for networks that have network unique and non-swapped labelling, ie all cl-ps mode technologies and PBB-TE in the co-ps mode, ie these network are inherently robust to misconnectivity defects without any OAM at all (since each traffic unit essentially carries it own CV function due to presence of the SA). However, in the case of PBB-TE we still require the OAM activation/deactivation in concert with the connection set-up/tear-down as we need to distinguish the cases of 'quiescent client traffic' from 'simple break'. Moreover, as I already noted, we also need the OAM for protection-switching requirements.
regards, Neil
>
>
> > 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
> >
> >
>
>