Re: [mpls-tp] R: Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09
John E Drake <jdrake@juniper.net> Fri, 26 November 2010 16:54 UTC
Return-Path: <jdrake@juniper.net>
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 C6C4028C0F2 for <mpls-tp@core3.amsl.com>; Fri, 26 Nov 2010 08:54:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.373
X-Spam-Level:
X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 YF40OXtykBD0 for <mpls-tp@core3.amsl.com>; Fri, 26 Nov 2010 08:54:25 -0800 (PST)
Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 6006928C0DE for <mpls-tp@ietf.org>; Fri, 26 Nov 2010 08:54:25 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTO/meu/PQDe+YYy+Wf11Hi6lzUSYK9zU@postini.com; Fri, 26 Nov 2010 08:55:29 PST
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 26 Nov 2010 08:53:10 -0800
From: John E Drake <jdrake@juniper.net>
To: Maarten Vissers <maarten.vissers@huawei.com>, "'BUSI, ITALO (ITALO)'" <italo.busi@alcatel-lucent.com>, 'Dan Frost' <danfrost@cisco.com>
Date: Fri, 26 Nov 2010 08:54:25 -0800
Thread-Topic: [mpls-tp] R: Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09
Thread-Index: AcuMEvlMU6LdI+xVTW6oPtZJnETCaABW3FrwAALPwZAABB9MQA==
Message-ID: <5E893DB832F57341992548CDBB33316398C505A939@EMBX01-HQ.jnpr.net>
References: <20101124200520.GE17168@cisco.com> <15740615FC9674499FBCE797B011623F16C23AD7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <007301cb8d7a$aeb5d5f0$0c2181d0$%vissers@huawei.com>
In-Reply-To: <007301cb8d7a$aeb5d5f0$0c2181d0$%vissers@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mpls-tp@ietf.org" <mpls-tp@ietf.org>
Subject: Re: [mpls-tp] R: Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09
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: Fri, 26 Nov 2010 16:54:26 -0000
Maarten, I probably shouldn't tell you how to do this, but a sensible implementation would probably allow the configuration of the TTL for both the working and protecting LSPs, and when a protection switch occurs, such an implementation would switch to the TTL of the protecting LSP. Thanks, John Sent from my iPhone > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > Behalf Of Maarten Vissers > Sent: Friday, November 26, 2010 7:01 AM > To: 'BUSI, ITALO (ITALO)'; 'Dan Frost' > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] R: Intermediate nodes and segment monitoring in > draft-ietf-mpls-tp-oam-framework-09 > > Italo, > > > 2) The TTL-expiry mechanism is not a very reliable one: TTL distance > > between two nodes can change during the lifetime of a transport path. > > I assume that you refer to the a change of the transport path due to > e.g. > protection switching or restoration event. Correct? > > Use of pro-active OAM based on TTL-expiry would cause problems after > the > failed transport path was restored via a path with e.g. 4 hops (whereas > the > original path has e.g. 2 hops). The TTL in the OAM packets would expire > too > early, and these OAM packets would not reach the far end MEP. > > Regards, > Maarten > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of BUSI, ITALO (ITALO) > > Sent: 26 November 2010 14:50 > > To: Dan Frost > > Cc: mpls-tp@ietf.org > > Subject: [mpls-tp] R: Intermediate nodes and segment monitoring in > > draft-ietf-mpls-tp-oam-framework-09 > > > > Dan, > > > > I think that the proposed changes are quite substantial and require a > > lot of further investigation so I do not feel comfortable to just > apply > > them without further investigating all the associated issues. > > > > In particular we need to consider that: > > > > 1) Regardless of the mechanisms, MEPs and MIPs are functionally > > different: MEPs are active component while MIPs are passive > components. > > > > The fact that the OAM packet delivery is achieved via TTL-expiry does > > not change the nature of MEP-MEP and MEP-MIP communications from a > > functional perspective. > > > > 2) The TTL-expiry mechanism is not a very reliable one: TTL distance > > between two nodes can change during the lifetime of a transport path. > > > > This issue has major impacts especially with pro-active OAM tools. > > > > As a consequence my proposal is: > > > > > > - #1 is IMHO a valid and relatively cheap (for IETF) resolution: > > the > > > > caveats associated with the SPME construct would be explicitly > > > > presented for consideration of potential "users". If they still > > agree > > > > to use this construct, this would be a case of "informed > consent". > > > > > > > > These caveats have been already added in version -09 of the draft. > > Please check section 3.8 and let me know if you have any concern with > > the current text. > > > > > > - #2 is much more complicated for the IETF, since it would mean > at > > > > least retraction of the SPME construct as defined in RFC 5921 and > > > > appropriate correction of the MPLS-TP OAM FW draft. If an > > alternative > > > > solution is required, this would add to complexity of the task, > > but, > > > > hopefully, the operators would be presented with a valid > solution. > > > > This work has already started, please see the following individual > > drafts: > > - http://tools.ietf.org/html/draft-koike-mpls-tp-temporal-hitless- > psm- > > 01 > > - http://tools.ietf.org/html/draft-zhang-mpls-tp-path-segment- > > monitoring-01 > > > > During IETF 79, I had some offline conversations with the authors of > > these drafts and I think the requirements need to be further > detailed. > > > > Based on this discussion, it is my understanding that the SPME would > > work well-enough for inter-domain segment monitoring. The only issue > > that needs to be addressed is related only to the temporal segment > > monitoring. > > > > I would therefore propose to move forward the OAM framework draft in > > its current form (with the caveats in section 3.8) and, in parallel, > to > > progress the work on temporal PSM within the MPLS WG. > > > > Italo > > > > > -----Messaggio originale----- > > > Da: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] Per > > conto > > > di Dan Frost > > > Inviato: mercoledì 24 novembre 2010 21.05 > > > A: mpls-tp@ietf.org > > > Oggetto: [mpls-tp] Intermediate nodes and segment monitoring in > > draft- > > > ietf-mpls-tp-oam-framework-09 > > > > > > Resending to note that this is intended as a (late) LC comment on > the > > > OAM framework. It would be useful to hear brief yea/nays from the > WG > > as > > > to whether lifting the restriction on intermediate nodes is > > desirable. > > > > > > -d > > > > > > ----- Forwarded message ----- > > > > > > Date: Wed, 24 Nov 2010 16:58:32 +0000 > > > From: Dan Frost <danfrost@cisco.com> > > > To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> > > > Cc: mpls-tp@ietf.org > > > Subject: Re: [mpls-tp] about open discussion about MIPMEP in MPLS- > TP > > > networks > > > > > > On Tue, Nov 23, 2010 at 10:04:45PM +0200, Alexander Vainshtein > wrote: > > > > [...] > > > > As for its resolution: > > > > - #1 is IMHO a valid and relatively cheap (for IETF) resolution: > > the > > > > caveats associated with the SPME construct would be explicitly > > > > presented for consideration of potential "users". If they still > > agree > > > > to use this construct, this would be a case of "informed > consent". > > > > > > > > - #2 is much more complicated for the IETF, since it would mean > at > > > > least retraction of the SPME construct as defined in RFC 5921 and > > > > appropriate correction of the MPLS-TP OAM FW draft. If an > > alternative > > > > solution is required, this would add to complexity of the task, > > but, > > > > hopefully, the operators would be presented with a valid > solution. > > > > > > > > Hopefully this clarifies my position. > > > > > > Since it seems we're sentenced to run through the same circles > every > > > three months or so with different subject headings, it will save > time > > to > > > refer to Dave Allan's message > > > > > > http://www.ietf.org/mail-archive/web/mpls-tp/current/msg04422.html > > > > > > and the related messages in the thread. > > > > > > The key technical issue for segment monitoring is whether > > intermediate > > > nodes are "allowed" by the architecture to initiate OAM operations. > > > This however is purely a modeling issue, as the MPLS data plane > > already > > > supports this behaviour. The sane thing to do in this situation is > > to > > > remove the artificial restriction from the model. The earlier > > > discussions show broad consensus on this among protocol designers, > > and > > > service providers have been saying that it really is important > > because > > > of the alternative options for segment monitoring it enables. > > > > > > Given this, it's not clear to me why the restriction is still > present > > in > > > the OAM framework. If the consensus reading is correct, the > > restriction > > > should either be removed from the document, or an update drafted > > > accordingly. > > > > > > Regarding SPME monitoring, it seems entirely reasonable to make its > > > properties as clear as possible, and if the above restriction is > > lifted, > > > to contrast the two approaches in the documentation for the benefit > > of > > > operators and protocol designers. The OAM framework, or its > update, > > is > > > the right place to do this. > > > > > > -d > > > > > > > Regards, Sasha > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > ----- End forwarded message ----- > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp
- [mpls-tp] Intermediate nodes and segment monitori… Dan Frost
- Re: [mpls-tp] Intermediate nodes and segment moni… Alexander Vainshtein
- Re: [mpls-tp] Intermediate nodes and segment moni… John E Drake
- [mpls-tp] R: Intermediate nodes and segment monit… BUSI, ITALO (ITALO)
- Re: [mpls-tp] R: Intermediate nodes and segment m… Maarten Vissers
- Re: [mpls-tp] R: Intermediate nodes and segment m… Alexander Vainshtein
- Re: [mpls-tp] R: Intermediate nodes and segment m… John E Drake
- Re: [mpls-tp] R: Intermediate nodes and segment m… zhang.fei3
- Re: [mpls-tp] R: Intermediate nodes and segment m… Maarten Vissers
- Re: [mpls-tp] R: Intermediate nodes and segment m… John E Drake
- Re: [mpls-tp] R: Intermediate nodes and segment m… zhang.fei3
- Re: [mpls-tp] R: Intermediate nodes and segment m… John E Drake
- Re: [mpls-tp] R: Intermediate nodes and segment m… Greg Mirsky
- Re: [mpls-tp] R: Intermediate nodes and segment m… John E Drake
- Re: [mpls-tp] R: Intermediate nodes and segment m… Greg Mirsky
- Re: [mpls-tp] R: Intermediate nodes and segment m… Maarten Vissers
- Re: [mpls-tp] R: Intermediate nodes and segment m… Greg Mirsky
- Re: [mpls-tp] R: Intermediate nodes and segment m… Maarten Vissers
- Re: [mpls-tp] R: Intermediate nodes and segment m… John E Drake
- Re: [mpls-tp] R: Intermediate nodes and segment m… John E Drake
- Re: [mpls-tp] R: Intermediate nodes and segment m… Alexander Vainshtein
- Re: [mpls-tp] R: Intermediate nodes and segment m… John E Drake
- Re: [mpls-tp] R: Intermediate nodes and segment m… Maarten Vissers
- Re: [mpls-tp] R: Intermediate nodes and segment m… John E Drake