Re: [mpls-tp] Linera Protection - Operator commands terminology.
Mahesh Akula <mahesh.akula36@gmail.com> Wed, 16 June 2010 19:19 UTC
Return-Path: <mahesh.akula36@gmail.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id 838943A6BAB for <mpls-tp@core3.amsl.com>;
Wed, 16 Jun 2010 12:19:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=-1.200,
BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_36=0.6,
J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aqn5oloVjrI for
<mpls-tp@core3.amsl.com>; Wed, 16 Jun 2010 12:19:49 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com
[74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id B1A943A6BAA for
<mpls-tp@ietf.org>; Wed, 16 Jun 2010 12:19:41 -0700 (PDT)
Received: by pvc30 with SMTP id 30so425369pvc.31 for <mpls-tp@ietf.org>;
Wed, 16 Jun 2010 12:19:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:received:in-reply-to
:references:date:message-id:subject:from:to:cc:content-type;
bh=D9AsHdu3tTVQY4jWnMBuhWkuS5MOurPYoRiqPjcQlRM=;
b=mW/dy4tusPBDGK1EG0MX/E/1E8hXAgAolup5wtep1B03F5QTmpw/OyNCgEuJQZFr4K
h5QJLyNUhrjLj/EMDzfKBu1UXvIBDoy76PcVPm7Z/3Kh7QG9X8uTnmUWliZKQna/49eb
hKhwzcRFpmqcsSyNorY32EGQE6zB7FlDhYeO4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
b=ISwJu/o3Mw/cm38M0jIjtYe8YjKLDV5XbvLWlUbi29dWUEcKoavp4/bJ1o4CQqbXc/
Mu6K6vyMjqyb9jjWbglkPUX0ZI5m58rXzX1BCFa0X4Vt85rNz5TzzDgBgZcTFqomLmgC
+GyZShNyyP9A0djLmOCh0smV8duB3NnaIbJvc=
MIME-Version: 1.0
Received: by 10.143.25.2 with SMTP id c2mr6541387wfj.147.1276715983460;
Wed, 16 Jun 2010 12:19:43 -0700 (PDT)
Received: by 10.142.102.19 with HTTP; Wed, 16 Jun 2010 12:19:43 -0700 (PDT)
In-Reply-To: <D24353715A854C7280A5707C8CA9C933@etri.info>
References: <D24353715A854C7280A5707C8CA9C933@etri.info>
Date: Wed, 16 Jun 2010 12:19:43 -0700
Message-ID: <AANLkTin3fRsfGWnC53qNzU8zLlZ-BBlZPjITM3pMY05P@mail.gmail.com>
From: Mahesh Akula <mahesh.akula36@gmail.com>
To: "Ryoo, Jeong-dong" <ryoo@etri.re.kr>
Content-Type: multipart/alternative; boundary=001636e1f81bac5b1504892a9aa7
Cc: mpls-tp@ietf.org
Subject: Re: [mpls-tp] Linera Protection - Operator commands terminology.
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>,
<mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>,
<mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Jun 2010 19:19:51 -0000
Hi Jeong-dong, Thanks, yes it does clarify the usage of those commands to me. Regards, Mahesh On Wed, Jun 16, 2010 at 3:24 AM, Ryoo, Jeong-dong <ryoo@etri.re.kr> wrote: > Hi, Mahesh. > > Everything you said is ok, except the fact MS is to move the normal traffic > to the protection path, and MS-W is to move the traffic to the working > path.FS is to move the traffic to the protection path. > > When an operator issues the FS command and removes a node/link in the > working path, there would be no SF report to the operator or its management > system. This says that something happening in the working path is due to the > intentional act of the operator, not by the defect in the working path. > > During MS state, if a node/link is removed in the working path, SF will > occur and the traffic goes to the protection path. > > MS-W is for moving the traffic to the working path, and it can be used in > DNR state or WTR state. > I hope this can clarify the definition/usage of those commands. > > Jeong-dong > > ============================================== > Jeong-dong Ryoo, Ph.D. > Principal Member of Research Staff > Network Research Department > Electronics and Telecommunications Research Institute (ETRI) > Phone: +82-42-860-5384, Fax: +82-42-860-6342 > Email: ryoo@etri.re.kr > ============================================== > > -----Original Message----- > *From:* "Mahesh Akula" <mahesh.akula36@gmail.com> > *From Date:* 2010-06-16 AM 7:54:37 > *To:* "Ryoo, Jeong-dong" <ryoo@etri.re.kr> > *Cc:* "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" < > yaacov.weingarten@nsn.com>gt;, "mpls-tp@ietf.org" <mpls-tp@ietf.org> > *Subject:* Re: Re: [mpls-tp] Linera Protection - Operator commands > terminology. > > > Hello Jeong-dong, >> ? >> After looking little more into the state transition diagrams in G.8031, I >> could see the following difference between FS and MS-W. >> ? >> If Protection domain is in Forced Switch state, changes in the working >> path (i.e. SF /SF recovery events) will have no impact on the protection >> domain state, and recovery path is continued to be used as Active path, >> unless the recovery path itself goes down or lockout protection/clear >> commands are triggered. >> ? >> Whereas if protection domain is in Manual Switch state,?a series of SF and >> SF recovery events on the working path will lead to switching the traffic >> back from recovery path to Working path. >> ? >> Is this the expected difference between FS and MS operations? >> ? >> If this is not the case, can you pls clarify what is the difference >> between FS and MS-W as per APS definitions? Also it will be helpful if you >> can provide the?applicability for these operator commands. >> ? >> Regards, >> Mahesh >> >> On Tue, Jun 15, 2010 at 7:18 AM, Ryoo, Jeong-dong <ryoo@etri.re.kr>wrote;wrote: >> >>> Yaacov, >>> ? >>> In my opinion, if there is any technical problem in the >>> mechanism/protocol,?the problem should be solved. >>> ? >>> Besides, the mismatch problem that I stated in my previous?email is >>> what?G.8031 already?avoids by assigning >>> different priorities for SF-P and FS. >>> ? >>> In the MPLS-TP survivability framework document, the definition of FS >>> does not have any?consideration on the?defect condition. And the definition >>> of FS in the MPLS-TP survivability framework document is the SAME as that in >>> G.8031. >>> ? >>> I don't think the behaviour that I stated?violates the architecture. >>> ? >>> Jeong-dong >>> ? >>> >>> ? >>> ============================================== >>> Jeong-dong Ryoo, Ph.D. >>> Principal Member of Research Staff >>> Network Research Department >>> Electronics and Telecommunications Research Institute (ETRI) >>> Phone: +82-42-860-5384, Fax: +82-42-860-6342 >>> Email: ryoo@etri.re.kr >>> ============================================== >>> >>> -----Original Message----- >>> *From:* "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" < >>> yaacov.weingarten@nsn.com> >>> *From Date:* 2010-06-15 PM 10:52:21 >>> *To:* "Ryoo, Jeong-dong" <ryoo@etri.re.kr>kr>, "ext Mahesh Akula" < >>> mahesh.akula36@gmail.com>gt;, "Adrian Farrel" <adrian@olddog.co.uk> >>> *Cc:* "Mukund Mani" <mukund.mani@gmail.com>om>, "mpls-tp@ietf.org" < >>> mpls-tp@ietf.org> >>> *Subject:* RE: Re: [mpls-tp] Linera Protection - Operator commands >>> terminology. >>> >>> Hi, >>> >>> ? >>> >>> I think that this means that there is a conceptual problem with the >>> differentiation between the FS and MS commands!? The idea of the difference >>> that has always been explained is that FS would force a switchover even in >>> the case of a signal failure ? if as you say that this is not possible >>> because of the insufficiency of the architecture ? then there is a need to >>> redesign the architecture or redefine the set of operator commands. >>> >>> ? >>> >>> BR, >>> >>> yaacov >>> >>> ? >>> ------------------------------ >>> >>> *From:* ext Ryoo, Jeong-dong [mailto:ryoo@etri.re.kr] >>> *Sent:* Tuesday, June 15, 2010 16:38 >>> *To:* Weingarten, Yaacov (NSN - IL/Hod HaSharon); ext Mahesh Akula; >>> Adrian Farrel >>> *Cc:* Mukund Mani; mpls-tp@ietf.org >>> *Subject:* RE: Re: [mpls-tp] Linera Protection - Operator commands >>> terminology. >>> >>> ? >>> >>> Yaacov, >>> >>> ? >>> >>> When there is SF on Protection (SF-P),?the Forced Switch (FS)?command >>> cannot be delivered to?the other end as the APS/PSC protocol message is >>> conveyed via the protection path. >>> >>> As the result, one end is in FS state?and points its selector/bridge to >>> the protection path >>> >>> while?the other end is in SF-P state and points its selector/bridge to >>> the working path. >>> >>> In order to avoid the mismatch, SF-P needs to have a higher priority than >>> FS. >>> >>> ? >>> >>> What do you think? >>> >>> ? >>> >>> Jeong-dong? >>> >>> >>> ? >>> >>> ============================================== >>> Jeong-dong Ryoo, Ph.D. >>> Principal Member of Research Staff >>> Network Research Department >>> Electronics and Telecommunications Research Institute (ETRI) >>> Phone: +82-42-860-5384, Fax: +82-42-860-6342 >>> Email: ryoo@etri.re.kr >>> ============================================== >>> >>
- [mpls-tp] Linera Protection - Operator commands t… Mahesh Akula
- Re: [mpls-tp] Linera Protection - Operator comman… Mahesh Akula
- Re: [mpls-tp] Linera Protection - Operator comman… 류정동
- Re: [mpls-tp] Linera Protection - Operator comman… Mahesh Akula
- Re: [mpls-tp] Linera Protection - Operator comman… Ryoo, Jeong-dong
- Re: [mpls-tp] Linera Protection - Operator comman… Weingarten, Yaacov (NSN - IL/Hod HaSharon)
- Re: [mpls-tp] Linera Protection - Operator comman… Ryoo, Jeong-dong
- Re: [mpls-tp] Linera Protection - Operator comman… Mahesh Akula
- Re: [mpls-tp] Linera Protection - Operator comman… Ryoo, Jeong-dong
- Re: [mpls-tp] Linera Protection - Operator comman… Ryoo, Jeong-dong
- Re: [mpls-tp] Linera Protection - Operator comman… Mahesh Akula