Re: [mpls-tp] R: Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09
zhang.fei3@zte.com.cn Sun, 28 November 2010 03:03 UTC
Return-Path: <zhang.fei3@zte.com.cn>
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 E069B3A69A0; Sat, 27 Nov 2010 19:03:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.768
X-Spam-Level:
X-Spam-Status: No, score=-96.768 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
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 TstdJAy-msW7; Sat, 27 Nov 2010 19:03:18 -0800 (PST)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id E754C3A6BB3; Sat, 27 Nov 2010 19:03:16 -0800 (PST)
Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101105171106; Sun, 28 Nov 2010 11:02:44 +0800 (CST)
Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 52528.6663117710; Sun, 28 Nov 2010 10:59:30 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id oAS34JKg095985; Sun, 28 Nov 2010 11:04:19 +0800 (CST) (envelope-from zhang.fei3@zte.com.cn)
In-Reply-To: <5E893DB832F57341992548CDBB33316398C505A939@EMBX01-HQ.jnpr.net>
To: John E Drake <jdrake@juniper.net>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OF9A23A7F7.D9FDB37D-ON482577E9.000F8D8B-482577E9.00111897@zte.com.cn>
From: zhang.fei3@zte.com.cn
Date: Sun, 28 Nov 2010 11:04:14 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-11-28 11:04:10, Serialize complete at 2010-11-28 11:04:10
Content-Type: multipart/alternative; boundary="=_alternative 00111893482577E9_="
X-MAIL: mse2.zte.com.cn oAS34JKg095985
Cc: mpls-tp-bounces@ietf.org, "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: Sun, 28 Nov 2010 03:03:20 -0000
John: I agree with you, but TTL scheme will face scaling issues if it is used for nested path segment monitoring, as I addressed in d raft-zhang-mpls-tp-path-segment-monitoring-01. Fortunately, it would not happen if it is only used for on-demand monitoring. So MBB is used for proactive and TTL used for the on-demand monitoring? This would utilize the advantages of these two schemes. Italo, Dan: If TTL is used, two options are applicalbe: (1)lifting the restriction on intermediate nodes, as Dan said. (2)Increasing the MEP definition for path segment, a little revision to the document [tp-identifier]. Just my two cents. Fei :) John E Drake <jdrake@juniper.net> 发件人: mpls-tp-bounces@ietf.org 2010-11-27 00:54 收件人 Maarten Vissers <maarten.vissers@huawei.com>, "'BUSI, ITALO (ITALO)'" <italo.busi@alcatel-lucent.com>, 'Dan Frost' <danfrost@cisco.com> 抄送 "mpls-tp@ietf.org" <mpls-tp@ietf.org> 主题 Re: [mpls-tp] R: Intermediate nodes and segment monitoring in draft-ietf-mpls-tp-oam-framework-09 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 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