From zheng.zhi@zte.com.cn Tue Mar 1 03:29:03 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C7A3A67B0 for ; Tue, 1 Mar 2011 03:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 E9SAz2jN8UMH for ; Tue, 1 Mar 2011 03:29:02 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 6EC843A67AC for ; Tue, 1 Mar 2011 03:29:01 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 3510806486374; Tue, 1 Mar 2011 19:27:50 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 91645.806486374; Tue, 1 Mar 2011 19:20:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p21BTrpe069437 for ; Tue, 1 Mar 2011 19:29:53 +0800 (GMT-8) (envelope-from zheng.zhi@zte.com.cn) To: mpls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zheng.zhi@zte.com.cn Date: Tue, 1 Mar 2011 19:26:46 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-01 19:29:53, Serialize complete at 2011-03-01 19:29:53 Content-Type: multipart/alternative; boundary="=_alternative 003F83EB48257846_=" X-MAIL: mse01.zte.com.cn p21BTrpe069437 Subject: [mpls] Problem of hostname display of each RSVP Hop X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 11:29:03 -0000 This is a multipart message in MIME format. --=_alternative 003F83EB48257846_= Content-Type: text/plain; charset="US-ASCII" Hi, all: Hostname display for OSPF and RSVP-TE can improve the operating experience. But when initiating an inter-area LSP tunnel with RSVP-TE, and tried to get the hostname of each RSVP Hop display on the CLI at the ingress node, it is impossible to obtain the hostname information of those nodes in areas other than the initiator's. The hostname flooding scope is controlled by the OSPF Opaque LSA, as described in [RFC5642]. That means the hostname information of a router other than an ASBR, cannot traverse OSPF routing areas. The draft makes some extensions, please review and comment... http://tools.ietf.org/html/draft-zheng-ccamp-rsvp-te-dynamic-hostname-00 Best Regards, Zhi > > Filename: draft-zheng-ccamp-rsvp-te-dynamic-hostname > Revision: 00 > Title: RSVP-TE extensions for dynamic hostname traversing OSPF > routing areas > Creation_date: 2011-02-19 > WG ID: Independent Submission > Number_of_pages: 6 > > Abstract: > RFC 5642 defines an OSPF Router Information TLV that allows OSPF > Routers to flood their hostname-to-Router-ID mapping information. > Sometimes, when the operators create an inter-area MPLS LSP tunnel > with Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE), > they need the hostname display on the CLI at the ingress node for > management and operational reasons. This document describes > extensions to RSVP-TE to support hostname-to-Router-ID mapping > information traversing areas in an inter-area MPLS LSP tunnel > situation. > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 003F83EB48257846_= Content-Type: text/html; charset="US-ASCII"
Hi, all:

Hostname display for OSPF and RSVP-TE can improve the operating experience. But when initiating an inter-area LSP tunnel with RSVP-TE, and tried to get the hostname of each RSVP Hop display on the CLI at the ingress node, it is impossible to obtain the hostname information of those nodes in areas other than the initiator's.
The hostname flooding scope is controlled by the OSPF Opaque LSA, as described in [RFC5642]. That means the hostname information of a router other than an ASBR, cannot traverse OSPF routing areas.
The draft makes some extensions, please review and comment...
http://tools.ietf.org/html/draft-zheng-ccamp-rsvp-te-dynamic-hostname-00

Best Regards,
Zhi
 
>
> Filename:    draft-zheng-ccamp-rsvp-te-dynamic-hostname
> Revision:    00
> Title:       RSVP-TE extensions for dynamic hostname traversing OSPF
> routing areas
> Creation_date:    2011-02-19
> WG ID:       Independent Submission
> Number_of_pages: 6
>
> Abstract:
> RFC 5642 defines an OSPF Router Information TLV that allows OSPF
> Routers to flood their hostname-to-Router-ID mapping information.
> Sometimes, when the operators create an inter-area MPLS LSP tunnel
> with Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE),
> they need the hostname display on the CLI at the ingress node for
> management and operational reasons.  This document describes
> extensions to RSVP-TE to support hostname-to-Router-ID mapping
> information traversing areas in an inter-area MPLS LSP tunnel
> situation.
> 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 003F83EB48257846_=-- From Alexander.Vainshtein@ecitele.com Tue Mar 1 03:35:42 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE24A3A67AD; Tue, 1 Mar 2011 03:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] 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 zYr3HwsHtr6v; Tue, 1 Mar 2011 03:35:41 -0800 (PST) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id 066873A67AC; Tue, 1 Mar 2011 03:35:40 -0800 (PST) X-AuditID: 93eaf2e8-b7bf5ae000000ab6-76-4d6cda09b9ce Received: from ilptexch01.ecitele.com (ilptexfe.ecitele.com [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id F5.88.02742.90ADC6D4; Tue, 1 Mar 2011 13:35:37 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 1 Mar 2011 13:36:42 +0200 From: Alexander Vainshtein To: Loa Andersson Date: Tue, 1 Mar 2011 13:36:39 +0200 Thread-Topic: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Thread-Index: AcvDlqZcu41bIvzRSJKUHtJMRtmDlAUaseVg Message-ID: References: <4D4A934F.5020206@pi.nu> In-Reply-To: <4D4A934F.5020206@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsWyRv6Lhi7nrRxfg+2LlSz+zZ3DbHG46y6j xdNnLha3lq5ktbg9pYnRgdWj9dleVo8pvzeyeixZ8pPJY9b0NrYAligum5TUnMyy1CJ9uwSu jB3tP1kKuuQrXh9Lb2CcKNbFyMkhIWAi0Xd4PROELSZx4d56ti5GLg4hgbOMEhf2LWeEcCYz Slz/84cFpIpNwFZi0+q7bCC2iICsxLVtP5lAipgFtjFKHJt4BqyIRUBFYvafDlYQW1jASWLm 7clARRxADc4SCyYnQ/QaScycfASsnFfAX2Lxpftg5UJArRsWHmUHsTkFVCVarkGMYQS67vup NWCXMguIS9x6Mh/qagGJJXvOM0PYohIvH/+DqheVuNO+nhGiXkdiwe5PbBC2tsSyha+ZIfYK Spyc+YRlAqPYLCRjZyFpmYWkZRaSlgWMLKsYRTNzCkqSctMNjPRSkzNLUnNS9ZLzczcxAuNt 8qtPL3YwTtisc4iRiYNTqoFRI/0NK9N5T8NDh6//Y3JzWyNxREW5M1Sg6xp3uWvlTPPCspOi gQt6J3Smlr/qDDtV4HxojXG72F891X3nJt7u+6bHu++7YQTH7qnm0+XecNsbi7QVvDqrd+Br G8NjFbvvxj08883Z34voVErmnc1himk5fEM15Xg639e26Idup1PW9pt8eKbEUpyRaKjFXFSc CAAWDscGZwIAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 11:35:43 -0000 Loa, and all, I have two LC comments on the draft. in question. They both refer to issues= I've raised in private discussions with George and Matthew and which, to t= he best of my understanding, have not been resolved in the -03 version. My first issue deals with potential dangers of sending fault OAM messages i= n conjunction with certain protection mechanisms. The example I've presented to George and Matthew deals with the situation = when the LSP in question employs Facility FRR for node protection.=20 The topology is shown below: |------| |-----| |-----| |-----| |-----|=20 | A |<--->| B |<--->| C |<--->| D |<--->| E | |------| |-----| |-----| |-----| |-----| \ / \ / \ / \ / \ / \ /=20 \ |------| / \| C' |/ |------| The LSP runs A-->B-->C-->D-->E with LSP-level MEPs at A and D and MIPs in = the rest of the nodes. If the link BC is broken, the link-level MEP at C detects that and initiate= s (I'll skip the details) insertion of AIS (with LDI flag set after some st= abilization) into the LSP. These AIS/LDI packets will be captured by the LS= P MEP in D. Meanwhile, B could operate a node protection bypass (B-->C'-->D) for this L= SP, starting at B and terminated at D, D would be the merge point. Note tha= t C would not be aware of this action, and D would not aware of AIS inserti= on undertaken by C. As a consequence, E would receive both AIS/LDI generated by C and valid tra= ffic coming thru bypass. This is definitely not healthy, and the draft does not define any ways to a= void that. The text in the draft that deals with protection seems to refer to link pro= tection rather than to LSP protection. IMHO the same problem would appear in the case of segment protection if a l= ink in the middle of a segment is broken, so this issue is not limited just= to FRR. My second issue deals with association between links and LSPs that pass thr= u these links. Ability to insert Fault OAM messages into all the LSPs cross= ing a certain link may be compromised IMHO in the case LSPs that use labels= from the per-platform space. It is not clear from the draft how the LSR th= at has detected a link failure could decide whether Fault OAM messages shou= ld be inserted in a transit LSP (which it perceives as an ILM table entry) = or not - because the actual LSP could be running thru a different link. The= problem would presumably disappear if per-interface label space were used;= but RFC 5960 does not restrict MPLS-TP from using per-platform label space= . I apologize for sending these comments so late in the LC. Regards, Sasha -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Loa Andersson Sent: Thursday, February 03, 2011 1:37 PM To: mpls-tp@ietf.org; mpls@ietf.org Cc: ahmpls-tp@lists.itu.int Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03 Working Group, this is to start a four week working group last call on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03). Please send comments to the mpls-tp@ietf.org mailing list. This working group last call ends on February 28, 2011. Loa, George and Ross MPLS wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From ietfc@btconnect.com Tue Mar 1 07:43:14 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1F143A6947; Tue, 1 Mar 2011 07:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.673, BAYES_00=-2.599] 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 srCZsrLUWsfe; Tue, 1 Mar 2011 07:43:14 -0800 (PST) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by core3.amsl.com (Postfix) with ESMTP id 900E23A690E; Tue, 1 Mar 2011 07:43:13 -0800 (PST) Received: from host86-141-16-12.range86-141.btcentralplus.com (HELO pc6) ([86.141.16.12]) by c2beaomr06.btconnect.com with SMTP id CCT40942; Tue, 01 Mar 2011 15:44:13 +0000 (GMT) Message-ID: <009201cbd81e$823ac820$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Loa Andersson" , , References: <4D498294.7050703@pi.nu> Date: Tue, 1 Mar 2011 15:39:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4D6D144B.0214, actions=TAG X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0208.4D6D144D.0266,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: ahmpls-tp@lists.itu.int Subject: Re: [mpls] [mpls-tp] Early review of two mpls working group documents X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 15:43:15 -0000 ----- Original Message ----- From: "Loa Andersson" To: ; Cc: Sent: Wednesday, February 02, 2011 5:13 PM > Working group, > > "A Thesaurus for the Terminology used in Multiprotocol Label > Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's > Transport Network Recommendations." > > draft-ietf-mpls-tp-rosetta-stone-03.txt I do NOT think that this I-D should progress. It could have been very useful, as when a new term has been introduced, such as PST or SPME. There are, of course, definitions of such terms but buried in non-obvious places, with the obsoleted terms still present in a Standards Track RFC, with no obvious place to look for what is now called what. Except, of course, there is an obvious place to look. Lo and behold, A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations. What could be more obvious a place to look; trouble is, the necessary definitions are not there. There is still hope. Going forward, this I-D could still act as a repository for terminology, old, new and the relationships between them, but for this to work, it MUST NOT become an RFC for then it is set in concrete, the way obsolete terms have been already set in concrete is some MPLS RFC. Rather, this should stay an I-D and be updated whenever there is a significant change in terminology and only when we are at the end of the process of producing the first cut at MPLS-TP, only then should it be turned into an RFC. So, yes it should become an RFC but no way should it do so yet. Tom Petch From venkatflex@gmail.com Tue Mar 1 08:44:47 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8204C3A692E; Tue, 1 Mar 2011 08:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135] 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 10Vat5VvZnsK; Tue, 1 Mar 2011 08:44:45 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 8B32F3A677C; Tue, 1 Mar 2011 08:44:45 -0800 (PST) Received: by qwh6 with SMTP id 6so4274479qwh.31 for ; Tue, 01 Mar 2011 08:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1Q5rWOs0ivhNWe2bkF2bkujZm02BvxArbRleEk2cfvU=; b=wEziNkffvE/1vxxX3Lm1PwwS4FcmSP9swUN+x6ywm56LbPI6eqLsQu3IgZ3D2A6fhM NIOFiQi8ZXm70VUHrTkIlLQ/yy6o15vsisxkOnk0js/+nJIkMdulYRwacSAmDzTU1SaV OvRCAO1spx5aGO3B3jeFWxjHltAGRNTusHo3k= 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=l0qVJX5lCCJ2LMC6/dnBTm+By5Lx34/mO8AUP5qnezoE+c+pfMK8COtotbp2M5fMqo Fk6cpwcEK3s+TrzePYXsmv9L8CFTRBr7c6XnyVE4hh9ugv7hDzCkpngUUZU6OCA5dhOG DuugncOqXZpP0i8xNa94hxfeKIKzG7SkVc36M= MIME-Version: 1.0 Received: by 10.224.36.203 with SMTP id u11mr6020851qad.105.1298997947315; Tue, 01 Mar 2011 08:45:47 -0800 (PST) Received: by 10.224.20.71 with HTTP; Tue, 1 Mar 2011 08:45:47 -0800 (PST) In-Reply-To: <44F4E579A764584EA9BDFD07D0CA0813068984F8@tlvmail1> References: <44F4E579A764584EA9BDFD07D0CA081306898455@tlvmail1> <44F4E579A764584EA9BDFD07D0CA0813068984F8@tlvmail1> Date: Tue, 1 Mar 2011 11:45:47 -0500 Message-ID: From: venkatesan mahalingam To: Daniel Cohn Content-Type: multipart/alternative; boundary=0015175cdbdc36b83c049d6e8758 Cc: mpls , mpls-tp@ietf.org Subject: Re: [mpls] New draft-vkst-mpls-tp-te-mib-00 draft for review X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 16:44:47 -0000 --0015175cdbdc36b83c049d6e8758 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Daniel, Please refer the latest version draft for MPLS-TP identifiers draft-ietf-mpls-tp-identifiers-03. * * * * * * * * * * * * * * * * We don't disagree with the MPLS-TP identifiers draft, the draft is generically written considering the co-routed and associated bi-directional tunnels. Thanks, Venkat. On Tue, Mar 1, 2011 at 10:36 AM, Daniel Cohn wrote: > Hi Venkatesan, > > > > I forgot to consider associated bidirectional =E2=80=93 it makes perfect = sense now. > Actually you did mention them in your example section (). > > So can we agree then to disagree with the following statement in > draft-swallow-mpls-tp-identifiers? > > > > *5.1. MPLS-TP Point to Point Tunnel Identifiers* > > ** > > *The motivation for each endpoint having its own tunnel number is to > allow a compact form for the MEP-ID* > > > > Or am I again missing something? > > > > =E0=A4=A7=E0=A4=A8=E0=A5=8D=E0=A4=AF=E0=A4=B5=E0=A4=BE=E0=A4=A6, > > Daniel > > > > *From:* venkatesan mahalingam [mailto:venkatflex@gmail.com] > *Sent:* Tuesday, March 01, 2011 5:00 PM > *To:* Daniel Cohn > *Subject:* Re: [mpls] New draft-vkst-mpls-tp-te-mib-00 draft for review > > > > Dear Daniel, > > There is no discrepancy. > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num > > For co-routed bi-directional tunnel, we will have one tunnel entry with t= wo XC entries for both forward and reverse LSPs. In this case, source tunne= l number is same as destination tunnel number. > > Incase of associated bi-direction tunnel, we will have two tunnel entries= each one has separate XC entry for LSP informations (Forward or reverse di= rection). In this case, we need to use the mplsTunnelExtTable to give the d= estination tunnel index. So, we will have two tunnels one for forward direc= tion with reverse direction tunnel index associated similarly reverse direc= tion tunnel with forward direction tunnel index associated. > > Hope this helps. > > > > Thanks, > > Venkat. > > On Tue, Mar 1, 2011 at 5:54 AM, Daniel Cohn wrote: > > Hi Ventaksean, > > > > > > Your draft of reference mentions that a TP tunnel is indexed by tunnel in= dex, tunnel instance, source ID and destination ID (where ID can be either = global::local for IP or ICC-ID for ICC). I fully agree with this statement.= However draft-swallow-mpls-tp-identifiers specifies Src-Node_ID::Src-Tunne= l_Num::Dst-Node_ID::Dst-Tunnel_Num, which explicitly assumes the validity o= f different tunnel number at source and destination. > > > > Are you aware of this discrepancy? What is your view on this? > > > > Thanks, > > > > > > Daniel Cohn > > System Engineer > > Orckit-Corrigent > > Mobile: +972 54 922 5104 > Email: danielc@orckit.com > > [image: logo-final-small] > > *Pushing technology to the edge* > > > > > > > > > > *From:* venkatesan mahalingam [mailto:venkatflex@gmail.com] > *Sent:* Monday, February 28, 2011 5:21 AM > > > *To:* mpls; mpls-tp@ietf.org > > *Subject:* [mpls] New draft-vkst-mpls-tp-te-mib-00 draft for review > > > > Hi Team, > > We have uploaded the MPLS-TP TE MIB draft last week into IETF repository. > > > > This document provides an enhancement to the RFC-3812 for managing the > Traffic Engineering tunnels > > for MPLS based transport networks in IP and Non-IP operator environments. > > > > Please review the draft and provide your valuable comments/suggestions. > > > > A URL of the draft is: > > http://tools.ietf.org/id/draft-vkst-mpls-tp-te-mib-00.txt > > > -- > Best Regards, > Venkatesan Mahalingam. > > > > > -- > Best Regards, > Venkatesan Mahalingam. > --=20 Best Regards, Venkatesan Mahalingam. --0015175cdbdc36b83c049d6e8758 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Daniel,
Please refer the latest version draft for MPLS-TP identifi= ers=C2=A0draft-ietf-mpls-tp-identifiers-03.=


<= div>

<= div>

<= div>

We don't disagree with the MPLS-TP identifiers draft,= the draft is generically written considering the co-routed and associated = bi-directional tunnels.

Thanks,
Venkat.

On Tue, Mar 1, 2011 at 10:36 AM, Daniel Cohn= <DanielC@orckit.com> wrote:

Hi Venkatesan,

=C2= =A0

I forgot to consider associa= ted bidirectional =E2=80=93 it makes perfect sense now. Actually you did me= ntion them in your example section (<blush>).

So can we agree then to disa= gree with the following statement in draft-swallow-mpls-tp-identifiers?

=C2=A0

5.= 1.=C2=A0 MPLS-TP Point to Point Tunnel Identifiers

<snip&g= t;

Th= e motivation for each endpoint having its own tunnel=C2=A0 number is to all= ow a compact form for the MEP-ID

=C2= =A0

Or am I again missing something?

= =C2=A0

=E0=A4=A7=E0=A4=A8=E0=A5=8D=E0=A4=AF=E0=A4=B5=E0=A4=BE=E0=A4=A6,

Danie= l

=C2= =A0

From: venkatesan mahalin= gam [mailto:venka= tflex@gmail.com]
Sent: Tuesday, March 01, 2011 5:00 PM
To: Daniel Cohn
<= b>Subject: Re: [mpls] New draft-vkst-mpls-tp-te-mib-00 draft for review=

=C2=A0

Dear Daniel,

There is no discrepancy.
Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num
For co-routed bi-directional tunnel, we will have one tunnel entry with=
 two XC entries for both forward and reverse LSPs. In this case,=C2=A0source tunnel number is same as destination tunnel number.


Incase of associated bi-direction tunnel, we will have two tunnel entri=
es each one has separate XC entry for LSP informations (Forward or reverse =
direction). In this case, we need to use the mplsTunnelExtTable to gi=
ve the destination tunnel index. So, we will have two tunnels one for forwa=
rd direction with reverse direction tunnel index associated similarly rever=
se direction tunnel with forward direction tunnel index associated.<=
/span>



Hope this helps.
=C2=A0
Thanks,
<=
pre>
V=
enkat.

On Tue, Mar 1, 2011 at 5:54 AM, Daniel Cohn <= ;DanielC@orckit.com= > wrote:

Hi Ventaksean,

=C2=A0

=C2=A0
Your draft of reference mentions that a TP t=
unnel is indexed by tunnel index, tunnel instance, source ID and destinatio=
n ID (where ID can be either global::local for IP or ICC-ID for ICC). I ful=
ly agree with this statement. However draft-swallow-mpls-tp-identifiers spe=
cifies Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num, which expl=
icitly assumes the validity of different tunnel number at source and destin=
ation.
=C2=A0
Are you aware of this discrepancy? What is your =
view on this?
=C2=A0
Thanks,
=C2=
=A0

=C2= =A0

Daniel Cohn

System Engineer

Orcki= t-Corrigent

Mobile: +972 54 922 5104
Email: danielc@orckit.com

3D"logo-final-=

Pushi= ng technology to the edge

=C2= =A0

=C2=A0

=C2=A0

=C2=A0

From: venkatesan mahalingam [mailto:venkatflex@gmail.co= m]
Sent: Monday, February 28, 2011 5:21 AM

Subject= : [mpls] New draft-vkst-mpls-tp-te-mib-00 draft for review

=C2=A0

Hi = Team,

We have uploaded the MPLS-TP TE MIB dr= aft last week into IETF repository.

= =C2=A0

This document provides an enhancement to the RF= C-3812 for managing the Traffic Engineering tunnels=C2=A0

for MPLS based transport networks in IP and Non-IP oper= ator environments.

=C2=A0

Please review the draft and provide your valuable comments/suggestions.<= /p>

=C2=A0

A URL of the draft is:




--
Best Regards,
Venkatesa= n Mahalingam.




--
Best Regards,
Venkatesan Mahalingam.
--0015175cdbdc36b83c049d6e8758-- From DanielC@orckit.com Tue Mar 1 08:53:33 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F523A687C; Tue, 1 Mar 2011 08:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_OTHER=0.135] 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 Vkm1ZjARKxXZ; Tue, 1 Mar 2011 08:53:31 -0800 (PST) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by core3.amsl.com (Postfix) with ESMTP id A1B493A681D; Tue, 1 Mar 2011 08:53:30 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD831.426B08BA" Date: Tue, 1 Mar 2011 18:54:58 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130689851D@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] New draft-vkst-mpls-tp-te-mib-00 draft for review Thread-Index: AcvYMA0bsHxp3MnrQlClu6IedmnfnwAANSzw References: <44F4E579A764584EA9BDFD07D0CA081306898455@tlvmail1><44F4E579A764584EA9BDFD07D0CA0813068984F8@tlvmail1> From: "Daniel Cohn" To: "venkatesan mahalingam" , , , Cc: mpls , mpls-tp@ietf.org Subject: Re: [mpls] New draft-vkst-mpls-tp-te-mib-00 draft for review X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 16:53:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD831.426B08BA Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFZlbnRhaywgSSB0aGluayBteSBjb25mdXNpb24gd2FzIGhlbHBlZCBieSB0aGUgaW5j b3JyZWN0IHJlZmVyZW5jZSBpbiBkcmFmdC1pZXRmLW1wbHMtdHAtaWRlbnRpZmllcnMtMDMuIA0K DQpTZWN0aW9uIDUuMSDigJxTZWUgc2VjdGlvbiBTZWN0aW9uIDcuMS4yLjHigJ0gc2hvdWxkIGJl IOKAnFNlZSBzZWN0aW9uIFNlY3Rpb24gNy4yLjIuMeKAnQ0KDQogDQoNCmRyYWZ0LWlldGYtbXBs cy10cC1pZGVudGlmaWVycy0wMyBhdXRob3JzLCBwbGVhc2UgY29uc2lkZXIgdGhlIGFib3ZlIGNv bW1lbnQuDQoNCiANCg0KUmVnYXJkcyBhbmQgdGhhbmtzIGFnYWluIGZvciB0aGUgY2xhcmlmaWNh dGlvbi4sDQoNCiANCg0KRGFuaWVsDQoNCiANCg0KIA0KDQpGcm9tOiB2ZW5rYXRlc2FuIG1haGFs aW5nYW0gW21haWx0bzp2ZW5rYXRmbGV4QGdtYWlsLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBNYXJj aCAwMSwgMjAxMSA2OjQ2IFBNDQpUbzogRGFuaWVsIENvaG4NCkNjOiBtcGxzOyBtcGxzLXRwQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIE5ldyBkcmFmdC12a3N0LW1wbHMtdHAtdGUtbWli LTAwIGRyYWZ0IGZvciByZXZpZXcNCg0KIA0KDQpEZWFyIERhbmllbCwNCg0KUGxlYXNlIHJlZmVy IHRoZSBsYXRlc3QgdmVyc2lvbiBkcmFmdCBmb3IgTVBMUy1UUCBpZGVudGlmaWVycyBkcmFmdC1p ZXRmLW1wbHMtdHAtaWRlbnRpZmllcnMtMDMuDQoNCiANCg0KIA0KDQogDQoNCiANCg0KIA0KDQog DQoNCiANCg0KIA0KDQogDQoNCldlIGRvbid0IGRpc2FncmVlIHdpdGggdGhlIE1QTFMtVFAgaWRl bnRpZmllcnMgZHJhZnQsIHRoZSBkcmFmdCBpcyBnZW5lcmljYWxseSB3cml0dGVuIGNvbnNpZGVy aW5nIHRoZSBjby1yb3V0ZWQgYW5kIGFzc29jaWF0ZWQgYmktZGlyZWN0aW9uYWwgdHVubmVscy4N Cg0KIA0KDQpUaGFua3MsDQoNClZlbmthdC4NCg0KIA0KDQpPbiBUdWUsIE1hciAxLCAyMDExIGF0 IDEwOjM2IEFNLCBEYW5pZWwgQ29obiA8RGFuaWVsQ0BvcmNraXQuY29tPiB3cm90ZToNCg0KSGkg VmVua2F0ZXNhbiwNCg0KIA0KDQpJIGZvcmdvdCB0byBjb25zaWRlciBhc3NvY2lhdGVkIGJpZGly ZWN0aW9uYWwg4oCTIGl0IG1ha2VzIHBlcmZlY3Qgc2Vuc2Ugbm93LiBBY3R1YWxseSB5b3UgZGlk IG1lbnRpb24gdGhlbSBpbiB5b3VyIGV4YW1wbGUgc2VjdGlvbiAoPGJsdXNoPikuDQoNClNvIGNh biB3ZSBhZ3JlZSB0aGVuIHRvIGRpc2FncmVlIHdpdGggdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQg aW4gZHJhZnQtc3dhbGxvdy1tcGxzLXRwLWlkZW50aWZpZXJzPw0KDQogDQoNCjUuMS4gIE1QTFMt VFAgUG9pbnQgdG8gUG9pbnQgVHVubmVsIElkZW50aWZpZXJzDQoNCjxzbmlwPg0KDQpUaGUgbW90 aXZhdGlvbiBmb3IgZWFjaCBlbmRwb2ludCBoYXZpbmcgaXRzIG93biB0dW5uZWwgIG51bWJlciBp cyB0byBhbGxvdyBhIGNvbXBhY3QgZm9ybSBmb3IgdGhlIE1FUC1JRA0KDQogDQoNCk9yIGFtIEkg YWdhaW4gbWlzc2luZyBzb21ldGhpbmc/DQoNCiANCg0K4KSn4KSo4KWN4KSv4KS14KS+4KSmLA0K DQpEYW5pZWwNCg0KIA0KDQpGcm9tOiB2ZW5rYXRlc2FuIG1haGFsaW5nYW0gW21haWx0bzp2ZW5r YXRmbGV4QGdtYWlsLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAwMSwgMjAxMSA1OjAwIFBN DQpUbzogRGFuaWVsIENvaG4NClN1YmplY3Q6IFJlOiBbbXBsc10gTmV3IGRyYWZ0LXZrc3QtbXBs cy10cC10ZS1taWItMDAgZHJhZnQgZm9yIHJldmlldw0KDQogDQoNCkRlYXIgRGFuaWVsLA0KDQpU aGVyZSBpcyBubyBkaXNjcmVwYW5jeS4NClNyYy1Ob2RlX0lEOjpTcmMtVHVubmVsX051bTo6RHN0 LU5vZGVfSUQ6OkRzdC1UdW5uZWxfTnVtDQpGb3IgY28tcm91dGVkIGJpLWRpcmVjdGlvbmFsIHR1 bm5lbCwgd2Ugd2lsbCBoYXZlIG9uZSB0dW5uZWwgZW50cnkgd2l0aCB0d28gWEMgZW50cmllcyBm b3IgYm90aCBmb3J3YXJkIGFuZCByZXZlcnNlIExTUHMuIEluIHRoaXMgY2FzZSwgc291cmNlIHR1 bm5lbCBudW1iZXIgaXMgc2FtZSBhcyBkZXN0aW5hdGlvbiB0dW5uZWwgbnVtYmVyLg0KSW5jYXNl IG9mIGFzc29jaWF0ZWQgYmktZGlyZWN0aW9uIHR1bm5lbCwgd2Ugd2lsbCBoYXZlIHR3byB0dW5u ZWwgZW50cmllcyBlYWNoIG9uZSBoYXMgc2VwYXJhdGUgWEMgZW50cnkgZm9yIExTUCBpbmZvcm1h dGlvbnMgKEZvcndhcmQgb3IgcmV2ZXJzZSBkaXJlY3Rpb24pLiBJbiB0aGlzIGNhc2UsIHdlIG5l ZWQgdG8gdXNlIHRoZSBtcGxzVHVubmVsRXh0VGFibGUgdG8gZ2l2ZSB0aGUgZGVzdGluYXRpb24g dHVubmVsIGluZGV4LiBTbywgd2Ugd2lsbCBoYXZlIHR3byB0dW5uZWxzIG9uZSBmb3IgZm9yd2Fy ZCBkaXJlY3Rpb24gd2l0aCByZXZlcnNlIGRpcmVjdGlvbiB0dW5uZWwgaW5kZXggYXNzb2NpYXRl ZCBzaW1pbGFybHkgcmV2ZXJzZSBkaXJlY3Rpb24gdHVubmVsIHdpdGggZm9yd2FyZCBkaXJlY3Rp b24gdHVubmVsIGluZGV4IGFzc29jaWF0ZWQuDQpIb3BlIHRoaXMgaGVscHMuDQogDQpUaGFua3Ms DQogDQpWZW5rYXQuDQoNCk9uIFR1ZSwgTWFyIDEsIDIwMTEgYXQgNTo1NCBBTSwgRGFuaWVsIENv aG4gPERhbmllbENAb3Jja2l0LmNvbT4gd3JvdGU6DQoNCkhpIFZlbnRha3NlYW4sDQoNCiANCg0K IA0KWW91ciBkcmFmdCBvZiByZWZlcmVuY2UgbWVudGlvbnMgdGhhdCBhIFRQIHR1bm5lbCBpcyBp bmRleGVkIGJ5IHR1bm5lbCBpbmRleCwgdHVubmVsIGluc3RhbmNlLCBzb3VyY2UgSUQgYW5kIGRl c3RpbmF0aW9uIElEICh3aGVyZSBJRCBjYW4gYmUgZWl0aGVyIGdsb2JhbDo6bG9jYWwgZm9yIElQ IG9yIElDQy1JRCBmb3IgSUNDKS4gSSBmdWxseSBhZ3JlZSB3aXRoIHRoaXMgc3RhdGVtZW50LiBI b3dldmVyIGRyYWZ0LXN3YWxsb3ctbXBscy10cC1pZGVudGlmaWVycyBzcGVjaWZpZXMgU3JjLU5v ZGVfSUQ6OlNyYy1UdW5uZWxfTnVtOjpEc3QtTm9kZV9JRDo6RHN0LVR1bm5lbF9OdW0sIHdoaWNo IGV4cGxpY2l0bHkgYXNzdW1lcyB0aGUgdmFsaWRpdHkgb2YgZGlmZmVyZW50IHR1bm5lbCBudW1i ZXIgYXQgc291cmNlIGFuZCBkZXN0aW5hdGlvbi4NCiANCkFyZSB5b3UgYXdhcmUgb2YgdGhpcyBk aXNjcmVwYW5jeT8gV2hhdCBpcyB5b3VyIHZpZXcgb24gdGhpcz8NCiANClRoYW5rcywNCiANCg0K IA0KDQpEYW5pZWwgQ29obg0KDQpTeXN0ZW0gRW5naW5lZXINCg0KT3Jja2l0LUNvcnJpZ2VudA0K DQpNb2JpbGU6ICs5NzIgNTQgOTIyIDUxMDQNCkVtYWlsOiBkYW5pZWxjQG9yY2tpdC5jb20NCg0K IGxvZ28tZmluYWwtc21hbGw8aHR0cHM6Ly9tYWlsLmdvb2dsZS5jb20vbWFpbC8/dWk9MiZpaz0y YWNjZWU5OGQyJnZpZXc9YXR0JnRoPTEyZTcyMzU0MDIzMzdiOTcmYXR0aWQ9MC4xJmRpc3A9ZW1i JnJlYWxhdHRpZD0zMzczYzc4MWUyOWFlYWNkXzAuMSZ6dz4gDQoNClB1c2hpbmcgdGVjaG5vbG9n eSB0byB0aGUgZWRnZQ0KDQogDQoNCiANCg0KIA0KDQogDQoNCkZyb206IHZlbmthdGVzYW4gbWFo YWxpbmdhbSBbbWFpbHRvOnZlbmthdGZsZXhAZ21haWwuY29tXSANClNlbnQ6IE1vbmRheSwgRmVi cnVhcnkgMjgsIDIwMTEgNToyMSBBTQ0KDQoNClRvOiBtcGxzOyBtcGxzLXRwQGlldGYub3JnDQoN ClN1YmplY3Q6IFttcGxzXSBOZXcgZHJhZnQtdmtzdC1tcGxzLXRwLXRlLW1pYi0wMCBkcmFmdCBm b3IgcmV2aWV3DQoNCiANCg0KSGkgVGVhbSwNCg0KV2UgaGF2ZSB1cGxvYWRlZCB0aGUgTVBMUy1U UCBURSBNSUIgZHJhZnQgbGFzdCB3ZWVrIGludG8gSUVURiByZXBvc2l0b3J5Lg0KDQogDQoNClRo aXMgZG9jdW1lbnQgcHJvdmlkZXMgYW4gZW5oYW5jZW1lbnQgdG8gdGhlIFJGQy0zODEyIGZvciBt YW5hZ2luZyB0aGUgVHJhZmZpYyBFbmdpbmVlcmluZyB0dW5uZWxzIA0KDQpmb3IgTVBMUyBiYXNl ZCB0cmFuc3BvcnQgbmV0d29ya3MgaW4gSVAgYW5kIE5vbi1JUCBvcGVyYXRvciBlbnZpcm9ubWVu dHMuDQoNCiANCg0KUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIHByb3ZpZGUgeW91ciB2YWx1 YWJsZSBjb21tZW50cy9zdWdnZXN0aW9ucy4NCg0KIA0KDQpBIFVSTCBvZiB0aGUgZHJhZnQgaXM6 DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC12a3N0LW1wbHMtdHAtdGUtbWliLTAw LnR4dA0KDQoNCi0tIA0KQmVzdCBSZWdhcmRzLA0KVmVua2F0ZXNhbiBNYWhhbGluZ2FtLg0KDQoN Cg0KDQotLSANCkJlc3QgUmVnYXJkcywNClZlbmthdGVzYW4gTWFoYWxpbmdhbS4NCg0KDQoNCg0K LS0gDQpCZXN0IFJlZ2FyZHMsDQpWZW5rYXRlc2FuIE1haGFsaW5nYW0uDQoNCg== ------_=_NextPart_001_01CBD831.426B08BA Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5Ok1hbmdhbDsNCglwYW5vc2UtMTowIDAgNCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6TWFuZ2FsOw0KCXBhbm9zZS0xOjAgMCA0IDAgMCAwIDAgMCAwIDA7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29s YXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5 MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFk Pjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRT ZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGFua3Mg VmVudGFrLCBJIHRoaW5rIG15IGNvbmZ1c2lvbiB3YXMgaGVscGVkIGJ5IHRoZSBpbmNvcnJlY3Qg cmVmZXJlbmNlIGluIGRyYWZ0LWlldGYtbXBscy10cC1pZGVudGlmaWVycy0wMy4gPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNl Y3Rpb24gNS4xIOKAnFNlZSBzZWN0aW9uIFNlY3Rpb24gNy4xLjIuMeKAnSBzaG91bGQgYmUg4oCc U2VlIHNlY3Rpb24gU2VjdGlvbiA3LjIuMi4x4oCdPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5kcmFmdC1p ZXRmLW1wbHMtdHAtaWRlbnRpZmllcnMtMDMgYXV0aG9ycywgcGxlYXNlIGNvbnNpZGVyIHRoZSBh Ym92ZSBjb21tZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UmVnYXJkcyBhbmQgdGhhbmtzIGFnYWlu IGZvciB0aGUgY2xhcmlmaWNhdGlvbi4sPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5EYW5pZWw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+IHZlbmthdGVzYW4gbWFoYWxpbmdhbSBbbWFpbHRvOnZlbmthdGZsZXhAZ21haWwuY29t XSA8YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXksIE1hcmNoIDAxLCAyMDExIDY6NDYgUE08YnI+PGI+ VG86PC9iPiBEYW5pZWwgQ29objxicj48Yj5DYzo8L2I+IG1wbHM7IG1wbHMtdHBAaWV0Zi5vcmc8 YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbbXBsc10gTmV3IGRyYWZ0LXZrc3QtbXBscy10cC10ZS1t aWItMDAgZHJhZnQgZm9yIHJldmlldzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkRlYXIg RGFuaWVsLDxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlBsZWFzZSByZWZl ciB0aGUgbGF0ZXN0IHZlcnNpb24gZHJhZnQgZm9yIE1QTFMtVFAgaWRlbnRpZmllcnMmbmJzcDs8 Yj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ZHJhZnQtaWV0Zi1tcGxz LXRwLWlkZW50aWZpZXJzLTAzLjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5XZSBkb24ndCBkaXNhZ3JlZSB3aXRoIHRoZSBNUExT LVRQIGlkZW50aWZpZXJzIGRyYWZ0LCB0aGUgZHJhZnQgaXMgZ2VuZXJpY2FsbHkgd3JpdHRlbiBj b25zaWRlcmluZyB0aGUgY28tcm91dGVkIGFuZCBhc3NvY2lhdGVkIGJpLWRpcmVjdGlvbmFsIHR1 bm5lbHMuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhhbmtzLDxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlZlbmthdC48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiBUdWUsIE1hciAxLCAyMDExIGF0IDEwOjM2 IEFNLCBEYW5pZWwgQ29obiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkRhbmllbENAb3Jja2l0LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPkRhbmllbENAb3Jja2l0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz5IaSBWZW5rYXRlc2FuLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtj b2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+SSBmb3Jn b3QgdG8gY29uc2lkZXIgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIOKAkyBpdCBtYWtlcyBwZXJm ZWN0IHNlbnNlIG5vdy4gQWN0dWFsbHkgeW91IGRpZCBtZW50aW9uIHRoZW0gaW4geW91ciBleGFt cGxlIHNlY3Rpb24gKCZsdDtibHVzaCZndDspLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdE Jz5TbyBjYW4gd2UgYWdyZWUgdGhlbiB0byBkaXNhZ3JlZSB3aXRoIHRoZSBmb2xsb3dpbmcgc3Rh dGVtZW50IGluIGRyYWZ0LXN3YWxsb3ctbXBscy10cC1pZGVudGlmaWVycz88L3NwYW4+PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Qn PjUuMS4mbmJzcDsgTVBMUy1UUCBQb2ludCB0byBQb2ludCBUdW5uZWwgSWRlbnRpZmllcnM8L3Nw YW4+PC9pPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxpPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPiZsdDtzbmlwJmd0Ozwvc3Bhbj48L2k+ PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGk+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+VGhlIG1vdGl2YXRpb24gZm9yIGVhY2ggZW5kcG9p bnQgaGF2aW5nIGl0cyBvd24gdHVubmVsJm5ic3A7IG51bWJlciBpcyB0byBhbGxvdyBhIGNvbXBh Y3QgZm9ybSBmb3IgdGhlIE1FUC1JRDwvc3Bhbj48L2k+PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCc+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPk9yIGFtIEkgYWdhaW4gbWlzc2lu ZyBzb21ldGhpbmc/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUhJIHN0eWxlPSdm b250LWZhbWlseTpNYW5nYWw7Y29sb3I6YmxhY2snPuCkp+CkqOCljeCkr+CkteCkvuCkpjwvc3Bh bj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiw8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5EYW5pZWw8L3NwYW4+PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Yj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Jz4gdmVua2F0ZXNhbiBtYWhhbGluZ2FtIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZlbmth dGZsZXhAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmVua2F0ZmxleEBnbWFpbC5jb208L2E+ XSA8YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXksIE1hcmNoIDAxLCAyMDExIDU6MDAgUE08YnI+PGI+ VG86PC9iPiBEYW5pZWwgQ29objxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFttcGxzXSBOZXcgZHJh ZnQtdmtzdC1tcGxzLXRwLXRlLW1pYi0wMCBkcmFmdCBmb3IgcmV2aWV3PC9zcGFuPjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5EZWFyIERhbmllbCw8bzpwPjwvbzpwPjwvcD48 ZGl2PjxwcmU+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiInPlRoZXJlIGlzIG5vIGRpc2NyZXBhbmN5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmU+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPlNyYy1O b2RlX0lEOjpTcmMtVHVubmVsX051bTo6RHN0LU5vZGVfSUQ6OkRzdC1UdW5uZWxfTnVtPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIic+Rm9yIGNvLXJvdXRlZCBiaS1kaXJlY3Rpb25hbCB0dW5uZWwsIHdl IHdpbGwgaGF2ZSBvbmUgdHVubmVsIGVudHJ5IHdpdGggdHdvIFhDIGVudHJpZXMgZm9yIGJvdGgg Zm9yd2FyZCBhbmQgcmV2ZXJzZSBMU1BzLiBJbiB0aGlzIGNhc2UsJm5ic3A7c291cmNlIHR1bm5l bCBudW1iZXIgaXMgc2FtZSBhcyBkZXN0aW5hdGlvbiB0dW5uZWwgbnVtYmVyLjwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiInPkluY2FzZSBvZiBhc3NvY2lhdGVkIGJpLWRpcmVjdGlvbiB0dW5uZWwsIHdl IHdpbGwgaGF2ZSB0d28gdHVubmVsIGVudHJpZXMgZWFjaCBvbmUgaGFzIHNlcGFyYXRlIFhDIGVu dHJ5IGZvciBMU1AgaW5mb3JtYXRpb25zIChGb3J3YXJkIG9yIHJldmVyc2UgZGlyZWN0aW9uKS4g SW4gdGhpcyBjYXNlLCB3ZSBuZWVkIHRvIHVzZSB0aGUgbXBsc1R1bm5lbEV4dFRhYmxlIHRvIGdp dmUgdGhlIGRlc3RpbmF0aW9uIHR1bm5lbCBpbmRleC4gU28sIHdlIHdpbGwgaGF2ZSB0d28gdHVu bmVscyBvbmUgZm9yIGZvcndhcmQgZGlyZWN0aW9uIHdpdGggcmV2ZXJzZSBkaXJlY3Rpb24gdHVu bmVsIGluZGV4IGFzc29jaWF0ZWQgc2ltaWxhcmx5IHJldmVyc2UgZGlyZWN0aW9uIHR1bm5lbCB3 aXRoIGZvcndhcmQgZGlyZWN0aW9uIHR1bm5lbCBpbmRleCBhc3NvY2lhdGVkLjwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiInPkhvcGUgdGhpcyBoZWxwcy48L3NwYW4+PG86cD48L286cD48L3ByZT48cHJl PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIic+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiJz5WZW5rYXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5PbiBUdWUsIE1hciAxLCAyMDExIGF0IDU6NTQgQU0s IERhbmllbCBDb2huICZsdDs8YSBocmVmPSJtYWlsdG86RGFuaWVsQ0BvcmNraXQuY29tIiB0YXJn ZXQ9Il9ibGFuayI+RGFuaWVsQ0BvcmNraXQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPkhpIFZlbnRha3NlYW4sPG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PHByZT4mbmJz cDs8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiInPllvdXIgZHJhZnQgb2YgcmVmZXJlbmNlIG1lbnRpb25zIHRoYXQg YSBUUCB0dW5uZWwgaXMgaW5kZXhlZCBieSB0dW5uZWwgaW5kZXgsIHR1bm5lbCBpbnN0YW5jZSwg c291cmNlIElEIGFuZCBkZXN0aW5hdGlvbiBJRCAod2hlcmUgSUQgY2FuIGJlIGVpdGhlciBnbG9i YWw6OmxvY2FsIGZvciBJUCBvciBJQ0MtSUQgZm9yIElDQykuIEkgZnVsbHkgYWdyZWUgd2l0aCB0 aGlzIHN0YXRlbWVudC4gSG93ZXZlciBkcmFmdC1zd2FsbG93LW1wbHMtdHAtaWRlbnRpZmllcnMg c3BlY2lmaWVzIFNyYy1Ob2RlX0lEOjpTcmMtVHVubmVsX051bTo6RHN0LU5vZGVfSUQ6OkRzdC1U dW5uZWxfTnVtLCB3aGljaCBleHBsaWNpdGx5IGFzc3VtZXMgdGhlIHZhbGlkaXR5IG9mIGRpZmZl cmVudCB0dW5uZWwgbnVtYmVyIGF0IHNvdXJjZSBhbmQgZGVzdGluYXRpb24uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIic+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PHByZT48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIic+QXJlIHlvdSBhd2FyZSBv ZiB0aGlzIGRpc2NyZXBhbmN5PyBXaGF0IGlzIHlvdXIgdmlldyBvbiB0aGlzPzwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiInPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPlRoYW5rcyw8L3NwYW4+ PG86cD48L286cD48L3ByZT48cHJlPjxzcGFuIGxhbmc9RU4+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPkRh bmllbCBDb2huPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPlN5c3RlbSBFbmdpbmVlcjwv c3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz5PcmNraXQtQ29ycmlnZW50PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2NvbG9yOiMxRjQ5N0QnPk1vYmlsZTogKzk3MiA1NCA5MjIgNTEwNDxicj5FbWFpbDogPGEg aHJlZj0ibWFpbHRvOmRhbmllbGNAb3Jja2l0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRhbmllbGNA b3Jja2l0LmNvbTwvYT48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxicj48YnI+ PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2NvbG9yOm5hdnknPjxpbWcgYm9y ZGVyPTAgd2lkdGg9MTc2IGhlaWdodD04OCBpZD0iX3gwMDAwX2kxMDM0IiBzcmM9Imh0dHBzOi8v bWFpbC5nb29nbGUuY29tL21haWwvP3VpPTImYW1wO2lrPTJhY2NlZTk4ZDImYW1wO3ZpZXc9YXR0 JmFtcDt0aD0xMmU3MjM1NDAyMzM3Yjk3JmFtcDthdHRpZD0wLjEmYW1wO2Rpc3A9ZW1iJmFtcDty ZWFsYXR0aWQ9MzM3M2M3ODFlMjlhZWFjZF8wLjEmYW1wO3p3IiBhbHQ9bG9nby1maW5hbC1zbWFs bD48L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGk+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6Z3JheSc+UHVzaGluZyB0ZWNobm9sb2d5IHRvIHRo ZSBlZGdlPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwcmU+PHNw YW4gbGFuZz1FTj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiB2ZW5rYXRlc2FuIG1haGFsaW5nYW0g W21haWx0bzo8YSBocmVmPSJtYWlsdG86dmVua2F0ZmxleEBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj52ZW5rYXRmbGV4QGdtYWlsLmNvbTwvYT5dIDxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBG ZWJydWFyeSAyOCwgMjAxMSA1OjIxIEFNPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PGJyPjxiPlRvOjwvYj4gbXBsczsgPGEgaHJlZj0ibWFpbHRvOm1wbHMt dHBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzLXRwQGlldGYub3JnPC9hPjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxiPlN1YmplY3Q6PC9iPiBbbXBsc10g TmV3IGRyYWZ0LXZrc3QtbXBscy10cC10ZS1taWItMDAgZHJhZnQgZm9yIHJldmlldzxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5IaSBUZWFtLDxvOnA+PC9vOnA+PC9wPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+V2UgaGF2ZSB1cGxvYWRlZCB0aGUgTVBMUy1UUCBURSBNSUIg ZHJhZnQgbGFzdCB3ZWVrIGludG8gSUVURiByZXBvc2l0b3J5LjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz5UaGlzIGRvY3VtZW50IHByb3ZpZGVzIGFuIGVuaGFuY2Vt ZW50IHRvIHRoZSBSRkMtMzgxMiBmb3IgbWFuYWdpbmcgdGhlIFRyYWZmaWMgRW5naW5lZXJpbmcg dHVubmVscyZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+Zm9yIE1QTFMgYmFzZWQgdHJhbnNwb3J0IG5ldHdvcmtzIGluIElQIGFuZCBOb24tSVAgb3Bl cmF0b3IgZW52aXJvbm1lbnRzLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvJz5QbGVhc2UgcmV2aWV3IHRoZSBkcmFmdCBhbmQgcHJvdmlkZSB5b3VyIHZhbHVhYmxlIGNv bW1lbnRzL3N1Z2dlc3Rpb25zLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvJz5BIFVSTCBvZiB0aGUgZHJhZnQgaXM6PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvJz48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQt dmtzdC1tcGxzLXRwLXRlLW1pYi0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMu aWV0Zi5vcmcvaWQvZHJhZnQtdmtzdC1tcGxzLXRwLXRlLW1pYi0wMC50eHQ8L2E+PG86cD48L286 cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48YnI+LS0gPGJyPkJlc3QgUmVnYXJkcyw8 YnI+VmVua2F0ZXNhbiBNYWhhbGluZ2FtLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2 PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxicj48YnIgY2xl YXI9YWxsPjxicj4tLSA8YnI+QmVzdCBSZWdhcmRzLDxicj5WZW5rYXRlc2FuIE1haGFsaW5nYW0u PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxicj48YnIgY2xlYXI9YWxsPjxicj4tLSA8YnI+QmVzdCBSZWdhcmRzLDxi cj5WZW5rYXRlc2FuIE1haGFsaW5nYW0uPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9ib2R5 PjwvaHRtbD4= ------_=_NextPart_001_01CBD831.426B08BA-- From davari@broadcom.com Tue Mar 1 11:54:08 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C8F3A6AAE; Tue, 1 Mar 2011 11:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] 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 n8aZybIN1aR8; Tue, 1 Mar 2011 11:54:03 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 6EB1A3A6A8F; Tue, 1 Mar 2011 11:54:03 -0800 (PST) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 01 Mar 2011 11:57:16 -0800 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Tue, 1 Mar 2011 11:54:57 -0800 From: "Shahram Davari" To: "Alexander Vainshtein" , "David Allan I" Date: Tue, 1 Mar 2011 11:54:57 -0800 Thread-Topic: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03 Thread-Index: AcvDrJpCvXJpavHRRhKBBXlDzw1/zAFFYIGQABGDQCAAAKcQEAACic4AAAbIaBADxnLswA== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6956BBA178B@SJEXCHCCR02.corp.ad.broadcom.com> References: <4D4AB81D.3080907@pi.nu> <06c901cbc8d4$d682a820$8387f860$@com> <60C093A41B5E45409A19D42CF7786DFD51CDF3F790@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 617390163BS5809748-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , Robert Rennison , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 19:54:08 -0000 Hi, I would like to support the disabling of Poll/Final for MPLS-TP LSP BFDs. T= ransport networks don't need to change the rates and are mostly static. Als= o Poll/Final will most likely require extra Software in addition to HW, whi= ch can increase complexity and cost for MPLS-TP operation. Regards, Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Thursday, February 10, 2011 6:38 AM To: David Allan I Cc: mpls@ietf.org; mpls-tp@ietf.org; Robert Rennison Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv= -rdi-03 Dave, and all, To avoid any misinterpretation, please consider the original email as my LC= comment. Regards, Sasha -----Original Message----- From: Alexander Vainshtein=20 Sent: Thursday, February 10, 2011 1:36 PM To: 'David Allan I' Cc: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; Robert Ren= nison Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv= -rdi-03 Dave and all, I'd like to remind you that Rob and I have already questioned the decision = to change the BFD state machine by disabling in some case the Poll/Final se= quence. The situation as presented in the draft seems to introduce even more proble= ms.=20 E.g., RFC 5885 allows to run BFD in VCCV without UDP/IP encapsulation but f= ollows the procedures specified in RFC 5880 and 5881 which, to the best of = my understanding, include usage of Poll/Final sequence. It is my understanding that BFD for an MPLS-TP LSP would look exactly as BF= D in VCCV (including the same code point). If this is correct, how should the implementation distinguish between "PWE3= mode" (where poll/final are used) and "MPLS-TP mode where they seem to be = prohibited? Regards, Sasha -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Dav= id Allan I Sent: Thursday, February 10, 2011 1:09 PM To: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@= lists.itu.int Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv= -rdi-03 =20 Hi Mach:=20 Thanks for the review >I read the draft, here are some comments, please consider: >1.Section 3.5, last sentence of first paragraph >"Poll/final discipline can only used for VCCV and UDP/IP encapsulated BFD.= " >There is a "be" lost between "can" and "only". Good catch, will fix. >2.Section 3.5.2 >"1. BFD control packets are received with an unexpected encapsulation (mis= -connectivity defect), these include:=20 > - a PW receiving a packet with a GAL", Since GAL can be used=20 >for PW(http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-00), t= his should not be a defect. Suggest to remove it. We'll review and edit accordingly. >3 Section 3.5.2 >" 4. Receipt of an expected session discriminator with an unexpected label= (mis-connectivity defect).", For a receiver, how does it know that the ses= sion >discriminator is valid but the label is invalid? IMHO, this defect is= just another description of defect 3 . Suggest to remove it. If the session discriminator exists in the BFD database, it is superficiall= y a valid descriminator but the label of arrival can be incorrect. This may= indicate an implementation problem at the source MEP. What we were referri= ng to in '3' was a session discriminator that did not exist in the local da= tabase, BFD had never handed it out hence it could not be found. >4.Section 3.5.4.2 >" Exit from a misconfiguration defect occurs when two consecutive CC or=20 >CV frames have been received with the expected M bit setting." IMHO, this = sentence is little bit vague, and since this draft only defines for P2P LSP= , why not just say "...with M bit clear." OK >5. Section 3.5.4.3 >"Exit from a mis-connectivity defect state occurs when no CV messages=20 >have been received with an incorrect source MEP-ID for a period of 3.5 sec= onds.", since there are several defects listed in Section 3.5.2 and this is= only one condition for exiting from a mis-connectivity defect state. How a= bout "Exit >from a mis-connectivity defect state occurs when no CV messages= with mis-connectivity defects have been received for a period of 3.5 secon= ds " That seems to be more accurate, I'd replace "with...." with "indicating an = on-going mis-connectivity defect has been....". Simply wordsmithing. >6. Section 3.5.5 >In Figure 5, seems that it is lack of "AIS-LDI, LKR" inputs for DOWN state= . Good catch. Will fix Cheers Dave > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Thursday, February 03, 2011 10:14 PM > To: mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int > Subject: [mpls-tp] mpls wg last call on > draft-ietf-mpls-tp-cc-cv-rdi-03 >=20 > Working Group, >=20 > this is to start a four week working group last call on "Proactive=20 > Connectivity Verification, Continuity Check and Remote Defect=20 > indication for MPLS Transport Profile" > (draft-ietf-mpls-tp-cc-cv-rdi-03.txt). >=20 > Please send comments to the mpls-tp@ietf.org mailing list. >=20 > This working group last call ends on February 28, 2011. >=20 >=20 > Loa, George and Ross >=20 > MPLS wg co-chairs > -- >=20 >=20 > Loa Andersson email: > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From gregimirsky@gmail.com Tue Mar 1 12:28:51 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56F753A6AA9; Tue, 1 Mar 2011 12:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 NowqFTmlvYuX; Tue, 1 Mar 2011 12:28:49 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 8189D3A69F9; Tue, 1 Mar 2011 12:28:48 -0800 (PST) Received: by vws6 with SMTP id 6so5156243vws.31 for ; Tue, 01 Mar 2011 12:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=n1Eijio3A3rTU/ytczXE5ITo8Ka9lj8DRp4iE4KBplw=; b=lqqoLA5bBPVpHjzB3wuR+WkmHDGxYXLy0ExdYC1kydNqVaAo+9yvXit0IqoP1OTcwU cV96UrBwuF4DW4ufDigESsHhZqwpRsFBcFVn9v7AQsYxzn/6EsPsvCChXC+XhFDDumSv 3r7XJ1gZKRnwsXzT5RN3vcy1CqWAgmEDsOZMo= 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=XX0/C5bE4U/gib+YfkDE6uRe3iJnnBimVNwBiUPfP+EkCdDFMbNEBu770+c92VB/GS esG2rfUfEJ8fWeV8l/+J9VVYK+c+6szz4Lt1FVoS3g/jOMoVO5uRe4n0oWVxur4NdwgF 9ftPXckHq4BTg32s+e1rbhmg7dXHehk7Tse1E= MIME-Version: 1.0 Received: by 10.52.89.140 with SMTP id bo12mr9020303vdb.142.1299011392102; Tue, 01 Mar 2011 12:29:52 -0800 (PST) Received: by 10.52.169.65 with HTTP; Tue, 1 Mar 2011 12:29:52 -0800 (PST) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6956BBA178B@SJEXCHCCR02.corp.ad.broadcom.com> References: <4D4AB81D.3080907@pi.nu> <06c901cbc8d4$d682a820$8387f860$@com> <60C093A41B5E45409A19D42CF7786DFD51CDF3F790@EUSAACMS0703.eamcs.ericsson.se> <2C2F1EBA8050E74EA81502D5740B4BD6956BBA178B@SJEXCHCCR02.corp.ad.broadcom.com> Date: Tue, 1 Mar 2011 12:29:52 -0800 Message-ID: From: Greg Mirsky To: Shahram Davari Content-Type: multipart/alternative; boundary=bcaec50166b395e2c2049d71a8ec Cc: "mpls@ietf.org" , Alexander Vainshtein , Robert Rennison , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 20:28:51 -0000 --bcaec50166b395e2c2049d71a8ec Content-Type: text/plain; charset=ISO-8859-1 Dear Shahram, Sasha and All, I support current wording of the first para in Section 3.5. to address Sasha's concern regarding distinguishing MPLS CC message from BFD over VCCV per RFC 5885 the last sentence might be changed to like: "Poll/final discipline can be only used for VCCV and UDP/IP encapsulated BFD when using unique appropriate Associated Channel type." I believe that lately there was sufficient discussion about compatibility of BFD-based CC OAM and BFD over VCCV. AFAIK, there's no requirement to support backward compatibility and that might be stated in the document. Regards, Greg On Tue, Mar 1, 2011 at 11:54 AM, Shahram Davari wrote: > Hi, > > I would like to support the disabling of Poll/Final for MPLS-TP LSP BFDs. > Transport networks don't need to change the rates and are mostly static. > Also Poll/Final will most likely require extra Software in addition to HW, > which can increase complexity and cost for MPLS-TP operation. > > Regards, > Shahram > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein > Sent: Thursday, February 10, 2011 6:38 AM > To: David Allan I > Cc: mpls@ietf.org; mpls-tp@ietf.org; Robert Rennison > Subject: Re: [mpls] [mpls-tp] mpls wg last call on > draft-ietf-mpls-tp-cc-cv-rdi-03 > > Dave, and all, > To avoid any misinterpretation, please consider the original email as my LC > comment. > > Regards, > Sasha > > > -----Original Message----- > From: Alexander Vainshtein > Sent: Thursday, February 10, 2011 1:36 PM > To: 'David Allan I' > Cc: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; Robert > Rennison > Subject: RE: [mpls] [mpls-tp] mpls wg last call on > draft-ietf-mpls-tp-cc-cv-rdi-03 > > Dave and all, > I'd like to remind you that Rob and I have already questioned the decision > to change the BFD state machine by disabling in some case the Poll/Final > sequence. > > The situation as presented in the draft seems to introduce even more > problems. > E.g., RFC 5885 allows to run BFD in VCCV without UDP/IP encapsulation but > follows the procedures specified in RFC 5880 and 5881 which, to the best of > my understanding, include usage of Poll/Final sequence. > > It is my understanding that BFD for an MPLS-TP LSP would look exactly as > BFD in VCCV (including the same code point). > If this is correct, how should the implementation distinguish between "PWE3 > mode" (where poll/final are used) and "MPLS-TP mode where they seem to be > prohibited? > > Regards, > Sasha > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > David Allan I > Sent: Thursday, February 10, 2011 1:09 PM > To: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; > ahmpls-tp@lists.itu.int > Subject: Re: [mpls] [mpls-tp] mpls wg last call on > draft-ietf-mpls-tp-cc-cv-rdi-03 > > > > Hi Mach: > > Thanks for the review > > >I read the draft, here are some comments, please consider: > > >1.Section 3.5, last sentence of first paragraph > > >"Poll/final discipline can only used for VCCV and UDP/IP encapsulated > BFD." > >There is a "be" lost between "can" and "only". > > Good catch, will fix. > > >2.Section 3.5.2 > >"1. BFD control packets are received with an unexpected encapsulation > (mis-connectivity defect), these include: > > - a PW receiving a packet with a GAL", Since GAL can be used > >for PW(http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-00), > this should not be a defect. Suggest to remove it. > > We'll review and edit accordingly. > > >3 Section 3.5.2 > >" 4. Receipt of an expected session discriminator with an unexpected label > (mis-connectivity defect).", For a receiver, how does it know that the > session >discriminator is valid but the label is invalid? IMHO, this defect > is just another description of defect 3 . Suggest to remove it. > > If the session discriminator exists in the BFD database, it is > superficially a valid descriminator but the label of arrival can be > incorrect. This may indicate an implementation problem at the source MEP. > What we were referring to in '3' was a session discriminator that did not > exist in the local database, BFD had never handed it out hence it could not > be found. > > >4.Section 3.5.4.2 > >" Exit from a misconfiguration defect occurs when two consecutive CC or > >CV frames have been received with the expected M bit setting." IMHO, this > sentence is little bit vague, and since this draft only defines for P2P LSP, > why not just say "...with M bit clear." > > OK > > >5. Section 3.5.4.3 > >"Exit from a mis-connectivity defect state occurs when no CV messages > >have been received with an incorrect source MEP-ID for a period of 3.5 > seconds.", since there are several defects listed in Section 3.5.2 and this > is only one condition for exiting from a mis-connectivity defect state. How > about "Exit >from a mis-connectivity defect state occurs when no CV messages > with mis-connectivity defects have been received for a period of 3.5 seconds > " > > That seems to be more accurate, I'd replace "with...." with "indicating an > on-going mis-connectivity defect has been....". Simply wordsmithing. > > >6. Section 3.5.5 > > >In Figure 5, seems that it is lack of "AIS-LDI, LKR" inputs for DOWN > state. > > Good catch. Will fix > > Cheers > Dave > > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of Loa Andersson > > Sent: Thursday, February 03, 2011 10:14 PM > > To: mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int > > Subject: [mpls-tp] mpls wg last call on > > draft-ietf-mpls-tp-cc-cv-rdi-03 > > > > Working Group, > > > > this is to start a four week working group last call on "Proactive > > Connectivity Verification, Continuity Check and Remote Defect > > indication for MPLS Transport Profile" > > (draft-ietf-mpls-tp-cc-cv-rdi-03.txt). > > > > Please send comments to the mpls-tp@ietf.org mailing list. > > > > This working group last call ends on February 28, 2011. > > > > > > Loa, George and Ross > > > > MPLS wg co-chairs > > -- > > > > > > Loa Andersson email: > > loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > --bcaec50166b395e2c2049d71a8ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Shahram, Sasha and All,
I support current wording of the first para= in Section 3.5. to address Sasha's concern regarding distinguishing MP= LS CC message from BFD over VCCV per RFC 5885 the last sentence might be ch= anged to like:
"Poll/final discipline can be only used for VCCV and UDP/IP encapsulat= ed BFD when using unique appropriate Associated Channel type."
I = believe that lately there was sufficient discussion about compatibility of = BFD-based CC OAM and BFD over VCCV. AFAIK, there's no requirement to su= pport backward compatibility and that might be stated in the document.

Regards,
Greg

On Tue, Mar 1, 2011 = at 11:54 AM, Shahram Davari <davari@broadcom.com> wrote:
Hi,

I would like to support the disabling of Poll/Final for MPLS-TP LSP BFDs. T= ransport networks don't need to change the rates and are mostly static.= Also Poll/Final will most likely require extra Software in addition to HW,= which can increase complexity and cost for MPLS-TP operation.

Regards,
Shahram

-----Original Message-----
From: mpls-bounces@ietf.org [m= ailto:mpls-bounces@ietf.org] O= n Behalf Of Alexander Vainshtein
Sent: Thursday, February 10, 2011 6:38 AM
To: David Allan I
Cc: mpls@ietf.org; mpls-tp@ietf.org; Robert Rennison
Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv= -rdi-03

Dave, and all,
To avoid any misinterpretation, please consider the original email as my LC= comment.

Regards,
=A0 =A0 Sasha


-----Original Message-----
From: Alexander Vainshtein
Sent: Thursday, February 10, 2011 1:36 PM
To: 'David Allan I'
Cc: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; = Robert Rennison
Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv= -rdi-03

Dave and all,
I'd like to remind you that Rob and I have already questioned the decis= ion to change the BFD state machine by disabling in some case the Poll/Fina= l sequence.

The situation as presented in the draft seems to introduce even more proble= ms.
E.g., RFC 5885 allows to run BFD in VCCV without UDP/IP encapsulation but f= ollows the procedures specified in RFC 5880 and 5881 which, to the best of = my understanding, include usage of Poll/Final sequence.

It is my understanding that BFD for an MPLS-TP LSP would look exactly as BF= D in VCCV (including the same code point).
If this is correct, how should the implementation distinguish between "= ;PWE3 mode" (where poll/final are used) and "MPLS-TP mode where t= hey seem to be prohibited?

Regards,
=A0 =A0 Sasha

-----Original Message-----
From: mpls-bounces@ietf.org [m= ailto:mpls-bounces@ietf.org] O= n Behalf Of David Allan I
Sent: Thursday, February 10, 2011 1:09 PM
To: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; = ahmpls-tp@lists.itu.int
Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv= -rdi-03



Hi Mach:

Thanks for the review

>I read the draft, here are some comments, please consider:

>1.Section 3.5, last sentence of first paragraph

>"Poll/final discipline can only used for VCCV and UDP/IP encapsula= ted BFD."
>There is a "be" lost between "can" and "only&q= uot;.

Good catch, will fix.

>2.Section 3.5.2
>"1. BFD control packets are received with an unexpected encapsulat= ion (mis-connectivity defect), these include:
> =A0 =A0 =A0 =A0 =A0- a PW receiving a packet with a GAL", Since G= AL can be used
>for PW(http://tools.ietf.org/html/draft-ietf-pwe3-mp= ls-tp-gal-in-pw-00), this should not be a defect. Suggest to remove it.=

We'll review and edit accordingly.

>3 Section 3.5.2
>" 4. Receipt of an expected session discriminator with an unexpect= ed label (mis-connectivity defect).", For a receiver, how does it know= that the session >discriminator is valid but the label is invalid? IMHO= , this defect is just another description of defect 3 . Suggest to remove i= t.

If the session discriminator exists in the BFD database, it is superficiall= y a valid descriminator but the label of arrival can be incorrect. This may= indicate an implementation problem at the source MEP. What we were referri= ng to in '3' was a session discriminator that did not exist in the = local database, BFD had never handed it out hence it could not be found.
>4.Section 3.5.4.2
>" Exit from a misconfiguration defect occurs when two consecutive = CC or
>CV frames have been received with the expected M bit setting." IMH= O, this sentence is little bit vague, and since this draft only defines for= P2P LSP, why not just say "...with M bit clear."

OK

>5. Section 3.5.4.3
>"Exit from a mis-connectivity defect state occurs when no CV messa= ges
>have been received with an incorrect source MEP-ID for a period of 3.5 = seconds.", since there are several defects listed in Section 3.5.2 and= this is only one condition for exiting from a mis-connectivity defect stat= e. How about "Exit >from a mis-connectivity defect state occurs whe= n no CV messages with mis-connectivity defects have been received for a per= iod of 3.5 seconds "

That seems to be more accurate, I'd replace "with...." with &= quot;indicating an on-going mis-connectivity defect has been....". Sim= ply wordsmithing.

>6. Section 3.5.5

>In Figure 5, seems that it is lack of "AIS-LDI, LKR" inputs f= or DOWN state.

Good catch. Will fix

Cheers
Dave



> -----Original Message-----
> From: mpls-tp-bounces@ietf= .org [mailto:mpls-tp-bounce= s@ietf.org] On
> Behalf Of Loa Andersson
> Sent: Thursday, February 03, 2011 10:14 PM
> To: mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int
> Subject: [mpls-tp] mpls wg last call on
> draft-ietf-mpls-tp-cc-cv-rdi-03
>
> Working Group,
>
> this is to start a four week working group last call on "Proactiv= e
> Connectivity Verification, Continuity Check and Remote Defect
> indication for MPLS Transport Profile"
> (draft-ietf-mpls-tp-cc-cv-rdi-03.txt).
>
> Please send comments to the mpls-t= p@ietf.org mailing list.
>
> This working group last call ends on February 28, 2011.
>
>
> Loa, George and Ross
>
> MPLS wg co-chairs
> --
>
>
> Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: > loa.andersson@ericsson.c= om
> Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
> Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone:= +46 10 717 52 13
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 +46 767 = 72 92 13
> _______________________________________________
> mpls-tp mailing list
> mpls-tp@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls


_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp

--bcaec50166b395e2c2049d71a8ec-- From iesg-secretary@ietf.org Tue Mar 1 16:22:59 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE0603A6A30; Tue, 1 Mar 2011 16:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, 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 eTiNUWArm4dc; Tue, 1 Mar 2011 16:22:58 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B503A6B5A; Tue, 1 Mar 2011 16:22:57 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110302002257.5469.58139.idtracker@localhost> Date: Tue, 01 Mar 2011 16:22:57 -0800 Cc: mpls mailing list , mpls chair , Internet Architecture Board , RFC Editor Subject: [mpls] Protocol Action: 'MPLS Upstream Label Assignment for LDP' to Proposed Standard (draft-ietf-mpls-ldp-upstream-10.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 00:23:00 -0000 The IESG has approved the following document: - 'MPLS Upstream Label Assignment for LDP' (draft-ietf-mpls-ldp-upstream-10.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-upstream/ Technical Summary The document describes procedures for distributing upstream-assigned labels for the Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. Working Group Summary Nothing to report Document Quality There is at least one implementation that we know of. Personnel Loa Andersson (loa@pi.nu) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. RFC Editor Note Section 3 s/MUST be carried only LDP initialization messages/MUST be carried only in LDP initialization messages/ --- Section 4.1 OLD As described in [RFC5331] an upstream LSR Ru MAY transmit a MPLS packet, the top label of which (L) is upstream-assigned, to a downstream LSR Rd. NEW As described in [RFC5331], a specific upstream LSR (Ru) MAY transmit an MPLS packet, the top label of which (L) is upstream-assigned, to it downstream neighbor LSR (Rd). END --- Section 8 OLD The security considerations discussed in RFC 5036, RFC 5331 and RFC 5332 apply to this document. NEW The security considerations discussed in [RFC5036], [RFC5331] and [RFC5332] apply to this document. END --- Sections 10.1/10.2 Please move [RFC5561] from Informative to Normative. --- Section 10.2 Note that [MPLS-SEC] is now RFC 5920. From rcallon@juniper.net Tue Mar 1 18:30:17 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3383C3A6C15 for ; Tue, 1 Mar 2011 18:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 lYx+i5c14ikE for ; Tue, 1 Mar 2011 18:30:16 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 243003A6C12 for ; Tue, 1 Mar 2011 18:30:15 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTW2r91JEnBG8UEXncxOhB71UUU860NlT@postini.com; Tue, 01 Mar 2011 18:31:21 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 1 Mar 2011 18:26:33 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 1 Mar 2011 21:27:11 -0500 From: Ross Callon To: "mpls@ietf.org" Date: Tue, 1 Mar 2011 21:27:10 -0500 Thread-Topic: mpls wg last call on draft-ietf-mpls-ldp-p2mp-11 Thread-Index: AcvDrJhCOwxbl7gbTh6wLaZt8CCDPAUkW1CwAAAOGjA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] mpls wg last call on draft-ietf-mpls-ldp-p2mp-11 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 02:30:17 -0000 Working Group, This is to start a two week working group last call on "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths" (draft-ietf-mpls-ldp-p2mp-11). Please send comments to the mpls@ietf.org mailing list. This working group last call ends on March 16, 2011.=20 Ross, George, and Loa MPLS WG co-chairs From Internet-Drafts@ietf.org Tue Mar 1 21:00:02 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19D53A6C01; Tue, 1 Mar 2011 21:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, 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 JDID4jta+cIW; Tue, 1 Mar 2011 21:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92BEF3A6B5D; Tue, 1 Mar 2011 21:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110302050001.8771.83391.idtracker@localhost> Date: Tue, 01 Mar 2011 21:00:01 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-li-lb-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 05:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Transport Profile Lock Instruct and Loopback Functions Author(s) : S. Boutros, et al. Filename : draft-ietf-mpls-tp-li-lb-01.txt Pages : 20 Date : 2011-03-01 This document specifies an extension to MPLS Operation, administration, and Maintenance (OAM) to operate an Label Switched Path (LSP), bi-directional RSVP-TE tunnels, Pseudowires (PW), or Multi-segment PWs in loopback mode for management purpose in an MPLS based Transport. This extension includes mechanism to lock and unlock MPLS-TP Tunnels (i.e. data and control traffic) and can be used to loop all traffic (i.e, data and control traffic) at a specified LSR on the path of the LSP in an MPLS based Transport Network back to the source. However, the mechanisms are intended to be applicable to other aspects of MPLS as well. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-li-lb-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-01204638.I-D@ietf.org> --NextPart-- From Alexander.Vainshtein@ecitele.com Wed Mar 2 05:35:55 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E21A3A67FB; Wed, 2 Mar 2011 05:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] 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 D8mOac6xZPDd; Wed, 2 Mar 2011 05:35:54 -0800 (PST) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id 745233A67D8; Wed, 2 Mar 2011 05:35:53 -0800 (PST) X-AuditID: 93eaf2e8-b7cc2ae000002890-78-4d6e47b53587 Received: from ilptexch01.ecitele.com (ilptexfe.ecitele.com [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 4F.96.10384.5B74E6D4; Wed, 2 Mar 2011 15:35:49 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 2 Mar 2011 15:36:56 +0200 From: Alexander Vainshtein To: Shahram Davari Date: Wed, 2 Mar 2011 15:36:54 +0200 Thread-Topic: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03 Thread-Index: AcvDrJpCvXJpavHRRhKBBXlDzw1/zAFFYIGQABGDQCAAAKcQEAACic4AAAbIaBADxnLswAAif0NA Message-ID: References: <4D4AB81D.3080907@pi.nu> <06c901cbc8d4$d682a820$8387f860$@com> <60C093A41B5E45409A19D42CF7786DFD51CDF3F790@EUSAACMS0703.eamcs.ericsson.se> <2C2F1EBA8050E74EA81502D5740B4BD6956BBA178B@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6956BBA178B@SJEXCHCCR02.corp.ad.broadcom.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsWyRv6Lhu5W9zxfgy9/ZC3W93paPDy/ndni 6TMXi1tLV7I6sHjMun+WzePX16tsHkuW/GQKYI7isklJzcksSy3St0vgymg518ZecNemYtXt LrYGxi0GXYycHBICJhI7m+azQNhiEhfurWfrYuTiEBI4yygxfXsfM4QzmVHi05WzTCBVbAK2 EptW32UDsUUENCQO3rrCDGIzC6xklDi6jxHEZhFQkbhz5R07iC0sECLx7FcnI0R9qMT2jt1M EHaUxNHrE8BsXgF/iWmHprJALFvHJHH1yQmgBg4OTqCiaw22IDWMQNd9P7WGCWKXuMStJ/OZ IK4WkFiy5zwzhC0q8fLxP1aIelGJO+3rGSHqdSQW7P7EBmFrSyxb+JoZYq+gxMmZT1gmMIrN QjJ2FpKWWUhaZiFpWcDIsopRNDOnoCQpN93ASC81ObMkNSdVLzk/dxMjMLYmv/r0YgfjhM06 hxiZODilGhibrF2m+fAGyj0233S2alvr+TtfZmWKN6nq7r3QuVS8cYL+0f7pmkdeCikaxeVK dN05+ujLsoJNjhztcR3N5+OnPHsnLPjycGL/my+6rouDjgks5pgvM7+ypPJJktDXslAlT7bI 8J/yTU0GBzcU2C8OPftAf77O641vljDxLPl47NTHo7uCZjMosRRnJBpqMRcVJwIAqU3m7l0C AAA= Cc: "mpls@ietf.org" , Robert Rennison , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 13:35:55 -0000 Shahram and all, Please see some comments inline below. Regards, Sasha > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Tuesday, March 01, 2011 9:55 PM > To: Alexander Vainshtein; David Allan I > Cc: mpls@ietf.org; mpls-tp@ietf.org; Robert Rennison > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03 >=20 > Hi, >=20 > I would like to support the disabling of Poll/Final for MPLS-TP LSP > BFDs. Transport networks don't need to change the rates and are mostly > static.=20 [[[Sasha]]] There are two different statements here IMO: 1. "Transport networks do not have to change the rates". Sounds very much like "transport networks are always single-vendor" to m= e. Because in a multi-vendor environment you have to deal with different ra= te ranges And have from time to time manipulate these rates... 2. "Transport networks are mostly static". I do not really understand how this is related to the subject. =20 Also Poll/Final will most likely require extra Software in > addition to HW, which can increase complexity and cost for MPLS-TP > operation. [[[Sasha]]] Extra SW (as opposed to extra HW) usually doesn't cost to the o= perators. And the vendors who have implemented Poll/Final will have to go into=20 new development and support two different BFD state machines... if this is = not expensive, what is? >=20 > Regards, > Shahram >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein > Sent: Thursday, February 10, 2011 6:38 AM > To: David Allan I > Cc: mpls@ietf.org; mpls-tp@ietf.org; Robert Rennison > Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03 >=20 > Dave, and all, > To avoid any misinterpretation, please consider the original email as > my LC comment. >=20 > Regards, > Sasha >=20 >=20 > -----Original Message----- > From: Alexander Vainshtein > Sent: Thursday, February 10, 2011 1:36 PM > To: 'David Allan I' > Cc: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; Robert > Rennison > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03 >=20 > Dave and all, > I'd like to remind you that Rob and I have already questioned the > decision to change the BFD state machine by disabling in some case the > Poll/Final sequence. >=20 > The situation as presented in the draft seems to introduce even more > problems. > E.g., RFC 5885 allows to run BFD in VCCV without UDP/IP encapsulation > but follows the procedures specified in RFC 5880 and 5881 which, to the > best of my understanding, include usage of Poll/Final sequence. >=20 > It is my understanding that BFD for an MPLS-TP LSP would look exactly > as BFD in VCCV (including the same code point). > If this is correct, how should the implementation distinguish between > "PWE3 mode" (where poll/final are used) and "MPLS-TP mode where they > seem to be prohibited? >=20 > Regards, > Sasha >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > David Allan I > Sent: Thursday, February 10, 2011 1:09 PM > To: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; > ahmpls-tp@lists.itu.int > Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03 >=20 >=20 >=20 > Hi Mach: >=20 > Thanks for the review >=20 > >I read the draft, here are some comments, please consider: >=20 > >1.Section 3.5, last sentence of first paragraph >=20 > >"Poll/final discipline can only used for VCCV and UDP/IP encapsulated > BFD." > >There is a "be" lost between "can" and "only". >=20 > Good catch, will fix. >=20 > >2.Section 3.5.2 > >"1. BFD control packets are received with an unexpected encapsulation > (mis-connectivity defect), these include: > > - a PW receiving a packet with a GAL", Since GAL can be used > >for PW(http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw- > 00), this should not be a defect. Suggest to remove it. >=20 > We'll review and edit accordingly. >=20 > >3 Section 3.5.2 > >" 4. Receipt of an expected session discriminator with an unexpected > label (mis-connectivity defect).", For a receiver, how does it know > that the session >discriminator is valid but the label is invalid? > IMHO, this defect is just another description of defect 3 . Suggest to > remove it. >=20 > If the session discriminator exists in the BFD database, it is > superficially a valid descriminator but the label of arrival can be > incorrect. This may indicate an implementation problem at the source > MEP. What we were referring to in '3' was a session discriminator that > did not exist in the local database, BFD had never handed it out hence > it could not be found. >=20 > >4.Section 3.5.4.2 > >" Exit from a misconfiguration defect occurs when two consecutive CC > or > >CV frames have been received with the expected M bit setting." IMHO, > this sentence is little bit vague, and since this draft only defines > for P2P LSP, why not just say "...with M bit clear." >=20 > OK >=20 > >5. Section 3.5.4.3 > >"Exit from a mis-connectivity defect state occurs when no CV messages > >have been received with an incorrect source MEP-ID for a period of 3.5 > seconds.", since there are several defects listed in Section 3.5.2 and > this is only one condition for exiting from a mis-connectivity defect > state. How about "Exit >from a mis-connectivity defect state occurs > when no CV messages with mis-connectivity defects have been received > for a period of 3.5 seconds " >=20 > That seems to be more accurate, I'd replace "with...." with "indicating > an on-going mis-connectivity defect has been....". Simply wordsmithing. >=20 > >6. Section 3.5.5 >=20 > >In Figure 5, seems that it is lack of "AIS-LDI, LKR" inputs for DOWN > state. >=20 > Good catch. Will fix >=20 > Cheers > Dave >=20 >=20 >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of Loa Andersson > > Sent: Thursday, February 03, 2011 10:14 PM > > To: mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int > > Subject: [mpls-tp] mpls wg last call on > > draft-ietf-mpls-tp-cc-cv-rdi-03 > > > > Working Group, > > > > this is to start a four week working group last call on "Proactive > > Connectivity Verification, Continuity Check and Remote Defect > > indication for MPLS Transport Profile" > > (draft-ietf-mpls-tp-cc-cv-rdi-03.txt). > > > > Please send comments to the mpls-tp@ietf.org mailing list. > > > > This working group last call ends on February 28, 2011. > > > > > > Loa, George and Ross > > > > MPLS wg co-chairs > > -- > > > > > > Loa Andersson email: > > loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From ietfc@btconnect.com Wed Mar 2 08:49:37 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4FE63A67B3; Wed, 2 Mar 2011 08:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ekp9LKQ3Zk2L; Wed, 2 Mar 2011 08:49:37 -0800 (PST) Received: from mail.btconnect.com (c2beaomr07.btconnect.com [213.123.26.185]) by core3.amsl.com (Postfix) with ESMTP id 8418D3A67A5; Wed, 2 Mar 2011 08:49:35 -0800 (PST) Received: from host217-44-145-106.range217-44.btcentralplus.com (HELO pc6) ([217.44.145.106]) by c2beaomr07.btconnect.com with SMTP id BYR52327; Wed, 02 Mar 2011 16:50:38 +0000 (GMT) Message-ID: <000801cbd8f0$f3b272a0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ross Callon" , , , References: Date: Wed, 2 Mar 2011 16:46:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4D6E755E.001F, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0208.4D6E755F.0197,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Subject: Re: [mpls] MPLS WG last call on draft-ietf-mpls-tp-loss-delay-profile-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 16:49:38 -0000 The choice of parameters here looks fine but the language that goes with it less so. The protocol will still send the parameters in TLV but this I-D says that "When an LM session is externally configured, the values of several protocol parameters can be fixed in advance at the endpoints involved in the session, so that inspection or negotiation of these parameters is not required." " A simple implementation may assume that external configuration will ensure that both ends of the communication are using the default values for these parameters." This seems to me too cavalier. If one end is configured correctly for eg packet and the other incorrectly for byte and these recommendations are followed, then the protocol will work, will produce values and those values will be a complete nonsense. Ditto the other parameters and DM. I do not think we should be recommending something which is open to such errors. There have been a fair number of posts on the mpls-tp list about misconfiguration, about the fact that it is always with us and that we need to be robust in the presence of it. Here we seem to be digging a heffalump trap for mpls-tp to fall into. Tom Petch ----- Original Message ----- From: "Ross Callon" To: ; ; Sent: Monday, February 07, 2011 4:33 AM Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-loss-delay-profile-02 > Working Group, > > This is to start a four week working group last call on > "A Packet Loss and Delay Measurement Profile for MPLS-based > Transport Networks" > (draft-ietf-mpls-tp-loss-delay-profile-02.txt). > > Please send comments to the mpls-tp@ietf.org mailing list. > > Also, please note that the related document > "draft-ietf-mpls-loss-delay-01" is being last called in > parallel on the MPLS WG email list. > > This working group last call ends on Monday March 7, 2011. > > Ross, Loa, and George > > MPLS WG co-chairs > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From marc.lasserre@alcatel-lucent.com Thu Mar 3 01:11:24 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDCFF3A695F; Thu, 3 Mar 2011 01:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.248 X-Spam-Level: X-Spam-Status: No, score=-5.248 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 xsZF0IDXaSnm; Thu, 3 Mar 2011 01:11:05 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 73C243A6964; Thu, 3 Mar 2011 01:11:03 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p239BmiE018609 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Mar 2011 10:12:10 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 3 Mar 2011 10:12:04 +0100 From: "LASSERRE, MARC (MARC)" To: "mpls-tp@ietf.org" , "mpls@ietf.org" Date: Thu, 3 Mar 2011 10:12:01 +0100 Thread-Topic: Re: [mpls] mpls WG last call on draft on draft-ietf-mpls-tp-linear-protection-04: Major comments (part 1) Thread-Index: AcvXp1+R2FxKFrhcTxK2hQuKpBDsQQB2JyOgAAC6H2A= Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_E6E66922099CFB4391FAA7A7D3238F9F214DB505FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [mpls] mpls WG last call on draft on draft-ietf-mpls-tp-linear-protection-04: Major comments (part 1) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 09:11:25 -0000 --_000_E6E66922099CFB4391FAA7A7D3238F9F214DB505FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am forwarding this message again (in 2 parts) as the original message bou= nced. Sorry for the extra delay. Marc ________________________________ From: LASSERRE, MARC (MARC) Sent: mardi 1 mars 2011 01:27 To: 'mpls-tp@ietf.org'; 'mpls@ietf.org' Subject: Re: [mpls] mpls WG last call on draft on draft-ietf-mpls-tp-linear= -protection-04 Below is a list of major comments to draft on draft-ietf-mpls-tp-linear-pro= tection-04: 1. General: A definition of Failure of Protocol defects is missing. There= is only a mention in 4.2.3 (Protection type field) or in 4.2.4 (Revertive = field) that inconsistency in the value between both end points leads to an = alarm SHALL be sent to the management system, but this is not sufficient; t= here are other protocol and configuration mismatches which should be alarme= d. 2. General: the Exercise operator command is missing. Exercise is used to= test, while in idle situation, that a protection path is available and tha= t the protection mechanism works properly without actually switching the tr= affic itself. Exercise is a requirement in RFC 5654 MPLS-TP Requirements (R= eqt #84). 3. General: The current document misses a specification for a Hold-off ti= mer. It is only shortly mentioned in section 3.1.1 (page 9) and is only a M= AY. An explicit description is needed. 4. General: Neither this document nor the MPLS-TP Survivability Framework= document mention the protection switching time performance objective of 50= ms as requirement. In the MPLS-TP Survivability Framework document, there = is only one mention on pgae 30 "For 50-ms protection switching, ...". In t= his document, there is only indirect mention in "For protection switching w= ithin 50ms, it is RECOMMENDED that the default interval of the first three = PSC messages SHOULD be no larger than 3.3ms." It needs to be explicitly mentioned 5. Section 1.1 (page 4) and Section 4.2.3 (page 17): IETF defines both 1+= 1 and 1:1 unidirectional and 1+1 and 1:1 bidirectional. ITU-T G.8031 (Ether= net) and G.8131 defined 1+1 unidirectional, 1:1 and 1+1 bidirectional but n= ot 1:1 unidirectional. What's the rationale behind the inclusion of 1:1 uni= directional? There is no known application for it, neither in legacy transp= ort networks nor in Ethernet Transport networks. What are the applications for it? 6. Section 3.1.5 (page 12): the WtR timer can be stopped by the PSC Contr= ol Logic. The text is not clear if the operator also has possibility to ove= rride the WtR timer and its PSC Control logic by clearing manually the WtR = timer. Clear of WtR is a capability in transport network. Two solutions: ei= ther introduce a Clear WtR command or use the same Clear command as used fo= r clearing LO/FS/MS operator command to stop the WtR timer. 7. Section 3.1.5 (page 12): Is it possible to list the range of values, s= teps and default for the WtR timer? (In ITU-T, WtR values are explicitly pr= ovided: 1 minute steps between 5 and 12 minutes; the default value is 5 min= utes.) 8. General about Section 4.2: PSC signaling: the LER always signals (in R= equest field) the local highest priority request and, consistently, signals= in FPath field, either the signal 1 (when protection is required) or signa= l 0 (when the protection is unavailable). Then it matches the possible far = end highest priority request, by signaling (in Path field) the same value o= f Path field in PSC packet received. With this behavior, a command locally applied at one end, with a lower prio= rity than far end requests, seems to be kept as "pending" (there is no evid= ence of a different behavior in the draft). "pending" commands are not all= owed to co-exist. 9. Section 4.1 (page 15): Wrt paragraph "The frequency of the three rapid= messages and the separate frequency of the continual transmission SHOULD b= e configurable by the operator. For protection switching within 50ms, the d= efault interval of the first three PSC messages is RECOMMENDED to be no lar= ger than 3.3ms. The continuous transmission interval is RECOMMENDED to be 5= seconds". Replace the "SHOULD" by a "MAY" in the first sentence. Rationale: There is no strong requirement to make them configurable by the= operator. All packet transport network operators want it to switch in 50ms= and have as little configuration as possible. In current practice such rat= es are not configurable; neither are they in ITU-T G.8031. Therefore the pr= oposal is to replace the "SHOULD" by a "MAY" in the first sentence. 10. Section 4.1 (page 15): The following requirement "If no valid PSC speci= fic information is received, the last valid received information remains ap= plicable. In the event a signal fail condition is detected on the protectio= n path, the received PSC specific information should be evaluated." should = be revised: o Proposal to remove the second sentence "In the event a signal fail condi= tion is detected on the protection transport entity, the received PSC speci= fic information should be evaluated" as it is is either incorrect or mislea= ding. When SF is detected on a protection MPLS-TP LSP, the data is meaningl= ess so evaluating it is not meaningful. 11. Section 4.1 (page 15): The last paragraph should also add "If a protect= ion end point receives PSC-specific information from the working entity, it= should ignore this information. This will also lead to detection of a Fail= ure of Protocol defect" (see comment #1 for FOP)." 12. Appendix A (page 31): The sentence "In the event of a mismatch be= tween these tables and the text in section 4.3.3, the text is authoritative= ." Proposal to align text and table instead 13. Section 4.3.3.4 (page27) When in remote protection state failure and su= ddenly an NR is received , LER need to go to normal, if not a lock conditio= n exist where one end is in remote protection failure state waiting for WTR= and the other end is in normal. The test following text should be added to Section 4.3.3.4 (page27) "If in remote Protecting failure state, a remote NR message SHALL cause the= LER to go into the Normal state and SHALL transmit a NR(0,0) message." Page 34 table part2 should also be corrected as follow (replace i by N): PF:W:R |UA:LO:R|UA:P:R|PA:F:R| i | i | [14] | [15] | i(N) 14. Section 4.3.3.5 (page29) Remote Wait-to-restore state is not addressed = properly. It is mentioned on page 27, but later on page 32 only WR state is mentioned= . In order not to get stuck in remote wait-to-restore state on both end sendi= ng NR(0,1) in a recovery of a simultaneous Signal Fail on working, the foll= owing need to be added on (page29) "If in remote wait-to-restore state then a remote NR message SHALL cause th= e LER to go into Normal state and begin transmitting a NR(0,0) message." The table on page 34 Part 2 line WTR addresses the issue. --_000_E6E66922099CFB4391FAA7A7D3238F9F214DB505FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am forwarding thi= s message again (in 2 parts) as the original message bounced. Sorry for the e= xtra delay.

 

Marc

 

From:= LASSERRE, MARC (MARC)
Sent: mardi 1 mars 2011 01:2= 7
To: 'mpls-tp@ietf.org'; 'mpl= s@ietf.org'
Subject: Re: [mpls] mpls WG = last call on draft on draft-ietf-mpls-tp-linear-protection-04

 

Below is a list of major comments t= o draft on draft-ietf-mpls-tp-linear-protection-04:<= /p>

 

1. &= nbsp; General: A definition of Failure of Protocol defects is missing. There is only a mention in 4.2.3 (Protection type field) or in 4.2= .4 (Revertive field) that inconsistency in the value between both end points l= eads to an alarm SHALL be sent to the management system, but this is not suffici= ent; there are other protocol and configuration mismatches which should be alarm= ed.

2.   General: the Exercise operator command is missing. Exercise= is used to test, while in idle situation, that a protection path is available = and that the protection mechanism works properly without actually switching the traffic itself. Exercise is a requirement in RFC 5654 MPLS-TP Requirements (Reqt #84).

3.   General: The current document misses a specification for a Hold-off timer. It is only shortly mentioned in section 3.1.1 (page 9) and = is only a MAY. An explicit description is needed.

4. &= nbsp; General: Neither this document nor the MPLS-TP Survivabilit= y Framework document mention the protection switching time performance object= ive of 50ms as requirement.  In the MPLS-TP Survivability Framework docume= nt, there is only one mention on pgae 30 “For 50-ms protection switching, …”.  In this document, there is only indirect mention in “For protection switchi= ng within 50ms, it is RECOMMENDED that the default interval of the first three= PSC messages SHOULD be no larger than 3.3ms.”
It needs to be explicitly mentioned

 

5. &= nbsp; Section 1.1 (page 4) and Section 4.2.3 (page 17): IETF defi= nes both 1+1 and 1:1 unidirectional and 1+1 and 1:1 bidirectional. ITU-T G.8031 (Ethernet) and G.8131 defined 1+1 unidirectional, 1:1 and 1+1 bidirectional= but not 1:1 unidirectional. What’s the rationale behind the inclusion of = 1:1 unidirectional? There is no known application for it, neither in legacy transport networks nor in Ethernet Transport networks.
What are the applications for it?

 

6.   Section 3.1.5 (page 12): the WtR timer can be stopped by th= e PSC Control Logic. The text is not clear if the operator also has possibili= ty to override the WtR timer and its PSC Control logic by clearing manually th= e WtR timer. Clear of WtR is a capability in transport network. Two solutions= : either introduce a Clear WtR command or use the same Clear command as used = for clearing LO/FS/MS operator command to stop the WtR timer.=

7.   Section 3.1.5 (page 12): Is it possible to list the range o= f values, steps and default for the WtR timer? (In ITU-T, WtR values are explicitly provided: 1 minute steps between 5 and 12 minutes; the default v= alue is 5 minutes.)

8.   General about Section 4.2: PSC signaling: the LER always signals (in Request field) the local highest priority request and, consistently, signals in FPath field, either the signal 1 (when protection = is required) or signal 0 (when the protection is unavailable). Then it matches= the possible far end highest priority request, by signaling (in Path field) the same value of Path field in PSC packet received.
With this behavior, a command locally applied at one end, with a lower prio= rity than far end requests, seems to be kept as “pending” (there is = no evidence of a different behavior in the draft).  “pending” commands are not allowed to co-exist.

9.   Section 4.1 (page 15): Wrt paragraph “<= font size=3D2 face=3D"Courier New">The frequency of the three rapid messages and the separate frequency of the continual transmission SHOULD be configurable by the opera= tor. For protection switching within 50ms, the default interval of the first thr= ee PSC messages is RECOMMENDED to be no larger than 3.3ms. The continuous transmission interval is RECOMMENDED to be 5 seconds”.

Replace the “SHOULD” by a “MAY” in = the first sentence.

 Rationale: There is no strong requirement to make the= m configurable by the operator. All packet transport network operators want i= t to switch in 50ms and have as little configuration as possible. In current practice such rates are not configurable; neither are they in ITU-T G.8031. Therefore the proposal is to replace the “SHOULD” by a “MAY” in the first sentence.

10. Section 4.1 (page 15): The following requirement "If no valid PSC specific information is received, the last valid received information remains applicable. In the event a signal fail condition is detected on the protection path, the received PSC specific information shou= ld be evaluated." should be revi= sed:

o  <= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Trebuchet MS"'>Proposal= to remove the second sentence "In the ev= ent a signal fail condition is detected on the protection transport entity, the received PSC specific information should be evaluated" as it is is either incorrect or misleading. When SF = is detected on a protection MPLS-TP LSP, the data is meaningless so evaluating= it is not meaningful.


11. Section 4= .1 (page 15): The last paragraph should also add “If a protection end point receives PSC-specific information from the working entity, it should ignore this information. This will also lead to detection= of a Failure of Protocol defect” = (see comment #1 for FOP).”

12.     &n= bsp; Appendix A (page 31):= The sentence "In the event of a mism= atch between these tables and the text in section 4.3.3, the text is authoritati= ve."

Proposal to align text and table instead

 

13. Sect= ion 4.3.3.4 (page27) When in remote protection state failure and suddenly an NR is rece= ived , LER need to go to normal, if not a lock condition exist where one end is = in remote protection failure state waiting for WTR and the other end is in nor= mal.

The test= following text should be added to Section 4.3.3.4 (page27)

“I= f in remote Protecting failure state, a remote NR message SHALL cause the LER to= go into the Normal state and SHALL transmit= a NR(0,0) message.”

Page 34 = table part2 should also be corrected as follow (replace i by N):

PF:W:R  |UA:LO:R|UA:P:R|PA:F:R| i    | i    | [14] | = [15] | i(N)

 <= /o:p>

14. Sect= ion 4.3.3.5 (page29) Remote Wait-to-restore state is not addressed properly.

It is me= ntioned on page 27, but later on page 32 only WR state is mentioned.

In order= not to get stuck in remote wait-to-restore state on both end sending NR(0,1) in a recovery of a simultaneous Signal Fail on working, the following need to be added on (page29)

“If= in remote wait-to-restore state then a remote NR message SHALL cause the LER t= o go into Normal state and begin transmitting= a NR(0,0) message.”

The tabl= e on page 34 Part 2 line WTR addresses the issue.

 

--_000_E6E66922099CFB4391FAA7A7D3238F9F214DB505FRMRSSXCHMBSC3d_-- From marc.lasserre@alcatel-lucent.com Thu Mar 3 01:13:05 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D173A6964; Thu, 3 Mar 2011 01:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.581 X-Spam-Level: X-Spam-Status: No, score=-5.581 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 alikdwQKti5y; Thu, 3 Mar 2011 01:12:58 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 87EA13A695F; Thu, 3 Mar 2011 01:12:57 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p239CcHN018916 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Mar 2011 10:14:02 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 3 Mar 2011 10:13:49 +0100 From: "LASSERRE, MARC (MARC)" To: "LASSERRE, MARC (MARC)" , "mpls-tp@ietf.org" , "mpls@ietf.org" Date: Thu, 3 Mar 2011 10:13:46 +0100 Thread-Topic: Re: [mpls] mpls WG last call on draft on draft-ietf-mpls-tp-linear-protection-04: Minor comments (part 2) Thread-Index: AcvXp1+R2FxKFrhcTxK2hQuKpBDsQQB2JyOgAADGK/A= Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_E6E66922099CFB4391FAA7A7D3238F9F214DB50DFRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [mpls] mpls WG last call on draft on draft-ietf-mpls-tp-linear-protection-04: Minor comments (part 2) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 09:13:05 -0000 --_000_E6E66922099CFB4391FAA7A7D3238F9F214DB50DFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the second part of the message with minor comments. Marc ________________________________ From: LASSERRE, MARC (MARC) Sent: mardi 1 mars 2011 01:27 To: 'mpls-tp@ietf.org'; 'mpls@ietf.org' Subject: Re: [mpls] mpls WG last call on draft on draft-ietf-mpls-tp-linear= -protection-04 Below is a list of minor comments to draft on draft-ietf-mpls-tp-linear-pro= tection-04: - The document uses consistently the term working path but inconsistently e= ither recovery or protection path. The term "protection path" is more commo= nly used. - Section 3.1 (page 7): In "e.g. switching the Selector Bridge to select th= e working or protection path, and transmit different protocol messages." It= is not only the selector bridge which selects the working and protection p= aths: to be precise, it can be the Selector Bridge at the source or the Sel= ective Selector at the sink of the protection domain. - Section 3.1 (page 8): Figure 1 is not complete. It could be enhanced with= additional text and blocks as for example in ITU-T G.8031: the output of t= he PSC Control Logic is not only action to generate PSC message to far-end,= it should also show the local action to set the local bridge/selector. The= Remote PSC Request should first go through a PSC message Validity Check - Section 3.1.1 (page 9) - 1st bullet: in "Operator command - the network o= perator may issue commands that trigger protection switching. The supporte= d commands are Forced Switch, Manual Switch, Clear, Lockout of Protection, = (see definitions in [RFC4427])" the local request logic only processes oper= ator commands issued locally on this LER, while the operator commands on re= mote LER are received via PSC messages and handled in the PSC Control logic= , therefore, the sentence could be improved to "Operator command - the netw= ork operator may issue local administrative commands on the LER that trigge= r protection switching. The supported commands are Forced Switch, Manual S= witch, Clear, Lockout of Protection, (see definitions in [RFC4427])" - Section 31.1 (page 9) - 2nd bullet: It should also be clarified, which i= s the signal generated at server layer (or at its adaptation layer) expecte= d to be used as "server layer alarm indication". In ITU-T Equipment specifi= cation this would be defined in unambiguous terms by referring to the CI_SS= F contribution from the server layer. But this contribution is unclear wrt = current IETF OAM specification. Does it include for example AIS w/LDI indic= ation? Description of an application scenario could also contribute in clar= ifying the function. - Section 3.1.1 (page 9) - 4th bullet: in "OAM indication - OAM fault manag= ement or performance measurement tools may detect a failure or degrade cond= ition on the MPLS-TP transport path and this SHOULD input an indication to = the Local Request Logic." Suggest to rephrase "failure and degrade conditio= ns on either working and protection transport paths" - Section 3.1.1 (pages 9 & 10): the text should indicate which local reques= t is global versus per transport path (working or protection): for example,= SF condition is in reality SF-Working or SF-Protection - Section 3.1.3 (page 11): In "b. the remote request message from the remo= te end point of the transport path," add reference (see section 3.1.2) as d= one in the item #a. - Section 3.1.6.1 (page 14): "If, however, the LER has local and remote ind= icators that would cause the PSC Control logic to enter different states, e= .g. a Local SF on working and a Remote Lockout message, then the state with= the higher importance will be the deciding factor and the source of that i= ndicator will determine whether it is local or remote." It is not clear wha= t is the "state of higher importance". There is a definition of priority be= tween different inputs in section 4.3.2, which I suppose is what is referre= d to, but there is no definition of priority/importance of PSC control stat= e in the document. Clarification needed. - Section 4.1: transmission of PSC packets over the protection path also in= creases availability - Section 4.2.2 (page 16): why choose code points different from those alre= ady used in ITU-T G.8031? - Section 4.2.2 (page 16): Typo: Signal Defect -> Signal Degrade - Section 4.3.2 (page 20): "7. Clear Signal Fail/Degrade (OAM/Control Plane= /Server Indication)" is listed as part of the priority list. In ITU-T linea= r protection specification, clearance of SF/SD is not listed explicitly in = the priority list and is taken into account different in the priority logic= and state machine. It is not a functional issue, but is it possible to add a note to clarify t= he need to keep this in the priority list? - Appendix 1 (page 31), end of first paragraph: typo "implementation" -= > "implementation" - Appendix A (page 33): The abbreviation CSF for Clear Signal Fail" is = misleading as CSF is an already used term for Client Signal Fail indication= in OAM. The following syntax is preferable: SFc (SF Clear) - Section 4.1 page 15 , first paragraph: "When the PSC information changes due to a remote message there is no need for the aforementioned rapid transmission of three messages. The exception ..." why not make it simple and always require a rapid transmission of three messages on any PSC change of messages. - Section 4.3.3.2 page 22: "A local Lockout of protection input SHALL cause the LER to remain in local Unavailable State and transmit a LO(0,0) message to the far-end LER (LER-Z)." While it is clear that no change is state is desired here, is the local Loc= kout command rejected or accepted when a local Lockout already exist, that = is not clear or specified here or on page 32. - Section 4.3.3.3 page 24: "A local Forced switch input SHALL cause the LER to remain in local Protecting administrative state and transmit a FS(1,1) message" While it is clear that no change is state is desired here, is the local For= ced switched command rejected or accepted when a local FS already exist, th= at is not clear or specified here or on page 32. - Section 4.3.3.3 page 24: "A local Signal Fail indication on the protection path SHALL cause the LER to go into local Unavailable state (i.e. overriding the MS related Protection administrative state) and begin transmission of a SF(0,0) message." The FS should also be added to the MS in the example "(i.e. overriding the = MS or FS...) - Section 4.3.3.3 page 25: "A local Manual switch input SHALL be ignored if in remote Protecting administrative state is due to a remote Forced switch command. If the current state is due to a (local or remote) Manual switch operator command, it SHALL cause the LER to remain in local Protecting administrative state and transmit a MS(1,1) message." While it is clear that no change is state is desired here, is the MS switch= ed command rejected or accepted when a local MS already exist, that is not = clear or specified here or on page 32. --_000_E6E66922099CFB4391FAA7A7D3238F9F214DB50DFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Here is the second = part of the message with minor comments.

 

Marc

 

From:= LASSERRE, MARC (MARC)
Sent: mardi 1 mars 2011 01:2= 7
To: 'mpls-tp@ietf.org'; 'mpls@ietf.org'
Subject: Re: [mpls] mpls WG = last call on draft on draft-ietf-mpls-tp-linear-protection-04

 

Below is a list of minor comments t= o draft on draft-ietf-mpls-tp-linear-protection-04:<= /p>

- The document uses consistently the term working path but inconsistently either recovery or protection path. The term “protecti= on path” is more commonly used.

- = Section 3.1 (page 7): In “e.g. switching the Selector Bridge to select th= e working or protection path, and transmit different protocol messages= .” It is not only the selector bridge which selects t= he working and protection paths: to be precise, it can be the <= st1:PlaceName w:st=3D"on">Selector Bridge at the source or the Selective Selector at the sink of the protection domai= n.

- Section 3.1 (page 8): Figure 1 is not complete. It could be enhanced with additional text and blocks as for example in ITU-T G.8031: th= e output of the PSC Control Logic is not only action to generate PSC message = to far-end, it should also show the local action to set the local bridge/selec= tor. The Remote PSC Request should first go through a PSC message Validity Check=

- Section 3.1.1 (page 9) – 1st bullet: in “Operator command - the network operator may issue commands that trigger protection switching. = ; The supported commands are Forced Switch, Manual Switch, Clear, Lockout of = Protection, (see definitions in [RFC4427])” = the local request logic only processes operator commands issued locally on this LER, while the operator commands on remote LER are received via PSC message= s and handled in the PSC Control logic, therefore, the sentence could be impr= oved to “Operator command - the network operator may issue local administrative commands on the LER that trigger protection switching.  The supported commands are Forced Switc= h, Manual Switch, Clear, Lockout of Protection, (see definitions in [RFC4427])= ”

- = Section 31.1 (page 9) – 2nd bullet:  = It should also be clarified, which is the signal generated at server layer (or= at its adaptation layer) expected to be used as “server layer alarm indication”. In ITU-T Equipment specification this would be defined i= n unambiguous terms by referring to the CI_SSF contribution from the server layer. But this contribution is unclear wrt current IETF OAM specification. Does it include for example AIS w/LDI indication? Description of an applica= tion scenario could also contribute in clarifying the function.

- = Section 3.1.1 (page 9) - 4th bullet: in “<= /span>OAM indication - OAM fault management or performance measure= ment tools may detect a failure or degrade condition on the MPLS-TP transport pa= th and this SHOULD input an indication to the Local Request Logic.” Suggest to rephrase “failure and degrade conditions on either working and protection transport paths”

- = Section 3.1.1 (pages 9 & 10): the text should indicate which local request is global versus per transport path (working or protection): for example, SF condition is in reality SF-Working or SF-Protection

- = Section 3.1.3 (page 11): In “b.  the remote request message from the remote end point of the transport path,= ” add reference (see section 3.1.2) as done in the it= em #a.

- = Section 3.1.6.1 (page 14): “If, however, the LER has local and remote indicators that would cause the PSC Control logic to enter different states, e.g. a Local SF on working and a Remote Lockout message, then the state with the higher importance will be t= he deciding factor and the source of that indicator will determine whether it = is local or remote.” = It is not clear what is the “state of higher importance”. There is a definition of priority between different inputs in section 4.3.2, which I suppose is what is referred to, but there is no definition of priority/importance of PSC control state in the document. Clarification nee= ded.

- = Section 4.1: transmission of PSC packets over the protectio= n path also increases availability

- = Section 4.2.2 (page 16): why choose code points different f= rom those already used in ITU-T G.8031?

- Section 4.2.2 (page 16): Typo: Signal Defect -> Signal Degrade=

- Section 4.3.2 (page 20): “<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>7. Clear Signal Fail/Degrade (OAM/Control Plane/Server Indicati= on)” is listed as part of the priority list. In ITU-T li= near protection specification, clearance of SF/SD is not listed explicitly in th= e priority list and is taken into account different in the priority logic and state machine.
It is not a functional issue, but is it possible to add a note to clarify t= he need to keep this in the priority list?

-     Appendix= 1 (page 31), end of first paragraph: typo “implementation” -> “implementation”

- &n= bsp;   Appendix A (page 33):= The abbreviation CSF for Clear Signal Fail” is misleading as CSF is an already used term for Client Signal Fail indication in OAM. The following syntax is preferable: SFc (SF Clear)

&nb= sp;

&nb= sp;

- Section 4.1 page 15 , first paragraph:

“<= /span>When the PSC information changes due to a remote<= /span>

message t= here is no need for the aforementioned rapid transmission of<= /p>

three messages.  The exception …”

why not = make it simple and always require a rapid transmission of<= /p>

three me= ssages on any PSC change of messages.

&nb= sp;

&nb= sp;

- Section 4.3.3.2 page 22:<= /p>

“A = local Lockout of protection input SHALL cause the LER to remain<= /p>

in local = Unavailable State and transmit a LO(0,0) messa= ge to the

far-end L= ER (LER-Z).”

While it= is clear that no change is state is desired here, is the local Lockout command rejected or accepted when a local Lockout already exist, that is not clear = or specified here or on page 32.

&nb= sp;

- Section 4.3.3.3 page 24:<= /p>

“A = local Forced switch input SHALL cause the LER to remain in local

Protectin= g administrative state and transmit a FS(1,1) message”

While it= is clear that no change is state is desired here, is the local Forced switched command rejected or accepted when a local FS already exist, that is not cle= ar or specified here or on page 32.

&nb= sp;

- Section 4.3.3.3 page 24:<= /p>

“A = local Signal Fail indication on the protection path SHALL cause=

the LER t= o go into local Unavailable state (i.e. overriding the MS

related Protection administrative state) and begin transmission of

a SF(0,0) message.”

 

The FS s= hould also be added to the MS in the example “(i.e. overriding the MS or FS…)

&nb= sp;

- Section 4.3.3.3 page 25:

“A = local Manual switch input SHALL be ignored if in remote<= /p>

Protectin= g administrative state is due to a remote Forced switch

command.&= nbsp; If the current state is due to a (local or remote)

Manual sw= itch operator command, it SHALL cause the LER to remain=

in local Protecting administrative state and transmit a MS(1,1)

message.&= #8221;

While it= is clear that no change is state is desired here, is the MS switched command rejected or accepted when a local MS already exist, that is not clear or specified here or on page 32.

 

--_000_E6E66922099CFB4391FAA7A7D3238F9F214DB50DFRMRSSXCHMBSC3d_-- From marc.lasserre@alcatel-lucent.com Thu Mar 3 07:14:08 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D493A69E8; Thu, 3 Mar 2011 07:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 NbKmFhnoQae1; Thu, 3 Mar 2011 07:14:04 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 0ED893A67B2; Thu, 3 Mar 2011 07:14:03 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p23FEu1P014889 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Mar 2011 16:15:10 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 3 Mar 2011 16:15:02 +0100 From: "LASSERRE, MARC (MARC)" To: "mpls-tp@ietf.org" , "mpls@ietf.org" Date: Thu, 3 Mar 2011 16:15:00 +0100 Thread-Topic: [mpls-tp] [mpls] MPLS WG last call on draft-ietf-mpls-tp-loss-delay-profile-02 Thread-Index: AcvY+f9mc1CwKjwyQZi6gRh6Jd8CdwAucl3A Message-ID: References: <000801cbd8f0$f3b272a0$4001a8c0@gateway.2wire.net> In-Reply-To: <000801cbd8f0$f3b272a0$4001a8c0@gateway.2wire.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [mpls] [mpls-tp] MPLS WG last call on draft-ietf-mpls-tp-loss-delay-profile-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 15:14:08 -0000 See below for a list of major and minor comments. Thanks, Marc -------------------------------------------- Major comments - Section 2.7.9 The draft specifies the 1588 (PTP) is the default and a MUST. While there i= s a good amount of hardware out there that supports 1588 but making this a = MUST means that older hardware that supports NTP and not 1588 would require= the carrier to upgrade their equipment for this. Shouldn't NTP be the default and a MUST, and 1588 PTP an option? - Comment #5: Proposed text as last sentence of sections 4.1.3, 4.1.4, 4.2.[1-3] In the case of an invalid message (e.g. request or response), an error repo= rt should be made, in a form a response message if the code =3D 0 or=20 1, or as an alarm report. Suggest rewording sentence in section 3.1: "0x2: No Response Requested. Indicates that no response to the query shoul= d be sent. This mode can be used when an NMS is controlling both nodes" - Section 3.4 After sentence "1: Sequence number. This value indicates that the timestam= p field is to be viewed as a simple 64-bit sequence number." Suggest adding sentence: The sequence number provides a simple solution for= applications that don't need a real absolute timestamp but just an indication of message ordering. An example is LM exception detection. - Section 3.5.1 Suggest adding sentence: "Asymetrical padding may be useful in the case of OOB response or when diff= erent MTUs are used in a bidir path" - Suggest deleting "which is usually what is desired." in section 4.1.10 - Section 4.1.9 Suggestion adding sentence "Separate test message protocol SHOULD include a= timeout value that informs the responder when to discard any state associa= ted with this test." Minor comments - Suggest adding sentence in section 1 "The direct method is also known as "frame-based" in [Y.1731]. The inferred= method is a superset of the "synthetic" approach being currently specified= within Ethernet documents, because it allows for the possiblity of decoupl= ing measurement messages from test messages" - editorial - Section 2.1, page 8, 3rd paragraph: change "response code" to= "response control code" =20 Editorial - Section 2.3, page 10, 7th paragraph: change "response code" to = "response control code" - Section 2.3 Clarify that clock synchronization is required for 2-way channel delay but = not for roundtrip delay - Fix consistency between 1588v1 and v2 references - Editorial - Section 3.5.3: In second paragraph, change "too low" to "too = short", and in last paragraph, change "Lower" to "Shorter". - Section 4.1.10: We can note that misorderings are rare in the absence of = ECMP. ----- Original Message ----- From: "Ross Callon" To: ; ; Sent: Monday, February 07, 2011 4:33 AM Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-loss-delay-profile-= 02 > Working Group, > > This is to start a four week working group last call on > "A Packet Loss and Delay Measurement Profile for MPLS-based > Transport Networks" > (draft-ietf-mpls-tp-loss-delay-profile-02.txt). > > Please send comments to the mpls-tp@ietf.org mailing list. > > Also, please note that the related document > "draft-ietf-mpls-loss-delay-01" is being last called in > parallel on the MPLS WG email list. > > This working group last call ends on Monday March 7, 2011. > > Ross, Loa, and George > > MPLS WG co-chairs > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From marc.lasserre@alcatel-lucent.com Thu Mar 3 07:29:23 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC29C28C0DE; Thu, 3 Mar 2011 07:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 nWnd+oxYfDGC; Thu, 3 Mar 2011 07:29:21 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 96FAF3A69F6; Thu, 3 Mar 2011 07:29:18 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p23FUJeQ009941 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Mar 2011 16:30:22 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 3 Mar 2011 16:30:06 +0100 From: "LASSERRE, MARC (MARC)" To: "LASSERRE, MARC (MARC)" , "mpls-tp@ietf.org" , "mpls@ietf.org" Date: Thu, 3 Mar 2011 16:30:04 +0100 Thread-Topic: [mpls-tp] [mpls] MPLS WG last call on draft-ietf-mpls-tp-loss-delay-profile-02 Thread-Index: AcvY+f9mc1CwKjwyQZi6gRh6Jd8CdwAucl3AAAD2uFA= Message-ID: References: <000801cbd8f0$f3b272a0$4001a8c0@gateway.2wire.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: Re: [mpls] [mpls-tp] MPLS WG last call on draft-ietf-mpls-tp-loss-delay-profile-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 15:29:23 -0000 See below for a list of major and minor comments. Thanks, Marc -------------------------------------------- - Add comment "ECMP/LDP/PHP considerations are not applicable to MPLS-TP" - Section 2: Suggest removing "This profile is restricted to direct-mode=20 LM and therefore uses the MPLS Direct Packet Loss Measurement (DLM) Channel= Type in the Associated Channel Header (ACH)." - It should be specified that the message rate for LM and DM packets should= be configurable from the operator on a MEP, separately for LM and DM. - Add following recommended intervals:=20 Recommended intervals for direct or inferred LM messages is: 100ms, 1s, 10s= , 1 min, 10 min=20 Recommended intervals for LM test messages is: 10ms, 100ms, 1s, 10s, 1 min Recommended intervals for DM messages is: 1s, 10s, 1 min, 10 min ----- Original Message ----- From: "Ross Callon" To: ; ; Sent: Monday, February 07, 2011 4:33 AM Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-loss-delay-profile-= 02 > Working Group, > > This is to start a four week working group last call on > "A Packet Loss and Delay Measurement Profile for MPLS-based > Transport Networks" > (draft-ietf-mpls-tp-loss-delay-profile-02.txt). > > Please send comments to the mpls-tp@ietf.org mailing list. > > Also, please note that the related document > "draft-ietf-mpls-loss-delay-01" is being last called in > parallel on the MPLS WG email list. > > This working group last call ends on Monday March 7, 2011. > > Ross, Loa, and George > > MPLS WG co-chairs > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ 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 From marc.lasserre@alcatel-lucent.com Thu Mar 3 07:31:37 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439493A67B1; Thu, 3 Mar 2011 07:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.582 X-Spam-Level: X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 n4JpjsHwD6An; Thu, 3 Mar 2011 07:31:36 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id CD3F03A6832; Thu, 3 Mar 2011 07:31:35 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p23FWKEp006606 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Mar 2011 16:32:42 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 3 Mar 2011 16:32:40 +0100 From: "LASSERRE, MARC (MARC)" To: "mpls-tp@ietf.org" , "mpls@ietf.org" Date: Thu, 3 Mar 2011 16:32:38 +0100 Thread-Topic: [mpls-tp] [mpls] MPLS WG last call on draft-ietf-mpls-loss-delay-01 Thread-Index: AcvY+f9mc1CwKjwyQZi6gRh6Jd8CdwAucl3AAAELNxA= Message-ID: References: <000801cbd8f0$f3b272a0$4001a8c0@gateway.2wire.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [mpls] [mpls-tp] MPLS WG last call on draft-ietf-mpls-loss-delay-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 15:31:37 -0000 Sorry, I'm posting the same message again with the right subject this time. See below for a list of major and minor comments. Thanks, Marc -------------------------------------------- Major comments - Section 2.7.9 The draft specifies the 1588 (PTP) is the default and a MUST. While there i= s a good amount of hardware out there that supports 1588 but making this a = MUST means that older hardware that supports NTP and not 1588 would require= the carrier to upgrade their equipment for this. Shouldn't NTP be the default and a MUST, and 1588 PTP an option? - Comment #5: Proposed text as last sentence of sections 4.1.3, 4.1.4, 4.2.[1-3] In the case of an invalid message (e.g. request or response), an error repo= rt should be made, in a form a response message if the code =3D 0 or=20 1, or as an alarm report. Suggest rewording sentence in section 3.1: "0x2: No Response Requested. Indicates that no response to the query shoul= d be sent. This mode can be used when an NMS is controlling both nodes" - Section 3.4 After sentence "1: Sequence number. This value indicates that the timestam= p field is to be viewed as a simple 64-bit sequence number." Suggest adding sentence: The sequence number provides a simple solution for= applications that don't need a real absolute timestamp but just an indication of message ordering. An example is LM exception detection. - Section 3.5.1 Suggest adding sentence: "Asymetrical padding may be useful in the case of OOB response or when diff= erent MTUs are used in a bidir path" - Suggest deleting "which is usually what is desired." in section 4.1.10 - Section 4.1.9 Suggestion adding sentence "Separate test message protocol SHOULD include a= timeout value that informs the responder when to discard any state associa= ted with this test." Minor comments - Suggest adding sentence in section 1 "The direct method is also known as "frame-based" in [Y.1731]. The inferred= method is a superset of the "synthetic" approach being currently specified= within Ethernet documents, because it allows for the possiblity of decoupl= ing measurement messages from test messages" - editorial - Section 2.1, page 8, 3rd paragraph: change "response code" to= "response control code" =20 Editorial - Section 2.3, page 10, 7th paragraph: change "response code" to = "response control code" - Section 2.3 Clarify that clock synchronization is required for 2-way channel delay but = not for roundtrip delay - Fix consistency between 1588v1 and v2 references - Editorial - Section 3.5.3: In second paragraph, change "too low" to "too = short", and in last paragraph, change "Lower" to "Shorter". - Section 4.1.10: We can note that misorderings are rare in the absence of = ECMP. From stbryant@cisco.com Thu Mar 3 08:05:34 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635113A6811; Thu, 3 Mar 2011 08:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.498 X-Spam-Level: X-Spam-Status: No, score=-110.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 11y5TWT9akPD; Thu, 3 Mar 2011 08:05:32 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 179A33A69A1; Thu, 3 Mar 2011 08:05:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=6344; q=dns/txt; s=iport; t=1299168400; x=1300378000; h=message-id:date:from:reply-to:mime-version:to:cc:subject; bh=zyM5wUpKmedNB/cNUAGaztmnQZWfgddGcGH4issiwYs=; b=jl289Ab20XXnNjpGEErxPIzJAAbVcKn5Ca0KAne+wXlLTP8/t3y14gVJ E/gJbmGvCLLijChFpTB7bX1m9iwFSb/jKN+bBZL7TVvbf+dYCPkzcUcOF xgB2T7/AM56bl+1l5dY4d7RBrx55vt1NPbGI+Bn5ni7Go/DZSCUpc/s+m Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIEAL9Kb02Q/khLgWdsb2JhbACiBYRgFQEBFiIlowGCZw4BmSqFYQSMLA X-IronPort-AV: E=Sophos;i="4.62,258,1297036800"; d="scan'208,217";a="20620376" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 03 Mar 2011 16:06:39 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p23G6cM7019968; Thu, 3 Mar 2011 16:06:39 GMT Received: from dhcp-64-103-102-164.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p23G6b805245; Thu, 3 Mar 2011 16:06:38 GMT Message-ID: <4D6FBC8C.50904@cisco.com> Date: Thu, 03 Mar 2011 16:06:36 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: multipart/alternative; boundary="------------060501010706040400050108" Cc: "tictoc@ietf.org" Subject: [mpls] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 16:05:34 -0000 This is a multi-part message in MIME format. --------------060501010706040400050108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We have received a LC comment on draft-ietf-mpls-loss-delay concerning the default timestamp. In the first version of the draft we proposed NTP, but following initial comments from the MPLS-TP community we changed to IEEE1588. This requirement for IEEE1588 can be traced back to the choice of using IEEE1588 in Y.1731. We have now received a LC request to change the default back to NTP. NTP is the "natural" choice for an IETF protocol. NTP is specified in IETF and is used in other MPLS protocols such as LSP ping. It is implemented on almost every host and every router. However in general the implementations provides a relatively low precision timestamp, and the NTP time distribution infrastructure operates on a best effort basis. Thus even a good client implementation would normally have a relatively low quality path to the server, which would result in a low quality of timestamp. NTP could be made to work to higher accuracy, but defacto upgrading NTP and providing high quality NTP paths to the time servers is not getting much attention. Computing timestamp differences is easier with NTP. On the other hand IEEE1588 has defacto become the two way time tranfer protocol for precision applications. IEEE1588 only provides high quality time in well engineered networks with some form of hop by hop assistance. It is not widely implemented other than in equipment targeted to specific markets, although one of those markets is in mobile backhaul applications where we expect to see significant initial deployment of MPLS-TP. Computing timestamp differences is harder with IEEE1588 The loss-delay work is targeting to be able to do one way packet delay measurement, so it does need a higher quality of timestamp than is required in general purpose network instrumentation. Converting from IEEE1588 to NTP is not trivial, since they use different epochs, and different representations of sub-second time. In a "traditional" NTP implementation the time error due to on the fly conversion is likely to be small compared to the time error in the time synchronization system, but an IEEE1588 system would need hardware conversion to maintain the accuracy for an NTP timestamp. So the question arises, should we make IEEE1588 or NTP the default for draft-ietf-mpls-loss-delay. Much as I would like to suggest that we should go back to NTP for consistency with other IETF protocols, I have difficulty reconciling this with the situation in network deployments and thus suggest that we continue to use IEEE1588. What is the opinion of the working group? Stewart (speaking as a draft editor) --------------060501010706040400050108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
We have received a LC comment on draft-ietf-mpls-loss-delay concerning the default timestamp.

In the first version of the draft we proposed NTP, but following initial comments from the MPLS-TP community we changed to IEEE1588. This requirement for IEEE1588 can be traced back to the choice of using IEEE1588 in Y.1731.

We have now received a LC request to change the default back to NTP.

NTP is the "natural" choice for an IETF protocol. NTP is specified in IETF and is used in other MPLS protocols such as LSP ping. It is implemented on almost every host and every router. However in general the implementations provides a relatively low precision timestamp, and the NTP time distribution infrastructure operates on a best effort basis. Thus even a good client implementation would normally have a relatively low quality path to the server, which would result in a low quality of timestamp. NTP could be made to work to higher accuracy, but defacto upgrading NTP and providing high quality NTP paths to the time servers is not getting much attention. Computing timestamp differences is easier with NTP.

On the other hand IEEE1588 has defacto become the two way time tranfer protocol for precision applications. IEEE1588 only provides high quality time in well engineered networks with some form of hop by hop assistance. It is not widely implemented other than in equipment targeted to specific markets, although one of those markets is in mobile backhaul applications  where we expect to see significant initial deployment of MPLS-TP. Computing timestamp differences is harder with IEEE1588

The loss-delay work is targeting to be able to do one way packet delay measurement, so it does need a higher quality of timestamp than is required in general purpose network instrumentation.

Converting from IEEE1588 to NTP is not trivial, since they use different epochs, and different representations of sub-second time. In a "traditional" NTP implementation the time error due to on the fly conversion is likely to be small compared to the time error in the time synchronization system, but an IEEE1588 system would need hardware conversion to maintain the accuracy for an NTP timestamp.

So the question arises, should we make IEEE1588 or NTP the default for draft-ietf-mpls-loss-delay. Much as I would like to suggest that we should go back to NTP for consistency with other IETF protocols, I have difficulty reconciling this with the situation in network deployments and thus suggest that we continue to use IEEE1588.

What is the opinion of the working group?

Stewart (speaking as a draft editor)

--------------060501010706040400050108-- From rcallon@juniper.net Thu Mar 3 09:30:15 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 741C43A6859; Thu, 3 Mar 2011 09:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 qrVxjdLOPKEx; Thu, 3 Mar 2011 09:30:11 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id DC3C83A6860; Thu, 3 Mar 2011 09:30:09 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTW/QZadd7mgTZ2HZupklHUEClRpKFyJ0@postini.com; Thu, 03 Mar 2011 09:31:18 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 3 Mar 2011 09:25:05 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 3 Mar 2011 12:25:52 -0500 From: Ross Callon To: "mpls@ietf.org" , "mpls-tp@ietf.org" Date: Thu, 3 Mar 2011 12:25:46 -0500 Thread-Topic: MPLS-TP work Thread-Index: AcvZyAh0gvCDZWtpRF6AUUuxVbfjlg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {7BA66296-9F09-4179-B57D-C49949F0B82F} x-cr-hashedpuzzle: AndF BcYY BlKS CgQ0 E2/y HPrQ IUQl JR00 LAmL MW34 NTCq Njf9 N1DE PCPb PzbI Wbim; 2; bQBwAGwAcwAtAHQAcABAAGkAZQB0AGYALgBvAHIAZwA7AG0AcABsAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {7BA66296-9F09-4179-B57D-C49949F0B82F}; cgBjAGEAbABsAG8AbgBAAGoAdQBuAGkAcABlAHIALgBuAGUAdAA=; Thu, 03 Mar 2011 17:25:46 GMT;TQBQAEwAUwAtAFQAUAAgAHcAbwByAGsA acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704A51230398BEMBX01WFjnprn_" MIME-Version: 1.0 Subject: [mpls] MPLS-TP work X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 17:30:15 -0000 --_000_DF7F294AF4153D498141CBEFADB17704A51230398BEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Several people have asked us what impact the recent activity in ITU-T SG15 will have on the MPLS-TP work in the MPLS WG. The effects on the MPLS working group is small, since we are very close to completing the first set of protocol specifications for MPLS based Transport Networks. The MPLS WG will continue work on the protocol specifications for MPLS based Transport Networks. This work will be done using normal IETF processes. George, Loa and Ross MPLS Working Group co-Chairs --_000_DF7F294AF4153D498141CBEFADB17704A51230398BEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
  Several people have asked us what impact the recent activity
  in ITU-T SG15 will have on the MPLS-TP work in the MPLS WG.
 
  The effects on the MPLS working group is small, since we are
  very close to completing the first set of protocol specificatio= ns
  for MPLS based Transport Networks.
 
  The MPLS WG will continue work on the protocol specifications
  for MPLS based Transport Networks. This work will be done using=
  normal IETF processes.
 
  George, Loa and Ross
  MPLS Working Group co-Chairs
 
 
 --_000_DF7F294AF4153D498141CBEFADB17704A51230398BEMBX01WFjnprn_-- From davari@broadcom.com Thu Mar 3 10:03:03 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F156028C0F1; Thu, 3 Mar 2011 10:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 3JHSSRH7+X0y; Thu, 3 Mar 2011 10:03:01 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id BE7113A6A02; Thu, 3 Mar 2011 10:03:01 -0800 (PST) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 03 Mar 2011 10:06:17 -0800 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Thu, 3 Mar 2011 10:03:56 -0800 From: "Shahram Davari" To: "stbryant@cisco.com" , "mpls@ietf.org" Date: Thu, 3 Mar 2011 10:03:54 -0800 Thread-Topic: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Thread-Index: AcvZvQG5UD8w+gNWTPGhD7ic5ow2KQAD+zuQ Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6956C122C58@SJEXCHCCR02.corp.ad.broadcom.com> References: <4D6FBC8C.50904@cisco.com> In-Reply-To: <4D6FBC8C.50904@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 617107133T8660902-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6956C122C58SJEXCHCCR02co_ Cc: "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 18:03:03 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6956C122C58SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Stewart, Accurate delay measurement requires the Timestamp to be done in HW. It is t= rue that most routers support NTP today, but the majority of those are real= ly maintained in Software and AFAIK most HW based timestamps implementation= s are 1588 based and really the industry is shifting toward 1588 and SyncE = for network synchronization. So I support 1588 as being the default. Thanks, Shahram From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Stewart Bryant Sent: Thursday, March 03, 2011 8:07 AM To: mpls@ietf.org Cc: tictoc@ietf.org Subject: [TICTOC] draft-ietf-mpls-loss-delay Timestamp We have received a LC comment on draft-ietf-mpls-loss-delay concerning the = default timestamp. In the first version of the draft we proposed NTP, but following initial co= mments from the MPLS-TP community we changed to IEEE1588. This requirement = for IEEE1588 can be traced back to the choice of using IEEE1588 in Y.1731. We have now received a LC request to change the default back to NTP. NTP is the "natural" choice for an IETF protocol. NTP is specified in IETF = and is used in other MPLS protocols such as LSP ping. It is implemented on = almost every host and every router. However in general the implementations = provides a relatively low precision timestamp, and the NTP time distributio= n infrastructure operates on a best effort basis. Thus even a good client i= mplementation would normally have a relatively low quality path to the serv= er, which would result in a low quality of timestamp. NTP could be made to = work to higher accuracy, but defacto upgrading NTP and providing high quali= ty NTP paths to the time servers is not getting much attention. Computing t= imestamp differences is easier with NTP. On the other hand IEEE1588 has defacto become the two way time tranfer prot= ocol for precision applications. IEEE1588 only provides high quality time i= n well engineered networks with some form of hop by hop assistance. It is n= ot widely implemented other than in equipment targeted to specific markets,= although one of those markets is in mobile backhaul applications where we= expect to see significant initial deployment of MPLS-TP. Computing timesta= mp differences is harder with IEEE1588 The loss-delay work is targeting to be able to do one way packet delay meas= urement, so it does need a higher quality of timestamp than is required in = general purpose network instrumentation. Converting from IEEE1588 to NTP is not trivial, since they use different ep= ochs, and different representations of sub-second time. In a "traditional" = NTP implementation the time error due to on the fly conversion is likely to= be small compared to the time error in the time synchronization system, bu= t an IEEE1588 system would need hardware conversion to maintain the accurac= y for an NTP timestamp. So the question arises, should we make IEEE1588 or NTP the default for draf= t-ietf-mpls-loss-delay. Much as I would like to suggest that we should go b= ack to NTP for consistency with other IETF protocols, I have difficulty rec= onciling this with the situation in network deployments and thus suggest th= at we continue to use IEEE1588. What is the opinion of the working group? Stewart (speaking as a draft editor) --_000_2C2F1EBA8050E74EA81502D5740B4BD6956C122C58SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

= Hi Stewart,

&n= bsp;

Accurate delay measurement= requires the Timestamp to be done in HW. It is true that most routers supp= ort NTP today, but the majority of those are really maintained in Software = and AFAIK most HW based timestamps implementations are 1588 based and reall= y the industry is shifting toward 1588 and SyncE for network synchronizatio= n. So I support 1588 as being the default.

 

Th= anks,

Shahram

 

From: tictoc-bounc= es@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Stewart Br= yant
Sent: Thursday, March 03, 2011 8:07 AM
To: mpls@ie= tf.org
Cc: tictoc@ietf.org
Subject: [TICTOC] draft-ietf= -mpls-loss-delay Timestamp

 


We have received a LC comment on draft-ietf-mpls-loss-delay concern= ing the default timestamp.

In the first version of the draft we prop= osed NTP, but following initial comments from the MPLS-TP community we chan= ged to IEEE1588. This requirement for IEEE1588 can be traced back to the ch= oice of using IEEE1588 in Y.1731.

We have now received a LC request = to change the default back to NTP.

NTP is the "natural" ch= oice for an IETF protocol. NTP is specified in IETF and is used in other MP= LS protocols such as LSP ping. It is implemented on almost every host and e= very router. However in general the implementations provides a relatively l= ow precision timestamp, and the NTP time distribution infrastructure operat= es on a best effort basis. Thus even a good client implementation would nor= mally have a relatively low quality path to the server, which would result = in a low quality of timestamp. NTP could be made to work to higher accuracy= , but defacto upgrading NTP and providing high quality NTP paths to the tim= e servers is not getting much attention. Computing timestamp differences is= easier with NTP.

On the other hand IEEE1588 has defacto become the = two way time tranfer protocol for precision applications. IEEE1588 only pro= vides high quality time in well engineered networks with some form of hop b= y hop assistance. It is not widely implemented other than in equipment targ= eted to specific markets, although one of those markets is in mobile backha= ul applications  where we expect to see significant initial deployment= of MPLS-TP. Computing timestamp differences is harder with IEEE1588
The loss-delay work is targeting to be able to do one way packet delay mea= surement, so it does need a higher quality of timestamp than is required in= general purpose network instrumentation.

Converting from IEEE1588 t= o NTP is not trivial, since they use different epochs, and different repres= entations of sub-second time. In a "traditional" NTP implementati= on the time error due to on the fly conversion is likely to be small compar= ed to the time error in the time synchronization system, but an IEEE1588 sy= stem would need hardware conversion to maintain the accuracy for an NTP tim= estamp.

So the question arises, should we make IEEE1588 or NTP the d= efault for draft-ietf-mpls-loss-delay. Much as I would like to suggest that= we should go back to NTP for consistency with other IETF protocols, I have= difficulty reconciling this with the situation in network deployments and = thus suggest that we continue to use IEEE1588.

What is the opinion o= f the working group?

Stewart (speaking as a draft editor)=

= --_000_2C2F1EBA8050E74EA81502D5740B4BD6956C122C58SJEXCHCCR02co_-- From Alexander.Vainshtein@ecitele.com Thu Mar 3 11:38:05 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1ABD3A6847; Thu, 3 Mar 2011 11:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 u0MHkV62iFCF; Thu, 3 Mar 2011 11:38:03 -0800 (PST) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id 2D5583A690F; Thu, 3 Mar 2011 11:38:01 -0800 (PST) X-AuditID: 93eaf2e8-b7c4aae000002fdd-20-4d6fee140a91 Received: from ILPTEXCH02.ecitele.com (ilptexfe.ecitele.com [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 8E.BA.12253.41EEF6D4; Thu, 3 Mar 2011 21:37:56 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 3 Mar 2011 21:39:07 +0200 From: Alexander Vainshtein To: Ron Cohen Date: Thu, 3 Mar 2011 21:35:42 +0200 Thread-Topic: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Thread-Index: AcvZ2D7kIL9pht5aRuSOpuYC1WzL+gAAfA9q Message-ID: References: <2C2F1EBA8050E74EA81502D5740B4BD6956C122C58@SJEXCHCCR02.corp.ad.broadcom.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAA2ILPTMAIL02eci_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUy+dXXrboi7/J9DWZv5bO4tXQlq8X5u5vZ LPY9amW0OL/lPqPF3+YedgdWj52z7rJ7LFnyk8njw6MdLAHMUVw2Kak5mWWpRfp2CVwZ/6/M Yy443MFY0dUygbWB8URBFyMnh4SAicS0T79YIWwxiQv31rN1MXJxCAmcZ5S4tH0HE4QzlVHi 1Ke5bCBVbAK2EptW3wWzRQRUJHZ3HmEFKWIW2MAosfPrS0aQBAtQYumfA2BjhQWsJJZ8fArV YC3xfM8bKNtIYtniY8xdjBwcvAL+Eu8O10Mse8QosfvqA3aQGk4Bb4k7hw6B1TMCnff91Bom EJtZQFzi1pP5TBBnC0gs2XOeGcIWlXj5+B8rRL2oxJ329YwQ9fkSry/3gsV5BQQlTs58wjKB UXQWklGzkJTNQlK2gJF5FaNoZk5BSVJuuoGRXmpyZklqTqpecn7uJkZw9Hx6sYNxwmadQ4xM HJxSDYzdW7Z+mvrqNNfc23OPcMxhFZd89V8pZZ1n69d25U71t1eifW6Wah7V1M5lW7Ds+XeO wKzCn++vv3x4zJw9/bgep992zy0lR8LCHnGVLf0bL+hhIrZ3it6kF0JM7z/IzpXIKdUpzdea 9yPq38/0DqMk2RnLpmx5+HqjCsuq6aorjU9+8lZ3/xyrxFKckWioxVxUnAgAxAfZL04CAAA= Cc: "mpls@ietf.org" , "PDiamond@semtech.com" , "tictoc-bounces@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 19:38:05 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAA2ILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ron, Lots of thanks for the important input. I am somewhat less worried about the forthcoming rollover of NTP timestamps= in 25 years from now. (Reminds me of Bug 2000:-). But leap seconds represe= nt a serious technical point that cannot be ignored IMHO. My 2c, Sasha ________________________________ From: tictoc-bounces@ietf.org [tictoc-bounces@ietf.org] On Behalf Of Ron Co= hen [ronc.ntear@gmail.com] Sent: Thursday, March 03, 2011 9:21 PM To: PDiamond@semtech.com Cc: mpls@ietf.org; tictoc-bounces@ietf.org; tictoc@ietf.org Subject: Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Hi, I apologize in advance if my comments below where already been discussed. The draft specify using PTPv1 timestamp format and not PTPv2 timestamp form= at. The seconds part of the PTPv2 timestamp is 48bits, and not 32bits as wr= itten in the draft. NTP timestamps will roll over in 2036. PTPv2 timestamps= do not rollover. I don't think its advisable to include timestamps that rolls over ~20 years= from now. In addition, NTP timestamp, unlike PTP timestamp, 'jumps' in leap seconds e= vents. This makes calculation of time differences hard, and would render so= me measurements ambiguous. It is much easier to use continuous timescale li= ke PTP. In my opinion changing the timestamp format to PTPv2 timestamp format (i.e.= 48bit/32bit sec/ns) should be the right way to go. I would also remove the= NTP timestamp format option to avoid leap seconds confusion and 2036 rollo= ver events. Best, Ron On Thu, Mar 3, 2011 at 8:26 PM, > wrote: My feeling is 1588 is the right answer in the long run since it is already coupled to the hardware and widely deployed in networks using the "packet clock derived time" in precise time and frequency delivery. Pat "Shahram Davari" To Sent by: "stbryant@cisco.com" tictoc-bounces@ie >, tf.org "mpls@ietf.org" > cc "tictoc@ietf.org" > 03/03/2011 10:05 Subject AM Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Hi Stewart, Accurate delay measurement requires the Timestamp to be done in HW. It is true that most routers support NTP today, but the majority of those are really maintained in Software and AFAIK most HW based timestamps implementations are 1588 based and really the industry is shifting toward 1588 and SyncE for network synchronization. So I support 1588 as being the default. Thanks, Shahram From: tictoc-bounces@ietf.org [mailto:ticto= c-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Thursday, March 03, 2011 8:07 AM To: mpls@ietf.org Cc: tictoc@ietf.org Subject: [TICTOC] draft-ietf-mpls-loss-delay Timestamp We have received a LC comment on draft-ietf-mpls-loss-delay concerning the default timestamp. In the first version of the draft we proposed NTP, but following initial comments from the MPLS-TP community we changed to IEEE1588. This requirement for IEEE1588 can be traced back to the choice of using IEEE1588 in Y.1731. We have now received a LC request to change the default back to NTP. NTP is the "natural" choice for an IETF protocol. NTP is specified in IETF and is used in other MPLS protocols such as LSP ping. It is implemented on almost every host and every router. However in general the implementations provides a relatively low precision timestamp, and the NTP time distribution infrastructure operates on a best effort basis. Thus even a good client implementation would normally have a relatively low quality path to the server, which would result in a low quality of timestamp. NTP could be made to work to higher accuracy, but defacto upgrading NTP and providing high quality NTP paths to the time servers is not getting much attention. Computing timestamp differences is easier with NTP. On the other hand IEEE1588 has defacto become the two way time tranfer protocol for precision applications. IEEE1588 only provides high quality time in well engineered networks with some form of hop by hop assistance. It is not widely implemented other than in equipment targeted to specific markets, although one of those markets is in mobile backhaul applications where we expect to see significant initial deployment of MPLS-TP. Computing timestamp differences is harder with IEEE1588 The loss-delay work is targeting to be able to do one way packet delay measurement, so it does need a higher quality of timestamp than is required in general purpose network instrumentation. Converting from IEEE1588 to NTP is not trivial, since they use different epochs, and different representations of sub-second time. In a "traditional" NTP implementation the time error due to on the fly conversion is likely to be small compared to the time error in the time synchronization system, but an IEEE1588 system would need hardware conversion to maintain the accuracy for an NTP timestamp. So the question arises, should we make IEEE1588 or NTP the default for draft-ietf-mpls-loss-delay. Much as I would like to suggest that we should go back to NTP for consistency with other IETF protocols, I have difficulty reconciling this with the situation in network deployments and thus suggest that we continue to use IEEE1588. What is the opinion of the working group? Stewart (speaking as a draft editor) _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAA2ILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ron,
Lots of thanks for the important input.=
 
I am somewhat less worried&= nbsp;about the forthcoming rollover of NTP t= imestamps in 25 years from now. (Reminds me of Bug 2000:-). But leap second= s represent a serious technical point that cannot be ignored IMHO.
 
My 2c,
     Sasha
From: tictoc-boun= ces@ietf.org [tictoc-bounces@ietf.org] On Behalf Of Ron Cohen [ronc.ntear@g= mail.com]
Sent: Thursday, March 03, 2011 9:21 PM
To: PDiamond@semtech.com
Cc: mpls@ietf.org; tictoc-bounces@ietf.org; tictoc@ietf.org
Subject: Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp

Hi,

I apologize in advance if my comments below where already been discussed.
The draft specify using PTPv1 timestamp format and not PTPv2 timestamp form= at. The seconds part of the PTPv2 timestamp is 48bits, and not 32bits as wr= itten in the draft. NTP timestamps will roll over in 2036. PTPv2 timestamps= do not rollover.

I don't think its advisable to include timestamps that rolls over ~20 years= from now.

In addition, NTP timestamp, unlike PTP timestamp, 'jumps' in leap seconds e= vents. This makes calculation of time differences hard, and would render so= me measurements ambiguous. It is much easier to use continuous timescale li= ke PTP.

In my opinion changing the timestamp format to PTPv2 timestamp format (i.e.= 48bit/32bit sec/ns) should be the right way to go. I would also remove the= NTP timestamp format option to avoid leap seconds confusion and 2036 rollo= ver events.

Best,
Ron


On Thu, Mar 3, 2011 at 8:26 PM, <PDiamond@semtech.com><= /span> wrote:
My feeling is 1588 is the right answer in the long run since it is already<= br> coupled to the hardware and widely deployed in networks using the "pac= ket
clock derived time" in precise time and frequency delivery.

Pat



            "Shahram Davari"
            <davari@broadcom.
            com>       &nbs= p;                     &n= bsp;                     =     To
            Sent by:       &nb= sp;          "stbryant@cisco.com"
            tictoc-bounces@ie     &= nbsp;   <stbryant@cisco.com>,
            tf.org               &nb= sp;    "mpls@ietf.org&q= uot; <mpls@ietf.org>
                     = ;                     &nb= sp;                     &= nbsp;      cc
                     = ;                 "tictoc@ietf.org" <tictoc@ietf.org>
            03/03/2011 10:05     &n= bsp;                     =            Subject
            AM         &n= bsp;              Re: [TICTOC]
                &= nbsp;                    = draft-ietf-mpls-loss-delay
                     = ;                 Timestamp










Hi Stewart,

Accurate delay measurement requires the Timestamp to be done in HW. It is true that most routers support NTP today, but the majority of those are
really maintained in Software and AFAIK most HW based timestamps
implementations are 1588 based and really the industry is shifting toward 1588 and SyncE for network synchronization. So I support 1588 as being the<= br> default.

Thanks,
Shahram

From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.or= g] On Behalf Of
Stewart Bryant
Sent: Thursday, March 03, 2011 8:07 AM
To: mpls@ietf.org
Cc: tictoc@ietf.org
Subject: [TICTOC] draft-ietf-mpls-loss-delay Timestamp


We have received a LC comment on draft-ietf-mpls-loss-delay concerning the<= br> default timestamp.

In the first version of the draft we proposed NTP, but following initial comments from the MPLS-TP community we changed to IEEE1588. This
requirement for IEEE1588 can be traced back to the choice of using IEEE1588=
in Y.1731.

We have now received a LC request to change the default back to NTP.

NTP is the "natural" choice for an IETF protocol. NTP is specifie= d in IETF
and is used in other MPLS protocols such as LSP ping. It is implemented on<= br> almost every host and every router. However in general the implementations<= br> provides a relatively low precision timestamp, and the NTP time
distribution infrastructure operates on a best effort basis. Thus even a good client implementation would normally have a relatively low quality
path to the server, which would result in a low quality of timestamp. NTP could be made to work to higher accuracy, but defacto upgrading NTP and
providing high quality NTP paths to the time servers is not getting much attention. Computing timestamp differences is easier with NTP.

On the other hand IEEE1588 has defacto become the two way time tranfer
protocol for precision applications. IEEE1588 only provides high quality time in well engineered networks with some form of hop by hop assistance. It is not widely implemented other than in equipment targeted to specific markets, although one of those markets is in mobile backhaul applications where we expect to see significant initial deployment of MPLS-TP. Computing=
timestamp differences is harder with IEEE1588

The loss-delay work is targeting to be able to do one way packet delay
measurement, so it does need a higher quality of timestamp than is required=
in general purpose network instrumentation.

Converting from IEEE1588 to NTP is not trivial, since they use different epochs, and different representations of sub-second time. In a
"traditional" NTP implementation the time error due to on the fly=
conversion is likely to be small compared to the time error in the time
synchronization system, but an IEEE1588 system would need hardware
conversion to maintain the accuracy for an NTP timestamp.

So the question arises, should we make IEEE1588 or NTP the default for
draft-ietf-mpls-loss-delay. Much as I would like to suggest that we should<= br> go back to NTP for consistency with other IETF protocols, I have difficulty=
reconciling this with the situation in network deployments and thus suggest=
that we continue to use IEEE1588.

What is the opinion of the working group?

Stewart (speaking as a draft editor)
_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
= https://www.ietf.org/mailman/listinfo/tictoc


_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
= https://www.ietf.org/mailman/listinfo/tictoc

--_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAA2ILPTMAIL02eci_-- From davari@broadcom.com Thu Mar 3 11:44:22 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7583A6844; Thu, 3 Mar 2011 11:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 wqv6ozP2mVGS; Thu, 3 Mar 2011 11:44:13 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 8EF443A685B; Thu, 3 Mar 2011 11:44:13 -0800 (PST) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 03 Mar 2011 11:47:26 -0800 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 3 Mar 2011 11:45:06 -0800 From: "Shahram Davari" To: "Ron Cohen" , "PDiamond@semtech.com" Date: Thu, 3 Mar 2011 11:45:03 -0800 Thread-Topic: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Thread-Index: AcvZ2D9QCten0mHHQLaLyZ1c9flbBQAAswbA Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6956C29995E@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6956C122C58@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 61712FCD3EW1167365-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6956C29995ESJEXCHCCR02co_ Cc: "mpls@ietf.org" , "tictoc-bounces@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 19:44:22 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6956C29995ESJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Ron, Although the PTPv2 is 80 bytes, but I don't see a need to use all 80 bytes = for delay measurement. The upper 2^32 seconds covers almost 136 years, whic= h should be good enough to measure delay. Also lets' be compatible with Y.1= 731 format since that HW already exist. Thx Shahram From: Ron Cohen [mailto:ronc.ntear@gmail.com] Sent: Thursday, March 03, 2011 11:22 AM To: PDiamond@semtech.com Cc: Shahram Davari; mpls@ietf.org; tictoc-bounces@ietf.org; tictoc@ietf.org Subject: Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Hi, I apologize in advance if my comments below where already been discussed. The draft specify using PTPv1 timestamp format and not PTPv2 timestamp form= at. The seconds part of the PTPv2 timestamp is 48bits, and not 32bits as wr= itten in the draft. NTP timestamps will roll over in 2036. PTPv2 timestamps= do not rollover. I don't think its advisable to include timestamps that rolls over ~20 years= from now. In addition, NTP timestamp, unlike PTP timestamp, 'jumps' in leap seconds e= vents. This makes calculation of time differences hard, and would render so= me measurements ambiguous. It is much easier to use continuous timescale li= ke PTP. In my opinion changing the timestamp format to PTPv2 timestamp format (i.e.= 48bit/32bit sec/ns) should be the right way to go. I would also remove the= NTP timestamp format option to avoid leap seconds confusion and 2036 rollo= ver events. Best, Ron On Thu, Mar 3, 2011 at 8:26 PM, > wrote: My feeling is 1588 is the right answer in the long run since it is already coupled to the hardware and widely deployed in networks using the "packet clock derived time" in precise time and frequency delivery. Pat "Shahram Davari" To Sent by: "stbryant@cisco.com" tictoc-bounces@ie >, tf.org "mpls@ietf.org" > cc "tictoc@ietf.org" > 03/03/2011 10:05 Subject AM Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Hi Stewart, Accurate delay measurement requires the Timestamp to be done in HW. It is true that most routers support NTP today, but the majority of those are really maintained in Software and AFAIK most HW based timestamps implementations are 1588 based and really the industry is shifting toward 1588 and SyncE for network synchronization. So I support 1588 as being the default. Thanks, Shahram From: tictoc-bounces@ietf.org [mailto:ticto= c-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Thursday, March 03, 2011 8:07 AM To: mpls@ietf.org Cc: tictoc@ietf.org Subject: [TICTOC] draft-ietf-mpls-loss-delay Timestamp We have received a LC comment on draft-ietf-mpls-loss-delay concerning the default timestamp. In the first version of the draft we proposed NTP, but following initial comments from the MPLS-TP community we changed to IEEE1588. This requirement for IEEE1588 can be traced back to the choice of using IEEE1588 in Y.1731. We have now received a LC request to change the default back to NTP. NTP is the "natural" choice for an IETF protocol. NTP is specified in IETF and is used in other MPLS protocols such as LSP ping. It is implemented on almost every host and every router. However in general the implementations provides a relatively low precision timestamp, and the NTP time distribution infrastructure operates on a best effort basis. Thus even a good client implementation would normally have a relatively low quality path to the server, which would result in a low quality of timestamp. NTP could be made to work to higher accuracy, but defacto upgrading NTP and providing high quality NTP paths to the time servers is not getting much attention. Computing timestamp differences is easier with NTP. On the other hand IEEE1588 has defacto become the two way time tranfer protocol for precision applications. IEEE1588 only provides high quality time in well engineered networks with some form of hop by hop assistance. It is not widely implemented other than in equipment targeted to specific markets, although one of those markets is in mobile backhaul applications where we expect to see significant initial deployment of MPLS-TP. Computing timestamp differences is harder with IEEE1588 The loss-delay work is targeting to be able to do one way packet delay measurement, so it does need a higher quality of timestamp than is required in general purpose network instrumentation. Converting from IEEE1588 to NTP is not trivial, since they use different epochs, and different representations of sub-second time. In a "traditional" NTP implementation the time error due to on the fly conversion is likely to be small compared to the time error in the time synchronization system, but an IEEE1588 system would need hardware conversion to maintain the accuracy for an NTP timestamp. So the question arises, should we make IEEE1588 or NTP the default for draft-ietf-mpls-loss-delay. Much as I would like to suggest that we should go back to NTP for consistency with other IETF protocols, I have difficulty reconciling this with the situation in network deployments and thus suggest that we continue to use IEEE1588. What is the opinion of the working group? Stewart (speaking as a draft editor) _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc --_000_2C2F1EBA8050E74EA81502D5740B4BD6956C29995ESJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi Ron,

 

Although the PTPv2 is 80 bytes, but I don̵= 7;t see a need to use all 80 bytes for delay measurement. The upper 2^32 se= conds covers almost 136 years, which should be good enough to measure delay= . Also lets’ be compatible with Y.1731 format since that HW already e= xist.

 

Thx

Shahram

 

From: Ron Cohen [mailto= :ronc.ntear@gmail.com]
Sent: Thursday, March 03, 2011 11:22 AMTo: PDiamond@semtech.com
Cc: Shahram Davari; mpls@ietf.o= rg; tictoc-bounces@ietf.org; tictoc@ietf.org
Subject: Re: [TICTOC= ] draft-ietf-mpls-loss-delay Timestamp

 

Hi,

I apologize in advance if my comments below wher= e already been discussed.

The draft specify using PTPv1 timestamp fo= rmat and not PTPv2 timestamp format. The seconds part of the PTPv2 timestam= p is 48bits, and not 32bits as written in the draft. NTP timestamps will ro= ll over in 2036. PTPv2 timestamps do not rollover.

I don't think its= advisable to include timestamps that rolls over ~20 years from now.
In addition, NTP timestamp, unlike PTP timestamp, 'jumps' in leap seconds= events. This makes calculation of time differences hard, and would render = some measurements ambiguous. It is much easier to use continuous timescale = like PTP.

In my opinion changing the timestamp format to PTPv2 times= tamp format (i.e. 48bit/32bit sec/ns) should be the right way to go. I woul= d also remove the NTP timestamp format option to avoid leap seconds confusi= on and 2036 rollover events.

Best,
Ron

On Thu, Mar 3, 2011 at 8:26 PM, <PDiamond@semtech.com> wrote:

<= p class=3DMsoNormal>My feeling is 1588 is the right answer in the long run = since it is already
coupled to the hardware and widely deployed in netwo= rks using the "packet
clock derived time" in precise time and = frequency delivery.

Pat



        &= nbsp;   "Shahram Davari"
        &nbs= p;   <davari@broadcom.
           = com>                   &nb= sp;                     &= nbsp;             To
      =       Sent by:             &nb= sp;    "stbryant@cisco= .com"
            tictoc-bounces@= ie         <st= bryant@cisco.com>,
            tf.org       &nb= sp;            "mpls@ietf.org" <mpls@= ietf.org>
               =                     &nbs= p;                     &n= bsp;            cc
      &n= bsp;                     =           "tictoc@ietf.org" <tictoc@ie= tf.org>
            03/03/2011 10:0= 5                     &nb= sp;                Subject
 = ;           AM           =              Re: [TICTOC]

=

            &n= bsp;                     =     draft-ietf-mpls-loss-delay
        &nb= sp;                     &= nbsp;       Timestamp









Hi Stewart,

Accurate delay measurement requires the Timestamp t= o be done in HW. It is
true that most routers support NTP today, but the= majority of those are
really maintained in Software and AFAIK most HW b= ased timestamps
implementations are 1588 based and really the industry i= s shifting toward
1588 and SyncE for network synchronization. So I suppo= rt 1588 as being the
default.

Thanks,
Shahram

From: tictoc-bounces@ietf.org [mailto= :tictoc-bounces@ietf.org] On= Behalf Of
Stewart Bryant
Sent: Thursday, March 03, 2011 8:07 AM
T= o: mpls@ietf.org
Cc: tictoc@ietf.org
Subject: [TICTOC] draft-ietf-mp= ls-loss-delay Timestamp


We have received a LC comment on draft-i= etf-mpls-loss-delay concerning the
default timestamp.

In the firs= t version of the draft we proposed NTP, but following initial
comments f= rom the MPLS-TP community we changed to IEEE1588. This
requirement for I= EEE1588 can be traced back to the choice of using IEEE1588
in Y.1731.
We have now received a LC request to change the default back to NTP.
NTP is the "natural" choice for an IETF protocol. NTP is sp= ecified in IETF
and is used in other MPLS protocols such as LSP ping. It= is implemented on
almost every host and every router. However in genera= l the implementations
provides a relatively low precision timestamp, and= the NTP time
distribution infrastructure operates on a best effort basi= s. Thus even a
good client implementation would normally have a relative= ly low quality
path to the server, which would result in a low quality o= f timestamp. NTP
could be made to work to higher accuracy, but defacto u= pgrading NTP and
providing high quality NTP paths to the time servers is= not getting much
attention. Computing timestamp differences is easier w= ith NTP.

On the other hand IEEE1588 has defacto become the two way t= ime tranfer
protocol for precision applications. IEEE1588 only provides = high quality
time in well engineered networks with some form of hop by h= op assistance.
It is not widely implemented other than in equipment targ= eted to specific
markets, although one of those markets is in mobile bac= khaul applications
where we expect to see significant initial deployment= of MPLS-TP. Computing
timestamp differences is harder with IEEE1588
=
The loss-delay work is targeting to be able to do one way packet delay<= br>measurement, so it does need a higher quality of timestamp than is requi= red
in general purpose network instrumentation.

Converting from I= EEE1588 to NTP is not trivial, since they use different
epochs, and diff= erent representations of sub-second time. In a
"traditional" N= TP implementation the time error due to on the fly
conversion is likely = to be small compared to the time error in the time
synchronization syste= m, but an IEEE1588 system would need hardware
conversion to maintain the= accuracy for an NTP timestamp.

So the question arises, should we ma= ke IEEE1588 or NTP the default for
draft-ietf-mpls-loss-delay. Much as I= would like to suggest that we should
go back to NTP for consistency wit= h other IETF protocols, I have difficulty
reconciling this with the situ= ation in network deployments and thus suggest
that we continue to use IE= EE1588.

What is the opinion of the working group?

Stewart (sp= eaking as a draft editor)

__= _____________________________________________
TICTOC mailing list
TICTOC@ietf.org
https://www.ietf.org= /mailman/listinfo/tictoc


___________________________________= ____________
TICTOC mailing list
T= ICTOC@ietf.org
https://www.ietf.org/mailman/listinfo/tictoc=

 

= --_000_2C2F1EBA8050E74EA81502D5740B4BD6956C29995ESJEXCHCCR02co_-- From davari@broadcom.com Thu Mar 3 11:54:12 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85F623A69FA; Thu, 3 Mar 2011 11:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 dkQEG9gaW6C9; Thu, 3 Mar 2011 11:54:05 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 832B53A690F; Thu, 3 Mar 2011 11:54:05 -0800 (PST) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 03 Mar 2011 11:57:12 -0800 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 3 Mar 2011 11:54:59 -0800 From: "Shahram Davari" To: "Ron Cohen" , "PDiamond@semtech.com" Date: Thu, 3 Mar 2011 11:54:57 -0800 Thread-Topic: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Thread-Index: AcvZ2D9QCten0mHHQLaLyZ1c9flbBQAAswbAAABvjVA= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6956C29997D@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6956C122C58@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD6956C29995E@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6956C29995E@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 61712D123EW1172496-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6956C29997DSJEXCHCCR02co_ Cc: "mpls@ietf.org" , "tictoc-bounces@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 19:54:12 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6956C29997DSJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Ron, Sorry. I meant 80 bits (not bytes). Thx Shahram From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sha= hram Davari Sent: Thursday, March 03, 2011 11:45 AM To: Ron Cohen; PDiamond@semtech.com Cc: mpls@ietf.org; tictoc-bounces@ietf.org; tictoc@ietf.org Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp Hi Ron, Although the PTPv2 is 80 bytes, but I don't see a need to use all 80 bytes = for delay measurement. The upper 2^32 seconds covers almost 136 years, whic= h should be good enough to measure delay. Also lets' be compatible with Y.1= 731 format since that HW already exist. Thx Shahram From: Ron Cohen [mailto:ronc.ntear@gmail.com] Sent: Thursday, March 03, 2011 11:22 AM To: PDiamond@semtech.com Cc: Shahram Davari; mpls@ietf.org; tictoc-bounces@ietf.org; tictoc@ietf.org Subject: Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Hi, I apologize in advance if my comments below where already been discussed. The draft specify using PTPv1 timestamp format and not PTPv2 timestamp form= at. The seconds part of the PTPv2 timestamp is 48bits, and not 32bits as wr= itten in the draft. NTP timestamps will roll over in 2036. PTPv2 timestamps= do not rollover. I don't think its advisable to include timestamps that rolls over ~20 years= from now. In addition, NTP timestamp, unlike PTP timestamp, 'jumps' in leap seconds e= vents. This makes calculation of time differences hard, and would render so= me measurements ambiguous. It is much easier to use continuous timescale li= ke PTP. In my opinion changing the timestamp format to PTPv2 timestamp format (i.e.= 48bit/32bit sec/ns) should be the right way to go. I would also remove the= NTP timestamp format option to avoid leap seconds confusion and 2036 rollo= ver events. Best, Ron On Thu, Mar 3, 2011 at 8:26 PM, > wrote: My feeling is 1588 is the right answer in the long run since it is already coupled to the hardware and widely deployed in networks using the "packet clock derived time" in precise time and frequency delivery. Pat "Shahram Davari" To Sent by: "stbryant@cisco.com" tictoc-bounces@ie >, tf.org "mpls@ietf.org" > cc "tictoc@ietf.org" > 03/03/2011 10:05 Subject AM Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Hi Stewart, Accurate delay measurement requires the Timestamp to be done in HW. It is true that most routers support NTP today, but the majority of those are really maintained in Software and AFAIK most HW based timestamps implementations are 1588 based and really the industry is shifting toward 1588 and SyncE for network synchronization. So I support 1588 as being the default. Thanks, Shahram From: tictoc-bounces@ietf.org [mailto:ticto= c-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Thursday, March 03, 2011 8:07 AM To: mpls@ietf.org Cc: tictoc@ietf.org Subject: [TICTOC] draft-ietf-mpls-loss-delay Timestamp We have received a LC comment on draft-ietf-mpls-loss-delay concerning the default timestamp. In the first version of the draft we proposed NTP, but following initial comments from the MPLS-TP community we changed to IEEE1588. This requirement for IEEE1588 can be traced back to the choice of using IEEE1588 in Y.1731. We have now received a LC request to change the default back to NTP. NTP is the "natural" choice for an IETF protocol. NTP is specified in IETF and is used in other MPLS protocols such as LSP ping. It is implemented on almost every host and every router. However in general the implementations provides a relatively low precision timestamp, and the NTP time distribution infrastructure operates on a best effort basis. Thus even a good client implementation would normally have a relatively low quality path to the server, which would result in a low quality of timestamp. NTP could be made to work to higher accuracy, but defacto upgrading NTP and providing high quality NTP paths to the time servers is not getting much attention. Computing timestamp differences is easier with NTP. On the other hand IEEE1588 has defacto become the two way time tranfer protocol for precision applications. IEEE1588 only provides high quality time in well engineered networks with some form of hop by hop assistance. It is not widely implemented other than in equipment targeted to specific markets, although one of those markets is in mobile backhaul applications where we expect to see significant initial deployment of MPLS-TP. Computing timestamp differences is harder with IEEE1588 The loss-delay work is targeting to be able to do one way packet delay measurement, so it does need a higher quality of timestamp than is required in general purpose network instrumentation. Converting from IEEE1588 to NTP is not trivial, since they use different epochs, and different representations of sub-second time. In a "traditional" NTP implementation the time error due to on the fly conversion is likely to be small compared to the time error in the time synchronization system, but an IEEE1588 system would need hardware conversion to maintain the accuracy for an NTP timestamp. So the question arises, should we make IEEE1588 or NTP the default for draft-ietf-mpls-loss-delay. Much as I would like to suggest that we should go back to NTP for consistency with other IETF protocols, I have difficulty reconciling this with the situation in network deployments and thus suggest that we continue to use IEEE1588. What is the opinion of the working group? Stewart (speaking as a draft editor) _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc --_000_2C2F1EBA8050E74EA81502D5740B4BD6956C29997DSJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Ron,=

 

Sorry. I meant 80 bits (not bytes).

 

Thx
Shahram

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

From: mp= ls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Shah= ram Davari
Sent: Thursday, March 03, 2011 11:45 AM
To: = Ron Cohen; PDiamond@semtech.com
Cc: mpls@ietf.org; tictoc-bounces= @ietf.org; tictoc@ietf.org
Subject: Re: [mpls] [TICTOC] draft-iet= f-mpls-loss-delay Timestamp

 

Hi Ron,<= /span>

 

Although the PTPv2 is 80 bytes, but I don’t see a= need to use all 80 bytes for delay measurement. The upper 2^32 seconds cov= ers almost 136 years, which should be good enough to measure delay. Also le= ts’ be compatible with Y.1731 format since that HW already exist.

 

<= p class=3DMsoNormal>Thx

Shahram

 

From: Ron Cohen [mailto:ronc.nte= ar@gmail.com]
Sent: Thursday, March 03, 2011 11:22 AM
To:<= /b> PDiamond@semtech.com
Cc: Shahram Davari; mpls@ietf.org; ticto= c-bounces@ietf.org; tictoc@ietf.org
Subject: Re: [TICTOC] draft-i= etf-mpls-loss-delay Timestamp

 

Hi,

I apologize in advance if my comments below where already = been discussed.

The draft specify using PTPv1 timestamp format and n= ot PTPv2 timestamp format. The seconds part of the PTPv2 timestamp is 48bit= s, and not 32bits as written in the draft. NTP timestamps will roll over in= 2036. PTPv2 timestamps do not rollover.

I don't think its advisable= to include timestamps that rolls over ~20 years from now.

In addit= ion, NTP timestamp, unlike PTP timestamp, 'jumps' in leap seconds events. T= his makes calculation of time differences hard, and would render some measu= rements ambiguous. It is much easier to use continuous timescale like PTP.<= br>
In my opinion changing the timestamp format to PTPv2 timestamp forma= t (i.e. 48bit/32bit sec/ns) should be the right way to go. I would also rem= ove the NTP timestamp format option to avoid leap seconds confusion and 203= 6 rollover events.

Best,
Ron

On Thu, Mar 3, 2011 at 8:26 PM, <PDiamond@semtech.com> wrote:

My feeling is 1588 is the right answer in the long run since it is alread= y
coupled to the hardware and widely deployed in networks using the &quo= t;packet
clock derived time" in precise time and frequency delivery= .

Pat



            "= ;Shahram Davari"
            <dava= ri@broadcom.
            com>   &n= bsp;                     =                      = ;         To
          &nbs= p; Sent by:                  &= quot;stbryant@cisco.com"
=             tictoc-bounces@ie     &= nbsp;   <stbryant@cisco.com>,
            tf.org             =        "mpls@ietf= .org" <mpls@ietf.org>                    &nb= sp;                     &= nbsp;                    =        cc
           =                     &nbs= p;     "tictoc@ietf.org" <tictoc@ietf.org>
=             03/03/2011 10:05     &n= bsp;                     =            Subject
      &n= bsp;     AM               &nbs= p;        Re: [TICTOC]

                 =                     draf= t-ietf-mpls-loss-delay
              =                      = ;   Timestamp










Hi Stewart,
Accurate delay measurement requires the Timestamp to be done in HW. I= t is
true that most routers support NTP today, but the majority of those= are
really maintained in Software and AFAIK most HW based timestampsimplementations are 1588 based and really the industry is shifting toward<= br>1588 and SyncE for network synchronization. So I support 1588 as being t= he
default.

Thanks,
Shahram

From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of
Stew= art Bryant
Sent: Thursday, March 03, 2011 8:07 AM
To: mpls@ietf.org
Cc: tictoc@ietf.org
Subject: [TICTOC] draft-ietf-mpls-loss-delay Time= stamp


We have received a LC comment on draft-ietf-mpls-loss-dela= y concerning the
default timestamp.

In the first version of the d= raft we proposed NTP, but following initial
comments from the MPLS-TP co= mmunity we changed to IEEE1588. This
requirement for IEEE1588 can be tra= ced back to the choice of using IEEE1588
in Y.1731.

We have now r= eceived a LC request to change the default back to NTP.

NTP is the &= quot;natural" choice for an IETF protocol. NTP is specified in IETFand is used in other MPLS protocols such as LSP ping. It is implemented on=
almost every host and every router. However in general the implementati= ons
provides a relatively low precision timestamp, and the NTP time
d= istribution infrastructure operates on a best effort basis. Thus even a
= good client implementation would normally have a relatively low quality
= path to the server, which would result in a low quality of timestamp. NTPcould be made to work to higher accuracy, but defacto upgrading NTP andproviding high quality NTP paths to the time servers is not getting much<= br>attention. Computing timestamp differences is easier with NTP.

On= the other hand IEEE1588 has defacto become the two way time tranfer
pro= tocol for precision applications. IEEE1588 only provides high quality
ti= me in well engineered networks with some form of hop by hop assistance.
= It is not widely implemented other than in equipment targeted to specificmarkets, although one of those markets is in mobile backhaul applications=
where we expect to see significant initial deployment of MPLS-TP. Compu= ting
timestamp differences is harder with IEEE1588

The loss-delay= work is targeting to be able to do one way packet delay
measurement, so= it does need a higher quality of timestamp than is required
in general = purpose network instrumentation.

Converting from IEEE1588 to NTP is = not trivial, since they use different
epochs, and different representati= ons of sub-second time. In a
"traditional" NTP implementation = the time error due to on the fly
conversion is likely to be small compar= ed to the time error in the time
synchronization system, but an IEEE1588= system would need hardware
conversion to maintain the accuracy for an N= TP timestamp.

So the question arises, should we make IEEE1588 or NTP= the default for
draft-ietf-mpls-loss-delay. Much as I would like to sug= gest that we should
go back to NTP for consistency with other IETF proto= cols, I have difficulty
reconciling this with the situation in network d= eployments and thus suggest
that we continue to use IEEE1588.

Wha= t is the opinion of the working group?

Stewart (speaking as a draft = editor)

____________________= ___________________________
TICTOC mailing list
TICTOC@ietf.org
https://www.ietf.org/mailman/listinfo/= tictoc


_______________________________________________
TI= CTOC mailing list
TICTOC@ietf.org=
https://www.ietf.org/mailman/listinfo/tictoc

 

= --_000_2C2F1EBA8050E74EA81502D5740B4BD6956C29997DSJEXCHCCR02co_-- From ben@niven-jenkins.co.uk Thu Mar 3 13:26:02 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEE943A68AB; Thu, 3 Mar 2011 13:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.963 X-Spam-Level: X-Spam-Status: No, score=-103.963 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 ADAnSppys7Y8; Thu, 3 Mar 2011 13:26:01 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id 94C7D3A6893; Thu, 3 Mar 2011 13:26:01 -0800 (PST) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.203]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PvG37-0004O9-C0; Thu, 03 Mar 2011 21:27:06 +0000 References: <4D6FBC8C.50904@cisco.com> In-Reply-To: <4D6FBC8C.50904@cisco.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <2FFC51B6-2A07-477C-B947-5BB8FF9F8E02@niven-jenkins.co.uk> Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins Date: Thu, 3 Mar 2011 21:27:02 +0000 To: stbryant@cisco.com X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 21:26:03 -0000 Stewart, IMO a default serves two purposes: 1) A baseline everyone must implement 2) A reduction in the amount of additional configuration to get = something working. NTP arguably covers (1) better because as the draft notes it has had = wide deployment on the Internet.=20 However I would think (and I'm no expert so may be wrong) that NTP has = not generally been used for the sort of use cases that = draft-ietf-mpls-loss-delay attempts to cover and I do not think it would = provide the level of accuracy expected by Transport Network Operators. If NTP were the default then I would expect that in the majority of = cases Transport Network Operators would immediately change from the NTP = default to 1588. The one case I would think where maybe operators would = stick with NTP is if their equipment cannot for some reason support 1588 = but does support NTP. Even in those cases I expect the operator may well = just choose to not use draft-ietf-mpls-loss-delay at all as measurements = that aren't sufficiently accurate for a transport network operator could = be considered worse than no measurements at all. So IMO 1588 covers (2) = better and it is not a new protocol so 1588 has also seen quite a bit of = deployment AFAIK. Therefore the only case where making NTP the default makes sense IMO is = where it is felt that implementing 1588 is so burdensome that a = significant proportion of equipment will exist that will only ever be = capable of supporting NTP timestamps and that deployers of = draft-ietf-mpls-loss-delay would accept the level of accuracy provided = by NTP. I am not the right person to judge whether that would be the = case but my gut tells me that it won't. So I'd vote for 1588 to be the default. Ben On 3 Mar 2011, at 16:06, Stewart Bryant wrote: >=20 > We have received a LC comment on draft-ietf-mpls-loss-delay concerning = the default timestamp. >=20 > In the first version of the draft we proposed NTP, but following = initial comments from the MPLS-TP community we changed to IEEE1588. This = requirement for IEEE1588 can be traced back to the choice of using = IEEE1588 in Y.1731. >=20 > We have now received a LC request to change the default back to NTP. >=20 > NTP is the "natural" choice for an IETF protocol. NTP is specified in = IETF and is used in other MPLS protocols such as LSP ping. It is = implemented on almost every host and every router. However in general = the implementations provides a relatively low precision timestamp, and = the NTP time distribution infrastructure operates on a best effort = basis. Thus even a good client implementation would normally have a = relatively low quality path to the server, which would result in a low = quality of timestamp. NTP could be made to work to higher accuracy, but = defacto upgrading NTP and providing high quality NTP paths to the time = servers is not getting much attention. Computing timestamp differences = is easier with NTP. >=20 > On the other hand IEEE1588 has defacto become the two way time tranfer = protocol for precision applications. IEEE1588 only provides high quality = time in well engineered networks with some form of hop by hop = assistance. It is not widely implemented other than in equipment = targeted to specific markets, although one of those markets is in mobile = backhaul applications where we expect to see significant initial = deployment of MPLS-TP. Computing timestamp differences is harder with = IEEE1588 >=20 > The loss-delay work is targeting to be able to do one way packet delay = measurement, so it does need a higher quality of timestamp than is = required in general purpose network instrumentation. >=20 > Converting from IEEE1588 to NTP is not trivial, since they use = different epochs, and different representations of sub-second time. In a = "traditional" NTP implementation the time error due to on the fly = conversion is likely to be small compared to the time error in the time = synchronization system, but an IEEE1588 system would need hardware = conversion to maintain the accuracy for an NTP timestamp. >=20 > So the question arises, should we make IEEE1588 or NTP the default for = draft-ietf-mpls-loss-delay. Much as I would like to suggest that we = should go back to NTP for consistency with other IETF protocols, I have = difficulty reconciling this with the situation in network deployments = and thus suggest that we continue to use IEEE1588. >=20 > What is the opinion of the working group? >=20 > Stewart (speaking as a draft editor) >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Thu Mar 3 14:11:41 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73D5B3A68B0; Thu, 3 Mar 2011 14:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5] 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 FQPWe7D2+2my; Thu, 3 Mar 2011 14:11:24 -0800 (PST) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 9E1CC3A6867; Thu, 3 Mar 2011 14:11:23 -0800 (PST) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 03 Mar 2011 14:14:26 -0800 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 3 Mar 2011 14:12:14 -0800 From: "Shahram Davari" To: "'ronc.ntear@gmail.com'" Date: Thu, 3 Mar 2011 14:12:13 -0800 Thread-Topic: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Thread-Index: AcvZ6ud1QzORkdtGQoWLjyXPiTq1ggABSUIS Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6956BE358E6@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 616ECD4B26W7139929-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6956BE358E6SJEXCHCCR02co_ Cc: "'mpls@ietf.org'" , "'PDiamond@semtech.com'" , "'tictoc-bounces@ietf.org'" , "'tictoc@ietf.org'" Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 22:11:42 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6956BE358E6SJEXCHCCR02co_ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QWdyZWUuDQoNClNoYWhyYW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IFJvbiBDb2hlbiA8cm9uYy5udGVhckBnbWFpbC5jb20+DQpUbzogU2hhaHJhbSBEYXZhcmkN CkNjOiBQRGlhbW9uZEBzZW10ZWNoLmNvbSA8UERpYW1vbmRAc2VtdGVjaC5jb20+OyBtcGxzQGll dGYub3JnIDxtcGxzQGlldGYub3JnPjsgdGljdG9jLWJvdW5jZXNAaWV0Zi5vcmcgPHRpY3RvYy1i b3VuY2VzQGlldGYub3JnPjsgdGljdG9jQGlldGYub3JnIDx0aWN0b2NAaWV0Zi5vcmc+DQpTZW50 OiBUaHUgTWFyIDAzIDEzOjM1OjExIDIwMTENClN1YmplY3Q6IFJlOiBbVElDVE9DXSBkcmFmdC1p ZXRmLW1wbHMtbG9zcy1kZWxheSBUaW1lc3RhbXANCg0KSGkgU2hhaHJhbSwgSSBndWVzcyBhZGRp bmcgYSByZXF1aXJlbWVudCB0byB0YWtlIHRpbWVzdGFtcCByb2xsb3ZlciBpbnRvIGFjY291bnQg d291bGQgZG8uIElmIHRoZXJlIGlzIGEgc3Ryb25nIHJlYXNvbiB0byBhbHNvIGxlYXZlIE5UUCB0 aW1lc3RhbXAgYXMgYW4gb3B0aW9uLCBhIG5vdGUgZXhwbGFpbmluZyB0aGUgcmFtaWZpY2F0aW9u IG9mIGxlYXAgc2Vjb25kcyBzaG91bGQgYmUgYWRkZWQuIEkgc3VnZ2VzdCB0aGF0IGEgY29udGlu dW91cyB0aW1lc2NhbGUgKGkuZS4gUFRQKSB3b3VsZCBiZSBzZWxlY3RlZCBpbiB0aGUgZHJhZnQg YXMgdGhlIGRlZmF1bHQvbXVzdCBvcHRpb24uIEJlc3QsIFJvbg0KDQpPbiBUaHUsIE1hciAzLCAy MDExIGF0IDk6NDUgUE0sIFNoYWhyYW0gRGF2YXJpIDxkYXZhcmlAYnJvYWRjb20uY29tPG1haWx0 bzpkYXZhcmlAYnJvYWRjb20uY29tPj4gd3JvdGU6DQpIaSBSb24sDQoNCkFsdGhvdWdoIHRoZSBQ VFB2MiBpcyA4MCBieXRlcywgYnV0IEkgZG9u4oCZdCBzZWUgYSBuZWVkIHRvIHVzZSBhbGwgODAg Ynl0ZXMgZm9yIGRlbGF5IG1lYXN1cmVtZW50LiBUaGUgdXBwZXIgMl4zMiBzZWNvbmRzIGNvdmVy cyBhbG1vc3QgMTM2IHllYXJzLCB3aGljaCBzaG91bGQgYmUgZ29vZCBlbm91Z2ggdG8gbWVhc3Vy ZSBkZWxheS4gQWxzbyBsZXRz4oCZIGJlIGNvbXBhdGlibGUgd2l0aCBZLjE3MzEgZm9ybWF0IHNp bmNlIHRoYXQgSFcgYWxyZWFkeSBleGlzdC4NCg0KVGh4DQpTaGFocmFtDQoNCkZyb206IFJvbiBD b2hlbiBbbWFpbHRvOnJvbmMubnRlYXJAZ21haWwuY29tPG1haWx0bzpyb25jLm50ZWFyQGdtYWls LmNvbT5dDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMDMsIDIwMTEgMTE6MjIgQU0NClRvOiBQRGlh bW9uZEBzZW10ZWNoLmNvbTxtYWlsdG86UERpYW1vbmRAc2VtdGVjaC5jb20+DQpDYzogU2hhaHJh bSBEYXZhcmk7IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyB0aWN0b2MtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86dGljdG9jLWJvdW5jZXNAaWV0Zi5vcmc+OyB0aWN0b2NAaWV0 Zi5vcmc8bWFpbHRvOnRpY3RvY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVElDVE9DXSBkcmFm dC1pZXRmLW1wbHMtbG9zcy1kZWxheSBUaW1lc3RhbXANCg0KSGksDQoNCkkgYXBvbG9naXplIGlu IGFkdmFuY2UgaWYgbXkgY29tbWVudHMgYmVsb3cgd2hlcmUgYWxyZWFkeSBiZWVuIGRpc2N1c3Nl ZC4NCg0KVGhlIGRyYWZ0IHNwZWNpZnkgdXNpbmcgUFRQdjEgdGltZXN0YW1wIGZvcm1hdCBhbmQg bm90IFBUUHYyIHRpbWVzdGFtcCBmb3JtYXQuIFRoZSBzZWNvbmRzIHBhcnQgb2YgdGhlIFBUUHYy IHRpbWVzdGFtcCBpcyA0OGJpdHMsIGFuZCBub3QgMzJiaXRzIGFzIHdyaXR0ZW4gaW4gdGhlIGRy YWZ0LiBOVFAgdGltZXN0YW1wcyB3aWxsIHJvbGwgb3ZlciBpbiAyMDM2LiBQVFB2MiB0aW1lc3Rh bXBzIGRvIG5vdCByb2xsb3Zlci4NCg0KSSBkb24ndCB0aGluayBpdHMgYWR2aXNhYmxlIHRvIGlu Y2x1ZGUgdGltZXN0YW1wcyB0aGF0IHJvbGxzIG92ZXIgfjIwIHllYXJzIGZyb20gbm93Lg0KDQpJ biBhZGRpdGlvbiwgTlRQIHRpbWVzdGFtcCwgdW5saWtlIFBUUCB0aW1lc3RhbXAsICdqdW1wcycg aW4gbGVhcCBzZWNvbmRzIGV2ZW50cy4gVGhpcyBtYWtlcyBjYWxjdWxhdGlvbiBvZiB0aW1lIGRp ZmZlcmVuY2VzIGhhcmQsIGFuZCB3b3VsZCByZW5kZXIgc29tZSBtZWFzdXJlbWVudHMgYW1iaWd1 b3VzLiBJdCBpcyBtdWNoIGVhc2llciB0byB1c2UgY29udGludW91cyB0aW1lc2NhbGUgbGlrZSBQ VFAuDQoNCkluIG15IG9waW5pb24gY2hhbmdpbmcgdGhlIHRpbWVzdGFtcCBmb3JtYXQgdG8gUFRQ djIgdGltZXN0YW1wIGZvcm1hdCAoaS5lLiA0OGJpdC8zMmJpdCBzZWMvbnMpIHNob3VsZCBiZSB0 aGUgcmlnaHQgd2F5IHRvIGdvLiBJIHdvdWxkIGFsc28gcmVtb3ZlIHRoZSBOVFAgdGltZXN0YW1w IGZvcm1hdCBvcHRpb24gdG8gYXZvaWQgbGVhcCBzZWNvbmRzIGNvbmZ1c2lvbiBhbmQgMjAzNiBy b2xsb3ZlciBldmVudHMuDQoNCkJlc3QsDQpSb24NCg0KT24gVGh1LCBNYXIgMywgMjAxMSBhdCA4 OjI2IFBNLCA8UERpYW1vbmRAc2VtdGVjaC5jb208bWFpbHRvOlBEaWFtb25kQHNlbXRlY2guY29t Pj4gd3JvdGU6DQpNeSBmZWVsaW5nIGlzIDE1ODggaXMgdGhlIHJpZ2h0IGFuc3dlciBpbiB0aGUg bG9uZyBydW4gc2luY2UgaXQgaXMgYWxyZWFkeQ0KY291cGxlZCB0byB0aGUgaGFyZHdhcmUgYW5k IHdpZGVseSBkZXBsb3llZCBpbiBuZXR3b3JrcyB1c2luZyB0aGUgInBhY2tldA0KY2xvY2sgZGVy aXZlZCB0aW1lIiBpbiBwcmVjaXNlIHRpbWUgYW5kIGZyZXF1ZW5jeSBkZWxpdmVyeS4NCg0KUGF0 DQoNCg0KDQogICAgICAgICAgICAiU2hhaHJhbSBEYXZhcmkiDQogICAgICAgICAgICA8ZGF2YXJp QGJyb2FkY29tLg0KICAgICAgICAgICAgY29tPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBUbw0KICAgICAgICAgICAgU2VudCBieTogICAgICAg ICAgICAgICAgICAic3RicnlhbnRAY2lzY28uY29tPG1haWx0bzpzdGJyeWFudEBjaXNjby5jb20+ Ig0KICAgICAgICAgICAgdGljdG9jLWJvdW5jZXNAaWUgICAgICAgICA8c3RicnlhbnRAY2lzY28u Y29tPG1haWx0bzpzdGJyeWFudEBjaXNjby5jb20+PiwNCiAgICAgICAgICAgIHRmLm9yZzxodHRw Oi8vdGYub3JnPiAgICAgICAgICAgICAgICAgICAgIm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNA aWV0Zi5vcmc+IiA8bXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGNjDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJ0aWN0b2NA aWV0Zi5vcmc8bWFpbHRvOnRpY3RvY0BpZXRmLm9yZz4iIDx0aWN0b2NAaWV0Zi5vcmc8bWFpbHRv OnRpY3RvY0BpZXRmLm9yZz4+DQogICAgICAgICAgICAwMy8wMy8yMDExIDEwOjA1ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdWJqZWN0DQogICAgICAgICAgICBBTSAgICAg ICAgICAgICAgICAgICAgICAgIFJlOiBbVElDVE9DXQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBkcmFmdC1pZXRmLW1wbHMtbG9zcy1kZWxheQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBUaW1lc3RhbXANCg0KDQoNCg0KDQoNCg0KDQoNCg0KSGkg U3Rld2FydCwNCg0KQWNjdXJhdGUgZGVsYXkgbWVhc3VyZW1lbnQgcmVxdWlyZXMgdGhlIFRpbWVz dGFtcCB0byBiZSBkb25lIGluIEhXLiBJdCBpcw0KdHJ1ZSB0aGF0IG1vc3Qgcm91dGVycyBzdXBw b3J0IE5UUCB0b2RheSwgYnV0IHRoZSBtYWpvcml0eSBvZiB0aG9zZSBhcmUNCnJlYWxseSBtYWlu dGFpbmVkIGluIFNvZnR3YXJlIGFuZCBBRkFJSyBtb3N0IEhXIGJhc2VkIHRpbWVzdGFtcHMNCmlt cGxlbWVudGF0aW9ucyBhcmUgMTU4OCBiYXNlZCBhbmQgcmVhbGx5IHRoZSBpbmR1c3RyeSBpcyBz aGlmdGluZyB0b3dhcmQNCjE1ODggYW5kIFN5bmNFIGZvciBuZXR3b3JrIHN5bmNocm9uaXphdGlv bi4gU28gSSBzdXBwb3J0IDE1ODggYXMgYmVpbmcgdGhlDQpkZWZhdWx0Lg0KDQpUaGFua3MsDQpT aGFocmFtDQoNCkZyb206IHRpY3RvYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0aWN0b2MtYm91 bmNlc0BpZXRmLm9yZz4gW21haWx0bzp0aWN0b2MtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dGlj dG9jLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YNClN0ZXdhcnQgQnJ5YW50DQpTZW50 OiBUaHVyc2RheSwgTWFyY2ggMDMsIDIwMTEgODowNyBBTQ0KVG86IG1wbHNAaWV0Zi5vcmc8bWFp bHRvOm1wbHNAaWV0Zi5vcmc+DQpDYzogdGljdG9jQGlldGYub3JnPG1haWx0bzp0aWN0b2NAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBbVElDVE9DXSBkcmFmdC1pZXRmLW1wbHMtbG9zcy1kZWxheSBUaW1l c3RhbXANCg0KDQpXZSBoYXZlIHJlY2VpdmVkIGEgTEMgY29tbWVudCBvbiBkcmFmdC1pZXRmLW1w bHMtbG9zcy1kZWxheSBjb25jZXJuaW5nIHRoZQ0KZGVmYXVsdCB0aW1lc3RhbXAuDQoNCkluIHRo ZSBmaXJzdCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB3ZSBwcm9wb3NlZCBOVFAsIGJ1dCBmb2xsb3dp bmcgaW5pdGlhbA0KY29tbWVudHMgZnJvbSB0aGUgTVBMUy1UUCBjb21tdW5pdHkgd2UgY2hhbmdl ZCB0byBJRUVFMTU4OC4gVGhpcw0KcmVxdWlyZW1lbnQgZm9yIElFRUUxNTg4IGNhbiBiZSB0cmFj ZWQgYmFjayB0byB0aGUgY2hvaWNlIG9mIHVzaW5nIElFRUUxNTg4DQppbiBZLjE3MzEuDQoNCldl IGhhdmUgbm93IHJlY2VpdmVkIGEgTEMgcmVxdWVzdCB0byBjaGFuZ2UgdGhlIGRlZmF1bHQgYmFj ayB0byBOVFAuDQoNCk5UUCBpcyB0aGUgIm5hdHVyYWwiIGNob2ljZSBmb3IgYW4gSUVURiBwcm90 b2NvbC4gTlRQIGlzIHNwZWNpZmllZCBpbiBJRVRGDQphbmQgaXMgdXNlZCBpbiBvdGhlciBNUExT IHByb3RvY29scyBzdWNoIGFzIExTUCBwaW5nLiBJdCBpcyBpbXBsZW1lbnRlZCBvbg0KYWxtb3N0 IGV2ZXJ5IGhvc3QgYW5kIGV2ZXJ5IHJvdXRlci4gSG93ZXZlciBpbiBnZW5lcmFsIHRoZSBpbXBs ZW1lbnRhdGlvbnMNCnByb3ZpZGVzIGEgcmVsYXRpdmVseSBsb3cgcHJlY2lzaW9uIHRpbWVzdGFt cCwgYW5kIHRoZSBOVFAgdGltZQ0KZGlzdHJpYnV0aW9uIGluZnJhc3RydWN0dXJlIG9wZXJhdGVz IG9uIGEgYmVzdCBlZmZvcnQgYmFzaXMuIFRodXMgZXZlbiBhDQpnb29kIGNsaWVudCBpbXBsZW1l bnRhdGlvbiB3b3VsZCBub3JtYWxseSBoYXZlIGEgcmVsYXRpdmVseSBsb3cgcXVhbGl0eQ0KcGF0 aCB0byB0aGUgc2VydmVyLCB3aGljaCB3b3VsZCByZXN1bHQgaW4gYSBsb3cgcXVhbGl0eSBvZiB0 aW1lc3RhbXAuIE5UUA0KY291bGQgYmUgbWFkZSB0byB3b3JrIHRvIGhpZ2hlciBhY2N1cmFjeSwg YnV0IGRlZmFjdG8gdXBncmFkaW5nIE5UUCBhbmQNCnByb3ZpZGluZyBoaWdoIHF1YWxpdHkgTlRQ IHBhdGhzIHRvIHRoZSB0aW1lIHNlcnZlcnMgaXMgbm90IGdldHRpbmcgbXVjaA0KYXR0ZW50aW9u LiBDb21wdXRpbmcgdGltZXN0YW1wIGRpZmZlcmVuY2VzIGlzIGVhc2llciB3aXRoIE5UUC4NCg0K T24gdGhlIG90aGVyIGhhbmQgSUVFRTE1ODggaGFzIGRlZmFjdG8gYmVjb21lIHRoZSB0d28gd2F5 IHRpbWUgdHJhbmZlcg0KcHJvdG9jb2wgZm9yIHByZWNpc2lvbiBhcHBsaWNhdGlvbnMuIElFRUUx NTg4IG9ubHkgcHJvdmlkZXMgaGlnaCBxdWFsaXR5DQp0aW1lIGluIHdlbGwgZW5naW5lZXJlZCBu ZXR3b3JrcyB3aXRoIHNvbWUgZm9ybSBvZiBob3AgYnkgaG9wIGFzc2lzdGFuY2UuDQpJdCBpcyBu b3Qgd2lkZWx5IGltcGxlbWVudGVkIG90aGVyIHRoYW4gaW4gZXF1aXBtZW50IHRhcmdldGVkIHRv IHNwZWNpZmljDQptYXJrZXRzLCBhbHRob3VnaCBvbmUgb2YgdGhvc2UgbWFya2V0cyBpcyBpbiBt b2JpbGUgYmFja2hhdWwgYXBwbGljYXRpb25zDQp3aGVyZSB3ZSBleHBlY3QgdG8gc2VlIHNpZ25p ZmljYW50IGluaXRpYWwgZGVwbG95bWVudCBvZiBNUExTLVRQLiBDb21wdXRpbmcNCnRpbWVzdGFt cCBkaWZmZXJlbmNlcyBpcyBoYXJkZXIgd2l0aCBJRUVFMTU4OA0KDQpUaGUgbG9zcy1kZWxheSB3 b3JrIGlzIHRhcmdldGluZyB0byBiZSBhYmxlIHRvIGRvIG9uZSB3YXkgcGFja2V0IGRlbGF5DQpt ZWFzdXJlbWVudCwgc28gaXQgZG9lcyBuZWVkIGEgaGlnaGVyIHF1YWxpdHkgb2YgdGltZXN0YW1w IHRoYW4gaXMgcmVxdWlyZWQNCmluIGdlbmVyYWwgcHVycG9zZSBuZXR3b3JrIGluc3RydW1lbnRh dGlvbi4NCg0KQ29udmVydGluZyBmcm9tIElFRUUxNTg4IHRvIE5UUCBpcyBub3QgdHJpdmlhbCwg c2luY2UgdGhleSB1c2UgZGlmZmVyZW50DQplcG9jaHMsIGFuZCBkaWZmZXJlbnQgcmVwcmVzZW50 YXRpb25zIG9mIHN1Yi1zZWNvbmQgdGltZS4gSW4gYQ0KInRyYWRpdGlvbmFsIiBOVFAgaW1wbGVt ZW50YXRpb24gdGhlIHRpbWUgZXJyb3IgZHVlIHRvIG9uIHRoZSBmbHkNCmNvbnZlcnNpb24gaXMg bGlrZWx5IHRvIGJlIHNtYWxsIGNvbXBhcmVkIHRvIHRoZSB0aW1lIGVycm9yIGluIHRoZSB0aW1l DQpzeW5jaHJvbml6YXRpb24gc3lzdGVtLCBidXQgYW4gSUVFRTE1ODggc3lzdGVtIHdvdWxkIG5l ZWQgaGFyZHdhcmUNCmNvbnZlcnNpb24gdG8gbWFpbnRhaW4gdGhlIGFjY3VyYWN5IGZvciBhbiBO VFAgdGltZXN0YW1wLg0KDQpTbyB0aGUgcXVlc3Rpb24gYXJpc2VzLCBzaG91bGQgd2UgbWFrZSBJ RUVFMTU4OCBvciBOVFAgdGhlIGRlZmF1bHQgZm9yDQpkcmFmdC1pZXRmLW1wbHMtbG9zcy1kZWxh eS4gTXVjaCBhcyBJIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB0aGF0IHdlIHNob3VsZA0KZ28gYmFj ayB0byBOVFAgZm9yIGNvbnNpc3RlbmN5IHdpdGggb3RoZXIgSUVURiBwcm90b2NvbHMsIEkgaGF2 ZSBkaWZmaWN1bHR5DQpyZWNvbmNpbGluZyB0aGlzIHdpdGggdGhlIHNpdHVhdGlvbiBpbiBuZXR3 b3JrIGRlcGxveW1lbnRzIGFuZCB0aHVzIHN1Z2dlc3QNCnRoYXQgd2UgY29udGludWUgdG8gdXNl IElFRUUxNTg4Lg0KDQpXaGF0IGlzIHRoZSBvcGluaW9uIG9mIHRoZSB3b3JraW5nIGdyb3VwPw0K DQpTdGV3YXJ0IChzcGVha2luZyBhcyBhIGRyYWZ0IGVkaXRvcikNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUSUNUT0MgbWFpbGluZyBsaXN0DQpUSUNU T0NAaWV0Zi5vcmc8bWFpbHRvOlRJQ1RPQ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdGljdG9jDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NClRJQ1RPQyBtYWlsaW5nIGxpc3QNClRJQ1RPQ0BpZXRmLm9y ZzxtYWlsdG86VElDVE9DQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90aWN0b2MNCg0KDQo= --_000_2C2F1EBA8050E74EA81502D5740B4BD6956BE358E6SJEXCHCCR02co_ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdj48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPg0KQWdyZWUuPGJyPjxicj5T aGFocmFtPC9mb250PjwvZGl2Pg0KPGJyPjxkaXY+PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxp Z249Y2VudGVyIHRhYmluZGV4PS0xPg0KPGZvbnQgZmFjZT1UYWhvbWEgc2l6ZT0yPg0KPGI+RnJv bTwvYj46IFJvbiBDb2hlbiAmbHQ7cm9uYy5udGVhckBnbWFpbC5jb20mZ3Q7DTxicj48Yj5Ubzwv Yj46IFNoYWhyYW0gRGF2YXJpDTxicj48Yj5DYzwvYj46IFBEaWFtb25kQHNlbXRlY2guY29tICZs dDtQRGlhbW9uZEBzZW10ZWNoLmNvbSZndDs7IG1wbHNAaWV0Zi5vcmcgJmx0O21wbHNAaWV0Zi5v cmcmZ3Q7OyB0aWN0b2MtYm91bmNlc0BpZXRmLm9yZyAmbHQ7dGljdG9jLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7OyB0aWN0b2NAaWV0Zi5vcmcgJmx0O3RpY3RvY0BpZXRmLm9yZyZndDsNPGJyPjxiPlNl bnQ8L2I+OiBUaHUgTWFyIDAzIDEzOjM1OjExIDIwMTE8YnI+PGI+U3ViamVjdDwvYj46IFJlOiBb VElDVE9DXSBkcmFmdC1pZXRmLW1wbHMtbG9zcy1kZWxheSBUaW1lc3RhbXANPGJyPjwvZm9udD48 YnI+PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5IaSBTaGFocmFtLCBJIGd1ZXNzIGFkZGluZyBhIHJl cXVpcmVtZW50IHRvIHRha2UgdGltZXN0YW1wIHJvbGxvdmVyIGludG8gYWNjb3VudCB3b3VsZCBk by4gSWYgdGhlcmUgaXMgYSBzdHJvbmcgcmVhc29uIHRvIGFsc28gbGVhdmUgTlRQIHRpbWVzdGFt cCBhcyBhbiBvcHRpb24sIGEgbm90ZSBleHBsYWluaW5nIHRoZSByYW1pZmljYXRpb24gb2YgbGVh cCBzZWNvbmRzIHNob3VsZCBiZSBhZGRlZC4gSSBzdWdnZXN0IHRoYXQgYSBjb250aW51b3VzIHRp bWVzY2FsZSAoaS5lLiBQVFApIHdvdWxkIGJlIHNlbGVjdGVkIGluIHRoZSBkcmFmdCBhcyB0aGUg ZGVmYXVsdC9tdXN0IG9wdGlvbi4gQmVzdCwgUm9uPGJyPg0KPGJyPjxkaXYgY2xhc3M9ImdtYWls X3F1b3RlIj5PbiBUaHUsIE1hciAzLCAyMDExIGF0IDk6NDUgUE0sIFNoYWhyYW0gRGF2YXJpIDxz cGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmFyaUBicm9hZGNvbS5jb20iPmRh dmFyaUBicm9hZGNvbS5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IGJvcmRl ci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nLWxlZnQ6IDFleDsi Pg0KPGRpdiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBsYW5nPSJFTi1VUyI+PGRpdj48cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsiPkhpIFJvbiw8L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+wqA8 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5BbHRob3VnaCB0aGUgUFRQdjIgaXMgODAg Ynl0ZXMsIGJ1dCBJIGRvbuKAmXQgc2VlIGEgbmVlZCB0byB1c2UgYWxsIDgwIGJ5dGVzIGZvciBk ZWxheSBtZWFzdXJlbWVudC4gVGhlIHVwcGVyIDJeMzIgc2Vjb25kcyBjb3ZlcnMgYWxtb3N0IDEz NiB5ZWFycywgd2hpY2ggc2hvdWxkIGJlIGdvb2QgZW5vdWdoIHRvIG1lYXN1cmUgZGVsYXkuIEFs c28gbGV0c+KAmSBiZSBjb21wYXRpYmxlIHdpdGggWS4xNzMxIGZvcm1hdCBzaW5jZSB0aGF0IEhX IGFscmVhZHkgZXhpc3QuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+wqA8L3NwYW4+ PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNv bG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+VGh4PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi PlNoYWhyYW08L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij7CoDwvc3Bhbj48L3A+PGRp diBzdHlsZT0iYm9yZGVyLXdpZHRoOiAxcHQgbWVkaXVtIG1lZGl1bTsgYm9yZGVyLXN0eWxlOiBz b2xpZCBub25lIG5vbmU7IGJvcmRlci1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpIC1tb3otdXNl LXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvcjsgcGFkZGluZzogM3B0IDBpbiAwaW47Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiPiBSb24gQ29oZW4g W21haWx0bzo8YSBocmVmPSJtYWlsdG86cm9uYy5udGVhckBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5yb25jLm50ZWFyQGdtYWlsLmNvbTwvYT5dIDxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXks IE1hcmNoIDAzLCAyMDExIDExOjIyIEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86 UERpYW1vbmRAc2VtdGVjaC5jb20iIHRhcmdldD0iX2JsYW5rIj5QRGlhbW9uZEBzZW10ZWNoLmNv bTwvYT48YnI+PGI+Q2M6PC9iPiBTaGFocmFtIERhdmFyaTsgPGEgaHJlZj0ibWFpbHRvOm1wbHNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFp bHRvOnRpY3RvYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGljdG9jLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86dGljdG9jQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+dGljdG9jQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RJ Q1RPQ10gZHJhZnQtaWV0Zi1tcGxzLWxvc3MtZGVsYXkgVGltZXN0YW1wPC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxkaXY+PC9kaXY+PGRpdiBjbGFzcz0iaDUiPjxwIGNsYXNzPSJNc29Ob3JtYWwiPsKg PC9wPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206IDEycHQ7 Ij5IaSw8YnI+PGJyPkkgYXBvbG9naXplIGluIGFkdmFuY2UgaWYgbXkgY29tbWVudHMgYmVsb3cg d2hlcmUgYWxyZWFkeSBiZWVuIGRpc2N1c3NlZC48YnI+DQo8YnI+VGhlIGRyYWZ0IHNwZWNpZnkg dXNpbmcgUFRQdjEgdGltZXN0YW1wIGZvcm1hdCBhbmQgbm90IFBUUHYyIHRpbWVzdGFtcCBmb3Jt YXQuIFRoZSBzZWNvbmRzIHBhcnQgb2YgdGhlIFBUUHYyIHRpbWVzdGFtcCBpcyA0OGJpdHMsIGFu ZCBub3QgMzJiaXRzIGFzIHdyaXR0ZW4gaW4gdGhlIGRyYWZ0LiBOVFAgdGltZXN0YW1wcyB3aWxs IHJvbGwgb3ZlciBpbiAyMDM2LiBQVFB2MiB0aW1lc3RhbXBzIGRvIG5vdCByb2xsb3Zlci48YnI+ DQo8YnI+SSBkb24mIzM5O3QgdGhpbmsgaXRzIGFkdmlzYWJsZSB0byBpbmNsdWRlIHRpbWVzdGFt cHMgdGhhdCByb2xscyBvdmVyIH4yMCB5ZWFycyBmcm9tIG5vdy4gPGJyPjxicj5JbiBhZGRpdGlv biwgTlRQIHRpbWVzdGFtcCwgdW5saWtlIFBUUCB0aW1lc3RhbXAsICYjMzk7anVtcHMmIzM5OyBp biBsZWFwIHNlY29uZHMgZXZlbnRzLiBUaGlzIG1ha2VzIGNhbGN1bGF0aW9uIG9mIHRpbWUgZGlm ZmVyZW5jZXMgaGFyZCwgYW5kIHdvdWxkIHJlbmRlciBzb21lIG1lYXN1cmVtZW50cyBhbWJpZ3Vv dXMuIEl0IGlzIG11Y2ggZWFzaWVyIHRvIHVzZSBjb250aW51b3VzIHRpbWVzY2FsZSBsaWtlIFBU UC48YnI+DQo8YnI+SW4gbXkgb3BpbmlvbiBjaGFuZ2luZyB0aGUgdGltZXN0YW1wIGZvcm1hdCB0 byBQVFB2MiB0aW1lc3RhbXAgZm9ybWF0IChpLmUuIDQ4Yml0LzMyYml0IHNlYy9ucykgc2hvdWxk IGJlIHRoZSByaWdodCB3YXkgdG8gZ28uIEkgd291bGQgYWxzbyByZW1vdmUgdGhlIE5UUCB0aW1l c3RhbXAgZm9ybWF0IG9wdGlvbiB0byBhdm9pZCBsZWFwIHNlY29uZHMgY29uZnVzaW9uIGFuZCAy MDM2IHJvbGxvdmVyIGV2ZW50cy4gPGJyPg0KPGJyPkJlc3QsPGJyPlJvbjxicj48YnI+PC9wPjxk aXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIgMywgMjAxMSBhdCA4OjI2IFBNLCAm bHQ7PGEgaHJlZj0ibWFpbHRvOlBEaWFtb25kQHNlbXRlY2guY29tIiB0YXJnZXQ9Il9ibGFuayI+ UERpYW1vbmRAc2VtdGVjaC5jb208L2E+Jmd0OyB3cm90ZTo8L3A+PHAgY2xhc3M9Ik1zb05vcm1h bCI+TXkgZmVlbGluZyBpcyAxNTg4IGlzIHRoZSByaWdodCBhbnN3ZXIgaW4gdGhlIGxvbmcgcnVu IHNpbmNlIGl0IGlzIGFscmVhZHk8YnI+DQpjb3VwbGVkIHRvIHRoZSBoYXJkd2FyZSBhbmQgd2lk ZWx5IGRlcGxveWVkIGluIG5ldHdvcmtzIHVzaW5nIHRoZSAmcXVvdDtwYWNrZXQ8YnI+Y2xvY2sg ZGVyaXZlZCB0aW1lJnF1b3Q7IGluIHByZWNpc2UgdGltZSBhbmQgZnJlcXVlbmN5IGRlbGl2ZXJ5 Ljxicj48YnI+UGF0PGJyPjxicj48YnI+PGJyPsKgIMKgIMKgIMKgIMKgIMKgICZxdW90O1NoYWhy YW0gRGF2YXJpJnF1b3Q7PGJyPsKgIMKgIMKgIMKgIMKgIMKgICZsdDtkYXZhcmlAYnJvYWRjb20u PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgY29tJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBU bzxicj7CoCDCoCDCoCDCoCDCoCDCoCBTZW50IGJ5OiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCZxdW90OzxhIGhyZWY9Im1haWx0bzpzdGJyeWFudEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5r Ij5zdGJyeWFudEBjaXNjby5jb208L2E+JnF1b3Q7PGJyPsKgIMKgIMKgIMKgIMKgIMKgIHRpY3Rv Yy1ib3VuY2VzQGllIMKgIMKgIMKgIMKgICZsdDs8YSBocmVmPSJtYWlsdG86c3RicnlhbnRAY2lz Y28uY29tIiB0YXJnZXQ9Il9ibGFuayI+c3RicnlhbnRAY2lzY28uY29tPC9hPiZndDssPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0iaHR0cDovL3RmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnRmLm9yZzwvYT4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmcXVvdDs8YSBocmVmPSJt YWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1w bHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgY2M8YnI+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnRpY3RvY0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRpY3RvY0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzp0aWN0b2NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50aWN0b2NAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIDAzLzAzLzIwMTEgMTA6MDUgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBTdWJqZWN0 PGJyPsKgIMKgIMKgIMKgIMKgIMKgIEFNIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgUmU6IFtUSUNUT0NdPC9wPjxkaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj7CoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkcmFmdC1p ZXRmLW1wbHMtbG9zcy1kZWxheTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRpbWVzdGFtcDxicj48YnI+PGJyPjxicj48YnI+PGJy Pjxicj48YnI+PGJyPjxicj48YnI+SGkgU3Rld2FydCw8YnI+PGJyPkFjY3VyYXRlIGRlbGF5IG1l YXN1cmVtZW50IHJlcXVpcmVzIHRoZSBUaW1lc3RhbXAgdG8gYmUgZG9uZSBpbiBIVy4gSXQgaXM8 YnI+dHJ1ZSB0aGF0IG1vc3Qgcm91dGVycyBzdXBwb3J0IE5UUCB0b2RheSwgYnV0IHRoZSBtYWpv cml0eSBvZiB0aG9zZSBhcmU8YnI+DQpyZWFsbHkgbWFpbnRhaW5lZCBpbiBTb2Z0d2FyZSBhbmQg QUZBSUsgbW9zdCBIVyBiYXNlZCB0aW1lc3RhbXBzPGJyPmltcGxlbWVudGF0aW9ucyBhcmUgMTU4 OCBiYXNlZCBhbmQgcmVhbGx5IHRoZSBpbmR1c3RyeSBpcyBzaGlmdGluZyB0b3dhcmQ8YnI+MTU4 OCBhbmQgU3luY0UgZm9yIG5ldHdvcmsgc3luY2hyb25pemF0aW9uLiBTbyBJIHN1cHBvcnQgMTU4 OCBhcyBiZWluZyB0aGU8YnI+DQpkZWZhdWx0Ljxicj48YnI+VGhhbmtzLDxicj5TaGFocmFtPGJy Pjxicj5Gcm9tOiA8YSBocmVmPSJtYWlsdG86dGljdG9jLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj50aWN0b2MtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJt YWlsdG86dGljdG9jLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50aWN0b2MtYm91 bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZjxicj4NClN0ZXdhcnQgQnJ5YW50PGJyPlNl bnQ6IFRodXJzZGF5LCBNYXJjaCAwMywgMjAxMSA4OjA3IEFNPGJyPlRvOiA8YSBocmVmPSJtYWls dG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPkNj OiA8YSBocmVmPSJtYWlsdG86dGljdG9jQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGljdG9j QGlldGYub3JnPC9hPjxicj5TdWJqZWN0OiBbVElDVE9DXSBkcmFmdC1pZXRmLW1wbHMtbG9zcy1k ZWxheSBUaW1lc3RhbXA8YnI+DQo8YnI+PGJyPldlIGhhdmUgcmVjZWl2ZWQgYSBMQyBjb21tZW50 IG9uIGRyYWZ0LWlldGYtbXBscy1sb3NzLWRlbGF5IGNvbmNlcm5pbmcgdGhlPGJyPmRlZmF1bHQg dGltZXN0YW1wLjxicj48YnI+SW4gdGhlIGZpcnN0IHZlcnNpb24gb2YgdGhlIGRyYWZ0IHdlIHBy b3Bvc2VkIE5UUCwgYnV0IGZvbGxvd2luZyBpbml0aWFsPGJyPmNvbW1lbnRzIGZyb20gdGhlIE1Q TFMtVFAgY29tbXVuaXR5IHdlIGNoYW5nZWQgdG8gSUVFRTE1ODguIFRoaXM8YnI+DQpyZXF1aXJl bWVudCBmb3IgSUVFRTE1ODggY2FuIGJlIHRyYWNlZCBiYWNrIHRvIHRoZSBjaG9pY2Ugb2YgdXNp bmcgSUVFRTE1ODg8YnI+aW4gWS4xNzMxLjxicj48YnI+V2UgaGF2ZSBub3cgcmVjZWl2ZWQgYSBM QyByZXF1ZXN0IHRvIGNoYW5nZSB0aGUgZGVmYXVsdCBiYWNrIHRvIE5UUC48YnI+PGJyPk5UUCBp cyB0aGUgJnF1b3Q7bmF0dXJhbCZxdW90OyBjaG9pY2UgZm9yIGFuIElFVEYgcHJvdG9jb2wuIE5U UCBpcyBzcGVjaWZpZWQgaW4gSUVURjxicj4NCmFuZCBpcyB1c2VkIGluIG90aGVyIE1QTFMgcHJv dG9jb2xzIHN1Y2ggYXMgTFNQIHBpbmcuIEl0IGlzIGltcGxlbWVudGVkIG9uPGJyPmFsbW9zdCBl dmVyeSBob3N0IGFuZCBldmVyeSByb3V0ZXIuIEhvd2V2ZXIgaW4gZ2VuZXJhbCB0aGUgaW1wbGVt ZW50YXRpb25zPGJyPnByb3ZpZGVzIGEgcmVsYXRpdmVseSBsb3cgcHJlY2lzaW9uIHRpbWVzdGFt cCwgYW5kIHRoZSBOVFAgdGltZTxicj4NCmRpc3RyaWJ1dGlvbiBpbmZyYXN0cnVjdHVyZSBvcGVy YXRlcyBvbiBhIGJlc3QgZWZmb3J0IGJhc2lzLiBUaHVzIGV2ZW4gYTxicj5nb29kIGNsaWVudCBp bXBsZW1lbnRhdGlvbiB3b3VsZCBub3JtYWxseSBoYXZlIGEgcmVsYXRpdmVseSBsb3cgcXVhbGl0 eTxicj5wYXRoIHRvIHRoZSBzZXJ2ZXIsIHdoaWNoIHdvdWxkIHJlc3VsdCBpbiBhIGxvdyBxdWFs aXR5IG9mIHRpbWVzdGFtcC4gTlRQPGJyPg0KY291bGQgYmUgbWFkZSB0byB3b3JrIHRvIGhpZ2hl ciBhY2N1cmFjeSwgYnV0IGRlZmFjdG8gdXBncmFkaW5nIE5UUCBhbmQ8YnI+cHJvdmlkaW5nIGhp Z2ggcXVhbGl0eSBOVFAgcGF0aHMgdG8gdGhlIHRpbWUgc2VydmVycyBpcyBub3QgZ2V0dGluZyBt dWNoPGJyPmF0dGVudGlvbi4gQ29tcHV0aW5nIHRpbWVzdGFtcCBkaWZmZXJlbmNlcyBpcyBlYXNp ZXIgd2l0aCBOVFAuPGJyPjxicj4NCk9uIHRoZSBvdGhlciBoYW5kIElFRUUxNTg4IGhhcyBkZWZh Y3RvIGJlY29tZSB0aGUgdHdvIHdheSB0aW1lIHRyYW5mZXI8YnI+cHJvdG9jb2wgZm9yIHByZWNp c2lvbiBhcHBsaWNhdGlvbnMuIElFRUUxNTg4IG9ubHkgcHJvdmlkZXMgaGlnaCBxdWFsaXR5PGJy PnRpbWUgaW4gd2VsbCBlbmdpbmVlcmVkIG5ldHdvcmtzIHdpdGggc29tZSBmb3JtIG9mIGhvcCBi eSBob3AgYXNzaXN0YW5jZS48YnI+DQpJdCBpcyBub3Qgd2lkZWx5IGltcGxlbWVudGVkIG90aGVy IHRoYW4gaW4gZXF1aXBtZW50IHRhcmdldGVkIHRvIHNwZWNpZmljPGJyPm1hcmtldHMsIGFsdGhv dWdoIG9uZSBvZiB0aG9zZSBtYXJrZXRzIGlzIGluIG1vYmlsZSBiYWNraGF1bCBhcHBsaWNhdGlv bnM8YnI+d2hlcmUgd2UgZXhwZWN0IHRvIHNlZSBzaWduaWZpY2FudCBpbml0aWFsIGRlcGxveW1l bnQgb2YgTVBMUy1UUC4gQ29tcHV0aW5nPGJyPg0KdGltZXN0YW1wIGRpZmZlcmVuY2VzIGlzIGhh cmRlciB3aXRoIElFRUUxNTg4PGJyPjxicj5UaGUgbG9zcy1kZWxheSB3b3JrIGlzIHRhcmdldGlu ZyB0byBiZSBhYmxlIHRvIGRvIG9uZSB3YXkgcGFja2V0IGRlbGF5PGJyPm1lYXN1cmVtZW50LCBz byBpdCBkb2VzIG5lZWQgYSBoaWdoZXIgcXVhbGl0eSBvZiB0aW1lc3RhbXAgdGhhbiBpcyByZXF1 aXJlZDxicj5pbiBnZW5lcmFsIHB1cnBvc2UgbmV0d29yayBpbnN0cnVtZW50YXRpb24uPGJyPg0K PGJyPkNvbnZlcnRpbmcgZnJvbSBJRUVFMTU4OCB0byBOVFAgaXMgbm90IHRyaXZpYWwsIHNpbmNl IHRoZXkgdXNlIGRpZmZlcmVudDxicj5lcG9jaHMsIGFuZCBkaWZmZXJlbnQgcmVwcmVzZW50YXRp b25zIG9mIHN1Yi1zZWNvbmQgdGltZS4gSW4gYTxicj4mcXVvdDt0cmFkaXRpb25hbCZxdW90OyBO VFAgaW1wbGVtZW50YXRpb24gdGhlIHRpbWUgZXJyb3IgZHVlIHRvIG9uIHRoZSBmbHk8YnI+DQpj b252ZXJzaW9uIGlzIGxpa2VseSB0byBiZSBzbWFsbCBjb21wYXJlZCB0byB0aGUgdGltZSBlcnJv ciBpbiB0aGUgdGltZTxicj5zeW5jaHJvbml6YXRpb24gc3lzdGVtLCBidXQgYW4gSUVFRTE1ODgg c3lzdGVtIHdvdWxkIG5lZWQgaGFyZHdhcmU8YnI+Y29udmVyc2lvbiB0byBtYWludGFpbiB0aGUg YWNjdXJhY3kgZm9yIGFuIE5UUCB0aW1lc3RhbXAuPGJyPjxicj5TbyB0aGUgcXVlc3Rpb24gYXJp c2VzLCBzaG91bGQgd2UgbWFrZSBJRUVFMTU4OCBvciBOVFAgdGhlIGRlZmF1bHQgZm9yPGJyPg0K ZHJhZnQtaWV0Zi1tcGxzLWxvc3MtZGVsYXkuIE11Y2ggYXMgSSB3b3VsZCBsaWtlIHRvIHN1Z2dl c3QgdGhhdCB3ZSBzaG91bGQ8YnI+Z28gYmFjayB0byBOVFAgZm9yIGNvbnNpc3RlbmN5IHdpdGgg b3RoZXIgSUVURiBwcm90b2NvbHMsIEkgaGF2ZSBkaWZmaWN1bHR5PGJyPnJlY29uY2lsaW5nIHRo aXMgd2l0aCB0aGUgc2l0dWF0aW9uIGluIG5ldHdvcmsgZGVwbG95bWVudHMgYW5kIHRodXMgc3Vn Z2VzdDxicj4NCnRoYXQgd2UgY29udGludWUgdG8gdXNlIElFRUUxNTg4Ljxicj48YnI+V2hhdCBp cyB0aGUgb3BpbmlvbiBvZiB0aGUgd29ya2luZyBncm91cD88YnI+PGJyPlN0ZXdhcnQgKHNwZWFr aW5nIGFzIGEgZHJhZnQgZWRpdG9yKTwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFs Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5USUNU T0MgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRJQ1RPQ0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPlRJQ1RPQ0BpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90aWN0b2MiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RpY3RvYzwvYT48YnI+PGJyPjxicj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClRJQ1RPQyBt YWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOlRJQ1RPQ0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPlRJQ1RPQ0BpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90aWN0b2MiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RpY3RvYzwvYT48L3A+PC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj7CoDwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVv dGU+PC9kaXY+PGJyPjxkaXYgc3R5bGU9InZpc2liaWxpdHk6IGhpZGRlbjsgbGVmdDogLTUwMDBw eDsgcG9zaXRpb246IGFic29sdXRlOyB6LWluZGV4OiA5OTk5OyBwYWRkaW5nOiAwcHg7IG1hcmdp bi1sZWZ0OiAwcHg7IG1hcmdpbi10b3A6IDBweDsgb3ZlcmZsb3c6IGhpZGRlbjsgd29yZC13cmFw OiBicmVhay13b3JkOyBjb2xvcjogYmxhY2s7IGZvbnQtc2l6ZTogMTBweDsgdGV4dC1hbGlnbjog bGVmdDsgbGluZS1oZWlnaHQ6IDEzMCU7IiBpZD0iYXZnX2xzX2lubGluZV9wb3B1cCI+DQo8L2Rp dj48L2Rpdj4NCg== --_000_2C2F1EBA8050E74EA81502D5740B4BD6956BE358E6SJEXCHCCR02co_-- From stbryant@cisco.com Thu Mar 3 14:47:46 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 716043A68B0; Thu, 3 Mar 2011 14:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.5 X-Spam-Level: X-Spam-Status: No, score=-110.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 bqa7NLLSZLDV; Thu, 3 Mar 2011 14:47:44 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id C772D3A67D9; Thu, 3 Mar 2011 14:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=32254; q=dns/txt; s=iport; t=1299192531; x=1300402131; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=3AmlCDHIT2fwrvWUBU3VXRU95UDpJMx9Xu50KE8UUDs=; b=b7UNu89dijUK3C38fDMpQYpXfDeN9XVoDilV+rC/RQl1AbrMRA6WtOvf Ux8/xnhO1RWPv6TMsjAU9us+2kuSESznDPew3ynhRsF5Sg7Ki9DMonJwx bNMDuXPEmsfK4bDTu4eJwqGFq+8Aj6/RU5kfI8umh877sm2IVn+FPc/Jx 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8CAKupb02Q/khMgWdsb2JhbAAXgjmBWpN3iWeEXxUBARYiJZU5Fo0AgmcOAYgUkQ2DEYFadgSBbIpAhlo X-IronPort-AV: E=Sophos;i="4.62,260,1297036800"; d="scan'208,217";a="20645365" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 03 Mar 2011 22:48:50 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p23MmotN008924; Thu, 3 Mar 2011 22:48:50 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p23Mmk804162; Thu, 3 Mar 2011 22:48:47 GMT Message-ID: <4D701ACF.4020702@cisco.com> Date: Thu, 03 Mar 2011 22:48:47 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Shahram Davari References: <2C2F1EBA8050E74EA81502D5740B4BD6956BE358E6@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6956BE358E6@SJEXCHCCR02.corp.ad.broadcom.com> Content-Type: multipart/alternative; boundary="------------010708060102000808000203" Cc: "'mpls@ietf.org'" , "'tictoc@ietf.org'" , "'PDiamond@semtech.com'" , "'tictoc-bounces@ietf.org'" , "'ronc.ntear@gmail.com'" Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 22:47:46 -0000 This is a multi-part message in MIME format. --------------010708060102000808000203 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I do not think that rollover or leap seconds are much of a problem in this application. We are measuring the transit time of a packet across a network. That is less than a second. Rollover or leap second errors mean that we make a mistake once in every 136 years in the first case and maybe never in the case of leap seconds. I am sure that it would be acceptable to simply state that for that for that one second at some time in the future we cannot make that measurement. BTW we are only going to use 32 bits of seconds and 32 bits of sub seconds in the 1588 case, and even then most of the sub second bits will be ignored. I don't thing that we need to be measuring time of flight over 8" of cable. Stewart On 03/03/2011 22:12, Shahram Davari wrote: > Agree. > > Shahram > > ------------------------------------------------------------------------ > *From*: Ron Cohen > *To*: Shahram Davari > *Cc*: PDiamond@semtech.com ; mpls@ietf.org > ; tictoc-bounces@ietf.org ; > tictoc@ietf.org > *Sent*: Thu Mar 03 13:35:11 2011 > *Subject*: Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp > > Hi Shahram, I guess adding a requirement to take timestamp rollover > into account would do. If there is a strong reason to also leave NTP > timestamp as an option, a note explaining the ramification of leap > seconds should be added. I suggest that a continuous timescale (i.e. > PTP) would be selected in the draft as the default/must option. Best, Ron > > On Thu, Mar 3, 2011 at 9:45 PM, Shahram Davari > wrote: > > Hi Ron, > > Although the PTPv2 is 80 bytes, but I don’t see a need to use all > 80 bytes for delay measurement. The upper 2^32 seconds covers > almost 136 years, which should be good enough to measure delay. > Also lets’ be compatible with Y.1731 format since that HW already > exist. > > Thx > > Shahram > > *From:*Ron Cohen [mailto:ronc.ntear@gmail.com > ] > *Sent:* Thursday, March 03, 2011 11:22 AM > *To:* PDiamond@semtech.com > *Cc:* Shahram Davari; mpls@ietf.org ; > tictoc-bounces@ietf.org ; > tictoc@ietf.org > *Subject:* Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp > > Hi, > > I apologize in advance if my comments below where already been > discussed. > > The draft specify using PTPv1 timestamp format and not PTPv2 > timestamp format. The seconds part of the PTPv2 timestamp is > 48bits, and not 32bits as written in the draft. NTP timestamps > will roll over in 2036. PTPv2 timestamps do not rollover. > > I don't think its advisable to include timestamps that rolls over > ~20 years from now. > > In addition, NTP timestamp, unlike PTP timestamp, 'jumps' in leap > seconds events. This makes calculation of time differences hard, > and would render some measurements ambiguous. It is much easier to > use continuous timescale like PTP. > > In my opinion changing the timestamp format to PTPv2 timestamp > format (i.e. 48bit/32bit sec/ns) should be the right way to go. I > would also remove the NTP timestamp format option to avoid leap > seconds confusion and 2036 rollover events. > > Best, > Ron > > On Thu, Mar 3, 2011 at 8:26 PM, > wrote: > > My feeling is 1588 is the right answer in the long run since it is > already > coupled to the hardware and widely deployed in networks using the > "packet > clock derived time" in precise time and frequency delivery. > > Pat > > > > "Shahram Davari" > com> > To > Sent by: "stbryant@cisco.com > " > tictoc-bounces@ie >, > tf.org "mpls@ietf.org > " > > > cc > "tictoc@ietf.org > " > > 03/03/2011 10:05 > Subject > AM Re: [TICTOC] > > draft-ietf-mpls-loss-delay > Timestamp > > > > > > > > > > > Hi Stewart, > > Accurate delay measurement requires the Timestamp to be done in > HW. It is > true that most routers support NTP today, but the majority of > those are > really maintained in Software and AFAIK most HW based timestamps > implementations are 1588 based and really the industry is shifting > toward > 1588 and SyncE for network synchronization. So I support 1588 as > being the > default. > > Thanks, > Shahram > > From: tictoc-bounces@ietf.org > [mailto:tictoc-bounces@ietf.org ] > On Behalf Of > Stewart Bryant > Sent: Thursday, March 03, 2011 8:07 AM > To: mpls@ietf.org > Cc: tictoc@ietf.org > Subject: [TICTOC] draft-ietf-mpls-loss-delay Timestamp > > > We have received a LC comment on draft-ietf-mpls-loss-delay > concerning the > default timestamp. > > In the first version of the draft we proposed NTP, but following > initial > comments from the MPLS-TP community we changed to IEEE1588. This > requirement for IEEE1588 can be traced back to the choice of using > IEEE1588 > in Y.1731. > > We have now received a LC request to change the default back to NTP. > > NTP is the "natural" choice for an IETF protocol. NTP is specified > in IETF > and is used in other MPLS protocols such as LSP ping. It is > implemented on > almost every host and every router. However in general the > implementations > provides a relatively low precision timestamp, and the NTP time > distribution infrastructure operates on a best effort basis. Thus > even a > good client implementation would normally have a relatively low > quality > path to the server, which would result in a low quality of > timestamp. NTP > could be made to work to higher accuracy, but defacto upgrading > NTP and > providing high quality NTP paths to the time servers is not > getting much > attention. Computing timestamp differences is easier with NTP. > > On the other hand IEEE1588 has defacto become the two way time tranfer > protocol for precision applications. IEEE1588 only provides high > quality > time in well engineered networks with some form of hop by hop > assistance. > It is not widely implemented other than in equipment targeted to > specific > markets, although one of those markets is in mobile backhaul > applications > where we expect to see significant initial deployment of MPLS-TP. > Computing > timestamp differences is harder with IEEE1588 > > The loss-delay work is targeting to be able to do one way packet delay > measurement, so it does need a higher quality of timestamp than is > required > in general purpose network instrumentation. > > Converting from IEEE1588 to NTP is not trivial, since they use > different > epochs, and different representations of sub-second time. In a > "traditional" NTP implementation the time error due to on the fly > conversion is likely to be small compared to the time error in the > time > synchronization system, but an IEEE1588 system would need hardware > conversion to maintain the accuracy for an NTP timestamp. > > So the question arises, should we make IEEE1588 or NTP the default for > draft-ietf-mpls-loss-delay. Much as I would like to suggest that > we should > go back to NTP for consistency with other IETF protocols, I have > difficulty > reconciling this with the situation in network deployments and > thus suggest > that we continue to use IEEE1588. > > What is the opinion of the working group? > > Stewart (speaking as a draft editor) > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------010708060102000808000203 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I do not think that rollover or leap seconds are much of a problem in this application. We are measuring the transit time of a packet across a network. That is less than a second. Rollover or leap second errors mean that we make a mistake once in every 136 years in the first case and maybe never in the case of leap seconds. I am sure that it would be acceptable to simply state that for that for that one second at some time in the future we cannot make that measurement.

BTW we are only going to use 32 bits of seconds and 32 bits of sub seconds in the 1588 case, and even then most of the sub second bits will be ignored. I don't thing that we need to be measuring time of flight over 8" of  cable.

Stewart

On 03/03/2011 22:12, Shahram Davari wrote:
Agree.

Shahram

From: Ron Cohen <ronc.ntear@gmail.com>
To: Shahram Davari
Cc: PDiamond@semtech.com <PDiamond@semtech.com>; mpls@ietf.org <mpls@ietf.org>; tictoc-bounces@ietf.org <tictoc-bounces@ietf.org>; tictoc@ietf.org <tictoc@ietf.org>
Sent: Thu Mar 03 13:35:11 2011
Subject: Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp

Hi Shahram, I guess adding a requirement to take timestamp rollover into account would do. If there is a strong reason to also leave NTP timestamp as an option, a note explaining the ramification of leap seconds should be added. I suggest that a continuous timescale (i.e. PTP) would be selected in the draft as the default/must option. Best, Ron

On Thu, Mar 3, 2011 at 9:45 PM, Shahram Davari <davari@broadcom.com> wrote:

Hi Ron,

 

Although the PTPv2 is 80 bytes, but I don’t see a need to use all 80 bytes for delay measurement. The upper 2^32 seconds covers almost 136 years, which should be good enough to measure delay. Also lets’ be compatible with Y.1731 format since that HW already exist.

 

Thx

Shahram

 

From: Ron Cohen [mailto:ronc.ntear@gmail.com]
Sent: Thursday, March 03, 2011 11:22 AM
To: PDiamond@semtech.com
Cc: Shahram Davari; mpls@ietf.org; tictoc-bounces@ietf.org; tictoc@ietf.org
Subject: Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp

 

Hi,

I apologize in advance if my comments below where already been discussed.

The draft specify using PTPv1 timestamp format and not PTPv2 timestamp format. The seconds part of the PTPv2 timestamp is 48bits, and not 32bits as written in the draft. NTP timestamps will roll over in 2036. PTPv2 timestamps do not rollover.

I don't think its advisable to include timestamps that rolls over ~20 years from now.

In addition, NTP timestamp, unlike PTP timestamp, 'jumps' in leap seconds events. This makes calculation of time differences hard, and would render some measurements ambiguous. It is much easier to use continuous timescale like PTP.

In my opinion changing the timestamp format to PTPv2 timestamp format (i.e. 48bit/32bit sec/ns) should be the right way to go. I would also remove the NTP timestamp format option to avoid leap seconds confusion and 2036 rollover events.

Best,
Ron

On Thu, Mar 3, 2011 at 8:26 PM, <PDiamond@semtech.com> wrote:

My feeling is 1588 is the right answer in the long run since it is already
coupled to the hardware and widely deployed in networks using the "packet
clock derived time" in precise time and frequency delivery.

Pat



            "Shahram Davari"
            <davari@broadcom.
            com>                                                       To
            Sent by:                  "stbryant@cisco.com"
            tictoc-bounces@ie         <stbryant@cisco.com>,
            tf.org                    "mpls@ietf.org" <mpls@ietf.org>
                                                                       cc
                                      "tictoc@ietf.org" <tictoc@ietf.org>
            03/03/2011 10:05                                      Subject
            AM                        Re: [TICTOC]

                                      draft-ietf-mpls-loss-delay
                                      Timestamp










Hi Stewart,

Accurate delay measurement requires the Timestamp to be done in HW. It is
true that most routers support NTP today, but the majority of those are
really maintained in Software and AFAIK most HW based timestamps
implementations are 1588 based and really the industry is shifting toward
1588 and SyncE for network synchronization. So I support 1588 as being the
default.

Thanks,
Shahram

From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of
Stewart Bryant
Sent: Thursday, March 03, 2011 8:07 AM
To: mpls@ietf.org
Cc: tictoc@ietf.org
Subject: [TICTOC] draft-ietf-mpls-loss-delay Timestamp


We have received a LC comment on draft-ietf-mpls-loss-delay concerning the
default timestamp.

In the first version of the draft we proposed NTP, but following initial
comments from the MPLS-TP community we changed to IEEE1588. This
requirement for IEEE1588 can be traced back to the choice of using IEEE1588
in Y.1731.

We have now received a LC request to change the default back to NTP.

NTP is the "natural" choice for an IETF protocol. NTP is specified in IETF
and is used in other MPLS protocols such as LSP ping. It is implemented on
almost every host and every router. However in general the implementations
provides a relatively low precision timestamp, and the NTP time
distribution infrastructure operates on a best effort basis. Thus even a
good client implementation would normally have a relatively low quality
path to the server, which would result in a low quality of timestamp. NTP
could be made to work to higher accuracy, but defacto upgrading NTP and
providing high quality NTP paths to the time servers is not getting much
attention. Computing timestamp differences is easier with NTP.

On the other hand IEEE1588 has defacto become the two way time tranfer
protocol for precision applications. IEEE1588 only provides high quality
time in well engineered networks with some form of hop by hop assistance.
It is not widely implemented other than in equipment targeted to specific
markets, although one of those markets is in mobile backhaul applications
where we expect to see significant initial deployment of MPLS-TP. Computing
timestamp differences is harder with IEEE1588

The loss-delay work is targeting to be able to do one way packet delay
measurement, so it does need a higher quality of timestamp than is required
in general purpose network instrumentation.

Converting from IEEE1588 to NTP is not trivial, since they use different
epochs, and different representations of sub-second time. In a
"traditional" NTP implementation the time error due to on the fly
conversion is likely to be small compared to the time error in the time
synchronization system, but an IEEE1588 system would need hardware
conversion to maintain the accuracy for an NTP timestamp.

So the question arises, should we make IEEE1588 or NTP the default for
draft-ietf-mpls-loss-delay. Much as I would like to suggest that we should
go back to NTP for consistency with other IETF protocols, I have difficulty
reconciling this with the situation in network deployments and thus suggest
that we continue to use IEEE1588.

What is the opinion of the working group?

Stewart (speaking as a draft editor)

_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
https://www.ietf.org/mailman/listinfo/tictoc


_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
https://www.ietf.org/mailman/listinfo/tictoc

 



_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------010708060102000808000203-- From swallow@cisco.com Thu Mar 3 15:27:48 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B4F83A6872 for ; Thu, 3 Mar 2011 15:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.9 X-Spam-Level: X-Spam-Status: No, score=-109.9 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, 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 NNwXvZLcKCJ0 for ; Thu, 3 Mar 2011 15:27:46 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 893643A6816 for ; Thu, 3 Mar 2011 15:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=8439; q=dns/txt; s=iport; t=1299194935; x=1300404535; h=date:subject:from:to:message-id:mime-version; bh=GJ8CGv+1uK+vCArAmm2ieCAOHEpobRlqa2OcQBRP09M=; b=NPaxG9XkiLaff1VuvIU0+GfC7OASU5dtO/5tlezFi9vGnlRbiK0iEbQp A5XiRqokeLSkbFYoOSodIttFFBGAQkMw3J3b3JcatMRMJ+JSyv9Z/gDqr tpZ0RA1t1avhc1eqTS4/sEfWUYwf7Pd8jHzfXmR/bJ+6AToHXMtZ5uhny w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEazb02tJV2Y/2dsb2JhbACCUKM6XXSiJZwShWEEhRqHEoNI X-IronPort-AV: E=Sophos;i="4.62,260,1297036800"; d="scan'208,217";a="222056727" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 03 Mar 2011 23:28:54 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p23NSsN7021614 for ; Thu, 3 Mar 2011 23:28:54 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Mar 2011 17:28:54 -0600 Received: from 10.82.229.44 ([10.82.229.44]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Mar 2011 23:28:54 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 03 Mar 2011 18:28:56 -0500 From: George Swallow To: Message-ID: Thread-Topic: Comment resolution on MPLS Identifiers draft Thread-Index: AcvZ+sPJNvIFlhFEq0K5Gx1jsradxw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3382021737_199398104" X-OriginalArrivalTime: 03 Mar 2011 23:28:54.0194 (UTC) FILETIME=[C2B5D920:01CBD9FA] Subject: [mpls] Comment resolution on MPLS Identifiers draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 23:27:48 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3382021737_199398104 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Addressed a comment from Mach Chen on the need for two LSP-IDs for associated bi-directional LSPs. Added a new section which allows for two LSP-IDs in this case, as well as a mapping to RSVP-TE signaling. Removed the automatic mapping of tunnel numbers to IF_IDs as this is implementation specific. Addressed the ITU comments as follows: 1. Not accepted. The sentence is correct as it is. It does not say that the document defines all identifier nor does it mention LSPs, tunnels or connections. 2. Accepted 3. Accepted in principle - removed sentence. Note that the TLV definitions are what actually define the order. 4. Accepted 5. Added the Operator ID. However the divergent naming of endpoint was not added. Such a move would add a great deal of complexity. Need to see clear market demand before adding. 6. Accepted in principle - wording is diffent since some of the changes propose are to a direct quote from another RFC. 7. The Global_ID is not an ASN. A non-zero Global_ID MUST be derived from an ASN owned by the operator. In a node running both MPLS-TP and BGP the ASN and the Global_ID could have the same value. But the ASN could be another ASN also owned by the operator. 8. Accepted 9. Accepted with wording changes. In particular the comment is addressed in a new paragraph immediately after the paragraph where the comment was made. 10. Accepted 11. Accepted with wording changed. 12. Accepted 13. Accepted 14. Accepted in principle. The comment was addressed by making a reference to hierarchical tunnels in the last paragraph of section 4. 15. Accepted 16. Accepted 17, 18. Paragraph rewritten for clarification. 19. Accepted 20. Per comment 26, this text was not moved. 21. Accepted but used East/West instead of A/Z 22. This has been stable text for over a year and half. We see no point in changing it now. 23. Type-o fixed 24. This is the naming for co-routed bi-directional tunnels. See new text in section xx for associated bi-directional 25. This is an artifact cause by the type-o which was addressed per comment 23. 26. Accepted. Added text on associated bi-directional. 27. Type-o fixed 28. Type-o fixed 29. Accepted, text added. 30. Accepted but used East/West instead of A/Z 31. Not accepted. The PW_ID is not unique to a node, but to a node pair. To automatically generate MEP_IDs in this case would require both node_ids and both global_ids for global uniqueness. Further, having another option just makes for more complication. 32. Accepted but used East/West instead of A/Z 33. The AGI is used in defining L2VPNs 34. Rather than incorporating the comment, the note was removed as it was not really appropriate for this document. 35. Not accepted. Believe the existing text is clear enough. The MEP-ID is required and there are two defined. This document does not specify usage. 36. Accepted with wording changes - new text is "where the Node_ID is the node in which the MEP is located and the AC_ID is the AC_ID of the Pseudowire at that node." 37. Changed name to Pseudowire Segments Endpoint ID or PW_SE_ID 38. Type-o fixed 39. Accepted --B_3382021737_199398104 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Comment resolution on MPLS Identifiers draft Addressed a comment from Mach Chen on the need for two LSP-IDs for associa= ted bi-directional LSPs.  Added a new section which allows for two LSP-= IDs in this case, as well as a mapping to RSVP-TE signaling.

Removed the automatic mapping of tunnel numbers to IF_IDs as this is implem= entation specific.

Addressed the ITU comments as follows:


1.  Not accepted.  The sentence is correct as it is.  It doe= s not say
    that the document defines all identifier nor does i= t mention LSPs,
    tunnels or connections.

2.  Accepted

3.  Accepted in principle - removed sentence.  Note that the TLV<= BR>     definitions are what actually define the order.

4.  Accepted

5.  Added the Operator ID.  However the divergent naming of endpo= int
    was not added.  Such a move would add a great = deal of complexity.
    Need to see clear market demand before adding.

6.  Accepted in principle - wording is diffent since some of the
    changes propose are to a direct quote from another = RFC.

7.  The Global_ID is not an ASN.  A non-zero Global_ID MUST be de= rived
    from an ASN owned by the operator.  In a node = running both MPLS-TP
    and BGP the ASN and the Global_ID could have the sa= me value.  But
    the ASN could be another ASN also owned by the oper= ator.

8.  Accepted

9.  Accepted with wording changes.  In particular the comment is<= BR>     addressed in a new paragraph immediately after the = paragraph
    where the comment was made.

10. Accepted

11. Accepted with wording changed.

12. Accepted

13. Accepted

14. Accepted in principle.  The comment was addressed by making a
    reference to hierarchical tunnels in the last parag= raph of section
    4.

15. Accepted

16. Accepted

17, 18. Paragraph rewritten for clarification.

19. Accepted

20. Per comment 26, this text was not moved.   

21. Accepted but used East/West instead of A/Z

22. This has been stable text for over a year and half.  We see no
    point in changing it now.

23. Type-o fixed

24. This is the naming for co-routed bi-directional tunnels.  See new<= BR>     text in section xx for associated bi-directional
25. This is an artifact cause by the type-o which was addressed per comment= 23.

26. Accepted.  Added text on associated bi-directional.

27. Type-o fixed

28. Type-o fixed

29. Accepted, text added.

30. Accepted but used East/West instead of A/Z

31. Not accepted.  The PW_ID is not unique to a node, but to a node     pair.  To automatically generate MEP_IDs in th= is case would
    require both node_ids and both global_ids for globa= l uniqueness.
    Further, having another option just makes for more = complication.

32. Accepted but used East/West instead of A/Z

33. The AGI is used in defining L2VPNs

34. Rather than incorporating the comment, the note was removed as it
    was not really appropriate for this document.

35. Not accepted.  Believe the existing text is clear enough.  Th= e
    MEP-ID is required and there are two defined.  = ;This document does
    not specify usage.

36. Accepted with wording changes - new text is "where the Node_ID is<= BR>     the node in which the MEP is located and the AC_ID = is the AC_ID of
    the Pseudowire at that node."

37. Changed name to Pseudowire Segments Endpoint ID or PW_SE_ID

38. Type-o fixed

39. Accepted

 --B_3382021737_199398104-- From Internet-Drafts@ietf.org Thu Mar 3 15:45:03 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E86E23A68C4; Thu, 3 Mar 2011 15:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, 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 8aR5ZyKkONMR; Thu, 3 Mar 2011 15:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8494F3A6816; Thu, 3 Mar 2011 15:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110303234501.22132.37520.idtracker@localhost> Date: Thu, 03 Mar 2011 15:45:01 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-identifiers-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 23:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS-TP Identifiers Author(s) : M. Bocci, et al. Filename : draft-ietf-mpls-tp-identifiers-04.txt Pages : 16 Date : 2011-03-03 This document specifies identifiers for MPLS-TP objects. Included are identifiers conformant to existing ITU conventions and identifiers which are compatible with existing IP, MPLS, GMPLS, and Pseudowire definitions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-identifiers-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-identifiers-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-03153653.I-D@ietf.org> --NextPart-- From manav.bhatia@alcatel-lucent.com Thu Mar 3 16:17:43 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36543A68B7; Thu, 3 Mar 2011 16:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.83 X-Spam-Level: X-Spam-Status: No, score=-6.83 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6axDorHFq6zE; Thu, 3 Mar 2011 16:17:42 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 9E1C03A68B5; Thu, 3 Mar 2011 16:17:42 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p240IiSa002944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Mar 2011 18:18:46 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p240Igh8011179 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Mar 2011 05:48:43 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 4 Mar 2011 05:48:42 +0530 From: "Bhatia, Manav (Manav)" To: Shahram Davari , "stbryant@cisco.com" , "mpls@ietf.org" Date: Fri, 4 Mar 2011 05:48:41 +0530 Thread-Topic: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Thread-Index: AcvZvQG5UD8w+gNWTPGhD7ic5ow2KQAD+zuQAA0nAmA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFCC81922@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4D6FBC8C.50904@cisco.com> <2C2F1EBA8050E74EA81502D5740B4BD6956C122C58@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6956C122C58@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350CFCC81922INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 00:17:44 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350CFCC81922INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with this. NTP is mostly done in SW as against 1588 which is alread= y supported in HW in most vendor platforms. Going by this, i would like to = see 1588 as the default. Cheers, Manav ________________________________ From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Shahram Davari Sent: Thursday, March 03, 2011 11.34 PM To: stbryant@cisco.com; mpls@ietf.org Cc: tictoc@ietf.org Subject: Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Hi Stewart, Accurate delay measurement requires the Timestamp to be done in HW. It is t= rue that most routers support NTP today, but the majority of those are real= ly maintained in Software and AFAIK most HW based timestamps implementation= s are 1588 based and really the industry is shifting toward 1588 and SyncE = for network synchronization. So I support 1588 as being the default. Thanks, Shahram From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Stewart Bryant Sent: Thursday, March 03, 2011 8:07 AM To: mpls@ietf.org Cc: tictoc@ietf.org Subject: [TICTOC] draft-ietf-mpls-loss-delay Timestamp We have received a LC comment on draft-ietf-mpls-loss-delay concerning the = default timestamp. In the first version of the draft we proposed NTP, but following initial co= mments from the MPLS-TP community we changed to IEEE1588. This requirement = for IEEE1588 can be traced back to the choice of using IEEE1588 in Y.1731. We have now received a LC request to change the default back to NTP. NTP is the "natural" choice for an IETF protocol. NTP is specified in IETF = and is used in other MPLS protocols such as LSP ping. It is implemented on = almost every host and every router. However in general the implementations = provides a relatively low precision timestamp, and the NTP time distributio= n infrastructure operates on a best effort basis. Thus even a good client i= mplementation would normally have a relatively low quality path to the serv= er, which would result in a low quality of timestamp. NTP could be made to = work to higher accuracy, but defacto upgrading NTP and providing high quali= ty NTP paths to the time servers is not getting much attention. Computing t= imestamp differences is easier with NTP. On the other hand IEEE1588 has defacto become the two way time tranfer prot= ocol for precision applications. IEEE1588 only provides high quality time i= n well engineered networks with some form of hop by hop assistance. It is n= ot widely implemented other than in equipment targeted to specific markets,= although one of those markets is in mobile backhaul applications where we= expect to see significant initial deployment of MPLS-TP. Computing timesta= mp differences is harder with IEEE1588 The loss-delay work is targeting to be able to do one way packet delay meas= urement, so it does need a higher quality of timestamp than is required in = general purpose network instrumentation. Converting from IEEE1588 to NTP is not trivial, since they use different ep= ochs, and different representations of sub-second time. In a "traditional" = NTP implementation the time error due to on the fly conversion is likely to= be small compared to the time error in the time synchronization system, bu= t an IEEE1588 system would need hardware conversion to maintain the accurac= y for an NTP timestamp. So the question arises, should we make IEEE1588 or NTP the default for draf= t-ietf-mpls-loss-delay. Much as I would like to suggest that we should go b= ack to NTP for consistency with other IETF protocols, I have difficulty rec= onciling this with the situation in network deployments and thus suggest th= at we continue to use IEEE1588. What is the opinion of the working group? Stewart (speaking as a draft editor) --_000_7C362EEF9C7896468B36C9B79200D8350CFCC81922INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I agree with this. NTP is mostly done in SW as aga= inst 1588=20 which is already supported in HW in most vendor platforms. Going by this,&n= bsp;i=20 would like to see 1588 as the default.
 
Cheers, Manav

From: tictoc-bounces@ietf.org=20 [mailto:tictoc-bounces@ietf.org] On Behalf Of Shahram=20 Davari
Sent: Thursday, March 03, 2011 11.34 PM
To:=20 stbryant@cisco.com; mpls@ietf.org
Cc:=20 tictoc@ietf.org
Subject: Re: [TICTOC] draft-ietf-mpls-loss-dela= y=20 Timestamp

Hi=20 Stewart,

 

Accurate=20 delay measurement requires the Timestamp to be done in HW. It is true tha= t=20 most routers support NTP today, but the majority of those are really=20 maintained in Software and AFAIK most HW based timestamps implementations= are=20 1588 based and really the industry is shifting toward 1588 and SyncE for= =20 network synchronization. So I support 1588 as being the=20 default.

 

Thanks,

Shahram

 

From:=20 tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= =20 Stewart Bryant
Sent: Thursday, March 03, 2011 8:07=20 AM
To: mpls@ietf.org
Cc:=20 tictoc@ietf.org
Subject: [TICTOC] draft-ietf-mpls-loss-delay=20 Timestamp

 


We have received a= LC=20 comment on draft-ietf-mpls-loss-delay concerning the default=20 timestamp.

In the first version of the draft we proposed NTP, but= =20 following initial comments from the MPLS-TP community we changed to IEEE1= 588.=20 This requirement for IEEE1588 can be traced back to the choice of using=20 IEEE1588 in Y.1731.

We have now received a LC request to change th= e=20 default back to NTP.

NTP is the "natural" choice for an IETF proto= col.=20 NTP is specified in IETF and is used in other MPLS protocols such as LSP = ping.=20 It is implemented on almost every host and every router. However in gener= al=20 the implementations provides a relatively low precision timestamp, and th= e NTP=20 time distribution infrastructure operates on a best effort basis. Thus ev= en a=20 good client implementation would normally have a relatively low quality p= ath=20 to the server, which would result in a low quality of timestamp. NTP coul= d be=20 made to work to higher accuracy, but defacto upgrading NTP and providing = high=20 quality NTP paths to the time servers is not getting much attention. Comp= uting=20 timestamp differences is easier with NTP.

On the other hand IEEE15= 88=20 has defacto become the two way time tranfer protocol for precision=20 applications. IEEE1588 only provides high quality time in well engineered= =20 networks with some form of hop by hop assistance. It is not widely implem= ented=20 other than in equipment targeted to specific markets, although one of tho= se=20 markets is in mobile backhaul applications  where we expect to see=20 significant initial deployment of MPLS-TP. Computing timestamp difference= s is=20 harder with IEEE1588

The loss-delay work is targeting to be able t= o do=20 one way packet delay measurement, so it does need a higher quality of=20 timestamp than is required in general purpose network=20 instrumentation.

Converting from IEEE1588 to NTP is not trivial, s= ince=20 they use different epochs, and different representations of sub-second ti= me.=20 In a "traditional" NTP implementation the time error due to on the fly=20 conversion is likely to be small compared to the time error in the time=20 synchronization system, but an IEEE1588 system would need hardware conver= sion=20 to maintain the accuracy for an NTP timestamp.

So the question ari= ses,=20 should we make IEEE1588 or NTP the default for draft-ietf-mpls-loss-delay= .=20 Much as I would like to suggest that we should go back to NTP for consist= ency=20 with other IETF protocols, I have difficulty reconciling this with the=20 situation in network deployments and thus suggest that we continue to use= =20 IEEE1588.

What is the opinion of the working group?

Stewart= =20 (speaking as a draft editor)

--_000_7C362EEF9C7896468B36C9B79200D8350CFCC81922INBANSXCHMBSA_-- From zhang.fei3@zte.com.cn Thu Mar 3 20:05:23 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EDD03A6926; Thu, 3 Mar 2011 20:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.387 X-Spam-Level: X-Spam-Status: No, score=-100.387 tagged_above=-999 required=5 tests=[AWL=1.451, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 JGzcipaFH77m; Thu, 3 Mar 2011 20:05:22 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id A07C83A6920; Thu, 3 Mar 2011 20:05:19 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101570495873; Fri, 4 Mar 2011 12:04:11 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84746.5667502205; Fri, 4 Mar 2011 12:06:22 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p2446HYU018411; Fri, 4 Mar 2011 12:06:17 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) To: sboutros@cisco.com, msiva@cisco.com, ssaxena@cisco.com, vishwas@ipinfusion.com, swallow@cisco.com, aldrin.ietf@gmail.com, mpls@ietf.org, mpls-tp@ietf.org MIME-Version: 1.0 X-KeepSent: 90D453BE:251E5CDA-48257849:000F2901; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 4 Mar 2011 12:06:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-04 12:06:17, Serialize complete at 2011-03-04 12:06:17 Content-Type: multipart/alternative; boundary="=_alternative 00168A6448257849_=" X-MAIL: mse01.zte.com.cn p2446HYU018411 Subject: [mpls] [mpls-tp] Question to draft-boutros-mpls-lsp-ping-ttl-tlv-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 04:05:23 -0000 This is a multipart message in MIME format. --=_alternative 00168A6448257849_= Content-Type: text/plain; charset="US-ASCII" Dear Authors, I have read this version of the draft, here are some comments, please consider 1. The last paragraph in introduction , "The scope of this TTL TLV is currently limited to MS-PW or Bidirectional co-routed MPLS TP LSPs." Just my two cents, I think you can enlarge the scope to inlcude associated bidirectional LSP, for the initiator can learn the TTL TLV value from the NMS or control plane. Furthermore, the same intermediate nodes know the binding relationship of the two unidirectional LSPs (one from west to east and the other one form east to west) according to the definition in RFC5654. 2. Section 4.2 "Return TTL Value = (TTL TLV Value)-(Incoming Label TTL)-1" SHOULD be "Return TTL Value = (TTL TLV Value)-(Incoming Label TTL)+1" ? Fei --=_alternative 00168A6448257849_= Content-Type: text/html; charset="US-ASCII"
Dear Authors,

I have read this version of the draft, here are some comments, please consider

1. The last paragraph in introduction , "The  scope  of  this  TTL  TLV  is  currently  limited  to  MS-PW  or Bidirectional co-routed MPLS TP LSPs."

Just my two cents, I think you can enlarge the scope to inlcude associated bidirectional LSP, for the initiator can learn the TTL TLV value from the NMS or control plane. Furthermore, the same intermediate nodes know the binding relationship of the two unidirectional LSPs (one from west to east and the other one form east to west) according to the definition in RFC5654.

2. Section 4.2
 "Return TTL Value = (TTL TLV Value)-(Incoming Label TTL)-1" SHOULD be "Return TTL Value = (TTL TLV Value)-(Incoming Label TTL)+1" ?

Fei --=_alternative 00168A6448257849_=-- From zheng.zhi@zte.com.cn Thu Mar 3 23:02:28 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85ECE3A68B8 for ; Thu, 3 Mar 2011 23:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7KYndOzb+uWI for ; Thu, 3 Mar 2011 23:02:23 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 6AB9B3A67AE for ; Thu, 3 Mar 2011 23:02:22 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 20595806486374; Fri, 4 Mar 2011 14:58:20 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84746.4699248914; Fri, 4 Mar 2011 14:55:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p246tB4M006348; Fri, 4 Mar 2011 14:55:12 +0800 (GMT-8) (envelope-from zheng.zhi@zte.com.cn) To: nitinb@juniper.net, kireeti@juniper.net, swallow@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zheng.zhi@zte.com.cn Date: Fri, 4 Mar 2011 14:52:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-04 14:55:12, Serialize complete at 2011-03-04 14:55:12 Content-Type: multipart/alternative; boundary="=_alternative 00265CEA48257849_=" X-MAIL: mse01.zte.com.cn p246tB4M006348 Cc: mpls@ietf.org Subject: [mpls] Questions on draft-ietf-mpls-lsp-ping-enhanced-dsmap-08 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 07:02:28 -0000 This is a multipart message in MIME format. --=_alternative 00265CEA48257849_= Content-Type: text/plain; charset="US-ASCII" Dear authors, I have some questions on draft-ietf-mpls-lsp-ping-enhanced-dsmap-08. 1. In the specified paragraph following "Remote peer addrss" in Section 3.3.3, there is an example described as "E.g. In the LDP over RSVP case Figure 1, router B would respond back with the address of router D as the remote peer address for the LDP FEC being traced." The Figure 1 mentioned is: A B C D E o -------- o -------- o --------- o --------- o \_____/ | \______/ \______/ | \______/ LDP | RSVP RSVP | LDP | | \____________________/ LDP According to the usage described in this draft, there is no FEC Stack change sub-TLV for the LDP FEC being traced. And, there will be only one FEC Stack change sub-TLV, for the RSVP FEC. In this example, does it mean that the remote peer address for the LDP FEC will be included in the FEC Stack change sub-TLV for the RSVP FEC? I don't believe this implementation is suitable, or maybe this example is not suitable here. How to use this remote peer address field exactly? IMHO, the Remote Peer Address is for the build of a LSP topology. However, if without this field in the FEC Stack change sub-TLV, there is no impact on the normal tracing procedures, and the LSP topology will also be build with the information from the other field in FEC Stack change sub-TLVs. 2. AFAIK, the FEC Stack change sub-TLV in the echo reply message is for the initiator to have a knowledge of the Target FEC change. As described in RFC4379 and draft-ietf-mpls-p2mp-lsp-ping-15, the initiator SHOULD copy the Downstream Detailed Mapping TLV into its next echo request. That means the FEC Stack change sub-TLV in the DDM TLV will be also in the next echo request message. I don't think the reciever need this sub-TLV in the echo request. So IMHO it is not necessary to contain this sub-TLV in the echo request message. 3. In the algorithm section 4.3.1.2, there missing a "{" at the end of line fourth " while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv)) " Thanks, Zhi -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00265CEA48257849_= Content-Type: text/html; charset="US-ASCII"
Dear authors,

I have some questions on draft-ietf-mpls-lsp-ping-enhanced-dsmap-08.

1. In the specified paragraph following "Remote peer addrss" in Section 3.3.3, there is an example described as
"E.g.  In the LDP over RSVP case Figure 1, router B would respond back with the address of router D as the remote peer address for the LDP FEC being traced."

The Figure 1 mentioned is:
   A           B           C            D            E
   o -------- o -------- o --------- o --------- o
     \_____/  | \______/    \______/ | \______/
       LDP    |   RSVP        RSVP   |    LDP
              |                      |
               \____________________/
                         LDP

According to the usage described in this draft, there is no FEC Stack change sub-TLV for the LDP FEC being traced. And, there will be only one FEC Stack change sub-TLV, for the RSVP FEC. In this example, does it mean that the remote peer address for the LDP FEC will be included in the FEC Stack change sub-TLV for the RSVP FEC? I don't believe this implementation is suitable, or maybe this example is not suitable here. How to use this remote peer address field exactly?
IMHO, the Remote Peer Address is for the build of a LSP topology. However, if without this field in the FEC Stack change sub-TLV, there is no impact on the normal tracing procedures, and the LSP topology will also be build with the information from the other field in FEC Stack change sub-TLVs.

2. AFAIK, the FEC Stack change sub-TLV in the echo reply message is for the initiator to have a knowledge of the Target FEC change. As described in RFC4379 and draft-ietf-mpls-p2mp-lsp-ping-15, the initiator SHOULD copy the Downstream Detailed Mapping TLV into its next echo request. That means the FEC Stack change sub-TLV in the DDM TLV will be also in the next echo request message. I don't think the reciever need this sub-TLV in the echo request. So IMHO it is not necessary to contain this sub-TLV in the echo request message.

3. In the algorithm section 4.3.1.2, there missing a "{" at the end of line fourth
" while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv)) "

Thanks,
Zhi
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00265CEA48257849_=-- From nurit.sprecher@nsn.com Fri Mar 4 02:31:10 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044D73A68AF; Fri, 4 Mar 2011 02:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wWFnSwiR+Fw2; Fri, 4 Mar 2011 02:31:08 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 22D333A6827; Fri, 4 Mar 2011 02:31:07 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p24AWCmr028985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Mar 2011 11:32:12 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p24AW9ut002907; Fri, 4 Mar 2011 11:32:12 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Mar 2011 11:32:09 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBDA57.6A2875A0" Date: Fri, 4 Mar 2011 11:32:07 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A532640371EB75@DEMUEXC014.nsn-intra.net> In-Reply-To: <4D6FBC8C.50904@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-ietf-mpls-loss-delay Timestamp Thread-Index: AcvZvQljbsfdFwavRi6EXHjRLSg3FwAmavbQ References: <4D6FBC8C.50904@cisco.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: , X-OriginalArrivalTime: 04 Mar 2011 10:32:09.0148 (UTC) FILETIME=[6A59EFC0:01CBDA57] Cc: "Zhao, Peng \(NSN - CN/Shanghai\)" , "Pietilainen, Antti \(NSN - FI/Espoo\)" , tictoc@ietf.org Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 10:31:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBDA57.6A2875A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart hi, The accuracy targets as described below are approaching a level where on-path support is needed.=20 In this case the clear choice is IEEE 1588 because it specifies on-path support whereas NTP does not.=20 Even without on-path support IEEE 1588 could be better if better accuracy is pursued by sending multiple timing packets per second per slave/client, because standard NTP clients send messages at a very low rate for saving server resources. I support the default of IEEE1588! Best regards, Nurit =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Stewart Bryant Sent: Thursday, March 03, 2011 6:07 PM To: mpls@ietf.org Cc: tictoc@ietf.org Subject: [mpls] draft-ietf-mpls-loss-delay Timestamp =20 We have received a LC comment on draft-ietf-mpls-loss-delay concerning the default timestamp. In the first version of the draft we proposed NTP, but following initial comments from the MPLS-TP community we changed to IEEE1588. This requirement for IEEE1588 can be traced back to the choice of using IEEE1588 in Y.1731. We have now received a LC request to change the default back to NTP. NTP is the "natural" choice for an IETF protocol. NTP is specified in IETF and is used in other MPLS protocols such as LSP ping. It is implemented on almost every host and every router. However in general the implementations provides a relatively low precision timestamp, and the NTP time distribution infrastructure operates on a best effort basis. Thus even a good client implementation would normally have a relatively low quality path to the server, which would result in a low quality of timestamp. NTP could be made to work to higher accuracy, but defacto upgrading NTP and providing high quality NTP paths to the time servers is not getting much attention. Computing timestamp differences is easier with NTP. On the other hand IEEE1588 has defacto become the two way time tranfer protocol for precision applications. IEEE1588 only provides high quality time in well engineered networks with some form of hop by hop assistance. It is not widely implemented other than in equipment targeted to specific markets, although one of those markets is in mobile backhaul applications where we expect to see significant initial deployment of MPLS-TP. Computing timestamp differences is harder with IEEE1588 The loss-delay work is targeting to be able to do one way packet delay measurement, so it does need a higher quality of timestamp than is required in general purpose network instrumentation. Converting from IEEE1588 to NTP is not trivial, since they use different epochs, and different representations of sub-second time. In a "traditional" NTP implementation the time error due to on the fly conversion is likely to be small compared to the time error in the time synchronization system, but an IEEE1588 system would need hardware conversion to maintain the accuracy for an NTP timestamp. So the question arises, should we make IEEE1588 or NTP the default for draft-ietf-mpls-loss-delay. Much as I would like to suggest that we should go back to NTP for consistency with other IETF protocols, I have difficulty reconciling this with the situation in network deployments and thus suggest that we continue to use IEEE1588. What is the opinion of the working group? Stewart (speaking as a draft editor) ------_=_NextPart_001_01CBDA57.6A2875A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stewart hi,

The accuracy targets as described below are approaching a level = where on-path support is needed.

In this case the clear choice is IEEE 1588 because = it specifies on-path support whereas NTP does = not. 

Even without on-path support IEEE 1588 could be better if better = accuracy is pursued by sending multiple timing packets per second per = slave/client, because standard = NTP clients send messages at a very low rate for saving = server resources.

I support the default of IEEE1588!

Best regards,

Nurit

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of ext Stewart Bryant
Sent: Thursday, March 03, 2011 6:07 = PM
To: mpls@ietf.org
Cc: = tictoc@ietf.org
Subject: [mpls] draft-ietf-mpls-loss-delay = Timestamp

 


We have received a LC comment on = draft-ietf-mpls-loss-delay concerning the default timestamp.

In = the first version of the draft we proposed NTP, but following initial = comments from the MPLS-TP community we changed to IEEE1588. This = requirement for IEEE1588 can be traced back to the choice of using = IEEE1588 in Y.1731.

We have now received a LC request to change = the default back to NTP.

NTP is the "natural" choice = for an IETF protocol. NTP is specified in IETF and is used in other MPLS = protocols such as LSP ping. It is implemented on almost every host and = every router. However in general the implementations provides a = relatively low precision timestamp, and the NTP time distribution = infrastructure operates on a best effort basis. Thus even a good client = implementation would normally have a relatively low quality path to the = server, which would result in a low quality of timestamp. NTP could be = made to work to higher accuracy, but defacto upgrading NTP and providing = high quality NTP paths to the time servers is not getting much = attention. Computing timestamp differences is easier with NTP.

On = the other hand IEEE1588 has defacto become the two way time tranfer = protocol for precision applications. IEEE1588 only provides high quality = time in well engineered networks with some form of hop by hop = assistance. It is not widely implemented other than in equipment = targeted to specific markets, although one of those markets is in mobile = backhaul applications  where we expect to see significant initial = deployment of MPLS-TP. Computing timestamp differences is harder with = IEEE1588

The loss-delay work is targeting to be able to do one = way packet delay measurement, so it does need a higher quality of = timestamp than is required in general purpose network = instrumentation.

Converting from IEEE1588 to NTP is not trivial, = since they use different epochs, and different representations of = sub-second time. In a "traditional" NTP implementation the = time error due to on the fly conversion is likely to be small compared = to the time error in the time synchronization system, but an IEEE1588 = system would need hardware conversion to maintain the accuracy for an = NTP timestamp.

So the question arises, should we make IEEE1588 or = NTP the default for draft-ietf-mpls-loss-delay. Much as I would like to = suggest that we should go back to NTP for consistency with other IETF = protocols, I have difficulty reconciling this with the situation in = network deployments and thus suggest that we continue to use = IEEE1588.

What is the opinion of the working = group?

Stewart (speaking as a draft = editor)

------_=_NextPart_001_01CBDA57.6A2875A0-- From Alexander.Vainshtein@ecitele.com Fri Mar 4 03:24:00 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767BF3A69A2; Fri, 4 Mar 2011 03:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 I7LBA-+JVjrd; Fri, 4 Mar 2011 03:23:57 -0800 (PST) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id 602D23A69A0; Fri, 4 Mar 2011 03:23:56 -0800 (PST) X-AuditID: 93eaf2e8-b7c4aae000002fdd-8d-4d70cbc486fb Received: from ilptexch01.ecitele.com (ilptexfe.ecitele.com [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 3B.D3.12253.4CBC07D4; Fri, 4 Mar 2011 13:23:49 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Fri, 4 Mar 2011 13:25:02 +0200 From: Alexander Vainshtein To: "stbryant@cisco.com" , Shahram Davari Date: Fri, 4 Mar 2011 13:25:01 +0200 Thread-Topic: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp Thread-Index: AcvZ9T4KQ/BQddQrS/eOadBJvTNA9QAYJlmy Message-ID: References: <2C2F1EBA8050E74EA81502D5740B4BD6956BE358E6@SJEXCHCCR02.corp.ad.broadcom.com>, <4D701ACF.4020702@cisco.com> In-Reply-To: <4D701ACF.4020702@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAA4ILPTMAIL02eci_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsWyRv6Lhu7R0wW+Bif+MVp8X/GfyWJ9r6fF raUrWS3O393MZrHvUSujxbmncxgtzm+5z2jxt7mH3YHDY9b9s2weU35vZPXYOesuu8eSJT+Z PD482sESwBrFZZOSmpNZllqkb5fAldF69TN7waEZTBUzNz1gbWC8+Iqxi5GTQ0LAROJz3xZ2 CFtM4sK99WxdjFwcQgJnGSX6vi1iAUkICUxmlGi6ZQ9iswnYSmxafZcNxBYRCJXY/O8FM0gD s8BJZom9t9qYQBIsAioSd9ceBZsqLOAocXxNJzNEg5PEhpnrmSBsI4l/TXfAbF4Bf4lHvyaw QSwrk1jf+wFsMaeApsTZyy1gvYxA130/tQasnllAXOLWk/lMEFcLSCzZc54ZwhaVePn4HytE vajEnfb1jBD1+RI939cwQ+wSlDg58wnLBEbRWUhGzUJSNgtJ2QJG5lWMopk5BSVJuekGRnqp yZklqTmpesn5uZsYgdE2+dWnFzsYJ2zWOcTIxMEp1cDo4j/9+m5Hjw+/Gzmq5dW/yDVfWuUi bC/Nda1jxZlvar7nF9ptTEi81J2X9udv+6fZeutVeeQa760R3CC6pnjx82fiq1m1+LYXcar6 tN5ZzHD/nYqageKrFW1nXXgVRecVXJNkv2jHouQXPfG/yb9zmwSdVeLOhUgq16/P7rTYKbvc 4q7cFwslluKMREMt5qLiRAD6SDNQZgIAAA== Cc: "'mpls@ietf.org'" , Idan Kaspit , Robert Rennison , Martin Greenberg , "'tictoc@ietf.org'" , "'PDiamond@semtech.com'" , "'tictoc-bounces@ietf.org'" , Jacob Ruthstein , "'ronc.ntear@gmail.com'" Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 11:24:00 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAA4ILPTMAIL02eci_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Stewart, Shahram and all, Here is my proposal based on reading this thread and some thinking. Instead of trying to specify the mandatory default for the timestamp format= , let's mandate something else: 1. Ability to convert the timestamps from PTP to NTP for 1-way delay meas= urements. * The computational load associated with this operation could result = in relatively low rate of 1-way DM messages (say 1 pps?) in line with the g= eneral direction of the draft which says that loss and delay measurement sh= ould not stretch the network resources. * The direction (PTP to NTP) of conversion has been chosen because co= mputation of differences is simpler for NTP timestamps. 2. Ability to compute differences between pairs of timestamps in the same= format both for NTP and PTP timestamps for 2-way delay measurements. This = operation does not require conversion from one format into another. Neither of the two items above carries with it any special HW requirements.= Hence, IMHO this approach, if accepted, would promote backward compatibili= ty with the installed LSR base while allowing new equipment to benefit from= the HW-based PTP-oriented timestamping mechanisms. Below you can find the chain of reasoning that has led me to this proposal= (you may skip this part if you are not interested:-). 1. I tend to agree with Stewart: neither rollover nor leap seconds are re= ally relevant for the delay measurement application. (I did not think so ye= sterday:-(). 2. AFAIK (and I have discussed in a personal email exchange with the auth= ors of the draft), the required accuracy of delay measurements is not speci= fied - neither in the draft itself (intentionally) nor in other relevant st= andards. * This thread really confirms that - the best I see is a somewhat vag= ue reference to "expectations of the Transport network operators". Did I m= iss something here? * Without these requirements references to comparative "accuracy of t= he timestamps" for NTP vs. PTP in this thread do not make too much sense t= o me 3. The available accuracy of delay measurements depends on many factors i= n addition to the timestamp resolution. E.g., we all know that one-way dela= y measurements require ToD synchronization between two endpoints. It is als= o widely known that, e.g., TDD-based mobile application require ~1 microsec= ond accuracy of ToD synchronization. Hence I conclude that the achievable a= ccuracy of 1-way delay measurements will be probably in the microseconds ra= nge, no matter which protocol and what kind of timestamps we use (as long a= s the granularity of the timestamps is in microseconds). Hence I agree with= Stewart - quite a few the bits in the nanoseconds part of the PTP timesta= mp can be actually ignored 4. The draft we discuss here is NOT an MPLS-TP draft. It is a generic MPL= S draft with an accompanying MPLS-TP document. IMO imposing a TP-derived re= quirement on non-TP equipment doesn't make too much sense 5. The draft inherently supports the situation when the requester and the= responder use different timestamping formats: * For 2-way DM only ability to compute the difference between two NTP= timestamps and two PTP ones is required * For 1-way DM conversion to a single format (e.g., NTP) is required.= While this may be computationally heavy, it is not an operation that has t= o be done in HW or even in hard real-time. If, say, you send the delay meas= urement packets once a second, the originator would have 1" to do this "hea= vy work" - lots of cycles in a modern CPU! BTW, one of the issues *not add= ressed* in the draft is the rate at which delay measurement messages are su= pposed to be sent * The installed base of LSRs will probably benefit from using SW-gene= rated NTP timestamps (with whatever accuracy can be achieved) * New equipment that supports HW timestamping for PTP "close to PHY" = will benefit from using PTP timestamps. My 2c, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Stewart Br= yant [stbryant@cisco.com] Sent: Friday, March 04, 2011 12:48 AM To: Shahram Davari Cc: 'mpls@ietf.org'; 'tictoc@ietf.org'; 'PDiamond@semtech.com'; 'tictoc-bou= nces@ietf.org'; 'ronc.ntear@gmail.com' Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp I do not think that rollover or leap seconds are much of a problem in this = application. We are measuring the transit time of a packet across a network= . That is less than a second. Rollover or leap second errors mean that we m= ake a mistake once in every 136 years in the first case and maybe never in = the case of leap seconds. I am sure that it would be acceptable to simply s= tate that for that for that one second at some time in the future we cannot= make that measurement. BTW we are only going to use 32 bits of seconds and 32 bits of sub seconds = in the 1588 case, and even then most of the sub second bits will be ignored= . I don't thing that we need to be measuring time of flight over 8" of cab= le. Stewart On 03/03/2011 22:12, Shahram Davari wrote: Agree. Shahram ________________________________ From: Ron Cohen To: Shahram Davari Cc: PDiamond@semtech.com ; mpls@ietf.org ; tictoc-bounces@ietf.org ; tic= toc@ietf.org Sent: Thu Mar 03 13:35:11 2011 Subject: Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Hi Shahram, I guess adding a requirement to take timestamp rollover into ac= count would do. If there is a strong reason to also leave NTP timestamp as = an option, a note explaining the ramification of leap seconds should be add= ed. I suggest that a continuous timescale (i.e. PTP) would be selected in t= he draft as the default/must option. Best, Ron On Thu, Mar 3, 2011 at 9:45 PM, Shahram Davari > wrote: Hi Ron, Although the PTPv2 is 80 bytes, but I don=92t see a need to use all 80 byte= s for delay measurement. The upper 2^32 seconds covers almost 136 years, wh= ich should be good enough to measure delay. Also lets=92 be compatible with= Y.1731 format since that HW already exist. Thx Shahram From: Ron Cohen [mailto:ronc.ntear@gmail.com] Sent: Thursday, March 03, 2011 11:22 AM To: PDiamond@semtech.com Cc: Shahram Davari; mpls@ietf.org; tictoc-bounces@iet= f.org; tictoc@ietf.org Subject: Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Hi, I apologize in advance if my comments below where already been discussed. The draft specify using PTPv1 timestamp format and not PTPv2 timestamp form= at. The seconds part of the PTPv2 timestamp is 48bits, and not 32bits as wr= itten in the draft. NTP timestamps will roll over in 2036. PTPv2 timestamps= do not rollover. I don't think its advisable to include timestamps that rolls over ~20 years= from now. In addition, NTP timestamp, unlike PTP timestamp, 'jumps' in leap seconds e= vents. This makes calculation of time differences hard, and would render so= me measurements ambiguous. It is much easier to use continuous timescale li= ke PTP. In my opinion changing the timestamp format to PTPv2 timestamp format (i.e.= 48bit/32bit sec/ns) should be the right way to go. I would also remove the= NTP timestamp format option to avoid leap seconds confusion and 2036 rollo= ver events. Best, Ron On Thu, Mar 3, 2011 at 8:26 PM, > wrote: My feeling is 1588 is the right answer in the long run since it is already coupled to the hardware and widely deployed in networks using the "packet clock derived time" in precise time and frequency delivery. Pat "Shahram Davari" To Sent by: "stbryant@cisco.com" tictoc-bounces@ie >, tf.org "mpls@ietf.org" > cc "tictoc@ietf.org" > 03/03/2011 10:05 Subject AM Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Hi Stewart, Accurate delay measurement requires the Timestamp to be done in HW. It is true that most routers support NTP today, but the majority of those are really maintained in Software and AFAIK most HW based timestamps implementations are 1588 based and really the industry is shifting toward 1588 and SyncE for network synchronization. So I support 1588 as being the default. Thanks, Shahram From: tictoc-bounces@ietf.org [mailto:ticto= c-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Thursday, March 03, 2011 8:07 AM To: mpls@ietf.org Cc: tictoc@ietf.org Subject: [TICTOC] draft-ietf-mpls-loss-delay Timestamp We have received a LC comment on draft-ietf-mpls-loss-delay concerning the default timestamp. In the first version of the draft we proposed NTP, but following initial comments from the MPLS-TP community we changed to IEEE1588. This requirement for IEEE1588 can be traced back to the choice of using IEEE1588 in Y.1731. We have now received a LC request to change the default back to NTP. NTP is the "natural" choice for an IETF protocol. NTP is specified in IETF and is used in other MPLS protocols such as LSP ping. It is implemented on almost every host and every router. However in general the implementations provides a relatively low precision timestamp, and the NTP time distribution infrastructure operates on a best effort basis. Thus even a good client implementation would normally have a relatively low quality path to the server, which would result in a low quality of timestamp. NTP could be made to work to higher accuracy, but defacto upgrading NTP and providing high quality NTP paths to the time servers is not getting much attention. Computing timestamp differences is easier with NTP. On the other hand IEEE1588 has defacto become the two way time tranfer protocol for precision applications. IEEE1588 only provides high quality time in well engineered networks with some form of hop by hop assistance. It is not widely implemented other than in equipment targeted to specific markets, although one of those markets is in mobile backhaul applications where we expect to see significant initial deployment of MPLS-TP. Computing timestamp differences is harder with IEEE1588 The loss-delay work is targeting to be able to do one way packet delay measurement, so it does need a higher quality of timestamp than is required in general purpose network instrumentation. Converting from IEEE1588 to NTP is not trivial, since they use different epochs, and different representations of sub-second time. In a "traditional" NTP implementation the time error due to on the fly conversion is likely to be small compared to the time error in the time synchronization system, but an IEEE1588 system would need hardware conversion to maintain the accuracy for an NTP timestamp. So the question arises, should we make IEEE1588 or NTP the default for draft-ietf-mpls-loss-delay. Much as I would like to suggest that we should go back to NTP for consistency with other IETF protocols, I have difficulty reconciling this with the situation in network deployments and thus suggest that we continue to use IEEE1588. What is the opinion of the working group? Stewart (speaking as a draft editor) _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAA4ILPTMAIL02eci_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Stewart, Shahram and all,
Here is my proposal based on reading th= is thread and some thinking.
 
Instead of trying to specify the mandat= ory default for the timestamp format, let's mandate something else:
 
  1. Ability to convert the timestamps from P= TP to NTP for 1-way delay measurements.
    • The computational load associated with t= his operation could result in relatively low rate of 1-way DM m= essages (say 1 pps?) in line with the general dir= ection of the draft which says that loss and delay measurement should not stretch the network resources.
      • The direction (PTP to NTP) of conversion h= as been chosen because computation of differences is simpler fo= r NTP timestamps.
  2. Ability to compute differences betw= een pairs of timestamps in the same format both for NTP and PTP timestamps = for 2-way delay measurements. This operation does not require conversion fr= om one format into another.

Neither of the two items above carries wi= th it any special HW requirements. Hence, IMHO this approach, if accepted, = ;would promote backward compatibility with the installed LSR base while all= owing new equipment to benefit from the HW-based PTP-oriented timestam= ping mechanisms.

 

Below you can find  the chain of rea= soning that has led me to this proposal (you may skip this part if you are = not interested:-).

 
  1. I tend to agree with Stewart: neither ro= llover nor leap seconds are really relevant for the delay measu= rement application. (I did not think so yesterday:-().
  2. AFAIK (and I have discu= ssed in a personal email exchange with the authors of the draft), th= e required accuracy of delay measurements is not specified - neither in the= draft itself (intentionally) nor in other relevant standards.
    • This thread really confirms that - the b= est I see is a somewhat vague  reference to "expectations of= the Transport network operators". Did I miss something here?
    • Without these requirements r= eferences to comparative "accuracy of the timestamps"  for N= TP vs. PTP in this thread do not make too much sense to me
  3. The available accuracy of dela= y measurements depends on many factors in addition to the timestamp = resolution. E.g., we all know that one-way delay measurements require = ToD synchronization between two endpoints. It is also widely known that, e.g., TDD-based mobile application require ~= 1 microsecond accuracy of ToD synchronization. Hence I c= onclude that the achievable accuracy of 1-way delay measurements will be pr= obably in the microseconds range, no matter which protocol and what kind of timestamps we use (as long as the g= ranularity of the timestamps is in microseconds). Hence I agree with Stewar= t - quite a few  the bits in the nanoseconds part of the P= TP timestamp can be actually ignored
  4. The draft we discuss here is NOT an= MPLS-TP draft. It is a generic MPLS draft with an accompanying MPLS-TP doc= ument. IMO imposing a TP-derived requirement on non-TP equipment<= a> doesn't make too much sense
  5. The draft inherently supports the s= ituation when the requester and the responder use different times= tamping formats:
    • For 2-way DM only ability to compute the= difference between two NTP timestamps and two PTP ones is required
    • For 1-way DM conversion to a single= format (e.g., NTP) is required. While this may be computationally hea= vy, it is not an operation that has to be done in HW or even in hard real-t= ime. If, say, you send the delay measurement packets once a second, the ori= ginator would have 1" to do this "heavy work" - lots of cycles in a modern CPU!  BTW, one of the is= sues *not addressed* in the draft is the rate at which delay measurement me= ssages are supposed to be sent
    • The installed base of LSRs will pro= bably benefit from using SW-generated NTP timestamps (with whatever ac= curacy can be achieved)
    • New equipment that supports HW = ;timestamping for PTP "close to PHY" will benefit f= rom using PTP timestamps.
 
My 2c,
     Sasha
 
 
 
 
 
 
 
 
 
 
 
 
 
 
From: mpls-bounce= s@ietf.org [mpls-bounces@ietf.org] On Behalf Of Stewart Bryant [stbryant@ci= sco.com]
Sent: Friday, March 04, 2011 12:48 AM
To: Shahram Davari
Cc: 'mpls@ietf.org'; 'tictoc@ietf.org'; 'PDiamond@semtech.com'; 'tic= toc-bounces@ietf.org'; 'ronc.ntear@gmail.com'
Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp
I do not think that rollover or leap seconds are much of a problem in = this application. We are measuring the transit time of a packet across a ne= twork. That is less than a second. Rollover or leap second errors mean that= we make a mistake once in every 136 years in the first case and maybe never in the case of leap seconds. I= am sure that it would be acceptable to simply state that for that for that= one second at some time in the future we cannot make that measurement.

BTW we are only going to use 32 bits of seconds and 32 bits of sub seconds = in the 1588 case, and even then most of the sub second bits will be ignored= . I don't thing that we need to be measuring time of flight over 8" of=   cable.

Stewart

On 03/03/2011 22:12, Shahram Davari wrote:
Agree.

Shahram

From: Ron Cohen <ronc.ntear@gmail.com>
To: Shahram Davari
Cc: PDiamond@semtech.com <PDiamond@semtech.com>; mpls@ietf.org <mpls@ietf.org>; tictoc-bounces@ietf.org = <tictoc-bounces@ietf.org>; ticto= c@ietf.org <tict= oc@ietf.org>
Sent: Thu Mar 03 13:35:11 2011
Subject: Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp

Hi Shahram, I guess adding a requirement to take timestamp= rollover into account would do. If there is a strong reason to also leave = NTP timestamp as an option, a note explaining the ramification of leap seco= nds should be added. I suggest that a continuous timescale (i.e. PTP) would be selected in the draft as the de= fault/must option. Best, Ron

On Thu, Mar 3, 2011 at 9:45 PM, Shahram Davari <= span dir=3D"ltr"> <davari@broadcom.com> wrote:

Hi Ron,

 

Although the PTPv2 is 80 bytes, but I don=92t see a need to use all 80 b= ytes for delay measurement. The upper 2^32 seconds covers almost 136 years,= which should be good enough to measure delay. Also lets=92 be compatible with Y.1731 format since that HW already= exist.

 

Thx

Shahram

 

From:<= span style=3D"FONT-SIZE: 10pt"> Ron Cohen [mailto:ronc.ntear@gmail.com]
Sent: Thursday, March 03, 2011 11:22 AM
To: PDiamond@semtech.com=
Cc: Shahram Davari; mpls@ietf.org; tictoc-bounces@ietf.org; tictoc@ietf= .org
Subject: Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp

 

Hi,

I apologize in advance if my comments below where already been discussed.
The draft specify using PTPv1 timestamp format and not PTPv2 timestamp form= at. The seconds part of the PTPv2 timestamp is 48bits, and not 32bits as wr= itten in the draft. NTP timestamps will roll over in 2036. PTPv2 timestamps= do not rollover.

I don't think its advisable to include timestamps that rolls over ~20 years= from now.

In addition, NTP timestamp, unlike PTP timestamp, 'jumps' in leap seconds e= vents. This makes calculation of time differences hard, and would render so= me measurements ambiguous. It is much easier to use continuous timescale li= ke PTP.

In my opinion changing the timestamp format to PTPv2 timestamp format (i.e.= 48bit/32bit sec/ns) should be the right way to go. I would also remove the= NTP timestamp format option to avoid leap seconds confusion and 2036 rollo= ver events.

Best,
Ron

On Thu, Mar 3, 2011 at 8:26 PM, <PDiamond@semtech.com> wrote:

My feeling is 1588 is the right answer in the long r= un since it is already
coupled to the hardware and widely deployed in networks using the "pac= ket
clock derived time" in precise time and frequency delivery.

Pat



            "Shahram Davari"
            <davari@broadcom.
            com>       &nbs= p;                     &n= bsp;                     =     To
            Sent by:       &nb= sp;          "stbryant@cisco.com"
            tictoc-bounces@ie     &= nbsp;   <stbryant@cisco.com>,
            tf.org               &nb= sp;    "mpls@ietf.org&q= uot; <mpls@ietf.org>
                     = ;                     &nb= sp;                     &= nbsp;      cc
                     = ;                 "tictoc@ietf.org" <tictoc@ietf.org>
            03/03/2011 10:05     &n= bsp;                     =            Subject
            AM         &n= bsp;              Re: [TICTOC]

              &nb= sp;                     &= nbsp; draft-ietf-mpls-loss-delay
                     = ;                 Timestamp










Hi Stewart,

Accurate delay measurement requires the Timestamp to be done in HW. It is true that most routers support NTP today, but the majority of those are
really maintained in Software and AFAIK most HW based timestamps
implementations are 1588 based and really the industry is shifting toward 1588 and SyncE for network synchronization. So I support 1588 as being the<= br> default.

Thanks,
Shahram

From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.or= g] On Behalf Of
Stewart Bryant
Sent: Thursday, March 03, 2011 8:07 AM
To: mpls@ietf.org
Cc: tictoc@ietf.org
Subject: [TICTOC] draft-ietf-mpls-loss-delay Timestamp


We have received a LC comment on draft-ietf-mpls-loss-delay concerning the<= br> default timestamp.

In the first version of the draft we proposed NTP, but following initial comments from the MPLS-TP community we changed to IEEE1588. This
requirement for IEEE1588 can be traced back to the choice of using IEEE1588=
in Y.1731.

We have now received a LC request to change the default back to NTP.

NTP is the "natural" choice for an IETF protocol. NTP is specifie= d in IETF
and is used in other MPLS protocols such as LSP ping. It is implemented on<= br> almost every host and every router. However in general the implementations<= br> provides a relatively low precision timestamp, and the NTP time
distribution infrastructure operates on a best effort basis. Thus even a good client implementation would normally have a relatively low quality
path to the server, which would result in a low quality of timestamp. NTP could be made to work to higher accuracy, but defacto upgrading NTP and
providing high quality NTP paths to the time servers is not getting much attention. Computing timestamp differences is easier with NTP.

On the other hand IEEE1588 has defacto become the two way time tranfer
protocol for precision applications. IEEE1588 only provides high quality time in well engineered networks with some form of hop by hop assistance. It is not widely implemented other than in equipment targeted to specific markets, although one of those markets is in mobile backhaul applications where we expect to see significant initial deployment of MPLS-TP. Computing=
timestamp differences is harder with IEEE1588

The loss-delay work is targeting to be able to do one way packet delay
measurement, so it does need a higher quality of timestamp than is required=
in general purpose network instrumentation.

Converting from IEEE1588 to NTP is not trivial, since they use different epochs, and different representations of sub-second time. In a
"traditional" NTP implementation the time error due to on the fly=
conversion is likely to be small compared to the time error in the time
synchronization system, but an IEEE1588 system would need hardware
conversion to maintain the accuracy for an NTP timestamp.

So the question arises, should we make IEEE1588 or NTP the default for
draft-ietf-mpls-loss-delay. Much as I would like to suggest that we should<= br> go back to NTP for consistency with other IETF protocols, I have difficulty=
reconciling this with the situation in network deployments and thus suggest=
that we continue to use IEEE1588.

What is the opinion of the working group?

Stewart (speaking as a draft editor)

_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
= https://www.ietf.org/mailman/listinfo/tictoc


_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
= https://www.ietf.org/mailman/listinfo/tictoc

 



_______________________________________________
mpls mailing list
mpls@ie=
tf.org
https://www.ietf.org/mailman/listinfo/mpls



--=20
For corporate legal information go to:

http://www.cisco.com/=
web/about/doing_business/legal/cri/index.html
--_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAA4ILPTMAIL02eci_-- From danfrost@cisco.com Fri Mar 4 04:08:00 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A92B3A69BA for ; Fri, 4 Mar 2011 04:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 PdooNXB76U6R for ; Fri, 4 Mar 2011 04:07:58 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 79D753A69A8 for ; Fri, 4 Mar 2011 04:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=danfrost@cisco.com; l=3244; q=dns/txt; s=iport; t=1299240547; x=1300450147; h=date:from:to:subject:message-id:references:mime-version: in-reply-to; bh=8wH7FwMzPIwvnNGg/RmgcPuz/8CdEU4Whfu0UyR/YO4=; b=TxElreTDKzE9/k/loMj9qB/B8BYllIq6nLaVAQZK2EXHbxvLBnUXrtwT X+y2YD7ZRFJ6RCbT+BkAwK+vRSCsUGWL1YdxgBKVXPdciN+oFDTurrjsN bx9oHV3Oji2N4yUGhj/9jK52Gwbz8cjhQDfJf9yc6BxLebZvJ6g5YiPks g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGZlcE1AZnwM/2dsb2JhbACmY3SiUZt+hWEEjC8 X-IronPort-AV: E=Sophos;i="4.62,263,1297036800"; d="scan'208";a="222194131" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 04 Mar 2011 12:09:07 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [64.100.19.13]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p24C97ei014511 for ; Fri, 4 Mar 2011 12:09:07 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id p24C97h2023123 for ; Fri, 4 Mar 2011 07:09:07 -0500 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id p24C97EJ023122 for mpls@ietf.org; Fri, 4 Mar 2011 12:09:07 GMT Date: Fri, 4 Mar 2011 12:09:07 +0000 From: Dan Frost To: mpls@ietf.org Message-ID: <20110304120907.GB21788@cisco.com> References: <000801cbd8f0$f3b272a0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [mpls] [mpls-tp] MPLS WG last call on draft-ietf-mpls-loss-delay-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 12:08:00 -0000 These comments are the outcome of a joint review by Marc and the authors, so they reflect our intent to update the text accordingly. (An exception is the comment about the default timestamp format, which is being discussed in a separate thread on the list.) -d On Thu, Mar 03, 2011 at 04:32:38PM +0100, LASSERRE, MARC (MARC) wrote: > > Sorry, I'm posting the same message again with the right subject this time. > See below for a list of major and minor comments. > > Thanks, > Marc > -------------------------------------------- > > Major comments > > - Section 2.7.9 > > The draft specifies the 1588 (PTP) is the default and a MUST. While there is a good amount of hardware out there that supports 1588 but making this a MUST means that older hardware that supports NTP and not 1588 would require the carrier to upgrade their equipment for this. > > Shouldn't NTP be the default and a MUST, and 1588 PTP an option? > > - Comment #5: Proposed text as last sentence of sections 4.1.3, 4.1.4, > 4.2.[1-3] > > In the case of an invalid message (e.g. request or response), an error report should be made, in a form a response message if the code = 0 or > 1, or as an alarm report. > > Suggest rewording sentence in section 3.1: > > "0x2: No Response Requested. Indicates that no response to the query should be sent. This mode can be used when an NMS is controlling both nodes" > > - Section 3.4 > > After sentence "1: Sequence number. This value indicates that the timestamp field is to be viewed as a simple 64-bit sequence number." > > Suggest adding sentence: The sequence number provides a simple solution for applications that don't need a real absolute timestamp but just an > indication of message ordering. An example is LM exception detection. > > - Section 3.5.1 > > Suggest adding sentence: > > "Asymetrical padding may be useful in the case of OOB response or when different MTUs are used in a bidir path" > > - Suggest deleting "which is usually what is desired." in section 4.1.10 > > - Section 4.1.9 > > Suggestion adding sentence "Separate test message protocol SHOULD include a timeout value that informs the responder when to discard any state associated with this test." > > Minor comments > > - Suggest adding sentence in section 1 > > "The direct method is also known as "frame-based" in [Y.1731]. The inferred method is a superset of the "synthetic" approach being currently specified within Ethernet documents, because it allows for the possiblity of decoupling measurement messages from test messages" > > - editorial - Section 2.1, page 8, 3rd paragraph: change "response code" to "response control code" > > Editorial - Section 2.3, page 10, 7th paragraph: change "response code" to "response control code" > > - Section 2.3 > > Clarify that clock synchronization is required for 2-way channel delay but not for roundtrip delay > > - Fix consistency between 1588v1 and v2 references > > - Editorial - Section 3.5.3: In second paragraph, change "too low" to "too short", and in last paragraph, change "Lower" to "Shorter". > > - Section 4.1.10: We can note that misorderings are rare in the absence of ECMP. > From danfrost@cisco.com Fri Mar 4 09:15:25 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6253A6820; Fri, 4 Mar 2011 09:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 GW6+KRFSTdbV; Fri, 4 Mar 2011 09:15:24 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 296863A6866; Fri, 4 Mar 2011 09:15:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=danfrost@cisco.com; l=874; q=dns/txt; s=iport; t=1299258993; x=1300468593; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=huBs/Vw52hw0dhWwgD4PYQzghLHgoUZqV7TpdJsW+Ig=; b=VR1XLh7OSKqZDCL3WyQ6Q0kbXZp46Y4W4/SaXH0VSMlzu2qFm1z3SkdR ZcNpuYLnhxbVf2nmvtpQaKRCAm9zOlbH9CtHmTa0lz4yIcpICVqZUih4w WC4Qzeltj2DplIjcY7I51LD4S1IGGd1VHsn9ErJaVel2+tW62HJmqk2N2 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKescE1AZnwN/2dsb2JhbACmY3SjQ5tqhWEEjC8 X-IronPort-AV: E=Sophos;i="4.62,264,1297036800"; d="scan'208";a="222650310" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 04 Mar 2011 17:16:33 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [64.100.19.13]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p24HGX7C016772; Fri, 4 Mar 2011 17:16:33 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id p24HGVUb026726; Fri, 4 Mar 2011 12:16:31 -0500 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id p24HGUt1026716; Fri, 4 Mar 2011 17:16:30 GMT Date: Fri, 4 Mar 2011 17:16:30 +0000 From: Dan Frost To: Alexander Vainshtein Message-ID: <20110304171630.GB24642@cisco.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6956BE358E6@SJEXCHCCR02.corp.ad.broadcom.com> <4D701ACF.4020702@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: mpls@ietf.org, tictoc@ietf.org Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 17:15:25 -0000 Hi Sasha, On Fri, Mar 04, 2011 at 07:05:08PM +0200, Alexander Vainshtein wrote: > Stewart, Dan and all, > I have a question regarding the draft which, IMHO, to some extent is > related to the ability to use HW-assisted PTP timestamping. > > The question is, at which moment the DM message receives its Tx > timestamp: before it is queued for transmission or after it has been > extracted from the queue and is ready to be sent on the appropriate > physical media? > > I believe I've asked a similar question in the past with regard to > direct loss measurement. However, I did not find any reference to this > issue in the draft. On this topic please see the last paragraph of Section 2.7.2. Since this draft is intended to be general enough to cover a wide variety of situations, I'm inclined to avoid saying more than is said there. Cheers, -d From lesnix@gmail.com Sat Mar 5 06:59:54 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3DB3A6A7F for ; Sat, 5 Mar 2011 06:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 m5nhgeHshSkc for ; Sat, 5 Mar 2011 06:59:53 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 8F20A3A6A7D for ; Sat, 5 Mar 2011 06:59:53 -0800 (PST) Received: by ywi6 with SMTP id 6so1337052ywi.31 for ; Sat, 05 Mar 2011 07:01:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=L+Ius482ff8B7xgb9RzDslH5zS5ZfiA+u381vMyVfFk=; b=gAKqA9H5pyGKnrx/fxt1lefjAMcu8aoeTDA6kBkhNyPN0NDIx5Im+eBUJuVstxh9Mu yWgDdL1IRHdeEOnoQZUj1qWiqtHhg19xPNDUkO16ljXr61BV9GVxgFeGqXPhHHnNDNZ4 OP+Ao5qjBgcJ3QTXDRfbLkk22QGYvUD1QwxWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=RlmFh2L08ptar4ooPoGSBUxokyARK+YcvjeklTZbQ8PSGeM+iC+GPx5FezwagIHPp3 kdNz9you/s5YNCn7WB0aRtt15xmB0gzVHQeEo5MY3eN+VyWMNnXBQfFHcCzXx9L+vVk2 gnSLcC6Wzig8/eNeod9ATMRs5hRPuKUO+zknk= MIME-Version: 1.0 Received: by 10.100.105.20 with SMTP id d20mr362148anc.248.1299337263818; Sat, 05 Mar 2011 07:01:03 -0800 (PST) Received: by 10.101.1.19 with HTTP; Sat, 5 Mar 2011 07:01:03 -0800 (PST) Date: Sat, 5 Mar 2011 18:01:03 +0300 Message-ID: From: Egor Zimin To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: =?KOI8-R?B?98HMxdLJyiDx09TSxcLP1w==?= Subject: [mpls] Question about RFC 4875 (bud node behavior) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 14:59:54 -0000 Hi all, Are there any document, which specify label allocation behavior for bud nodes in P2MP LSPs (described in 4875) ? Are there any statements about PHP on such nodes ? If no, may be, it has a sense to describe label allocation process on bud nodes in more details ? At the moment there are at least two different implementations exist: 1) Using Implicit/Explicit-null labels, which cause unnecessary replication before bud nodes 2) Using unreserved labels value -- Best regards, Egor Zimin From Alexander.Vainshtein@ecitele.com Sat Mar 5 12:39:09 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC9728C0CF; Sat, 5 Mar 2011 12:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] 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 6B1qOub58bXX; Sat, 5 Mar 2011 12:39:08 -0800 (PST) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id 43D9C3A6844; Sat, 5 Mar 2011 12:39:07 -0800 (PST) X-AuditID: 93eaf2e8-b7c4aae000002fdd-ec-4d729f6022b4 Received: from ilptexch01.ecitele.com (ilptexfe.ecitele.com [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 87.00.12253.06F927D4; Sat, 5 Mar 2011 22:38:56 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Sat, 5 Mar 2011 22:40:15 +0200 From: Alexander Vainshtein To: Dan Frost Date: Sat, 5 Mar 2011 22:40:15 +0200 Thread-Topic: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp Thread-Index: Acvaj/lSbEiJvSlaSumyc+giYJIV2wA5J+5I Message-ID: References: <2C2F1EBA8050E74EA81502D5740B4BD6956BE358E6@SJEXCHCCR02.corp.ad.broadcom.com> <4D701ACF.4020702@cisco.com> , <20110304171630.GB24642@cisco.com> In-Reply-To: <20110304171630.GB24642@cisco.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsWyRv6Lhm7C/CJfgy3/rC2+r/jPZHFr6UpW i7/NPewOzB5Tfm9k9Viy5CdTAFMUl01Kak5mWWqRvl0CV8aiI5tZC9byV6zoe8fSwLiHp4uR k0NCwETiSMsTdghbTOLCvfVsXYxcHEICZxklbmz7wgzhTGaU6J10jxWkik3AVmLT6rtsILaI gJJEQ/9iJhCbWcBD4tvyPYwgNouAisSLeVPAaoQFHCWOr+lkhqh3ktgwcz0ThG0ksXDhDLCZ vAL+Em/bD7CA2EICy5kkVi936mLk4OAU0Jd49kEZJMwIdNz3U2ugVolL3HoynwniaAGJJXvO M0PYohIvH/9jhagXlbjTvp4Rol5HYsHuT2wQtrbEsoWvmSHWCkqcnPmEZQKj2CwkY2chaZmF pGUWkpYFjCyrGEUzcwpKknLTDYz0UpMzS1JzUvWS83M3MQIjafKrTy92ME7YrHOIkYmDU6qB UeLE7N8fDqXMXHTj0q6JG+UmNW4Xk5H2fC98xPbI1AWKGftWFj+b9e70nMDpmgW+t1cVSMs1 Tvk5Yd4sH/fnohFmN2+wXd4U+HTFBunN925WTvL1XrGz7LvJMTtRsy2mpyMnP/af/ItxX7zm ErmZy6XP5Ebm7jo5x+Ss7FTX+7srpD2ntpt1il1UYinOSDTUYi4qTgQAh/SArVQCAAA= Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 20:39:10 -0000 Dan, Lots of thanks for a prompt response. I've looked up Section 2.7.2 as you'v= e suggested.=20 I think that placing the text that deals with location of the loss and dela= y measurement points in the section on QoS is misleading. Would you consider splitting it into a dedicated section? As for the position you've taking: I understand the intention to make the d= raft generic enough and not to prescribe specific location of the measureme= nt points. However, leaving this point open carries with it serious interop= erability issues. As a minimum, I would suggest replacing SHOULD in this te= xt with MUST. My 2c, Sasha ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Dan Frost = [danfrost@cisco.com] Sent: Friday, March 04, 2011 7:16 PM To: Alexander Vainshtein Cc: mpls@ietf.org; tictoc@ietf.org Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp Hi Sasha, On Fri, Mar 04, 2011 at 07:05:08PM +0200, Alexander Vainshtein wrote: > Stewart, Dan and all, > I have a question regarding the draft which, IMHO, to some extent is > related to the ability to use HW-assisted PTP timestamping. > > The question is, at which moment the DM message receives its Tx > timestamp: before it is queued for transmission or after it has been > extracted from the queue and is ready to be sent on the appropriate > physical media? > > I believe I've asked a similar question in the past with regard to > direct loss measurement. However, I did not find any reference to this > issue in the draft. On this topic please see the last paragraph of Section 2.7.2. Since this draft is intended to be general enough to cover a wide variety of situations, I'm inclined to avoid saying more than is said there. Cheers, -d _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls= From lavanya.srivatsa@aricent.com Mon Mar 7 01:46:25 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5EC43A6958 for ; Mon, 7 Mar 2011 01:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 wH0AH6q5eNdu for ; Mon, 7 Mar 2011 01:46:19 -0800 (PST) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id 474473A695F for ; Mon, 7 Mar 2011 01:46:17 -0800 (PST) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id AA5D636B7B; Mon, 7 Mar 2011 15:14:13 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id 94CBC36B4A; Mon, 7 Mar 2011 15:14:13 +0530 (IST) Received: from GUREXMB02.ASIAN.AD.ARICENT.COM ([10.203.171.130]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Mon, 7 Mar 2011 15:17:27 +0530 From: Lavanya Srivatsa To: MPLS TP , "mpls@ietf.org" , "ahmpls-tp@lists.itu.int" Date: Mon, 7 Mar 2011 15:17:25 +0530 Thread-Topic: RE:[mpls-tp] [mpls] MPLS WG last call on draft-ietf-mpls-loss-delay-01 Thread-Index: AcvcrKnj6dQpB8sdTJmRxufP+QFKQA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E13C8C03049AFA4E9CEE5A21D3E7F85DB588762FGUREXMB02ASIANA_" MIME-Version: 1.0 Subject: Re: [mpls] [mpls-tp] MPLS WG last call on draft-ietf-mpls-loss-delay-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 09:46:25 -0000 --_000_E13C8C03049AFA4E9CEE5A21D3E7F85DB588762FGUREXMB02ASIANA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, Others have covered most of the major comments; I just have a couple of min= or ones to add - - In Section 3.3 for Combined Loss/Delay Measurement Message Forma= t, it states "The LM/DM message fields have the same meanings as the corres= ponding fields in the LM and DM message formats." [Suggested Text] "The LM/DM message fields have the same meanings as the co= rresponding fields in the LM and DM message formats with the following exce= ptions - (a) the OTF of the LM message is to be interpreted from the QTF of= the combined LM/DM message (b) the "Origin Timestamp" of the LM message is= to be interpreted from the "Timestamp 1" of the combined LM/DM message. - In Section 4.2.5, suggest adding following sentence at the end o= f the last paragraph - "If the responder is not capable of supporting the q= uerier's preferred timestamp format, the RTF will be equal to the RPTF. The= querier should change/set its current QTF as per the received RPTF (thus g= iving preference to the responder's timestamp format) if such a format is s= upported by the querier; else the querier should discard the DM response an= d raise an appropriate notification to the user." Apart from this, I have one query - Sections 3.1 and 3.2 state towards the = end, that ensuring that counters and timestamps (respectively) are always w= ritten in the same fixed offset in the packet is an important property for = hardware processing. Does the Combined LM/DM message format not take away t= his property if different formats (either combined or individual) can be us= ed at different points of time during loss and delay measurements, thus req= uiring hardware to support different offsets at different points of time? O= r would this be more of an implementation aspect? - Lavanya -----Original Message----- From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On Behalf Of Ross Callon Sent: Sunday, February 06, 2011 9:33 PM To: mpls-tp at ietf.org; mpls at ietf.org; ahmpls-tp at lists.itu.int Subject: [mpls] MPLS WG last call on draft-ietf-mpls-loss-delay-01 Working Group, This is to start a four week working group last call on " Packet Loss and Delay Measurement for MPLS Networks" (draft-ietf-mpls-loss-delay-01). Please send comments to the mpls at ietf.org mailing list. Also, please note that the related document " draft-ietf-mpls-tp-loss-delay-profile-02.txt" is being last called in parallel on the mpls-tp email list (mpls-tp at ietf.org). This working group last call ends on Monday March 7, 2011. Ross, Loa, and George MPLS WG co-chairs ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." --_000_E13C8C03049AFA4E9CEE5A21D3E7F85DB588762FGUREXMB02ASIANA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authors,

 

Others have covered most of t= he major comments; I just have a couple of minor ones to add –

 

-      &n= bsp;   In Section 3.3 for Combined Loss/Delay Measurement Message Format, it= states “The LM/DM message fields have the same meanings as the corresponding fields in the LM and DM message formats.R= 21;

[Suggested Text] “The LM/DM message fields have the same m= eanings as the corresponding fields in the LM and DM message formats with the following exceptions – (a) the OTF of the LM messag= e is to be interpreted from the QTF of the combined LM/DM message (b) the &= #8220;Origin Timestamp” of the LM message is to be interpreted from t= he “Timestamp 1” of the combined LM/DM message.

 

-      &n= bsp;   In Section 4.2.5, suggest adding following sentence at the end of the= last paragraph – “If the responder is not capable of supporting the querier’s preferred timestamp format, the RTF will= be equal to the RPTF. The querier should change/set its current QTF as per= the received RPTF (thus giving preference to the responder’s timesta= mp format) if such a format is supported by the querier; else the querier should discard the DM response and raise an = appropriate notification to the user.”

 

Apart from this, I have one q= uery – Sections 3.1 and 3.2 state towards the end, that ensuring that= counters and timestamps (respectively) are always written in the same fixed offset in the packet is an important prop= erty for hardware processing. Does the Combined LM/DM message format not ta= ke away this property if different formats (either combined or individual) = can be used at different points of time during loss and delay measurements, thus requiring hardware to sup= port different offsets at different points of time? Or would this be more o= f an implementation aspect?

 

- Lavanya

 

 

-----Original Message-----
From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On Behalf Of Ross Callon
Sent: Sunday, February 06, 2011 9:33 PM
To: mpls-tp at ietf.org; mpls at ietf.org; ahmpls-tp at lists.itu.int
Subject: [mpls] MPLS WG last call on draft-ietf-mpls-loss-delay-01

 

Working Group,

 

This is to start a four week working group last call o= n

" Packet Loss and Delay Measurement for MPLS Netw= orks"

(draft-ietf-mpls-loss-delay-01).

 

Please send comments to the mpls at ietf.org mailing l= ist.

 

Also, please note that the related document

" draft-ietf-mpls-tp-loss-delay-profile-02.txt&qu= ot; is being last called in

parallel on the mpls-tp email list (mpls-tp at ietf.or= g).

 

This working group last call ends on Monday March 7, 2= 011.

 

Ross, Loa, and George

 

MPLS WG co-chairs

 

 


"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error, please notify the originator immediately. If you= are not the intended recipient, you are notified that you are strictly pro= hibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
 --_000_E13C8C03049AFA4E9CEE5A21D3E7F85DB588762FGUREXMB02ASIANA_-- From danfrost@cisco.com Mon Mar 7 04:52:23 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3E4728C107; Mon, 7 Mar 2011 04:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 vKw+mMoySaFM; Mon, 7 Mar 2011 04:52:22 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7BD3A28C0FA; Mon, 7 Mar 2011 04:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=danfrost@cisco.com; l=746; q=dns/txt; s=iport; t=1299502416; x=1300712016; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=sL3kBFjHq1DTWY+JBXSDbxJFbc3gGwXop0lPsz2fjM4=; b=MKBseoO3XcbPeKF9Q/qwBl3cBmxahbwI+pfaBJZ6sAEYBea1PNUrTq1t QnlCbapDjJofkleapW7pQZOb5D0UMBRMC32zcdxEFL8vBLUSSPRvjqZ9h GbjTf5Dizl3t6S8e+bIDL8jJ1nPcN3kSEg8gEHixVU/FDpKwTHDOXsowx Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADdkdE1AZnwM/2dsb2JhbACmSXSiEZs+hWIEjDA X-IronPort-AV: E=Sophos;i="4.62,277,1297036800"; d="scan'208";a="222864895" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 07 Mar 2011 12:53:35 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [64.100.19.13]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p27CrZ66006757; Mon, 7 Mar 2011 12:53:35 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id p27CrYLT008205; Mon, 7 Mar 2011 07:53:34 -0500 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id p27CrX0K008204; Mon, 7 Mar 2011 12:53:33 GMT Date: Mon, 7 Mar 2011 12:53:32 +0000 From: Dan Frost To: Alexander Vainshtein Message-ID: <20110307125332.GA6134@cisco.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6956BE358E6@SJEXCHCCR02.corp.ad.broadcom.com> <4D701ACF.4020702@cisco.com> <20110304171630.GB24642@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 12:52:24 -0000 On Sat, Mar 05, 2011 at 10:40:15PM +0200, Alexander Vainshtein wrote: > Lots of thanks for a prompt response. I've looked up Section 2.7.2 as > you've suggested. > > I think that placing the text that deals with location of the loss and > delay measurement points in the section on QoS is misleading. Would > you consider splitting it into a dedicated section? Sure. > As for the position you've taking: I understand the intention to make > the draft generic enough and not to prescribe specific location of the > measurement points. However, leaving this point open carries with it > serious interoperability issues. As a minimum, I would suggest > replacing SHOULD in this text with MUST. Agreed. -d > My 2c, Sasha From danfrost@cisco.com Mon Mar 7 05:27:09 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1580A3A63CB for ; Mon, 7 Mar 2011 05:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Vz0V7O8SSpAF for ; Mon, 7 Mar 2011 05:27:07 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C487E3A67AA for ; Mon, 7 Mar 2011 05:27:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=danfrost@cisco.com; l=2418; q=dns/txt; s=iport; t=1299504501; x=1300714101; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ky6tXWClZUKq4FR4TYBlUFIl6qeZhIJcAbtV4A7f0DQ=; b=CSv6BNXivG+D5GQ2WpScE/B5WQTmTYCM4WLNoF0WFvUCl0vN04t1nmL4 VNPLkvvK9FiFa5VqwBTkAQ9KM0UBbv4dJLDqHnhYKXjkv4PLf90+fKRrT x137qDkVBiRcTPFqQx7fNwlOpIM5OKbP1LN909rU6UBmmlMQND0JGV6XE E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGpsdE1AZnwN/2dsb2JhbACmVHSiFZs+hWIEjDA X-IronPort-AV: E=Sophos;i="4.62,277,1297036800"; d="scan'208";a="223249461" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 07 Mar 2011 13:28:21 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [64.100.19.13]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p27DSLs8008969; Mon, 7 Mar 2011 13:28:21 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id p27DSKw2009044; Mon, 7 Mar 2011 08:28:20 -0500 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id p27DSK6k009043; Mon, 7 Mar 2011 13:28:20 GMT Date: Mon, 7 Mar 2011 13:28:20 +0000 From: Dan Frost To: Lavanya Srivatsa Message-ID: <20110307132820.GB6134@cisco.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: mpls@ietf.org Subject: Re: [mpls] [mpls-tp] MPLS WG last call on draft-ietf-mpls-loss-delay-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 13:27:09 -0000 Hi Lavanya, On Mon, Mar 07, 2011 at 03:17:25PM +0530, Lavanya Srivatsa wrote: > - In Section 3.3 for Combined Loss/Delay Measurement Message > Format, it states "The LM/DM message fields have the same meanings as > the corresponding fields in the LM and DM message formats." [Suggested > Text] "The LM/DM message fields have the same meanings as the > corresponding fields in the LM and DM message formats with the > following exceptions - (a) the OTF of the LM message is to be > interpreted from the QTF of the combined LM/DM message (b) the "Origin > Timestamp" of the LM message is to be interpreted from the "Timestamp > 1" of the combined LM/DM message. OK. > - In Section 4.2.5, suggest adding following sentence at the > end of the last paragraph - "If the responder is not capable of > supporting the querier's preferred timestamp format, the RTF will be > equal to the RPTF. The querier should change/set its current QTF as > per the received RPTF (thus giving preference to the responder's > timestamp format) if such a format is supported by the querier; else > the querier should discard the DM response and raise an appropriate > notification to the user." This doesn't add anything except to restrict how the querier proceeds after receiving a response, which is intentionally left open, but it's fair to add a note that the user should be alerted in case the querier determines that format support is irreconcilable. > Apart from this, I have one query - Sections 3.1 and 3.2 state towards > the end, that ensuring that counters and timestamps (respectively) are > always written in the same fixed offset in the packet is an important > property for hardware processing. Does the Combined LM/DM message > format not take away this property if different formats (either > combined or individual) can be used at different points of time during > loss and delay measurements, thus requiring hardware to support > different offsets at different points of time? Or would this be more > of an implementation aspect? This is all very implementation-specific, but the idea is to make the processing of any given message type (ACH type) as simple as possible. The offsets may of course differ across ACH types. Also one would not mix and match message types within a single measurement session. Thanks for your review! -d > - Lavanya From prvs=0047a0e5fa=edwin.mallette@bhnis.com Mon Mar 7 06:43:50 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 182423A67D3; Mon, 7 Mar 2011 06:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 yAFaVdP01Ern; Mon, 7 Mar 2011 06:43:48 -0800 (PST) Received: from mx2.mybrighthouse.com (MX2.mybrighthouse.com [209.16.122.104]) by core3.amsl.com (Postfix) with ESMTP id 76A7D3A67B4; Mon, 7 Mar 2011 06:43:48 -0800 (PST) Received: from pps.filterd (mx2 [127.0.0.1]) by mx2.mybrighthouse.com (8.14.3/8.14.3) with SMTP id p27EeHqS025971; Mon, 7 Mar 2011 09:44:59 -0500 Received: from cntpaowa2.corp.local ([10.225.4.6]) by mx2.mybrighthouse.com with ESMTP id uw08f0f87-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 07 Mar 2011 09:44:59 -0500 Received: from CNEMAIL.corp.local ([10.225.1.130]) by cntpaowa2.corp.local ([10.225.4.6]) with mapi; Mon, 7 Mar 2011 09:44:59 -0500 From: "Mallette, Edwin" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "stbryant@cisco.com" , "mpls@ietf.org" Date: Mon, 7 Mar 2011 09:44:57 -0500 Thread-Topic: [mpls] draft-ietf-mpls-loss-delay Timestamp Thread-Index: Acvc1juX4TEkWBHVSwWopZ4+2Sjnuw== Message-ID: In-Reply-To: <077E41CFFD002C4CAB7DFA4386A532640371EB75@DEMUEXC014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C99A56F57DD8edwinmallettebhniscom_" MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1103070062 Cc: "Zhao, Peng \(NSN - CN/Shanghai\)" , "Pietilainen, Antti \(NSN - FI/Espoo\)" , "tictoc@ietf.org" Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 14:43:50 -0000 --_000_C99A56F57DD8edwinmallettebhniscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I concur with the points made by Nurit and Ben. In addition there is the a= symmetric delay problems (for a given link) that lots of work has gone into= to solve with 1588 - 1588 Transparent Clock / 1588 residency time compensa= tion. To the best of my knowledge this is not being addressed for NTP. Thus +1 for the default of IEEE1588. Ed From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" > Date: Fri, 4 Mar 2011 05:32:07 -0500 To: "stbryant@cisco.com" >, "mpls@ietf.org" > Cc: "Zhao, Peng (NSN - CN/Shanghai)" >, "Pietilainen, Antti (NSN - FI/Espoo)" >, "tictoc@ietf.org= " > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp Stewart hi, The accuracy targets as described below are approaching a level where on-pa= th support is needed. In this case the clear choice is IEEE 1588 because it specifies on-path sup= port whereas NTP does not. Even without on-path support IEEE 1588 could be better if better accuracy i= s pursued by sending multiple timing packets per second per slave/client, b= ecause standard NTP clients send messages at a very low rate for saving ser= ver resources. I support the default of IEEE1588! Best regards, Nurit From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of ext Stewart Bryant Sent: Thursday, March 03, 2011 6:07 PM To: mpls@ietf.org Cc: tictoc@ietf.org Subject: [mpls] draft-ietf-mpls-loss-delay Timestamp We have received a LC comment on draft-ietf-mpls-loss-delay concerning the = default timestamp. In the first version of the draft we proposed NTP, but following initial co= mments from the MPLS-TP community we changed to IEEE1588. This requirement = for IEEE1588 can be traced back to the choice of using IEEE1588 in Y.1731. We have now received a LC request to change the default back to NTP. NTP is the "natural" choice for an IETF protocol. NTP is specified in IETF = and is used in other MPLS protocols such as LSP ping. It is implemented on = almost every host and every router. However in general the implementations = provides a relatively low precision timestamp, and the NTP time distributio= n infrastructure operates on a best effort basis. Thus even a good client i= mplementation would normally have a relatively low quality path to the serv= er, which would result in a low quality of timestamp. NTP could be made to = work to higher accuracy, but defacto upgrading NTP and providing high quali= ty NTP paths to the time servers is not getting much attention. Computing t= imestamp differences is easier with NTP. On the other hand IEEE1588 has defacto become the two way time tranfer prot= ocol for precision applications. IEEE1588 only provides high quality time i= n well engineered networks with some form of hop by hop assistance. It is n= ot widely implemented other than in equipment targeted to specific markets,= although one of those markets is in mobile backhaul applications where we= expect to see significant initial deployment of MPLS-TP. Computing timesta= mp differences is harder with IEEE1588 The loss-delay work is targeting to be able to do one way packet delay meas= urement, so it does need a higher quality of timestamp than is required in = general purpose network instrumentation. Converting from IEEE1588 to NTP is not trivial, since they use different ep= ochs, and different representations of sub-second time. In a "traditional" = NTP implementation the time error due to on the fly conversion is likely to= be small compared to the time error in the time synchronization system, bu= t an IEEE1588 system would need hardware conversion to maintain the accurac= y for an NTP timestamp. So the question arises, should we make IEEE1588 or NTP the default for draf= t-ietf-mpls-loss-delay. Much as I would like to suggest that we should go b= ack to NTP for consistency with other IETF protocols, I have difficulty rec= onciling this with the situation in network deployments and thus suggest th= at we continue to use IEEE1588. What is the opinion of the working group? Stewart (speaking as a draft editor) ________________________________ CONFIDENTIALITY NOTICE: This e-mail may contain information that is privile= ged, confidential or otherwise protected from disclosure. If you are not th= e intended recipient of this e-mail, please notify the sender immediately b= y return e-mail, purge it and do not disseminate or copy it. --_000_C99A56F57DD8edwinmallettebhniscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I concur with the points made by Nurit an= d Ben.  In addition there is the asymmetric delay problems (for a given link) that lo= ts of work has gone into to solve with 1588 - 1588 Transparent Clock /=  1588 residency time compensation.  To the best of my knowledge this is not= being addressed for NTP.

Thus +1 for the default of IEEE1588.

Ed

From: "Sprecher, Nurit (NSN - = IL/Hod HaSharon)" <nurit.= sprecher@nsn.com>
Date: Fri, 4 Mar 2011 05:32:07 -050= 0
To: "stbryant@cisco.com" <stbryant@cisco.com>, "mpls@ietf.org" <mpls@ietf.org= >
Cc: "Zhao, Peng (NSN - CN/Shan= ghai)" <peng.zhao@nsn.com&= gt;, "Pietilainen, Antti (NSN - FI/Espoo)" <antti.pietilainen@nsn.com>, "tictoc@ietf.org" <tictoc@ietf.org>
Subject: Re: [mpls] draft-ietf-mpls= -loss-delay Timestamp

Stewart hi,

The accuracy targets as described = below are approaching a level where on-path support is needed.

In this case the clear choice= is IEEE 1588 because it specifies on-path support wher= eas NTP does not. 

Even without on-path support IEEE = 1588 could be better if better accuracy is pursued by sending multiple= timing packets per second per slave/client, because standard NTP clients send messages at a very l= ow rate for saving server resources.

I support the default of IEEE1588!=

Best regards,

Nurit

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Stewart Bryant
Sent: Thursday, March 03, 2011 6:07 PM
To: mpls@ietf.org
Cc: tictoc@ietf.org
Subject: [mpls] draft-ietf-mpls-loss-delay Timestamp

 


We have received a LC comment on draft-ietf-mpls-loss-delay concerning the = default timestamp.

In the first version of the draft we proposed NTP, but following initial co= mments from the MPLS-TP community we changed to IEEE1588. This requirement = for IEEE1588 can be traced back to the choice of using IEEE1588 in Y.1731.<= br>
We have now received a LC request to change the default back to NTP.

NTP is the "natural" choice for an IETF protocol. NTP is specifie= d in IETF and is used in other MPLS protocols such as LSP ping. It is imple= mented on almost every host and every router. However in general the implem= entations provides a relatively low precision timestamp, and the NTP time distribution infrastructure operates on a best= effort basis. Thus even a good client implementation would normally have a= relatively low quality path to the server, which would result in a low qua= lity of timestamp. NTP could be made to work to higher accuracy, but defacto upgrading NTP and providing h= igh quality NTP paths to the time servers is not getting much attention. Co= mputing timestamp differences is easier with NTP.

On the other hand IEEE1588 has defacto become the two way time tranfer prot= ocol for precision applications. IEEE1588 only provides high quality time i= n well engineered networks with some form of hop by hop assistance. It is n= ot widely implemented other than in equipment targeted to specific markets, although one of those markets i= s in mobile backhaul applications  where we expect to see significant = initial deployment of MPLS-TP. Computing timestamp differences is harder wi= th IEEE1588

The loss-delay work is targeting to be able to do one way packet delay meas= urement, so it does need a higher quality of timestamp than is required in = general purpose network instrumentation.

Converting from IEEE1588 to NTP is not trivial, since they use different ep= ochs, and different representations of sub-second time. In a "traditio= nal" NTP implementation the time error due to on the fly conversion is= likely to be small compared to the time error in the time synchronization system, but an IEEE1588 system would need hard= ware conversion to maintain the accuracy for an NTP timestamp.

So the question arises, should we make IEEE1588 or NTP the default for draf= t-ietf-mpls-loss-delay. Much as I would like to suggest that we should go b= ack to NTP for consistency with other IETF protocols, I have difficulty rec= onciling this with the situation in network deployments and thus suggest that we continue to use IEEE1588.<= br>
What is the opinion of the working group?

Stewart (speaking as a draft editor)


CONFIDENTIALITY NOTICE: This= e-mail may contain information that is privileged, confidential or otherwi= se protected from disclosure. If you are not the intended recipient of this= e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.
 --_000_C99A56F57DD8edwinmallettebhniscom_-- From loa@pi.nu Mon Mar 7 11:36:23 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE83C3A680C; Mon, 7 Mar 2011 11:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 VhIl+SK1XJDn; Mon, 7 Mar 2011 11:36:23 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id CAA063A6809; Mon, 7 Mar 2011 11:36:22 -0800 (PST) Received: from pi.nu (localhost [127.0.0.1]) by mail.pi.nu (Postfix) with ESMTP id B1B872A8001; Mon, 7 Mar 2011 20:37:34 +0100 (CET) Received: from 129.192.170.250 (SquirrelMail authenticated user loa@pi.nu) by pi.nu with HTTP; Mon, 7 Mar 2011 20:37:34 +0100 Message-ID: <88c733fa5e0bbb559d42d43655c8996d.squirrel@pi.nu> Date: Mon, 7 Mar 2011 20:37:34 +0100 From: loa@pi.nu To: mpls@ietf.org, mpls-tp@ietf.org, ahmpls-tp@lists.itu.int User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: elisa.bellagamba@ericsson.com Subject: [mpls] closing the mpls-tp mailing list X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 19:36:23 -0000 All, when the work on MPLS based Transport Networks were started we anticipated that would be a lot of work and involve a number of people that were not used to the operations of IETF working groups. In order to focus and make it easier to follow the transport profile specific work the mpls-tp mailing list were started, while the mpls working group mailing should be used for other discussions. Evaluating the situation it turns out that instead of increased focus we have had an increased number of cross-posting and fragmented discussions as people sub-scribed to only on list has tried to respond to discussions going on on the other list. This means that the positive contribution of the mpls-tp mailing list is small, but the administrative effort to maintain a mailing list is not negligible. The mpls working group chairs has decided to close mpls-tp mailing list and re-direct all mpls work to the working group mailing list. Those subscribed to the mpls-tp list only will have to subscribe to the mpls working group mailing list. Please stat already now to direct all mpls-tp mails to mpls@ietf.org. Loa, Ross and George mpls wg co-chairs From wwwrun@core3.amsl.com Mon Mar 7 11:41:50 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id C5F3D3A680E; Mon, 7 Mar 2011 11:41:50 -0800 (PST) From: Loa Andersson(IETF MPLS WG) To: greg.jones@itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110307194150.C5F3D3A680E@core3.amsl.com> Date: Mon, 7 Mar 2011 11:41:50 -0800 (PST) Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, mpls-tp@ietf.org, malcolm.betts@zte.com.cn, loa.andersson@ericsson.com, yoichi.maeda@ttc.or.jp, kam.lam@alcatel-lucent.com, ahmpls-tp@lists.itu.int, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, hhelvoort@huawei.com, elisa.bellagamba@ericsson.com, ghani.abbas@ericsson.com Subject: [mpls] New Liaison Statement, "Closing the mpls-tp mailing-list" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: loa.andersson@ericsson.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 19:41:50 -0000 Title: Closing the mpls-tp mailing-list Submission Date: 2011-03-07 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1024 From: Loa Andersson(IETF MPLS WG) To: ITU-T SG15 Q9, Q10, Q12 and Q14(greg.jones@itu.int) Cc: yoichi.maeda@ttc.or.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int adrian.farrel@huawei.com rcallon@juniper.net paf@cisco.com stbryant@cisco.com mpls@ietf.org mpls-tp@ietf.org swallow@cisco.com elisa.bellagamba@ericsson.com Reponse Contact: loa.andersson@ericsson.com Technical Contact: loa.andersson@ericsson.com swallow@cisco.com rcallon@juniper.net Purpose: For information Body: When the work on MPLS based Transport Networks were started we anticipated that would be a lot of work and involve a number of people that were not used to the operations of IETF working groups. In order to focus and make it easier to follow the transport profile specific work the mpls-tp mailing list were started, while the mpls working group mailing should be used for other discussions. Evaluating the situation it turns out that instead of increased focus we have had an increased number of cross-posting and fragmented discussions as people sub-scribed to only on list has tried to respond to discussions going on on the other list. This means that the positive contribution of the mpls-tp mailing list is small, but the administrative effort to maintain a mailing list is not negligible. The mpls working group chairs has decided to close mpls-tp mailing list and re-direct all mpls work to the working group mailing list. Those subscribed to the mpls-tp list only will have to subscribe to the mpls working group mailing list. Please stat already now to direct all mpls-tp mails to mpls@ietf.org. Loa, Ross and George mpls wg co-chairs Attachment(s): No document has been attached From curtis@occnc.com Mon Mar 7 15:18:25 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F663A6955 for ; Mon, 7 Mar 2011 15:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 5NsEzNXkAuhI for ; Mon, 7 Mar 2011 15:18:25 -0800 (PST) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 3EFAF3A687F for ; Mon, 7 Mar 2011 15:18:25 -0800 (PST) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p27NJX0W019101; Mon, 7 Mar 2011 18:19:33 -0500 (EST) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201103072319.p27NJX0W019101@harbor.orleans.occnc.com> To: "Mallette, Edwin" From: Curtis Villamizar In-reply-to: Your message of "Mon, 07 Mar 2011 09:44:57 EST." Date: Mon, 07 Mar 2011 18:19:33 -0500 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , "Zhao, Peng \(NSN - CN/Shanghai\)" , "Pietilainen, Antti \(NSN - FI/Espoo\)" , "tictoc@ietf.org" , "stbryant@cisco.com" Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 23:18:25 -0000 In message "Mallette, Edwin" writes: > > I concur with the points made by Nurit and Ben. In addition there is > the asymmetric delay problems (for a given link) that lots of work has > gone into to solve with 1588 - 1588 Transparent Clock / 1588 residency > time compensation. To the best of my knowledge this is not being > addressed for NTP. > > Thus +1 for the default of IEEE1588. > > Ed NTP has always, probably from day one but at least going back to the early 1990s (AFAIK), compensated for asymetric delay. With hardware assist, NTP deployed over a link is every bit as accurate as PTP deployed over a link with hardware assist. It is probably more accurate due to the jitter compensation used by NTP and omited by PTP. Some hardware doesn't quite get all the jitter out. Admitedly, NTP is more complex due to the compensation that is included in NTP and not in PTP. OTOH if there is something that favors PTP, then we should approach the TICTOC WG and pass along that requirements. For example, a two step transmit, allowing the transmit timestamp on a given packet to be sent with the next packet, may simplify hardware. If so, we ask TICTOC to support that in NTP. I support making the default NTP. This is the IETF and given a very nearly equivalent IETF solution and an IEEE solution we should require the IETF solution, make the IEEE solution optional, and if there are any shortcomings to the IETF solution, address that in the appropriate IETF WG. Curtis > From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" > > > Date: Fri, 4 Mar 2011 05:32:07 -0500 > To: "stbryant@cisco.com" > >, > "mpls@ietf.org" > > > Cc: "Zhao, Peng (NSN - CN/Shanghai)" > >, "Pietilainen, > Antti (NSN - FI/Espoo)" > >, > "tictoc@ietf.org" > > > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp > > Stewart hi, > The accuracy targets as described below are approaching a level where > on-path support is needed. > In this case the clear choice is IEEE 1588 because it specifies > on-path support whereas NTP does not. > Even without on-path support IEEE 1588 could be better if better > accuracy is pursued by sending multiple timing packets per second per > slave/client, because standard NTP clients send messages at a very low > rate for saving server resources. > I support the default of IEEE1588! > Best regards, > Nurit > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Stewart Bryant > Sent: Thursday, March 03, 2011 6:07 PM > To: mpls@ietf.org > Cc: tictoc@ietf.org > Subject: [mpls] draft-ietf-mpls-loss-delay Timestamp > > > We have received a LC comment on draft-ietf-mpls-loss-delay concerning > the default timestamp. > > In the first version of the draft we proposed NTP, but following > initial comments from the MPLS-TP community we changed to > IEEE1588. This requirement for IEEE1588 can be traced back to the > choice of using IEEE1588 in Y.1731. > > We have now received a LC request to change the default back to NTP. > > NTP is the "natural" choice for an IETF protocol. NTP is specified in > IETF and is used in other MPLS protocols such as LSP ping. It is > implemented on almost every host and every router. However in general > the implementations provides a relatively low precision timestamp, and > the NTP time distribution infrastructure operates on a best effort > basis. Thus even a good client implementation would normally have a > relatively low quality path to the server, which would result in a low > quality of timestamp. NTP could be made to work to higher accuracy, > but defacto upgrading NTP and providing high quality NTP paths to the > time servers is not getting much attention. Computing timestamp > differences is easier with NTP. > > On the other hand IEEE1588 has defacto become the two way time tranfer > protocol for precision applications. IEEE1588 only provides high > quality time in well engineered networks with some form of hop by hop > assistance. It is not widely implemented other than in equipment > targeted to specific markets, although one of those markets is in > mobile backhaul applications where we expect to see significant > initial deployment of MPLS-TP. Computing timestamp differences is > harder with IEEE1588 > > The loss-delay work is targeting to be able to do one way packet delay > measurement, so it does need a higher quality of timestamp than is > required in general purpose network instrumentation. > > Converting from IEEE1588 to NTP is not trivial, since they use > different epochs, and different representations of sub-second time. In > a "traditional" NTP implementation the time error due to on the fly > conversion is likely to be small compared to the time error in the > time synchronization system, but an IEEE1588 system would need > hardware conversion to maintain the accuracy for an NTP timestamp. > > So the question arises, should we make IEEE1588 or NTP the default for > draft-ietf-mpls-loss-delay. Much as I would like to suggest that we > should go back to NTP for consistency with other IETF protocols, I > have difficulty reconciling this with the situation in network > deployments and thus suggest that we continue to use IEEE1588. > > What is the opinion of the working group? > > Stewart (speaking as a draft editor) From saalvare@cisco.com Mon Mar 7 15:32:28 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DD8F28C140 for ; Mon, 7 Mar 2011 15:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.374 X-Spam-Level: X-Spam-Status: No, score=-9.374 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] 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 iyZukw8JPpd7 for ; Mon, 7 Mar 2011 15:32:27 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3273028C139 for ; Mon, 7 Mar 2011 15:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=saalvare@cisco.com; l=1192; q=dns/txt; s=iport; t=1299540821; x=1300750421; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ynaaFNwJj4nWOjKt8bf9LoEE/o0Xv456Ep7CNG3c7rg=; b=WB2OF4yD3EHUiuQm/P0YjTZ9riipKkv8juvJv8ZOMy6FvGjD2KPSQyln sUNiu3hK0Jqg/b3I0uODcIZgFgTmcNHlD7DRzzzD9HznmpqRoSpbASZME NvVsUg8gDTRQKV6BeJ3+AQL+LzywEDwlogRGrmT07X/JSuGbk02qKmgZ0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAIP5dE2rRN+J/2dsb2JhbACEK5Nljkd0oieLAwaRGYElg0V4BIUcil0 X-IronPort-AV: E=Sophos;i="4.62,280,1297036800"; d="scan'208";a="341953213" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 07 Mar 2011 23:33:41 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p27NXf8m013487; Mon, 7 Mar 2011 23:33:41 GMT Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Mar 2011 15:33:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Mar 2011 15:33:40 -0800 Message-ID: <96327EF53EF71A48806DE2DFC034D57F0E0853E1@xmb-sjc-22b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Question about RFC 4875 (bud node behavior) Thread-Index: AcvbRixCt1F0NEKITNasCDH+Xjn1AgB2PZOg References: From: "Santiago Alvarez (saalvare)" To: "Egor Zimin" , X-OriginalArrivalTime: 07 Mar 2011 23:33:41.0335 (UTC) FILETIME=[17831670:01CBDD20] Cc: "Santiago Alvarez \(saalvare\)" , =?koi8-r?B?98HMxdLJyiDx09TSxcLP1w==?= Subject: Re: [mpls] Question about RFC 4875 (bud node behavior) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 23:32:28 -0000 It has been discussed before. Some implementations are known to behave = as in 1 at least in some situations. RFC 4875 doesn't preclude 1 from = what I recall. =20 Cheers. SA -- > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of Egor > Zimin > Sent: Saturday, March 05, 2011 7:01 AM > To: mpls@ietf.org > Cc: =F7=C1=CC=C5=D2=C9=CA =F1=D3=D4=D2=C5=C2=CF=D7 > Subject: [mpls] Question about RFC 4875 (bud node behavior) >=20 > Hi all, >=20 > Are there any document, which specify label allocation behavior for = bud > nodes in P2MP LSPs (described in 4875) ? > Are there any statements about PHP on such nodes ? > If no, may be, it has a sense to describe label allocation process on = bud > nodes in more details ? >=20 > At the moment there are at least two different implementations exist: > 1) Using Implicit/Explicit-null labels, which cause unnecessary = replication > before bud nodes > 2) Using unreserved labels value >=20 > -- > Best regards, > Egor Zimin > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From soramakr@cisco.com Mon Mar 7 16:14:49 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1008C3A67EE for ; Mon, 7 Mar 2011 16:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.178 X-Spam-Level: X-Spam-Status: No, score=-8.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] 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 MwLN9kfjAG81 for ; Mon, 7 Mar 2011 16:14:47 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A2BCC3A67A5 for ; Mon, 7 Mar 2011 16:14:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=soramakr@cisco.com; l=13980; q=dns/txt; s=iport; t=1299543362; x=1300752962; h=mime-version:subject:date:message-id:from:to; bh=rXm87Ty+s2iHgq0phNjVGGUpR6OvgSGL7bmdYKw3XfU=; b=Im5nam24Ozsf+WrpTVNKLWYDIz4s5M9+nGbkpHq2FM8yT+jRzK1rS6tE 2YRATAN7XyIDArMUhDNoAF2agQLZr5tdyg9X3O9GEmiV1wJOSnUBb+eXU x7EHy5y1dQBzi55B6FTv7zZ6orR8R+1jdQhtc5xKi/MRAhYMSXDJoF7+r c=; X-Files: image001.jpg, image002.gif, image003.gif : 2651, 68, 347 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwRAIcEdU2rR7Ht/2dsb2JhbACBf1CWAI4IdKI1nCECgxaCSgSFHIIxghuGEQ X-IronPort-AV: E=Sophos;i="4.62,280,1297036800"; d="gif'147?jpg'147,145?scan'147,145,208,217,147,145";a="412453835" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 08 Mar 2011 00:16:01 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p280G1Iq009890 for ; Tue, 8 Mar 2011 00:16:01 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Mar 2011 16:16:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-CR-Hashedpuzzle: AATr Bw4q B1TH D7wV EeOH EzVb FJFX FgWj Fq4u GK0p Hl/s IPje IovM I9iJ KHVx KLgJ; 1; bQBwAGwAcwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {9CB11F79-559A-44E0-8ECA-9236A9C0421F}; cwBvAHIAYQBtAGEAawByAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 07 Mar 2011 21:17:09 GMT; cwB1AGIAYwByAGkAYgBlAA== MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CBDD26.01832B19"; type="multipart/alternative" X-CR-Puzzleid: {9CB11F79-559A-44E0-8ECA-9236A9C0421F} Content-class: urn:content-classes:message Date: Mon, 7 Mar 2011 16:16:01 -0800 Message-ID: <13D1EAB852BE194C94773A947138483D0C6A7C8D@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: subcribe Thread-Index: AcvdDQTpM+7MDD+1Qom6ygIqRQnByg== From: "Som Ramakrishnan (soramakr)" To: X-OriginalArrivalTime: 08 Mar 2011 00:16:01.0616 (UTC) FILETIME=[01A33500:01CBDD26] Subject: [mpls] subcribe X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 00:14:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBDD26.01832B19 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBDD26.01832B19" ------_=_NextPart_002_01CBDD26.01832B19 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 =09 Som Ramakrishnan Technical Leader =20 CCIE #4257 soramakr@cisco.com =20 Phone :408 525 1066 Mobile :408 858 6929 10, West Tasman Drive San Jose, CA 95134 United States =20 =20 =20 =20 If this e-mail is sent you by mistake or you for some reason do not want to receive mail from Cisco Systems please notify sender. All statements, information, and recommendations in this email and attached documents are believed to be accurate but are presented without warranty of any kind, express or implied. Users must take full responsibility for their application of any products. The software license and limited warranty terms are set forth in the information pack shipped with the products. =20 =20 =20 ------_=_NextPart_002_01CBDD26.01832B19 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

Som Ramakrishnan
Technical  Leader
3D"CCIE_10_BW"

CCIE #4257
soramakr@cisco.com
Phone :408 525 1066
Mobile :408 858 6929

10, West Tasman Drive
San Jose, CA
95134
United States

 

 

3D"http://www.cisco.com/global/EMEA/brand/signature/default/footerHea=

 

If this e-mail is sent you by mistake or you for some = reason do not want to receive mail from Cisco Systems please notify sender. = All statements, information, and recommendations in this email and = attached documents are believed to be accurate but are presented without = warranty of any kind, express or implied. Users must take full responsibility = for their application of any products. The software license and limited = warranty terms are set forth in the information pack shipped with the = products.

 

3D"http://www.cisco.com/global/EMEA/brand/signature/default/footer.gi=


 

------_=_NextPart_002_01CBDD26.01832B19-- ------_=_NextPart_001_01CBDD26.01832B19 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABUAFQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiik oAWoLu8trGDzrqZIY8gbmOMk9B7mm31/Dp8KyTb23uI0SNdzOx6AD8/yrGv7+DUbvTltGlivY3M8 ay25Kj70bBxkEdTyOmPSgDVbWNNS3+0G+g8rarBg4IIbO3H1wfyNI2s6YrQKb+DNyA0Xzj5weAR9 TwK5KWWyuNPmuDcySsscEj5sioKhpCHAUgqCWOCDkY75qaNV03ZF9vd3lWCG4SSz3SErudduTgfL kc5xjPWgDqodUsLm7ktIbuKSePO6NWyRjg/l39Kt1yVp9nstUs4GuWmS1mnW3ijtyHDNjdvYnBA8 wdOuc9q3LPXLO+ujbRearnfsMkZVZArbW2nocGgDRoopKAFooooAga5QTPGOdke8kHpz0rn/AALP Pf6XdardSF5by5Zsk8Ko4UD0A5q5Ej/2xqCNbeSZYMhg2RJyRu9jjGar+AQB4NsgOvz5+u85q18L M38aNLU47S8ijWS7MDwyCWKSNhuRhnnnIPBIwR3rL+y6RDfW16+pTSz26ld8iCQvlix5Kkjkn7uO OKz0vtZ8X61fW+mai2l6Vp8vkPNEgaWeQdQCegH+HrxNb/8ACReHvENnZ3F3PrOl3pKGZ4h5ls/b cV7H3/pzjz+R2vDtaOSva9v60uEVv4csrS4tbc3Kx3MKRSiOEjcVzhvu/eOeT3qWa40G8vzdXMNz ITIshSW3LISEKDjB7MfxqC41HWPEviS80jSL3+zrDTsLdXSIGkkkP8K54GOefakZfEfhjWLHN9c6 3pl3KIZhJEDLbk9Hyo+765o5/IPq72clfe39aFqSDQri9ju/tcqSJM8oDwbhltueGQ4+4ORz1q1p 1npdtdrcJfyTGPzPJSVhti3tubHAzk9znioLLU72X4ialprzlrSGzjkjiwMKxIyc9awPDcXifxLa XV4PFc9osd3JCsYtY34XGOePWjn7IFh3a8pJLTv1+R6EkiSDKMG+hrl/C93Pb6lrulys0kVlP5kA Y8qjZO36VuaRZ3ljYLBfag2oThiTO0YQkdhgelYOngJ4v8TSjgLDDk++wmtY6xZyVFaaszqYZVmi WRSMMAevSis/QUkj0mJTbC3GMhS2S3+0fcnNFSUU/OtbXxSqLPN5kwZHjkztGeQVz6kUzwgv2SHU dLb71neyAD/Yb5lP5GrWvxX8sSiztY5sYIfdh42ByCPaqcNwserW+sINsN8gtbtT/wAs5VPyE/jl fxWqWzREt0zJ8E3kOiaprPh3UJFguhevcQ+YdvnRvjBXPXp+vtWxf+KNvifTtD0xYruWYl7shs+R GO/Hc+/t61c1jQbPW1Vb+wtLrZ90yqdy/QjkVBpuiDQ0ZdK0vTrcP94qzBm+pwSaxUZLQ7p1aU25 tO/bpfv/AMAw/Dd3DoPjPXtJ1F1t3vrn7XavIcLKrZyAfUen1rW1vxT9j1jTdI0xYby8vJgJU3Z8 qLu5x0/+saXVtOudYhEWo6FYXiKcrvmOV+hxkVBpGkzaKXOm+GrK0Z+GcT5Yj64JxQoyWiCVWlJ8 8k7226bWv/wCDTv+Sr6x/wBg+L+YrmfCOieHNRsb2bVr3ybgX8qhftpi+XIwduR7813sNrerfyX4 02wjupUCPL5rFmUdATtqp/whukyuXm0LStzHLEITk/lScGaQxMUmtVolp5Gto0Fja6XFb6bMJraL Kqwl8zvk/Nk561zdjMq6br2rO+1b+8aONvVF+QEf+PVrXUEWhaI1lpVtDBLcN5dvFEuB5jfxfgMk +wql5E0Elppml2q3UGmqFcyNhTIR1PqRkn6mtlpE8+b5ql0bWjLANOQ28k8sbZIebO5vz7UVdj3C NQ4UNgZ29M+1FIZBf20N3aNFPI8adSyPsI/GuTjnt7C4mhWC7n0+Ubbrzlzg/wB8EV1OqwRXGnuk yb4wVZl9QCM1RPhXTsFY2uIlbqqTHBoA0rFi1oh84Trj5ZQfvjsT71YrAuI7PwvYGQT33lO4UImH 5JxnphfrxRbatBdar9iJvQjySRxTGQBZHT74GOR+PXBp2b1J5ktDfqN54o/vyov1YCucOovJrY0n +zGFwpd3aWRnQwgfK4PfJwMduapWWvXJ8NXmqTW8UUoiXyAlrtUOTtGCSS/OOwquRi9ojrDfWucC ZW/3ef5UovIT08w/SJv8K4yTXdTv7PTokkuBdLPJb3UduVheRghZSN4+UEDPT2qvd6nqTadpt1Jf 3EkhtNxji3xF5A/YhSC+OCrDFP2bI9qjotXvmty13DFJNc7THBiJtsIPVjkdT/T61F4d0+zmxeRS Xu9G+YSNtVm7nA6/jXRxsXiVipUkAkHqKgKqmoqwABkiOSO+CP8AGszVFmiiigZHPH51vJEDgupA PpUQnuFGJbRiR3jYEH88GrNFAGZqcSapp01lLDcosgAJVBkYIPH5VUt9Hhg1X7ckd4wWR5Y4G2BE dxhmHfn69zW9RTTaE4pu5ntbs+oJfCyxOkZiDtNj5SQSMDPcCq9roNtaMzW9hYwFiCSIy5znI647 81dvbE3S5iuZbaXHEkbfzHQ1n2Wk6n5hbUdUkkRT8qRHbuHuev4UXYWRofZZi5c3IDHqUiUE/nmn G1kIObufP/AR/SrCqEUKowB0paQzDTTNe25bWlDeghBFS2drrQvo2vri3lhjydyLhjkYxWvRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/9k= ------_=_NextPart_001_01CBDD26.01832B19 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhHwIBAJEAAAAAAP///9bY2v///yH5BAEAAAMALAAAAAAfAgEAAAIVlI+py+0Po5y02ouz 3rz7D4biSE4FADs= ------_=_NextPart_001_01CBDD26.01832B19 Content-Type: image/gif; name="image003.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.gif Content-Location: image003.gif R0lGODlhHwIRAMQAAAAAAP////f3+PX19vHx8u7u7+jp6+Tl59/g4tze4Nvd39ja3NfZ29bY2vHy 8+3u7+vs7eTl5ufp6uTm597g4dze3/j5+fHy8v7+/v39/fv7+/n5+f///wAAAAAAAAAAACH5BAEA ABwALAAAAAAfAhEAAAXY4JIFZGmeaKqubOu+cCzPdG3feK7vfO//wKCwlVkkNsOkcslsOp/QqHRK FW4SE0J1y+16v+CweJwkZCfktHrNbrvf7yymMoDb7/i8fp8fKDABFweAfIWGh4iJijIYBxclBhIa i5SVlpeYXhoSBicQDA+ZoqOkpaYuBQwQKRsIERcCp7KztLV2Ag4RCBYsDgcUDcHCw8TFxsfIycrL zM3Oz9DR0tPU1dbX2Nna29zd3twUEQ625OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wADChxI UEYIADs= ------_=_NextPart_001_01CBDD26.01832B19-- From loa@pi.nu Mon Mar 7 16:51:41 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98F153A69C2; Mon, 7 Mar 2011 16:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 dJcRdAYEYbZF; Mon, 7 Mar 2011 16:51:40 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 232433A6765; Mon, 7 Mar 2011 16:51:39 -0800 (PST) Received: from pi.nu (localhost [127.0.0.1]) by mail.pi.nu (Postfix) with ESMTP id 60DBB2A8001; Tue, 8 Mar 2011 01:52:53 +0100 (CET) Received: from 129.192.170.250 (SquirrelMail authenticated user loa@pi.nu) by pi.nu with HTTP; Tue, 8 Mar 2011 01:52:53 +0100 Message-ID: Date: Tue, 8 Mar 2011 01:52:53 +0100 From: loa@pi.nu To: mpls@ietf.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ahmpls-tp@lists.itu.int, mpls-tp@ietf.org Subject: [mpls] wg last call on draft-ietf-mpls-tp-identifiers-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 00:51:41 -0000 Working Group, this is to start a two week working group last call on: draft-ietf-mpls-tp-identifiers-04 The draft has been updated after the earlier working group last call. A mail describing how the comments has been resolved will be found at: http://www.ietf.org/mail-archive/web/mpls/current/msg05832.html A diff from the previous version will be found at: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-identifiers/history/ click on "diff from -03". Please send comments to mpls@ietf.org. This working group last call ends on March 18, 2011. /Loa From zali@cisco.com Mon Mar 7 18:53:08 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE2943A68B1 for ; Mon, 7 Mar 2011 18:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.149 X-Spam-Level: X-Spam-Status: No, score=-8.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] 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 8zXkW40Z1kHW for ; Mon, 7 Mar 2011 18:53:07 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 081A33A68B0 for ; Mon, 7 Mar 2011 18:53:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zali@cisco.com; l=1464; q=dns/txt; s=iport; t=1299552861; x=1300762461; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=qPkiCwHbSrRfn0y2NLopT1K0IvAB1deB/1zt6o4VMSU=; b=XFgr2CvBse3mgEAXwTHVBDndDVbtm6Vuym6EJ4cnEE37vHHUij3tZErA aRPJ1UoODfVCnvIEexAMyQXQDO4olHmAuoVfVuKYSyBzHRTSJ4/SQNSMu Hyu6YYKfxfBX8dFINFP5U0kTqhBJlVShjgjsMkSUkKs9ioGsv6OnFZw3e w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAABcpdU2tJXG//2dsb2JhbACEK5Nljkd0oimLAwaRKYElg0V4BIUdimE X-IronPort-AV: E=Sophos;i="4.62,281,1297036800"; d="scan'208";a="272217103" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2011 02:54:21 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p282sKoP003125; Tue, 8 Mar 2011 02:54:20 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Mar 2011 20:54:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Mar 2011 20:54:19 -0600 Message-ID: <7CC717E2F49DAA4A827DA3FEA237111B04294865@XMB-RCD-103.cisco.com> In-Reply-To: <96327EF53EF71A48806DE2DFC034D57F0E0853E1@xmb-sjc-22b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Question about RFC 4875 (bud node behavior) Thread-Index: AcvbRixCt1F0NEKITNasCDH+Xjn1AgB2PZOgAAcY0UA= References: <96327EF53EF71A48806DE2DFC034D57F0E0853E1@xmb-sjc-22b.amer.cisco.com> From: "Zafar Ali (zali)" To: "Santiago Alvarez (saalvare)" , "Egor Zimin" , X-OriginalArrivalTime: 08 Mar 2011 02:54:20.0901 (UTC) FILETIME=[1FA71150:01CBDD3C] Cc: =?koi8-r?B?98HMxdLJyiDx09TSxcLP1w==?= Subject: Re: [mpls] Question about RFC 4875 (bud node behavior) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 02:53:08 -0000 Hi-=20 Please see in-line. =20 Thanks Regards ... Zafar=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Egor > > Zimin > > Sent: Saturday, March 05, 2011 7:01 AM > > To: mpls@ietf.org > > Cc: =F7=C1=CC=C5=D2=C9=CA =F1=D3=D4=D2=C5=C2=CF=D7 > > Subject: [mpls] Question about RFC 4875 (bud node behavior) > > > > Hi all, > > > > Are there any document, which specify label allocation behavior for > bud > > nodes in P2MP LSPs (described in 4875) ? > > Are there any statements about PHP on such nodes ? > > If no, may be, it has a sense to describe label allocation process = on > bud > > nodes in more details ? Please have a look at the following draft for signaling non-php = behavior.=20 http://trac.tools.ietf.org/rfcmarkup/draft-ietf-mpls-rsvp-te-no-php-oob-m= apping Thanks Regards.. Zafar=20 > > > > At the moment there are at least two different implementations = exist: > > 1) Using Implicit/Explicit-null labels, which cause unnecessary > replication > > before bud nodes > > 2) Using unreserved labels value > > > > -- > > Best regards, > > Egor Zimin > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From yaacov.weingarten@nsn.com Tue Mar 8 00:48:22 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3EC3A689E for ; Tue, 8 Mar 2011 00:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 6ubHbC1YLUjv for ; Tue, 8 Mar 2011 00:48:21 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 4AAF13A68CE for ; Tue, 8 Mar 2011 00:48:21 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p288nYnW011931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Mar 2011 09:49:34 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p288nXi7027246 for ; Tue, 8 Mar 2011 09:49:34 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Mar 2011 09:49:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Mar 2011 09:49:18 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] wg last call on draft-ietf-mpls-tp-identifiers-04 Thread-Index: AcvdKzrL4SofQDTQRbuuL9ImI0XqVgAMfmZg References: From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 08 Mar 2011 08:49:21.0042 (UTC) FILETIME=[B786A720:01CBDD6D] Subject: Re: [mpls] [mpls-tp] wg last call on draft-ietf-mpls-tp-identifiers-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 08:48:22 -0000 Hi Editorial comments: 1. Introduction: "identifiers to be used in within the" choose either "in" or "within" not both. 2. Section 2 (just before the bulleted list): s/follow/following/ 3. Section 3 s/and or/and/ 4. Section 3 s/An The/The/ 5. Section 3 - it would be nice if you could clarify that "Operator" here is a "Service Provider" rather than e.g. a mathematical operator = =3D) 6. Section 3.1 s/and finally and attachment circuit/and, finally, an attachment circuit/ 7. Just a suggestion - change "It has nothing to do with" to "It is not related to" 8. Section 4 & several other places in the document - s/(see section Section 5.1/(see Section 5.1)/ 9. Section 5.1 - s/the format of the format of a Tunnel_ID/the format of a Tunnel_ID/ 10. Section 5.2.1 - s/For a co-routed/A co-routed/ 11. Section 5.2.2 (second sentence) - s/The each/Each/ 12. Section 5.3 - s/Likewise, the East/Likewise, for the East/ Questions for clarification - 1. Section 4 - "Note that MPLS-TP supports hierarchical tunnels. The attachment point to a MPLS-TP Tunnel at any sub layer requires a unique IF_ID." - what level of uniqueness are you referring to - unique within the node? 2. Section 5 - "The corresponding ICC-based version of this identifier would be: =20 East-ICC::East-Node_ID::East-Tunnel_Num::West-ICC::West-Node_ID::West-Tu nnel_Num::LSP_Num" - Why is this pointed out for the LSP and not, for example, for the Tunnel_ID? Wouldn't it have been simpler to just define the Global Node_ID to have the two variants? >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On >> Behalf Of ext loa@pi.nu >> Sent: Tuesday, March 08, 2011 2:53 AM >> To: mpls@ietf.org >> Cc: ahmpls-tp@lists.itu.int; mpls-tp@ietf.org >> Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-identifiers-04 >>=20 >>=20 >> Working Group, >>=20 >> this is to start a two week working group last call on: >>=20 >> draft-ietf-mpls-tp-identifiers-04 >>=20 >> The draft has been updated after the earlier working group >> last call. A mail describing how the comments has been >> resolved will be found at: >>=20 >> http://www.ietf.org/mail-archive/web/mpls/current/msg05832.html >>=20 >> A diff from the previous version will be found at: >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp- >> identifiers/history/ >>=20 >> click on "diff from -03". >>=20 >> Please send comments to mpls@ietf.org. >>=20 >> This working group last call ends on March 18, 2011. >>=20 >> /Loa >>=20 >>=20 >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp From Alexander.Vainshtein@ecitele.com Tue Mar 8 03:15:54 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374013A6842; Tue, 8 Mar 2011 03:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] 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 cSVuU0kraLwv; Tue, 8 Mar 2011 03:15:52 -0800 (PST) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id E19CA3A6834; Tue, 8 Mar 2011 03:15:51 -0800 (PST) X-AuditID: 93eaf2e8-b7bcdae000001123-ad-4d760fd911f7 Received: from ilptexch01.ecitele.com (ilptexfe.ecitele.com [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 72.97.04387.9DF067D4; Tue, 8 Mar 2011 13:15:37 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 8 Mar 2011 13:17:05 +0200 From: Alexander Vainshtein To: "curtis@occnc.com" Date: Tue, 8 Mar 2011 13:17:03 +0200 Thread-Topic: [mpls] draft-ietf-mpls-loss-delay Timestamp Thread-Index: AcvdHmbwi1KfksPjQpug/QtFL54j0AAYaErQ Message-ID: References: Your message of "Mon, 07 Mar 2011 09:44:57 EST." <201103072319.p27NJX0W019101@harbor.orleans.occnc.com> In-Reply-To: <201103072319.p27NJX0W019101@harbor.orleans.occnc.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsWyRv6Lhu5N/jJfg7ffZS16zv1ktzh8YDq7 xd9X3xgtbi1dyWrx+tVNZotzT+cwWvxt7mF3YPe4svAbs8eU3xtZPZYs+cnk8XP9VXaPxV/8 AlijuGxSUnMyy1KL9O0SuDK2/93IVvDNoWLXvn2MDYxfjLsYOTkkBEwkLqyYyg5hi0lcuLee rYuRi0NI4CyjROv6AywQzmRGid7dX9hAqtgEbCU2rb4LZosIaEr8nbSZHaSIWWARk8ShiVeZ QBIsAioSJ16eYQWxhQUsJHZ1/GOGaLCUODl5EguEbSTx7FEP2CBeAX+J5qeboVYvZJTY3fUE rIhTwFliQc9/MJsR6L7vp9aALWAWEJe49WQ+E8TdAhJL9pxnhrBFJV4+/scKUS8qcad9PSNE vY7Egt2f2CBsbYllC18zQywWlDg58wnLBEaxWUjGzkLSMgtJyywkLQsYWVYximbmFJQk5aYb GOmlJmeWpOak6iXn525iBMbk5FefXuxgnLBZ5xAjEwenVAOj10rLf/8mGq1d/qAxTu+/1kWN 94K9W5ZsWXfRxlXv7P6T/N+TZvCVzp1WxmSzqfmBmlf2+ic7Eqq4/d7ZzlE8sKH04tPSwL4D Xw4vc5kWtb1qttzD3qUPyi7aq2wobb7ouIr77tcl30I+ckyVtYx5/zV2ZdJy+y3Okdfy7fbZ cq185JK+sEDfQImlOCPRUIu5qDgRAEwmG695AgAA Cc: "mpls@ietf.org" , "Zhao, Peng \(NSN - CN/Shanghai\)" , "Pietilainen, Antti \(NSN - FI/Espoo\)" , "tictoc@ietf.org" , "Mallette, Edwin" , "stbryant@cisco.com" Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 11:15:54 -0000 Curtis, and all, To the best of my understanding, this is not about accuracy of synchronizat= ion using NTP or PTP. It is about the default timestamp format in the Delay Measurement (DM) mess= ages for MPLS. Whatever accuracy can be achieved with one of these, the timestamp format = is probably the least significant factor affecting the result. I have already stated on this list that, IMHO, the question itself is moot,= because the DM can operate with disparate timestamp formats at two ends: a= ctual format is specified in the message, and there is no need to do conver= sion in HW or in hard real time. What's more, 2-way DM does not even requir= e conversion from one timestamp format to another, just ability to compute = differences between two timestamps in the same format both for NTP and PTP = formats. In addition, the points in the data path where the timestamps are captured = by a HW assist for the needs of a given protocol do not necessarily match t= he points where these timestamps should be taken for the purpose of DM. Whi= le it is probably possible to live with DM that ignores the time a packet i= s queued for transmission in the originating LSR, the results could look fi= shy, especially if the objective is to measure PDV and not delay per se. In= other words, a timestamping HW assist that is optimal from the point of vi= ew of PTP "as close to actual ingress/egress as possible"), may be not very= effective for DM (and, of course, vice versa).=20 My 2c, Sasha > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Curtis Villamizar > Sent: Tuesday, March 08, 2011 1:20 AM > To: Mallette, Edwin > Cc: mpls@ietf.org; Zhao, Peng (NSN - CN/Shanghai); Pietilainen, Antti > (NSN - FI/Espoo); tictoc@ietf.org; stbryant@cisco.com > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp >=20 >=20 > In message > "Mallette, Edwin" writes: > > > > I concur with the points made by Nurit and Ben. In addition there is > > the asymmetric delay problems (for a given link) that lots of work > has > > gone into to solve with 1588 - 1588 Transparent Clock / 1588 > residency > > time compensation. To the best of my knowledge this is not being > > addressed for NTP. > > > > Thus +1 for the default of IEEE1588. > > > > Ed >=20 >=20 > NTP has always, probably from day one but at least going back to the > early 1990s (AFAIK), compensated for asymetric delay. >=20 > With hardware assist, NTP deployed over a link is every bit as > accurate as PTP deployed over a link with hardware assist. It is > probably more accurate due to the jitter compensation used by NTP and > omited by PTP. Some hardware doesn't quite get all the jitter out. >=20 > Admitedly, NTP is more complex due to the compensation that is > included in NTP and not in PTP. >=20 > OTOH if there is something that favors PTP, then we should approach > the TICTOC WG and pass along that requirements. For example, a two > step transmit, allowing the transmit timestamp on a given packet to be > sent with the next packet, may simplify hardware. If so, we ask > TICTOC to support that in NTP. >=20 > I support making the default NTP. This is the IETF and given a very > nearly equivalent IETF solution and an IEEE solution we should require > the IETF solution, make the IEEE solution optional, and if there are > any shortcomings to the IETF solution, address that in the appropriate > IETF WG. >=20 > Curtis >=20 >=20 > > From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" > > > > > Date: Fri, 4 Mar 2011 05:32:07 -0500 > > To: "stbryant@cisco.com" > > >, > > "mpls@ietf.org" > > > > > Cc: "Zhao, Peng (NSN - CN/Shanghai)" > > >, "Pietilainen, > > Antti (NSN - FI/Espoo)" > > >, > > "tictoc@ietf.org" > > > > > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp > > > > Stewart hi, > > The accuracy targets as described below are approaching a level where > > on-path support is needed. > > In this case the clear choice is IEEE 1588 because it specifies > > on-path support whereas NTP does not. > > Even without on-path support IEEE 1588 could be better if better > > accuracy is pursued by sending multiple timing packets per second per > > slave/client, because standard NTP clients send messages at a very > low > > rate for saving server resources. > > I support the default of IEEE1588! > > Best regards, > > Nurit > > > > From: mpls-bounces@ietf.org > [mailto:mpls-bounces@ietf.org] On Behalf Of ext Stewart Bryant > > Sent: Thursday, March 03, 2011 6:07 PM > > To: mpls@ietf.org > > Cc: tictoc@ietf.org > > Subject: [mpls] draft-ietf-mpls-loss-delay Timestamp > > > > > > We have received a LC comment on draft-ietf-mpls-loss-delay > concerning > > the default timestamp. > > > > In the first version of the draft we proposed NTP, but following > > initial comments from the MPLS-TP community we changed to > > IEEE1588. This requirement for IEEE1588 can be traced back to the > > choice of using IEEE1588 in Y.1731. > > > > We have now received a LC request to change the default back to NTP. > > > > NTP is the "natural" choice for an IETF protocol. NTP is specified in > > IETF and is used in other MPLS protocols such as LSP ping. It is > > implemented on almost every host and every router. However in general > > the implementations provides a relatively low precision timestamp, > and > > the NTP time distribution infrastructure operates on a best effort > > basis. Thus even a good client implementation would normally have a > > relatively low quality path to the server, which would result in a > low > > quality of timestamp. NTP could be made to work to higher accuracy, > > but defacto upgrading NTP and providing high quality NTP paths to the > > time servers is not getting much attention. Computing timestamp > > differences is easier with NTP. > > > > On the other hand IEEE1588 has defacto become the two way time > tranfer > > protocol for precision applications. IEEE1588 only provides high > > quality time in well engineered networks with some form of hop by hop > > assistance. It is not widely implemented other than in equipment > > targeted to specific markets, although one of those markets is in > > mobile backhaul applications where we expect to see significant > > initial deployment of MPLS-TP. Computing timestamp differences is > > harder with IEEE1588 > > > > The loss-delay work is targeting to be able to do one way packet > delay > > measurement, so it does need a higher quality of timestamp than is > > required in general purpose network instrumentation. > > > > Converting from IEEE1588 to NTP is not trivial, since they use > > different epochs, and different representations of sub-second time. > In > > a "traditional" NTP implementation the time error due to on the fly > > conversion is likely to be small compared to the time error in the > > time synchronization system, but an IEEE1588 system would need > > hardware conversion to maintain the accuracy for an NTP timestamp. > > > > So the question arises, should we make IEEE1588 or NTP the default > for > > draft-ietf-mpls-loss-delay. Much as I would like to suggest that we > > should go back to NTP for consistency with other IETF protocols, I > > have difficulty reconciling this with the situation in network > > deployments and thus suggest that we continue to use IEEE1588. > > > > What is the opinion of the working group? > > > > Stewart (speaking as a draft editor) >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From stbryant@cisco.com Tue Mar 8 06:05:57 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F2D3A67BD for ; Tue, 8 Mar 2011 06:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.455 X-Spam-Level: X-Spam-Status: No, score=-110.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 027vd2ar2Q9t for ; Tue, 8 Mar 2011 06:05:56 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 39A013A63CB for ; Tue, 8 Mar 2011 06:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=363; q=dns/txt; s=iport; t=1299593231; x=1300802831; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=l7uQAmpT+Mgb/kpCQ+cyXwhaH7I/vBsyNNZ0f6dq6FA=; b=JGV6Nxn/Q5MdfrdrHW+XU6IDb6WZd6hd96f4JLZEIESy9JLgEAzd79Uq DcrpquhTqUKr481wXG7uWYHuIg6k0i5d0EnJP9FLPE458R2LnJRAlznkD ADs4LBLVom9VjvQ1xKVTRozkiW8GkorFv9SLLndYFMI9xFG9hnF91E54l 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8EAErHdU2Q/khLgWdsb2JhbACmQBUBARYiJaJXgmkOAZlKhWMEjDI X-IronPort-AV: E=Sophos;i="4.62,284,1297036800"; d="scan'208";a="78313922" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 08 Mar 2011 14:07:10 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p28E7A3O031640 for ; Tue, 8 Mar 2011 14:07:10 GMT Received: from dhcp-64-103-102-244.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p28E78s16794; Tue, 8 Mar 2011 14:07:09 GMT Message-ID: <4D76380C.6000007@cisco.com> Date: Tue, 08 Mar 2011 14:07:08 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] G.8110.1 is in AAP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 14:05:57 -0000 I see that G.8110.1 is in AAP. http://www.itu.int/ITU-T/aap/AAPRecDetails.aspx?AAPSeqNo=2281 I know that there are a number of IETF comments that have not been addressed, so we need to send them in. If anyone has any further comments that they wish to raise via IETF rather than via their own sector membership, please make these known. - Stewart From maarten.vissers@huawei.com Tue Mar 8 06:13:04 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B453A67BD for ; Tue, 8 Mar 2011 06:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 TkzP5oFma0GT for ; Tue, 8 Mar 2011 06:13:03 -0800 (PST) Received: from lhrga04-in.huawei.com (lhrga04-in.huawei.com [195.33.106.149]) by core3.amsl.com (Postfix) with ESMTP id 5AF7F3A63CB for ; Tue, 8 Mar 2011 06:13:03 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHQ00G3TSVSZH@lhrga04-in.huawei.com> for mpls@ietf.org; Tue, 08 Mar 2011 14:14:16 +0000 (GMT) Received: from LHREML201-EDG.china.huawei.com ([172.18.7.118]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LHQ00GWDSVSJC@lhrga04-in.huawei.com> for mpls@ietf.org; Tue, 08 Mar 2011 14:14:16 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.30) by LHREML201-EDG.china.huawei.com (172.18.7.188) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 08 Mar 2011 14:14:10 +0000 Received: from LHREML502-MBX.china.huawei.com ([fe80::31cd:8f92:ced2:dac5]) by LHREML401-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Tue, 08 Mar 2011 14:14:15 +0000 Date: Tue, 08 Mar 2011 14:14:14 +0000 From: Maarten vissers In-reply-to: <4D76380C.6000007@cisco.com> X-Originating-IP: [10.202.112.247] To: "stbryant@cisco.com" , "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, en-US Thread-topic: [mpls] G.8110.1 is in AAP Thread-index: AQHL3ZqGeGpblRR9ekmHN5LrqPFGrJQjerKg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4D76380C.6000007@cisco.com> Subject: Re: [mpls] G.8110.1 is in AAP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 14:13:04 -0000 Stewart, AAP for G.8110.1 has not yet started. AAP-54 (1 March) does not include it. Most likely it will be part of AAP-55 (16 March). Regards, Maarten > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Stewart Bryant > Sent: 8 March 2011 15:07 > To: mpls@ietf.org > Subject: [mpls] G.8110.1 is in AAP > > I see that G.8110.1 is in AAP. > > http://www.itu.int/ITU-T/aap/AAPRecDetails.aspx?AAPSeqNo=2281 > > I know that there are a number of IETF comments that have not been > addressed, so we need to send them in. If anyone has any further > comments that they wish to raise via IETF rather than via their own > sector membership, please make these known. > > - Stewart > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From curtis@occnc.com Tue Mar 8 11:37:30 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3E83A692C; Tue, 8 Mar 2011 11:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 V4AU-sC8zNpe; Tue, 8 Mar 2011 11:37:28 -0800 (PST) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 4A2FC3A6814; Tue, 8 Mar 2011 11:37:28 -0800 (PST) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p28JbHv2028102; Tue, 8 Mar 2011 14:37:17 -0500 (EST) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201103081937.p28JbHv2028102@harbor.orleans.occnc.com> To: Alexander Vainshtein From: Curtis Villamizar In-reply-to: Your message of "Tue, 08 Mar 2011 13:17:03 +0200." Date: Tue, 08 Mar 2011 14:37:17 -0500 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , "Zhao, Peng \(NSN - CN/Shanghai\)" , "Pietilainen, Antti \(NSN - FI/Espoo\)" , "tictoc@ietf.org" , "Mallette, Edwin" , "stbryant@cisco.com" Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 19:37:30 -0000 In message Alexander Vainshtein writes: > > Curtis, and all, > > To the best of my understanding, this is not about accuracy of > synchronization using NTP or PTP. It is about the default timestamp > format in the Delay Measurement (DM) messages for MPLS. > > Whatever accuracy can be achieved with one of these, the timestamp > format is probably the least significant factor affecting the result. For very high timestamp accuracy, the timestamp must be generated in hardware. Perhaps the answer is send either format (maximize the supported hardware) and accept both. On the receive side, the locally generated time stamp can be converted or the sent timestamp can be converted to achieve a common format. It is the transmit timestamp that is hard to get into a format that the hardware does not support. > I have already stated on this list that, IMHO, the question itself is > moot, because the DM can operate with disparate timestamp formats at > two ends: actual format is specified in the message, and there is no > need to do conversion in HW or in hard real time. What's more, 2-way > DM does not even require conversion from one timestamp format to > another, just ability to compute differences between two timestamps in > the same format both for NTP and PTP formats. It seems that the timestamp fields are nearly identical. IEEE-1588-2008 section 5,2,3 contains: struct Timestamp { UInteger48 secondsField; UInteger32 nanosecondsFeild; }; Hopefully IEEE will see this excerpt as an acceptable "fair use". This is very similar to the unix/bsd/linux timespec. struct timespec { time_t tv_sec; /* seconds */ long tv_nsec; /* and nanoseconds */ }; The NTP 64 bit timestamp is also quite similar (RFC5905). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NTP Timestamp Format Briefly (from RFC5905) "It includes a 32-bit unsigned seconds field spanning 136 years and a 32-bit fraction field resolving 232 picoseconds." The resolution of NTP 64 bit timestamp is slightly better by about a factor of four. The draft-ietf-mpls-loss-delay-01 draft chops off the top 16 bits and therefore is really using unix/bsd/linux timespec format. The conversion for PTP to timespec is tacking on or removing 16 bits of leading zeros. That conversion will work for the next 90+ years, which gives us a lot of time to decide how to extend time_t and timespec and all the things that go with it, however NTP has this covered in the 128 bit format when we go beyond era 0. Is there an endian-ness issue that I'm missing? In any case, this is acheivable as long as we specify "send either" and "accept both". Perhaps the expected lifetime of the solar system would be an adequate target, but 2106 may be OK for now so NTP 64 bit format is OK. :-) OTOH, NTP also supports a 32 bit stamp: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | Fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Again from RFC5905 "The 32-bit short format is used in delay and dispersion header fields where the full resolution and range of the other formats are not justified. It includes a 16-bit unsigned seconds field and a 16-bit fraction field." 1 second / 65536 is less than 20 usec. This should be fine in delay measurements. It is less than 4km worth of fiber if I've done the math right. Otherwise we stick with the 64 bit format only. I should also point out that 20 usec accuracy may be within the range acheivable in software, or at least packet processor microcode. As spcified in draft-ietf-mpls-loss-delay-01 the 32 bit timestamp would be padded out to 64 bits, so there is no motivation to use it. > In addition, the points in the data path where the timestamps are > captured by a HW assist for the needs of a given protocol do not > necessarily match the points where these timestamps should be taken > for the purpose of DM. While it is probably possible to live with DM > that ignores the time a packet is queued for transmission in the > originating LSR, the results could look fishy, especially if the > objective is to measure PDV and not delay per se. In other words, a > timestamping HW assist that is optimal from the point of view of PTP > "as close to actual ingress/egress as possible"), may be not very > effective for DM (and, of course, vice versa). We have been specifying hardware that allows the PTP and NTP 64 bit and 32 bit time stamp formats to be placed at an arbitrary byte location. Packets from CPU to hardware have an internal header that gets stripped before going out and one thing that can go in that header is an indication of time stamp format and where to put it (byte offset). Final modifications for NTP, PTP, LM, DM, happen there. I am aware that some "merchant silicon" has some built in assumptions about how these timestamps will be used and may only be able to support hardware asssisted time synchronization using PTP over Ethernet. That does not mean we should limit our specs in IETF to use PTP formats only. > My 2c, > Sasha Therefore I support "send any", and "accept all" as the MUST. This guarentees interoperability and removes any need to negociate formats. As long as hardware can record stamps, software can convert them and produce a delay value. Thanks, Curtis > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Curtis Villamizar > > Sent: Tuesday, March 08, 2011 1:20 AM > > To: Mallette, Edwin > > Cc: mpls@ietf.org; Zhao, Peng (NSN - CN/Shanghai); Pietilainen, Antti > > (NSN - FI/Espoo); tictoc@ietf.org; stbryant@cisco.com > > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp > > > > > > In message > > "Mallette, Edwin" writes: > > > > > > I concur with the points made by Nurit and Ben. In addition there is > > > the asymmetric delay problems (for a given link) that lots of work > > has > > > gone into to solve with 1588 - 1588 Transparent Clock / 1588 > > residency > > > time compensation. To the best of my knowledge this is not being > > > addressed for NTP. > > > > > > Thus +1 for the default of IEEE1588. > > > > > > Ed > > > > > > NTP has always, probably from day one but at least going back to the > > early 1990s (AFAIK), compensated for asymetric delay. > > > > With hardware assist, NTP deployed over a link is every bit as > > accurate as PTP deployed over a link with hardware assist. It is > > probably more accurate due to the jitter compensation used by NTP and > > omited by PTP. Some hardware doesn't quite get all the jitter out. > > > > Admitedly, NTP is more complex due to the compensation that is > > included in NTP and not in PTP. > > > > OTOH if there is something that favors PTP, then we should approach > > the TICTOC WG and pass along that requirements. For example, a two > > step transmit, allowing the transmit timestamp on a given packet to be > > sent with the next packet, may simplify hardware. If so, we ask > > TICTOC to support that in NTP. > > > > I support making the default NTP. This is the IETF and given a very > > nearly equivalent IETF solution and an IEEE solution we should require > > the IETF solution, make the IEEE solution optional, and if there are > > any shortcomings to the IETF solution, address that in the appropriate > > IETF WG. > > > > Curtis > > > > > > > From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" > > > > > > > Date: Fri, 4 Mar 2011 05:32:07 -0500 > > > To: "stbryant@cisco.com" > > > >, > > > "mpls@ietf.org" > > > > > > > Cc: "Zhao, Peng (NSN - CN/Shanghai)" > > > >, "Pietilainen, > > > Antti (NSN - FI/Espoo)" > > > >, > > > "tictoc@ietf.org" > > > > > > > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp > > > > > > Stewart hi, > > > The accuracy targets as described below are approaching a level where > > > on-path support is needed. > > > In this case the clear choice is IEEE 1588 because it specifies > > > on-path support whereas NTP does not. > > > Even without on-path support IEEE 1588 could be better if better > > > accuracy is pursued by sending multiple timing packets per second per > > > slave/client, because standard NTP clients send messages at a very > > low > > > rate for saving server resources. > > > I support the default of IEEE1588! > > > Best regards, > > > Nurit > > > > > > From: mpls-bounces@ietf.org > > [mailto:mpls-bounces@ietf.org] On Behalf Of ext Stewart Bryant > > > Sent: Thursday, March 03, 2011 6:07 PM > > > To: mpls@ietf.org > > > Cc: tictoc@ietf.org > > > Subject: [mpls] draft-ietf-mpls-loss-delay Timestamp > > > > > > > > > We have received a LC comment on draft-ietf-mpls-loss-delay > > concerning > > > the default timestamp. > > > > > > In the first version of the draft we proposed NTP, but following > > > initial comments from the MPLS-TP community we changed to > > > IEEE1588. This requirement for IEEE1588 can be traced back to the > > > choice of using IEEE1588 in Y.1731. > > > > > > We have now received a LC request to change the default back to NTP. > > > > > > NTP is the "natural" choice for an IETF protocol. NTP is specified in > > > IETF and is used in other MPLS protocols such as LSP ping. It is > > > implemented on almost every host and every router. However in general > > > the implementations provides a relatively low precision timestamp, > > and > > > the NTP time distribution infrastructure operates on a best effort > > > basis. Thus even a good client implementation would normally have a > > > relatively low quality path to the server, which would result in a > > low > > > quality of timestamp. NTP could be made to work to higher accuracy, > > > but defacto upgrading NTP and providing high quality NTP paths to the > > > time servers is not getting much attention. Computing timestamp > > > differences is easier with NTP. > > > > > > On the other hand IEEE1588 has defacto become the two way time > > tranfer > > > protocol for precision applications. IEEE1588 only provides high > > > quality time in well engineered networks with some form of hop by hop > > > assistance. It is not widely implemented other than in equipment > > > targeted to specific markets, although one of those markets is in > > > mobile backhaul applications where we expect to see significant > > > initial deployment of MPLS-TP. Computing timestamp differences is > > > harder with IEEE1588 > > > > > > The loss-delay work is targeting to be able to do one way packet > > delay > > > measurement, so it does need a higher quality of timestamp than is > > > required in general purpose network instrumentation. > > > > > > Converting from IEEE1588 to NTP is not trivial, since they use > > > different epochs, and different representations of sub-second time. > > In > > > a "traditional" NTP implementation the time error due to on the fly > > > conversion is likely to be small compared to the time error in the > > > time synchronization system, but an IEEE1588 system would need > > > hardware conversion to maintain the accuracy for an NTP timestamp. > > > > > > So the question arises, should we make IEEE1588 or NTP the default > > for > > > draft-ietf-mpls-loss-delay. Much as I would like to suggest that we > > > should go back to NTP for consistency with other IETF protocols, I > > > have difficulty reconciling this with the situation in network > > > deployments and thus suggest that we continue to use IEEE1588. > > > > > > What is the opinion of the working group? > > > > > > Stewart (speaking as a draft editor) > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Tue Mar 8 12:11:59 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABB133A67B3; Tue, 8 Mar 2011 12:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] 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 rxnpZ6q-hPL2; Tue, 8 Mar 2011 12:11:57 -0800 (PST) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id 871183A6781; Tue, 8 Mar 2011 12:11:56 -0800 (PST) X-AuditID: 93eaf2e8-b7bcdae000001123-b9-4d768d7dc9fe Received: from ilptexch01.ecitele.com (ilptexfe.ecitele.com [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id DB.32.04387.D7D867D4; Tue, 8 Mar 2011 22:11:41 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 8 Mar 2011 22:13:10 +0200 From: Alexander Vainshtein To: "curtis@occnc.com" Date: Tue, 8 Mar 2011 22:13:06 +0200 Thread-Topic: [mpls] draft-ietf-mpls-loss-delay Timestamp Thread-Index: AcvdyG612gxgvgi1QzmHv0nxpP31OwAAtXqw Message-ID: References: Your message of "Tue, 08 Mar 2011 13:17:03 +0200." <201103081937.p28JbHv2028102@harbor.orleans.occnc.com> In-Reply-To: <201103081937.p28JbHv2028102@harbor.orleans.occnc.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsWyRv6Lhm5tb5mvwdfl/BY9536yWxw+MJ3d 4u+rb4wWt5auZLV4/eoms8W5p3MYLf4297A7sHtcWfiN2WPK742sHkuW/GTy+Ln+KrvH4i9+ AaxRXDYpqTmZZalF+nYJXBkvbkxiLFhfWXF6VlID476YLkZODgkBE4lJ+z6zQthiEhfurWfr YuTiEBI4yygxacUTFghnMqPEtIZudpAqNgFbiU2r77KB2CICmhJ/J21mByliFljNJLFg/k0W kASLgIrEyb51TCC2sIClxI7+JewQDVYScy7+ZoSwjSSmXVwEVsMr4C/xe8oiVohtpxglLpw9 BNbAKeAs0di8HKyBEei+76fWgDUwC4hL3HoynwnibgGJJXvOM0PYohIvH/9jhagXlbjTvp4R ol5HYsHuT2wQtrbEsoWvmSEWC0qcnPmEZQKj2CwkY2chaZmFpGUWkpYFjCyrGEUzcwpKknLT DYz0UpMzS1JzUvWS83M3MQIjcvKrTy92ME7YrHOIkYmDU6qBsc91n4h7WWzzZMW9RZv1G1tn hRSbx7R2m9vxH2GeaSn49NZCv6Dm27zdsW0njRtlFWJ1BU5dnyOx9O2979fvZOmXr/c6MO1g yekwu91ih8OEDy1wXSp7s33H3TtPVj84VlHVxH+5b0mujFJUW4D2E40bwVb1l9LPNPnsyjh3 v2g/79+957eoK7EUZyQaajEXFScCANMvhnN4AgAA Cc: "mpls@ietf.org" , "Zhao, Peng \(NSN - CN/Shanghai\)" , "Pietilainen, Antti \(NSN - FI/Espoo\)" , "tictoc@ietf.org" , "Mallette, Edwin" , "stbryant@cisco.com" Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 20:11:59 -0000 Curtis, Lots of thanks for a prompt and very detailed response. 1. I have proposed the "send what you can, accept both" approach in my earl= ier email to the TICTOC list (http://www.ietf.org/mail-archive/web/tictoc/current/msg00877.html). So it = seems that we are on the same wavelength. 2. The "timestamp capture point in the data path" was not about the timesta= mp location in the message. It is about the stage of the data processing when the timestamp can be capt= ured. E.g., some designs use commercial HW that captures the timestamps bet= ween PHY and MAC. This is OK for PTP and NTP, but excludes the time spent i= n the egress queue of the node from delay measurement. 3. You have said that 20 microseconds look to you as very good accuracy for= delay measurements. This probably depends on the application. E.g., if we = must synchronize two base stations within 2-3 microseconds of relative ToD = error, this accuracy will hardly help you to understand why your synchroniz= ation mechanisms do not work:-). I am somewhat suspicious about a measurement procedure that does not specif= y accuracy explicitly. But I understand the position taken by the draft aut= hors. Regards, Sasha > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Tuesday, March 08, 2011 9:37 PM > To: Alexander Vainshtein > Cc: curtis@occnc.com; mpls@ietf.org; Zhao, Peng (NSN - CN/Shanghai); > Pietilainen, Antti (NSN - FI/Espoo); tictoc@ietf.org; > stbryant@cisco.com; Mallette, Edwin > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp > > > In message > > Alexander Vainshtein writes: > > > > Curtis, and all, > > > > To the best of my understanding, this is not about accuracy of > > synchronization using NTP or PTP. It is about the default timestamp > > format in the Delay Measurement (DM) messages for MPLS. > > > > Whatever accuracy can be achieved with one of these, the timestamp > > format is probably the least significant factor affecting the result. > > For very high timestamp accuracy, the timestamp must be generated in > hardware. Perhaps the answer is send either format (maximize the > supported hardware) and accept both. > > On the receive side, the locally generated time stamp can be converted > or the sent timestamp can be converted to achieve a common format. > > It is the transmit timestamp that is hard to get into a format that > the hardware does not support. > > > I have already stated on this list that, IMHO, the question itself is > > moot, because the DM can operate with disparate timestamp formats at > > two ends: actual format is specified in the message, and there is no > > need to do conversion in HW or in hard real time. What's more, 2-way > > DM does not even require conversion from one timestamp format to > > another, just ability to compute differences between two timestamps > in > > the same format both for NTP and PTP formats. > > It seems that the timestamp fields are nearly identical. > IEEE-1588-2008 section 5,2,3 contains: > > struct Timestamp { > UInteger48 secondsField; > UInteger32 nanosecondsFeild; > }; > > Hopefully IEEE will see this excerpt as an acceptable "fair use". > > This is very similar to the unix/bsd/linux timespec. > > struct timespec { > time_t tv_sec; /* seconds */ > long tv_nsec; /* and nanoseconds */ > }; > > The NTP 64 bit timestamp is also quite similar (RFC5905). > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Seconds | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Fraction | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > NTP Timestamp Format > > Briefly (from RFC5905) "It includes a 32-bit unsigned seconds field > spanning 136 years and a 32-bit fraction field resolving 232 > picoseconds." The resolution of NTP 64 bit timestamp is slightly > better by about a factor of four. > > The draft-ietf-mpls-loss-delay-01 draft chops off the top 16 bits and > therefore is really using unix/bsd/linux timespec format. > > The conversion for PTP to timespec is tacking on or removing 16 bits > of leading zeros. That conversion will work for the next 90+ years, > which gives us a lot of time to decide how to extend time_t and > timespec and all the things that go with it, however NTP has this > covered in the 128 bit format when we go beyond era 0. > > Is there an endian-ness issue that I'm missing? In any case, this is > acheivable as long as we specify "send either" and "accept both". > > Perhaps the expected lifetime of the solar system would be an adequate > target, but 2106 may be OK for now so NTP 64 bit format is OK. :-) > > OTOH, NTP also supports a 32 bit stamp: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Seconds | Fraction | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Again from RFC5905 "The 32-bit short format is used in delay and > dispersion header fields where the full resolution and range of the > other formats are not justified. It includes a 16-bit unsigned > seconds field and a 16-bit fraction field." > > 1 second / 65536 is less than 20 usec. This should be fine in delay > measurements. It is less than 4km worth of fiber if I've done the > math right. Otherwise we stick with the 64 bit format only. > > I should also point out that 20 usec accuracy may be within the range > acheivable in software, or at least packet processor microcode. > > As spcified in draft-ietf-mpls-loss-delay-01 the 32 bit timestamp > would be padded out to 64 bits, so there is no motivation to use it. > > > In addition, the points in the data path where the timestamps are > > captured by a HW assist for the needs of a given protocol do not > > necessarily match the points where these timestamps should be taken > > for the purpose of DM. While it is probably possible to live with DM > > that ignores the time a packet is queued for transmission in the > > originating LSR, the results could look fishy, especially if the > > objective is to measure PDV and not delay per se. In other words, a > > timestamping HW assist that is optimal from the point of view of PTP > > "as close to actual ingress/egress as possible"), may be not very > > effective for DM (and, of course, vice versa). > > We have been specifying hardware that allows the PTP and NTP 64 bit > and 32 bit time stamp formats to be placed at an arbitrary byte > location. Packets from CPU to hardware have an internal header that > gets stripped before going out and one thing that can go in that > header is an indication of time stamp format and where to put it (byte > offset). Final modifications for NTP, PTP, LM, DM, happen there. > > I am aware that some "merchant silicon" has some built in assumptions > about how these timestamps will be used and may only be able to > support hardware asssisted time synchronization using PTP over > Ethernet. That does not mean we should limit our specs in IETF to use > PTP formats only. > > > My 2c, > > Sasha > > Therefore I support "send any", and "accept all" as the MUST. This > guarentees interoperability and removes any need to negociate formats. > As long as hardware can record stamps, software can convert them and > produce a delay value. > > Thanks, > > Curtis > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of > > > Curtis Villamizar > > > Sent: Tuesday, March 08, 2011 1:20 AM > > > To: Mallette, Edwin > > > Cc: mpls@ietf.org; Zhao, Peng (NSN - CN/Shanghai); Pietilainen, > Antti > > > (NSN - FI/Espoo); tictoc@ietf.org; stbryant@cisco.com > > > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp > > > > > > > > > In message > > > "Mallette, Edwin" writes: > > > > > > > > I concur with the points made by Nurit and Ben. In addition > there is > > > > the asymmetric delay problems (for a given link) that lots of > work > > > has > > > > gone into to solve with 1588 - 1588 Transparent Clock / 1588 > > > residency > > > > time compensation. To the best of my knowledge this is not being > > > > addressed for NTP. > > > > > > > > Thus +1 for the default of IEEE1588. > > > > > > > > Ed > > > > > > > > > NTP has always, probably from day one but at least going back to > the > > > early 1990s (AFAIK), compensated for asymetric delay. > > > > > > With hardware assist, NTP deployed over a link is every bit as > > > accurate as PTP deployed over a link with hardware assist. It is > > > probably more accurate due to the jitter compensation used by NTP > and > > > omited by PTP. Some hardware doesn't quite get all the jitter out. > > > > > > Admitedly, NTP is more complex due to the compensation that is > > > included in NTP and not in PTP. > > > > > > OTOH if there is something that favors PTP, then we should approach > > > the TICTOC WG and pass along that requirements. For example, a two > > > step transmit, allowing the transmit timestamp on a given packet to > be > > > sent with the next packet, may simplify hardware. If so, we ask > > > TICTOC to support that in NTP. > > > > > > I support making the default NTP. This is the IETF and given a > very > > > nearly equivalent IETF solution and an IEEE solution we should > require > > > the IETF solution, make the IEEE solution optional, and if there > are > > > any shortcomings to the IETF solution, address that in the > appropriate > > > IETF WG. > > > > > > Curtis > > > > > > > > > > From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" > > > > > > > > > Date: Fri, 4 Mar 2011 05:32:07 -0500 > > > > To: "stbryant@cisco.com" > > > > >, > > > > "mpls@ietf.org" > > > > > > > > > Cc: "Zhao, Peng (NSN - CN/Shanghai)" > > > > >, > "Pietilainen, > > > > Antti (NSN - FI/Espoo)" > > > > > >, > > > > "tictoc@ietf.org" > > > > > > > > > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp > > > > > > > > Stewart hi, > > > > The accuracy targets as described below are approaching a level > where > > > > on-path support is needed. > > > > In this case the clear choice is IEEE 1588 because it specifies > > > > on-path support whereas NTP does not. > > > > Even without on-path support IEEE 1588 could be better if better > > > > accuracy is pursued by sending multiple timing packets per second > per > > > > slave/client, because standard NTP clients send messages at a > very > > > low > > > > rate for saving server resources. > > > > I support the default of IEEE1588! > > > > Best regards, > > > > Nurit > > > > > > > > From: mpls-bounces@ietf.org > > > [mailto:mpls-bounces@ietf.org] On Behalf Of ext Stewart Bryant > > > > Sent: Thursday, March 03, 2011 6:07 PM > > > > To: mpls@ietf.org > > > > Cc: tictoc@ietf.org > > > > Subject: [mpls] draft-ietf-mpls-loss-delay Timestamp > > > > > > > > > > > > We have received a LC comment on draft-ietf-mpls-loss-delay > > > concerning > > > > the default timestamp. > > > > > > > > In the first version of the draft we proposed NTP, but following > > > > initial comments from the MPLS-TP community we changed to > > > > IEEE1588. This requirement for IEEE1588 can be traced back to the > > > > choice of using IEEE1588 in Y.1731. > > > > > > > > We have now received a LC request to change the default back to > NTP. > > > > > > > > NTP is the "natural" choice for an IETF protocol. NTP is > specified in > > > > IETF and is used in other MPLS protocols such as LSP ping. It is > > > > implemented on almost every host and every router. However in > general > > > > the implementations provides a relatively low precision > timestamp, > > > and > > > > the NTP time distribution infrastructure operates on a best > effort > > > > basis. Thus even a good client implementation would normally have > a > > > > relatively low quality path to the server, which would result in > a > > > low > > > > quality of timestamp. NTP could be made to work to higher > accuracy, > > > > but defacto upgrading NTP and providing high quality NTP paths to > the > > > > time servers is not getting much attention. Computing timestamp > > > > differences is easier with NTP. > > > > > > > > On the other hand IEEE1588 has defacto become the two way time > > > tranfer > > > > protocol for precision applications. IEEE1588 only provides high > > > > quality time in well engineered networks with some form of hop by > hop > > > > assistance. It is not widely implemented other than in equipment > > > > targeted to specific markets, although one of those markets is in > > > > mobile backhaul applications where we expect to see significant > > > > initial deployment of MPLS-TP. Computing timestamp differences is > > > > harder with IEEE1588 > > > > > > > > The loss-delay work is targeting to be able to do one way packet > > > delay > > > > measurement, so it does need a higher quality of timestamp than > is > > > > required in general purpose network instrumentation. > > > > > > > > Converting from IEEE1588 to NTP is not trivial, since they use > > > > different epochs, and different representations of sub-second > time. > > > In > > > > a "traditional" NTP implementation the time error due to on the > fly > > > > conversion is likely to be small compared to the time error in > the > > > > time synchronization system, but an IEEE1588 system would need > > > > hardware conversion to maintain the accuracy for an NTP > timestamp. > > > > > > > > So the question arises, should we make IEEE1588 or NTP the > default > > > for > > > > draft-ietf-mpls-loss-delay. Much as I would like to suggest that > we > > > > should go back to NTP for consistency with other IETF protocols, > I > > > > have difficulty reconciling this with the situation in network > > > > deployments and thus suggest that we continue to use IEEE1588. > > > > > > > > What is the opinion of the working group? > > > > > > > > Stewart (speaking as a draft editor) > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls From curtis@occnc.com Tue Mar 8 16:06:23 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCDD63A67B8; Tue, 8 Mar 2011 16:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 SgOTgeQ6nLYx; Tue, 8 Mar 2011 16:06:22 -0800 (PST) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id AABB13A67AB; Tue, 8 Mar 2011 16:06:21 -0800 (PST) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p29068jF052572; Tue, 8 Mar 2011 19:06:08 -0500 (EST) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201103090006.p29068jF052572@harbor.orleans.occnc.com> To: Alexander Vainshtein From: Curtis Villamizar In-reply-to: Your message of "Tue, 08 Mar 2011 22:13:06 +0200." Date: Tue, 08 Mar 2011 19:06:08 -0500 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , "Zhao, Peng \(NSN - CN/Shanghai\)" , "Pietilainen, Antti \(NSN - FI/Espoo\)" , "tictoc@ietf.org" , "Mallette, Edwin" , "stbryant@cisco.com" Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 00:06:23 -0000 In message Alexander Vainshtein writes: > > Curtis, > Lots of thanks for a prompt and very detailed response. > > 1. I have proposed the "send what you can, accept both" approach in my > earlier email to the TICTOC list > (http://www.ietf.org/mail-archive/web/tictoc/current/msg00877.html). So > it seems that we are on the same wavelength. Agree. > 2. The "timestamp capture point in the data path" was not about the > timestamp location in the message. It is about the stage of the data > processing when the timestamp can be captured. E.g., some designs use > commercial HW that captures the timestamps between PHY and MAC. This > is OK for PTP and NTP, but excludes the time spent in the egress queue > of the node from delay measurement. That is why in NTP, PTP, and draft-ietf-mpls-loss-delay there are four timestamps. The total round trip delay subtracts the third and second to eliminate queueing and turn around. > 3. You have said that 20 microseconds look to you as very good > accuracy for delay measurements. This probably depends on the > application. E.g., if we must synchronize two base stations within 2-3 > microseconds of relative ToD error, this accuracy will hardly help you > to understand why your synchronization mechanisms do not work:-). I > am somewhat suspicious about a measurement procedure that does not > specify accuracy explicitly. But I understand the position taken by > the draft authors. 20 usec is OK for draft-ietf-mpls-loss-delay type measurements. draft-ietf-mpls-loss-delay is not used to synchronize clocks. For that NTP is used and that uses the 64 fit format for that purpose. The 64 bit time stamp is relative to the NTP era. We are in era zero until the year 2106. You seem to misinterpret what I said 20 usec is OK for. As I mentioned, NTP is good to just under 1 nsec if the hardware is dead accurate in producing both transmit and receive time stamps. If there is some inaccuracy in the timestamping, then NTP is better equiped to remove that inaccuracy (using multiple samples) than PTP is. BTW - If all that is needed is an accurate oscillator (for example for CE or mobile backhaul), then a slightly assymetric path is OK. > Regards, > Sasha Curtis > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Tuesday, March 08, 2011 9:37 PM > > To: Alexander Vainshtein > > Cc: curtis@occnc.com; mpls@ietf.org; Zhao, Peng (NSN - CN/Shanghai); > > Pietilainen, Antti (NSN - FI/Espoo); tictoc@ietf.org; > > stbryant@cisco.com; Mallette, Edwin > > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp > > > > > > In message > > > > Alexander Vainshtein writes: > > > > > > Curtis, and all, > > > > > > To the best of my understanding, this is not about accuracy of > > > synchronization using NTP or PTP. It is about the default timestamp > > > format in the Delay Measurement (DM) messages for MPLS. > > > > > > Whatever accuracy can be achieved with one of these, the timestamp > > > format is probably the least significant factor affecting the result. > > > > For very high timestamp accuracy, the timestamp must be generated in > > hardware. Perhaps the answer is send either format (maximize the > > supported hardware) and accept both. > > > > On the receive side, the locally generated time stamp can be converted > > or the sent timestamp can be converted to achieve a common format. > > > > It is the transmit timestamp that is hard to get into a format that > > the hardware does not support. > > > > > I have already stated on this list that, IMHO, the question itself is > > > moot, because the DM can operate with disparate timestamp formats at > > > two ends: actual format is specified in the message, and there is no > > > need to do conversion in HW or in hard real time. What's more, 2-way > > > DM does not even require conversion from one timestamp format to > > > another, just ability to compute differences between two timestamps > > in > > > the same format both for NTP and PTP formats. > > > > It seems that the timestamp fields are nearly identical. > > IEEE-1588-2008 section 5,2,3 contains: > > > > struct Timestamp { > > UInteger48 secondsField; > > UInteger32 nanosecondsFeild; > > }; > > > > Hopefully IEEE will see this excerpt as an acceptable "fair use". > > > > This is very similar to the unix/bsd/linux timespec. > > > > struct timespec { > > time_t tv_sec; /* seconds */ > > long tv_nsec; /* and nanoseconds */ > > }; > > > > The NTP 64 bit timestamp is also quite similar (RFC5905). > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Seconds | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Fraction | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > NTP Timestamp Format > > > > Briefly (from RFC5905) "It includes a 32-bit unsigned seconds field > > spanning 136 years and a 32-bit fraction field resolving 232 > > picoseconds." The resolution of NTP 64 bit timestamp is slightly > > better by about a factor of four. > > > > The draft-ietf-mpls-loss-delay-01 draft chops off the top 16 bits and > > therefore is really using unix/bsd/linux timespec format. > > > > The conversion for PTP to timespec is tacking on or removing 16 bits > > of leading zeros. That conversion will work for the next 90+ years, > > which gives us a lot of time to decide how to extend time_t and > > timespec and all the things that go with it, however NTP has this > > covered in the 128 bit format when we go beyond era 0. > > > > Is there an endian-ness issue that I'm missing? In any case, this is > > acheivable as long as we specify "send either" and "accept both". > > > > Perhaps the expected lifetime of the solar system would be an adequate > > target, but 2106 may be OK for now so NTP 64 bit format is OK. :-) > > > > OTOH, NTP also supports a 32 bit stamp: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Seconds | Fraction | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Again from RFC5905 "The 32-bit short format is used in delay and > > dispersion header fields where the full resolution and range of the > > other formats are not justified. It includes a 16-bit unsigned > > seconds field and a 16-bit fraction field." > > > > 1 second / 65536 is less than 20 usec. This should be fine in delay > > measurements. It is less than 4km worth of fiber if I've done the > > math right. Otherwise we stick with the 64 bit format only. > > > > I should also point out that 20 usec accuracy may be within the range > > acheivable in software, or at least packet processor microcode. > > > > As spcified in draft-ietf-mpls-loss-delay-01 the 32 bit timestamp > > would be padded out to 64 bits, so there is no motivation to use it. > > > > > In addition, the points in the data path where the timestamps are > > > captured by a HW assist for the needs of a given protocol do not > > > necessarily match the points where these timestamps should be taken > > > for the purpose of DM. While it is probably possible to live with DM > > > that ignores the time a packet is queued for transmission in the > > > originating LSR, the results could look fishy, especially if the > > > objective is to measure PDV and not delay per se. In other words, a > > > timestamping HW assist that is optimal from the point of view of PTP > > > "as close to actual ingress/egress as possible"), may be not very > > > effective for DM (and, of course, vice versa). > > > > We have been specifying hardware that allows the PTP and NTP 64 bit > > and 32 bit time stamp formats to be placed at an arbitrary byte > > location. Packets from CPU to hardware have an internal header that > > gets stripped before going out and one thing that can go in that > > header is an indication of time stamp format and where to put it (byte > > offset). Final modifications for NTP, PTP, LM, DM, happen there. > > > > I am aware that some "merchant silicon" has some built in assumptions > > about how these timestamps will be used and may only be able to > > support hardware asssisted time synchronization using PTP over > > Ethernet. That does not mean we should limit our specs in IETF to use > > PTP formats only. > > > > > My 2c, > > > Sasha > > > > Therefore I support "send any", and "accept all" as the MUST. This > > guarentees interoperability and removes any need to negociate formats. > > As long as hardware can record stamps, software can convert them and > > produce a delay value. > > > > Thanks, > > > > Curtis > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf Of > > > > Curtis Villamizar > > > > Sent: Tuesday, March 08, 2011 1:20 AM > > > > To: Mallette, Edwin > > > > Cc: mpls@ietf.org; Zhao, Peng (NSN - CN/Shanghai); Pietilainen, > > Antti > > > > (NSN - FI/Espoo); tictoc@ietf.org; stbryant@cisco.com > > > > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp > > > > > > > > > > > > In message > > > > "Mallette, Edwin" writes: > > > > > > > > > > I concur with the points made by Nurit and Ben. In addition > > there is > > > > > the asymmetric delay problems (for a given link) that lots of > > work > > > > has > > > > > gone into to solve with 1588 - 1588 Transparent Clock / 1588 > > > > residency > > > > > time compensation. To the best of my knowledge this is not being > > > > > addressed for NTP. > > > > > > > > > > Thus +1 for the default of IEEE1588. > > > > > > > > > > Ed > > > > > > > > > > > > NTP has always, probably from day one but at least going back to > > the > > > > early 1990s (AFAIK), compensated for asymetric delay. > > > > > > > > With hardware assist, NTP deployed over a link is every bit as > > > > accurate as PTP deployed over a link with hardware assist. It is > > > > probably more accurate due to the jitter compensation used by NTP > > and > > > > omited by PTP. Some hardware doesn't quite get all the jitter out. > > > > > > > > Admitedly, NTP is more complex due to the compensation that is > > > > included in NTP and not in PTP. > > > > > > > > OTOH if there is something that favors PTP, then we should approach > > > > the TICTOC WG and pass along that requirements. For example, a two > > > > step transmit, allowing the transmit timestamp on a given packet to > > be > > > > sent with the next packet, may simplify hardware. If so, we ask > > > > TICTOC to support that in NTP. > > > > > > > > I support making the default NTP. This is the IETF and given a > > very > > > > nearly equivalent IETF solution and an IEEE solution we should > > require > > > > the IETF solution, make the IEEE solution optional, and if there > > are > > > > any shortcomings to the IETF solution, address that in the > > appropriate > > > > IETF WG. > > > > > > > > Curtis > > > > > > > > > > > > > From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" > > > > > > > > > > > Date: Fri, 4 Mar 2011 05:32:07 -0500 > > > > > To: "stbryant@cisco.com" > > > > > >, > > > > > "mpls@ietf.org" > > > > > > > > > > > Cc: "Zhao, Peng (NSN - CN/Shanghai)" > > > > > >, > > "Pietilainen, > > > > > Antti (NSN - FI/Espoo)" > > > > > > > >, > > > > > "tictoc@ietf.org" > > > > > > > > > > > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp > > > > > > > > > > Stewart hi, > > > > > The accuracy targets as described below are approaching a level > > where > > > > > on-path support is needed. > > > > > In this case the clear choice is IEEE 1588 because it specifies > > > > > on-path support whereas NTP does not. > > > > > Even without on-path support IEEE 1588 could be better if better > > > > > accuracy is pursued by sending multiple timing packets per second > > per > > > > > slave/client, because standard NTP clients send messages at a > > very > > > > low > > > > > rate for saving server resources. > > > > > I support the default of IEEE1588! > > > > > Best regards, > > > > > Nurit > > > > > > > > > > From: mpls-bounces@ietf.org > > > > [mailto:mpls-bounces@ietf.org] On Behalf Of ext Stewart Bryant > > > > > Sent: Thursday, March 03, 2011 6:07 PM > > > > > To: mpls@ietf.org > > > > > Cc: tictoc@ietf.org > > > > > Subject: [mpls] draft-ietf-mpls-loss-delay Timestamp > > > > > > > > > > > > > > > We have received a LC comment on draft-ietf-mpls-loss-delay > > > > concerning > > > > > the default timestamp. > > > > > > > > > > In the first version of the draft we proposed NTP, but following > > > > > initial comments from the MPLS-TP community we changed to > > > > > IEEE1588. This requirement for IEEE1588 can be traced back to the > > > > > choice of using IEEE1588 in Y.1731. > > > > > > > > > > We have now received a LC request to change the default back to > > NTP. > > > > > > > > > > NTP is the "natural" choice for an IETF protocol. NTP is > > specified in > > > > > IETF and is used in other MPLS protocols such as LSP ping. It is > > > > > implemented on almost every host and every router. However in > > general > > > > > the implementations provides a relatively low precision > > timestamp, > > > > and > > > > > the NTP time distribution infrastructure operates on a best > > effort > > > > > basis. Thus even a good client implementation would normally have > > a > > > > > relatively low quality path to the server, which would result in > > a > > > > low > > > > > quality of timestamp. NTP could be made to work to higher > > accuracy, > > > > > but defacto upgrading NTP and providing high quality NTP paths to > > the > > > > > time servers is not getting much attention. Computing timestamp > > > > > differences is easier with NTP. > > > > > > > > > > On the other hand IEEE1588 has defacto become the two way time > > > > tranfer > > > > > protocol for precision applications. IEEE1588 only provides high > > > > > quality time in well engineered networks with some form of hop by > > hop > > > > > assistance. It is not widely implemented other than in equipment > > > > > targeted to specific markets, although one of those markets is in > > > > > mobile backhaul applications where we expect to see significant > > > > > initial deployment of MPLS-TP. Computing timestamp differences is > > > > > harder with IEEE1588 > > > > > > > > > > The loss-delay work is targeting to be able to do one way packet > > > > delay > > > > > measurement, so it does need a higher quality of timestamp than > > is > > > > > required in general purpose network instrumentation. > > > > > > > > > > Converting from IEEE1588 to NTP is not trivial, since they use > > > > > different epochs, and different representations of sub-second > > time. > > > > In > > > > > a "traditional" NTP implementation the time error due to on the > > fly > > > > > conversion is likely to be small compared to the time error in > > the > > > > > time synchronization system, but an IEEE1588 system would need > > > > > hardware conversion to maintain the accuracy for an NTP > > timestamp. > > > > > > > > > > So the question arises, should we make IEEE1588 or NTP the > > default > > > > for > > > > > draft-ietf-mpls-loss-delay. Much as I would like to suggest that > > we > > > > > should go back to NTP for consistency with other IETF protocols, > > I > > > > > have difficulty reconciling this with the situation in network > > > > > deployments and thus suggest that we continue to use IEEE1588. > > > > > > > > > > What is the opinion of the working group? > > > > > > > > > > Stewart (speaking as a draft editor) > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Wed Mar 9 05:02:01 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6193A699F; Wed, 9 Mar 2011 05:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] 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 R5OTMfO8Hu8r; Wed, 9 Mar 2011 05:02:00 -0800 (PST) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id 6A6D53A6971; Wed, 9 Mar 2011 05:01:59 -0800 (PST) X-AuditID: 93eaf2e8-b7bcdae000001123-43-4d777a3686f1 Received: from ILPTEXCH02.ecitele.com (ilptexfe.ecitele.com [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 59.C3.04387.63A777D4; Wed, 9 Mar 2011 15:01:42 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 9 Mar 2011 15:03:14 +0200 From: Alexander Vainshtein To: "curtis@occnc.com" Date: Wed, 9 Mar 2011 15:03:12 +0200 Thread-Topic: [mpls] draft-ietf-mpls-loss-delay Timestamp Thread-Index: Acvd7f8DyssYp0egSU6uRgxTQxuM3QAZzkcQ Message-ID: References: Your message of "Tue, 08 Mar 2011 22:13:06 +0200." <201103090006.p29068jF052572@harbor.orleans.occnc.com> In-Reply-To: <201103090006.p29068jF052572@harbor.orleans.occnc.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUy+dXXrbpmVeW+Bq+6tSx6zv1ktzh8YDq7 xd9X3xgtbi1dyWrx+tVNZotzT+cwWvxt7mF3YPe4svAbs8eU3xtZPZYs+cnk8XP9VXaPxV/8 AlijuGxSUnMyy1KL9O0SuDIe9ZxlLbghVrHsXytTA+M8oS5GTg4JAROJW4vXsELYYhIX7q1n A7GFBM4zSty/kNTFyAVkT2WUmLxsAztIgk3AVmLT6rtgRSICmhJ/J21mByliFljNJLFg/k0W kASLgIrE+gcbwYqEBSwldvQvYYdosJKYc/E3I4RtJLH861qwGl4Bf4nf0xYwQ2w7xSixctFj sEGcAs4Sy3q6wM5jBDrv+6k1TCA2s4C4xK0n85kgzhaQWLLnPDOELSrx8vE/qHpRiTvt6xkh 6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzUIydhaSlllIWmYhaVnAyLKKUTQzp6AkKTfd wEgvNTmzJDUnVS85P3cTIzgiP73YwThhs84hRiYOTqkGxgJz/bs344VuCDXYWS3wkKy0EGPJ 3lV3IPFv3l22wwmtrPfehV8w2WDuMO+o4v+6o0YNW3YsOypsYP5xbfYUvfAVM+e+1Hgc82N/ /sTcR2mHdpx4PEV609z72cevpH6NyVg5Yd/vMMef72XbPk+ZW3BhtbaV9cKJFTfP2h77wPHz 64UFsrPl3q9WYinOSDTUYi4qTgQAZYld03gCAAA= Cc: "mpls@ietf.org" , "Zhao, Peng \(NSN - CN/Shanghai\)" , "Pietilainen, Antti \(NSN - FI/Espoo\)" , "tictoc@ietf.org" , "Mallette, Edwin" , "stbryant@cisco.com" Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 13:02:01 -0000 Curtis, Lots of thanks for a prompt and delayed response. Please see some comments inline below. I've shipped the next that is not re= lated to these comments. Regards, Sasha > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Wednesday, March 09, 2011 2:06 AM > To: Alexander Vainshtein > Cc: curtis@occnc.com; mpls@ietf.org; Zhao, Peng (NSN - CN/Shanghai); > Pietilainen, Antti (NSN - FI/Espoo); tictoc@ietf.org; > stbryant@cisco.com; Mallette, Edwin > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp >=20 --- snipped --- > > 2. The "timestamp capture point in the data path" was not about the > > timestamp location in the message. It is about the stage of the data > > processing when the timestamp can be captured. E.g., some designs use > > commercial HW that captures the timestamps between PHY and MAC. This > > is OK for PTP and NTP, but excludes the time spent in the egress > queue > > of the node from delay measurement. >=20 > That is why in NTP, PTP, and draft-ietf-mpls-loss-delay there are four > timestamps. The total round trip delay subtracts the third and second > to eliminate queuing and turn around. [[[Sasha]]] Please consider the following use case: - I am going to use a certain LSP as a tunnel for TDM PWs - I would like to measure packet delay *variation* (PDV) introduced by this= LSP in order to configure the jitter buffer of these TDM PWs. I expect to = do that by measuring delay for multiple samples and computing the PDV as (M= ax. measured delay - Min. measured delay) - If queuing delay at the LSP head- and tail-nodes is not accounted in my d= elay measurements, my PDV estimation will not account for that also (becaus= e queuing only increases Max. measured delay) - As a consequence, my PDV estimation may be not suitable for configuring t= he jitter buffer correctly. As a consequence, my TDM customers will see err= ors in their traffic when TDM PW packets that arrive too late to be accommo= dated into the jitter buffer are discarded and their payload replaced with = "all ones". Do I miss something here? >=20 > > 3. You have said that 20 microseconds look to you as very good > > accuracy for delay measurements. This probably depends on the > > application. E.g., if we must synchronize two base stations within 2- > 3 > > microseconds of relative ToD error, this accuracy will hardly help > you > > to understand why your synchronization mechanisms do not work:-). I > > am somewhat suspicious about a measurement procedure that does not > > specify accuracy explicitly. But I understand the position taken by > > the draft authors. >=20 > 20 usec is OK for draft-ietf-mpls-loss-delay type measurements. [[[Sasha]]] I would be happy to accept that. But the draft does not yield t= his (or any other) number. --- snipped to the end --- From wwwrun@core3.amsl.com Wed Mar 9 06:17:17 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8A0363A69CC; Wed, 9 Mar 2011 06:17:17 -0800 (PST) From: Greg Jones(ITU-T SG 15) To: rcallon@juniper.net,swallow@cisco.com,loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110309141717.8A0363A69CC@core3.amsl.com> Date: Wed, 9 Mar 2011 06:17:17 -0800 (PST) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, Steve.Trowbridge@alcatel-lucent.com, yoichi.maeda@ttc.or.jp, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS283 - Response to Comments on the Updated draft Recommendation ITU-T G.8151 [Ref 045.04]" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:17:17 -0000 Title: LS283 - Response to Comments on the Updated draft Recommendation ITU-T G.8151 [Ref 045.04] Submission Date: 2011-03-09 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1027 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(rcallon@juniper.net,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp Steve.Trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: Kam.Lam@alcatel-lucent.com Purpose: For information Body: Thank you for your liaison titled �Response to Updated draft Recommendation G.8151 [Ref 045.03]�, which provides your review comments on draft G.8151 Revision. Q14/15 thanks your comments regarding the IP-based MEG-ID and MEP_ID and MEL. Q14/15 will take these comments into consideration when updating the draft Recommendation. No newer version of draft G.8151 was produced from this SG15 plenary meeting. Attachment(s): LS283 - Response to Comments on the Updated draft Recommendation ITU-T G.8151 [Ref 045.04] - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1198.pdf) From wwwrun@core3.amsl.com Wed Mar 9 06:43:20 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 208DC3A69D5; Wed, 9 Mar 2011 06:43:19 -0800 (PST) From: Greg Jones(ITU-T SG 15) To: chair@ietf.org,rcallon@juniper.net,swallow@cisco.com,loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110309144320.208DC3A69D5@core3.amsl.com> Date: Wed, 9 Mar 2011 06:43:20 -0800 (PST) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, Steve.Trowbridge@alcatel-lucent.com, Ghani.Abbas@ericsson.com, yoichi.maeda@ttc.or.jp, paf@cisco.com, iesg@ietf.org, tsbsg15@itu.int, stbryant@cisco.com, adrian.farrel@huawei.com Subject: [mpls] New Liaison Statement, "LS285 - Review of "draft-ietf-mpls-tp-linear-protection-04 (ref #049.01)" [ref #049.02]" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:43:20 -0000 Title: LS285 - Review of "draft-ietf-mpls-tp-linear-protection-04 (ref #049.01)" [ref #049.02] Submission Date: 2011-03-09 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1028 Please reply by 2011-03-31 From: Greg Jones(ITU-T SG 15) To: IESG; IETF MPLS WG(chair@ietf.org,rcallon@juniper.net,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org iesg@ietf.org yoichi.maeda@ttc.or.jp Steve.Trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: Ghani.Abbas@ericsson.com Purpose: For action Body: ITU-T SG15 thanks the IETF MPLS WG for the liaison �The IETF MPLS working group last call on "MPLS-TP Linear Protection" (ref #049.01)�. During the review of this draft a number of comments were identified and listed as in the attached document. We request that you address these comments provided in the attached document and provide us a new version of the text. Q9/15 would appreciate the opportunity to discuss the disposition of these comments before the MPLS Working Group requests publication of this document as an RFC. Attach: Q9/15 comments on draft draft-ietf-mpls-tp-linear-protection-04. Attachment(s): LS285 - Review of "draft-ietf-mpls-tp-linear-protection-04 (ref #049.01)" [ref #049.02] - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1199.pdf) LS285 - Review of "draft-ietf-mpls-tp-linear-protection-04 (ref #049.01)" [ref #049.02] - pdf attach (https://datatracker.ietf.org/documents/LIAISON/file1200.pdf) From wwwrun@core3.amsl.com Wed Mar 9 07:18:28 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E74723A69D9; Wed, 9 Mar 2011 07:18:28 -0800 (PST) From: Greg Jones(ITU-T SG 15) To: lberger@labn.net, dbrungard@att.com, jpv@cisco.com, rcallon@juniper.net, swallow@cisco.com, loa@pi.nu, julien.meuric@orange-ftgroup.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110309151828.E74723A69D9@core3.amsl.com> Date: Wed, 9 Mar 2011 07:18:28 -0800 (PST) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, Steve.Trowbridge@alcatel-lucent.com, ccamp@ietf.org, yoichi.maeda@ttc.or.jp, pce@ietf.org, adrian.farrel@huawei.com, tsbsg15@itu.int, paf@cisco.com, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS274 - SG15 OTNT Standardization Work Plan" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 15:18:29 -0000 Title: LS274 - SG15 OTNT Standardization Work Plan Submission Date: 2011-03-09 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1029 Please reply by 2011-11-18 From: Greg Jones(ITU-T SG 15) To: IETF (CCAMP, PCE and MPLS WGs)(lberger@labn.net,dbrungard@att.com,jpv@cisco.com,rcallon@juniper.net,swallow@cisco.com,loa@pi.nu,julien.meuric@orange-ftgroup.com) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com ccamp@ietf.org pce@ietf.org mpls@ietf.org yoichi.maeda@ttc.or.jp Steve.Trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: koike.yoshinori@lab.ntt.co.jp Purpose: For comment Body: Thank you for your previous review and comments for �Optical Transport Networks & Technologies Standardization Work Plan�. Attached is the updated version from this SG15 meeting (Geneva, 14-25 February 2011). This version reflects recent development of related standards and your valuable input. We appreciate your review of this latest version and comments. Attachment: OTNT Standardization Work Plan, Issue 14 (TD408R1/PLEN) Attachment(s): LS274 - SG15 OTNT Standardization Work Plan - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1201.pdf) LS274 - SG15 OTNT Standardization Work Plan - pdf attach (https://datatracker.ietf.org/documents/LIAISON/file1202.pdf) From wwwrun@core3.amsl.com Wed Mar 9 07:33:14 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id BDC5A3A6866; Wed, 9 Mar 2011 07:33:14 -0800 (PST) From: Greg Jones(ITU-T SG 15) To: rcallon@juniper.net,swallow@cisco.com,loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110309153314.BDC5A3A6866@core3.amsl.com> Date: Wed, 9 Mar 2011 07:33:14 -0800 (PST) Cc: Huub.van.Helvoort@huawei.com, mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, Steve.Trowbridge@alcatel-lucent.com, yoichi.maeda@ttc.or.jp, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS259 - Reply to the IETF MPLS working group last call on "A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks (ref #051.01)" (ref #051.02)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 15:33:15 -0000 Title: LS259 - Reply to the IETF MPLS working group last call on "A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks (ref #051.01)" (ref #051.02) Submission Date: 2011-03-09 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1030 Please reply by 2011-06-01 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(rcallon@juniper.net,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp Steve.Trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: Huub.van.Helvoort@huawei.com Purpose: For comment Body: Thank you for your liaison statement (Ref # 051.01) requesting a review by the ITU-T of the draft "A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks". Please note that in the past weeks the Q10/15 experts have been very busy preparing for the ITU-T SG15 plenary meeting and attending this meeting in Geneva 14-25 February 2011. Considering the limited amount of time, the Q10/15 experts may send more comments at a later date. We request that you address the comments and provide us a new version of draft-ietf-mpls-tp-loss-delay-profile. Q10/15 would like to have an opportunity to review the next version of this draft before approval. Attachment(s): LS259 - Reply to the IETF MPLS working group last call on "A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks (ref #051.01)" - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1203.pdf) From wwwrun@core3.amsl.com Wed Mar 9 07:38:19 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A8D163A6866; Wed, 9 Mar 2011 07:38:19 -0800 (PST) From: Greg Jones(ITU-T SG 15) To: rcallon@juniper.net,swallow@cisco.com,loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110309153819.A8D163A6866@core3.amsl.com> Date: Wed, 9 Mar 2011 07:38:19 -0800 (PST) Cc: Huub.van.Helvoort@huawei.com, mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, Steve.Trowbridge@alcatel-lucent.com, yoichi.maeda@ttc.or.jp, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, stbryant@cisco.com Subject: [mpls] Updated Liaison Statement, "LS295 - Reply to the IETF MPLS working group last call on "A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks (ref #051.01)" (ref #051.02)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 15:38:19 -0000 Title: LS295 - Reply to the IETF MPLS working group last call on "A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks (ref #051.01)" (ref #051.02) Submission Date: 2011-03-09 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1030 Please reply by 2011-06-01 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(rcallon@juniper.net,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp Steve.Trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: Huub.van.Helvoort@huawei.com Purpose: For comment Body: Thank you for your liaison statement (Ref # 051.01) requesting a review by the ITU-T of the draft "A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks". Please note that in the past weeks the Q10/15 experts have been very busy preparing for the ITU-T SG15 plenary meeting and attending this meeting in Geneva 14-25 February 2011. Considering the limited amount of time, the Q10/15 experts may send more comments at a later date. We request that you address the comments and provide us a new version of draft-ietf-mpls-tp-loss-delay-profile. Q10/15 would like to have an opportunity to review the next version of this draft before approval. Attachment(s): LS295 - Reply to the IETF MPLS working group last call on "A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks (ref #051.01)" (ref #051.02) - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1204.pdf) From rcallon@juniper.net Wed Mar 9 11:50:55 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E0543A6A77 for ; Wed, 9 Mar 2011 11:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 e4wlQMB7yomj for ; Wed, 9 Mar 2011 11:50:53 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 278603A6969 for ; Wed, 9 Mar 2011 11:50:53 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTXfaXheHwtH5gJSm7YkRRHsyfMfUocOL@postini.com; Wed, 09 Mar 2011 11:52:10 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 9 Mar 2011 11:40:50 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 9 Mar 2011 14:41:46 -0500 From: Ross Callon To: "mpls@ietf.org" Date: Wed, 9 Mar 2011 14:41:45 -0500 Thread-Topic: MPLS WG Last call on draft-ietf-mpls-loss-delay-01 Thread-Index: AcvGd7puTQVnojA3ThmPPWkMXUN/MgYGhxdQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704A9F11524A6EMBX01WFjnprn_" MIME-Version: 1.0 Subject: Re: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 19:50:55 -0000 --_000_DF7F294AF4153D498141CBEFADB17704A9F11524A6EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The WG last call on draft-ietf-mpls-loss-delay-01 has now ended. Thanks to all for the many useful comments received. Ross, Loa, and George MPLS WG co-chairs From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Sunday, February 06, 2011 10:33 PM To: mpls@ietf.org Subject: [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-01 Working Group, This is to start a four week working group last call on " Packet Loss and Delay Measurement for MPLS Networks" (draft-ietf-mpls-loss-delay-01). Please send comments to the mpls@ietf.org mailing list. Also, please note that the related document " draft-ietf-mpls-tp-loss-delay-profile-02.txt" is being last called in parallel on the mpls-tp email list (mpls-tp@ietf.org). This working group last call ends on Monday March 7, 2011. Ross, Loa, and George MPLS WG co-chairs --_000_DF7F294AF4153D498141CBEFADB17704A9F11524A6EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The WG la= st call on draft-ietf-mpls-loss-delay-01 has now ended.

 

Thanks to all for the many useful comments received. =

 

Ross, Loa, and George

MPLS WG co-chairs

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ro= ss Callon
Sent: Sunday, February 06, 2011 10:33 PM
To: = mpls@ietf.org
Subject: [mpls] MPLS WG Last call on draft-ietf-mpl= s-loss-delay-01

=  

Working Group,

 

T= his is to start a four week working group last call on

" Packet Loss and Delay Measurement for MPLS= Networks"

(draft-ietf-m= pls-loss-delay-01).

 

Please send comments to the mpl= s@ietf.org mailing list.

&nbs= p;

Also, please note that the= related document

" dra= ft-ietf-mpls-tp-loss-delay-profile-02.txt" is being last called in

parallel on the mpls-tp email l= ist (mpls-tp@ietf.org).

&nbs= p;

This working group last ca= ll ends on Monday March 7, 2011.

 

Ross, Loa, and G= eorge

 

MPLS WG co-chairs

=

 

&nb= sp;

= --_000_DF7F294AF4153D498141CBEFADB17704A9F11524A6EMBX01WFjnprn_-- From rcallon@juniper.net Wed Mar 9 11:52:10 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19B2C3A69AA; Wed, 9 Mar 2011 11:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 CvYMVPQiBzgK; Wed, 9 Mar 2011 11:52:08 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id B83EE3A6967; Wed, 9 Mar 2011 11:52:07 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTXfaqnvJQLgcmrH8vikzDgjmGIdgOZm9@postini.com; Wed, 09 Mar 2011 11:53:24 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 9 Mar 2011 11:49:16 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 9 Mar 2011 14:50:12 -0500 From: Ross Callon To: "mpls-tp@ietf.org" , "mpls@ietf.org" , "ahmpls-tp@lists.itu.int" Date: Wed, 9 Mar 2011 14:50:10 -0500 Thread-Topic: [mpls-tp] MPLS WG last call on draft-ietf-mpls-tp-loss-delay-profile-02 Thread-Index: AcvDrJhCOwxbl7gbTh6wLaZt8CCDPACx1e2wBgfCsRA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] [mpls-tp] MPLS WG last call on draft-ietf-mpls-tp-loss-delay-profile-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 19:52:10 -0000 The WG last call on draft-ietf-mpls-tp-loss-delay-profile-02 has now ended. Thanks to all for the useful comments received.=20 Ross, Loa, and George MPLS WG co-chairs -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Ross Callon Sent: Sunday, February 06, 2011 10:33 PM To: mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int Subject: [mpls-tp] MPLS WG last call on draft-ietf-mpls-tp-loss-delay-profi= le-02 Working Group, This is to start a four week working group last call on "A Packet Loss and Delay Measurement Profile for MPLS-based=20 Transport Networks" (draft-ietf-mpls-tp-loss-delay-profile-02.txt). Please send comments to the mpls-tp@ietf.org mailing list. Also, please note that the related document=20 "draft-ietf-mpls-loss-delay-01" is being last called in=20 parallel on the MPLS WG email list.=20 This working group last call ends on Monday March 7, 2011. Ross, Loa, and George MPLS WG co-chairs _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From rcallon@juniper.net Wed Mar 9 13:54:38 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E99763A6778 for ; Wed, 9 Mar 2011 13:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 MIuAbSbeB+5y for ; Wed, 9 Mar 2011 13:54:38 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 0A9BB3A6407 for ; Wed, 9 Mar 2011 13:54:37 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTXf3ag24Mjp92zVyd5D99nuoy3o0vDp/@postini.com; Wed, 09 Mar 2011 13:55:55 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 9 Mar 2011 13:42:20 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 9 Mar 2011 16:43:14 -0500 From: Ross Callon To: "mpls@ietf.org" Date: Wed, 9 Mar 2011 16:43:13 -0500 Thread-Topic: mpls wg last call on draft-ietf-mpls-ldp-p2mp Thread-Index: AcvDrJhCOwxbl7gbTh6wLaZt8CCDPAUkW1CwAAAOGjABmRK/gA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] mpls wg last call on draft-ietf-mpls-ldp-p2mp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:54:39 -0000 OOps. The most recent version is -12. Thus the last call is on: "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths" (draft-ietf-mpls-ldp-p2mp-12). Just in case anyone was confused by this error, we will extend the last cal= l to March 23, 2011.=20 Thanks, Ross -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Tuesday, March 01, 2011 9:27 PM To: mpls@ietf.org Subject: [mpls] mpls wg last call on draft-ietf-mpls-ldp-p2mp-11 Working Group, This is to start a two week working group last call on "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths" (draft-ietf-mpls-ldp-p2mp-11). Please send comments to the mpls@ietf.org mailing list. This working group last call ends on March 16, 2011.=20 Ross, George, and Loa MPLS WG co-chairs _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From ping@pingpan.org Thu Mar 10 08:19:16 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED80C3A68A9; Thu, 10 Mar 2011 08:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ZwG2GFyHxd8J; Thu, 10 Mar 2011 08:19:15 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with SMTP id 4DDE83A68C1; Thu, 10 Mar 2011 08:19:15 -0800 (PST) Received: from source ([209.85.216.177]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTXj6UK0/pLf3Z3dthJWc1ExfH93azjNK@postini.com; Thu, 10 Mar 2011 08:20:33 PST Received: by qyl38 with SMTP id 38so1501053qyl.8 for ; Thu, 10 Mar 2011 08:20:28 -0800 (PST) Received: by 10.52.95.175 with SMTP id dl15mr11773663vdb.69.1299774028154; Thu, 10 Mar 2011 08:20:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.165.197 with HTTP; Thu, 10 Mar 2011 08:19:57 -0800 (PST) In-Reply-To: <20110308020004.17578.69780.idtracker@localhost> References: <20110308020004.17578.69780.idtracker@localhost> From: Ping Pan Date: Thu, 10 Mar 2011 08:19:57 -0800 Message-ID: To: mpls@ietf.org, ccamp@ietf.org Content-Type: multipart/alternative; boundary=20cf307f307c3c865c049e233902 Cc: Rajan Rao Subject: [mpls] Fwd: I-D ACTION:draft-pan-shared-mesh-protection-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 16:19:17 -0000 --20cf307f307c3c865c049e233902 Content-Type: text/plain; charset=ISO-8859-1 Hi, Shared Mesh Protection has the benefit of optimizing network resources in transport networks. However, activating the protection has always been a challenge. MPLS-TP has outlined the requirements and framework. Here is a proposal that we have put together to solve the performance issue in shared meshed networks. Given its simplicity (actually it's designed for embedded data-plane), this can achieve rapid traffic recovery and switch-over. The performance goal is to recover traffic in million seconds for end-to-end transport tunnels. We are still working on details. Look forward to hear your feedback. Best regards, Ping ---------- Forwarded message ---------- From: Date: Mon, Mar 7, 2011 at 6:00 PM Subject: I-D ACTION:draft-pan-shared-mesh-protection-00.txt To: i-d-announce@ietf.org A new Internet-Draft is available from the on-line Internet-Drafts directories. Title : Supporting Shared Mesh Protection in MPLS-TP Networks Author(s) : R. Rao, et al Filename : draft-pan-shared-mesh-protection-00.txt Pages : 15 Date : 2011-03-07 Shared mesh protection is a common protection and recovery mechanism in transport networks, where multiple paths can share the same set of network resources for protection purposes. In the context of MPLS-TP, it has been explicitly requested as a part of the overall solution (Req. 67, 68 and 69 in RFC5654 [1]). It's important to note that each MPLS-TP LSP may be associated with transport network resources. In event of network failure, it may require explicit activation on the protecting paths before switching user traffic over. In this memo, we define a lightweight signaling mechanism for protecting path activation in shared mesh protection-enabled MPLS-TP networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pan-shared-mesh-protection-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --20cf307f307c3c865c049e233902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Shared Mesh Protection has the benefit of optimizing= network resources in transport networks. However, activating the protectio= n has always been a challenge.

MPLS-TP has outline= d the requirements and framework. Here is a proposal that we have put toget= her to solve the performance issue in shared meshed networks.

Given its simplicity (actually it's designed for em= bedded data-plane), this can achieve rapid traffic recovery and switch-over= . The performance goal is to recover traffic in million seconds for end-to-= end transport tunnels.

We are still working on details. Look forward to hear y= our feedback.

Best regards,

Ping



-------= --- Forwarded message ----------
From: <Internet-Drafts@ietf.org>
= Date: Mon, Mar 7, 2011 at 6:00 PM
Subject: I-D ACTION:draft-pan-shared-m= esh-protection-00.txt
To: i-d-announce@ietf.org
<= br>
A new Internet-Draft is available from the on-line Internet-Drafts d= irectories.


=A0 =A0Title =A0 =A0 =A0 =A0 : Supporting Shared Mesh Protection in MPLS-T= P Networks
=A0 =A0Author(s) =A0 =A0 : R. Rao, et al
=A0 =A0Filename =A0 =A0 =A0: draft-pan-shared-mesh-protection-00.txt
=A0 =A0Pages =A0 =A0 =A0 =A0 : 15
=A0 =A0Date =A0 =A0 =A0 =A0 =A0: 2011-03-07

Shared mesh protection is a common protection and recovery mechanism
=A0 =A0 =A0 =A0in transport networks, where multiple paths can share the s= ame set
=A0 =A0 =A0 =A0of network resources for protection purposes.

=A0 =A0 =A0 =A0In the context of MPLS-TP, it has been explicitly requested= as a
=A0 =A0 =A0 =A0part of the overall solution (Req. 67, 68 and 69 in RFC5654= [1]).

=A0 =A0 =A0 =A0It's important to note that each MPLS-TP LSP may be ass= ociated with
=A0 =A0 =A0 =A0transport network resources. In event of network failure, i= t may
=A0 =A0 =A0 =A0require explicit activation on the protecting paths before = switching
=A0 =A0 =A0 =A0user traffic over.

=A0 =A0 =A0 =A0In this memo, we define a lightweight signaling mechanism f= or
=A0 =A0 =A0 =A0protecting path activation in shared mesh protection-enable= d MPLS-TP
=A0 =A0 =A0 =A0networks.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pa= n-shared-mesh-protection-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--20cf307f307c3c865c049e233902-- From ping@pingpan.org Thu Mar 10 11:17:47 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014903A6A56; Thu, 10 Mar 2011 11:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 MMpBue8LtyKf; Thu, 10 Mar 2011 11:17:45 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with SMTP id 50D583A6806; Thu, 10 Mar 2011 11:17:45 -0800 (PST) Received: from source ([209.85.216.51]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTXkkJ8ftTVVlPJvJk8/3PgxtG0ahuiAt@postini.com; Thu, 10 Mar 2011 11:19:04 PST Received: by qwb8 with SMTP id 8so1582718qwb.38 for ; Thu, 10 Mar 2011 11:19:02 -0800 (PST) Received: by 10.52.65.52 with SMTP id u20mr473262vds.309.1299784742277; Thu, 10 Mar 2011 11:19:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.165.197 with HTTP; Thu, 10 Mar 2011 11:18:32 -0800 (PST) In-Reply-To: References: <20110308020004.17578.69780.idtracker@localhost> From: Ping Pan Date: Thu, 10 Mar 2011 11:18:32 -0800 Message-ID: To: mpls@ietf.org, ccamp@ietf.org Content-Type: multipart/alternative; boundary=bcaec50166a5d91440049e25b770 Subject: Re: [mpls] I-D ACTION:draft-pan-shared-mesh-protection-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 19:17:47 -0000 --bcaec50166a5d91440049e25b770 Content-Type: text/plain; charset=ISO-8859-1 Correction: the goal is to recover in milliseconds. Did not mean to use US Postal Service or Pony Express for protecting path activation. ;-) Ping On Thu, Mar 10, 2011 at 8:19 AM, Ping Pan wrote: > Hi, > > Shared Mesh Protection has the benefit of optimizing network resources in > transport networks. However, activating the protection has always been a > challenge. > > MPLS-TP has outlined the requirements and framework. Here is a proposal > that we have put together to solve the performance issue in shared meshed > networks. > > Given its simplicity (actually it's designed for embedded data-plane), this > can achieve rapid traffic recovery and switch-over. The performance goal > is to recover traffic in million seconds for end-to-end transport tunnels. > > We are still working on details. Look forward to hear your feedback. > > Best regards, > > Ping > > > > ---------- Forwarded message ---------- > From: > Date: Mon, Mar 7, 2011 at 6:00 PM > Subject: I-D ACTION:draft-pan-shared-mesh-protection-00.txt > To: i-d-announce@ietf.org > > > A new Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Supporting Shared Mesh Protection in MPLS-TP Networks > Author(s) : R. Rao, et al > Filename : draft-pan-shared-mesh-protection-00.txt > Pages : 15 > Date : 2011-03-07 > > Shared mesh protection is a common protection and recovery mechanism > in transport networks, where multiple paths can share the same set > of network resources for protection purposes. > > In the context of MPLS-TP, it has been explicitly requested as a > part of the overall solution (Req. 67, 68 and 69 in RFC5654 [1]). > > It's important to note that each MPLS-TP LSP may be associated with > transport network resources. In event of network failure, it may > require explicit activation on the protecting paths before switching > user traffic over. > > In this memo, we define a lightweight signaling mechanism for > protecting path activation in shared mesh protection-enabled MPLS-TP > networks. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-pan-shared-mesh-protection-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draftdirectories: > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > --bcaec50166a5d91440049e25b770 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Correction: the goal is to recover in milliseconds.=A0

Did not= mean to use US Postal Service or Pony Express for protecting path activati= on. ;-)

Ping

On = Thu, Mar 10, 2011 at 8:19 AM, Ping Pan <ping@pingpan.org> wrote:
Hi,

Shared Mesh Protecti= on has the benefit of optimizing network resources in transport networks. H= owever, activating the protection has always been a challenge.

MPLS-TP has outlined the requirements and framework. He= re is a proposal that we have put together to solve the performance issue i= n shared meshed networks.

Given its simplicity (actually it's designed for em= bedded data-plane), this can achieve rapid traffic recovery and switch-over= . The performance goal is to recover traffic in million seconds for en= d-to-end transport tunnels.

We are still working on details. Look forward to hear y= our feedback.

Best regards,

Ping



A new Inte= rnet-Draft is available from the on-line Internet-Drafts directories.


=A0 =A0Title =A0 =A0 =A0 =A0 : Supporting Shared Mesh Protection in MPLS-T= P Networks
=A0 =A0Author(s) =A0 =A0 : R. Rao, et al
=A0 =A0Filename =A0 =A0 =A0: draft-pan-shared-mesh-protection-00.txt
=A0 =A0Pages =A0 =A0 =A0 =A0 : 15
=A0 =A0Date =A0 =A0 =A0 =A0 =A0: 2011-03-07

Shared mesh protection is a common protection and recovery mechanism
=A0 =A0 =A0 =A0in transport networks, where multiple paths can share the s= ame set
=A0 =A0 =A0 =A0of network resources for protection purposes.

=A0 =A0 =A0 =A0In the context of MPLS-TP, it has been explicitly requested= as a
=A0 =A0 =A0 =A0part of the overall solution (Req. 67, 68 and 69 in RFC5654= [1]).

=A0 =A0 =A0 =A0It's important to note that each MPLS-TP LSP may be ass= ociated with
=A0 =A0 =A0 =A0transport network resources. In event of network failure, i= t may
=A0 =A0 =A0 =A0require explicit activation on the protecting paths before = switching
=A0 =A0 =A0 =A0user traffic over.

=A0 =A0 =A0 =A0In this memo, we define a lightweight signaling mechanism f= or
=A0 =A0 =A0 =A0protecting path activation in shared mesh protection-enable= d MPLS-TP
=A0 =A0 =A0 =A0networks.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pa= n-shared-mesh-protection-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_____________________________________= __________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/li= stinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt



--bcaec50166a5d91440049e25b770-- From stbryant@cisco.com Thu Mar 10 13:25:16 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D435E3A6A7F for ; Thu, 10 Mar 2011 13:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.344 X-Spam-Level: X-Spam-Status: No, score=-108.344 tagged_above=-999 required=5 tests=[AWL=-1.984, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, RCVD_IN_DNSWL_HI=-8, TVD_SPACE_RATIO=2.219, 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 d7r4bNTfu2cC for ; Thu, 10 Mar 2011 13:25:15 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 396E33A6A7D for ; Thu, 10 Mar 2011 13:25:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=140; q=dns/txt; s=iport; t=1299792394; x=1301001994; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=kPVQ7AsOALfSPyiLCjgqHQJcGmEUlWohaJg5B/xElI0=; b=lpbOYke3FLfe6/JslAzI6vqyezUfP9jtb534xok+D5U1A45YnGBvt5C1 v5MU7GOKP0CtvObmPKyEgf5t4eXWRV2T2t3EUEduVwLuq3lOQvfqtU4UR FVw5iDDli7ABzWRNKp+FoA/vRTkCqKSgfNdgYgh/2NR1zRMOxkp2J2pl4 4=; X-IronPort-AV: E=Sophos;i="4.62,298,1297036800"; d="scan'208";a="78661887" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 10 Mar 2011 21:26:33 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2ALQSR9011254; Thu, 10 Mar 2011 21:26:32 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p2ALQLs14681; Thu, 10 Mar 2011 21:26:21 GMT Message-ID: <4D7941FD.5000700@cisco.com> Date: Thu, 10 Mar 2011 21:26:21 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: draft-kini-mpls-frr-ldp@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , Mike Shand Subject: [mpls] draft-kini-mpls-frr-ldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:25:16 -0000 Authors How does draft-kini-mpls-frr-ldp differ from http://tools.ietf.org/html/draft-shen-mpls-ldp-nnhop-label-02 Thanks Stewart From RCosta@ptinovacao.pt Thu Mar 10 19:30:59 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856EB3A6B64 for ; Thu, 10 Mar 2011 19:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 CTJsJHxQWZU4 for ; Thu, 10 Mar 2011 19:30:58 -0800 (PST) Received: from owa.ptinovacao.pt (mail6.ptinovacao.pt [194.65.138.99]) by core3.amsl.com (Postfix) with ESMTP id 6ACB13A67EC for ; Thu, 10 Mar 2011 19:30:58 -0800 (PST) Received: from INOAVREX11.ptin.corpPT.com ([10.112.15.121]) by inoavrcas01.ptin.corpPT.com ([10.112.15.99]) with mapi; Fri, 11 Mar 2011 03:32:13 +0000 From: Rui Costa To: "mpls@ietf.org" Date: Fri, 11 Mar 2011 03:32:10 +0000 Thread-Topic: draft-tsb-mpls-tp-ach-ptn Thread-Index: AcvfnOeVV3ZPtvhwS+WvdnOPEqon7Q== Message-ID: <52981DB05D3C5247A12D0AEE309F3CC201EB24B1CBBC@INOAVREX11.ptin.corpPT.com> Accept-Language: pt-PT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: pt-PT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] draft-tsb-mpls-tp-ach-ptn X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 03:30:59 -0000 Hello,=09 The draft provided by the TSB draft-tsb-mpls-tp-ach-ptn requests the alloca= tion of an Associated Channel Type value that will allow ITU-T to develop O= AM tools required to address the needs identified by some ITU-T members. Al= location of this value will make more efficient use of resources of both IE= TF and ITU-T. The use of this associated channel type fully complies with t= he framework and architecture for MPLS-TP.=09 The draft also describes the cases where networks that run the ITU defined = OAM tools are interconnected to networks that run the IETF defined OAM tool= s. In most cases it is a client/server relationship and no interworking is = required. If a LSP or PW originates in one domain and terminates in the oth= er domain then the IETF OAM tools must be used.=09 This draft should be discussed in Prague.=09 Best Regards,=09 Rui From Alexander.Vainshtein@ecitele.com Thu Mar 10 23:13:54 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E65A3A68F7; Thu, 10 Mar 2011 23:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 8IbEh7DiIlSK; Thu, 10 Mar 2011 23:13:49 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 52BD03A68C7; Thu, 10 Mar 2011 23:13:47 -0800 (PST) X-AuditID: 93eaf2e7-b7c1dae000001449-90-4d79cbef525a Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 13.33.05193.FEBC97D4; Fri, 11 Mar 2011 09:14:56 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Fri, 11 Mar 2011 09:15:04 +0200 From: Alexander Vainshtein To: "tnadeau@lucidvision.com" , "lmartini@cisco.com" Date: Fri, 11 Mar 2011 09:15:03 +0200 Thread-Topic: A brief comment on draft-nadeau-pwe3-vccv-2-01.txt Thread-Index: AQHL37wKa5PIJp6q3Emc88eiA340sQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAB1ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , Andrew Sergeev , Robert, Idan Kaspit , Mishael Wexler , "pwe3@ietf.org" , Rennison , Rotem Cohen Subject: [mpls] A brief comment on draft-nadeau-pwe3-vccv-2-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 07:13:54 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAB1ILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tom, Luca and all, I've read the draft. The draft defines a new VCCV type for PWs that do not use the CW. VCCV packets for this type look like following (copy and paste from the dra= ft): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Associated Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ VCCV Message Body ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The draft further says that "The PW Label must set the TTL field to 1. In the case of multi-segment pseudo-wires, the PW Label TTL MUST be set to the correct value to reach the intended destination PE as described in [RFC6073]". The proposed format seems to stretch to the limit the somewhat vague waiver= in RFC 5586 (highlighted in the quoted text): In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. Where the GAL is at the bottom of the label stack (i.e., S bit set to 1), then it MUST always be followed by an ACH. This format also seems to contradict draft-ietf-pwe3-mpls-tp-gal-in-pw (and= , IMHO, makes it completely unnecessary). Please note that: 1. The function of GAL in this case seems to be limited to forwarding the= packet to a control entity at the tail-end of the tunnel. 2. RFC 5586 does not define how the packets with GAL exposed are forwarde= d (if at all) if GAL is exposed but is not at the bottom of the label stack= . Hence my comments: 1. The draft must explicitly define how the packets with the GAL exposed = in the Label Stack are forwarded (similar to what has been done for the Rou= ter Alert label in RFC 3032), and must state that it updates RFC 5586 in th= is regard. Without such a change, VCCV Type 4 would not be applicable MS-PW= s. 2. The ACH type for static PW status messages (as defined in draft-ietf-p= we3-static-pw-status) should be added to the explicit lists of ACH types su= pported with the new VCCV type. Such a list appears in Section 3 of the dra= ft. Alternatively, explicit specification of allowed ACH types could be rem= oved from the draft. Regards, Sasha --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAB1ILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Tom, Luca and all,
I've read the draft.


The draft defines a new VCCV type for PWs that do not use the CW.
VCCV packets for this type look like following (copy and paste from the dra= ft):

0            &n= bsp;      1      &nb= sp;            2&nbs= p;            &= nbsp;     3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
|            &n= bsp;            = ;     GAL       &nbs= p;            &= nbsp;         |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
|            &n= bsp;            = ;   PW Label         = ;            &n= bsp;     |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
|0 0 0 1|Version|   Reserved    |  Associated= Channel Type      |
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
|            &n= bsp;            = ;            &n= bsp;            = ;             |=
~            &n= bsp;           VCCV Messa= ge Body           &n= bsp;          ~
|            &n= bsp;            = ;            &n= bsp;            = ;             |=
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+

 

The draft further says that "The PW Labe= l must set the TTL field to 1.

In the case of multi-segment pseudo-wires, th= e PW Label TTL MUST be set

to the correct value to reach the intended de= stination PE as described
in [RFC6073]".

The proposed = format seems to stretch to the limit the somewhat vague waiver in RFC 5586 = (highlighted in the quoted text):

<quote>

   In MP= LS-TP, the GAL MUST be used with packets on a G-ACh on LSPs,<= br>    Concatenated Segments of LSPs, and with Sections, and MUST NOT= be
   used with PWs.  It MUST always be at the bottom of the la= bel stack
   (i.e., S bit set to 1).  However, in other MPLS environments, this
   document places no restrictions on where the GAL may appear wi= thin
   the label stack or its use with PWs.  Where the GA= L is at the bottom
   of the label stack (i.e., S bit set to 1), then it MUST always= be
   followed by an ACH.
<end quote>

&nbs= p;

This format also seems to contradict draft-ie= tf-pwe3-mpls-tp-gal-in-pw (and, IMHO, makes it completely unnecessary).

 

Please note that:

  1. The function of G= AL in this case seems to be limited to forwarding the packet to a control e= ntity at the tail-end of the tunnel.
  2. Hence my comments:

    1. The draft must explicitly define how the packets with the GAL exposed i= n the Label Stack are forwarded (similar to what has been done for the Rout= er Alert label in RFC 3032), and must state that it updates RFC 5586 in thi= s regard. Without such a change, VCCV Type 4 would not be applicable MS-PWs.
    2. The ACH type for static PW status messages (as defined in draft-ietf-= pwe3-static-pw-status) should be added to the explicit lists of ACH types s= upported with the new VCCV type. Such a list appears in Section 3 of the dr= aft. Alternatively, explicit specification of allowed ACH types could be removed f= rom the draft.

    Regards,

         Sasha

     

     

     

     

    --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAB1ILPTMAIL02eci_-- From neil.2.harrison@bt.com Thu Mar 10 23:38:16 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 480403A6BB0 for ; Thu, 10 Mar 2011 23:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=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 pfOzuDPXhgSm for ; Thu, 10 Mar 2011 23:38:14 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by core3.amsl.com (Postfix) with ESMTP id 8CC863A6BAE for ; Thu, 10 Mar 2011 23:38:14 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 11 Mar 2011 07:39:31 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.4]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Fri, 11 Mar 2011 07:39:32 +0000 From: To: , Date: Fri, 11 Mar 2011 07:39:28 +0000 Thread-Topic: draft-tsb-mpls-tp-ach-ptn Thread-Index: AcvfnOeVV3ZPtvhwS+WvdnOPEqon7QAH8Hew Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E44017BF6AEA@EMV62-UKRD.domain1.systemhost.net> References: <52981DB05D3C5247A12D0AEE309F3CC201EB24B1CBBC@INOAVREX11.ptin.corpPT.com> In-Reply-To: <52981DB05D3C5247A12D0AEE309F3CC201EB24B1CBBC@INOAVREX11.ptin.corpPT.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 07:38:16 -0000 Hi Rui, A couple of observations: - you are correct to say that a client/server relationship is the key one, = because any layer network mode/technology that is not TOS (Top-Of-Stack), a= nd thus does not directly support external message/file/stream applications= , MUST always have at least one higher layer network above it that is a tru= e TOS layer network (a true TOS layer is present in all networking cases). = It therefore trivially follows that any peer interworking of non-TOS layer= networks (whether they are the same or different mode/technology) is an un= necessary exercise....one can simply terminate the non-TOS layer networks a= t an interworking point and pass the client layer network transparently. =20 - when we have client/server nesting of co-ps mode layer networks that use = exactly the same traffic units (noting one can have the same or different f= unctional semantics of fields and components in the client and server layer= network cases, eg same/different addressing for forwarding, same/different= OAM, same/different routing process, etc) then one should consider both in= tra-layer and inter-layer misconnectivity. =20 regards, Neil Neil Harrison BT Design Email: neil.2.harrison@bt.com Web: www.bt.com This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rui Costa > Sent: 11 March 2011 03:32 > To: mpls@ietf.org > Subject: [mpls] draft-tsb-mpls-tp-ach-ptn >=20 > Hello, >=20 > The draft provided by the TSB draft-tsb-mpls-tp-ach-ptn requests the > allocation of an Associated Channel Type value that will allow ITU-T to > develop OAM tools required to address the needs identified by some ITU- > T members. Allocation of this value will make more efficient use of > resources of both IETF and ITU-T. The use of this associated channel > type fully complies with the framework and architecture for MPLS-TP. >=20 >=20 > The draft also describes the cases where networks that run the ITU > defined OAM tools are interconnected to networks that run the IETF > defined OAM tools. In most cases it is a client/server relationship and > no interworking is required. If a LSP or PW originates in one domain > and terminates in the other domain then the IETF OAM tools must be > used. >=20 > This draft should be discussed in Prague. >=20 > Best Regards, > Rui >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From lmartini@cisco.com Fri Mar 11 05:37:04 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 764153A6BE8; Fri, 11 Mar 2011 05:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 wLUKklh89MY5; Fri, 11 Mar 2011 05:37:03 -0800 (PST) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by core3.amsl.com (Postfix) with ESMTP id 13A103A69AE; Fri, 11 Mar 2011 05:37:03 -0800 (PST) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id p2BDVbhM014634 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2011 06:31:38 -0700 (MST) Message-ID: <4D7A2439.6010508@cisco.com> Date: Fri, 11 Mar 2011 06:31:37 -0700 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: Greg Mirsky References: <4D5E9442.3030101@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lihan@chinamobile.com, mpls@ietf.org, pwe3 , HUANG Feng F , mpls-tp@ietf.org Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 13:37:04 -0000 Greg , Some On 02/18/11 11:15, Greg Mirsky wrote: > Dear Luca, > I see at least two issues: > > * use of GAL for PW, in my view, is another VCCV CC type that has > to be negotiated as described in RFC 5085. > These are valid points, but this document in question does not define, not discussed VCCV. We have since posted a draft that proposes a new VCCV mode , and we welcome comments regarding that document. (draft-nadeau-pwe3-vccv-2-01.txt) > * use of GAL creates ambiguous situation when PW CW is used. The > benefit from extending GAL in PW, as I see, is for PWs that are > not required to use PW CW. That might be a good enough reason to > update RFC 5586 as proposed in the document but we must address > use cases of GAL in PWs that require presence PW CW. If we > prohibit or even discourage use of GAL for these PWs that have > PW VCCV as native Associated Channel, then architecture of ACh > for MPLS-TP PW not simplified as result of adopting the proposal. > > Regard Greg, The GAL is basically a notifier that the packet following the end of the MPLS label stack, is explicitly defined as a G-ACH format. Normally the packet would be decoded as an IP packet , unless the last label on the stack indicated otherwise. The GAL can certainly be applied to a PW OAM packet on a PW that uses the CW, and this document does not define that , nor restricts it. The scope of this document is limited to removing an unnecessary restriction in rfc5586, hence this comment not applicable to this document. Thanks. Luca > s, > Greg > > On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini > wrote: > > Greg, > > Sorry, but I do not remember the point you mention. > Can you explain again here ? > Thanks. > Luca > > > On 02/17/11 23:47, Greg Mirsky wrote: > > Dear Authors and All, > > prior to the meeting in Bejing and acceptance of this proposal as WG > > document Luca and I agreed that use of GAL with PW VCCV presents a > > problem. > > I was not attending the IETF-79, nor I found discussion of this > issue > > in the minutes. I think that this issue should be specified, > > explained. In my view, this document updates not only RFC 5586 > > but RFC 5085 too. > > > > Regards, > > Greg > > > > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > > > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > > > >> wrote: > > > > Greg, > > > > You are correct , the proposed update does not propose any > changes > > to VCCV. > > However the problem with vccv is not as simple as to ask for > a new > > code point from IANA. > > Given the good amount of discussion on this point, we should > > probably have a discussion in Beijing. > > > > Luca > > > > > > > > On 10/29/2010 05:07 PM, Greg Mirsky wrote: > >> Dear Authors, > >> I think that proposed update of the Section 4.2. RFC 5586 > makes it possible > >> to use GAL on MPLS-TP PW that uses Control Word. I consider > it to be > >> conflict between PW VCCV CC types because use of GAL is not > negotiated > >> through PW VCCV negotiation. To avoid such situation I propose: > >> > >> - in Section 5 request IANA to assign new CC Type "MPLS > Generic > >> Associated Channel Label" > >> - assign precedence to new CC Type that affects Section > 7 RFC 5085 > >> > >> Regards, > >> Greg > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > From gregimirsky@gmail.com Fri Mar 11 11:13:08 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438603A6867; Fri, 11 Mar 2011 11:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 G1G5tZuHkifu; Fri, 11 Mar 2011 11:13:07 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 808143A692A; Fri, 11 Mar 2011 11:13:06 -0800 (PST) Received: by vxg33 with SMTP id 33so3436782vxg.31 for ; Fri, 11 Mar 2011 11:14:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hGvMLrqnfDT5Md1LdED+ehD8g+nQWAU3R3U/eBsRAcs=; b=GdG4thn6MIrO/mPJX1qjVlh6rNDi5CGVW9g12aQfnvIukUeyEUDv8iXCyeRShbPN3g C8nutqTdt9YCQS/Vu7boh3ZVaRqyeREOeEFHKJSw6AJTbckzdSWzzusxaQHlCWdRu4WP 3xUmKdIodPGXO6GYCtsPt1cKrCjf/LKiclgk8= 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=pJh0kPAvixjbHbsmiMwq5URY9OlMIi5TdLUX2zLYa4WhHo/R/bFz98ifeKo1VaKkD3 Ii5JbmgLBMlOK3XNWgdGC8Y2sM4Pas/+hBgJPTZdYKn0bXiKSATdUE+GBp+6DMbKZGsn CR+IHdU9YC2XlhMBueJ3eNHqnML8SSdSor5bE= MIME-Version: 1.0 Received: by 10.52.159.3 with SMTP id wy3mr14155643vdb.289.1299870865619; Fri, 11 Mar 2011 11:14:25 -0800 (PST) Received: by 10.52.169.35 with HTTP; Fri, 11 Mar 2011 11:14:25 -0800 (PST) In-Reply-To: <4D7A2439.6010508@cisco.com> References: <4D5E9442.3030101@cisco.com> <4D7A2439.6010508@cisco.com> Date: Fri, 11 Mar 2011 11:14:25 -0800 Message-ID: From: Greg Mirsky To: Luca Martini Content-Type: multipart/alternative; boundary=bcaec53f97973306bd049e39c525 Cc: lihan@chinamobile.com, mpls@ietf.org, pwe3 , HUANG Feng F , mpls-tp@ietf.org Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 19:13:08 -0000 --bcaec53f97973306bd049e39c525 Content-Type: text/plain; charset=ISO-8859-1 Dear Luca, thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my attention. I'll send my comments to it in a separate e-mail. I'll have to miss another opportunity to discuss your proposal in a meeting. Please add my comments below to my earlier expressed WG LC comments: - the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution that addresses applicability of GAL in PW VCCV, e.g. solution proposed in draft-nadeau-pwe3-vccv-2-01; - the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs to mention such dependency and refer to any existing proposal; - I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be advanced in lock with document that addresses use of GAL in PW VCCV. Regards, Greg On Fri, Mar 11, 2011 at 5:31 AM, Luca Martini wrote: > Greg , > Some > > On 02/18/11 11:15, Greg Mirsky wrote: > > Dear Luca, > > I see at least two issues: > > > > * use of GAL for PW, in my view, is another VCCV CC type that has > > to be negotiated as described in RFC 5085. > > > These are valid points, but this document in question does not define, > not discussed VCCV. > We have since posted a draft that proposes a new VCCV mode , and we > welcome comments regarding that document. > (draft-nadeau-pwe3-vccv-2-01.txt) > > > * use of GAL creates ambiguous situation when PW CW is used. The > > benefit from extending GAL in PW, as I see, is for PWs that are > > not required to use PW CW. That might be a good enough reason to > > update RFC 5586 as proposed in the document but we must address > > use cases of GAL in PWs that require presence PW CW. If we > > prohibit or even discourage use of GAL for these PWs that have > > PW VCCV as native Associated Channel, then architecture of ACh > > for MPLS-TP PW not simplified as result of adopting the proposal. > > > > Regard > Greg, > The GAL is basically a notifier that the packet following the end of the > MPLS label stack, is explicitly defined as a G-ACH format. > Normally the packet would be decoded as an IP packet , unless the last > label on the stack indicated otherwise. > > The GAL can certainly be applied to a PW OAM packet on a PW that uses > the CW, and this document does not define that , nor restricts it. > > The scope of this document is limited to removing an unnecessary > restriction in rfc5586, hence this comment not applicable to this > document. > > Thanks. > Luca > > > s, > > Greg > > > > On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini > > wrote: > > > > Greg, > > > > Sorry, but I do not remember the point you mention. > > Can you explain again here ? > > Thanks. > > Luca > > > > > > On 02/17/11 23:47, Greg Mirsky wrote: > > > Dear Authors and All, > > > prior to the meeting in Bejing and acceptance of this proposal as > WG > > > document Luca and I agreed that use of GAL with PW VCCV presents a > > > problem. > > > I was not attending the IETF-79, nor I found discussion of this > > issue > > > in the minutes. I think that this issue should be specified, > > > explained. In my view, this document updates not only RFC 5586 > > > but RFC 5085 too. > > > > > > Regards, > > > Greg > > > > > > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > > > > > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > > > > > >> wrote: > > > > > > Greg, > > > > > > You are correct , the proposed update does not propose any > > changes > > > to VCCV. > > > However the problem with vccv is not as simple as to ask for > > a new > > > code point from IANA. > > > Given the good amount of discussion on this point, we should > > > probably have a discussion in Beijing. > > > > > > Luca > > > > > > > > > > > > On 10/29/2010 05:07 PM, Greg Mirsky wrote: > > >> Dear Authors, > > >> I think that proposed update of the Section 4.2. RFC 5586 > > makes it possible > > >> to use GAL on MPLS-TP PW that uses Control Word. I consider > > it to be > > >> conflict between PW VCCV CC types because use of GAL is not > > negotiated > > >> through PW VCCV negotiation. To avoid such situation I > propose: > > >> > > >> - in Section 5 request IANA to assign new CC Type "MPLS > > Generic > > >> Associated Channel Label" > > >> - assign precedence to new CC Type that affects Section > > 7 RFC 5085 > > >> > > >> Regards, > > >> Greg > > >> > > >> > > >> > > >> _______________________________________________ > > >> mpls mailing list > > >> mpls@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > --bcaec53f97973306bd049e39c525 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Luca,
    thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my atte= ntion. I'll send my comments to it in a separate e-mail.
    I'll ha= ve to miss another opportunity to discuss your proposal in a meeting. Pleas= e add my comments below to my earlier expressed WG LC comments:
    • the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution that= addresses applicability of GAL in PW VCCV, e.g. solution proposed in draft= -nadeau-pwe3-vccv-2-01;
    • the draft-lm-pwe3-mpls-tp-gal-in-pw-00 need= s to mention such dependency and refer to any existing proposal;
    • I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be advanced i= n lock with document that addresses use of GAL in PW VCCV.
    Regards= ,
    Greg

    On Fri, Mar 11, 2011 at 5:31 AM= , Luca Martini <= lmartini@cisco.com> wrote:
    Greg ,
    Some

    On 02/18/11 11:15, Greg Mirsky wrote:
    > Dear Luca,
    > I see at least two issues:
    >
    > =A0 =A0 * use of GAL for PW, in my view, is another VCCV CC type that = has
    > =A0 =A0 =A0 to be negotiated as described in RFC 5085.
    >
    These are valid points, but this document in question does not define= ,
    not discussed VCCV.
    We have since posted a draft that proposes a new VCCV mode , and we
    welcome comments regarding that document.
    (draft-nadeau-pwe3-vccv-2-01.txt)

    > =A0 =A0 * use of GAL creates ambiguous situation when PW CW is used. T= he
    > =A0 =A0 =A0 benefit from extending GAL in PW, as I s= ee, is for PWs that are
    > =A0 =A0 =A0 not required to use PW CW. That might be a good enough rea= son to
    > =A0 =A0 =A0 update RFC 5586 as proposed in the document but we must ad= dress
    > =A0 =A0 =A0 use cases of GAL in PWs that require presence PW CW. If we=
    > =A0 =A0 =A0 prohibit or even discourage use of GAL for these PWs that = have
    > =A0 =A0 =A0 PW VCCV as native Associated Channel, then architecture of= ACh
    > =A0 =A0 =A0 for MPLS-TP PW not simplified as result of adopting the pr= oposal.
    >
    > Regard
    Greg,
    The GAL is basically a notifier that the packet following the end of the MPLS label stack, is explicitly defined as a G-ACH format.
    Normally the packet would be decoded as an IP packet , unless the last
    label on the stack indicated otherwise.

    The GAL can certainly be applied =A0to a PW OAM packet on a PW that uses the CW, and this document does not define that , nor restricts it.

    The scope of this document is limited to removing an unnecessary
    restriction in rfc5586, hence =A0this comment not applicable to this docume= nt.

    Thanks.
    Luca

    > s,
    > Greg
    >
    > On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini <lmartini@cisco.com
    > <mailto:lmartini@cisco.com>> wrote:
    >
    > =A0 =A0 Greg,
    >
    > =A0 =A0 Sorry, but I do not remember the point you mention.
    > =A0 =A0 Can you explain again here ?
    > =A0 =A0 Thanks.
    > =A0 =A0 Luca
    >
    >
    > =A0 =A0 On 02/17/11 23:47, Greg Mirsky wrote:
    > =A0 =A0 > Dear Authors and All,
    > =A0 =A0 > prior to the meeting in Bejing and acceptance of this pro= posal as WG
    > =A0 =A0 > document Luca and I agreed that use of GAL with PW VCCV p= resents a
    > =A0 =A0 > problem.
    > =A0 =A0 > I was not attending the IETF-79, nor I found discussion o= f this
    > =A0 =A0 issue
    > =A0 =A0 > in the minutes. I think that this issue should be specifi= ed,
    > =A0 =A0 > explained. In my view, this document updates not only RFC= 5586
    > =A0 =A0 > but RFC 5085 too.
    > =A0 =A0 >
    > =A0 =A0 > Regards,
    > =A0 =A0 > Greg
    > =A0 =A0 >
    > =A0 =A0 > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt
    > =A0 =A0 >
    > =A0 =A0 > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini
    > =A0 =A0 <lmartini@cisco.com <mailto:lmartini@cisco.com&= gt;
    > =A0 =A0 > <mailto:lmartini@cisco.com <mailto:lmartini@cisco.com>>> wrote: > =A0 =A0 >
    > =A0 =A0 > =A0 =A0 Greg,
    > =A0 =A0 >
    > =A0 =A0 > =A0 =A0 You are correct , the proposed update does not pr= opose any
    > =A0 =A0 changes
    > =A0 =A0 > =A0 =A0 to VCCV.
    > =A0 =A0 > =A0 =A0 However the problem with vccv is not as simple as= to ask for
    > =A0 =A0 a new
    > =A0 =A0 > =A0 =A0 code point from IANA.
    > =A0 =A0 > =A0 =A0 Given the good amount of discussion on this point= , we should
    > =A0 =A0 > =A0 =A0 probably have a discussion in Beijing.
    > =A0 =A0 >
    > =A0 =A0 > =A0 =A0 Luca
    > =A0 =A0 >
    > =A0 =A0 >
    > =A0 =A0 >
    > =A0 =A0 > =A0 =A0 On 10/29/2010 05:07 PM, Greg Mirsky wrote:
    > =A0 =A0 >> =A0 =A0 Dear Authors,
    > =A0 =A0 >> =A0 =A0 I think that proposed update of the Section 4= .2. RFC 5586
    > =A0 =A0 makes it possible
    > =A0 =A0 >> =A0 =A0 to use GAL on MPLS-TP PW that uses Control Wo= rd. I consider
    > =A0 =A0 it to be
    > =A0 =A0 >> =A0 =A0 conflict between PW VCCV CC types because use= of GAL is not
    > =A0 =A0 negotiated
    > =A0 =A0 >> =A0 =A0 through PW VCCV negotiation. To avoid such si= tuation I propose:
    > =A0 =A0 >>
    > =A0 =A0 >> =A0 =A0 =A0 =A0- in Section 5 request IANA to assign = new CC Type "MPLS
    > =A0 =A0 Generic
    > =A0 =A0 >> =A0 =A0 =A0 =A0Associated Channel Label"
    > =A0 =A0 >> =A0 =A0 =A0 =A0- assign precedence to new CC Type tha= t affects Section
    > =A0 =A0 7 RFC 5085
    > =A0 =A0 >>
    > =A0 =A0 >> =A0 =A0 Regards,
    > =A0 =A0 >> =A0 =A0 Greg
    > =A0 =A0 >>
    > =A0 =A0 >>
    > =A0 =A0 >>
    > =A0 =A0 >> =A0 =A0 _____________________________________________= __
    > =A0 =A0 >> =A0 =A0 mpls mailing list
    > =A0 =A0 >> =A0 =A0 = mpls@ietf.org <mailto:mpls@ietf.org= > <mailto:mpls@ietf.org
    > =A0 =A0 <mailto:mpls@ietf.org>>
    > =A0 =A0 >> =A0 =A0 https://www.ietf.org/mailman/listinfo/mpls<= br> > =A0 =A0 >
    > =A0 =A0 >
    > =A0 =A0 >
    > =A0 =A0 > _______________________________________________
    > =A0 =A0 > mpls mailing list
    > =A0 =A0 > mpls@ietf.org <ma= ilto:mpls@ietf.org>
    > =A0 =A0 > https://www.ietf.org/mailman/listinfo/mpls
    >
    >



    --bcaec53f97973306bd049e39c525-- From Alexander.Vainshtein@ecitele.com Fri Mar 11 11:20:46 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 275B23A6C7A; Fri, 11 Mar 2011 11:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 9N6N97j9WH5O; Fri, 11 Mar 2011 11:20:36 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 8D7473A698D; Fri, 11 Mar 2011 11:20:34 -0800 (PST) X-AuditID: 93eaf2e7-b7c1dae000001449-47-4d7a7648cc71 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 96.2E.05193.8467A7D4; Fri, 11 Mar 2011 21:21:44 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Fri, 11 Mar 2011 21:21:52 +0200 From: Alexander Vainshtein To: Greg Mirsky , Luca Martini Date: Fri, 11 Mar 2011 21:21:49 +0200 Thread-Topic: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Thread-Index: AcvgIJCjINO9d7bvQ8uZXoqo8NcncgAAI1aw Message-ID: References: <4D5E9442.3030101@cisco.com> <4D7A2439.6010508@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76D6FBBDD332ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "lihan@chinamobile.com" , "mpls-tp@ietf.org" , pwe3 , HUANG Feng F , "mpls@ietf.org" Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 19:20:46 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D6FBBDD332ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, Luca, As I've already stated in my comment on draft-nadeau-pwe3-vccv-2, IMHO it m= akes draft-lm-pwe3-mpls-tp-gal-in-pw completely useless. My 2c, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gre= g Mirsky Sent: Friday, March 11, 2011 9:14 PM To: Luca Martini Cc: lihan@chinamobile.com; mpls@ietf.org; pwe3; HUANG Feng F; mpls-tp@ietf.= org Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Dear Luca, thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my attention. I'll se= nd my comments to it in a separate e-mail. I'll have to miss another opportunity to discuss your proposal in a meeting= . Please add my comments below to my earlier expressed WG LC comments: * the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution that ad= dresses applicability of GAL in PW VCCV, e.g. solution proposed in draft-na= deau-pwe3-vccv-2-01; * the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs to mention such dependenc= y and refer to any existing proposal; * I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be advanced = in lock with document that addresses use of GAL in PW VCCV. Regards, Greg On Fri, Mar 11, 2011 at 5:31 AM, Luca Martini > wrote: Greg , Some On 02/18/11 11:15, Greg Mirsky wrote: > Dear Luca, > I see at least two issues: > > * use of GAL for PW, in my view, is another VCCV CC type that has > to be negotiated as described in RFC 5085. > These are valid points, but this document in question does not define, not discussed VCCV. We have since posted a draft that proposes a new VCCV mode , and we welcome comments regarding that document. (draft-nadeau-pwe3-vccv-2-01.txt) > * use of GAL creates ambiguous situation when PW CW is used. The > benefit from extending GAL in PW, as I see, is for PWs that are > not required to use PW CW. That might be a good enough reason to > update RFC 5586 as proposed in the document but we must address > use cases of GAL in PWs that require presence PW CW. If we > prohibit or even discourage use of GAL for these PWs that have > PW VCCV as native Associated Channel, then architecture of ACh > for MPLS-TP PW not simplified as result of adopting the proposal. > > Regard Greg, The GAL is basically a notifier that the packet following the end of the MPLS label stack, is explicitly defined as a G-ACH format. Normally the packet would be decoded as an IP packet , unless the last label on the stack indicated otherwise. The GAL can certainly be applied to a PW OAM packet on a PW that uses the CW, and this document does not define that , nor restricts it. The scope of this document is limited to removing an unnecessary restriction in rfc5586, hence this comment not applicable to this document= . Thanks. Luca > s, > Greg > > On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini > >> wrote: > > Greg, > > Sorry, but I do not remember the point you mention. > Can you explain again here ? > Thanks. > Luca > > > On 02/17/11 23:47, Greg Mirsky wrote: > > Dear Authors and All, > > prior to the meeting in Bejing and acceptance of this proposal as W= G > > document Luca and I agreed that use of GAL with PW VCCV presents a > > problem. > > I was not attending the IETF-79, nor I found discussion of this > issue > > in the minutes. I think that this issue should be specified, > > explained. In my view, this document updates not only RFC 5586 > > but RFC 5085 too. > > > > Regards, > > Greg > > > > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > > > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > > > > >>> wrote: > > > > Greg, > > > > You are correct , the proposed update does not propose any > changes > > to VCCV. > > However the problem with vccv is not as simple as to ask for > a new > > code point from IANA. > > Given the good amount of discussion on this point, we should > > probably have a discussion in Beijing. > > > > Luca > > > > > > > > On 10/29/2010 05:07 PM, Greg Mirsky wrote: > >> Dear Authors, > >> I think that proposed update of the Section 4.2. RFC 5586 > makes it possible > >> to use GAL on MPLS-TP PW that uses Control Word. I consider > it to be > >> conflict between PW VCCV CC types because use of GAL is not > negotiated > >> through PW VCCV negotiation. To avoid such situation I propose= : > >> > >> - in Section 5 request IANA to assign new CC Type "MPLS > Generic > >> Associated Channel Label" > >> - assign precedence to new CC Type that affects Section > 7 RFC 5085 > >> > >> Regards, > >> Greg > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > > >> > >> https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > --_000_A3C5DF08D38B6049839A6F553B331C76D6FBBDD332ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Greg, Luc= a,

    As I’ve already s= tated in my comment on draft-nadeau-pwe3-vccv-2, IMHO it makes draft-lm-pwe= 3-mpls-tp-gal-in-pw completely useless.

     

    My 2= c,

        = ; Sasha

     <= /span>

    From: mpls-bounces@ietf.= org [mailto:mpls-bounces@ietf.org] On Behalf Of Greg Mirsky
    Se= nt: Friday, March 11, 2011 9:14 PM
    To: Luca Martini
    Cc:= lihan@chinamobile.com; mpls@ietf.org; pwe3; HUANG Feng F; mpls-tp@ietf= .org
    Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00= .txt

     

    Dear Luca,
    thank you for bringing draft-nadeau= -pwe3-vccv-2-01 to my attention. I'll send my comments to it in a separate = e-mail.
    I'll have to miss another opportunity to discuss your proposal i= n a meeting. Please add my comments below to my earlier expressed WG LC com= ments:

    • the dr= aft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution that addresses app= licability of GAL in PW VCCV, e.g. solution proposed in draft-nadeau-pwe3-v= ccv-2-01;
    • the draft-lm-pwe3-= mpls-tp-gal-in-pw-00 needs to mention such dependency and refer to any exis= ting proposal;
    • I believe tha= t the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be advanced in lock with docum= ent that addresses use of GAL in PW VCCV.

    Regards,
    Greg

    =

    On Fri, Mar 11, 2011 at 5:31 AM, Luca Martini <lmartini@cisco.com> wrote:

    Greg ,
    Some


    On 02/18/11 11:15, Greg Mirsky wrote:
    > Dear Luca,
    >= ; I see at least two issues:
    >
    >     * use of GAL for= PW, in my view, is another VCCV CC type that has
    >     &nb= sp; to be negotiated as described in RFC 5085.
    >

    =

    These are valid points, but this document in question = does not define,
    not discussed VCCV.
    We have since posted a draft tha= t proposes a new VCCV mode , and we
    welcome comments regarding that docu= ment.
    (draft-nadeau-pwe3-vccv-2-01.txt)

    >     * use = of GAL creates ambiguous situation when PW CW is used. The

    >       benefit from extending GA= L in PW, as I see, is for PWs that are
    >       not req= uired to use PW CW. That might be a good enough reason to
    >   &n= bsp;   update RFC 5586 as proposed in the document but we must address=
    >       use cases of GAL in PWs that require presence= PW CW. If we
    >       prohibit or even discourage use = of GAL for these PWs that have
    >       PW VCCV as nati= ve Associated Channel, then architecture of ACh
    >      = ; for MPLS-TP PW not simplified as result of adopting the proposal.
    >=
    > Regard

    Greg,
    The GAL i= s basically a notifier that the packet following the end of the
    MPLS lab= el stack, is explicitly defined as a G-ACH format.
    Normally the packet w= ould be decoded as an IP packet , unless the last
    label on the stack ind= icated otherwise.

    The GAL can certainly be applied  to a PW OAM= packet on a PW that uses
    the CW, and this document does not define that= , nor restricts it.

    The scope of this document is limited to removi= ng an unnecessary
    restriction in rfc5586, hence  this comment not a= pplicable to this document.

    Thanks.
    Luca


    > s,
    > Greg
    >
    > On Fri, Feb 18, 20= 11 at 7:46 AM, Luca Martini <lmart= ini@cisco.com

    > <ma= ilto:lmartini@cisco.com>> w= rote:
    >
    >     Greg,
    >
    >     Sor= ry, but I do not remember the point you mention.
    >     Can = you explain again here ?
    >     Thanks.
    >    = ; Luca
    >
    >
    >     On 02/17/11 23:47, Greg Mirsky= wrote:
    >     > Dear Authors and All,
    >   &nb= sp; > prior to the meeting in Bejing and acceptance of this proposal as = WG
    >     > document Luca and I agreed that use of GAL wi= th PW VCCV presents a
    >     > problem.
    >   &n= bsp; > I was not attending the IETF-79, nor I found discussion of this>     issue
    >     > in the minutes. I thi= nk that this issue should be specified,
    >     > explaine= d. In my view, this document updates not only RFC 5586
    >    = ; > but RFC 5085 too.
    >     >
    >     &= gt; Regards,
    >     > Greg
    >     >
    = >     > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt>     >
    >     > On Sat, Oct 30, 2010 a= t 10:14 AM, Luca Martini
    >     <lmartini@cisco.com <mailto:lmartini@cisco.com>

    >     > <mailto:lmartini@cisco.com <mailto:lmartini@cisco.com>>> wrote:
    >     &g= t;
    >     >     Greg,
    >     >= ;
    >     >     You are correct , the proposed u= pdate does not propose any
    >     changes
    >   &nb= sp; >     to VCCV.
    >     >     Ho= wever the problem with vccv is not as simple as to ask for
    >   &= nbsp; a new
    >     >     code point from IANA.<= br>>     >     Given the good amount of discussio= n on this point, we should
    >     >     probabl= y have a discussion in Beijing.
    >     >
    >   &= nbsp; >     Luca
    >     >
    >   &nb= sp; >
    >     >
    >     >    = ; On 10/29/2010 05:07 PM, Greg Mirsky wrote:
    >     >>=     Dear Authors,
    >     >>     I= think that proposed update of the Section 4.2. RFC 5586
    >   &nb= sp; makes it possible
    >     >>     to use G= AL on MPLS-TP PW that uses Control Word. I consider
    >     i= t to be
    >     >>     conflict between PW VC= CV CC types because use of GAL is not
    >     negotiated
    &= gt;     >>     through PW VCCV negotiation. To av= oid such situation I propose:
    >     >>
    >  =   >>        - in Section 5 request IANA to = assign new CC Type "MPLS
    >     Generic
    >   =   >>        Associated Channel Label">     >>        - assign precedenc= e to new CC Type that affects Section
    >     7 RFC 5085
    &= gt;     >>
    >     >>     Reg= ards,
    >     >>     Greg
    >   &nbs= p; >>
    >     >>
    >     >>>     >>     _______________________________= ________________
    >     >>     mpls mailing = list

    >     >= >     mpls@ietf.org <m= ailto:mpls@ietf.org> <mailto:mpls@ietf.org

     

    <= /div>= --_000_A3C5DF08D38B6049839A6F553B331C76D6FBBDD332ILPTMAIL02eci_-- From venkatflex@gmail.com Fri Mar 11 12:11:39 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10CBC3A6A63; Fri, 11 Mar 2011 12:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 AclshglcZ15n; Fri, 11 Mar 2011 12:11:33 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 7669C3A6A13; Fri, 11 Mar 2011 12:11:32 -0800 (PST) Received: by qyk29 with SMTP id 29so5768229qyk.10 for ; Fri, 11 Mar 2011 12:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Fn42uvlStrWIca7gwqedlwhWSf5nw5TZ4X0jBYl4qPA=; b=Yw8UrmjTYbuem3csujknmwiIn6ic+lGsgUTn6iR48xJ/pXIjTgCAaG/NtWTz39uCBf udJlIjhl49x3KV2jeB923WM/gPIJX5+s6KSbHQTY4YTae+xgsz7waoKBHI8IdpXrsaNb dHelOXYzL8F3mAJZ18SMWXOfhsxhKyT/5Vq5E= 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 :content-type; b=xxUAL3zQ4AneBCNUFb70uPymMLhDVmkO7uD/MLgbw5nqzcTAGCQ34W1Po0fA1Q2Cl1 9+BX+4XxhXL9nMkmjcP6OUDoW/qQYLejbsQnVo4nV3WJNFfQV1jxCq/7995Pmi1onjvw kb56q6CZ4ECktM1jeEUyZJK0MUOqB2hemo8Tk= MIME-Version: 1.0 Received: by 10.224.213.193 with SMTP id gx1mr5574898qab.44.1299874371694; Fri, 11 Mar 2011 12:12:51 -0800 (PST) Received: by 10.224.20.71 with HTTP; Fri, 11 Mar 2011 12:12:51 -0800 (PST) In-Reply-To: References: <4D5E9442.3030101@cisco.com> <4D7A2439.6010508@cisco.com> Date: Fri, 11 Mar 2011 15:12:51 -0500 Message-ID: From: venkatesan mahalingam To: Alexander Vainshtein , Greg Mirsky , Luca Martini , "lihan@chinamobile.com" , "mpls-tp@ietf.org" , pwe3 , HUANG Feng F , "mpls@ietf.org" Content-Type: multipart/alternative; boundary=20cf3005dccc2d70e2049e3a9686 Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 20:11:40 -0000 --20cf3005dccc2d70e2049e3a9686 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, AFAIK, ACH can't be used without supporting the CW in HW. As per RFC-5085, 5.1.1. In-Band VCCV (Type 1) CC Type-1 mode of VCCV operation MUST be supported when the control word is present. Are we implicitly mandating the CW (ACH) in HW by configuring/negotiating the CC type-4? It looks to me that CC type-1 for ACH without GAL and CC type-4 for ACH wit= h GAL. IMO, if we support CC type-4, CC type-1 support is implicitly attained. IMHO, it should be possible to get the MPLS-TP OAM control packets with or without GAL from HW to CP by negotiating CC type-1 itself. Some editorial comments for the draft-nadeau-pwe3-vccv-2-01.txt draft, " 4.1.1. MPLS VCCV Control Channel (CC) Type 4 IANA is requested to augment the registry of "MPLS VCCV Control Channel Types" with the new type defined below. As defined in RFC5058, this new bitfield is to be assigned by IANA using " Replace the RFC5058 as RFC5085. Thanks, Venkat. On Fri, Mar 11, 2011 at 2:21 PM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Greg, Luca, > > As I=92ve already stated in my comment on draft-nadeau-pwe3-vccv-2, IMHO = it > makes draft-lm-pwe3-mpls-tp-gal-in-pw completely useless. > > > > My 2c, > > Sasha > > > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf O= f > *Greg Mirsky > *Sent:* Friday, March 11, 2011 9:14 PM > *To:* Luca Martini > *Cc:* lihan@chinamobile.com; mpls@ietf.org; pwe3; HUANG Feng F; > mpls-tp@ietf.org > *Subject:* Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > > > Dear Luca, > thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my attention. I'll > send my comments to it in a separate e-mail. > I'll have to miss another opportunity to discuss your proposal in a > meeting. Please add my comments below to my earlier expressed WG LC > comments: > > - the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution that > addresses applicability of GAL in PW VCCV, e.g. solution proposed in > draft-nadeau-pwe3-vccv-2-01; > - the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs to mention such > dependency and refer to any existing proposal; > - I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be advance= d > in lock with document that addresses use of GAL in PW VCCV. > > Regards, > Greg > > On Fri, Mar 11, 2011 at 5:31 AM, Luca Martini wrote: > > Greg , > Some > > > On 02/18/11 11:15, Greg Mirsky wrote: > > Dear Luca, > > I see at least two issues: > > > > * use of GAL for PW, in my view, is another VCCV CC type that has > > to be negotiated as described in RFC 5085. > > > > These are valid points, but this document in question does not define, > not discussed VCCV. > We have since posted a draft that proposes a new VCCV mode , and we > welcome comments regarding that document. > (draft-nadeau-pwe3-vccv-2-01.txt) > > > * use of GAL creates ambiguous situation when PW CW is used. The > > > benefit from extending GAL in PW, as I see, is for PWs that are > > not required to use PW CW. That might be a good enough reason to > > update RFC 5586 as proposed in the document but we must address > > use cases of GAL in PWs that require presence PW CW. If we > > prohibit or even discourage use of GAL for these PWs that have > > PW VCCV as native Associated Channel, then architecture of ACh > > for MPLS-TP PW not simplified as result of adopting the proposal. > > > > Regard > > Greg, > The GAL is basically a notifier that the packet following the end of the > MPLS label stack, is explicitly defined as a G-ACH format. > Normally the packet would be decoded as an IP packet , unless the last > label on the stack indicated otherwise. > > The GAL can certainly be applied to a PW OAM packet on a PW that uses > the CW, and this document does not define that , nor restricts it. > > The scope of this document is limited to removing an unnecessary > restriction in rfc5586, hence this comment not applicable to this > document. > > Thanks. > Luca > > > > s, > > Greg > > > > On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini > > > wrote: > > > > Greg, > > > > Sorry, but I do not remember the point you mention. > > Can you explain again here ? > > Thanks. > > Luca > > > > > > On 02/17/11 23:47, Greg Mirsky wrote: > > > Dear Authors and All, > > > prior to the meeting in Bejing and acceptance of this proposal as > WG > > > document Luca and I agreed that use of GAL with PW VCCV presents = a > > > problem. > > > I was not attending the IETF-79, nor I found discussion of this > > issue > > > in the minutes. I think that this issue should be specified, > > > explained. In my view, this document updates not only RFC 5586 > > > but RFC 5085 too. > > > > > > Regards, > > > Greg > > > > > > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > > > > > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > > > > > > >> wrote: > > > > > > Greg, > > > > > > You are correct , the proposed update does not propose any > > changes > > > to VCCV. > > > However the problem with vccv is not as simple as to ask for > > a new > > > code point from IANA. > > > Given the good amount of discussion on this point, we should > > > probably have a discussion in Beijing. > > > > > > Luca > > > > > > > > > > > > On 10/29/2010 05:07 PM, Greg Mirsky wrote: > > >> Dear Authors, > > >> I think that proposed update of the Section 4.2. RFC 5586 > > makes it possible > > >> to use GAL on MPLS-TP PW that uses Control Word. I consider > > it to be > > >> conflict between PW VCCV CC types because use of GAL is not > > negotiated > > >> through PW VCCV negotiation. To avoid such situation I > propose: > > >> > > >> - in Section 5 request IANA to assign new CC Type "MPLS > > Generic > > >> Associated Channel Label" > > >> - assign precedence to new CC Type that affects Section > > 7 RFC 5085 > > >> > > >> Regards, > > >> Greg > > >> > > >> > > >> > > >> _______________________________________________ > > >> mpls mailing list > > > >> mpls@ietf.org > > > > > >> https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --=20 Best Regards, Venkatesan Mahalingam. --20cf3005dccc2d70e2049e3a9686 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,
    AFAIK, ACH can't be used without supporting the CW in HW.<= /div>

    As per RFC-5085, 5.1.1. =A0In-Band VCCV (Type 1)
    CC Type-1 mode of VCCV operation MUST be supported when the contro= l word is present.

    Are we implicitly mandating the CW (ACH) in HW by confi= guring/negotiating the CC type-4?
    It looks to me that CC type-1 f= or ACH without GAL and CC type-4 for ACH with GAL.

    IMO, if we support CC type-4, CC type-1 support is implicitly attained= .

    IMHO, it should be possible to get the MPLS-TP O= AM control packets with or without GAL from HW to CP by negotiating CC type= -1 itself.

    Some editorial comments for the draft-nadeau-pwe3-= vccv-2-01.txt draft,
    "
    4.1.1. =A0MPLS VCCV Control= Channel (CC) Type 4

    =A0=A0 IANA is requested to a= ugment the registry of "MPLS VCCV Control
    =A0=A0 Channel Types" with the new type defined below. As defined= in
    =A0=A0 RFC5058, this new bitfield is to be assigned by IANA u= sing
    "
    Replace the RFC5058 as RFC5085.
    =

    Thanks,
    Venkat.

    On Fri, Mar 11, 2011 at 2:21 PM, Alexander Vainshtein &= lt;Alexander.Vainshtein= @ecitele.com> wrote:

    Greg, Luca,

    As I= =92ve already stated in my comment on draft-nadeau-pwe3-vccv-2, IMHO it mak= es draft-lm-pwe3-mpls-tp-gal-in-pw completely useless.

    =A0

    My 2c,

    =A0=A0= =A0=A0 Sasha

    =A0

    From:= mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf= Of Greg Mirsky
    Sent: Friday, March 11, 2011 9:14 PM
    To: Luca Martini
    <= b>Cc: lihan@= chinamobile.com; mpl= s@ietf.org; pwe3; HUANG Feng F; mpls-tp@ietf.org
    Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

    =A0

    Dear Luca,
    thank you for bringing draft-n= adeau-pwe3-vccv-2-01 to my attention. I'll send my comments to it in a = separate e-mail.
    I'll have to miss another opportunity to discuss your proposal in a mee= ting. Please add my comments below to my earlier expressed WG LC comments:<= /p>

    • the draft-lm-pwe3-mpls-tp-gal-= in-pw-00 depends on any solution that addresses applicability of GAL in PW = VCCV, e.g. solution proposed in draft-nadeau-pwe3-vccv-2-01;
    • the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs to men= tion such dependency and refer to any existing proposal;
    • I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be adva= nced in lock with document that addresses use of GAL in PW VCCV.

    Regards,
    Greg=

    On Fri, Mar 11, 2011 at 5:31 AM, Luca Marti= ni <lmartini@cis= co.com> wrote:

    Greg ,
    Some


    On= 02/18/11 11:15, Greg Mirsky wrote:
    > Dear Luca,
    > I see at lea= st two issues:
    >
    > =A0 =A0 * use of GAL for PW, in my view, is = another VCCV CC type that has
    > =A0 =A0 =A0 to be negotiated as described in RFC 5085.
    >

    These are valid points, but this document in quest= ion does not define,
    not discussed VCCV.
    We have since posted a draft= that proposes a new VCCV mode , and we
    welcome comments regarding that document.
    (draft-nadeau-pwe3-vccv-2-01.t= xt)

    > =A0 =A0 * use of GAL creates ambiguous situation when PW CW= is used. The

    > =A0 =A0 =A0 benefit from = extending GAL in PW, as I see, is for PWs that are
    > =A0 =A0 =A0 not required to use PW CW. That might be a good enough rea= son to
    > =A0 =A0 =A0 update RFC 5586 as proposed in the document but = we must address
    > =A0 =A0 =A0 use cases of GAL in PWs that require pr= esence PW CW. If we
    > =A0 =A0 =A0 prohibit or even discourage use of GAL for these PWs that = have
    > =A0 =A0 =A0 PW VCCV as native Associated Channel, then archite= cture of ACh
    > =A0 =A0 =A0 for MPLS-TP PW not simplified as result of= adopting the proposal.
    >
    > Regard

    Greg,
    The GAL is bas= ically a notifier that the packet following the end of the
    MPLS label st= ack, is explicitly defined as a G-ACH format.
    Normally the packet would = be decoded as an IP packet , unless the last
    label on the stack indicated otherwise.

    The GAL can certainly be app= lied =A0to a PW OAM packet on a PW that uses
    the CW, and this document d= oes not define that , nor restricts it.

    The scope of this document i= s limited to removing an unnecessary
    restriction in rfc5586, hence =A0this comment not applicable to this docume= nt.

    Thanks.
    Luca


    > s,
    &g= t; Greg
    >
    > On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini <<= a href=3D"mailto:lmartini@cisco.com" target=3D"_blank">lmartini@cisco.com

    > <mailto:lmartini@cisco.com>> wrote:
    >= ;
    > =A0 =A0 Greg,
    >
    > =A0 =A0 Sorry, but I do not remembe= r the point you mention.
    > =A0 =A0 Can you explain again here ?
    > =A0 =A0 Thanks.
    > = =A0 =A0 Luca
    >
    >
    > =A0 =A0 On 02/17/11 23:47, Greg Mirsky= wrote:
    > =A0 =A0 > Dear Authors and All,
    > =A0 =A0 > pri= or to the meeting in Bejing and acceptance of this proposal as WG
    > =A0 =A0 > document Luca and I agreed that use of GAL with PW VCCV p= resents a
    > =A0 =A0 > problem.
    > =A0 =A0 > I was not atte= nding the IETF-79, nor I found discussion of this
    > =A0 =A0 issue
    = > =A0 =A0 > in the minutes. I think that this issue should be specifi= ed,
    > =A0 =A0 > explained. In my view, this document updates not only RFC= 5586
    > =A0 =A0 > but RFC 5085 too.
    > =A0 =A0 >
    > = =A0 =A0 > Regards,
    > =A0 =A0 > Greg
    > =A0 =A0 >
    >= ; =A0 =A0 > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt
    > =A0 =A0 >
    > =A0 =A0 > On Sat, Oct 30, 2010 at 10:14 AM, Lu= ca Martini
    > =A0 =A0 <lmartini@cisco.com <mailto:lmartini@cisco.com>

    > =A0 =A0 > <mailto:lmartini@cisco.com <= ;mailto:lmartini@ci= sco.com>>> wrote:
    > =A0 =A0 >
    > =A0 =A0 > =A0 =A0 Greg,
    > =A0 =A0 >> =A0 =A0 > =A0 =A0 You are correct , the proposed update does not = propose any
    > =A0 =A0 changes
    > =A0 =A0 > =A0 =A0 to VCCV.> =A0 =A0 > =A0 =A0 However the problem with vccv is not as simple = as to ask for
    > =A0 =A0 a new
    > =A0 =A0 > =A0 =A0 code point from IANA.
    &g= t; =A0 =A0 > =A0 =A0 Given the good amount of discussion on this point, = we should
    > =A0 =A0 > =A0 =A0 probably have a discussion in Beijin= g.
    > =A0 =A0 >
    > =A0 =A0 > =A0 =A0 Luca
    > =A0 =A0 >
    > =A0 =A0 >
    > =A0 =A0 >
    > =A0 =A0= > =A0 =A0 On 10/29/2010 05:07 PM, Greg Mirsky wrote:
    > =A0 =A0 &g= t;> =A0 =A0 Dear Authors,
    > =A0 =A0 >> =A0 =A0 I think that = proposed update of the Section 4.2. RFC 5586
    > =A0 =A0 makes it possible
    > =A0 =A0 >> =A0 =A0 to use GAL = on MPLS-TP PW that uses Control Word. I consider
    > =A0 =A0 it to be> =A0 =A0 >> =A0 =A0 conflict between PW VCCV CC types because u= se of GAL is not
    > =A0 =A0 negotiated
    > =A0 =A0 >> =A0 =A0 through PW VCCV ne= gotiation. To avoid such situation I propose:
    > =A0 =A0 >>
    &= gt; =A0 =A0 >> =A0 =A0 =A0 =A0- in Section 5 request IANA to assign n= ew CC Type "MPLS
    > =A0 =A0 Generic
    > =A0 =A0 >> =A0 =A0 =A0 =A0Associated Cha= nnel Label"
    > =A0 =A0 >> =A0 =A0 =A0 =A0- assign precedenc= e to new CC Type that affects Section
    > =A0 =A0 7 RFC 5085
    > = =A0 =A0 >>
    > =A0 =A0 >> =A0 =A0 Regards,
    > =A0 =A0 >> =A0 =A0 Greg
    > =A0 =A0 >>
    > =A0 =A0= >>
    > =A0 =A0 >>
    > =A0 =A0 >> =A0 =A0 _______= ________________________________________
    > =A0 =A0 >> =A0 =A0 m= pls mailing list

    > =A0 =A0 >> =A0 =A0 mpls@ietf.org <mailto:mpls@ietf.org> <mailto:mpls@ietf.org

    > =A0 = =A0 <mailto:mpls@ietf= .org>>
    > =A0 =A0 >> =A0 =A0 https://www.ietf.org/mailma= n/listinfo/mpls
    > =A0 =A0 >
    > =A0 =A0 >
    > =A0 =A0 >
    > =A0 =A0= > _______________________________________________
    > =A0 =A0 > = mpls mailing list
    > =A0 =A0 > mpls@ietf.org <mailto:mpls@ietf.org>
    > =A0 =A0 > https://www.ietf.org/mailman/listinfo/mpls
    >
    &= gt;

    =A0

    =

    _______________________________________________
    mpls mailing list
    mpls@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/mpls




    --
    Best Regards,
    Ve= nkatesan Mahalingam.
    --20cf3005dccc2d70e2049e3a9686-- From tnadeau@lucidvision.com Fri Mar 11 12:57:09 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5913A6941; Fri, 11 Mar 2011 12:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 VyhIxur3WG+h; Fri, 11 Mar 2011 12:57:07 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 05FD73A6962; Fri, 11 Mar 2011 12:57:05 -0800 (PST) Received: from [192.168.1.133] (unknown [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id E6C261A68122; Fri, 11 Mar 2011 15:58:22 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-5--552644677 From: Thomas Nadeau In-Reply-To: Date: Fri, 11 Mar 2011 15:58:22 -0500 Message-Id: <88290F42-76E9-4403-87F6-9F5BEDA7D59F@lucidvision.com> References: <4D5E9442.3030101@cisco.com> <4D7A2439.6010508@cisco.com> To: venkatesan mahalingam X-Mailer: Apple Mail (2.1082) Cc: Alexander Vainshtein , "mpls@ietf.org" , "mpls-tp@ietf.org" , "lihan@chinamobile.com" , pwe3 , HUANG Feng F Subject: Re: [mpls] [PWE3] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 20:57:09 -0000 --Apple-Mail-5--552644677 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Hi, > AFAIK, ACH can't be used without supporting the CW in HW. >=20 > As per RFC-5085, 5.1.1. In-Band VCCV (Type 1) > CC Type-1 mode of VCCV operation MUST be supported when the control = word is present. >=20 > Are we implicitly mandating the CW (ACH) in HW by = configuring/negotiating the CC type-4? > It looks to me that CC type-1 for ACH without GAL and CC type-4 for = ACH with GAL. The IETF's protocols do not mandate how they are to be = implemented per se (i.e.: in HW or not). The draft addresses the operational concerns of = configuration/complexity=20 by having 1 mode for each of the major operational scenarios: with or = without the CW. > IMO, if we support CC type-4, CC type-1 support is implicitly = attained. >=20 > IMHO, it should be possible to get the MPLS-TP OAM control packets = with or without GAL from HW to CP by negotiating CC type-1 itself. There is no negotiation; VCCV uses a capability advertisement. = But more to the point,=20 the proposed operation rule here is simple and straight-forward: if you = have configured the CW and advertised=20 that as per the rules for use of the CW, then Type 1 MUST be used. If = not, use Type 4 (if both sides are capable). =20 > Some editorial comments for the draft-nadeau-pwe3-vccv-2-01.txt draft, > " > 4.1.1. MPLS VCCV Control Channel (CC) Type 4 >=20 > IANA is requested to augment the registry of "MPLS VCCV Control > Channel Types" with the new type defined below. As defined in > RFC5058, this new bitfield is to be assigned by IANA using > " > Replace the RFC5058 as RFC5085. Cool, thanks. We will fix this in the next rev. --Tom >=20 > Thanks, > Venkat. >=20 > On Fri, Mar 11, 2011 at 2:21 PM, Alexander Vainshtein = wrote: > Greg, Luca, >=20 > As I=92ve already stated in my comment on draft-nadeau-pwe3-vccv-2, = IMHO it makes draft-lm-pwe3-mpls-tp-gal-in-pw completely useless. >=20 > =20 > My 2c, >=20 > Sasha >=20 > =20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of Greg Mirsky > Sent: Friday, March 11, 2011 9:14 PM > To: Luca Martini > Cc: lihan@chinamobile.com; mpls@ietf.org; pwe3; HUANG Feng F; = mpls-tp@ietf.org > Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt >=20 > =20 > Dear Luca, > thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my attention. = I'll send my comments to it in a separate e-mail. > I'll have to miss another opportunity to discuss your proposal in a = meeting. Please add my comments below to my earlier expressed WG LC = comments: >=20 > the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution that = addresses applicability of GAL in PW VCCV, e.g. solution proposed in = draft-nadeau-pwe3-vccv-2-01; > the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs to mention such = dependency and refer to any existing proposal; > I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be advanced = in lock with document that addresses use of GAL in PW VCCV. > Regards, > Greg >=20 > On Fri, Mar 11, 2011 at 5:31 AM, Luca Martini = wrote: >=20 > Greg , > Some >=20 >=20 > On 02/18/11 11:15, Greg Mirsky wrote: > > Dear Luca, > > I see at least two issues: > > > > * use of GAL for PW, in my view, is another VCCV CC type that = has > > to be negotiated as described in RFC 5085. > > >=20 > These are valid points, but this document in question does not define, > not discussed VCCV. > We have since posted a draft that proposes a new VCCV mode , and we > welcome comments regarding that document. > (draft-nadeau-pwe3-vccv-2-01.txt) >=20 > > * use of GAL creates ambiguous situation when PW CW is used. The >=20 > > benefit from extending GAL in PW, as I see, is for PWs that = are > > not required to use PW CW. That might be a good enough reason = to > > update RFC 5586 as proposed in the document but we must = address > > use cases of GAL in PWs that require presence PW CW. If we > > prohibit or even discourage use of GAL for these PWs that have > > PW VCCV as native Associated Channel, then architecture of ACh > > for MPLS-TP PW not simplified as result of adopting the = proposal. > > > > Regard >=20 > Greg, > The GAL is basically a notifier that the packet following the end of = the > MPLS label stack, is explicitly defined as a G-ACH format. > Normally the packet would be decoded as an IP packet , unless the last > label on the stack indicated otherwise. >=20 > The GAL can certainly be applied to a PW OAM packet on a PW that uses > the CW, and this document does not define that , nor restricts it. >=20 > The scope of this document is limited to removing an unnecessary > restriction in rfc5586, hence this comment not applicable to this = document. >=20 > Thanks. > Luca >=20 >=20 > > s, > > Greg > > > > On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini =20 > > > wrote: > > > > Greg, > > > > Sorry, but I do not remember the point you mention. > > Can you explain again here ? > > Thanks. > > Luca > > > > > > On 02/17/11 23:47, Greg Mirsky wrote: > > > Dear Authors and All, > > > prior to the meeting in Bejing and acceptance of this proposal = as WG > > > document Luca and I agreed that use of GAL with PW VCCV = presents a > > > problem. > > > I was not attending the IETF-79, nor I found discussion of = this > > issue > > > in the minutes. I think that this issue should be specified, > > > explained. In my view, this document updates not only RFC 5586 > > > but RFC 5085 too. > > > > > > Regards, > > > Greg > > > > > > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > > > > > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > > >=20 > > > >> = wrote: > > > > > > Greg, > > > > > > You are correct , the proposed update does not propose any > > changes > > > to VCCV. > > > However the problem with vccv is not as simple as to ask = for > > a new > > > code point from IANA. > > > Given the good amount of discussion on this point, we = should > > > probably have a discussion in Beijing. > > > > > > Luca > > > > > > > > > > > > On 10/29/2010 05:07 PM, Greg Mirsky wrote: > > >> Dear Authors, > > >> I think that proposed update of the Section 4.2. RFC 5586 > > makes it possible > > >> to use GAL on MPLS-TP PW that uses Control Word. I = consider > > it to be > > >> conflict between PW VCCV CC types because use of GAL is = not > > negotiated > > >> through PW VCCV negotiation. To avoid such situation I = propose: > > >> > > >> - in Section 5 request IANA to assign new CC Type = "MPLS > > Generic > > >> Associated Channel Label" > > >> - assign precedence to new CC Type that affects = Section > > 7 RFC 5085 > > >> > > >> Regards, > > >> Greg > > >> > > >> > > >> > > >> _______________________________________________ > > >> mpls mailing list >=20 > > >> mpls@ietf.org = =20 > > > > > >> https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > >=20 >=20 > =20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 >=20 > --=20 > Best Regards, > Venkatesan Mahalingam. > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --Apple-Mail-5--552644677 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi,
    AFAIK, = ACH can't be used without supporting the CW in = HW.

    As per RFC-5085, 5.1.1.  In-Band VCCV = (Type 1)
    CC Type-1 mode of VCCV operation MUST be supported = when the control word is present.

    Are we implicitly mandating the CW (ACH) in HW by = configuring/negotiating the CC type-4?
    It looks to me that CC = type-1 for ACH without GAL and CC type-4 for ACH with = GAL.

    The = IETF's protocols do not mandate how they are to be implemented per se = (i.e.:
    in HW or not). The draft addresses the operational = concerns of configuration/complexity 
    by having 1 = mode for each of the major operational scenarios: with or without the = CW.

    IMO, if we support CC = type-4, CC type-1 support is implicitly = attained.

    IMHO, it should be possible to get = the MPLS-TP OAM control packets with or without GAL from HW to CP by = negotiating CC type-1 = itself.

    There is = no negotiation; VCCV uses a capability advertisement. But more to the = point, 
    the proposed operation rule here is simple and = straight-forward: if you have configured the CW and = advertised 
    that as per the rules for use of = the CW, then Type 1 MUST be used. If not, use Type 4 (if both = sides are capable).  

    Some editorial comments for the draft-nadeau-pwe3-vccv-2-01.txt = draft,
    "
    4.1.1.  MPLS VCCV Control Channel = (CC) Type 4

       IANA is requested to = augment the registry of "MPLS VCCV Control
       Channel Types" with the new type defined below. As = defined in
       RFC5058, this new bitfield is to be = assigned by IANA using
    "
    Replace the RFC5058 as = RFC5085.

    Cool, = thanks. We will fix this in the next rev.

    = --Tom



    Thanks,
    Venkat.

    On Fri, Mar 11, 2011 at 2:21 PM, Alexander = Vainshtein <Alexander.Vainshtein@ecit= ele.com> wrote:

    Greg, Luca,

    As = I=92ve already stated in my comment on draft-nadeau-pwe3-vccv-2, IMHO it = makes draft-lm-pwe3-mpls-tp-gal-in-pw completely = useless.

     

    My 2c,

         = Sasha

     

    From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Greg = Mirsky
    Sent: Friday, March 11, 2011 9:14 PM
    To: Luca = Martini
    Cc: lihan@chinamobile.com; mpls@ietf.org; pwe3; = HUANG Feng F; mpls-tp@ietf.org
    Subject: Re: [mpls] WG LC = draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

     

    Dear = Luca,
    thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my = attention. I'll send my comments to it in a separate e-mail.
    I'll have to miss another opportunity to discuss your proposal in a = meeting. Please add my comments below to my earlier expressed WG LC = comments:

    • the = draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution that = addresses applicability of GAL in PW VCCV, e.g. solution proposed in = draft-nadeau-pwe3-vccv-2-01;
    • the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs to = mention such dependency and refer to any existing proposal;
    • I believe that the = draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be advanced in lock with document = that addresses use of GAL in PW VCCV.

    Regards,
    Greg

    On Fri, Mar 11, 2011 at 5:31 AM, Luca Martini <lmartini@cisco.com> wrote:

    Greg ,
    Some


    On = 02/18/11 11:15, Greg Mirsky wrote:
    > Dear Luca,
    > I see at = least two issues:
    >
    >     * use of GAL for PW, in = my view, is another VCCV CC type that has
    >       to be negotiated as described in RFC = 5085.
    >

    These are valid points, = but this document in question does not define,
    not discussed = VCCV.
    We have since posted a draft that proposes a new VCCV mode , = and we
    welcome comments regarding that = document.
    (draft-nadeau-pwe3-vccv-2-01.txt)

    >     = * use of GAL creates ambiguous situation when PW CW is used. = The

    >       benefit = from extending GAL in PW, as I see, is for PWs that are
    >       not required to use PW CW. That might be a = good enough reason to
    >       update RFC 5586 as = proposed in the document but we must address
    >     =   use cases of GAL in PWs that require presence PW CW. If we
    >       prohibit or even discourage use of GAL for = these PWs that have
    >       PW VCCV as native = Associated Channel, then architecture of ACh
    >     =   for MPLS-TP PW not simplified as result of adopting the = proposal.
    >
    > Regard

    Greg,
    The GAL is = basically a notifier that the packet following the end of the
    MPLS = label stack, is explicitly defined as a G-ACH format.
    Normally the = packet would be decoded as an IP packet , unless the last
    label on the stack indicated otherwise.

    The GAL can certainly be = applied  to a PW OAM packet on a PW that uses
    the CW, and this = document does not define that , nor restricts it.

    The scope of = this document is limited to removing an unnecessary
    restriction in rfc5586, hence  this comment not applicable to this = document.

    Thanks.
    Luca


    > = s,
    > Greg
    >
    > On Fri, Feb 18, 2011 at 7:46 AM, Luca = Martini <lmartini@cisco.com

    > <mailto:lmartini@cisco.com>> wrote:
    >
    > =     Greg,
    >
    >     Sorry, but I do not = remember the point you mention.
    >     Can you explain again here ?
    >     = Thanks.
    >     Luca
    >
    >
    >     = On 02/17/11 23:47, Greg Mirsky wrote:
    >     > Dear = Authors and All,
    >     > prior to the meeting in = Bejing and acceptance of this proposal as WG
    >     > document Luca and I agreed that use of GAL with = PW VCCV presents a
    >     > problem.
    >   =   > I was not attending the IETF-79, nor I found discussion of = this
    >     issue
    >     > in the = minutes. I think that this issue should be specified,
    >     > explained. In my view, this document updates not = only RFC 5586
    >     > but RFC 5085 too.
    > =     >
    >     > Regards,
    >   =   > Greg
    >     >
    >     > = Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt
    >     >
    >     > On Sat, Oct 30, 2010 = at 10:14 AM, Luca Martini
    >     <lmartini@cisco.com <mailto:lmartini@cisco.com>

    >     > = <mailto:lmartini@cisco.com <mailto:lmartini@cisco.com>>> wrote:
    >     >
    >     >     = Greg,
    >     >
    >     >   =   You are correct , the proposed update does not propose = any
    >     changes
    >     >   =   to VCCV.
    >     >     However the = problem with vccv is not as simple as to ask for
    >     a new
    >     >     code = point from IANA.
    >     >     Given the good = amount of discussion on this point, we should
    >     > =     probably have a discussion in Beijing.
    >   =   >
    >     >     Luca
    >     >
    >     >
    >     = >
    >     >     On 10/29/2010 05:07 PM, = Greg Mirsky wrote:
    >     >>     Dear = Authors,
    >     >>     I think that = proposed update of the Section 4.2. RFC 5586
    >     makes it possible
    >     >> =     to use GAL on MPLS-TP PW that uses Control Word. I = consider
    >     it to be
    >     >> =     conflict between PW VCCV CC types because use of GAL is = not
    >     negotiated
    >     >>   =   through PW VCCV negotiation. To avoid such situation I = propose:
    >     >>
    >     >> =        - in Section 5 request IANA to assign new CC = Type "MPLS
    >     Generic
    >     >>     =    Associated Channel Label"
    >     >> =        - assign precedence to new CC Type that = affects Section
    >     7 RFC 5085
    >     = >>
    >     >>     Regards,
    >     >>     Greg
    >     = >>
    >     >>
    >     = >>
    >     >>     = _______________________________________________
    >     = >>     mpls mailing list

    >     >>     mpls@ietf.org = <mailto:mpls@ietf.org> <mailto:mpls@ietf.org

    > =     <mailto:mpls@ietf.org>>
    >     = >>     https://www.ietf.org/mailman/listinfo/mpls
    >     >
    >     >
    >     = >
    >     > = _______________________________________________
    >     = > mpls mailing list
    >     > mpls@ietf.org = <mailto:mpls@ietf.org>
    >     > https://www.ietf.org/mailman/listinfo/mpls
    >>

     

    _______________________________________________
    mpls mailing list
    mpls@ietf.org
    https://www.ietf.org/mailman/listinfo/mpls




    --
    Best = Regards,
    Venkatesan Mahalingam.
    _______________________________________________
    pwe3 mailing = list
    pwe3@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/pwe3

    = --Apple-Mail-5--552644677-- From gregimirsky@gmail.com Fri Mar 11 14:25:16 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E99B83A6A35; Fri, 11 Mar 2011 14:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 wgm9dbpUjnG3; Fri, 11 Mar 2011 14:25:16 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id CA0073A6A33; Fri, 11 Mar 2011 14:25:15 -0800 (PST) Received: by vxg33 with SMTP id 33so3633815vxg.31 for ; Fri, 11 Mar 2011 14:26:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=2GrZGr9yDED+6AhRbC4GZkBBarxuS5Cb/vMPyFJUJVw=; b=cjUd4wLgtt8GEGz1ZPmueWRecd5wVMu3rw8zoZV3xD7qOywQF45mW/2uC+QTbkIuf/ 78/pmq7ES+xUpWrxIPw6BmcRMGRwFLvug/+R4imH4p/8LrSvEIazXtxgG6E9adlPbhi3 RTYAtMezTOKjJyLtS/gOOwR55uzVfIS768ld8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YeOPp/xYEezSXaUlAE95Lu6IP/7QoDPsSZGqqUlFl11fFr50Ik4/M2XmD6QYx6eBIw aHFxSXOViyGqTHMxkzn1qJEDoacs/1Bl0yoqlS4wN8HS54Ery955BCdSaauOGuGD1RG8 Yza/sSb49py3cuQ7mIhzsoUOKvgUxqJ5h7D4Y= MIME-Version: 1.0 Received: by 10.52.0.34 with SMTP id 2mr14634365vdb.9.1299882395425; Fri, 11 Mar 2011 14:26:35 -0800 (PST) Received: by 10.52.169.35 with HTTP; Fri, 11 Mar 2011 14:26:35 -0800 (PST) Date: Fri, 11 Mar 2011 14:26:35 -0800 Message-ID: From: Greg Mirsky To: Thomas Nadeau , Luca Martini , pwe3 , mpls@ietf.org Content-Type: multipart/alternative; boundary=20cf3054aa2b6ddb57049e3c7486 Subject: [mpls] Comments to draft-nadeau-pwe3-vccv-2-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 22:25:17 -0000 --20cf3054aa2b6ddb57049e3c7486 Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, please find my comments below. - this proposal is closely related to changes to RFC 5586 put forward in draft-lm-pwe3-mpls-tp-gal-in-pw-00 but there's no reference to the draft. - RFC 5586 states and the draft-lm-pwe3-mpls-tp-gal-in-pw-00 maintains that in MPLS-TP network the GAL must be BoS. Only in non-TP MPLS netowrks GAL might be not a BoS. In your proposal the GAL precedes the PW and thus is not BoS. But the document's scope is for all MPLS PWs, including over MPLS-TP PSN. Unless statement in Section 4.2 RFC 5586 "In MPLS-TP (GAL) ... MUST always be at the bottom of the label stack (i.e., S bit set to 1)" updated proposed use of GAL is allowed only in non-TP MPLS PSN. - Section 2 lists of allowed ACH. Since these are hexadecimal numbers I'd suggest prepending them with '0x' to make as "0x07, 0x21, and 0x57". And I'd ask for clarification of "allowed". Is it "MAY", "SHOULD" or "MUST" be limited to ... A, B, C"? - In Section 3 stated that TTL in PW LSE must be set to 1 for SS-PW and to appropriate value in MS-PW to reach intended PE. Hence my question, Is this mechanism to reach MIP, i.e. S-PE, or this is mechanism to generate exception? But that is how PW VCCV Control Channel Type 3 works. What is the interpretation of GAL in a label stack? To indicate PW CW after the PW LSE? - editorial - in Abstract s/The MPLS/the MPLS or a reference to, perhaps, RFC 5654. Regards, Greg --20cf3054aa2b6ddb57049e3c7486 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors,
    please find my comments below.
    • this proposal is= closely related to changes to RFC 5586 put forward in draft-lm-pwe3-mpls-t= p-gal-in-pw-00 but there's no reference to the draft.
    • RFC 5586 = states and the draft-lm-pwe3-mpls-tp-gal-in-pw-00 maintains that in MPLS-TP= network the GAL must be BoS. Only in non-TP MPLS netowrks GAL might be not= a BoS. In your proposal the GAL precedes the PW and thus is not BoS. But t= he document's scope is for all MPLS PWs, including over MPLS-TP PSN. Un= less statement in Section 4.2 RFC 5586 "In MPLS-TP (GAL) ... MUST alwa= ys be at the bottom of the label stack (i.e., S bit set to 1)" updat= ed proposed use of GAL is allowed only in non-TP MPLS PSN.
    • Section 2 lists of allowed ACH. Since these are hexadecimal numbers I&#= 39;d suggest prepending them with '0x' to make as "0x07, 0x21,= and 0x57". And I'd ask for clarification of "allowed". = Is it "MAY", "SHOULD" or "MUST" be limited to= ... A, B, C"?
    • In Section 3 stated that TTL in PW LSE must be set to 1 for SS-PW and t= o appropriate value in MS-PW to reach intended PE. Hence my question, Is th= is mechanism to reach MIP, i.e. S-PE, or this is mechanism to generate exce= ption? But that is how PW VCCV Control Channel Type 3 works. What is the in= terpretation of GAL in a label stack? To indicate PW CW after the PW LSE?
    • editorial - in Abstract s/The MPLS/the MPLS or a reference to, perhaps,= RFC 5654.

    Regards,
    Greg



    --20cf3054aa2b6ddb57049e3c7486-- From Alexander.Vainshtein@ecitele.com Fri Mar 11 20:43:33 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED87E3A688F; Fri, 11 Mar 2011 20:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 jOVDqHDbc8-I; Fri, 11 Mar 2011 20:43:32 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id D63E93A6860; Fri, 11 Mar 2011 20:43:30 -0800 (PST) X-AuditID: 93eaf2e7-b7ba1ae000007bf7-35-4d7afa384233 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id D4.C0.31735.83AFA7D4; Sat, 12 Mar 2011 06:44:40 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Sat, 12 Mar 2011 06:44:48 +0200 From: Alexander Vainshtein To: venkatesan mahalingam , "mpls@ietf.org" Date: Sat, 12 Mar 2011 06:44:47 +0200 Thread-Topic: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Thread-Index: AcvgKLRR/QDnyQIyQ9GTo8TU7K+rhgARpxhw Message-ID: References: <4D5E9442.3030101@cisco.com> <4D7A2439.6010508@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAB3ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "mpls-tp@ietf.org" , "lihan@chinamobile.com" , pwe3 , HUANG Feng F Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 04:43:34 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAB3ILPTMAIL02eci_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Venkat, You have asked "Are we implicitly mandating the CW (ACH) in HW by configuri= ng/negotiating the CC type-4?" IMO the answer is "No". In VCCV Type 1 the first nibble of the CW is a data path (HW if you wish) e= xception mechanism forwarding the packets to an OAM entity. In VCCV Type 4 GAL acts as such an exception mechanism. ACH is actually onl= y needed to decide on the ACH Type. And it would not even be examined if th= e TTL in the PW label has not expired. My 2c, Sasha ________________________________ From: venkatesan mahalingam [venkatflex@gmail.com] Sent: Friday, March 11, 2011 10:12 PM To: Alexander Vainshtein; Greg Mirsky; Luca Martini; lihan@chinamobile.com;= mpls-tp@ietf.org; pwe3; HUANG Feng F; mpls@ietf.org Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Hi, AFAIK, ACH can't be used without supporting the CW in HW. As per RFC-5085, 5.1.1. In-Band VCCV (Type 1) CC Type-1 mode of VCCV operation MUST be supported when the control word is= present. It looks to me that CC type-1 for ACH without GAL and CC type-4 for ACH wit= h GAL. IMO, if we support CC type-4, CC type-1 support is implicitly attained. IMHO, it should be possible to get the MPLS-TP OAM control packets with or = without GAL from HW to CP by negotiating CC type-1 itself. Some editorial comments for the draft-nadeau-pwe3-vccv-2-01.txt draft, " 4.1.1. MPLS VCCV Control Channel (CC) Type 4 IANA is requested to augment the registry of "MPLS VCCV Control Channel Types" with the new type defined below. As defined in RFC5058, this new bitfield is to be assigned by IANA using " Replace the RFC5058 as RFC5085. Thanks, Venkat. On Fri, Mar 11, 2011 at 2:21 PM, Alexander Vainshtein > wrote: Greg, Luca, As I=92ve already stated in my comment on draft-nadeau-pwe3-vccv-2, IMHO it= makes draft-lm-pwe3-mpls-tp-gal-in-pw completely useless. My 2c, Sasha From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Greg Mirsky Sent: Friday, March 11, 2011 9:14 PM To: Luca Martini Cc: lihan@chinamobile.com; mpls@ietf.org; pwe3; HUANG Feng F; mpls-tp@ietf.org Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Dear Luca, thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my attention. I'll se= nd my comments to it in a separate e-mail. I'll have to miss another opportunity to discuss your proposal in a meeting= . Please add my comments below to my earlier expressed WG LC comments: * the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution that ad= dresses applicability of GAL in PW VCCV, e.g. solution proposed in draft-na= deau-pwe3-vccv-2-01; * the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs to mention such dependenc= y and refer to any existing proposal; * I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be advanced = in lock with document that addresses use of GAL in PW VCCV. Regards, Greg On Fri, Mar 11, 2011 at 5:31 AM, Luca Martini > wrote: Greg , Some On 02/18/11 11:15, Greg Mirsky wrote: > Dear Luca, > I see at least two issues: > > * use of GAL for PW, in my view, is another VCCV CC type that has > to be negotiated as described in RFC 5085. > These are valid points, but this document in question does not define, not discussed VCCV. We have since posted a draft that proposes a new VCCV mode , and we welcome comments regarding that document. (draft-nadeau-pwe3-vccv-2-01.txt) > * use of GAL creates ambiguous situation when PW CW is used. The > benefit from extending GAL in PW, as I see, is for PWs that are > not required to use PW CW. That might be a good enough reason to > update RFC 5586 as proposed in the document but we must address > use cases of GAL in PWs that require presence PW CW. If we > prohibit or even discourage use of GAL for these PWs that have > PW VCCV as native Associated Channel, then architecture of ACh > for MPLS-TP PW not simplified as result of adopting the proposal. > > Regard Greg, The GAL is basically a notifier that the packet following the end of the MPLS label stack, is explicitly defined as a G-ACH format. Normally the packet would be decoded as an IP packet , unless the last label on the stack indicated otherwise. The GAL can certainly be applied to a PW OAM packet on a PW that uses the CW, and this document does not define that , nor restricts it. The scope of this document is limited to removing an unnecessary restriction in rfc5586, hence this comment not applicable to this document= . Thanks. Luca > s, > Greg > > On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini > >> wrote: > > Greg, > > Sorry, but I do not remember the point you mention. > Can you explain again here ? > Thanks. > Luca > > > On 02/17/11 23:47, Greg Mirsky wrote: > > Dear Authors and All, > > prior to the meeting in Bejing and acceptance of this proposal as W= G > > document Luca and I agreed that use of GAL with PW VCCV presents a > > problem. > > I was not attending the IETF-79, nor I found discussion of this > issue > > in the minutes. I think that this issue should be specified, > > explained. In my view, this document updates not only RFC 5586 > > but RFC 5085 too. > > > > Regards, > > Greg > > > > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > > > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > > > > >>> wrote: > > > > Greg, > > > > You are correct , the proposed update does not propose any > changes > > to VCCV. > > However the problem with vccv is not as simple as to ask for > a new > > code point from IANA. > > Given the good amount of discussion on this point, we should > > probably have a discussion in Beijing. > > > > Luca > > > > > > > > On 10/29/2010 05:07 PM, Greg Mirsky wrote: > >> Dear Authors, > >> I think that proposed update of the Section 4.2. RFC 5586 > makes it possible > >> to use GAL on MPLS-TP PW that uses Control Word. I consider > it to be > >> conflict between PW VCCV CC types because use of GAL is not > negotiated > >> through PW VCCV negotiation. To avoid such situation I propose= : > >> > >> - in Section 5 request IANA to assign new CC Type "MPLS > Generic > >> Associated Channel Label" > >> - assign precedence to new CC Type that affects Section > 7 RFC 5085 > >> > >> Regards, > >> Greg > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > > >> > >> https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- Best Regards, Venkatesan Mahalingam. --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAB3ILPTMAIL02eci_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    Venkat,
     
    You have asked "Are we implic= itly mandating the CW (ACH) in HW by configuring/negotiating the CC type-4?= "
     
    IMO the answer is "No".
    In VCCV Type 1 the first nibble of the = CW is a data path (HW if you wish) exception mechanism forwarding the packe= ts to an OAM entity.
     
    In VCCV Type 4 GAL acts as such an exce= ption mechanism. ACH is actually only needed to decide on the ACH Type. And= it would not even be examined if the TTL in the PW label has n= ot expired.
     
    My 2c,
         Sasha
     
     
     
    From: venkatesan = mahalingam [venkatflex@gmail.com]
    Sent: Friday, March 11, 2011 10:12 PM
    To: Alexander Vainshtein; Greg Mirsky; Luca Martini; lihan@chinamobi= le.com; mpls-tp@ietf.org; pwe3; HUANG Feng F; mpls@ietf.org
    Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

    Hi,
    AFAIK, ACH can't be used without supporting the CW in HW.

    As per RFC-5085, 5.1.1.  In-Band VCCV (Type 1)
    CC Type-1 mode of VCCV operation MUST be supported when the control wo= rd is present.

    It looks to me that CC type-1 for ACH without GAL and CC type-4 for AC= H with GAL.

    IMO, if we support CC type-4, CC type-1 support is implicitly attained= .

    IMHO, it should be possible to get the MPLS-TP OAM control packets wit= h or without GAL from HW to CP by negotiating CC type-1 itself.

    Some editorial comments for the draft-nadeau-pwe3-vccv-2-01.txt draft,=
    "
    4.1.1.  MPLS VCCV Control Channel (CC) Type 4

       IANA is requested to augment the registry of "MPLS V= CCV Control
       Channel Types" with the new type defined below. As d= efined in
       RFC5058, this new bitfield is to be assigned by IANA usin= g
    "
    Replace the RFC5058 as RFC5085.

    Thanks,
    Venkat.

    On Fri, Mar 11, 2011 at 2:21 PM, Alexander Vains= htein <Alexander.Vainshtei= n@ecitele.com> wrote:

    Greg= , Luca,

    As I= =92ve already stated in my comment on draft-nadeau-pwe3-vccv-2, IMHO it mak= es draft-lm-pwe3-mpls-tp-gal-in-pw completely useless.

     

    My 2= c,

    &nbs= p;    Sasha

     

    From:<= span style=3D"FONT-SIZE: 10pt"> mpls-bounces@ietf.org [mailto:= mpls-bounces@ietf.org] On Behalf Of Greg Mirsky
    Sent: Friday, March 11, 2011 9:14 PM
    To: Luca Martini
    Cc: lihan@chinamobile.com; mpls@ietf.org; pwe3; HUANG Feng F; = mpls-tp@ietf.org
    Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

     

    Dear Luca,
    thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my attention. I'll se= nd my comments to it in a separate e-mail.
    I'll have to miss another opportunity to discuss your proposal in a meeting= . Please add my comments below to my earlier expressed WG LC comments:

    • the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on a= ny solution that addresses applicability of GAL in PW VCCV, e.g. solution p= roposed in draft-nadeau-pwe3-vccv-2-01;
    • the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs t= o mention such dependency and refer to any existing proposal;
    • I believe that the draft-lm-pwe3-mpls-tp-gal-i= n-pw-00 can be advanced in lock with document that addresses use of GAL in = PW VCCV.

    Regards,
    Greg

    On Fri, Mar 11, 2011 at 5:31 AM, Luca Martini <lmartini@cisco.com> wrote:

    Greg ,
    Some


    On 02/18/11 11:15, Greg Mirsky wrote:
    > Dear Luca,
    > I see at least two issues:
    >
    >     * use of GAL for PW, in my view, is another VCCV CC type= that has
    >       to be negotiated as described in RFC 5085.
    >

    These are valid points, but this document in questio= n does not define,
    not discussed VCCV.
    We have since posted a draft that proposes a new VCCV mode , and we
    welcome comments regarding that document.
    (draft-nadeau-pwe3-vccv-2-01.txt)

    >     * use of GAL creates ambiguous situation when PW CW is u= sed. The

    >       benefit from extending GAL= in PW, as I see, is for PWs that are
    >       not required to use PW CW. That might be a good e= nough reason to
    >       update RFC 5586 as proposed in the document but w= e must address
    >       use cases of GAL in PWs that require presence PW = CW. If we
    >       prohibit or even discourage use of GAL for these = PWs that have
    >       PW VCCV as native Associated Channel, then archit= ecture of ACh
    >       for MPLS-TP PW not simplified as result of adopti= ng the proposal.
    >
    > Regard

    Greg,
    The GAL is basically a notifier that the packet following the end of the MPLS label stack, is explicitly defined as a G-ACH format.
    Normally the packet would be decoded as an IP packet , unless the last
    label on the stack indicated otherwise.

    The GAL can certainly be applied  to a PW OAM packet on a PW that uses=
    the CW, and this document does not define that , nor restricts it.

    The scope of this document is limited to removing an unnecessary
    restriction in rfc5586, hence  this comment not applicable to this doc= ument.

    Thanks.
    Luca


    > s,
    > Greg
    >
    > On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini <lmartini@cisco.com

    > <mailto:lmartini@cisco.com>> wrote:
    >
    >     Greg,
    >
    >     Sorry, but I do not remember the point you mention.
    >     Can you explain again here ?
    >     Thanks.
    >     Luca
    >
    >
    >     On 02/17/11 23:47, Greg Mirsky wrote:
    >     > Dear Authors and All,
    >     > prior to the meeting in Bejing and acceptance of th= is proposal as WG
    >     > document Luca and I agreed that use of GAL with PW = VCCV presents a
    >     > problem.
    >     > I was not attending the IETF-79, nor I found discus= sion of this
    >     issue
    >     > in the minutes. I think that this issue should be s= pecified,
    >     > explained. In my view, this document updates not on= ly RFC 5586
    >     > but RFC 5085 too.
    >     >
    >     > Regards,
    >     > Greg
    >     >
    >     > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt >     >
    >     > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini
    >     <lmartini@cisco= .com <mailto:lmartini@cisco.co= m>

    >     > <mailto:lmartini@cisco.com <mailto:lmartini@cisco.com>>> wrote:
    >     >
    >     >     Greg,
    >     >
    >     >     You are correct , the proposed update= does not propose any
    >     changes
    >     >     to VCCV.
    >     >     However the problem with vccv is not = as simple as to ask for
    >     a new
    >     >     code point from IANA.
    >     >     Given the good amount of discussion o= n this point, we should
    >     >     probably have a discussion in Beijing= .
    >     >
    >     >     Luca
    >     >
    >     >
    >     >
    >     >     On 10/29/2010 05:07 PM, Greg Mirsky w= rote:
    >     >>     Dear Authors,
    >     >>     I think that proposed update of t= he Section 4.2. RFC 5586
    >     makes it possible
    >     >>     to use GAL on MPLS-TP PW that use= s Control Word. I consider
    >     it to be
    >     >>     conflict between PW VCCV CC types= because use of GAL is not
    >     negotiated
    >     >>     through PW VCCV negotiation. To a= void such situation I propose:
    >     >>
    >     >>        - in Section 5 reque= st IANA to assign new CC Type "MPLS
    >     Generic
    >     >>        Associated Channel L= abel"
    >     >>        - assign precedence = to new CC Type that affects Section
    >     7 RFC 5085
    >     >>
    >     >>     Regards,
    >     >>     Greg
    >     >>
    >     >>
    >     >>
    >     >>     _________________________________= ______________
    >     >>     mpls mailing list

    >     >>     mpls@ietf.org <mailto:mpls@ietf.org> <mailto:mpls@ietf.org

    >     <= ;mailto:mpls@ietf.org>>
    >     >>     https://www.ietf.org/mailman/listinfo/mpls
    >     >
    >     >
    >     >
    >     > _______________________________________________
    >     > mpls mailing list
    >     > mpls@ietf.org = <mailto:mpls@ietf.org>
    >     > https://www.ietf.org/mailman/listinfo/mpls
    >
    >

     


    _______________________________________________
    mpls mailing list
    mpls@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/mpls




    --
    Best Regards,
    Venkatesan Mahalingam.
    --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAB3ILPTMAIL02eci_-- From loa@pi.nu Sat Mar 12 18:57:37 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F3D13A6AA7 for ; Sat, 12 Mar 2011 18:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 mw9ZBRxJ2cPE for ; Sat, 12 Mar 2011 18:57:35 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 293433A6AA2 for ; Sat, 12 Mar 2011 18:57:34 -0800 (PST) Received: from [172.17.113.226] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 3B0222A8001; Sun, 13 Mar 2011 03:58:52 +0100 (CET) Message-ID: <4D7C32E9.9010203@pi.nu> Date: Sat, 12 Mar 2011 18:58:49 -0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , draft-ietf-mpls-mp-ldp-reqs@tools.ietf.org Subject: [mpls] working group last call on draft-ietf-mpls-mp-ldp-reqs-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 02:57:37 -0000 Working Group, This is to start a wg last call on publishing draft-ietf-mpls-mp-ldp-reqs-06 as an Informational RFC with Historic status. Background: The working group accepted "draft-ietf-mpls-mp-ldp-reqs" as working group document in 2006. Recently the working group chairs received a question from the authors of this document if we could issue a working group last call. At the same time we had opinions that said that we have deployed implementations and that the current version version did not match the existing implementations; further retrofitting the requirements to match the deployments would involve work that wouldn't really be necessary since the protocol specifications are availble. When the working group chairs discussed this we found that 1. The requirement draft is less than perfect aligned with existing implementations. 2. Publishing the document as an Informational RFC could cause confusion about requirement situation 3. That the work document in the draft still has value, if from no other perspective to document work that the work group have done. 4. We found that publishing the document as an Informational RFC with Historic status would be the appropriate thing to do. When discussing the process for this by our ADs it is clear that we need to run the document through a working group last call before requesting publication. We have also asked the authors and received no objections for this way forward. This working group does primarily not ask for comments on the actual text; but opinions on and support for publication as historic. An RFC-Editors note will be added to explain the reason to publish the document with Historic status. The working group last call ends on March 27. Please send your comments to the mpls working group mailing list. Loa on behalf of the MPLS working group co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From lamberto.sterling@gmail.com Sat Mar 12 19:34:56 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6F573A6AA7; Sat, 12 Mar 2011 19:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] 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 RxjaALs0P4S4; Sat, 12 Mar 2011 19:34:53 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 537F93A67FC; Sat, 12 Mar 2011 19:34:52 -0800 (PST) Received: by bwz13 with SMTP id 13so4078015bwz.31 for ; Sat, 12 Mar 2011 19:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=pvK2MZT2ouEhIqLP89nQ2D5nUAynfHRNHNgMGN12mHo=; b=l4wlgmfqo4tIQBO1LWiwQcU5dItCN2LrVMCJ2RZYQS7bT+UNYT823JUE8wBka0ad2+ JOVnufhz0ByRUW2Q2bDbeAeC+YVc7xK08fQx5X56XBgn6wu83SU5I6ir49/l4wZrJuxo 7jl4xtaXbixR32207upVTXARgVPQouhRj0eFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=a9AZvQRbUvOFjfvOpPNTPWdHyVL7baVnEVhSbRKZWZ5MeK7W905dAD/WIok5f4iqB7 tEtOOVbcQcnH+7c3kWfWgHd+BEW7kQQ1eybTKjdIQRHHjHCxpUir48DmoQH9fs/JnZYb v/4WpuvI3zcJAabPStoOh+i5VDTiRlyt9c1Hk= MIME-Version: 1.0 Received: by 10.204.141.14 with SMTP id k14mr5060633bku.37.1299987372957; Sat, 12 Mar 2011 19:36:12 -0800 (PST) Received: by 10.204.35.65 with HTTP; Sat, 12 Mar 2011 19:36:12 -0800 (PST) Date: Sun, 13 Mar 2011 04:36:12 +0100 Message-ID: From: Lamberto Sterling To: Alexander.Vainshtein@ecitele.com, Luca Martini Content-Type: multipart/alternative; boundary=00151759367093e25f049e54e566 Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" , "lihan@chinamobile.com" , pwe3 , HUANG Feng F Subject: Re: [mpls] [PWE3] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 03:34:57 -0000 --00151759367093e25f049e54e566 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I do not see the benefit that GAL in PW can bring while current three CC type does not own. If there is no agreed benefit, why we add overload to the indurstry (more HW design), and complexity to the interoperability by ourself? When IETF refuse draft-bhh-1731 as OAM tool for MPLS-TP, the reason is again interoperability and indurstry HW cost, and personally agree with that. Lamberto > ------------------------------ > > Date: Sat, 12 Mar 2011 06:44:47 +0200 > From: Alexander Vainshtein > Subject: Re: [PWE3] [mpls] WG LC > draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > To: venkatesan mahalingam , "mpls@ietf.org" > > Cc: Luca Martini , "mpls-tp@ietf.org" > , "lihan@chinamobile.com" < > lihan@chinamobile.com>, > pwe3 , HUANG Feng F < > Feng.f.Huang@alcatel-sbell.com.cn> > Message-ID: > > Content-Type: text/plain; charset="windows-1252" > > Venkat, > > You have asked "Are we implicitly mandating the CW (ACH) in HW by > configuring/negotiating the CC type-4?" > > IMO the answer is "No". > In VCCV Type 1 the first nibble of the CW is a data path (HW if you wish) > exception mechanism forwarding the packets to an OAM entity. > > In VCCV Type 4 GAL acts as such an exception mechanism. ACH is actually > only needed to decide on the ACH Type. And it would not even be examined if > the TTL in the PW label has not expired. > > My 2c, > Sasha > > > > ________________________________ > From: venkatesan mahalingam [venkatflex@gmail.com] > Sent: Friday, March 11, 2011 10:12 PM > To: Alexander Vainshtein; Greg Mirsky; Luca Martini; lihan@chinamobile.com; > mpls-tp@ietf.org; pwe3; HUANG Feng F; mpls@ietf.org > Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > Hi, > AFAIK, ACH can't be used without supporting the CW in HW. > > As per RFC-5085, 5.1.1. In-Band VCCV (Type 1) > CC Type-1 mode of VCCV operation MUST be supported when the control word is > present. > > It looks to me that CC type-1 for ACH without GAL and CC type-4 for ACH > with GAL. > > IMO, if we support CC type-4, CC type-1 support is implicitly attained. > > IMHO, it should be possible to get the MPLS-TP OAM control packets with or > without GAL from HW to CP by negotiating CC type-1 itself. > > Some editorial comments for the draft-nadeau-pwe3-vccv-2-01.txt draft, > " > 4.1.1. MPLS VCCV Control Channel (CC) Type 4 > > IANA is requested to augment the registry of "MPLS VCCV Control > Channel Types" with the new type defined below. As defined in > RFC5058, this new bitfield is to be assigned by IANA using > " > Replace the RFC5058 as RFC5085. > > Thanks, > Venkat. > > On Fri, Mar 11, 2011 at 2:21 PM, Alexander Vainshtein < > Alexander.Vainshtein@ecitele.com> > wrote: > Greg, Luca, > As I?ve already stated in my comment on draft-nadeau-pwe3-vccv-2, IMHO it > makes draft-lm-pwe3-mpls-tp-gal-in-pw completely useless. > > My 2c, > Sasha > > From: mpls-bounces@ietf.org [mailto: > mpls-bounces@ietf.org] On Behalf Of Greg > Mirsky > Sent: Friday, March 11, 2011 9:14 PM > To: Luca Martini > Cc: lihan@chinamobile.com; mpls@ietf.org > ; pwe3; HUANG Feng F; mpls-tp@ietf.org mpls-tp@ietf.org> > Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > Dear Luca, > thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my attention. I'll > send my comments to it in a separate e-mail. > I'll have to miss another opportunity to discuss your proposal in a > meeting. Please add my comments below to my earlier expressed WG LC > comments: > > * the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution that > addresses applicability of GAL in PW VCCV, e.g. solution proposed in > draft-nadeau-pwe3-vccv-2-01; > * the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs to mention such > dependency and refer to any existing proposal; > * I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be advanced > in lock with document that addresses use of GAL in PW VCCV. > Regards, > Greg > On Fri, Mar 11, 2011 at 5:31 AM, Luca Martini lmartini@cisco.com>> wrote: > Greg , > Some > > On 02/18/11 11:15, Greg Mirsky wrote: > > Dear Luca, > > I see at least two issues: > > > > * use of GAL for PW, in my view, is another VCCV CC type that has > > to be negotiated as described in RFC 5085. > > > These are valid points, but this document in question does not define, > not discussed VCCV. > We have since posted a draft that proposes a new VCCV mode , and we > welcome comments regarding that document. > (draft-nadeau-pwe3-vccv-2-01.txt) > > > * use of GAL creates ambiguous situation when PW CW is used. The > > benefit from extending GAL in PW, as I see, is for PWs that are > > not required to use PW CW. That might be a good enough reason to > > update RFC 5586 as proposed in the document but we must address > > use cases of GAL in PWs that require presence PW CW. If we > > prohibit or even discourage use of GAL for these PWs that have > > PW VCCV as native Associated Channel, then architecture of ACh > > for MPLS-TP PW not simplified as result of adopting the proposal. > > > > Regard > Greg, > The GAL is basically a notifier that the packet following the end of the > MPLS label stack, is explicitly defined as a G-ACH format. > Normally the packet would be decoded as an IP packet , unless the last > label on the stack indicated otherwise. > > The GAL can certainly be applied to a PW OAM packet on a PW that uses > the CW, and this document does not define that , nor restricts it. > > The scope of this document is limited to removing an unnecessary > restriction in rfc5586, hence this comment not applicable to this > document. > > Thanks. > Luca > > > s, > > Greg > > > > On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini > > >> wrote: > > > > Greg, > > > > Sorry, but I do not remember the point you mention. > > Can you explain again here ? > > Thanks. > > Luca > > > > > > On 02/17/11 23:47, Greg Mirsky wrote: > > > Dear Authors and All, > > > prior to the meeting in Bejing and acceptance of this proposal as > WG > > > document Luca and I agreed that use of GAL with PW VCCV presents a > > > problem. > > > I was not attending the IETF-79, nor I found discussion of this > > issue > > > in the minutes. I think that this issue should be specified, > > > explained. In my view, this document updates not only RFC 5586 > > > but RFC 5085 too. > > > > > > Regards, > > > Greg > > > > > > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > > > > > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > > lmartini@cisco.com> > > > lmartini@cisco.com>>> wrote: > > > > > > Greg, > > > > > > You are correct , the proposed update does not propose any > > changes > > > to VCCV. > > > However the problem with vccv is not as simple as to ask for > > a new > > > code point from IANA. > > > Given the good amount of discussion on this point, we should > > > probably have a discussion in Beijing. > > > > > > Luca > > > > > > > > > > > > On 10/29/2010 05:07 PM, Greg Mirsky wrote: > > >> Dear Authors, > > >> I think that proposed update of the Section 4.2. RFC 5586 > > makes it possible > > >> to use GAL on MPLS-TP PW that uses Control Word. I consider > > it to be > > >> conflict between PW VCCV CC types because use of GAL is not > > negotiated > > >> through PW VCCV negotiation. To avoid such situation I > propose: > > >> > > >> - in Section 5 request IANA to assign new CC Type "MPLS > > Generic > > >> Associated Channel Label" > > >> - assign precedence to new CC Type that affects Section > > 7 RFC 5085 > > >> > > >> Regards, > > >> Greg > > >> > > >> > > >> --00151759367093e25f049e54e566 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi all,
    I do not see the benefit that GAL in PW can bring while current three = CC type does not own. If there is no agreed benefit, why we add overload to= the indurstry (more HW design), and complexity to the interoperability by = ourself? When IETF refuse draft-bhh-1731 as OAM tool for MPLS-TP, the reaso= n is again interoperability and indurstry HW cost, and personally agree wit= h that.
    =A0
    Lamberto

    =A0
    ------------------------------
    Date: Sat, 12 Mar 2011 06:44:47 +0200
    From: Alexander Vainshtein &= lt;Alexander.Vainshtein= @ecitele.com>
    Subject: Re: [PWE3] [mpls] WG LC
    =A0 =A0 =A0 =A0draft-lm-pwe3-mpls-tp-ga= l-in-pw-00.txt
    To: venkatesan mahalingam <venkatflex@gmail.com>, "mpls@ietf.org"
    =A0 =A0 =A0 =A0<mpls@ietf.org>Cc: Luca Martini <lmartini@cisco= .com>, "mpls-tp@ietf.org"
    =A0 =A0 =A0 =A0<    mpls-tp@ietf.org= >, =A0 =A0 "lihan@chinamob= ile.com" <lihan@chinam= obile.com>,
    =A0 =A0 =A0 =A0pwe3 <pwe3@ietf.org&= gt;, =A0 HUANG Feng F <Feng.f.Huang@alcatel-sbell.com.cn>
    Message-ID:
    =A0 =A0 =A0= =A0<A3C5DF08D38B6049839A6F553B331C76D6FB8BEAB3@ILPTMAIL02.eci= tele.com>
    Content-Type: text/plain; charset=3D"windows-1252"

    Venkat,=

    You have asked "Are we implicitly mandating the CW (ACH) in HW= by configuring/negotiating the CC type-4?"

    IMO the answer is &= quot;No".
    In VCCV Type 1 the first nibble of the CW is a data path (HW if you wish) e= xception mechanism forwarding the packets to an OAM entity.

    In VCCV = Type 4 GAL acts as such an exception mechanism. ACH is actually only needed= to decide on the ACH Type. And it would not even be examined if the TTL in= the PW label has not expired.

    My 2c,
    =A0 =A0 Sasha



    ________________________________=
    From: venkatesan mahalingam [ve= nkatflex@gmail.com]
    Sent: Friday, March 11, 2011 10:12 PM
    To: Ale= xander Vainshtein; Greg Mirsky; Luca Martini; lihan@chinamobile.com; = mpls-tp@ietf.org; pwe3; HUANG Feng F; = mpls@ietf.org
    Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

    Hi,=
    AFAIK, ACH can't be used without supporting the CW in HW.

    As= per RFC-5085, 5.1.1. =A0In-Band VCCV (Type 1)
    CC Type-1 mode of VCCV op= eration MUST be supported when the control word is present.

    It looks to me that CC type-1 for ACH without GAL and CC type-4 for ACH= with GAL.

    IMO, if we support CC type-4, CC type-1 support is implic= itly attained.

    IMHO, it should be possible to get the MPLS-TP OAM co= ntrol packets with or without GAL from HW to CP by negotiating CC type-1 it= self.

    Some editorial comments for the draft-nadeau-pwe3-vccv-2-01.txt draft,<= br>"
    4.1.1. =A0MPLS VCCV Control Channel (CC) Type 4

    =A0 IAN= A is requested to augment the registry of "MPLS VCCV Control
    =A0 Ch= annel Types" with the new type defined below. As defined in
    =A0 RFC5058, this new bitfield is to be assigned by IANA using
    "Replace the RFC5058 as RFC5085.

    Thanks,
    Venkat.

    On Fri, M= ar 11, 2011 at 2:21 PM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecit= ele.com>> wrote:
    Greg, Luca,
    As I?ve already stated in my comment on draft-nadeau-pwe3-vc= cv-2, IMHO it makes draft-lm-pwe3-mpls-tp-gal-in-pw completely useless.
    =
    My 2c,
    =A0 =A0 Sasha

    From: mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org> [mailto:mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>] On Behalf Of Greg Mirsky
    Sent: Friday, March 11, 2011 9:14 PM
    To: Luca Martini
    Cc: lihan@chinamobile.com<mailto:lihan@chinamobile.com>; mpls@ietf.org<mailto:mpls@ietf.org>; pwe3; HUANG Feng F; mpls-tp@ietf.org<mailto:mpls-tp@ietf.org>
    Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

    Dea= r Luca,
    thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my attenti= on. I'll send my comments to it in a separate e-mail.
    I'll have = to miss another opportunity to discuss your proposal in a meeting. Please a= dd my comments below to my earlier expressed WG LC comments:

    =A0* =A0 the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution= that addresses applicability of GAL in PW VCCV, e.g. solution proposed in = draft-nadeau-pwe3-vccv-2-01;
    =A0* =A0 the draft-lm-pwe3-mpls-tp-gal-in-p= w-00 needs to mention such dependency and refer to any existing proposal; =A0* =A0 I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be advan= ced in lock with document that addresses use of GAL in PW VCCV.
    Regards,=
    Greg
    On Fri, Mar 11, 2011 at 5:31 AM, Luca Martini <lmartini@cisco.com<mailto:lmartini@cisco.com>> wrote:
    Greg ,
    Some

    On 02/18/11 11:15, Greg Mirsky wrote:
    > Dear Lu= ca,
    > I see at least two issues:
    >
    > =A0 =A0 * use of GAL= for PW, in my view, is another VCCV CC type that has
    > =A0 =A0 =A0 t= o be negotiated as described in RFC 5085.
    >
    These are valid points, but this document in question does not defi= ne,
    not discussed VCCV.
    We have since posted a draft that proposes a = new VCCV mode , and we
    welcome comments regarding that document.
    (draft-nadeau-pwe3-vccv-2-01.txt)

    > =A0 =A0 * use of GAL creates = ambiguous situation when PW CW is used. The
    > =A0 =A0 =A0 benefit fro= m extending GAL in PW, as I see, is for PWs that are
    > =A0 =A0 =A0 no= t required to use PW CW. That might be a good enough reason to
    > =A0 =A0 =A0 update RFC 5586 as proposed in the document but we must ad= dress
    > =A0 =A0 =A0 use cases of GAL in PWs that require presence PW = CW. If we
    > =A0 =A0 =A0 prohibit or even discourage use of GAL for th= ese PWs that have
    > =A0 =A0 =A0 PW VCCV as native Associated Channel, then architecture of= ACh
    > =A0 =A0 =A0 for MPLS-TP PW not simplified as result of adoptin= g the proposal.
    >
    > Regard
    Greg,
    The GAL is basically a n= otifier that the packet following the end of the
    MPLS label stack, is explicitly defined as a G-ACH format.
    Normally the = packet would be decoded as an IP packet , unless the last
    label on the s= tack indicated otherwise.

    The GAL can certainly be applied =A0to a P= W OAM packet on a PW that uses
    the CW, and this document does not define that , nor restricts it.

    T= he scope of this document is limited to removing an unnecessary
    restrict= ion in rfc5586, hence =A0this comment not applicable to this document.

    Thanks.
    Luca

    > s,
    > Greg
    >
    > On Fri, Feb= 18, 2011 at 7:46 AM, Luca Martini <lmartini@cisco.com<mailto:lm= artini@cisco.com>
    > <mailto:lmartini@cisco.com    <mailto:lmartini@cisco.com>= ;>> wrote:
    >
    > =A0 =A0 Greg,
    >
    > =A0 =A0 Sorr= y, but I do not remember the point you mention.
    > =A0 =A0 Can you explain again here ?
    > =A0 =A0 Thanks.
    > = =A0 =A0 Luca
    >
    >
    > =A0 =A0 On 02/17/11 23:47, Greg Mirsky= wrote:
    > =A0 =A0 > Dear Authors and All,
    > =A0 =A0 > pri= or to the meeting in Bejing and acceptance of this proposal as WG
    > =A0 =A0 > document Luca and I agreed that use of GAL with PW VCCV p= resents a
    > =A0 =A0 > problem.
    > =A0 =A0 > I was not atte= nding the IETF-79, nor I found discussion of this
    > =A0 =A0 issue
    = > =A0 =A0 > in the minutes. I think that this issue should be specifi= ed,
    > =A0 =A0 > explained. In my view, this document updates not only RFC= 5586
    > =A0 =A0 > but RFC 5085 too.
    > =A0 =A0 >
    > = =A0 =A0 > Regards,
    > =A0 =A0 > Greg
    > =A0 =A0 >
    >= ; =A0 =A0 > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt
    > =A0 =A0 >
    > =A0 =A0 > On Sat, Oct 30, 2010 at 10:14 AM, Lu= ca Martini
    > =A0 =A0 <lmarti= ni@cisco.com<mailto:lmartini@c= isco.com> <mailto:lmartini@= cisco.com<mailto:lmartini@cisc= o.com>>
    > =A0 =A0 > <mailto:lmartini= @cisco.com<mailto:lmartini@cis= co.com> <mailto:lmartini@ci= sco.com<mailto:lmartini@cisco.= com>>>> wrote:
    > =A0 =A0 >
    > =A0 =A0 > =A0 =A0 Greg,
    > =A0 =A0 >> =A0 =A0 > =A0 =A0 You are correct , the proposed update does not = propose any
    > =A0 =A0 changes
    > =A0 =A0 > =A0 =A0 to VCCV.> =A0 =A0 > =A0 =A0 However the problem with vccv is not as simple = as to ask for
    > =A0 =A0 a new
    > =A0 =A0 > =A0 =A0 code point from IANA.
    &g= t; =A0 =A0 > =A0 =A0 Given the good amount of discussion on this point, = we should
    > =A0 =A0 > =A0 =A0 probably have a discussion in Beijin= g.
    > =A0 =A0 >
    > =A0 =A0 > =A0 =A0 Luca
    > =A0 =A0 >
    > =A0 =A0 >
    > =A0 =A0 >
    > =A0 =A0= > =A0 =A0 On 10/29/2010 05:07 PM, Greg Mirsky wrote:
    > =A0 =A0 &g= t;> =A0 =A0 Dear Authors,
    > =A0 =A0 >> =A0 =A0 I think that = proposed update of the Section 4.2. RFC 5586
    > =A0 =A0 makes it possible
    > =A0 =A0 >> =A0 =A0 to use GAL = on MPLS-TP PW that uses Control Word. I consider
    > =A0 =A0 it to be> =A0 =A0 >> =A0 =A0 conflict between PW VCCV CC types because u= se of GAL is not
    > =A0 =A0 negotiated
    > =A0 =A0 >> =A0 =A0 through PW VCCV ne= gotiation. To avoid such situation I propose:
    > =A0 =A0 >>
    &= gt; =A0 =A0 >> =A0 =A0 =A0 =A0- in Section 5 request IANA to assign n= ew CC Type "MPLS
    > =A0 =A0 Generic
    > =A0 =A0 >> =A0 =A0 =A0 =A0Associated Cha= nnel Label"
    > =A0 =A0 >> =A0 =A0 =A0 =A0- assign precedenc= e to new CC Type that affects Section
    > =A0 =A0 7 RFC 5085
    > = =A0 =A0 >>
    > =A0 =A0 >> =A0 =A0 Regards,
    > =A0 =A0 >> =A0 =A0 Greg
    > =A0 =A0 >>
    > =A0 =A0= >>
    > =A0 =A0 >>
    --00151759367093e25f049e54e566-- From larryli888@yahoo.com.cn Sun Mar 13 03:11:31 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E1653A6AB8 for ; Sun, 13 Mar 2011 03:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 JA4BPrrMktMj for ; Sun, 13 Mar 2011 03:11:30 -0700 (PDT) Received: from web15608.mail.cnb.yahoo.com (web15608.mail.cnb.yahoo.com [202.165.102.62]) by core3.amsl.com (Postfix) with SMTP id BF0F53A695C for ; Sun, 13 Mar 2011 03:11:29 -0700 (PDT) Received: (qmail 43231 invoked by uid 60001); 13 Mar 2011 10:12:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1300011167; bh=o8pYG2QwktaGg2OzFDOrc8shhMUrVW5OUTgUuMc3Ghg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GADpLwJ/VoiP9+bGtltAF5dhguH/TnN3XNHJCBuJcsXjyRQb9E07pcyvTyOJCtHBooLrJ75VuBAWByadTUtB2/+zmtB14A2IxziycwOg8cFW/DDs2uyYbPOIxbQTvfXwKdc3sDuloHczkY6RAQsGvYwn0j6/9mmbm2Xogw5uKHc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jwwheYgCdJvNn/DxPYNIB2+VwrGACsD+xxAJEWIhX32w5nZRdf6GkKgLfk0cy35A6OEPGLkgEpVZ8ivehNnhPpHBPkB883o5CIWrqcAKxdTpCyUQNGYD3xOVuyWN+Vl/pOBYGPjav5IsZJz3W6i6Wg3GDXtc6li/BPCr5Pfo2VU=; Message-ID: <694098.42970.qm@web15608.mail.cnb.yahoo.com> X-YMail-OSG: qAcni8kVM1nxDVF5DNAPjIeiQI9.Gv3N_KY9uZ81k4s5OFe nWbJe6OTPju_tpjxyDY5S5aoyyIfZO7pJ8KbZcre_8MCx.NYsto7MRKvcvhd MGItMlMhoJ2PXGGExqMgAVGKGc.5zxpstZlt9KyZRS3xSP8bBwTUy8br49nq Q8zBD9PNWOqi.Inz3zqstUpGnk2gfUUOLM4jnvbuTi5NkByQSVfJ06sTJ8uh pmEvqJYzPVkwZTB0V0BhQTA4R_v6LeSrN7h2q6SaAFhhTOxP8.PiqLB7kSQa yng-- Received: from [117.136.0.165] by web15608.mail.cnb.yahoo.com via HTTP; Sun, 13 Mar 2011 18:12:47 CST X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.295617 Date: Sun, 13 Mar 2011 18:12:47 +0800 (CST) From: Larry To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 10:11:31 -0000 Support! I think the cooperation mode of allocating the Ethertype to Y.1731 provides= a good example. Best regards, Han Li ************************************************************************* Han Li, Ph.D=20 China Mobile Research Institute Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China=20 Fax: +86 10 63601087=20 MOBILE: 13501093385=20 ************************************************************************* > -----Original Message----- > From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On Behal= f Of > Rui Costa > Sent: 11 March 2011 03:32 > To: mpls at ietf.org > Subject: [mpls] draft-tsb-mpls-tp-ach-ptn >=20 > Hello, >=20 > The draft provided by the TSB draft-tsb-mpls-tp-ach-ptn requests the > allocation of an Associated Channel Type value that will allow ITU-T to > develop OAM tools required to address the needs identified by some ITU- > T members. Allocation of this value will make more efficient use of > resources of both IETF and ITU-T. The use of this associated channel > type fully complies with the framework and architecture for MPLS-TP. >=20 >=20 > The draft also describes the cases where networks that run the ITU > defined OAM tools are interconnected to networks that run the IETF > defined OAM tools. In most cases it is a client/server relationship and > no interworking is required. If a LSP or PW originates in one domain > and terminates in the other domain then the IETF OAM tools must be > used. >=20 > This draft should be discussed in Prague. >=20 > Best Regards, > Rui >=20 > _______________________________________________ > mpls mailing list > mpls at ietf.org > https://www.ietf.org/mailman/listinfo/mpls =0A=0A=0A From Internet-Drafts@ietf.org Sun Mar 13 11:00:04 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24F613A6A1A; Sun, 13 Mar 2011 11:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, 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 W0yV5RfzfYPI; Sun, 13 Mar 2011 11:00:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B7A3A6A19; Sun, 13 Mar 2011 11:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110313180002.12321.92801.idtracker@localhost> Date: Sun, 13 Mar 2011 11:00:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 18:00:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions Using LSP Ping Author(s) : E. Bellagamba, et al. Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-01.txt Pages : 20 Date : 2011-03-13 This specification describes the configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that is carried on LSP Ping. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-13105511.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Sun Mar 13 12:30:03 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57473A6A5C; Sun, 13 Mar 2011 12:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, 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 F47LKpZSRlp9; Sun, 13 Mar 2011 12:30:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB86E3A6B6C; Sun, 13 Mar 2011 12:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110313193001.32735.10451.idtracker@localhost> Date: Sun, 13 Mar 2011 12:30:01 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-linear-protection-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 19:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS-TP Linear Protection Author(s) : S. Bryant, et al. Filename : draft-ietf-mpls-tp-linear-protection-05.txt Pages : 38 Date : 2011-03-13 The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is being specified jointly by IETF and ITU-T. This document addresses the functionality described in the MPLS-TP Survivability Framework document [SurvivFwk] and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-linear-protection-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-linear-protection-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-13122453.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Sun Mar 13 12:45:05 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A483A69A3; Sun, 13 Mar 2011 12:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, 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 Cf-ydROliQIQ; Sun, 13 Mar 2011 12:45:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651383A6A65; Sun, 13 Mar 2011 12:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110313194502.5334.55573.idtracker@localhost> Date: Sun, 13 Mar 2011 12:45:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-linear-protection-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 19:45:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS-TP Linear Protection Author(s) : S. Bryant, et al. Filename : draft-ietf-mpls-tp-linear-protection-06.txt Pages : 38 Date : 2011-03-13 The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is being specified jointly by IETF and ITU-T. This document addresses the functionality described in the MPLS-TP Survivability Framework document [SurvivFwk] and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-linear-protection-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-linear-protection-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-13123935.I-D@ietf.org> --NextPart-- From ben@niven-jenkins.co.uk Sun Mar 13 14:18:51 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACA393A6BA7 for ; Sun, 13 Mar 2011 14:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.592 X-Spam-Level: X-Spam-Status: No, score=-103.592 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, 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 XE5PJS1-WlKw for ; Sun, 13 Mar 2011 14:18:50 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id B29663A65A6 for ; Sun, 13 Mar 2011 14:18:50 -0700 (PDT) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.202]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Pyshw-0004ml-1R for mpls@ietf.org; Sun, 13 Mar 2011 21:20:12 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Ben Niven-Jenkins In-Reply-To: <4D7C32E9.9010203@pi.nu> Date: Sun, 13 Mar 2011 21:20:10 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <911BF6EB-704B-48F9-BA3C-57D656E9B1C5@niven-jenkins.co.uk> References: <4D7C32E9.9010203@pi.nu> To: mpls@ietf.org X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Subject: Re: [mpls] working group last call on draft-ietf-mpls-mp-ldp-reqs-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 21:18:51 -0000 Loa, On 13 Mar 2011, at 02:58, Loa Andersson wrote: > Working Group, >=20 > This is to start a wg last call on publishing > draft-ietf-mpls-mp-ldp-reqs-06 as an Informational RFC with > Historic status. ... > This working group does primarily not ask for comments on the actual > text; but opinions on and support for publication as historic. I don't have a strong opinion on whether draft-ietf-mpls-mp-ldp-reqs = should be published as an RFC or left to expire although publishing it = as an RFC probably makes it easier to find for anyone interested in some = of the motivation behind MLDP. If it is published Infomrational+Historic = seems the most appropriate way to categorise it IMO. Ben From Internet-Drafts@ietf.org Sun Mar 13 15:00:04 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079823A6BB8; Sun, 13 Mar 2011 15:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, 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 cFlMyRrNMO1A; Sun, 13 Mar 2011 15:00:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15F33A6944; Sun, 13 Mar 2011 15:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110313220001.8637.10850.idtracker@localhost> Date: Sun, 13 Mar 2011 15:00:01 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-ldp-ipv6-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 22:00:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Updates to LDP for IPv6 Author(s) : V. Manral, et al. Filename : draft-ietf-mpls-ldp-ipv6-01.txt Pages : 12 Date : 2011-03-13 The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4 or IPv6 or both networks. This document corrects and clarifies the LDP behavior when IPv6 network is used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ipv6-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-ipv6-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-13145610.I-D@ietf.org> --NextPart-- From ruiquan.jing@ties.itu.int Sun Mar 13 17:33:37 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AA0E3A6A46 for ; Sun, 13 Mar 2011 17:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 lSd3NId2byce for ; Sun, 13 Mar 2011 17:33:36 -0700 (PDT) Received: from mail.ctbri.com.cn (mail.ctbri.com.cn [219.142.69.47]) by core3.amsl.com (Postfix) with ESMTP id 3FDFD3A6A34 for ; Sun, 13 Mar 2011 17:33:36 -0700 (PDT) Received: from ctbrijingrq ([10.9.53.112]) by mail.ctbri.com.cn (Lotus Domino Release 8.0.2FP5) with ESMTP id 2011031408345163-95128 ; Mon, 14 Mar 2011 08:34:51 +0800 From: "Jingrq" To: "'Rui Costa'" , References: <52981DB05D3C5247A12D0AEE309F3CC201EB24B1CBBC@INOAVREX11.ptin.corpPT.com> Date: Mon, 14 Mar 2011 08:34:56 +0800 Message-ID: <728AC2C738D94E14A2BF3712773FCD56@ctbrijingrq> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcvfnOeVV3ZPtvhwS+WvdnOPEqon7QCQkvXw In-Reply-To: <52981DB05D3C5247A12D0AEE309F3CC201EB24B1CBBC@INOAVREX11.ptin.corpPT.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-MIMETrack: Itemize by SMTP Server on mailserver/ctbri(Release 8.0.2FP5|April 13, 2010) at 2011-03-14 08:34:51, Serialize by Router on mailserver/ctbri(Release 8.0.2FP5|April 13, 2010) at 2011-03-14 08:34:59, Serialize complete at 2011-03-14 08:34:59 X-TNEFEvaluated: 1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="gb2312" Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 00:33:37 -0000 Hi Rui, I support your proposal. It will good to both IETF and ITU-T if the Associated Channel Type is allocated. Best regards=20 =20 Ruiquan=A3=A8Rick=A3=A9 Jing=20 China Telecom CTBRI > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Rui Costa > Sent: Friday, March 11, 2011 11:32 AM > To: mpls@ietf.org > Subject: [mpls] draft-tsb-mpls-tp-ach-ptn >=20 > Hello,=09 >=20 > The draft provided by the TSB draft-tsb-mpls-tp-ach-ptn=20 > requests the allocation of an Associated Channel Type value=20 > that will allow ITU-T to develop OAM tools required to=20 > address the needs identified by some ITU-T members.=20 > Allocation of this value will make more efficient use of=20 > resources of both IETF and ITU-T. The use of this associated=20 > channel type fully complies with the framework and=20 > architecture for MPLS-TP.=09 >=20 > The draft also describes the cases where networks that run=20 > the ITU defined OAM tools are interconnected to networks that=20 > run the IETF defined OAM tools. In most cases it is a=20 > client/server relationship and no interworking is required.=20 > If a LSP or PW originates in one domain and terminates in the=20 > other domain then the IETF OAM tools must be used.=09 >=20 > This draft should be discussed in Prague.=09 >=20 > Best Regards,=09 > Rui >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From curtis@occnc.com Sun Mar 13 19:58:29 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1813A6C32 for ; Sun, 13 Mar 2011 19:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 D2fcav5pilX2 for ; Sun, 13 Mar 2011 19:58:28 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 2E9303A6C30 for ; Sun, 13 Mar 2011 19:58:28 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p2E2xnAG028291; Sun, 13 Mar 2011 22:59:49 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201103140259.p2E2xnAG028291@harbor.orleans.occnc.com> To: Alexander Vainshtein From: Curtis Villamizar In-reply-to: Your message of "Wed, 09 Mar 2011 15:03:12 +0200." Date: Sun, 13 Mar 2011 22:59:49 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , "Zhao, Peng \(NSN - CN/Shanghai\)" , "Pietilainen, Antti \(NSN - FI/Espoo\)" , "Mallette, Edwin" , "stbryant@cisco.com" Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 02:58:29 -0000 In message Alexander Vainshtein writes: > > Curtis, > Lots of thanks for a prompt and delayed response. > > Please see some comments inline below. I've shipped the next that is not related to these comments. > > Regards, > Sasha > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Wednesday, March 09, 2011 2:06 AM > > To: Alexander Vainshtein > > Cc: curtis@occnc.com; mpls@ietf.org; Zhao, Peng (NSN - CN/Shanghai); > > Pietilainen, Antti (NSN - FI/Espoo); tictoc@ietf.org; > > stbryant@cisco.com; Mallette, Edwin > > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp > > > --- snipped --- > > > 2. The "timestamp capture point in the data path" was not about the > > > timestamp location in the message. It is about the stage of the data > > > processing when the timestamp can be captured. E.g., some designs use > > > commercial HW that captures the timestamps between PHY and MAC. This > > > is OK for PTP and NTP, but excludes the time spent in the egress > > queue > > > of the node from delay measurement. > > > > That is why in NTP, PTP, and draft-ietf-mpls-loss-delay there are four > > timestamps. The total round trip delay subtracts the third and second > > to eliminate queuing and turn around. > [[[Sasha]]] Please consider the following use case: > - I am going to use a certain LSP as a tunnel for TDM PWs > - I would like to measure packet delay *variation* (PDV) introduced by > this LSP in order to configure the jitter buffer of these TDM PWs. I > expect to do that by measuring delay for multiple samples and > computing the PDV as (Max. measured delay - Min. measured delay) > - If queuing delay at the LSP head- and tail-nodes is not accounted in > my delay measurements, my PDV estimation will not account for that > also (because queuing only increases Max. measured delay) > - As a consequence, my PDV estimation may be not suitable for > configuring the jitter buffer correctly. As a consequence, my TDM > customers will see errors in their traffic when TDM PW packets that > arrive too late to be accommodated into the jitter buffer are > discarded and their payload replaced with "all ones". > Do I miss something here? I would say yeah sort of. This is slightly out of scope of the draft which is measuring the delay of the segment or LSP. If you took that delay (which is a minimum delay) and used it to set jitter buffers, you'd have very unhappy customers. Jitter buffers are normally set by measuring the delay experienced by the service and adding a generous safety margin based on estimate of std dev. Again, this is a usage (that you envision and that I don't share) but the usage is out of scope regarding discussion of the draft itself. > > > 3. You have said that 20 microseconds look to you as very good > > > accuracy for delay measurements. This probably depends on the > > > application. E.g., if we must synchronize two base stations within 2- > > 3 > > > microseconds of relative ToD error, this accuracy will hardly help > > you > > > to understand why your synchronization mechanisms do not work:-). I > > > am somewhat suspicious about a measurement procedure that does not > > > specify accuracy explicitly. But I understand the position taken by > > > the draft authors. > > > > 20 usec is OK for draft-ietf-mpls-loss-delay type measurements. > [[[Sasha]]] I would be happy to accept that. But the draft does not > yield this (or any other) number. You snipped something important here. I was enumerating the timestamp formats and mentioned that the NTP 32 bit format would be more than adequate for most delay measurements. Later (snipped below) I mention that draft-ietf-mpls-loss-delay puts any timestamp format into 64 bits so there is no sense in using the 32 bit format. It is extremely difficult to know the accuracy (with any accuracy :). It depends on the accuracy of time synchronization which may not be known. > --- snipped to the end --- From hffellow@hotmail.com Sun Mar 13 20:17:52 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0143A6C0D; Sun, 13 Mar 2011 20:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.848 X-Spam-Level: * X-Spam-Status: No, score=1.848 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396] 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 BPPV597yg-hA; Sun, 13 Mar 2011 20:17:50 -0700 (PDT) Received: from blu0-omc2-s7.blu0.hotmail.com (blu0-omc2-s7.blu0.hotmail.com [65.55.111.82]) by core3.amsl.com (Postfix) with ESMTP id 97C8C3A6AB7; Sun, 13 Mar 2011 20:17:50 -0700 (PDT) Received: from BLU0-SMTP161 ([65.55.111.71]) by blu0-omc2-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Mar 2011 20:19:13 -0700 X-Originating-IP: [112.64.190.32] X-Originating-Email: [hffellow@hotmail.com] Message-ID: Received: from [172.18.10.66] ([112.64.190.32]) by BLU0-SMTP161.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Mar 2011 20:19:00 -0700 References: In-Reply-To: MIME-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="Apple-Mail-1--356993280" X-Mailer: iPhone Mail (8C148) From: Huang Feng Date: Mon, 14 Mar 2011 11:18:56 +0800 To: Lamberto Sterling X-OriginalArrivalTime: 14 Mar 2011 03:19:09.0374 (UTC) FILETIME=[955485E0:01CBE1F6] Cc: "mpls@ietf.org" , "Alexander.Vainshtein@ecitele.com" , "mpls-tp@ietf.org" , "lihan@chinamobile.com" , pwe3 , HUANG Feng F Subject: Re: [mpls] [PWE3] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 03:17:52 -0000 --Apple-Mail-1--356993280 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="GB2312" Support GAL both in LSP and PW=A3=ACcommon HW can be used, it save cost. BR Feng =D4=DA 2011-3-13=A3=AC11:36=A3=ACLamberto Sterling =D0=B4=B5=C0=A3=BA > Hi all, > I do not see the benefit that GAL in PW can bring while current three CC t= ype does not own. If there is no agreed benefit, why we add overload to the i= ndurstry (more HW design), and complexity to the interoperability by ourself= ? When IETF refuse draft-bhh-1731 as OAM tool for MPLS-TP, the reason is aga= in interoperability and indurstry HW cost, and personally agree with that. > =20 > Lamberto >=20 > =20 > ------------------------------ >=20 > Date: Sat, 12 Mar 2011 06:44:47 +0200 > From: Alexander Vainshtein > Subject: Re: [PWE3] [mpls] WG LC > draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > To: venkatesan mahalingam , "mpls@ietf.org" > > Cc: Luca Martini , "mpls-tp@ietf.org" > , "lihan@chinamobile.com" , > pwe3 , HUANG Feng F > Message-ID: > = > Content-Type: text/plain; charset=3D"windows-1252" >=20 > Venkat, >=20 > You have asked "Are we implicitly mandating the CW (ACH) in HW by configur= ing/negotiating the CC type-4?" >=20 > IMO the answer is "No". > In VCCV Type 1 the first nibble of the CW is a data path (HW if you wish) e= xception mechanism forwarding the packets to an OAM entity. >=20 > In VCCV Type 4 GAL acts as such an exception mechanism. ACH is actually on= ly needed to decide on the ACH Type. And it would not even be examined if th= e TTL in the PW label has not expired. >=20 > My 2c, > Sasha >=20 >=20 >=20 > ________________________________ > From: venkatesan mahalingam [venkatflex@gmail.com] > Sent: Friday, March 11, 2011 10:12 PM > To: Alexander Vainshtein; Greg Mirsky; Luca Martini; lihan@chinamobile.com= ; mpls-tp@ietf.org; pwe3; HUANG Feng F; mpls@ietf.org > Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt >=20 > Hi, > AFAIK, ACH can't be used without supporting the CW in HW. >=20 > As per RFC-5085, 5.1.1. In-Band VCCV (Type 1) > CC Type-1 mode of VCCV operation MUST be supported when the control word i= s present. >=20 > It looks to me that CC type-1 for ACH without GAL and CC type-4 for ACH wi= th GAL. >=20 > IMO, if we support CC type-4, CC type-1 support is implicitly attained. >=20 > IMHO, it should be possible to get the MPLS-TP OAM control packets with or= without GAL from HW to CP by negotiating CC type-1 itself. >=20 > Some editorial comments for the draft-nadeau-pwe3-vccv-2-01.txt draft, > " > 4.1.1. MPLS VCCV Control Channel (CC) Type 4 >=20 > IANA is requested to augment the registry of "MPLS VCCV Control > Channel Types" with the new type defined below. As defined in > RFC5058, this new bitfield is to be assigned by IANA using > " > Replace the RFC5058 as RFC5085. >=20 > Thanks, > Venkat. >=20 > On Fri, Mar 11, 2011 at 2:21 PM, Alexander Vainshtein > wrote: > Greg, Luca, > As I?ve already stated in my comment on draft-nadeau-pwe3-vccv-2, IMHO it m= akes draft-lm-pwe3-mpls-tp-gal-in-pw completely useless. >=20 > My 2c, > Sasha >=20 > From: mpls-bounces@ietf.org [mailto:mpls-bou= nces@ietf.org] On Behalf Of Greg Mirsky > Sent: Friday, March 11, 2011 9:14 PM > To: Luca Martini > Cc: lihan@chinamobile.com; mpls@ietf.org; pwe3; HUANG Feng F; mpls-tp@ietf.org > Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt >=20 > Dear Luca, > thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my attention. I'll s= end my comments to it in a separate e-mail. > I'll have to miss another opportunity to discuss your proposal in a meetin= g. Please add my comments below to my earlier expressed WG LC comments: >=20 > * the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution that a= ddresses applicability of GAL in PW VCCV, e.g. solution proposed in draft-na= deau-pwe3-vccv-2-01; > * the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs to mention such dependen= cy and refer to any existing proposal; > * I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be advanced= in lock with document that addresses use of GAL in PW VCCV. > Regards, > Greg > On Fri, Mar 11, 2011 at 5:31 AM, Luca Martini > wrote: > Greg , > Some >=20 > On 02/18/11 11:15, Greg Mirsky wrote: > > Dear Luca, > > I see at least two issues: > > > > * use of GAL for PW, in my view, is another VCCV CC type that has > > to be negotiated as described in RFC 5085. > > > These are valid points, but this document in question does not define, > not discussed VCCV. > We have since posted a draft that proposes a new VCCV mode , and we > welcome comments regarding that document. > (draft-nadeau-pwe3-vccv-2-01.txt) >=20 > > * use of GAL creates ambiguous situation when PW CW is used. The > > benefit from extending GAL in PW, as I see, is for PWs that are > > not required to use PW CW. That might be a good enough reason to > > update RFC 5586 as proposed in the document but we must address > > use cases of GAL in PWs that require presence PW CW. If we > > prohibit or even discourage use of GAL for these PWs that have > > PW VCCV as native Associated Channel, then architecture of ACh > > for MPLS-TP PW not simplified as result of adopting the proposal. > > > > Regard > Greg, > The GAL is basically a notifier that the packet following the end of the > MPLS label stack, is explicitly defined as a G-ACH format. > Normally the packet would be decoded as an IP packet , unless the last > label on the stack indicated otherwise. >=20 > The GAL can certainly be applied to a PW OAM packet on a PW that uses > the CW, and this document does not define that , nor restricts it. >=20 > The scope of this document is limited to removing an unnecessary > restriction in rfc5586, hence this comment not applicable to this documen= t. >=20 > Thanks. > Luca >=20 > > s, > > Greg > > > > On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini > > >> wrote: > > > > Greg, > > > > Sorry, but I do not remember the point you mention. > > Can you explain again here ? > > Thanks. > > Luca > > > > > > On 02/17/11 23:47, Greg Mirsky wrote: > > > Dear Authors and All, > > > prior to the meeting in Bejing and acceptance of this proposal as W= G > > > document Luca and I agreed that use of GAL with PW VCCV presents a= > > > problem. > > > I was not attending the IETF-79, nor I found discussion of this > > issue > > > in the minutes. I think that this issue should be specified, > > > explained. In my view, this document updates not only RFC 5586 > > > but RFC 5085 too. > > > > > > Regards, > > > Greg > > > > > > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > > > > > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > > > > > > >>> wrote: > > > > > > Greg, > > > > > > You are correct , the proposed update does not propose any > > changes > > > to VCCV. > > > However the problem with vccv is not as simple as to ask for > > a new > > > code point from IANA. > > > Given the good amount of discussion on this point, we should > > > probably have a discussion in Beijing. > > > > > > Luca > > > > > > > > > > > > On 10/29/2010 05:07 PM, Greg Mirsky wrote: > > >> Dear Authors, > > >> I think that proposed update of the Section 4.2. RFC 5586 > > makes it possible > > >> to use GAL on MPLS-TP PW that uses Control Word. I consider > > it to be > > >> conflict between PW VCCV CC types because use of GAL is not > > negotiated > > >> through PW VCCV negotiation. To avoid such situation I propos= e: > > >> > > >> - in Section 5 request IANA to assign new CC Type "MPLS > > Generic > > >> Associated Channel Label" > > >> - assign precedence to new CC Type that affects Section > > 7 RFC 5085 > > >> > > >> Regards, > > >> Greg > > >> > > >> > > >> > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail-1--356993280 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
    Support GAL both in LSP and PW=EF=BC=8C= common HW can be used, it save cost.

    BR
    = Feng

    =E5=9C=A8 2011-3-13=EF=BC=8C11:36=EF=BC=8CLamberto= Sterling <lamberto.sterli= ng@gmail.com> =E5=86=99=E9=81=93=EF=BC=9A

    Hi all,
    I do not see the benefit that GAL in PW can bring while current three C= C type does not own. If there is no agreed benefit, why we add overload to t= he indurstry (more HW design), and complexity to the interoperability by our= self? When IETF refuse draft-bhh-1731 as OAM tool for MPLS-TP, the reason is= again interoperability and indurstry HW cost, and personally agree with tha= t.
     
    Lamberto

     
    ------------------------------
    =
    Date: Sat, 12 Mar 2011 06:44:47 +0200
    From: Alexander Vainshtein <= Alexander.Vainshtein@ecitele.com>
    = Subject: Re: [PWE3] [mpls] WG LC
           draft-lm-pwe3= -mpls-tp-gal-in-pw-00.txt
    To: venkatesan mahalingam <venkatflex@gm= ail.com>, "mpls@ietf.org"
           <mpls@ietf.org>
    Cc: Luca Martini <lmart= ini@cisco.com>, "mpls-tp@ietf.org"
           <mpls-tp@ietf.org>,     "lihan@chinamobile.com" <lihan@chinamobile.com>,=
           pwe3 <pwe3@ietf.org>,   HUANG Feng F <= ;Feng.f.Huang@alcatel-sbell.com.cn>=
    Message-ID:
           <A3C5DF08= D38B6049839A6F553B331C76D6FB8BEAB3@ILPTMAIL02.ecitele.com>
    Content-Type: text/plain; charset=3D"windows-1252"

    Venkat,

    You= have asked "Are we implicitly mandating the CW (ACH) in HW by configuring/n= egotiating the CC type-4?"

    IMO the answer is "No".
    In VCCV Type 1 the first nibble of the CW is a data path (HW if you wish) ex= ception mechanism forwarding the packets to an OAM entity.

    In VCCV Ty= pe 4 GAL acts as such an exception mechanism. ACH is actually only needed to= decide on the ACH Type. And it would not even be examined if the TTL in the= PW label has not expired.

    My 2c,
        Sasha



    ___________________________= _____
    From: venkatesan mahalingam [venkatflex@gmail.com]
    S= ent: Friday, March 11, 2011 10:12 PM
    To: Alexander Vainshtein; Greg Mirsk= y; Luca Martini; lihan@chinamobile.com; mpls-tp@ietf.org; p= we3; HUANG Feng F; mpls@ietf.org
    Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

    Hi,<= br>AFAIK, ACH can't be used without supporting the CW in HW.

    As per R= FC-5085, 5.1.1.  In-Band VCCV (Type 1)
    CC Type-1 mode of VCCV operat= ion MUST be supported when the control word is present.

    It looks to me that CC type-1 for ACH without GAL and CC type-4 for ACH w= ith GAL.

    IMO, if we support CC type-4, CC type-1 support is implicitl= y attained.

    IMHO, it should be possible to get the MPLS-TP OAM contro= l packets with or without GAL from HW to CP by negotiating CC type-1 itself.=

    Some editorial comments for the draft-nadeau-pwe3-vccv-2-01.txt draft,"
    4.1.1.  MPLS VCCV Control Channel (CC) Type 4

      IANA= is requested to augment the registry of "MPLS VCCV Control
      Channe= l Types" with the new type defined below. As defined in
      RFC5058, this new bitfield is to be assigned by IANA using
    "
    Re= place the RFC5058 as RFC5085.

    Thanks,
    Venkat.

    On Fri, Mar 1= 1, 2011 at 2:21 PM, Alexander Vainshtein <Ale= xander.Vainshtein@ecitele.com<mailto:= Alexander.Vainshtein@ecitele.com>> wrote:
    Greg, Luca,
    As I?ve already stated in my comment on draft-nadeau-pwe3-vcc= v-2, IMHO it makes draft-lm-pwe3-mpls-tp-gal-in-pw completely useless.
    My 2c,
        Sasha

    From: mpls-bounces@ietf.org= <mailto:mpls-bounces@ietf.org> [mailto:mpls-bo= unces@ietf.org<mailto:mpls-bounces@ietf.org>] On= Behalf Of Greg Mirsky
    Sent: Friday, March 11, 2011 9:14 PM
    To: Luca Martini
    Cc: lihan@= chinamobile.com<mailto:<= a href=3D"mailto:lihan@chinamobile.com">lihan@chinamobile.com>; <= a href=3D"mailto:mpls@ietf.org">mpls@ietf.o= rg<mailto:mpls@ietf.org>; pwe3; HUANG Feng F; mpls-tp@ietf.org<mailto:mpls-tp@ietf.org>
    Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

    Dear= Luca,
    thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my attention= . I'll send my comments to it in a separate e-mail.
    I'll have to miss ano= ther opportunity to discuss your proposal in a meeting. Please add my commen= ts below to my earlier expressed WG LC comments:

     *   the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any sol= ution that addresses applicability of GAL in PW VCCV, e.g. solution proposed= in draft-nadeau-pwe3-vccv-2-01;
     *   the draft-lm-pwe3-mpls-tp= -gal-in-pw-00 needs to mention such dependency and refer to any existing pro= posal;
     *   I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be a= dvanced in lock with document that addresses use of GAL in PW VCCV.
    Regar= ds,
    Greg
    On Fri, Mar 11, 2011 at 5:31 AM, Luca Martini <lmartini@ci= sco.com<mailto:lmartini@cisco.com>> wrote:
    Greg ,
    Some

    On 02/18/11 11:15, Greg Mirsky wrote:
    > Dear Luc= a,
    > I see at least two issues:
    >
    >     * use of= GAL for PW, in my view, is another VCCV CC type that has
    >   &nb= sp;   to be negotiated as described in RFC 5085.
    >
    These are valid points, but this document in question does not defin= e,
    not discussed VCCV.
    We have since posted a draft that proposes a ne= w VCCV mode , and we
    welcome comments regarding that document.
    (draft-nadeau-pwe3-vccv-2-01.txt)

    >     * use of GAL cre= ates ambiguous situation when PW CW is used. The
    >      = ; benefit from extending GAL in PW, as I see, is for PWs that are
    > &n= bsp;     not required to use PW CW. That might be a good enough re= ason to
    >       update RFC 5586 as proposed in the document but we= must address
    >       use cases of GAL in PWs that requ= ire presence PW CW. If we
    >       prohibit or even disc= ourage use of GAL for these PWs that have
    >       PW VCCV as native Associated Channel, then archite= cture of ACh
    >       for MPLS-TP PW not simplified as r= esult of adopting the proposal.
    >
    > Regard
    Greg,
    The GAL i= s basically a notifier that the packet following the end of the
    MPLS label stack, is explicitly defined as a G-ACH format.
    Normally the p= acket would be decoded as an IP packet , unless the last
    label on the sta= ck indicated otherwise.

    The GAL can certainly be applied  to a P= W OAM packet on a PW that uses
    the CW, and this document does not define that , nor restricts it.

    Th= e scope of this document is limited to removing an unnecessary
    restrictio= n in rfc5586, hence  this comment not applicable to this document.

    Thanks.
    Luca

    > s,
    > Greg
    >
    > On Fri, Feb 1= 8, 2011 at 7:46 AM, Luca Martini <<= a href=3D"mailto:lmartini@cisco.com">lmartini@cisco.com<mailto:lm= artini@cisco.com>
    > <mailto:lmartini@cisco.com<mailto:lmartini@cisco.com<= /a>>>> wrote:
    >
    >     Greg,
    >
    > &= nbsp;   Sorry, but I do not remember the point you mention.
    >     Can you explain again here ?
    >     Thanks= .
    >     Luca
    >
    >
    >     On 02/17/= 11 23:47, Greg Mirsky wrote:
    >     > Dear Authors and All= ,
    >     > prior to the meeting in Bejing and acceptance o= f this proposal as WG
    >     > document Luca and I agreed that use of GAL with PW V= CCV presents a
    >     > problem.
    >     >= ; I was not attending the IETF-79, nor I found discussion of this
    > &n= bsp;   issue
    >     > in the minutes. I think that th= is issue should be specified,
    >     > explained. In my view, this document updates not onl= y RFC 5586
    >     > but RFC 5085 too.
    >    = ; >
    >     > Regards,
    >     > Greg>     >
    >     > Comment to draft-lm-pwe= 3-mpls-tp-gal-in-pw-00.txt
    >     >
    >     > On Sat, Oct 30, 2010 at 1= 0:14 AM, Luca Martini
    >     <lmartini@cisco.com&l= t;mailto:lmartini@cisco.com> <mailto:lmartini@cisco.com    <mailto:lmartini@cisco.com>>
    >     > <mailto:lmartini@cisco.com<mailto:lmart= ini@cisco.com> <mailto:<= a href=3D"mailto:lmartini@cisco.com">lmartini@cisco.com<mailto:lm= artini@cisco.com>>>> wrote:
    >     >
    >     >     Greg,
    &g= t;     >
    >     >     You are corre= ct , the proposed update does not propose any
    >     changes<= br>>     >     to VCCV.
    >     >=     However the problem with vccv is not as simple as to ask for<= br> >     a new
    >     >     code point= from IANA.
    >     >     Given the good amount o= f discussion on this point, we should
    >     >   &nbs= p; probably have a discussion in Beijing.
    >     >
    >=     >     Luca
    >     >
    >     >
    >     >= ;
    >     >     On 10/29/2010 05:07 PM, Greg Mirs= ky wrote:
    >     >>     Dear Authors,
    >=     >>     I think that proposed update of the Se= ction 4.2. RFC 5586
    >     makes it possible
    >     >>   &= nbsp; to use GAL on MPLS-TP PW that uses Control Word. I consider
    > &n= bsp;   it to be
    >     >>     conflict b= etween PW VCCV CC types because use of GAL is not
    >     negotiated
    >     >>     t= hrough PW VCCV negotiation. To avoid such situation I propose:
    >  = ;   >>
    >     >>        = - in Section 5 request IANA to assign new CC Type "MPLS
    >     Generic
    >     >>     &nbs= p;  Associated Channel Label"
    >     >>   &nb= sp;    - assign precedence to new CC Type that affects Section
    = >     7 RFC 5085
    >     >>
    >   &= nbsp; >>     Regards,
    >     >>     Greg
    >     >>= ;
    >     >>
    >     >>
    =
    ____________________= ___________________________
    mpls mailing list
    mpls@ietf.org
    https://www.ietf.org/mailman= /listinfo/mpls
    = --Apple-Mail-1--356993280-- From Alexander.Vainshtein@ecitele.com Sun Mar 13 22:35:31 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06AB63A6AEC for ; Sun, 13 Mar 2011 22:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] 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 idfSpGJ6YyJU for ; Sun, 13 Mar 2011 22:35:29 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id 76CA53A6A34 for ; Sun, 13 Mar 2011 22:35:28 -0700 (PDT) X-AuditID: 93eaf2e8-b7b1cae000000a72-74-4d7da90cf492 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Brightmail Gateway) with SMTP id 65.17.02674.C09AD7D4; Mon, 14 Mar 2011 07:35:08 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 14 Mar 2011 07:36:50 +0200 From: Alexander Vainshtein To: "curtis@occnc.com" Date: Mon, 14 Mar 2011 07:36:49 +0200 Thread-Topic: [mpls] draft-ietf-mpls-loss-delay Timestamp Thread-Index: Acvh8+Yl7AQKEOQ1T0m7lCGN3jC61QAFFxHz Message-ID: References: Your message of "Wed, 09 Mar 2011 15:03:12 +0200." ,<201103140259.p2E2xnAG028291@harbor.orleans.occnc.com> In-Reply-To: <201103140259.p2E2xnAG028291@harbor.orleans.occnc.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "stbryant@cisco.com" , "mpls@ietf.org" , "Pietilainen, Antti \(NSN - FI/Espoo\)" , "Mallette, Edwin" , "Zhao, Peng \(NSN - CN/Shanghai\)" Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 05:35:31 -0000 Curtis, Lots of thanks for a detailed response. I think that we partially agree regarding applicability (or non-applicabili= ty) of delay measurements for such purposes as estimating packet delay vari= ation: - we agree that without specifying the point in the data path where the tim= estamps are taken, delay measurements may be unsuitable for this purpose - we disagree regarding how jitter buffers should be set up. In particular,= the customers do not like the idea of giving them "a generous margin" beca= use this would result in increasing end-to-end delay of the emulated TDM ci= rcuit; and in most applications there is a strict delay budget for this. Ne= ither do they like setting these by trial and error. One way to resolve our partial agreement would be to explicitly state in th= e draft that applicability of the results of the delay measurements to any = specific needs is out of scope of the draft and is implementation-specific= . Regarding accuracy of the delay measurement, we seem to be mostly in agreem= ent. However, I'd like to notice that the accuracy of 2-way delay measureme= nt does not depend on accuracy of ToD synchronization between the nodes. Regards, Sasha ________________________________________ From: curtis@occnc.com [curtis@occnc.com] Sent: Monday, March 14, 2011 4:59 AM To: Alexander Vainshtein Cc: curtis@occnc.com; mpls@ietf.org; Zhao, Peng (NSN - CN/Shanghai); Pie= tilainen, Antti (NSN - FI/Espoo); stbryant@cisco.com; Mallette, Edw= in Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp In message Alexander Vainshtein writes: > > Curtis, > Lots of thanks for a prompt and delayed response. > > Please see some comments inline below. I've shipped the next that is not = related to these comments. > > Regards, > Sasha > > > -----Original Message----- > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > Sent: Wednesday, March 09, 2011 2:06 AM > > To: Alexander Vainshtein > > Cc: curtis@occnc.com; mpls@ietf.org; Zhao, Peng (NSN - CN/Shanghai); > > Pietilainen, Antti (NSN - FI/Espoo); tictoc@ietf.org; > > stbryant@cisco.com; Mallette, Edwin > > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp > > > --- snipped --- > > > 2. The "timestamp capture point in the data path" was not about the > > > timestamp location in the message. It is about the stage of the data > > > processing when the timestamp can be captured. E.g., some designs use > > > commercial HW that captures the timestamps between PHY and MAC. This > > > is OK for PTP and NTP, but excludes the time spent in the egress > > queue > > > of the node from delay measurement. > > > > That is why in NTP, PTP, and draft-ietf-mpls-loss-delay there are four > > timestamps. The total round trip delay subtracts the third and second > > to eliminate queuing and turn around. > [[[Sasha]]] Please consider the following use case: > - I am going to use a certain LSP as a tunnel for TDM PWs > - I would like to measure packet delay *variation* (PDV) introduced by > this LSP in order to configure the jitter buffer of these TDM PWs. I > expect to do that by measuring delay for multiple samples and > computing the PDV as (Max. measured delay - Min. measured delay) > - If queuing delay at the LSP head- and tail-nodes is not accounted in > my delay measurements, my PDV estimation will not account for that > also (because queuing only increases Max. measured delay) > - As a consequence, my PDV estimation may be not suitable for > configuring the jitter buffer correctly. As a consequence, my TDM > customers will see errors in their traffic when TDM PW packets that > arrive too late to be accommodated into the jitter buffer are > discarded and their payload replaced with "all ones". > Do I miss something here? I would say yeah sort of. This is slightly out of scope of the draft which is measuring the delay of the segment or LSP. If you took that delay (which is a minimum delay) and used it to set jitter buffers, you'd have very unhappy customers. Jitter buffers are normally set by measuring the delay experienced by the service and adding a generous safety margin based on estimate of std dev. Again, this is a usage (that you envision and that I don't share) but the usage is out of scope regarding discussion of the draft itself. > > > 3. You have said that 20 microseconds look to you as very good > > > accuracy for delay measurements. This probably depends on the > > > application. E.g., if we must synchronize two base stations within 2- > > 3 > > > microseconds of relative ToD error, this accuracy will hardly help > > you > > > to understand why your synchronization mechanisms do not work:-). I > > > am somewhat suspicious about a measurement procedure that does not > > > specify accuracy explicitly. But I understand the position taken by > > > the draft authors. > > > > 20 usec is OK for draft-ietf-mpls-loss-delay type measurements. > [[[Sasha]]] I would be happy to accept that. But the draft does not > yield this (or any other) number. You snipped something important here. I was enumerating the timestamp formats and mentioned that the NTP 32 bit format would be more than adequate for most delay measurements. Later (snipped below) I mention that draft-ietf-mpls-loss-delay puts any timestamp format into 64 bits so there is no sense in using the 32 bit format. It is extremely difficult to know the accuracy (with any accuracy :). It depends on the accuracy of time synchronization which may not be known. > --- snipped to the end ---= From eosborne@cisco.com Mon Mar 14 04:23:02 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAFFE3A6C65 for ; Mon, 14 Mar 2011 04:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 R7FYu2x1GiaA for ; Mon, 14 Mar 2011 04:23:00 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 1B59F3A6CA6 for ; Mon, 14 Mar 2011 04:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=2301; q=dns/txt; s=iport; t=1300101859; x=1301311459; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=L2d7oNgrKehXyy+QFbro/jkNwOyWSy29AgZJa+T0ymo=; b=eaS5FmqNvRyxfsPATHBGSG2WV3n3VHDWh+QR9hA2XlH7WL70TYALvZYX eBnAJQh3K6tqoGQmInJ/7QeyIm3l6ngVVL67fnKTqf7sf4fIHjui6Gozl /COTEepfzL0YMNYrlYE8/0jIFybgopuDvgGP6ofv7pzpBy3Nw41kzHogO E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAADaXfU2tJXG//2dsb2JhbACEPZQDjUV3pBqKJHIBkA6BJINFeQSFK4p7 X-IronPort-AV: E=Sophos;i="4.62,315,1297036800"; d="scan'208";a="276021976" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-4.cisco.com with ESMTP; 14 Mar 2011 11:24:19 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2EBOJim023897; Mon, 14 Mar 2011 11:24:19 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 06:24:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Date: Mon, 14 Mar 2011 06:24:16 -0500 Message-ID: In-Reply-To: <728AC2C738D94E14A2BF3712773FCD56@ctbrijingrq> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-tsb-mpls-tp-ach-ptn Thread-Index: AcvfnOeVV3ZPtvhwS+WvdnOPEqon7QCQkvXwABZ+Y1A= References: <52981DB05D3C5247A12D0AEE309F3CC201EB24B1CBBC@INOAVREX11.ptin.corpPT.com> <728AC2C738D94E14A2BF3712773FCD56@ctbrijingrq> From: "Eric Osborne (eosborne)" To: "Jingrq" , "Rui Costa" , X-OriginalArrivalTime: 14 Mar 2011 11:24:19.0753 (UTC) FILETIME=[5C77D990:01CBE23A] Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 11:23:03 -0000 Hey folks- Before we get all caught up in the support/nosupport contest, please remember that the time support/nosupport comes out is in response to a WG poll, that sort of thing. We're not there yet (the draft is brand new), so now is not the right time to start casting votes. It achieves nothing and just adds noise on top of signal. eric > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Jingrq > Sent: Sunday, March 13, 2011 8:35 PM > To: 'Rui Costa'; mpls@ietf.org > Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn > > Hi Rui, > > I support your proposal. It will good to both IETF and ITU-T if the > Associated Channel Type is allocated. > > Best regards > > Ruiquan$B!J(JRick$B!K(J Jing > > China Telecom CTBRI > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of Rui Costa > > Sent: Friday, March 11, 2011 11:32 AM > > To: mpls@ietf.org > > Subject: [mpls] draft-tsb-mpls-tp-ach-ptn > > > > Hello, > > > > The draft provided by the TSB draft-tsb-mpls-tp-ach-ptn requests the > > allocation of an Associated Channel Type value that will allow ITU-T > > to develop OAM tools required to address the needs identified by some > > ITU-T members. > > Allocation of this value will make more efficient use of resources of > > both IETF and ITU-T. The use of this associated channel type fully > > complies with the framework and > > architecture for MPLS-TP. > > > > The draft also describes the cases where networks that run the ITU > > defined OAM tools are interconnected to networks that run the IETF > > defined OAM tools. In most cases it is a client/server relationship > > and no interworking is required. > > If a LSP or PW originates in one domain and terminates in the > > other domain then the IETF OAM tools must be used. > > > > This draft should be discussed in Prague. > > > > Best Regards, > > Rui > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From huubatwork@gmail.com Mon Mar 14 06:03:07 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E803A6D17 for ; Mon, 14 Mar 2011 06:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 s8TtB4D6BZCK for ; Mon, 14 Mar 2011 06:03:06 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 99ACC3A68E5 for ; Mon, 14 Mar 2011 06:03:05 -0700 (PDT) Received: by eye13 with SMTP id 13so1923785eye.31 for ; Mon, 14 Mar 2011 06:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:disposition-notification-to:date :from:reply-to:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bORyyn6z39iXO5WFovsGpm5FXIMCI6g4KNCJI9vlync=; b=dA00FsloaAEdcQLP26fIAHLXlJO7SHqpEcHd+a1sCpTvcszoOlfgfkt2U/Llxl8+QC jZskjGAmLYezyla3zNS8Qriz4IIoveqrj41vJQOhU/Ip1tSzt4fXGWVRFiakUtxZolp9 yo3l6DsEQcE2A3mWIf1dHcKA4pfVvPUcCch7w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; b=X5OY7hk6PosQKj3dSNlc2c9WPZACUK3danGoNBFgQcI1Bduxx3vtEVzmq2aS/xQxWQ 99zq1pTwt+AaNKLkDFbfj2Vn9fzHznfDfgDWx+tdUDUNC77+YSjGRM+2bwqXtNDy6MY+ NJU/i4RHBsjNelNHjAfAmY75dLBj/x768AP6w= Received: by 10.213.20.214 with SMTP id g22mr2984249ebb.127.1300107868498; Mon, 14 Mar 2011 06:04:28 -0700 (PDT) Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl [77.250.51.60]) by mx.google.com with ESMTPS id u45sm3622967eeh.20.2011.03.14.06.04.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Mar 2011 06:04:27 -0700 (PDT) Message-ID: <4D7E1258.9000007@gmail.com> Date: Mon, 14 Mar 2011 14:04:24 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: mpls@ietf.org References: <52981DB05D3C5247A12D0AEE309F3CC201EB24B1CBBC@INOAVREX11.ptin.corpPT.com> <728AC2C738D94E14A2BF3712773FCD56@ctbrijingrq> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 13:03:07 -0000 Hi Eric, You wrote: > Before we get all caught up in the support/nosupport contest, please > remember that the time support/nosupport comes out is in response to > a WG poll, that sort of thing. You are right, this is not a WG poll. If I read the initial email it proposes: "This draft should be discussed in Prague" so I assume the 'support' is for this proposal. And I agree with that proposal. > We're not there yet (the draft is brand new), Indeed, but the draft is concise and to the point. It is based on advice from the IETF to progress work on MPLS-TP. A presentation would be very useful. Regards, Huub. >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Jingrq >> Sent: Sunday, March 13, 2011 8:35 PM >> To: 'Rui Costa'; mpls@ietf.org >> Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn >> >> Hi Rui, >> >> I support your proposal. It will good to both IETF and ITU-T if the >> Associated Channel Type is allocated. >> >> Best regards >> >> Ruiquan（Rick） Jing >> >> China Telecom CTBRI >> >> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>> Of Rui Costa >>> Sent: Friday, March 11, 2011 11:32 AM >>> To: mpls@ietf.org >>> Subject: [mpls] draft-tsb-mpls-tp-ach-ptn >>> >>> Hello, >>> >>> The draft provided by the TSB draft-tsb-mpls-tp-ach-ptn requests the >>> allocation of an Associated Channel Type value that will allow ITU-T >>> to develop OAM tools required to address the needs identified by some >>> ITU-T members. >>> Allocation of this value will make more efficient use of resources of >>> both IETF and ITU-T. The use of this associated channel type fully >>> complies with the framework and >>> architecture for MPLS-TP. >>> >>> The draft also describes the cases where networks that run the ITU >>> defined OAM tools are interconnected to networks that run the IETF >>> defined OAM tools. In most cases it is a client/server relationship >>> and no interworking is required. >>> If a LSP or PW originates in one domain and terminates in the >>> other domain then the IETF OAM tools must be used. >>> >>> This draft should be discussed in Prague. >>> >>> Best Regards, >>> Rui -- ***************************************************************** 我爱外点一七三一 From eric.gray@ericsson.com Mon Mar 14 06:11:41 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2E43A6D2F for ; Mon, 14 Mar 2011 06:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, J_CHICKENPOX_15=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 pxoCqp+26oeF for ; Mon, 14 Mar 2011 06:11:39 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id CF22F3A6D20 for ; Mon, 14 Mar 2011 06:11:36 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p2EDB7oi004752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Mar 2011 08:12:58 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.92]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 14 Mar 2011 09:12:49 -0400 From: Eric Gray To: "t.petch" Date: Mon, 14 Mar 2011 09:12:47 -0400 Thread-Topic: [mpls] I-D Action:draft-ietf-mpls-tp-on-demand-cv-02.txt Thread-Index: AcvSoIavSMIpVb4XS0SkhSCtYD05YgPqMa5A Message-ID: References: <20110209193001.19667.86167.idtracker@localhost> <002601cbd297$4f667340$4001a8c0@gateway.2wire.net> In-Reply-To: <002601cbd297$4f667340$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] I-D Action:draft-ietf-mpls-tp-on-demand-cv-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 13:11:41 -0000 Tom, Section 2.3 (MEP/MIP Identifiers) is going away in the next=20 iteration of the on-demand-cv draft. -- Eric -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of t.p= etch Sent: Tuesday, February 22, 2011 8:49 AM Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-ietf-mpls-tp-on-demand-cv-02.txt A minor quirk; the expansions given in s2.3 of this I-D for MIP and MEP are= out of line with those used in other MPLS I-Ds. Tom Petch ----- Original Message ----- From: To: Cc: Sent: Wednesday, February 09, 2011 8:30 PM Subject: [mpls] I-D Action:draft-ietf-mpls-tp-on-demand-cv-02.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching Working Gr= oup of the IETF. > > > Title : MPLS On-demand Connectivity Verification and Route Trac= ing > Author(s) : N. Bahadur, et al. > Filename : draft-ietf-mpls-tp-on-demand-cv-02.txt > Pages : 17 > Date : 2011-02-09 > > LSP-Ping is an existing and widely deployed OAM mechanism for MPLS > LSPs. This document describes extensions to LSP-Ping so that LSP- > Ping can be used for On-demand Connectivity Verification of MPLS-TP > LSPs. This document also clarifies procedures to be used for > processing the related OAM packets. Further, it describes procedures > for using LSP-Ping to perform Connectivity Verification and Route > Tracing functions in MPLS-TP networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-on-demand-cv-02.tx= t > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ---------------------------------------------------------------------------= ----- > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Mon Mar 14 06:21:59 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C543A6D5B; Mon, 14 Mar 2011 06:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599] 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 9ioOrzQf2p82; Mon, 14 Mar 2011 06:21:56 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 6C9D43A6D3E; Mon, 14 Mar 2011 06:21:56 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2EDNCYB020312; Mon, 14 Mar 2011 08:23:19 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.92]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 14 Mar 2011 09:23:16 -0400 From: Eric Gray To: "BUSI, ITALO (ITALO)" , Loa Andersson , "mpls-tp@ietf.org" , "mpls@ietf.org" , MPLS-TP ad hoc team Date: Mon, 14 Mar 2011 09:23:15 -0400 Thread-Topic: [mpls-tp] [mpls] poll to adopt draft-nitinb-mpls-tp-on-demand-cv as a working group document Thread-Index: AcsROjrrF49QvhDORjuDFaI2E7/UkQK8vpMAMYdDCDA= Message-ID: References: <4C1F5616.2060406@pi.nu> <15740615FC9674499FBCE797B011623F0B730111@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <15740615FC9674499FBCE797B011623F0B730111@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.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 Subject: Re: [mpls] [mpls-tp] poll to adopt draft-nitinb-mpls-tp-on-demand-cv as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 13:21:59 -0000 Italo, Sorry for the _long-time_ in responding... It is important to realize that this document specifies a procedure that is intended to be generally applicable to MPLS. As such, it is not appropriate to document each specific case in which this set of protocol extensions might be applicable. You do point out a valid hole in the suite of protocol extensions being developed to support the transport profile of MPLS. We will eventually need an applicability RFC that ties all of the various documents together. At the most recent ITU-T SG-15 plenary meeting, it struck me as very probable that you might be just the person to write such an RFC... -- Eric=20 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of BUSI, ITALO (ITALO) Sent: Monday, July 05, 2010 6:26 AM To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team Subject: Re: [mpls-tp] [mpls] poll to adopt draft-nitinb-mpls-tp-on-demand-= cv as a working group document The current draft does not clearly articulate how the solution mechanism is= satisfying the requirements and behaviors associated with on-demand CV (e.= g., support of per-interface MIP model). It is important that this be docu= mented. Italo=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: luned=EC 21 giugno 2010 14.08 > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team > Subject: [mpls] poll to adopt=20 > draft-nitinb-mpls-tp-on-demand-cv as a working group document >=20 >=20 > Working Group, >=20 > this email is to start poll to adopt > draft-nitinb-mpls-tp-on-demand-cv-00.txt > as an MPLS working group draft. >=20 > After recent experience, the chairs would like to remind you=20 > all what it means to conduct a poll to adopt a draft as a=20 > working group draft. >=20 > - Please recall that the IETF does not "vote." Polls of a working > group are to gather information to help the chairs make their > decisions. Voting is not part of the normal working methods of > an IETF working group. >=20 > - The "rough consensus" process used in the working group assumes > that people expressing opinions are also participating in the > development of standards documents. >=20 > - Subscription to the list specifically to express an opinion is > noticed by the chairs who has access to information on the new list > members. Such behavior is not part of the normal working methods. >=20 > - The purpose of a poll for adoption is to help the chairs understand > the level of support for a document (i.e. who has read it, who > believes it is a good starting point for working group work, who > will contribute to the work) and whether there are any significant > technical issues. Statements of objection must be backed up by > proper technical reasons. >=20 > So please respond to this poll indicating whether you support=20 > the adoption of this draft or stating your technical issues. >=20 > Please also not that this draft has after a discussion with=20 > the working group chairs been renamed, it was earlier know as=20 > draft-nitinb-mpls-tp-lsp-ping-extensions-01. >=20 > This poll ends eob July 5. >=20 >=20 > Loa and George > mpls wg co-chairs >=20 > --=20 >=20 >=20 > Loa Andersson email:=20 > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92=20 > 13 _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From eric.gray@ericsson.com Mon Mar 14 06:49:50 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509E13A6D50; Mon, 14 Mar 2011 06:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599] 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 ZvufKFtTHTUG; Mon, 14 Mar 2011 06:49:49 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 1746C3A6958; Mon, 14 Mar 2011 06:49:48 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2EDp1jt025980; Mon, 14 Mar 2011 08:51:06 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.92]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 14 Mar 2011 09:51:00 -0400 From: Eric Gray To: "hhelvoort@chello.nl" , Loa Andersson Date: Mon, 14 Mar 2011 09:50:58 -0400 Thread-Topic: [mpls] [mpls-tp] poll to adopt draft-nitinb-mpls-tp-on-demand-cv as a working group document Thread-Index: AcscOQasFqRxO8L/SWOO4wxvFOmWXTGE2pSQ Message-ID: References: <4C1F5616.2060406@pi.nu> <4C31C837.7020601@chello.nl> In-Reply-To: <4C31C837.7020601@chello.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] poll to adopt draft-nitinb-mpls-tp-on-demand-cv as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 13:49:50 -0000 Huub, Sorry for the delay in responding. As noted in my reply to Italo, the document is meant to apply generally, hence it would be inappropriate to specify how it would be used for a specific application (such as in the case of a transport profile of MPLS). As I told Italo, you (too) are correct that this needs to be documented somewhere. Just not here. We have had some iterations of the draft since your comment was posted. In fact, there will be a new one later today. Perhaps it now fits the new name better than it did... -- Eric -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Huu= b van Helvoort Sent: Monday, July 05, 2010 7:56 AM To: Loa Andersson Cc: mpls@ietf.org; MPLS-TP ad hoc team; mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] poll to adopt draft-nitinb-mpls-tp-on-demand-= cv as a working group document No/do not support The change of the name of this draft gives the impression that the content of the draft changed as well. So before it can be adopted the text has to be aligned with the title: On-demand CV for MPLS-TP. I see that it is still focused on extending LSP-Ping but not for use in a transport environment. It does not indicate where the transport OAM requirements are met. It does not indicate how the ACh is used. What is the meaning of "adjacency" in the context of MPLS-TP? It does not document how this tool can be used in transport environment where tools are enabled/disabled static (compared to the dynamic set-up of LSP-ping. Regards, Huub. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 21-06-10 14:07, Loa Andersson wrote: > > Working Group, > > this email is to start poll to adopt > draft-nitinb-mpls-tp-on-demand-cv-00.txt > as an MPLS working group draft. > > After recent experience, the chairs would like to remind you all > what it means to conduct a poll to adopt a draft as a working group > draft. > > - Please recall that the IETF does not "vote." Polls of a working > group are to gather information to help the chairs make their > decisions. Voting is not part of the normal working methods of > an IETF working group. > > - The "rough consensus" process used in the working group assumes > that people expressing opinions are also participating in the > development of standards documents. > > - Subscription to the list specifically to express an opinion is > noticed by the chairs who has access to information on the new list > members. Such behavior is not part of the normal working methods. > > - The purpose of a poll for adoption is to help the chairs understand > the level of support for a document (i.e. who has read it, who > believes it is a good starting point for working group work, who > will contribute to the work) and whether there are any significant > technical issues. Statements of objection must be backed up by > proper technical reasons. > > So please respond to this poll indicating whether you support the > adoption of this draft or stating your technical issues. > > Please also not that this draft has after a discussion with the > working group chairs been renamed, it was earlier know as > draft-nitinb-mpls-tp-lsp-ping-extensions-01. > > This poll ends eob July 5. > > > Loa and George > mpls wg co-chairs > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://www.van-helvoort.eu/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Mon Mar 14 07:01:37 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989263A6D78; Mon, 14 Mar 2011 07:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599] 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 TexHjKpsyhMV; Mon, 14 Mar 2011 07:01:36 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 4FA413A6D67; Mon, 14 Mar 2011 07:01:36 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p2EE2tjN008606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Mar 2011 09:02:55 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.92]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 14 Mar 2011 10:02:54 -0400 From: Eric Gray To: Zhang Haiyan , Loa Andersson , "mpls-tp@ietf.org" , "mpls@ietf.org" , MPLS-TP ad hoc team Date: Mon, 14 Mar 2011 10:02:53 -0400 Thread-Topic: [mpls] [mpls-tp] poll to adopt draft-nitinb-mpls-tp-on-demand-cv as a working group document Thread-Index: AcsZiX2AZ9nW28PnSe+NIlZA4wE/7DIxYEGA Message-ID: References: <4C1F5616.2060406@pi.nu> <064b01cb1989$6dc2fba0$774d460a@china.huawei.com> In-Reply-To: <064b01cb1989$6dc2fba0$774d460a@china.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] [mpls-tp] poll to adopt draft-nitinb-mpls-tp-on-demand-cv as a working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 14:01:37 -0000 Haiyan, This is largely a semantics issue. The extensions described in this draft are intended to - among other things - support the requirements of a transport profile of=20 MPLS. Those requirements initially drove the creation of this draft. It is still the case that these extensions are intended to support a transport profile of MPLS. However, as you note, they also support usage in an environment that may not be strictly limited to "transport" in the sense that has been used in referring to a "transport profile." Specifically, in=20 cases where (for example) IP addressing may be used generally in the services being provided by a service provider who also plane to use similar/identical technology to support "transport" requirements. It appears to be the (rough?) consensus of the MPLS working group that "LSP-Ping" is the tool of choice for on demand CV. Ping, in general, has filled a role as on-demand connectivity verification in IP-based networks for a very long time, and network operators who plan to use IP infrastructure to support their own "transport" needs are generally aware of this tool and the on-going need for it in the IP network infrastrcture. -- Eric -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Zha= ng Haiyan Sent: Thursday, July 01, 2010 9:54 PM To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team Subject: Re: [mpls] [mpls-tp] poll to adopt draft-nitinb-mpls-tp-on-demand-= cv as a working group document No/ do not support. Several comments need clarification:=20 1) We do not see how the content of the draft satisfies "on-demand-cv" as c= laimed in the title. We only see "LSP-Ping" and "LSP Traceroute" in the mai= n part of the draft.=20 In the introduction part we also see the "on-demand Connectivity Verificati= on, Route Tracing and Adjacency functions".=20 Could the authors clarify the "on-demand CV"?=20 2) Could the authors clarify the purpose of describing "LSP-Ping with IP en= capsulation" and "LSP Traceroute with IP encapsulation"? The draft seems to be just a regular extension of MPLS LSP ping, not partic= ular for MPLS-TP. Shouldn't it be a draft with the name "mpls-lsp-ping-exte= nsions"? B.R. Haiyan ----- Original Message -----=20 From: "Loa Andersson" To: ; ; "MPLS-TP ad hoc team" Sent: Monday, June 21, 2010 8:07 PM Subject: [mpls-tp] poll to adopt draft-nitinb-mpls-tp-on-demand-cv as a wor= king group document >=20 > Working Group, >=20 > this email is to start poll to adopt > draft-nitinb-mpls-tp-on-demand-cv-00.txt > as an MPLS working group draft. >=20 > After recent experience, the chairs would like to remind you all > what it means to conduct a poll to adopt a draft as a working group > draft. >=20 > - Please recall that the IETF does not "vote." Polls of a working > group are to gather information to help the chairs make their > decisions. Voting is not part of the normal working methods of > an IETF working group. >=20 > - The "rough consensus" process used in the working group assumes > that people expressing opinions are also participating in the > development of standards documents. >=20 > - Subscription to the list specifically to express an opinion is > noticed by the chairs who has access to information on the new list > members. Such behavior is not part of the normal working methods. >=20 > - The purpose of a poll for adoption is to help the chairs understand > the level of support for a document (i.e. who has read it, who > believes it is a good starting point for working group work, who > will contribute to the work) and whether there are any significant > technical issues. Statements of objection must be backed up by > proper technical reasons. >=20 > So please respond to this poll indicating whether you support the=20 > adoption of this draft or stating your technical issues. >=20 > Please also not that this draft has after a discussion with the > working group chairs been renamed, it was earlier know as > draft-nitinb-mpls-tp-lsp-ping-extensions-01. >=20 > This poll ends eob July 5. >=20 >=20 > Loa and George > mpls wg co-chairs >=20 > --=20 >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Alexander.Vainshtein@ecitele.com Mon Mar 14 07:02:44 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5383A6910 for ; Mon, 14 Mar 2011 07:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] 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 DRzMALaQwteP for ; Mon, 14 Mar 2011 07:02:43 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id DE5F63A6D72 for ; Mon, 14 Mar 2011 07:02:42 -0700 (PDT) X-AuditID: 93eaf2e8-b7b1cae000000a72-ef-4d7e1fefcee3 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Brightmail Gateway) with SMTP id 2C.34.02674.FEF1E7D4; Mon, 14 Mar 2011 16:02:23 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 14 Mar 2011 16:04:05 +0200 From: Alexander Vainshtein To: "huubatwork@gmail.com" Date: Mon, 14 Mar 2011 16:04:02 +0200 Thread-Topic: [mpls] draft-tsb-mpls-tp-ach-ptn Thread-Index: AcviSK66djcjqjrqQ+avJF2zRskwEwAArbMQ Message-ID: References: <52981DB05D3C5247A12D0AEE309F3CC201EB24B1CBBC@INOAVREX11.ptin.corpPT.com> <728AC2C738D94E14A2BF3712773FCD56@ctbrijingrq> <4D7E1258.9000007@gmail.com> In-Reply-To: <4D7E1258.9000007@gmail.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 14:02:44 -0000 SHV1YiwNCkkgYXNzdW1lIHRoYXQgdGhlIGF1dGhvciBoYXMgYXNrZWQgZm9yIGEgdGltZXNsb3Qg b24gdGhlIGFnZW5kYSBvZiB0aGUgTVBMUyBXRz8NCg0KQXMgZm9yIHRoZSBkcmFmdCBpdHNlbGY6 IEkgaGF2ZSByZWFkIGl0LCBhbmQgSSBkbyBub3Qgc2hhcmUgeW91ciBvcGluaW9uIHJlZ2FyZGlu ZyBpdHMgYmVpbmcgImNvbmNpc2UgYW5kIHRvIHRoZSBwb2ludCIuDQoNCkp1c3QgYSBjb3VwbGUg b2YgY29tbWVudHMgYW5kIHF1ZXN0aW9uczoNCi0gVGhlIGRyYWZ0IGRpc2N1c3NlcyBkaWZmZXJl bmNlcyBiZXR3ZWVuIHBhY2tldCBzd2l0Y2hpbmcgbmV0d29ya3MgKGkuZS4sIGEgZGF0YSBwbGFu ZSB0ZWNobm9sb2d5KSBhbmQgcGFja2V0IHRyYW5zcG9ydCBuZXR3b3JrcyAoaS5lLiBhIHNwZWNp ZmljIGFwcGxpY2F0aW9uKS4gU3VjaCBhIGNvbXBhcmlzb24gbG9va3MgaW5hcHByb3ByaWF0ZSB0 byBtZQ0KLSBUaGUgZHJhZnQgc3VnZ2VzdCB0aGF0IFJGQyA1NjU5IChBbiBBcmNoaXRlY3R1cmUg Zm9yIE11bHRpLVNlZ21lbnQgUHNldWRvd2lyZXMpIGRlZmluZXMgYSBuZXcgZGF0YSBwbGFuZS4g SW4gZmFjdCwgTVBMUyBtdWx0aS1zZWdtZW50IFBXcyB1c2UgTVBMUyBkYXRhIHBsYW5lIGFzIGRl ZmluZWQgaW4gUkZDIDMwMzEgYW5kIDMwMzINCi0gVGhlIGRyYWZ0IHN0YXRlcyB0aGF0IFBUTiBh cHBsaWNhdGlvbiB1c2VzIE1QTFMtVFAgdG8gYWRkIHBhY2tldCB0cmFuc3BvcnQgY2FwYWJpbGl0 aWVzIHRvIGV4aXN0aW5nIFNPTkVUL1NESCBuZXR3b3Jrcy4gRG9lcyB0aGlzIGltcGx5IHRoYXQg aXQgd2lsbCBub3QgYmUgYXBwbGllZCB0byBwYWNrZXRzIGNhcnJpZWQgb3ZlciBvdGhlciBkYXRh IGxpbmsgdGVjaG5vbG9naWVzLCBlLmcuLCBFdGhlcm5ldCBpbiBhbGwgaXRzIGZvcm1zPyBJbiBw YXJ0aWN1bGFyLCB3aGF0IGlzIGdvaW5nIHRvIGhhcHBlbiBpbiBhIGRldmljZSB0aGF0IHVzZXMg bGFiZWwgc3dpdGNoaW5nIGJldHdlZW4gdHdvIHBvcnRzLCBvbmUgb2YgdGhlbSB1c2luZyBNUExT IG92ZXIgR0ZQIG92ZXIgU0RILCBhbmQgdGhlIG90aGVyIG9uZSAtIHVzaW5nLCBzYXksIE1QTFMg b3ZlciBuYXRpdmUgR0Ugb3IgMTBHRT8gKFRoaXMgaXMgbm90IGFuIGltYWdpbmFyeSBjYXNlKS4N Ci0gVGhlIGRyYWZ0IGRvZXMgbm90IGNvbnNpZGVyIHRoZSBwb3NzaWJpbGl0eSBvZiBwZWVyaW5n IGJldHdlZW4gdGhlICJQVE4gYXBwbGljYXRpb24iIGFuZCAiTVBMUy1UUCIsIGJ1dCBoaXRzIHRo YXQgc3VjaCBhIHBlZXJpbmcgaXMgcG9zc2libGUgYmV0d2VlbiBFdGhlcm5ldCBhbmQgTVBMUy1U UC4NCi0gTGFzdCBidXQgbm90IGxlYXN0LCB0aGUgZHJhZnQgZG9lcyBub3QgZXhwbGFpbiBob3cg YWxsb2NhdGlvbiBvZiBhICpzaW5nbGUqIGNvZGUgcG9pbnQgaW4gdGhlIEFDSCB0eXBlIHJlZ2lz dHJ5IGZvciB0aGUgUFROIGFwcGxpY2F0aW9uIG1lZXRzICphbGwqIHRoZSBuZWVkcyBvZiB0aGUg UFROIGFwcGxpY2F0aW9uIChDQy9DViwgUFNDLCBMb2NrLCBMREksIE1TTiwgU1NOIGV0YykgdGhh dCBoYXZlIGJlZW4gaWRlbnRpZmllZCBhcyB0aGUgQUNIIGFwcGxpY2F0aW9ucyBmb3IgTVBMUy1U UC4gDQoNCk15IDJjLA0KICAgICBTYXNoYQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mDQo+IEh1dWIgdmFuIEhlbHZvb3J0DQo+IFNlbnQ6IE1vbmRheSwg TWFyY2ggMTQsIDIwMTEgMzowNCBQTQ0KPiBUbzogbXBsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW21wbHNdIGRyYWZ0LXRzYi1tcGxzLXRwLWFjaC1wdG4NCj4gDQo+IEhpIEVyaWMsDQo+IA0K PiBZb3Ugd3JvdGU6DQo+IA0KPiA+IEJlZm9yZSB3ZSBnZXQgYWxsIGNhdWdodCB1cCBpbiB0aGUg c3VwcG9ydC9ub3N1cHBvcnQgY29udGVzdCwgcGxlYXNlDQo+ICA+IHJlbWVtYmVyIHRoYXQgdGhl IHRpbWUgc3VwcG9ydC9ub3N1cHBvcnQgY29tZXMgb3V0IGlzIGluIHJlc3BvbnNlIHRvDQo+ICA+ IGEgV0cgcG9sbCwgdGhhdCBzb3J0IG9mIHRoaW5nLg0KPiANCj4gWW91IGFyZSByaWdodCwgdGhp cyBpcyBub3QgYSBXRyBwb2xsLg0KPiANCj4gSWYgSSByZWFkIHRoZSBpbml0aWFsIGVtYWlsIGl0 IHByb3Bvc2VzOiAiVGhpcyBkcmFmdCBzaG91bGQgYmUNCj4gZGlzY3Vzc2VkIGluIFByYWd1ZSIg c28gSSBhc3N1bWUgdGhlICdzdXBwb3J0JyBpcyBmb3IgdGhpcyBwcm9wb3NhbC4NCj4gDQo+IEFu ZCBJIGFncmVlIHdpdGggdGhhdCBwcm9wb3NhbC4NCj4gDQo+ID4gV2UncmUgbm90IHRoZXJlIHll dCAodGhlIGRyYWZ0IGlzIGJyYW5kIG5ldyksDQo+IA0KPiBJbmRlZWQsIGJ1dCB0aGUgZHJhZnQg aXMgY29uY2lzZSBhbmQgdG8gdGhlIHBvaW50Lg0KPiBJdCBpcyBiYXNlZCBvbiBhZHZpY2UgZnJv bSB0aGUgSUVURiB0byBwcm9ncmVzcyB3b3JrIG9uIE1QTFMtVFAuDQo+IEEgcHJlc2VudGF0aW9u IHdvdWxkIGJlIHZlcnkgdXNlZnVsLg0KPiANCj4gUmVnYXJkcywgSHV1Yi4NCj4gDQo+IA0KPiA+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZg0KPiA+ PiBKaW5ncnENCj4gPj4gU2VudDogU3VuZGF5LCBNYXJjaCAxMywgMjAxMSA4OjM1IFBNDQo+ID4+ IFRvOiAnUnVpIENvc3RhJzsgbXBsc0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW21wbHNd IGRyYWZ0LXRzYi1tcGxzLXRwLWFjaC1wdG4NCj4gPj4NCj4gPj4gSGkgUnVpLA0KPiA+Pg0KPiA+ PiBJIHN1cHBvcnQgeW91ciBwcm9wb3NhbC4gSXQgd2lsbCBnb29kIHRvIGJvdGggSUVURiBhbmQg SVRVLVQgaWYgdGhlDQo+ID4+IEFzc29jaWF0ZWQgQ2hhbm5lbCBUeXBlIGlzIGFsbG9jYXRlZC4N Cj4gPj4NCj4gPj4gQmVzdCByZWdhcmRzDQo+ID4+DQo+ID4+IFJ1aXF1YW7vvIhSaWNr77yJIEpp bmcNCj4gPj4NCj4gPj4gQ2hpbmEgVGVsZWNvbSBDVEJSSQ0KPiA+Pg0KPiA+Pg0KPiA+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmDQo+ID4+PiBPZiBS dWkgQ29zdGENCj4gPj4+IFNlbnQ6IEZyaWRheSwgTWFyY2ggMTEsIDIwMTEgMTE6MzIgQU0NCj4g Pj4+IFRvOiBtcGxzQGlldGYub3JnDQo+ID4+PiBTdWJqZWN0OiBbbXBsc10gZHJhZnQtdHNiLW1w bHMtdHAtYWNoLXB0bg0KPiA+Pj4NCj4gPj4+IEhlbGxvLA0KPiA+Pj4NCj4gPj4+IFRoZSBkcmFm dCBwcm92aWRlZCBieSB0aGUgVFNCIGRyYWZ0LXRzYi1tcGxzLXRwLWFjaC1wdG4gcmVxdWVzdHMN Cj4gdGhlDQo+ID4+PiBhbGxvY2F0aW9uIG9mIGFuIEFzc29jaWF0ZWQgQ2hhbm5lbCBUeXBlIHZh bHVlIHRoYXQgd2lsbCBhbGxvdyBJVFUtDQo+IFQNCj4gPj4+IHRvIGRldmVsb3AgT0FNIHRvb2xz IHJlcXVpcmVkIHRvIGFkZHJlc3MgdGhlIG5lZWRzIGlkZW50aWZpZWQgYnkNCj4gc29tZQ0KPiA+ Pj4gSVRVLVQgbWVtYmVycy4NCj4gPj4+IEFsbG9jYXRpb24gb2YgdGhpcyB2YWx1ZSB3aWxsIG1h a2UgbW9yZSBlZmZpY2llbnQgdXNlIG9mIHJlc291cmNlcw0KPiBvZg0KPiA+Pj4gYm90aCBJRVRG IGFuZCBJVFUtVC4gVGhlIHVzZSBvZiB0aGlzIGFzc29jaWF0ZWQgY2hhbm5lbCB0eXBlIGZ1bGx5 DQo+ID4+PiBjb21wbGllcyB3aXRoIHRoZSBmcmFtZXdvcmsgYW5kDQo+ID4+PiBhcmNoaXRlY3R1 cmUgZm9yIE1QTFMtVFAuDQo+ID4+Pg0KPiA+Pj4gVGhlIGRyYWZ0IGFsc28gZGVzY3JpYmVzIHRo ZSBjYXNlcyB3aGVyZSBuZXR3b3JrcyB0aGF0IHJ1biB0aGUgSVRVDQo+ID4+PiBkZWZpbmVkIE9B TSB0b29scyBhcmUgaW50ZXJjb25uZWN0ZWQgdG8gbmV0d29ya3MgdGhhdCBydW4gdGhlIElFVEYN Cj4gPj4+IGRlZmluZWQgT0FNIHRvb2xzLiBJbiBtb3N0IGNhc2VzIGl0IGlzIGEgY2xpZW50L3Nl cnZlciByZWxhdGlvbnNoaXANCj4gPj4+IGFuZCBubyBpbnRlcndvcmtpbmcgaXMgcmVxdWlyZWQu DQo+ID4+PiBJZiBhIExTUCBvciBQVyBvcmlnaW5hdGVzIGluIG9uZSBkb21haW4gYW5kIHRlcm1p bmF0ZXMgaW4gdGhlDQo+ID4+PiBvdGhlciBkb21haW4gdGhlbiB0aGUgSUVURiBPQU0gdG9vbHMg bXVzdCBiZSB1c2VkLg0KPiA+Pj4NCj4gPj4+IFRoaXMgZHJhZnQgc2hvdWxkIGJlIGRpc2N1c3Nl ZCBpbiBQcmFndWUuDQo+ID4+Pg0KPiA+Pj4gQmVzdCBSZWdhcmRzLA0KPiA+Pj4gUnVpDQo+IA0K PiANCj4gLS0NCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICDmiJHniLHl pJbngrnkuIDkuIPkuInkuIANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From Internet-Drafts@ietf.org Mon Mar 14 07:30:02 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D963A3A6DAD; Mon, 14 Mar 2011 07:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, 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 DY9gqMMRY4jn; Mon, 14 Mar 2011 07:30:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F11743A6DB4; Mon, 14 Mar 2011 07:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314143001.5553.3953.idtracker@localhost> Date: Mon, 14 Mar 2011 07:30:01 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-csf-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 14:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Indication of Client Failure in MPLS-TP Author(s) : H. Jia, et al. Filename : draft-ietf-mpls-tp-csf-01.txt Pages : 12 Date : 2011-03-14 This document describes a Multi-Protocol Label Switching Transport Profile (MPLS-TP) Operations, Administration and Maintenance (OAM) protocol to propagate a client failure indication across an MPLS-TP network in the case that propagation of failure status in the client layer is not supported as required in [RFC5860]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-csf-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-csf-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14071853.I-D@ietf.org> --NextPart-- From xqwei@fiberhome.com.cn Mon Mar 14 08:00:22 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6594E3A6DEF for ; Mon, 14 Mar 2011 08:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.639 X-Spam-Level: X-Spam-Status: No, score=0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_BASE64_TEXT=1.753] 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 p+lu5v4QKNct for ; Mon, 14 Mar 2011 08:00:21 -0700 (PDT) Received: from mail.fiberhome.com.cn (mail.fiberhome.com.cn [61.183.207.101]) by core3.amsl.com (Postfix) with ESMTP id 3A8193A6DB5 for ; Mon, 14 Mar 2011 07:59:59 -0700 (PDT) Received: from MyLaptop (111.175.127.95) by mail.fiberhome.com.cn (10.19.8.20) with Microsoft SMTP Server id 8.2.176.0; Mon, 14 Mar 2011 23:00:36 +0800 Date: Mon, 14 Mar 2011 23:01:09 +0800 From: Xueqin WEI To: MPLS Message-ID: <201103142257516097692@fiberhome.com.cn> Organization: Fiberhome Telecommunication Technologies Co.,Ltd. X-mailer: Foxmail 6, 15, 201, 23 [cn] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon225225208100_=====" Subject: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xqwei@fiberhome.com.cn List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:00:22 -0000 --=====003_Dragon225225208100_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsOg0KDQpJdCdzIG5pY2UgdG8gc2VlIGxpbmVhciBwcm90ZWN0aW9uIHVwZGF0ZWQgdG8g MDYgYW5kIHRoYW5rcyBoYXJkIHdvcmsgb2YgdGhlIGVkaXRvcnMuDQpGb2xsb3dzIGFyZSBzb21l IGNvbW1lbnRzIGFuZCBob3BlIHRoaXMgd2lsbCBiZSBoZWxwZnVsLg0KDQoNCkNvbW1lbnRzIDE6 IFBhZy41LCBzZWN0aW9uIDEuMiwgc2NvcGUgb2YgdGhlIGRvY3VtZW50cy4gU2hvdWxkIHdlIGNs ZWFybHkgbGlzdCB0aGUgY29ubmVjdGlvbiB0eXBlcyB0aGF0IHRoZSBsaW5lYXIgcHJvdGVjdGlv biBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgYXBwbGljYWJsZSB0b6O/IEJlY2F1c2UgSSBhbSBj b25mdXNlZCB3aGV0aGVyIHRoZSBsaW5lYXIgcHJvdGVjaXRvbiBjYW4gYXBwbGljYWJsZSB0byBi aXJlY3Rpb25hbCBQMlAgYXNzb2NpYXRlZCBjb25uZWN0aW9uLg0KIA0KQ29tbWVudHMgMjogUGFn LjYsIExhc3QgcGFyYWdyYXBoIG9mIHNlY3Rpb24gMS4yOiChsHRoZSBwcm90b2NvbCBtYXkgYmUg dXNlZCBieSB0aGUgaW5ncmVzcyBub2RlIG9mIHRoZSBwYXRoIHRvIG5vdGlmeSB0aGUgZmFyLXNp ZGUgZW5kIHBvaW50IHRoYXQgYSBzd2l0Y2hpbmcgY29uZGl0aW9uIGhhcyBvY2N1cnJlZCBhbmQg dmVyaWZ5IHRoZSBjb25zaXN0ZW5jeSBvZiB0aGUgZW5kIHBvaW50IGNvbmZpZ3VyYXRpb24uobEg VGhlIHRyYWZmaWMgaXMgcGVybWVybmFudGx5IGJyaWRnZWQgYXQgdGhlIGluZ3Jlc3Mgbm9kZSBh bmQgaXQgaXMgYXQgZWdyZXNzIG5vZGUgdGhlIHRyYWZmaWMgaXMgc3dpdGNoZWQuIFNvIEkgdGhp bmsgobBpbmdyZXNzIG5vZGWhsSBzaG91bGQgYmUgobBlZ3Jlc3Mgbm9kZaGxIChvciBlbmQgcG9p bnQgaXMgT0sgdG9vKS4gDQogDQpDb21tZW50cyAzOiBQYWcuOSwgc2VjdGlvbiAzLjEuIExvY2Fs IFJlcXVlc3QgTG9naWMuIKGwQ29udHJvbCBwbGFuZSAtIGlmIHRoZXJlIGlzIGEgY29udHJvbCBw bGFuZSBhY3RpdmUgaW4gdGhlIG5ldHdvcmsgKGVpdGhlciBzaWduYWxpbmcgb3Igcm91dGluZyks IGl0IE1BWSB0cmlnZ2VyIHByb3RlY3Rpb24gc3dpdGNoaW5nIGJhc2VkIG9uIGNvbmRpdGlvbnMg ZGV0ZWN0ZWQgYnkgdGhlIGNvbnRyb2wgcGxhbmUuobEgSSBzdWdnZXN0IHJlcGxhY2VkIGJ5IKGw Q29udHJvbCBwbGFuZSAtIGlmIHRoZXJlIGlzIGEgY29udHJvbCBwbGFuZSBhY3RpdmUgaW4gdGhl IG5ldHdvcmsgKGVpdGhlciBzaWduYWxpbmcgb3Igcm91dGluZyksIGl0IE1BWSB0cmlnZ2VyIHBy b3RlY3Rpb24gc3dpdGNoaW5nIGJhc2VkIG9uIGNvbmRpdGlvbnMgbm90aWZpZWQgb3IgZGV0ZWN0 ZWQgYnkgdGhlIGNvbnRyb2wgcGxhbmUuobENCiANCkNvbW1lbnRzIDQ6IFBhZy4xMiwgc2VjdGlv biAzLjQuIFBTQyBNZXNzYWdlIEdlbmVyYXRvci4gobBXaGVuIHRoZSBQU0MgY29udHJvbCBzdGF0 ZSAoc2VlIHNlY3Rpb24gMy42KSBoYXMgY2hhbmdlZCwgdGhyZWUgUFNDIG1lc3NhZ2VzIFNIT1VM RCBiZSB0cmFuc21pdHRlZCBpbiBxdWljayBzdWNjZXNzaW9uobEuIENvbnNpZGVyIHRoZSByZWNl aXZlIGVuZCBwb2ludCBtYXkgbmVlZCB0aHJlZSBmcmFtZSBjb25maXJtYXRpb24gYW5kIKGwVGhl IHRyYW5zbWlzc2lvbiBvZiB0aHJlZSByYXBpZCBwYWNrZXRzIGFsbG93cyBmb3IgZmFzdCBwcm90 ZWN0aW9uIHN3aXRjaGluZyBldmVuIGlmIG9uZSBvciB0d28gUFNDIG1lc3NhZ2VzIGFyZSBsb3N0 IG9yIGNvcnJ1cHRlZC6hsSBDb3VsZCB3ZSB0cmFuc21pdCBzaXggKG9yIG1vcmUpIFBTQyBtZXNz YWdlcyBpbiBxdWljayBzdWNjZXNzaW9uPw0KIA0KQ29tbWVudHMgNTogUGFnLjIwLCBzZWN0aW9u IDQuMy4yLiBQcmlvcml0eSBvZiBpbnB1dHMuIFRoZSBwcmlvcml0eSBvZiBGUyBpcyA0LCB0aGlz IG1lYW5zIHdoZW4gdGhlcmUgYXJlIGZhaWx1cmVzIGF0IHdvcmtpbmcgYW5kIHByb3RlY3Rpb24g cGF0aCBpbiB0aGUgc2FtZSB0aW1lLCB0aGUgdHJhZmZpYyBvbmx5IGNhbiB0cmFuc21pdHRlZCBh dCB3b3JraW5nIHBhdGguIEJ1dCBpZiB3ZSBwcm9tb3RlIHRoZSBwcmlvcml0eSBvZiBNUyB0byAz IChIaWdoZXIgdGhhbiBzaWduYWwgZmFpbCBvbiBwcm90ZWN0aW9uKSwgdGhlbiBldmVuIGluIGJv dGggd29ya2luZyBhbmQgcHJvdGVjdGlvbiBwYXRoIGZhaWx1cmUgdGhlIHRyYWZmaWMgY2FuIGJl IEZTIHRvIHByb3RlY3Rpb24gcGF0aC4gVGhpcyB3aWxsIGdpdmUgbmV0d29yayBvcGVyYXRvciBt b3JlIGZsZXhpYmlsaXR5Lg0KIA0KQ29tbWVudHMgNjogUGFnLjI0LCBzZWN0aW9uIDQuMy4zLjMu IFByb3RlY3RpbmcgYWRtaW5pc3RyYXRpdmUgc3RhdGUuIKGwSW4gdGhlIHByb3RlY3Rpbmcgc3Rh dGUgdGhlIHVzZXIgZGF0YSB0cmFmZmljIGlzIGJlaW5nIHRyYW5zcG9ydGVkIG9uIHRoZSBwcm90 ZWN0aW9uIHBhdGihsSwgSSB0aGluayBoZXJlIGlzIGFuIGVkaXRvcmlhbCBtaXN0YWtlLCBpdCBz aG91bGQgYmUgobBJbiB0aGUgcHJvdGVjdGluZyBhZG1pbmlzdHJhdGl2ZSAgc3RhdGUgdGhlIHVz ZXIgZGF0YSB0cmFmZmljIGlzIGJlaW5nIHRyYW5zcG9ydGVkIG9uIHRoZSBwcm90ZWN0aW9uIHBh dGihsQ0KIA0KQ29tbWVudHMgNzogUGFnLjI1LCBzZWN0aW9uIDQuMy4zLjMuIFByb3RlY3Rpbmcg YWRtaW5pc3RyYXRpdmUgc3RhdGUuIKGwQSBsb2NhbCBDbGVhciBTRiB3aGVuIGluIHJlbW90ZSBQ cm90ZWN0aW5nIGFkbWluaXN0cmF0aXZlIHN0YXRlIFNIT1VMRCBjbGVhciBhbnkgbG9jYWwgU0Yg Y29uZGl0aW9uIHRoYXQgbWF5IGV4aXN0LiBUaGUgTEVSIFNIQUxMIHN0b3AgdHJhbnNtaXR0aW5n IHRoZSBTRih4LDEpIG1lc3NhZ2UgYW5kIGJlZ2luIHRyYW5zbWl0dGluZyBhbiBOUigwLDEpIG1l c3NhZ2UuobEgSW4gcmVtb3RlIHByb3RlY3RpbmcgYWRtaW5pc3RyYXRpdmUgc3RhdGUsIHRoZSBs b2NhIFNGIG9ubHkgY2FuIGJlIHdvcmtpbmcgcGF0aCBTRi4gSWYgdGhlcmUgYXJlIHByb3RlY3Rp b24gcGF0aCBTRiwgdGhlIHN0YXRlIHdpbGwgYmUgVUEuIEhvdyBhYm91dCByZXBsYWNlIGFib3Zl IHRleHQgYnkgobBBIGxvY2FsIENsZWFyIG9mIFNGIHdoZW4gaW4gcmVtb3RlIFByb3RlY3Rpbmcg YWRtaW5pc3RyYXRpdmUgc3RhdGUgU0hPVUxEIGNsZWFyIGFueSBsb2NhbCBTRiBjb25kaXRpb24g b2Ygd29ya2luZyBwYXRoIHRoYXQgbWF5IGV4aXN0LiBUaGUgTEVSIFNIQUxMIHN0b3AgdHJhbnNt aXR0aW5nIHRoZSBTRigwLDEpIG1lc3NhZ2UgYW5kIGJlZ2luIHRyYW5zbWl0dGluZyBhbiBOUigw LDEpIG1lc3NhZ2UuobE/DQogDQpDb21tZW50cyA4OiBQYWcuMzUsIHNlY3Rpb24gQXBwZW5kaXgg QS4gUFNDIHN0YXRlIG1hY2hpbmUgdGFibGVzLiChsFsxMl0gVHJhbnNpdGlvbiB0byBVQSBhbmQg c2VuZCBTRigxLDApobEuIElzIHRoYXQgc2hvdWxkIGJlIKGwWzEyXSBUcmFuc2l0aW9uIHRvIFVB OlA6UiBhbmQgc2VuZCBTRigxLDApobE/DQoNCg0KDQoNCg0KU2luY2VyZWx5IFlvdXJzDQpYdWVx aW4gV2VpDQoNCkZpYmVyaG9tZSBUZWxlY29tbXVuaWNhdGlvbiBUZWNobm9sb2dpZXMgQ28uLEx0 ZC4sDQo= --=====003_Dragon225225208100_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8U1RZTEU+QkxPQ0tRVU9URSB7DQoJTUFS R0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0NCk9M IHsNCglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KDQo8TUVUQSBuYW1l PUdFTkVSQVRPUiBjb250ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE5MDE5Ij48L0hFQUQ+DQo8Qk9E WSBzdHlsZT0iTUFSR0lOOiAxMHB4Ij4NCjxESVY+PEZPTlQgZmFjZT3LzszlPjxTUEFOPkhpIGFs bDwvU1BBTj46PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOU+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOU+SXQncyBuaWNlIHRvIHNlZSBsaW5lYXIgcHJv dGVjdGlvbiB1cGRhdGVkIHRvIDA2IGFuZCB0aGFua3MgDQpoYXJkIHdvcmsgb2YgdGhlIGVkaXRv cnMuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOU+Rm9sbG93cyBhcmUgc29tZSBj b21tZW50cyBhbmQgaG9wZSB0aGlzIHdpbGwgYmUgDQpoZWxwZnVsLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT3LzszlPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3L zszlPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNt IDEwcHQiIGNsYXNzPU1zb1BsYWluVGV4dD48U1BBTiANCnN0eWxlPSJtc28taGFuc2ktZm9udC1m YW1pbHk6IMvOzOU7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDLzszlOyBtc28tZmFyZWFzdC1sYW5n dWFnZTogWkgtQ04iIA0KbGFuZz1FTi1VUz48Rk9OVCBmYWNlPcvOzOU+Q29tbWVudHMgMTogUGFn LjUsIHNlY3Rpb24gMS4yLCBzY29wZSBvZiB0aGUgZG9jdW1lbnRzLiANClNob3VsZCB3ZSBjbGVh cmx5Jm5ic3A7bGlzdCB0aGUgY29ubmVjdGlvbiB0eXBlcyB0aGF0IHRoZSBsaW5lYXIgcHJvdGVj dGlvbiANCmRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBhcHBsaWNhYmxlIHRvo78gQmVjYXVzZSBJ IGFtIGNvbmZ1c2VkIHdoZXRoZXIgdGhlIGxpbmVhciANCnByb3RlY2l0b24gY2FuIGFwcGxpY2Fi bGUgdG8gYmlyZWN0aW9uYWwgUDJQIGFzc29jaWF0ZWQgDQpjb25uZWN0aW9uLjw/eG1sOm5hbWVz cGFjZSBwcmVmaXggPSBvIG5zID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6 b2ZmaWNlIiAvPjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDEwcHQiIGNsYXNzPU1zb1BsYWluVGV4dD48U1BBTiANCnN0eWxlPSJtc28taGFu c2ktZm9udC1mYW1pbHk6IMvOzOU7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDLzszlOyBtc28tZmFy ZWFzdC1sYW5ndWFnZTogWkgtQ04iIA0KbGFuZz1FTi1VUz48bzpwPjxGT05UIGZhY2U9y87M5T4m bmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20g MTBwdCIgY2xhc3M9TXNvUGxhaW5UZXh0PjxTUEFOIA0Kc3R5bGU9Im1zby1oYW5zaS1mb250LWZh bWlseTogy87M5TsgbXNvLWJpZGktZm9udC1mYW1pbHk6IMvOzOU7IG1zby1mYXJlYXN0LWxhbmd1 YWdlOiBaSC1DTiIgDQpsYW5nPUVOLVVTPjxGT05UIGZhY2U9y87M5T5Db21tZW50cyAyOiBQYWcu NiwgTGFzdCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAxLjI6IKGwdGhlIA0KcHJvdG9jb2wgbWF5IGJl IHVzZWQgYnkgdGhlIGluZ3Jlc3Mgbm9kZSBvZiB0aGUgcGF0aCB0byBub3RpZnkgdGhlIGZhci1z aWRlIGVuZCANCnBvaW50IHRoYXQgYSBzd2l0Y2hpbmcgY29uZGl0aW9uIGhhcyBvY2N1cnJlZCBh bmQgdmVyaWZ5IHRoZSBjb25zaXN0ZW5jeSBvZiB0aGUgDQplbmQgcG9pbnQgY29uZmlndXJhdGlv bi6hsSBUaGUgdHJhZmZpYyBpcyBwZXJtZXJuYW50bHkgYnJpZGdlZCBhdCB0aGUgaW5ncmVzcyAN Cm5vZGUgYW5kIGl0IGlzIGF0IGVncmVzcyBub2RlIHRoZSB0cmFmZmljIGlzIHN3aXRjaGVkLiBT byANCkkmbmJzcDt0aGluayZuYnNwO6GwaW5ncmVzcyBub2RlobEgc2hvdWxkIGJlIKGwZWdyZXNz IG5vZGWhsSAob3IgZW5kIHBvaW50IGlzIE9LIA0KdG9vKS4gPG86cD48L286cD48L0ZPTlQ+PC9T UEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9TXNvUGxhaW5U ZXh0PjxTUEFOIA0Kc3R5bGU9Im1zby1oYW5zaS1mb250LWZhbWlseTogy87M5TsgbXNvLWJpZGkt Zm9udC1mYW1pbHk6IMvOzOU7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTiIgDQpsYW5nPUVO LVVTPjxvOnA+PEZPTlQgZmFjZT3LzszlPiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0K PFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz1Nc29QbGFpblRleHQ+PFNQQU4g DQpzdHlsZT0ibXNvLWhhbnNpLWZvbnQtZmFtaWx5OiDLzszlOyBtc28tYmlkaS1mb250LWZhbWls eTogy87M5TsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOIiANCmxhbmc9RU4tVVM+PEZPTlQg ZmFjZT3LzszlPkNvbW1lbnRzIDM6IFBhZy45LCBzZWN0aW9uIDMuMS4gTG9jYWwgUmVxdWVzdCBM b2dpYy4gDQqhsENvbnRyb2wgcGxhbmUgLSBpZiB0aGVyZSBpcyBhIGNvbnRyb2wgcGxhbmUgYWN0 aXZlIGluIHRoZSBuZXR3b3JrIChlaXRoZXIgDQpzaWduYWxpbmcgb3Igcm91dGluZyksIGl0IE1B WSB0cmlnZ2VyIHByb3RlY3Rpb24gc3dpdGNoaW5nIGJhc2VkIG9uIGNvbmRpdGlvbnMgDQpkZXRl Y3RlZCBieSB0aGUgY29udHJvbCBwbGFuZS6hsSBJIHN1Z2dlc3QgcmVwbGFjZWQgYnkgobBDb250 cm9sIHBsYW5lIC0gaWYgdGhlcmUgDQppcyBhIGNvbnRyb2wgcGxhbmUgYWN0aXZlIGluIHRoZSBu ZXR3b3JrIChlaXRoZXIgc2lnbmFsaW5nIG9yIHJvdXRpbmcpLCBpdCBNQVkgDQp0cmlnZ2VyIHBy b3RlY3Rpb24gc3dpdGNoaW5nIGJhc2VkIG9uIGNvbmRpdGlvbnMgPFNQQU4gDQpzdHlsZT0iQ09M T1I6IHJlZCI+bm90aWZpZWQgb3I8L1NQQU4+PFNQQU4gc3R5bGU9IkNPTE9SOiAjMDAyMDYwIj4g DQo8L1NQQU4+ZGV0ZWN0ZWQgYnkgdGhlIGNvbnRyb2wgcGxhbmUuobE8bzpwPjwvbzpwPjwvRk9O VD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz1Nc29Q bGFpblRleHQ+PFNQQU4gDQpzdHlsZT0ibXNvLWhhbnNpLWZvbnQtZmFtaWx5OiDLzszlOyBtc28t YmlkaS1mb250LWZhbWlseTogy87M5TsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOIiANCmxh bmc9RU4tVVM+PG86cD48Rk9OVCBmYWNlPcvOzOU+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48 L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPU1zb1BsYWluVGV4dD48 U1BBTiANCnN0eWxlPSJtc28taGFuc2ktZm9udC1mYW1pbHk6IMvOzOU7IG1zby1iaWRpLWZvbnQt ZmFtaWx5OiDLzszlOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ04iIA0KbGFuZz1FTi1VUz48 Rk9OVCBmYWNlPcvOzOU+Q29tbWVudHMgNDogUGFnLjEyLCBzZWN0aW9uIDMuNC4gUFNDIE1lc3Nh Z2UgR2VuZXJhdG9yLiANCqGwV2hlbiB0aGUgUFNDIGNvbnRyb2wgc3RhdGUgKHNlZSBzZWN0aW9u IDMuNikgaGFzIGNoYW5nZWQsIHRocmVlIFBTQyBtZXNzYWdlcyANClNIT1VMRCBiZSB0cmFuc21p dHRlZCBpbiBxdWljayBzdWNjZXNzaW9uobEuIENvbnNpZGVyIHRoZSByZWNlaXZlIGVuZCBwb2lu dCBtYXkgDQpuZWVkIHRocmVlIGZyYW1lIGNvbmZpcm1hdGlvbiBhbmQgobBUaGUgdHJhbnNtaXNz aW9uIG9mIHRocmVlIHJhcGlkIHBhY2tldHMgDQphbGxvd3MgZm9yIGZhc3QgcHJvdGVjdGlvbiBz d2l0Y2hpbmcgZXZlbiBpZiBvbmUgb3IgdHdvIFBTQyBtZXNzYWdlcyBhcmUgbG9zdCBvciANCmNv cnJ1cHRlZC6hsSBDb3VsZCB3ZSB0cmFuc21pdCBzaXggKG9yIG1vcmUpIFBTQyBtZXNzYWdlcyBp biBxdWljayANCnN1Y2Nlc3Npb24/PG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIHN0 eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9TXNvUGxhaW5UZXh0PjxTUEFOIA0Kc3R5 bGU9Im1zby1oYW5zaS1mb250LWZhbWlseTogy87M5TsgbXNvLWJpZGktZm9udC1mYW1pbHk6IMvO zOU7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTiIgDQpsYW5nPUVOLVVTPjxvOnA+PEZPTlQg ZmFjZT3LzszlPiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAxMHB0IiBjbGFzcz1Nc29QbGFpblRleHQ+PFNQQU4gDQpzdHlsZT0ibXNvLWhh bnNpLWZvbnQtZmFtaWx5OiDLzszlOyBtc28tYmlkaS1mb250LWZhbWlseTogy87M5TsgbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6IFpILUNOIiANCmxhbmc9RU4tVVM+PEZPTlQgZmFjZT3LzszlPkNvbW1l bnRzIDU6IFBhZy4yMCwgc2VjdGlvbiA0LjMuMi4gUHJpb3JpdHkgb2YgaW5wdXRzLiANClRoZSBw cmlvcml0eSBvZiBGUyBpcyA0LCB0aGlzIG1lYW5zIHdoZW4gdGhlcmUgYXJlIGZhaWx1cmVzIGF0 IHdvcmtpbmcgYW5kIA0KcHJvdGVjdGlvbiBwYXRoIGluIHRoZSBzYW1lIHRpbWUsIHRoZSB0cmFm ZmljIG9ubHkgY2FuIHRyYW5zbWl0dGVkIGF0IHdvcmtpbmcgDQpwYXRoLiBCdXQgaWYgd2UgcHJv bW90ZSB0aGUgcHJpb3JpdHkgb2YgTVMgdG8gMyAoSGlnaGVyIHRoYW4gc2lnbmFsIGZhaWwgb24g DQpwcm90ZWN0aW9uKSwgdGhlbiBldmVuIGluIGJvdGggd29ya2luZyBhbmQgcHJvdGVjdGlvbiBw YXRoIGZhaWx1cmUgdGhlIHRyYWZmaWMgDQpjYW4gYmUgRlMgdG8gcHJvdGVjdGlvbiBwYXRoLiBU aGlzIHdpbGwgZ2l2ZSBuZXR3b3JrIG9wZXJhdG9yIG1vcmUgDQpmbGV4aWJpbGl0eS48L0ZPTlQ+ PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9TXNvUGxh aW5UZXh0PjxTUEFOIA0Kc3R5bGU9Im1zby1oYW5zaS1mb250LWZhbWlseTogy87M5TsgbXNvLWJp ZGktZm9udC1mYW1pbHk6IMvOzOU7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTiIgDQpsYW5n PUVOLVVTPjxvOnA+PEZPTlQgZmFjZT3LzszlPiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9Q Pg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0IiBjbGFzcz1Nc29QbGFpblRleHQ+PFNQ QU4gDQpzdHlsZT0ibXNvLWhhbnNpLWZvbnQtZmFtaWx5OiDLzszlOyBtc28tYmlkaS1mb250LWZh bWlseTogy87M5TsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOIiANCmxhbmc9RU4tVVM+PEZP TlQgZmFjZT3LzszlPkNvbW1lbnRzIDY6IFBhZy4yNCwgc2VjdGlvbiA0LjMuMy4zLiBQcm90ZWN0 aW5nIA0KYWRtaW5pc3RyYXRpdmUgc3RhdGUuIKGwSW4gdGhlIHByb3RlY3Rpbmcgc3RhdGUgdGhl IHVzZXIgZGF0YSB0cmFmZmljIGlzIGJlaW5nIA0KdHJhbnNwb3J0ZWQgb24gdGhlIHByb3RlY3Rp b24gcGF0aKGxLCBJIHRoaW5rIGhlcmUgaXMgYW4gZWRpdG9yaWFsIG1pc3Rha2UsIGl0IA0Kc2hv dWxkIGJlIKGwSW4gdGhlIHByb3RlY3RpbmcgPFNQQU4gc3R5bGU9IkNPTE9SOiByZWQiPmFkbWlu aXN0cmF0aXZlPC9TUEFOPiANCjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 PC9TUEFOPnN0YXRlIHRoZSB1c2VyIGRhdGEgdHJhZmZpYyBpcyANCmJlaW5nIHRyYW5zcG9ydGVk IG9uIHRoZSBwcm90ZWN0aW9uIHBhdGihsTxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8 UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiIGNsYXNzPU1zb1BsYWluVGV4dD48U1BBTiAN CnN0eWxlPSJtc28taGFuc2ktZm9udC1mYW1pbHk6IMvOzOU7IG1zby1iaWRpLWZvbnQtZmFtaWx5 OiDLzszlOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ04iIA0KbGFuZz1FTi1VUz48bzpwPjxG T05UIGZhY2U9y87M5T4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJN QVJHSU46IDBjbSAwY20gMTBwdCIgY2xhc3M9TXNvUGxhaW5UZXh0PjxTUEFOIA0Kc3R5bGU9Im1z by1oYW5zaS1mb250LWZhbWlseTogy87M5TsgbXNvLWJpZGktZm9udC1mYW1pbHk6IMvOzOU7IG1z by1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTiIgDQpsYW5nPUVOLVVTPjxGT05UIGZhY2U9y87M5T5D b21tZW50cyA3OiBQYWcuMjUsIHNlY3Rpb24gNC4zLjMuMy4gUHJvdGVjdGluZyANCmFkbWluaXN0 cmF0aXZlIHN0YXRlLiChsEEgbG9jYWwgQ2xlYXIgU0Ygd2hlbiBpbiByZW1vdGUgUHJvdGVjdGlu ZyBhZG1pbmlzdHJhdGl2ZSANCnN0YXRlIFNIT1VMRCBjbGVhciBhbnkgbG9jYWwgU0YgY29uZGl0 aW9uIHRoYXQgbWF5IGV4aXN0LiBUaGUgTEVSIFNIQUxMIHN0b3AgDQp0cmFuc21pdHRpbmcgdGhl IFNGKHgsMSkgbWVzc2FnZSBhbmQgYmVnaW4gdHJhbnNtaXR0aW5nIGFuIE5SKDAsMSkgbWVzc2Fn ZS6hsSBJbiANCnJlbW90ZSBwcm90ZWN0aW5nIGFkbWluaXN0cmF0aXZlIHN0YXRlLCB0aGUgbG9j YSBTRiBvbmx5IGNhbiBiZSB3b3JraW5nIHBhdGggU0YuIA0KSWYgdGhlcmUgYXJlIHByb3RlY3Rp b24gcGF0aCBTRiwgdGhlIHN0YXRlIHdpbGwgYmUgVUEuIEhvdyBhYm91dCByZXBsYWNlIGFib3Zl IA0KdGV4dCBieSChsEEgbG9jYWwgQ2xlYXIgPFNQQU4gc3R5bGU9IkNPTE9SOiByZWQiPm9mPC9T UEFOPiBTRiB3aGVuIGluIHJlbW90ZSANClByb3RlY3RpbmcgYWRtaW5pc3RyYXRpdmUgc3RhdGUg U0hPVUxEIGNsZWFyIGFueSBsb2NhbCBTRiBjb25kaXRpb24gPFNQQU4gDQpzdHlsZT0iQ09MT1I6 IHJlZCI+b2Ygd29ya2luZyBwYXRoPC9TUEFOPiB0aGF0IG1heSBleGlzdC4gVGhlIExFUiBTSEFM TCBzdG9wIA0KdHJhbnNtaXR0aW5nIHRoZSBTRig8U1BBTiBzdHlsZT0iQ09MT1I6IHJlZCI+MDwv U1BBTj4sMSkgbWVzc2FnZSBhbmQgYmVnaW4gDQp0cmFuc21pdHRpbmcgYW4gTlIoMCwxKSBtZXNz YWdlLqGxPzxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAw Y20gMGNtIDEwcHQiIGNsYXNzPU1zb1BsYWluVGV4dD48U1BBTiANCnN0eWxlPSJtc28taGFuc2kt Zm9udC1mYW1pbHk6IMvOzOU7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDLzszlOyBtc28tZmFyZWFz dC1sYW5ndWFnZTogWkgtQ04iIA0KbGFuZz1FTi1VUz48bzpwPjxGT05UIGZhY2U9y87M5T4mbmJz cDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBw dCIgY2xhc3M9TXNvUGxhaW5UZXh0PjxTUEFOIA0Kc3R5bGU9Im1zby1oYW5zaS1mb250LWZhbWls eTogy87M5TsgbXNvLWJpZGktZm9udC1mYW1pbHk6IMvOzOU7IG1zby1mYXJlYXN0LWxhbmd1YWdl OiBaSC1DTiIgDQpsYW5nPUVOLVVTPjxGT05UIGZhY2U9y87M5T5Db21tZW50cyA4OiBQYWcuMzUs IHNlY3Rpb24gQXBwZW5kaXggQS4gUFNDIHN0YXRlIA0KbWFjaGluZSB0YWJsZXMuIKGwWzEyXSBU cmFuc2l0aW9uIHRvIFVBIGFuZCBzZW5kIFNGKDEsMCmhsS4gSXMgdGhhdCBzaG91bGQgYmUgDQqh sFsxMl0gVHJhbnNpdGlvbiB0byBVQTxTUEFOIHN0eWxlPSJDT0xPUjogcmVkIj46UDpSPC9TUEFO PiBhbmQgc2VuZCANClNGKDEsMCmhsT88bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPcvOzOU+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBm YWNlPcvOzOU+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOU+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOU+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBmYWNlPcvOzOU+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PcvOzOU+U2luY2VyZWx5IFlvdXJzPEJSPlh1ZXFpbiBXZWk8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9y87M5T48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9y87M5T5G aWJlcmhvbWUgVGVsZWNvbW11bmljYXRpb24gVGVjaG5vbG9naWVzIA0KQ28uLEx0ZC4sPC9GT05U PjxGT05UIGZhY2U9y87M5T48L0RJVj48L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon225225208100_=====-- From venkatflex@gmail.com Mon Mar 14 08:35:40 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B62ED3A6D36 for ; Mon, 14 Mar 2011 08:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Ewo+MCW10AWs for ; Mon, 14 Mar 2011 08:35:39 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 1E2033A6B32 for ; Mon, 14 Mar 2011 08:35:39 -0700 (PDT) Received: by qyk29 with SMTP id 29so1419466qyk.10 for ; Mon, 14 Mar 2011 08:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Xh1AI1BpysIbrA5a7MYo+shGWrAyVXE8h4r5IYk2HyY=; b=rWp5SKynbMeWJ3wNlAweKetPqb2QqSfVOoaS0HmX463JqyNK9HHvbf/9ZqsT4abY23 lcWCPPkwrPW6rvqZBtUUoMjCtT9T6Xt7LfkDpASg3CWXhGW7LVc0PjyQhfcdRgYzN1/y AZS3JNrCD+/RYfIKYTtQYOPHlh5Q4vSahYmXg= 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 :content-type; b=oIVbRLjZhoW21AWTHagz7rMlMjpLNtb85cCtiyKlb1YuhrpKWWKQh9+freaHaoTV3u +QsnuBsmUNqiwsfwkRNK7nCt+hvRzUeWvlObDN3niulV1PaUi32CsqT+4sIcWcxsMECZ o7opx/SB6h/6Y6VIUWOxcosNN8VLb29t90Yzw= MIME-Version: 1.0 Received: by 10.224.173.25 with SMTP id n25mr7047073qaz.124.1300117022656; Mon, 14 Mar 2011 08:37:02 -0700 (PDT) Received: by 10.224.2.210 with HTTP; Mon, 14 Mar 2011 08:37:02 -0700 (PDT) In-Reply-To: <20110313180002.12321.92801.idtracker@localhost> References: <20110313180002.12321.92801.idtracker@localhost> Date: Mon, 14 Mar 2011 11:37:02 -0400 Message-ID: From: venkatesan mahalingam To: mpls Content-Type: multipart/alternative; boundary=00032557595a4d4960049e731561 Subject: Re: [mpls] I-D Action:draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:35:40 -0000 --00032557595a4d4960049e731561 Content-Type: text/plain; charset=ISO-8859-1 Hi, As per your draft section 3.2.1.3. MPLS OAM SOURCE MEP-ID sub-TLV, Source MEP-ID TLV is mentioned only for tunnel identifiers. Don't we need source MEP-IDs for IP based Pseudowires and ICC based LSPs and Pseudowires? Thanks, Venkat. On Sun, Mar 13, 2011 at 2:00 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label Switching Working > Group of the IETF. > > > Title : Configuration of pro-active MPLS-TP Operations, > Administration, and Maintenance (OAM) Functions Using LSP Ping > Author(s) : E. Bellagamba, et al. > Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-01.txt > Pages : 20 > Date : 2011-03-13 > > This specification describes the configuration of pro-active MPLS-TP > Operations, Administration, and Maintenance (OAM) Functions for a > given LSP using a set of TLVs that is carried on LSP Ping. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > -- Best Regards, Venkatesan Mahalingam. --00032557595a4d4960049e731561 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
    As per your draft section=A03.2.1.3. =A0MPLS OAM SOURCE MEP-ID sub-= TLV, Source MEP-ID TLV is mentioned only for tunnel identifiers.
    =
    Don't we need source MEP-IDs for IP based Pseudowires an= d ICC based LSPs and Pseudowires?

    Thanks,
    Venkat.

    On Sun, Mar 13, 2011 at 2:00 PM, <Internet-Drafts@ietf.org> wrote= :
    A New Internet-Draft is available from the = on-line Internet-Drafts directories.
    This draft is a work item of the Multiprotocol Label Switching Working Grou= p of the IETF.


    =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Configuration of pro-active MPL= S-TP Operations, Administration, and Maintenance (OAM) Functions Using LSP = Ping
    =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : E. Bellagamba, et al.
    =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-mpls-lsp-ping-mpls-tp-= oam-conf-01.txt
    =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 20
    =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-13

    This specification describes the configuration of pro-active MPLS-TP
    Operations, Administration, and Maintenance (OAM) Functions for a
    given LSP using a set of TLVs that is carried on LSP Ping.

    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts= /draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-01.txt

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp= .ietf.org/internet-drafts/

    Below is the data which will enable a MIME compliant mail reader
    implementation to automatically retrieve the ASCII version of the
    Internet-Draft.


    _______________________________________________
    mpls mailing list
    mpls@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/mpls




    --
    Best Regards,
    Ve= nkatesan Mahalingam.
    --00032557595a4d4960049e731561-- From wwwrun@core3.amsl.com Mon Mar 14 08:46:47 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E3A7D3A6DE0; Mon, 14 Mar 2011 08:46:47 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: chair@ietf.org, iab-chair@iab.org, rcallon@juniper.net, swallow@cisco.com, loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110314154647.E3A7D3A6DE0@core3.amsl.com> Date: Mon, 14 Mar 2011 08:46:47 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, Steve.Trowbridge@alcatel-lucent.com, yoichi.maeda@ttc.or.jp, iab@iab.org, paf@cisco.com, iesg@ietf.org, tsbsg15@itu.int, stbryant@cisco.com, adrian.farrel@huawei.com Subject: [mpls] New Liaison Statement, "LS293 - Request for G-ACh channel codepoint to support traditional transport environment" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:46:48 -0000 Title: LS293 - Request for G-ACh channel codepoint to support traditional transport environment Submission Date: 2011-03-14 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1033 Please reply by 2011-04-01 From: Greg Jones(ITU-T SG 15) To: IESG, IAB, IETF MPLS WG(chair@ietf.org,iab-chair@iab.org,rcallon@juniper.net,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org iab@iab.org iesg@ietf.org yoichi.maeda@ttc.or.jp Steve.Trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: yoichi.maeda@ttc.or.jp Purpose: For action Body: At the February meeting of ITU-T Study Group 15, we have reached the conclusion that the needs of many of the operators participating in this work are not met by the solutions currently under development in the IETF. Therefore, we have decided to progress this work through ITU-T Recommendations. We request that the IETF provide the necessary G-ACh codepoint allocations to support this work through advancement of draft-tsb-mpls-tp-ach-ptn. Note that we have done additional work during this meeting to more clearly define the network environment for this application and produced a scope of applicability in TD522/WP3 (attached). draft-tsb-mpls-tp-ach-ptn will be updated to include this scope statement. The use of this G-ACh code point will fully comply with the framework and architecture for MPLS-TP that is currently being defined by IETF in cooperation with ITU-T. Allocation of this code point will allow ITU-T to develop the tools required to address the unique needs of the transport network and will make more efficient use of the resources of both organizations. Providing this codepoint will allow ITU-T to satisfy the immediate needs expressed at the recent Study Group 15 meeting recognizing that it is very important for ITU-T and IETF to provide timely solutions to maintain support for the MPLS-TP agreements. Attach: TD522/WP3 and C-1124 Appendix I. Attachment(s): LS293 - Request for G-ACh channel codepoint to support traditional transport environment - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1208.pdf) LS293 - Request for G-ACh channel codepoint to support traditional transport environment - pdf TD522/WP3 (https://datatracker.ietf.org/documents/LIAISON/file1209.pdf) LS293 - Request for G-ACh channel codepoint to support traditional transport environment - pdf C-1124 Appendix I (https://datatracker.ietf.org/documents/LIAISON/file1210.pdf) From Internet-Drafts@ietf.org Mon Mar 14 09:00:05 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8DA33A6DC8; Mon, 14 Mar 2011 09:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, 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 J6X4jE7otufE; Mon, 14 Mar 2011 09:00:04 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 604393A6DD1; Mon, 14 Mar 2011 09:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314160002.12937.45852.idtracker@localhost> Date: Mon, 14 Mar 2011 09:00:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-mib-management-overview-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 16:00:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview Author(s) : A. Farrel, et al. Filename : draft-ietf-mpls-tp-mib-management-overview-03.txt Pages : 28 Date : 2011-03-14 A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks. This document describes the MIB-based management architecture for MPLS-TP, indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management and identifies areas where additional MIB modules would be required. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF Consensus.] King & Venkatesan, et al. [page 1] draft-ietf-mpls-tp-mib-management-overview-03.txt March 2011 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-mib-management-overview-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-mib-management-overview-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14085202.I-D@ietf.org> --NextPart-- From phdgang@gmail.com Mon Mar 14 09:10:23 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F043A6D6F for ; Mon, 14 Mar 2011 09:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 yAVZfy+DFChD for ; Mon, 14 Mar 2011 09:10:22 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id E4F283A6972 for ; Mon, 14 Mar 2011 09:10:21 -0700 (PDT) Received: by bwz13 with SMTP id 13so5129867bwz.31 for ; Mon, 14 Mar 2011 09:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=8yP+mIs6imCUv33QPC0g7oghETMAVnCfY0zMxYiZHwA=; b=EQC5WUdrGXyeArTuJA8t6f386pWthnMrXfVyqv7+QTaKc10kI9lPIo4M8X64zWWf4F LWai8je0oYTG/kWDQkKvZy+dWq1eyYwNmP946Ezz89n4uqmkQSi46mF6m2f2Sx8D+zuM 5FwkC2afE/o4JeccUt4oP3izI4/ezkBTP6qLY= 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 :content-type; b=T90/nob4MxVNRa/RyLrWmxuwcy5LEFaYITRl5+iVYOVOT9G+LTaVjKmEjMxZTb5QrI 5RaToz0nnmo+5ck4t4GYrnyd0WWCyoVK5k/XGr6JBs9t/1P/s5b7RxRRYyvs/E0b5lcg A/1KkfeQIVqSUfWYUG4DudLcX5gXdzLZofP20= MIME-Version: 1.0 Received: by 10.204.20.143 with SMTP id f15mr4882003bkb.173.1300118782790; Mon, 14 Mar 2011 09:06:22 -0700 (PDT) Received: by 10.204.80.212 with HTTP; Mon, 14 Mar 2011 09:06:22 -0700 (PDT) In-Reply-To: <20110314154502.6000.48260.idtracker@localhost> References: <20110314154502.6000.48260.idtracker@localhost> Date: Tue, 15 Mar 2011 00:06:22 +0800 Message-ID: From: GangChen To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [mpls] I-D Action:draft-chen-mpls-6pe-mib-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 16:10:23 -0000 Hello all, A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Provider Edge Routers (6PE) Information Base (MIB) Author(s) : G. Chen, L. Li Filename : draft-chen-mpls-6pe-mib-01.txt Pages : 9 Date : 2011-03-14 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for IPv6 Provider Edge Routers (6PE)over Multiprotocol Label Switching (MPLS) Label Switching Routers (LSRs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-mpls-6pe-mib-01.txt Please kindly review. All comments are welcome. Best Regards Gang From ben@niven-jenkins.co.uk Mon Mar 14 09:32:49 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA943A6957 for ; Mon, 14 Mar 2011 09:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.518 X-Spam-Level: X-Spam-Status: No, score=-103.518 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 SorX2VLquIeq for ; Mon, 14 Mar 2011 09:32:49 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id 686A83A6DF5 for ; Mon, 14 Mar 2011 09:32:48 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-144-devlan.cachelogic.com) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PzAih-0007RB-29; Mon, 14 Mar 2011 16:34:11 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Mon, 14 Mar 2011 16:34:10 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1FDFF40B-497D-4EA0-A1A1-B8A26D36D279@niven-jenkins.co.uk> References: <20110314154502.6000.48260.idtracker@localhost> To: GangChen X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-chen-mpls-6pe-mib-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 16:32:49 -0000 Gang, Although this document extends MPLS MIBs, the original 6PE work was done = by the V6OPS & IDR WGs and I wonder if this draft should also be brought = to their attention? It doesn't contain any BGP specifics so IDR may not = be appropriate but I'm assuming some of the folks hanging out in V6OPS = may have deployed 6PE and would have views on what should be included in = a 6PE MIB. In any case the introduction states "RFC 4789[RFC4789] has elaborated = 6PE technology." which appears to be a typing mistake as it is RFC4798 = that describes 6PE. Ben On 14 Mar 2011, at 16:06, GangChen wrote: > Hello all, >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : IPv6 Provider Edge Routers (6PE) Information = Base (MIB) > Author(s) : G. Chen, L. Li > Filename : draft-chen-mpls-6pe-mib-01.txt > Pages : 9 > Date : 2011-03-14 >=20 > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes a MIB module for IPv6 Provider Edge > Routers (6PE)over Multiprotocol Label Switching (MPLS) Label > Switching Routers (LSRs). >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-mpls-6pe-mib-01.txt >=20 > Please kindly review. > All comments are welcome. >=20 > Best Regards >=20 > Gang > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From sriganeshkini@gmail.com Mon Mar 14 13:54:30 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F66C3A6B8C for ; Mon, 14 Mar 2011 13:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 V-nzjZdLi-GL for ; Mon, 14 Mar 2011 13:54:29 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id C68C53A6EDC for ; Mon, 14 Mar 2011 13:54:28 -0700 (PDT) Received: by qwg5 with SMTP id 5so1998892qwg.31 for ; Mon, 14 Mar 2011 13:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=DIlOy2BVY9soGEatoEUflqE31DGauzBrDHCl6gysmkY=; b=bjLPX98NBKzME5lzUvzkARPrHLgIKC9Y7LH8JqNBIjPkmGTHGxPyW5JHM52otI4Rv7 rY5pzU40tjfYYkalYeBt4ogId5oDeoETgWTrsWTapvUlv+vL2N9fS1ma1HE0DpDzW4xE 3hRjNqVRCqA4YXdNtkq+kB9ZW/GXLQBJYuIU8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=Jnq4GguETzJ2oo1PflcSLzMhJuw1U4Ak0EMuM3jmulbMynvVmWEeeb/+YpozZYjXmD NhJI97mCc1A7hvizMsHZB9gpm9pKjaQd8mE88m04w9FnHPPib2WUmCOkv3UOnvN5le7R Bh32F0PHfyqgU/z6s0TtoymYLANuyNs3LrDcU= Received: by 10.229.23.210 with SMTP id s18mr10503021qcb.10.1300136152251; Mon, 14 Mar 2011 13:55:52 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.229.52.65 with HTTP; Mon, 14 Mar 2011 13:55:22 -0700 (PDT) In-Reply-To: <4D7941FD.5000700@cisco.com> References: <4D7941FD.5000700@cisco.com> From: Sriganesh Kini Date: Mon, 14 Mar 2011 13:55:22 -0700 X-Google-Sender-Auth: oGwsGR0MP0tikEUHE11x3c4kCIs Message-ID: To: stbryant@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls@ietf.org" , draft-kini-mpls-frr-ldp@tools.ietf.org, Mike Shand Subject: Re: [mpls] draft-kini-mpls-frr-ldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 20:54:30 -0000 Hi Stewart, Our draft does not depend on explicitly routed tunnels. Thanks On Thu, Mar 10, 2011 at 1:26 PM, Stewart Bryant wrote: > Authors > > How does draft-kini-mpls-frr-ldp differ from > http://tools.ietf.org/html/draft-shen-mpls-ldp-nnhop-label-02 > > Thanks > > Stewart > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- - Sri From Internet-Drafts@ietf.org Mon Mar 14 14:45:13 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF5933A6F7B; Mon, 14 Mar 2011 14:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, 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 3-sphVzNjjj9; Mon, 14 Mar 2011 14:45:10 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C741B3A6F86; Mon, 14 Mar 2011 14:45:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314214506.28151.57.idtracker@localhost> Date: Mon, 14 Mar 2011 14:45:06 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-on-demand-cv-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 21:45:13 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS On-demand Connectivity Verification and Route Tracing Author(s) : N. Bahadur, et al. Filename : draft-ietf-mpls-tp-on-demand-cv-03.txt Pages : 19 Date : 2011-03-14 LSP-Ping is an existing and widely deployed OAM mechanism for MPLS LSPs. This document describes extensions to LSP-Ping so that LSP- Ping can be used for On-demand Connectivity Verification of MPLS-TP LSPs. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP-Ping to perform Connectivity Verification and Route Tracing functions in MPLS-TP networks. Finally this document updates RFC 4379 by adding a new address type and requesting a registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-on-demand-cv-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-on-demand-cv-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14143838.I-D@ietf.org> --NextPart-- From venkatflex@gmail.com Mon Mar 14 15:05:05 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21923A6BC2 for ; Mon, 14 Mar 2011 15:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 CboUfwG8kM9n for ; Mon, 14 Mar 2011 15:05:04 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id B36693A6BBA for ; Mon, 14 Mar 2011 15:05:02 -0700 (PDT) Received: by qwg5 with SMTP id 5so2044769qwg.31 for ; Mon, 14 Mar 2011 15:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=D1ZKQczJNOUQd+6j+1ySRDeuOqpuv/Gc4cHFRvwHTLg=; b=N0+0MowTLR+arIFFboSGYtupFHQRZXduvfK+wqRZ93TDeYambvW6WUCBNuKdXOuwBF d2b/rP/502rqbTGA7JU7hf2zb/NF6urtPZeiFxoYlidBZoHbe+s6y5a4d8qxHuXc2Eld 8qCKmdZd4L4I1HLk5CNm0PvXVEw9vLYm2Y+PI= 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 :content-type; b=GgDbosGEHslcq9pS9ZLJ6rWMMDvwsAh5RBbTpI6XPg95TyMERpi8x+kp2e1BHneQPo Xi0HsMP1ziXNUGKWuR9pSTcuRajTeYTNFQgPiamxyHy5837SjMYKl5XEZPwVMYhfvOXV jAYBBO3AKvu+LdGrTgqG6cquX5XNIVOIMJESM= MIME-Version: 1.0 Received: by 10.224.215.133 with SMTP id he5mr11757702qab.324.1300140386518; Mon, 14 Mar 2011 15:06:26 -0700 (PDT) Received: by 10.224.2.210 with HTTP; Mon, 14 Mar 2011 15:06:26 -0700 (PDT) In-Reply-To: <20110314214506.28151.57.idtracker@localhost> References: <20110314214506.28151.57.idtracker@localhost> Date: Mon, 14 Mar 2011 18:06:26 -0400 Message-ID: From: venkatesan mahalingam To: mpls Content-Type: multipart/alternative; boundary=20cf300514b0e58547049e78850d Subject: Re: [mpls] I-D Action:draft-ietf-mpls-tp-on-demand-cv-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 22:05:05 -0000 --20cf300514b0e58547049e78850d Content-Type: text/plain; charset=ISO-8859-1 Hi MPLS-TP On-Demand CV Authors, Per TP-identifiers-04 draft, Section 5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers, East-Global_Node_ID::East-Tunnel_Num::East-LSP_Num:: West-Global_Node_ID::West-Tunnel_Num::West-LSP_Num There is a requirement to have East and West LSP numbers for associated bidirectional tunnel, so please include both the LSP numbers in section 2.3.1. Static LSP Sub-TLV and define new TLVs for ICC based LSP and Pseudowire. Thanks, Venkat. On Mon, Mar 14, 2011 at 5:45 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label Switching Working > Group of the IETF. > > > Title : MPLS On-demand Connectivity Verification and Route > Tracing > Author(s) : N. Bahadur, et al. > Filename : draft-ietf-mpls-tp-on-demand-cv-03.txt > Pages : 19 > Date : 2011-03-14 > > LSP-Ping is an existing and widely deployed OAM mechanism for MPLS > LSPs. This document describes extensions to LSP-Ping so that LSP- > Ping can be used for On-demand Connectivity Verification of MPLS-TP > LSPs. This document also clarifies procedures to be used for > processing the related OAM packets. Further, it describes procedures > for using LSP-Ping to perform Connectivity Verification and Route > Tracing functions in MPLS-TP networks. Finally this document updates > RFC 4379 by adding a new address type and requesting a registry. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-on-demand-cv-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > -- Best Regards, Venkatesan Mahalingam. --20cf300514b0e58547049e78850d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi MPLS-TP = On-Demand CV Authors,

    Per TP-identifiers-04 draft, Section 5.2.2. =A0MPLS-TP Ass= ociated Bidirectional LSP Identifiers,
    =A0=A0 =A0 =A0East-Global_Node_ID::East-Tunnel_N= um::East-LSP_Num::
    =A0=A0 =A0 =A0West-Globa= l_Node_ID::West-Tunnel_Num::West-LSP_Num
    There is a requirement to have East and West LSP numbers for associated bid= irectional tunnel, so please include both the LSP numbers in section 2.3.1.= =A0Static LSP Sub-TLV and define new TLVs for ICC based LSP and Pseudowire= .

    Thank= s,
    Venkat.
    = On Mon, Mar 14, 2011 at 5:45 PM, <Internet-Drafts@ietf.org> wrote:
    A New Internet-Draft is available from the = on-line Internet-Drafts directories.
    This draft is a work item of the Multiprotocol Label Switching Working Grou= p of the IETF.


    =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : MPLS On-demand Connectivity Ver= ification and Route Tracing
    =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : N. Bahadur, et al.
    =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-mpls-tp-on-demand-cv-0= 3.txt
    =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 19
    =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-14

    LSP-Ping is an existing and widely deployed OAM mechanism for MPLS
    LSPs. =A0This document describes extensions to LSP-Ping so that LSP-
    Ping can be used for On-demand Connectivity Verification of MPLS-TP
    LSPs. =A0This document also clarifies procedures to be used for
    processing the related OAM packets. =A0Further, it describes procedures
    for using LSP-Ping to perform Connectivity Verification and Route
    Tracing functions in MPLS-TP networks. =A0Finally this document updates
    RFC 4379 by adding a new address type and requesting a registry.

    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-iet= f-mpls-tp-on-demand-cv-03.txt

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp= .ietf.org/internet-drafts/

    Below is the data which will enable a MIME compliant mail reader
    implementation to automatically retrieve the ASCII version of the
    Internet-Draft.


    _______________________________________________
    mpls mailing list
    mpls@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/mpls




    --
    Best Regards,
    Ve= nkatesan Mahalingam.
    --20cf300514b0e58547049e78850d-- From Internet-Drafts@ietf.org Mon Mar 14 16:30:24 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F29E3A6FF2; Mon, 14 Mar 2011 16:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, 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 IOnoDWpTG2hU; Mon, 14 Mar 2011 16:30:17 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DC2B3A6BA1; Mon, 14 Mar 2011 16:30:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314233006.11547.75287.idtracker@localhost> Date: Mon, 14 Mar 2011 16:30:06 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-16.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 23:30:24 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping Author(s) : S. Yasukawa, et al. Filename : draft-ietf-mpls-p2mp-lsp-ping-16.txt Pages : 27 Date : 2011-03-14 This document updates RFC 4379. Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. The requirement for a simple and efficient mechanism that can be used to detect data plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping". The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS P2MP environment. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-lsp-ping-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-p2mp-lsp-ping-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14162255.I-D@ietf.org> --NextPart-- From phdgang@gmail.com Mon Mar 14 20:16:21 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861CA3A697E for ; Mon, 14 Mar 2011 20:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 y-0WWIea759h for ; Mon, 14 Mar 2011 20:16:20 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 613933A6973 for ; Mon, 14 Mar 2011 20:16:20 -0700 (PDT) Received: by bwz13 with SMTP id 13so213829bwz.31 for ; Mon, 14 Mar 2011 20:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mfIJZ4QnVgtcEqvNXwJUhZLl8+6ggZ7uXEuVEN762eU=; b=AAD62JOJoWRDeQVYCpWqtF54g7m1a977OO0h5Vh+d1WV8AEzJhYdUPoPEdKvJihMiZ LQ3yiqOeVJrUhyxvA7WrRkTuML4J08dLgvnYeuyFZHobzM/CVzAqyOh7FJu0IIA4md37 LhwUhk5ejr+oLODZFnqomRxOX+07EeGWCZiEI= 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=QabO8AdASRY3uQ/fdTlWd4FozrfHhraAGa/kg8xG2srAIT6Qg7HpoV0EbjMqH7h2df CuJ01BZrkysipN/gYfJzHjLPnDT5s2JRSHq45U9JPYJgHylxb1kAErXPMTgncO33jxmh 4mgi+8ZMF0ZHWKI3rJej8Auots2du29Bxn3hg= MIME-Version: 1.0 Received: by 10.204.75.23 with SMTP id w23mr6429135bkj.200.1300156706599; Mon, 14 Mar 2011 19:38:26 -0700 (PDT) Received: by 10.204.80.212 with HTTP; Mon, 14 Mar 2011 19:38:26 -0700 (PDT) In-Reply-To: <1FDFF40B-497D-4EA0-A1A1-B8A26D36D279@niven-jenkins.co.uk> References: <20110314154502.6000.48260.idtracker@localhost> <1FDFF40B-497D-4EA0-A1A1-B8A26D36D279@niven-jenkins.co.uk> Date: Tue, 15 Mar 2011 10:38:26 +0800 Message-ID: From: GangChen To: Ben Niven-Jenkins Content-Type: text/plain; charset=ISO-8859-1 Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-chen-mpls-6pe-mib-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 03:16:21 -0000 Hello Ben, Thanks for suggestion. We will bring the draft to V6OPS for their attention. Best Regards Gang 2011/3/15, Ben Niven-Jenkins : > Gang, > > Although this document extends MPLS MIBs, the original 6PE work was done by > the V6OPS & IDR WGs and I wonder if this draft should also be brought to > their attention? It doesn't contain any BGP specifics so IDR may not be > appropriate but I'm assuming some of the folks hanging out in V6OPS may have > deployed 6PE and would have views on what should be included in a 6PE MIB. > > In any case the introduction states "RFC 4789[RFC4789] has elaborated 6PE > technology." which appears to be a typing mistake as it is RFC4798 that > describes 6PE. > > Ben > > > On 14 Mar 2011, at 16:06, GangChen wrote: > >> Hello all, >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : IPv6 Provider Edge Routers (6PE) Information Base (MIB) >> Author(s) : G. Chen, L. Li >> Filename : draft-chen-mpls-6pe-mib-01.txt >> Pages : 9 >> Date : 2011-03-14 >> >> This memo defines a portion of the Management Information Base (MIB) >> for use with network management protocols in the Internet community. >> In particular, it describes a MIB module for IPv6 Provider Edge >> Routers (6PE)over Multiprotocol Label Switching (MPLS) Label >> Switching Routers (LSRs). >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-chen-mpls-6pe-mib-01.txt >> >> Please kindly review. >> All comments are welcome. >> >> Best Regards >> >> Gang >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > From martin.vigoureux@alcatel-lucent.com Tue Mar 15 05:40:36 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119B93A6CA7 for ; Tue, 15 Mar 2011 05:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 uPMsfnSDZzeh for ; Tue, 15 Mar 2011 05:40:35 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id E41273A694E for ; Tue, 15 Mar 2011 05:40:34 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p2FCcngw007169 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 15 Mar 2011 13:41:56 +0100 Received: from [172.27.205.171] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 15 Mar 2011 13:41:31 +0100 Message-ID: <4D7F5E76.4070001@alcatel-lucent.com> Date: Tue, 15 Mar 2011 13:41:26 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "MPLS @ IETF" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [mpls] Slots requests for IETF 80 - Prague - Reminder X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 12:40:36 -0000 All, this is a reminder. Please send me your requests for a presentation slot indicating: draft name, speaker and duration Deadline for sending them is 2011-03-20 (Sunday) 24:00 UTC Thank you. regards, martin From rajiva@cisco.com Tue Mar 15 07:30:53 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BEF93A6D8F for ; Tue, 15 Mar 2011 07:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.867 X-Spam-Level: X-Spam-Status: No, score=-8.867 tagged_above=-999 required=5 tests=[AWL=-1.731, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 k5eG5wKSDJ+K for ; Tue, 15 Mar 2011 07:30:52 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 53E963A6D85 for ; Tue, 15 Mar 2011 07:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=726; q=dns/txt; s=iport; t=1300199537; x=1301409137; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=ljvNvR5nJIIpWtudrisB4QhU3aUOG4uY0s9M0OKbB4w=; b=S+rT1hRaYkP8SSYq5J2igcJgOf2BLjS+9W1LKIE2tYEfMpVCjZRunqO9 5i1PgSeLLwl36kUHpLkhqyH5EhY0QoR6RP5beXlZTMI0cM19Kw5XbGWKu 4x6YusCswFuFpwVHmznMlpbLBG00V/EkBnJDFQV1R0koEnMjZZJAgjwa2 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAAIVf02tJXG8/2dsb2JhbAClO1MCd6VMnQmFYgSMXYNV X-IronPort-AV: E=Sophos;i="4.62,322,1297036800"; d="scan'208";a="320476854" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2011 14:32:13 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2FEWDnU015312; Tue, 15 Mar 2011 14:32:13 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 09:32:13 -0500 Received: from 72.163.63.13 ([72.163.63.13]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Mar 2011 14:32:13 +0000 References: <4D7F5E76.4070001@alcatel-lucent.com> Content-Transfer-Encoding: quoted-printable Thread-Topic: [mpls] Slots requests for IETF 80 - Prague - Reminder Thread-Index: AcvjHcZdJK807ry6Sj20lTfuGgc11g== From: "Rajiv Asati (rajiva)" Content-Type: text/plain; charset="us-ascii" In-Reply-To: <4D7F5E76.4070001@alcatel-lucent.com> Message-ID: <5AC8CCB5-5A43-4634-A5C9-53F6211EFAB5@cisco.com> Date: Tue, 15 Mar 2011 10:32:07 -0400 To: "Martin Vigoureux" MIME-Version: 1.0 (iPhone Mail 8F190) X-OriginalArrivalTime: 15 Mar 2011 14:32:13.0963 (UTC) FILETIME=[C6D585B0:01CBE31D] Cc: "MPLS @ IETF" Subject: Re: [mpls] Slots requests for IETF 80 - Prague - Reminder X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 14:30:53 -0000 Martin, Draft-ietf-mpls-ldp-ipv6;=20 Rajiv Asati; 10mins Draft-asati-pignataro-mpls-ldp-gtsm Rajiv Asati; 10mins Draft-asati-pignataro-mpls-ldp-iana; Rajiv Asati; 5mins Cheers, Rajiv Sent from my Phone On Mar 15, 2011, at 8:42 AM, "Martin Vigoureux" wrote: > All, >=20 > this is a reminder. > Please send me your requests for a presentation slot indicating: > draft name, speaker and duration >=20 > Deadline for sending them is 2011-03-20 (Sunday) 24:00 UTC >=20 > Thank you. >=20 > regards, > martin >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From larryli888@yahoo.com.cn Tue Mar 15 09:17:20 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE3D43A6DDD for ; Tue, 15 Mar 2011 09:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_RECV_IP_061050=1.544, SARE_SUB_ENC_UTF8=0.152] 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 R2z5gRzyUhrn for ; Tue, 15 Mar 2011 09:17:19 -0700 (PDT) Received: from web15603.mail.cnb.yahoo.com (web15603.mail.cnb.yahoo.com [202.165.102.57]) by core3.amsl.com (Postfix) with SMTP id B7C2A3A6C5B for ; Tue, 15 Mar 2011 09:17:18 -0700 (PDT) Received: (qmail 82591 invoked by uid 60001); 15 Mar 2011 16:18:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1300205918; bh=Flu+RWMNmvrd3KUHzwyT3+C16t0NT38vziUG7bAs8MM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bj5aVevy5gXz8Keobq9v0LSWajgCVXdhvyZZv9LOYKSI6mLaPrSjX4+Gkqg/3MSeOxhFt4433PGvpSLGKrUd8g4vkawBYdYyeskApwMSgvRP3U5a0ATAkHmMKZJlD7ROqqNKNAqbGo/0IFZMM2K+uOZPa8/v3H2J6tri2ZEt12A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GAPWYIfRMFShL9iflKl4qBB6zpIXqb3vTgeIN+S7EetOc1/aCyvajrbKbtK8z/4C8G0R/e91NSHTEIo4lBpc87dTuX5LFJ+28DfYhyDeMTFm3PqKqEfnIHYO6SfXNOtaJvWqZ5o8746klFuX6Glw+0apeHoltArulYoJrj7dSb0=; Message-ID: <765245.77484.qm@web15603.mail.cnb.yahoo.com> X-YMail-OSG: FKIO2bUVM1nxiVtb.fjAr3y0Ln_LoFbICt_sEQcCbWbhoSx QqKEGnJZFiGn0z_LeqkxtILAxKeZz2c0wAW8YdeSWtoCvi4RpDS6dmWEubIA TC6mcwl2Q47.28w_gyaeQGpye6kfmhynTBHIG1IyGMNstXjHxb_pNq79Zq1Q hpPr38FEAz_kxkddpJ..Mfvk0HXYL9V.MYqd1iJ8srC2a0w4E3xpO1Z6Yjfu 4AO1v1eZ5z5JHJBby Received: from [61.50.133.14] by web15603.mail.cnb.yahoo.com via HTTP; Wed, 16 Mar 2011 00:18:38 CST X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.295617 Date: Wed, 16 Mar 2011 00:18:38 +0800 (CST) From: Larry To: chair@ietf.org, iab-chair@iab.org, rcallon@juniper.net, swallow@cisco.com, loa@pi.nu, tsbsg15@itu.int In-Reply-To: <20110314154647.E3A7D3A6DE0@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org, greg.jones@itu.int, Steve.Trowbridge@alcatel-lucent.com, yoichi.maeda@ttc.or.jp, iab@iab.org, hiroshi.ota@itu.int, iesg@ietf.org, tsbsg15@itu.int, paf@cisco.com, adrian.farrel@huawei.com, stbryant@cisco.com Subject: [mpls] =?utf-8?b?5Zue5aSN77yaICBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJM?= =?utf-8?q?S293_-_Request_for_G-ACh_channel_codepoint_to_support_tradition?= =?utf-8?q?al_transport_environment=22?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 16:17:20 -0000 Support! ************************************************************************* Han Li, Ph.D=20 China Mobile Research Institute Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China=20 Fax: +86 10 63601087=20 MOBILE: 13501093385=20 ************************************************************************* --- 11=E5=B9=B43=E6=9C=8814=E6=97=A5=EF=BC=8C=E5=91=A8=E4=B8=80, Greg Jones= =E5=86=99=E9=81=93=EF=BC=9A > =E5=8F=91=E4=BB=B6=E4=BA=BA: Greg Jones > =E4=B8=BB=E9=A2=98: [mpls] New Liaison Statement, "LS293 - Request for G-= ACh channel codepoint to support traditional transport environment" > =E6=94=B6=E4=BB=B6=E4=BA=BA: chair@ietf.org, iab-chair@iab.org, rcallon@j= uniper.net, swallow@cisco.com, loa@pi.nu > =E6=8A=84=E9=80=81: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.in= t, Steve.Trowbridge@alcatel-lucent.com, yoichi.maeda@ttc.or.jp, iab@iab.org= , paf@cisco.com, iesg@ietf.org, tsbsg15@itu.int, stbryant@cisco.com, adrian= .farrel@huawei.com > =E6=97=A5=E6=9C=9F: 2011=E5=B9=B43=E6=9C=8814=E6=97=A5,=E5=91=A8=E4=B8=80= ,=E4=B8=8B=E5=8D=8811:46 >=20 > Title: LS293 - Request for G-ACh channel codepoint to > support traditional transport environment > Submission Date: 2011-03-14 > URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_det= ail.cgi?detail_id=3D1033 >=20 > Please reply by 2011-04-01 >=20 > From: Greg Jones(ITU-T SG 15) > To: IESG, IAB, IETF MPLS WG(chair@ietf.org,iab-chair@iab.org,rcallon@juni= per.net,swallow@cisco.com,loa@pi.nu) > Cc: paf@cisco.com > stbryant@cisco.com > adrian.farrel@huawei.com > mpls@ietf.org > iab@iab.org > iesg@ietf.org > yoichi.maeda@ttc.or.jp > Steve.Trowbridge@alcatel-lucent.com > Reponse Contact: tsbsg15@itu.int > greg.jones@itu.int > hiroshi.ota@itu.int > Technical Contact: yoichi.maeda@ttc.or.jp > Purpose: For action=20 > Body: At the February meeting of ITU-T Study Group 15, we > have reached the conclusion that the needs of many of the > operators participating in this work are not met by the > solutions currently under development in the IETF. > Therefore, we have decided to progress this work through > ITU-T Recommendations. We request that the IETF provide the > necessary G-ACh codepoint allocations to support this work > through advancement of draft-tsb-mpls-tp-ach-ptn. Note that > we have done additional work during this meeting to more > clearly define the network environment for this application > and produced a scope of applicability in TD522/WP3 > (attached). draft-tsb-mpls-tp-ach-ptn will be updated to > include this scope statement. > The use of this G-ACh code point will fully comply with the > framework and architecture for MPLS-TP that is currently > being defined by IETF in cooperation with ITU-T.=C2=A0 > Allocation of this code point will allow ITU-T to develop > the tools required to address the unique needs of the > transport network and will make more efficient use of the > resources of both organizations.=C2=A0 Providing this > codepoint will allow ITU-T to satisfy the immediate needs > expressed at the recent Study Group 15 meeting recognizing > that it is very important for ITU-T and IETF to provide > timely solutions to maintain support for the MPLS-TP > agreements. >=20 > Attach: TD522/WP3 and C-1124 Appendix I. > Attachment(s): > =C2=A0 =C2=A0=C2=A0=C2=A0LS293 - Request for G-ACh channel > codepoint to support traditional transport environment - pdf > body (https://datatracker.ietf.org/documents/LIAISON/file1208.pdf) > =C2=A0 =C2=A0=C2=A0=C2=A0LS293 - Request for G-ACh channel > codepoint to support traditional transport environment - pdf > TD522/WP3 (https://datatracker.ietf.org/documents/LIAISON/file1209.pdf) > =C2=A0 =C2=A0=C2=A0=C2=A0LS293 - Request for G-ACh channel > codepoint to support traditional transport environment - pdf > C-1124 Appendix I (https://datatracker.ietf.org/documents/LIAISON/file121= 0.pdf) >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > =0A=0A=0A From curtis@occnc.com Tue Mar 15 14:00:30 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3F6C3A6EC6 for ; Tue, 15 Mar 2011 14:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 QqxS-RS8985N for ; Tue, 15 Mar 2011 14:00:29 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 631C73A6ED2 for ; Tue, 15 Mar 2011 14:00:29 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p2FL1rrh000181; Tue, 15 Mar 2011 17:01:53 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201103152101.p2FL1rrh000181@harbor.orleans.occnc.com> To: Alexander Vainshtein From: Curtis Villamizar In-reply-to: Your message of "Mon, 14 Mar 2011 07:36:49 +0200." Date: Tue, 15 Mar 2011 17:01:53 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , "Zhao, Peng \(NSN - CN/Shanghai\)" , "Pietilainen, Antti \(NSN - FI/Espoo\)" , "Mallette, Edwin" , "stbryant@cisco.com" Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 21:00:30 -0000 In message Alexander Vainshtein writes: > > Curtis, > Lots of thanks for a detailed response. Last call ended but its still useful to reply to indeicate where we are in agreement. > I think that we partially agree regarding applicability (or > non-applicability) of delay measurements for such purposes as > estimating packet delay variation: > - we agree that without specifying the point in the data path where > the timestamps are taken, delay measurements may be unsuitable for > this purpose > - we disagree regarding how jitter buffers should be set up. In > particular, the customers do not like the idea of giving them "a > generous margin" because this would result in increasing end-to-end > delay of the emulated TDM circuit; and in most applications there is a > strict delay budget for this. Neither do they like setting these by > trial and error. You can vary the multiplier on delay standard deviation to provide less generous jitter buffers at the expense of possible loss. This is out of scope of the draft. > One way to resolve our partial agreement would be to explicitly state > in the draft that applicability of the results of the delay > measurements to any specific needs is out of scope of the draft and > is implementation-specific. That would be implied. Maybe at most a reminder that the delay measurement when using a preferred QoS on OAM packets would tend to measure minimal delay. Vendors and providers can infer what a measurement of minimum delay is or is not applicable to. I don't really see a need for change. > Regarding accuracy of the delay measurement, we seem to be mostly in > agreement. However, I'd like to notice that the accuracy of 2-way > delay measurement does not depend on accuracy of ToD synchronization > between the nodes. Yes. Two way delay is unaffected by time of day sync. > Regards, > Sasha Curtis > ________________________________________ > From: curtis@occnc.com [curtis@occnc.com] > Sent: Monday, March 14, 2011 4:59 AM > To: Alexander Vainshtein > Cc: curtis@occnc.com; mpls@ietf.org; Zhao, Peng (NSN - CN/Shanghai); Pietilainen, Antti (NSN - FI/Espoo); stbryant@cisco.com; Mallette, Edwin > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp > > In message > Alexander Vainshtein writes: > > > > Curtis, > > Lots of thanks for a prompt and delayed response. > > > > Please see some comments inline below. I've shipped the next that is not related to these comments. > > > > Regards, > > Sasha > > > > > -----Original Message----- > > > From: curtis@occnc.com [mailto:curtis@occnc.com] > > > Sent: Wednesday, March 09, 2011 2:06 AM > > > To: Alexander Vainshtein > > > Cc: curtis@occnc.com; mpls@ietf.org; Zhao, Peng (NSN - CN/Shanghai); > > > Pietilainen, Antti (NSN - FI/Espoo); tictoc@ietf.org; > > > stbryant@cisco.com; Mallette, Edwin > > > Subject: Re: [mpls] draft-ietf-mpls-loss-delay Timestamp > > > > > --- snipped --- > > > > 2. The "timestamp capture point in the data path" was not about the > > > > timestamp location in the message. It is about the stage of the data > > > > processing when the timestamp can be captured. E.g., some designs use > > > > commercial HW that captures the timestamps between PHY and MAC. This > > > > is OK for PTP and NTP, but excludes the time spent in the egress > > > queue > > > > of the node from delay measurement. > > > > > > That is why in NTP, PTP, and draft-ietf-mpls-loss-delay there are four > > > timestamps. The total round trip delay subtracts the third and second > > > to eliminate queuing and turn around. > > [[[Sasha]]] Please consider the following use case: > > - I am going to use a certain LSP as a tunnel for TDM PWs > > - I would like to measure packet delay *variation* (PDV) introduced by > > this LSP in order to configure the jitter buffer of these TDM PWs. I > > expect to do that by measuring delay for multiple samples and > > computing the PDV as (Max. measured delay - Min. measured delay) > > - If queuing delay at the LSP head- and tail-nodes is not accounted in > > my delay measurements, my PDV estimation will not account for that > > also (because queuing only increases Max. measured delay) > > - As a consequence, my PDV estimation may be not suitable for > > configuring the jitter buffer correctly. As a consequence, my TDM > > customers will see errors in their traffic when TDM PW packets that > > arrive too late to be accommodated into the jitter buffer are > > discarded and their payload replaced with "all ones". > > Do I miss something here? > > > I would say yeah sort of. This is slightly out of scope of the draft > which is measuring the delay of the segment or LSP. > > If you took that delay (which is a minimum delay) and used it to set > jitter buffers, you'd have very unhappy customers. Jitter buffers are > normally set by measuring the delay experienced by the service and > adding a generous safety margin based on estimate of std dev. > > Again, this is a usage (that you envision and that I don't share) but > the usage is out of scope regarding discussion of the draft itself. > > > > > > 3. You have said that 20 microseconds look to you as very good > > > > accuracy for delay measurements. This probably depends on the > > > > application. E.g., if we must synchronize two base stations within 2- > > > 3 > > > > microseconds of relative ToD error, this accuracy will hardly help > > > you > > > > to understand why your synchronization mechanisms do not work:-). I > > > > am somewhat suspicious about a measurement procedure that does not > > > > specify accuracy explicitly. But I understand the position taken by > > > > the draft authors. > > > > > > 20 usec is OK for draft-ietf-mpls-loss-delay type measurements. > > [[[Sasha]]] I would be happy to accept that. But the draft does not > > yield this (or any other) number. > > You snipped something important here. I was enumerating the timestamp > formats and mentioned that the NTP 32 bit format would be more than > adequate for most delay measurements. > > Later (snipped below) I mention that draft-ietf-mpls-loss-delay puts > any timestamp format into 64 bits so there is no sense in using the 32 > bit format. > > It is extremely difficult to know the accuracy (with any accuracy :). > It depends on the accuracy of time synchronization which may not be > known. > > > --- snipped to the end --- From loa@pi.nu Tue Mar 15 16:24:52 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C82973A6F11 for ; Tue, 15 Mar 2011 16:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 41bXd6qYqvmd for ; Tue, 15 Mar 2011 16:24:51 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 89BD93A6DC6 for ; Tue, 15 Mar 2011 16:24:51 -0700 (PDT) Received: from pi.nu (localhost [127.0.0.1]) by mail.pi.nu (Postfix) with ESMTP id 3B64F2A8002; Wed, 16 Mar 2011 00:26:15 +0100 (CET) Received: from 129.192.170.250 (SquirrelMail authenticated user loa@pi.nu) by pi.nu with HTTP; Wed, 16 Mar 2011 00:26:15 +0100 Message-ID: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> Date: Wed, 16 Mar 2011 00:26:15 +0100 From: loa@pi.nu To: mpls@ietf.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: MPLS-TP ad hoc team Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 23:24:52 -0000 Working Group, this is to start a 3 week working group last call on draft-ietf-mpls-tp-on-demand-cv-03 Please send comments to the working group mailing list mpls@ietf.org The working group last call ends on April 8, 2011. /Loa From wwwrun@rfc-editor.org Tue Mar 15 17:33:59 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0E303A6F04; Tue, 15 Mar 2011 17:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.121 X-Spam-Level: X-Spam-Status: No, score=-102.121 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 K4-c9jxd+yO8; Tue, 15 Mar 2011 17:33:59 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 37C423A6F19; Tue, 15 Mar 2011 17:33:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3AE42E075F; Tue, 15 Mar 2011 17:35:25 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110316003525.3AE42E075F@rfc-editor.org> Date: Tue, 15 Mar 2011 17:35:25 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6178 on Label Edge Router Forwarding of IPv4 Option Packets X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 00:34:00 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6178 Title: Label Edge Router Forwarding of IPv4 Option Packets Author: D. Smith, J. Mullooly, W. Jaeger, T. Scholl Status: Standards Track Stream: IETF Date: March 2011 Mailbox: djsmith@cisco.com, jmullool@cisco.com, wjaeger@att.com, tscholl@nlayer.net Pages: Characters: 21645 Updates: RFC3031 I-D Tag: draft-ietf-mpls-ip-options-07.txt URL: http://www.rfc-editor.org/rfc/rfc6178.txt This document specifies how Label Edge Routers (LERs) should behave when determining whether to MPLS encapsulate an IPv4 packet with header options. Lack of a formal standard has resulted in different LER forwarding behaviors for IPv4 packets with header options despite being associated with a prefix-based Forwarding Equivalence Class (FEC). IPv4 option packets that belong to a prefix-based FEC, yet are forwarded into an IPv4/MPLS network without being MPLS- encapsulated, present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulate IPv4 packets with header options cannot operate in certain MPLS environments. While this newly defined LER behavior is mandatory to implement, it is optional to invoke. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From zhang.fei3@zte.com.cn Wed Mar 16 02:56:42 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2363A68E0; Wed, 16 Mar 2011 02:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.75 X-Spam-Level: X-Spam-Status: No, score=-100.75 tagged_above=-999 required=5 tests=[AWL=1.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 vSdan1JKQ8Uf; Wed, 16 Mar 2011 02:56:42 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 0BFD13A68C8; Wed, 16 Mar 2011 02:56:40 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35102967892178; Wed, 16 Mar 2011 17:55:42 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 84746.2967892178; Wed, 16 Mar 2011 17:53:20 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p2G9rDmS059824; Wed, 16 Mar 2011 17:53:13 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) To: pwe3 , mpls@ietf.org, "mpls-tp@ietf.org" MIME-Version: 1.0 X-KeepSent: A1CBEEB2:AE53C172-48257855:003575BA; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Wed, 16 Mar 2011 17:53:28 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-16 17:53:16, Serialize complete at 2011-03-16 17:53:16 Content-Type: multipart/alternative; boundary="=_alternative 0036508048257855_=" X-MAIL: mse02.zte.com.cn p2G9rDmS059824 Subject: [mpls] draft-zhang-mpls-tp-pw-oam-config-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 09:56:43 -0000 This is a multipart message in MIME format. --=_alternative 0036508048257855_= Content-Type: text/plain; charset="US-ASCII" Hi all, We have updated the document about the MPLS-TP PW OAM configuration, below is the link: http://tools.ietf.org/html/draft-zhang-mpls-tp-pw-oam-config-04 Comapred to last version, we put the MPLS-TP PW OAM capability negotiation into the LDP initializaiton message, and the other parts are almost editoral in nature. We will be apprecaited if you can review and give any comments. Thanks Fei --=_alternative 0036508048257855_= Content-Type: text/html; charset="US-ASCII"
    Hi all,
     
    We have updated the document about the MPLS-TP PW OAM configuration, below is the link:

    http://tools.ietf.org/html/draft-zhang-mpls-tp-pw-oam-config-04

    Comapred to last version, we put the MPLS-TP PW OAM capability negotiation into the LDP initializaiton message, and the other parts are almost editoral in nature.

    We will be apprecaited if you can  review and give any comments.

    Thanks

    Fei     --=_alternative 0036508048257855_=-- From stbryant@cisco.com Wed Mar 16 05:47:11 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62AFA3A698F for ; Wed, 16 Mar 2011 05:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.465 X-Spam-Level: X-Spam-Status: No, score=-110.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 FJjrEgZHGKMI for ; Wed, 16 Mar 2011 05:47:10 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id DE6763A698E for ; Wed, 16 Mar 2011 05:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=303; q=dns/txt; s=iport; t=1300279716; x=1301489316; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=9j4228SWWempBdbfHg2dQZHXmJJaGr0yaEIQ9EwpeZE=; b=B8jOEtMSlY/dv40C2y+tC8YTuWkzlhI5LNOXJ+h1qRgYsVliWWdJScpD DGWZQi3OBqBQ/5815t5/j1K/ih17uvYRjZ/6GgZWt5JEYj+cBq68kJmCU pyN6IzRwwXTf56eFwFrwLzftHsUTsGUQF17HWFHQufRsHdSPAMbvrZv5a 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoEACJOgE2Q/khMgWdsb2JhbACmCBQBARYmJaRrgmsOAZlahWIEjF4 X-IronPort-AV: E=Sophos;i="4.63,194,1299456000"; d="scan'208";a="21950037" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 16 Mar 2011 12:48:35 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2GCmZoM022941 for ; Wed, 16 Mar 2011 12:48:35 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p2GCmWU23759; Wed, 16 Mar 2011 12:48:34 GMT Message-ID: <4D80B1A0.7000907@cisco.com> Date: Wed, 16 Mar 2011 12:48:32 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] G.8110.1 now in ITU Last Call X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 12:47:11 -0000 Last call has started on G.8110.1, finishes on 12th April http://www.itu.int/itu-t/aap/AAPRecDetails.aspx?AAPSeqNo=2281 We have the comments raised under https://datatracker.ietf.org/documents/LIAISON/file1184.txt Are there any other comments that need to be submited via ISOC? Stewart From malcolm.betts@zte.com.cn Wed Mar 16 07:54:39 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2404A3A6954 for ; Wed, 16 Mar 2011 07:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.728 X-Spam-Level: X-Spam-Status: No, score=-100.728 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 9aONBmjwxOI8 for ; Wed, 16 Mar 2011 07:54:38 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 9EB993A699E for ; Wed, 16 Mar 2011 07:54:37 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 5083806486374; Wed, 16 Mar 2011 22:55:15 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 84746.2581014427; Wed, 16 Mar 2011 22:55:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p2GEtqqF087005; Wed, 16 Mar 2011 22:55:52 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <4D80B1A0.7000907@cisco.com> To: mpls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Wed, 16 Mar 2011 09:55:58 -0500 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-16 22:55:56, Serialize complete at 2011-03-16 22:55:56 Content-Type: multipart/alternative; boundary="=_alternative 005204C485257855_=" X-MAIL: mse02.zte.com.cn p2GEtqqF087005 Cc: stbryant@cisco.com Subject: Re: [mpls] G.8110.1 now in ITU Last Call X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 14:54:39 -0000 This is a multipart message in MIME format. --=_alternative 005204C485257855_= Content-Type: text/plain; charset="US-ASCII" All, Initiating this last call was an error since the final text is not yet available (at the meeting we requested an additional 30 days to prepare the text). The ITU web site has been updated to reflect this. Regards, Malcolm Stewart Bryant Sent by: mpls-bounces@ietf.org 16/03/2011 08:48 AM Please respond to stbryant@cisco.com To "mpls@ietf.org" cc Subject [mpls] G.8110.1 now in ITU Last Call Last call has started on G.8110.1, finishes on 12th April http://www.itu.int/itu-t/aap/AAPRecDetails.aspx?AAPSeqNo=2281 We have the comments raised under https://datatracker.ietf.org/documents/LIAISON/file1184.txt Are there any other comments that need to be submited via ISOC? Stewart _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --=_alternative 005204C485257855_= Content-Type: text/html; charset="US-ASCII"
    All,

    Initiating this last call was an error since the final text is not yet available (at the meeting we requested an additional 30 days to prepare the text).  The ITU web site has been updated to reflect this.

    Regards,

    Malcolm



    Stewart Bryant <stbryant@cisco.com>
    Sent by: mpls-bounces@ietf.org

    16/03/2011 08:48 AM
    Please respond to
    stbryant@cisco.com
    To
    		"mpls@ietf.org" <mpls@ietf.org>
    cc
    Subject
    		[mpls] G.8110.1 now in ITU Last Call





    Last call has started on G.8110.1, finishes on 12th April

    http://www.itu.int/itu-t/aap/AAPRecDetails.aspx?AAPSeqNo=2281

    We have the comments raised under

    https://datatracker.ietf.org/documents/LIAISON/file1184.txt

    Are there any other comments that  need to be submited via ISOC?

    Stewart

    _______________________________________________
    mpls mailing list
    mpls@ietf.org
    https://www.ietf.org/mailman/listinfo/mpls
    --=_alternative 005204C485257855_=-- From lavanya.srivatsa@aricent.com Thu Mar 17 02:14:43 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB24C3A6839 for ; Thu, 17 Mar 2011 02:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 6qJmhBzHVqzY for ; Thu, 17 Mar 2011 02:14:42 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by core3.amsl.com (Postfix) with ESMTP id 4EF5F3A67CC for ; Thu, 17 Mar 2011 02:14:40 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id ABDB936B3C for ; Thu, 17 Mar 2011 14:42:45 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id 9549236B3D for ; Thu, 17 Mar 2011 14:42:45 +0530 (IST) Received: from GUREXMB02.ASIAN.AD.ARICENT.COM ([10.203.171.132]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Thu, 17 Mar 2011 14:46:06 +0530 From: Lavanya Srivatsa To: MPLS TP , "mpls@ietf.org" Date: Thu, 17 Mar 2011 14:46:04 +0530 Thread-Topic: Comments on draft-ietf-mpls-tp-linear-protection-06.txt Thread-Index: AcvkeK8hutvfRZeXSZymrltxfoQJoAACOzwg Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E13C8C03049AFA4E9CEE5A21D3E7F85D020DE13549GUREXMB02ASIA_" MIME-Version: 1.0 Subject: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 09:14:43 -0000 --_000_E13C8C03049AFA4E9CEE5A21D3E7F85D020DE13549GUREXMB02ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To the authors, I have a list of protection switching scenarios that do not seem to result = in expected behaviour if operating as per this draft. I have proposed solut= ions/alternate text. I would appreciate your comments/confirmation on the s= ame. Scenario 1 Assume that there is a revertive protection switching group set up between = routers R1 and R5 for working LSP1 and protection LSP2 [Sequence of events] Both R1 and R5 in Normal state --> SF on R1 --> FS on R5 --> FS clear on R5 [Result] Both R1 and R5 going to Normal state with NR(0,0) [Problem] The above is an incorrect state on R1 since the local Signal Fail still exi= sts and has not been cleared. So R1 should have moved back to the local Pro= tecting Failure state transmitting SF(1,1) instead of going to the NR(0,0) = state. [Suggested Solution] In Section 4.3.3.3, the 2nd last bullet item under remote messages needs to= be modified as - "A remote NR(0,0) message SHALL be ignored if in local Pr= otecting administrative state. If in remote Protecting administrative stat= e then the LER SHALL go to Normal state and begin transmitting a NR(0,0) me= ssage OR shall go to the local Protecting Failure state if local Signal Fai= lure is still reasserted and begin transmitting SF(1,1). Scenario 2 Assume that there is a non-revertive protection switching set up between ro= uters R1 and R5 for working LSP1 and protection LSP2. [Sequence of events] Both R1 and R5 in Normal state --> SF on R1 --> SF clear on R1 --> FS on R1= --> FS clear on R1 [Result] Both R1 and R5 going to Normal state with NR(0,0) [Problem] Upon clearing the Forced Switch at R1, it is expected to go local Do-Not-Re= vert state again and begin transmitting DNR(0,1). Upon receiving this R5 is= expected to go to remote Do-Not-Revert state. [Suggested Solution] In Section 4.3.3.3, the 1st bullet item under local input needs to be modif= ied as - "A local Clear SHOULD be ignored if in remote Protecting administr= ative state. If in local Protecting administrative state then this input S= HALL cause the LER to go into Normal state and begin transmitting a NR(0,0)= message if in revertive mode or go into Do-Not-Revert state and begin tran= smitting DNR(0,1) if in non-revertive mode. Scenario 3 Assume that there is a protection switching set up between routers R1 and R= 5 for working LSP1 and protection LSP2 where R1 is operating in the reverti= ve mode and R5 is operating in the non-revertive mode. [Sequence of events] Both R1 and R5 in Normal state --> SF on R1 --> SF clear on R1 [Result] R5 moves to Wait-to-restore state and begins transmitting NR(0,1) [Problem] R5 is in non-revertive mode and as such does not have a Wait-to-restore sta= te. [Suggested Solution] In Section 4.3.3.4, the 4th bullet under remote messages needs to be modifi= ed as - "If in remote Protecting failure state, a remote Wait-to-Restore me= ssage SHALL cause the LER to go into remote Wait-to-Restore state if in rev= ertive mode and into remote Do-Not-Revert state if in non-revertive mode an= d continue transmission of the current message. I have worked out the exact sequence details of the state machine for the s= cenarios above, which I have listed below. - Lavanya DETAILED SEQUENCE Scenario 1 Assume that there is a revertive protection switching group set up between = routers R1 and R5 for working LSP1 and protection LSP2. Intially both are in Normal state sending NR(0,0) to each other. Now if R1 detects a Signal Failure, R1 moves to the local Protecting Failur= e state and sends SF(1,1) to R5. R5, on receiving SF(1,1), now moves to the remote Protecting Failure state = and will transmit NR(0,1) to R1. R1, on receiving NR(0,1), will ignore the message. Now issue a Forced Switch command on R5. R5 will now move to the local Protecting Administrative state and start tra= nsmitting FS(1,1). R1, on receiving FS(1,1), now moves to remote Protecting Adminstrative stat= e and since it was earlier in local Protecting Failure state, it will now t= ransmit SF(1,1) to R5. R5, on receiving SF(1,1) from R1, will ignore the message since there is an= active Local Forced Switch command. Now issue a Clear command on R5 for clearing the Forced Switch. R5 will now move to the Normal state since it was in local Protecting Admin= strative state and start transmitting NR(0,0). R1, on receiving NR(0,0), will go to Normal state since it was in remote Pr= otecting Adminstrative state and begin transmitting NR(0,0). Scenario 2 Assume that there is a non-revertive protection switching set up between ro= uters R1 and R5 for working LSP1 and protection LSP2. Intially both are in Normal state sending NR(0,0) to each other. Now if R1 detects a Signal Failure, R1 moves to the local Protecting Failur= e state and sends SF(1,1) to R5. R5, on receiving SF(1,1), now moves to the remote Protecting Failure state = and will transmit NR(0,1) to R1. R1, on receiving NR(0,1), will ignore the message. Now SF clears on R1. R1 will go to Do-Not-Revert state and start transmitting DNR(0,1). R5, on receving DNR(0,1) moves to the remote Do-Not-Revert state and contin= ues transmitting current message of NR(0,1). R1, on receiving NR(0,1), will ignore this message. Now issue a Forced Switch command on R1. R1 will go the local Protecting Administrative state and begins transmittin= g FS(1,1) to R5. R5, on receiving FS(1,1), moves to the remote Protecting Administrative sta= te and begins transmitting NR(0,1). R1, on receiving NR(0,1) will ignore this message. Now issue a Clear Forced Switch command on R1. R1 moves to the Normal state and begins transmitting NR(0,0). R5, on receiving NR(0,0), moves to the Normal state and begins transmitting= NR(0,0). Scenario 3 Assume that there is a protection switching set up between routers R1 and R= 5 for working LSP1 and protection LSP2 where R1 is operating in the reverti= ve mode and R5 is operating in the non-revertive mode. Intially both are in Normal state sending NR(0,0) to each other. Now if R1 detects a Signal Failure, R1 moves to the local Protecting Failur= e state and sends SF(1,1) to R5. R5, on receiving SF(1,1), now moves to the remote Protecting Failure state = and will transmit NR(0,1) to R1. R1, on receiving NR(0,1), will ignore the message. Now SF clears on R1. R1 will go to Wait-To-Restore state, start the WTR timer and start transmit= ting WTR(0,1). R5, on receiving WTR(0,1), moves to the remote Wait-To-Restore state and co= ntinues transmission of current message NR(0,1). ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." --_000_E13C8C03049AFA4E9CEE5A21D3E7F85D020DE13549GUREXMB02ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    To the authors,=

     

    I have a list of protection s= witching scenarios that do not seem to result in expected behaviour if oper= ating as per this draft. I have proposed solutions/alternate text. = I would appreciate your comments/confirmation on the same.

     

    Scenario 1<= /font>

    Assume that there is a r= evertive protection switching group set up between routers R1 and R5 f= or working LSP1 and protection LSP2

     

    [Sequence of events]

    Both R1 and R5 in Normal = state à SF on R1 à FS on R5 à FS clear on R5

    [Result]

    Both R1 and R5 going to Normal = state with NR(0,0)

    [Problem]

    The above is an incorrect state on R1 since the local Signal Fai= l still exists and has not been cleared. So R1 should have moved back to the local Protecting Failure state transmitting SF(1,1)= instead of going to the NR(0,0) state.

    [Suggested Solution] 

    In Section 4.3.3.3, the 2nd last bullet item under remote messag= es needs to be modified as - "A remote NR(0,0) message SHALL be ignored if in local Protecting administrative state.  I= f in remote Protecting administrative state then the LER SHALL go to N= ormal state and begin transmitting a NR(0,0) message OR shall go to th= e local Protecting Failure state if local Signal Failure is still reasserted and begin transmitting SF(1,1).

     

    Scenario 2<= font size=3D"2" face=3D"Comic Sans MS">

    Assume that there is a n= on-revertive protection switching set up between routers R1 and R5 for work= ing LSP1 and protection LSP2.

     

    [Sequence of events]

    Both R1 and R5 in Normal = state à SF on R1 à SF clear on R1 à FS on R1 à FS clear on R1

    [Result]

    Both R1 and R5 going to Normal = state with NR(0,0)

    [Problem]

    Upon clearing the Forced Switch at R1, it is expected to go loca= l Do-Not-Revert state again and begin transmitting DNR(0,1). Upon receiving this R5 is expected to go to remote Do-Not-Revert state.

    [Suggested Solution]

    In Section 4.3.3.3, the 1st bullet item under local input n= eeds to be modified as - "A local Clear SHOULD be ignored if in remote Protecting administrative state.  If in local Protecting= administrative state then this input SHALL cause the LER to go into Normal= state and begin transmitting a NR(0,0) message if in revertive mode or go = into Do-Not-Revert state and begin transmitting DNR(0,1) if in non-revertive mode.

     

    Scenario 3<= o:p>

    Assume that there is a p= rotection switching set up between routers R1 and R5 for working LSP1 and p= rotection LSP2 where R1 is operating in the revertive mode and R5 is operating in the non-revertive mode.

     

    [Sequence of events]

    Both R1 and R5 in Normal = state à SF on R1 à SF clear on R1

    [Result]

    R5 moves to Wait-to-restore state and begins transmitting NR(0,1= )

    [Problem]

    R5 is in non-revertive mode and as such does not have a Wait-to-= restore state.

    [Suggested Solution]

    In Section 4.3.3.4, the 4th bullet under remote messages needs t= o be modified as - "If in remote Protecting failure state, a remote Wait-to-Restore message SHALL cause the LER to go int= o remote Wait-to-Restore state if in revertive mode and into remote Do= -Not-Revert state if in non-revertive mode and continue transmission of the= current message.

     

     

    I have worked out the exact s= equence details of the state machine for the scenarios above, which I have = listed below.

     

    - Lavanya

     

     

    DETAILED SEQUENCE

     

    Scenario 1<= o:p>

    Assume that there is a r= evertive protection switching group set up between routers R1 and R5 f= or working LSP1 and protection LSP2.

    Intially both are in Normal state sending NR(0,0) to each oth= er.

    Now if R1 detects a Signal Fa= ilure, R1 moves to the local Protecting Failure state and sends SF(1,1) to = R5.

    R5, on receiving SF(1,1),&nbs= p;now moves to the remote Protecting Failure state and will transmit NR(0,1= ) to R1.

    R1, on receiving NR(0,1), wil= l ignore the message.

    Now issue a Forced Switch com= mand on R5.

    R5 will now move to the local= Protecting Administrative state and start transmitting FS(1,1).

    R1, on receiving FS(1,1), now= moves to remote Protecting Adminstrative state and since it was earlier in= local Protecting Failure state, it will now transmit SF(1,1) to R5.

    R5, on receiving SF(1,1) from= R1, will ignore the message since there is an active Local = Forced Switch command.

    Now issue a Clear comman= d on R5 for clearing the Forced Switch.

    R5 will now move to the Normal state since it was in local Prote= cting Adminstrative state and start transmitting NR(0,0).

    R1, on receiving NR(0,0), wil= l go to Normal state since it was in remote Protecting Adminstrative state = and begin transmitting NR(0,0).

     

     

    Scenario 2<= o:p>

    Assume that there is a n= on-revertive protection switching set up between routers R1 and R5 for work= ing LSP1 and protection LSP2.

    Intially both are in Normal state sending NR(0,0) to each oth= er.

    Now if R1 detects a Signal Fa= ilure, R1 moves to the local Protecting Failure state and sends SF(1,1) to = R5.

    R5, on receiving SF(1,1),&nbs= p;now moves to the remote Protecting Failure state and will transmit NR(0,1= ) to R1.

    R1, on receiving NR(0,1), wil= l ignore the message.

    Now SF clears on R1.

    R1 will go to Do-Not-Revert s= tate and start transmitting DNR(0,1).

    R5, on receving DNR(0,1) move= s to the remote Do-Not-Revert state and continues transmitting current mess= age of NR(0,1).

    R1, on receiving NR(0,1), wil= l ignore this message.

    Now issue a Forced Switch com= mand on R1.

    R1 will go the local Protecti= ng Administrative state and begins transmitting FS(1,1) to R5.

    R5, on receiving FS(1,1), mov= es to the remote Protecting Administrative state and begins transmitting NR= (0,1).

    R1, on receiving NR(0,1) will= ignore this message.

    Now issue a Clear Forced Swit= ch command on R1.

    R1 moves to the Normal state and begins transmitting NR(= 0,0).

    R5, on receiving NR(0,0), mov= es to the Normal state and begins transmitting NR(= 0,0).

     

     

    Scenario 3<= o:p>

    Assume that there is a p= rotection switching set up between routers R1 and R5 for working LSP1 and p= rotection LSP2 where R1 is operating in the revertive mode and R5 is operating in the non-revertive mode.

    Intially both are in Normal state sending NR(0,0) to each oth= er.

    Now if R1 detects a Signal Fa= ilure, R1 moves to the local Protecting Failure state and sends SF(1,1) to = R5.

    R5, on receiving SF(1,1),&nbs= p;now moves to the remote Protecting Failure state and will transmit NR(0,1= ) to R1.

    R1, on receiving NR(0,1), wil= l ignore the message.

    Now SF clears on R1.

    R1 will go to Wait-To-Restore= state, start the WTR timer and start transmitting WTR(0,1).

    R5, on receiving WTR(0,1), mo= ves to the remote Wait-To-Restore state and continues transmission of curre= nt message NR(0,1).

     


    "DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error, please notify the originator immediately. If you= are not the intended recipient, you are notified that you are strictly pro= hibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
     --_000_E13C8C03049AFA4E9CEE5A21D3E7F85D020DE13549GUREXMB02ASIA_-- From yaacov.weingarten@nsn.com Thu Mar 17 06:12:42 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D233A695E; Thu, 17 Mar 2011 06:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 NzWD3ldQYSms; Thu, 17 Mar 2011 06:12:30 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 630083A6950; Thu, 17 Mar 2011 06:12:29 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p2HDDp9Y009889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Mar 2011 14:13:51 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p2HDDkWg010694; Thu, 17 Mar 2011 14:13:51 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 14:13:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE4A5.281092BA" Date: Thu, 17 Mar 2011 14:13:45 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt Thread-Index: AcvkeK8hutvfRZeXSZymrltxfoQJoAACOzwgAAZzYNA= References: From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: "ext Lavanya Srivatsa" , "MPLS TP" , X-OriginalArrivalTime: 17 Mar 2011 13:13:50.0697 (UTC) FILETIME=[284B9590:01CBE4A5] Subject: Re: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 13:12:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE4A5.281092BA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lavanya, hi =20 See my comments below =20 Hope this helps BR, yaacov =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext Lavanya Srivatsa Sent: Thursday, March 17, 2011 11:16 AM To: MPLS TP; mpls@ietf.org Subject: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt =20 To the authors, =20 I have a list of protection switching scenarios that do not seem to = result in expected behaviour if operating as per this draft. I have = proposed solutions/alternate text. I would appreciate your = comments/confirmation on the same. =20 Scenario 1 Assume that there is a revertive protection switching group set up = between routers R1 and R5 for working LSP1 and protection LSP2=20 =20 [Sequence of events]=20 Both R1 and R5 in Normal state =E0 SF on R1 =E0 FS on R5 =E0 FS clear on = R5 [Result]=20 Both R1 and R5 going to Normal state with NR(0,0) [Problem]=20 The above is an incorrect state on R1 since the local Signal Fail still = exists and has not been cleared. So R1 should have moved back to the = local Protecting Failure state transmitting SF(1,1) instead of going to = the NR(0,0) state. =20 yw> First off see in the comment resolution, row#80. =20 To explain more fully - you just stopped your scenario one step too soon = - When R1 returns to Normal state it will then immediately receive the = SF indication and go into Protecting Failure. In essence, as pointed = out in the comment in row #80 of the LC comments the state machine = dictates that you transition through Normal to arrive at the Protecting = failure state. This was done in order to simplify the protocol and the state machine - = as you can see from the LC comments there are several other of these = scenarios and if we wanted to cover every possible scenario it would = greatly complicate the state machine with different levels of conditions = that would need to be checked. What you are suggesting is an = optimization that you could implement, but we (after discussing this and = other scenarios) opted for the simplicity of the protocol. [Suggested Solution]=20 In Section 4.3.3.3, the 2nd last bullet item under remote messages needs = to be modified as - "A remote NR(0,0) message SHALL be ignored if in = local Protecting administrative state. If in remote Protecting = administrative state then the LER SHALL go to Normal state and begin = transmitting a NR(0,0) message OR shall go to the local Protecting = Failure state if local Signal Failure is still reasserted and begin = transmitting SF(1,1). =20 Scenario 2 Assume that there is a non-revertive protection switching set up between = routers R1 and R5 for working LSP1 and protection LSP2. =20 [Sequence of events]=20 Both R1 and R5 in Normal state =E0 SF on R1 =E0 SF clear on R1 =E0 FS on = R1 =E0 FS clear on R1 [Result]=20 Both R1 and R5 going to Normal state with NR(0,0) [Problem]=20 Upon clearing the Forced Switch at R1, it is expected to go local = Do-Not-Revert state again and begin transmitting DNR(0,1). Upon = receiving this R5 is expected to go to remote Do-Not-Revert state. =20 yw> I do not agree that the domain should transition back to DNR state = once the operator did a Forced Switch he means to go back to Normal. In = a previous version of the draft we presented two possibilities of = reverting to Normal from DNR state (either use an explicit Clear command = or use FS) and the use of FS was chosen. So this is the very scenario = that allows the operator to revert back to Normal from DNR state. =20 [Suggested Solution]=20 In Section 4.3.3.3, the 1st bullet item under local input needs to be = modified as - "A local Clear SHOULD be ignored if in remote Protecting = administrative state. If in local Protecting administrative state then = this input SHALL cause the LER to go into Normal state and begin = transmitting a NR(0,0) message if in revertive mode or go into = Do-Not-Revert state and begin transmitting DNR(0,1) if in non-revertive = mode. =20 Scenario 3 Assume that there is a protection switching set up between routers R1 = and R5 for working LSP1 and protection LSP2 where R1 is operating in the = revertive mode and R5 is operating in the non-revertive mode. =20 yw> There is a problem already at this point in your description - = referring to section 4.2.4 of the draft - it states clearly that this = misconfiguration should be reported to the management system as an error = situation. =20 [Sequence of events]=20 Both R1 and R5 in Normal state =E0 SF on R1 =E0 SF clear on R1 [Result]=20 R5 moves to Wait-to-restore state and begins transmitting NR(0,1) [Problem]=20 R5 is in non-revertive mode and as such does not have a Wait-to-restore = state.=20 [Suggested Solution]=20 In Section 4.3.3.4, the 4th bullet under remote messages needs to be = modified as - "If in remote Protecting failure state, a remote = Wait-to-Restore message SHALL cause the LER to go into remote = Wait-to-Restore state if in revertive mode and into remote Do-Not-Revert = state if in non-revertive mode and continue transmission of the current = message. =20 =20 I have worked out the exact sequence details of the state machine for = the scenarios above, which I have listed below. =20 - Lavanya =20 =20 DETAILED SEQUENCE =20 Scenario 1 Assume that there is a revertive protection switching group set up = between routers R1 and R5 for working LSP1 and protection LSP2. Intially both are in Normal state sending NR(0,0) to each other. Now if R1 detects a Signal Failure, R1 moves to the local Protecting = Failure state and sends SF(1,1) to R5. R5, on receiving SF(1,1), now moves to the remote Protecting Failure = state and will transmit NR(0,1) to R1. R1, on receiving NR(0,1), will ignore the message. Now issue a Forced Switch command on R5. R5 will now move to the local Protecting Administrative state and start = transmitting FS(1,1). R1, on receiving FS(1,1), now moves to remote Protecting Adminstrative = state and since it was earlier in local Protecting Failure state, it = will now transmit SF(1,1) to R5. R5, on receiving SF(1,1) from R1, will ignore the message since there is = an active Local Forced Switch command. Now issue a Clear command on R5 for clearing the Forced Switch. R5 will now move to the Normal state since it was in local Protecting = Adminstrative state and start transmitting NR(0,0). R1, on receiving NR(0,0), will go to Normal state since it was in remote = Protecting Adminstrative state and begin transmitting NR(0,0). =20 =20 Scenario 2 Assume that there is a non-revertive protection switching set up between = routers R1 and R5 for working LSP1 and protection LSP2. Intially both are in Normal state sending NR(0,0) to each other. Now if R1 detects a Signal Failure, R1 moves to the local Protecting = Failure state and sends SF(1,1) to R5. R5, on receiving SF(1,1), now moves to the remote Protecting Failure = state and will transmit NR(0,1) to R1. R1, on receiving NR(0,1), will ignore the message. Now SF clears on R1. R1 will go to Do-Not-Revert state and start transmitting DNR(0,1). R5, on receving DNR(0,1) moves to the remote Do-Not-Revert state and = continues transmitting current message of NR(0,1). R1, on receiving NR(0,1), will ignore this message. Now issue a Forced Switch command on R1. R1 will go the local Protecting Administrative state and begins = transmitting FS(1,1) to R5. R5, on receiving FS(1,1), moves to the remote Protecting Administrative = state and begins transmitting NR(0,1). R1, on receiving NR(0,1) will ignore this message. Now issue a Clear Forced Switch command on R1. R1 moves to the Normal state and begins transmitting NR(0,0). R5, on receiving NR(0,0), moves to the Normal state and begins = transmitting NR(0,0). =20 =20 Scenario 3 Assume that there is a protection switching set up between routers R1 = and R5 for working LSP1 and protection LSP2 where R1 is operating in the = revertive mode and R5 is operating in the non-revertive mode. Intially both are in Normal state sending NR(0,0) to each other. Now if R1 detects a Signal Failure, R1 moves to the local Protecting = Failure state and sends SF(1,1) to R5. R5, on receiving SF(1,1), now moves to the remote Protecting Failure = state and will transmit NR(0,1) to R1. R1, on receiving NR(0,1), will ignore the message. Now SF clears on R1. R1 will go to Wait-To-Restore state, start the WTR timer and start = transmitting WTR(0,1). R5, on receiving WTR(0,1), moves to the remote Wait-To-Restore state and = continues transmission of current message NR(0,1). =20 =20 ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended = solely for the use of the individual to whom it is addressed. It may = contain privileged or confidential information and should not be = circulated or used for any purpose other than for what it is intended. = If you have received this message in error, please notify the originator = immediately. If you are not the intended recipient, you are notified = that you are strictly prohibited from using, copying, altering, or = disclosing the contents of this message. Aricent accepts no = responsibility for loss or damage arising from the use of the = information transmitted by this email including damage from virus." ------_=_NextPart_001_01CBE4A5.281092BA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Lavanya, hi

     

    See my comments below

     

    Hope this helps

    BR,

    yaacov

     

    From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext Lavanya Srivatsa
    Sent: Thursday, March 17, 2011 11:16 = AM
    To: MPLS TP; mpls@ietf.org
    Subject: [mpls] = Comments on = draft-ietf-mpls-tp-linear-protection-06.txt

     

    To the authors,

     

    I have a list of = protection switching scenarios that do not seem to result in expected = behaviour if operating as per this draft. I have proposed = solutions/alternate text. I would = appreciate your comments/confirmation on the = same.

     

    Scenario = 1

    Assume that there = is a revertive protection switching group set up between = routers R1 and R5 for working LSP1 and protection LSP2 =

     

    [Sequence of = events]

    Both R1 and R5 in = Normal state =E0 SF on R1 = =E0 FS on R5 = =E0 FS clear on = R5

    [Result] =

    Both R1 and R5 = going to Normal state with NR(0,0)

    [Problem]

    The above is an = incorrect state on R1 since the local Signal Fail still exists and has = not been cleared. So R1 should have moved back to the local = Protecting Failure state transmitting SF(1,1) instead of going to the = NR(0,0) state.

     

    yw>=A0 First off see in the comment = resolution, row#80.=A0

    To = explain more fully – you just stopped your scenario one step too = soon – When R1 returns to Normal state it will then immediately = receive the SF indication and go into Protecting Failure.=A0 In essence, = as pointed out in the comment in row #80 of the LC comments the state = machine dictates that you transition through Normal to arrive at the = Protecting failure state.

    This was done in order to simplify the protocol = and the state machine – as you can see from the LC comments there = are several other of these scenarios and if we wanted to cover every = possible scenario it would greatly complicate the state machine with = different levels of conditions that would need to be checked. =A0What = you are suggesting is an optimization that you could implement, but we = (after discussing this and other scenarios) opted for the simplicity of = the protocol.

    [Suggested = Solution] 

    In Section = 4.3.3.3, the 2nd last bullet item under remote messages needs to be = modified as - "A remote NR(0,0) message SHALL be ignored if in = local Protecting administrative state.  If in remote = Protecting administrative state then the LER SHALL go to Normal = state and begin transmitting a NR(0,0) message OR shall go to the = local Protecting Failure state if local Signal Failure is still = reasserted and begin transmitting SF(1,1).

     

    Scenario = 2

    Assume that there = is a non-revertive protection switching set up between routers R1 = and R5 for working LSP1 and protection LSP2.

     

    [Sequence of = events]

    Both R1 and R5 in = Normal state =E0 SF on R1 = =E0 SF clear on R1 = =E0 FS on R1 = =E0 FS clear on = R1

    [Result] =

    Both R1 and R5 = going to Normal state with NR(0,0)

    [Problem]

    Upon clearing the = Forced Switch at R1, it is expected to go local Do-Not-Revert state = again and begin transmitting DNR(0,1). Upon receiving this R5 is = expected to go to remote Do-Not-Revert state.

     

    yw> I do not agree that the domain should = transition back to DNR state once the operator did a Forced Switch he = means to go back to Normal. =A0In a previous version of the draft we = presented two possibilities of reverting to Normal from DNR state = (either use an explicit Clear command or use FS) and the use of FS was = chosen. =A0So this is the very scenario that allows the operator to = revert back to Normal from DNR state.

     

    [Suggested Solution]

    In Section = 4.3.3.3, the 1st bullet item under local input needs to be modified = as - "A local Clear SHOULD be ignored if in remote Protecting = administrative state.  If in local Protecting administrative state = then this input SHALL cause the LER to go into Normal state and begin = transmitting a NR(0,0) message if in revertive mode or go into = Do-Not-Revert state and begin transmitting DNR(0,1) if in non-revertive = mode.

     

    Scenario = 3

    Assume that there = is a protection switching set up between routers R1 and R5 for = working LSP1 and protection LSP2 where R1 is operating in the revertive = mode and R5 is operating in the non-revertive = mode.

     

    yw>=A0 There is a problem already at this = point in your description – referring to section 4.2.4 of the = draft – it states clearly that this misconfiguration should be = reported to the management system as an error = situation.

     

    [Sequence of = events]

    Both R1 and R5 in = Normal state =E0 SF on R1 = =E0 SF clear on = R1

    [Result] =

    R5 moves to = Wait-to-restore state and begins transmitting = NR(0,1)

    [Problem] =

    R5 is in = non-revertive mode and as such does not have a Wait-to-restore state. =

    [Suggested = Solution]

    In Section = 4.3.3.4, the 4th bullet under remote messages needs to be modified as - = "If in remote Protecting failure state, a remote = Wait-to-Restore message SHALL cause the LER to go into remote = Wait-to-Restore state if in revertive mode and into remote = Do-Not-Revert state if in non-revertive mode and continue transmission = of the current message.

     

     

    I have worked out = the exact sequence details of the state machine for the scenarios above, = which I have listed below.

     

    - = Lavanya

     

     

    DETAILED SEQUENCE

     

    Scenario = 1

    Assume that there = is a revertive protection switching group set up between = routers R1 and R5 for working LSP1 and protection = LSP2.

    Intially both are = in Normal state sending NR(0,0) to each other.

    Now if R1 detects a Signal Failure, R1 moves to the local = Protecting Failure state and sends SF(1,1) to = R5.

    R5, on receiving = SF(1,1), now moves to the remote Protecting Failure state and will = transmit NR(0,1) to R1.

    R1, on receiving = NR(0,1), will ignore the message.

    Now issue a Forced Switch command on = R5.

    R5 will now move = to the local Protecting Administrative state and start transmitting = FS(1,1).

    R1, on receiving = FS(1,1), now moves to remote Protecting Adminstrative state and since it = was earlier in local Protecting Failure state, it will now transmit = SF(1,1) to R5.

    R5, on receiving = SF(1,1) from R1, will ignore the message since = there is an active Local Forced Switch = command.

    Now issue a = Clear command on R5 for clearing the Forced = Switch.

    R5 will now move = to the Normal state since it was in local Protecting Adminstrative state = and start transmitting NR(0,0).

    R1, on receiving NR(0,0), will go to Normal state since it was = in remote Protecting Adminstrative state and begin transmitting = NR(0,0).

     

     

    Scenario = 2

    Assume that there = is a non-revertive protection switching set up between routers R1 = and R5 for working LSP1 and protection LSP2.

    Intially both are in Normal state sending NR(0,0) to each = other.

    Now if R1 detects = a Signal Failure, R1 moves to the local Protecting Failure state and = sends SF(1,1) to R5.

    R5, on receiving = SF(1,1), now moves to the remote Protecting Failure state and will = transmit NR(0,1) to R1.

    R1, on receiving = NR(0,1), will ignore the message.

    Now SF clears on R1.

    R1 will go to Do-Not-Revert state and start transmitting = DNR(0,1).

    R5, on receving = DNR(0,1) moves to the remote Do-Not-Revert state and continues = transmitting current message of NR(0,1).

    R1, on receiving NR(0,1), will ignore this = message.

    Now issue a = Forced Switch command on R1.

    R1 will go the local Protecting Administrative state and = begins transmitting FS(1,1) to R5.

    R5, on receiving FS(1,1), moves to the remote Protecting = Administrative state and begins transmitting = NR(0,1).

    R1, on receiving = NR(0,1) will ignore this message.

    Now issue a Clear Forced Switch command on = R1.

    R1 moves to the = Normal state and begins transmitting NR(0,0).

    R5, on receiving NR(0,0), moves to the Normal state and begins = transmitting NR(0,0).

     

     

    Scenario = 3

    Assume that there = is a protection switching set up between routers R1 and R5 for = working LSP1 and protection LSP2 where R1 is operating in the revertive = mode and R5 is operating in the non-revertive = mode.

    Intially both are = in Normal state sending NR(0,0) to each other.

    Now if R1 detects a Signal Failure, R1 moves to the local = Protecting Failure state and sends SF(1,1) to = R5.

    R5, on receiving = SF(1,1), now moves to the remote Protecting Failure state and will = transmit NR(0,1) to R1.

    R1, on receiving = NR(0,1), will ignore the message.

    Now SF clears on R1.

    R1 will go to Wait-To-Restore state, start the WTR = timer and start transmitting WTR(0,1).

    R5, on receiving WTR(0,1), moves to the remote Wait-To-Restore = state and continues transmission of current message = NR(0,1).

     

     

    "DISCLAIMER: = This message is proprietary to Aricent and is intended solely for the = use of the individual to whom it is addressed. It may contain privileged = or confidential information and should not be circulated or used for any = purpose other than for what it is intended. If you have received this = message in error, please notify the originator immediately. If you are = not the intended recipient, you are notified that you are strictly = prohibited from using, copying, altering, or disclosing the contents of = this message. Aricent accepts no responsibility for loss or damage = arising from the use of the information transmitted by this email = including damage from = virus."

    ------_=_NextPart_001_01CBE4A5.281092BA-- From wwwrun@core3.amsl.com Thu Mar 17 07:25:40 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id BC1D73A69B1; Thu, 17 Mar 2011 07:25:40 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: rcallon@juniper.net,swallow@cisco.com,loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110317142540.BC1D73A69B1@core3.amsl.com> Date: Thu, 17 Mar 2011 07:25:40 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, Steve.Trowbridge@alcatel-lucent.com, yoichi.maeda@ttc.or.jp, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS297 - Comments on draft-ietf-mpls-tp-identifiers-04 [Ref # 046.03]" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 14:25:40 -0000 Title: LS297 - Comments on draft-ietf-mpls-tp-identifiers-04 [Ref # 046.03] Submission Date: 2011-03-17 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1036 Please reply by 2011-06-01 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(rcallon@juniper.net,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp Steve.Trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: malcolm.betts@zte.com.cn Purpose: For action Body: We note that the MPLS Working Group has initiated a last call on draft-ietf-mpls-tp-identifiers-04. We have not yet received liaisons describing the disposition of our comment provided in �Comments on draft-ietf-mpls-tp-identifiers-03 [Ref # 046.02]� or a requesting our review of draft-ietf-mpls-tp-identifiers-04. The experts of Q12/15 have reviewed draft-ietf-mpls-tp-identifiers-04 by correspondence. At this time we do not have consensus to support the approval of this draft. We request that the changes and comments in the attached marked up draft are addressed and that we are given a further opportunity to review this draft before approval by the IETF. Attach: Changes and comments relative to draft-ietf-mpls-tp-identifiers-04. Attachment(s): LS297 - Comments on draft-ietf-mpls-tp-identifiers-04 [Ref # 046.03] - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1213.pdf) LS297 - Changes and comments relative to draft-ietf-mpls-tp-identifiers-04 (https://datatracker.ietf.org/documents/LIAISON/file1214.pdf) From PDiamond@semtech.com Thu Mar 3 10:24:55 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 764B63A6A08 for ; Thu, 3 Mar 2011 10:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 DZlbmkj4JoZ2 for ; Thu, 3 Mar 2011 10:24:54 -0800 (PST) Received: from mail200.messagelabs.com (mail200.messagelabs.com [216.82.254.195]) by core3.amsl.com (Postfix) with SMTP id 0AE733A682C for ; Thu, 3 Mar 2011 10:24:53 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: PDiamond@semtech.com X-Msg-Ref: server-12.tower-200.messagelabs.com!1299176760!67138089!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [12.155.129.37] Received: (qmail 4560 invoked from network); 3 Mar 2011 18:26:00 -0000 Received: from mail.semtech.com (HELO mail.semtech.com) (12.155.129.37) by server-12.tower-200.messagelabs.com with SMTP; 3 Mar 2011 18:26:00 -0000 In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6956C122C58@SJEXCHCCR02.corp.ad.broadcom.com> X-KeepSent: 2F78BA7F:ED8EFE35-88257848:0064FB67; type=4; name=$KeepSent To: "Shahram Davari" X-Mailer: Lotus Notes Release 7.0.4 March 23, 2009 Message-ID: From: PDiamond@semtech.com Date: Thu, 3 Mar 2011 10:26:00 -0800 X-MIMETrack: Serialize by Router on Mail/SMTC(Release 8.5.1FP4|July 25, 2010) at 03/03/2011 10:26:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Thu, 17 Mar 2011 10:28:29 -0700 Cc: "mpls@ietf.org" , tictoc-bounces@ietf.org, "tictoc@ietf.org" , "stbryant@cisco.com" Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 18:24:55 -0000 My feeling is 1588 is the right answer in the long run since it is already coupled to the hardware and widely deployed in networks using the "packet clock derived time" in precise time and frequency delivery. Pat "Shahram Davari" To Sent by: "stbryant@cisco.com" tictoc-bounces@ie , tf.org "mpls@ietf.org" cc "tictoc@ietf.org" 03/03/2011 10:05 Subject AM Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp Hi Stewart, Accurate delay measurement requires the Timestamp to be done in HW. It is true that most routers support NTP today, but the majority of those are really maintained in Software and AFAIK most HW based timestamps implementations are 1588 based and really the industry is shifting toward 1588 and SyncE for network synchronization. So I support 1588 as being the default. Thanks, Shahram From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Thursday, March 03, 2011 8:07 AM To: mpls@ietf.org Cc: tictoc@ietf.org Subject: [TICTOC] draft-ietf-mpls-loss-delay Timestamp We have received a LC comment on draft-ietf-mpls-loss-delay concerning the default timestamp. In the first version of the draft we proposed NTP, but following initial comments from the MPLS-TP community we changed to IEEE1588. This requirement for IEEE1588 can be traced back to the choice of using IEEE1588 in Y.1731. We have now received a LC request to change the default back to NTP. NTP is the "natural" choice for an IETF protocol. NTP is specified in IETF and is used in other MPLS protocols such as LSP ping. It is implemented on almost every host and every router. However in general the implementations provides a relatively low precision timestamp, and the NTP time distribution infrastructure operates on a best effort basis. Thus even a good client implementation would normally have a relatively low quality path to the server, which would result in a low quality of timestamp. NTP could be made to work to higher accuracy, but defacto upgrading NTP and providing high quality NTP paths to the time servers is not getting much attention. Computing timestamp differences is easier with NTP. On the other hand IEEE1588 has defacto become the two way time tranfer protocol for precision applications. IEEE1588 only provides high quality time in well engineered networks with some form of hop by hop assistance. It is not widely implemented other than in equipment targeted to specific markets, although one of those markets is in mobile backhaul applications where we expect to see significant initial deployment of MPLS-TP. Computing timestamp differences is harder with IEEE1588 The loss-delay work is targeting to be able to do one way packet delay measurement, so it does need a higher quality of timestamp than is required in general purpose network instrumentation. Converting from IEEE1588 to NTP is not trivial, since they use different epochs, and different representations of sub-second time. In a "traditional" NTP implementation the time error due to on the fly conversion is likely to be small compared to the time error in the time synchronization system, but an IEEE1588 system would need hardware conversion to maintain the accuracy for an NTP timestamp. So the question arises, should we make IEEE1588 or NTP the default for draft-ietf-mpls-loss-delay. Much as I would like to suggest that we should go back to NTP for consistency with other IETF protocols, I have difficulty reconciling this with the situation in network deployments and thus suggest that we continue to use IEEE1588. What is the opinion of the working group? Stewart (speaking as a draft editor) _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc From ronc.ntear@gmail.com Thu Mar 3 11:20:35 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A35163A69A4; Thu, 3 Mar 2011 11:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 W3ceH0A9xNS2; Thu, 3 Mar 2011 11:20:33 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 688183A681A; Thu, 3 Mar 2011 11:20:33 -0800 (PST) Received: by vxg33 with SMTP id 33so1496532vxg.31 for ; Thu, 03 Mar 2011 11:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=t9vDYaH68z4JB+l3AOjt+4hs3MnvX1/YnZqRrkf/58o=; b=fe2p4ixf/bIdzfNN+8M8wT3cuhZCyHw73QvkV81mmYwXpHsjufrvZQqwHHQyHBCDNT ST9jz9voxwA7FYkXNNWMhO5vUuvYoM0SXPF2Bxhyf/O+vFct8H7s/flBgVAnG8ZvI6Tf vY9QKu9PDk64laMQEZcLdtuL7Mrf8g9rYv7e0= 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=c9U693UMmDtcqHNX4H39ZTASbkYBo4eJu+1M1QYpupy0MD+N+Fuc1UiMs7Ww6GPzM8 yzVbpOrvKix1ojMIKzMac5WBUZStPorZ0K+NunlRucqWGu86lBf4ay0KWVLp6RgHZXT+ eMYU0f9kgFkZ2ip6DgIUlg2mOkWijZ9w+aq98= MIME-Version: 1.0 Received: by 10.52.70.67 with SMTP id k3mr1325224vdu.63.1299180100250; Thu, 03 Mar 2011 11:21:40 -0800 (PST) Received: by 10.52.162.97 with HTTP; Thu, 3 Mar 2011 11:21:40 -0800 (PST) In-Reply-To: References: <2C2F1EBA8050E74EA81502D5740B4BD6956C122C58@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 3 Mar 2011 21:21:40 +0200 Message-ID: From: Ron Cohen To: PDiamond@semtech.com Content-Type: multipart/alternative; boundary=20cf307c9b725fedd5049d98f0e3 X-Mailman-Approved-At: Thu, 17 Mar 2011 10:28:29 -0700 Cc: "mpls@ietf.org" , tictoc-bounces@ietf.org, "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 19:20:35 -0000 --20cf307c9b725fedd5049d98f0e3 Content-Type: text/plain; charset=ISO-8859-1 Hi, I apologize in advance if my comments below where already been discussed. The draft specify using PTPv1 timestamp format and not PTPv2 timestamp format. The seconds part of the PTPv2 timestamp is 48bits, and not 32bits as written in the draft. NTP timestamps will roll over in 2036. PTPv2 timestamps do not rollover. I don't think its advisable to include timestamps that rolls over ~20 years from now. In addition, NTP timestamp, unlike PTP timestamp, 'jumps' in leap seconds events. This makes calculation of time differences hard, and would render some measurements ambiguous. It is much easier to use continuous timescale like PTP. In my opinion changing the timestamp format to PTPv2 timestamp format (i.e. 48bit/32bit sec/ns) should be the right way to go. I would also remove the NTP timestamp format option to avoid leap seconds confusion and 2036 rollover events. Best, Ron On Thu, Mar 3, 2011 at 8:26 PM, wrote: > My feeling is 1588 is the right answer in the long run since it is already > coupled to the hardware and widely deployed in networks using the "packet > clock derived time" in precise time and frequency delivery. > > Pat > > > > "Shahram Davari" > com> To > Sent by: "stbryant@cisco.com" > tictoc-bounces@ie , > tf.org "mpls@ietf.org" > cc > "tictoc@ietf.org" > 03/03/2011 10:05 Subject > AM Re: [TICTOC] > draft-ietf-mpls-loss-delay > Timestamp > > > > > > > > > > > Hi Stewart, > > Accurate delay measurement requires the Timestamp to be done in HW. It is > true that most routers support NTP today, but the majority of those are > really maintained in Software and AFAIK most HW based timestamps > implementations are 1588 based and really the industry is shifting toward > 1588 and SyncE for network synchronization. So I support 1588 as being the > default. > > Thanks, > Shahram > > From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf > Of > Stewart Bryant > Sent: Thursday, March 03, 2011 8:07 AM > To: mpls@ietf.org > Cc: tictoc@ietf.org > Subject: [TICTOC] draft-ietf-mpls-loss-delay Timestamp > > > We have received a LC comment on draft-ietf-mpls-loss-delay concerning the > default timestamp. > > In the first version of the draft we proposed NTP, but following initial > comments from the MPLS-TP community we changed to IEEE1588. This > requirement for IEEE1588 can be traced back to the choice of using IEEE1588 > in Y.1731. > > We have now received a LC request to change the default back to NTP. > > NTP is the "natural" choice for an IETF protocol. NTP is specified in IETF > and is used in other MPLS protocols such as LSP ping. It is implemented on > almost every host and every router. However in general the implementations > provides a relatively low precision timestamp, and the NTP time > distribution infrastructure operates on a best effort basis. Thus even a > good client implementation would normally have a relatively low quality > path to the server, which would result in a low quality of timestamp. NTP > could be made to work to higher accuracy, but defacto upgrading NTP and > providing high quality NTP paths to the time servers is not getting much > attention. Computing timestamp differences is easier with NTP. > > On the other hand IEEE1588 has defacto become the two way time tranfer > protocol for precision applications. IEEE1588 only provides high quality > time in well engineered networks with some form of hop by hop assistance. > It is not widely implemented other than in equipment targeted to specific > markets, although one of those markets is in mobile backhaul applications > where we expect to see significant initial deployment of MPLS-TP. Computing > timestamp differences is harder with IEEE1588 > > The loss-delay work is targeting to be able to do one way packet delay > measurement, so it does need a higher quality of timestamp than is required > in general purpose network instrumentation. > > Converting from IEEE1588 to NTP is not trivial, since they use different > epochs, and different representations of sub-second time. In a > "traditional" NTP implementation the time error due to on the fly > conversion is likely to be small compared to the time error in the time > synchronization system, but an IEEE1588 system would need hardware > conversion to maintain the accuracy for an NTP timestamp. > > So the question arises, should we make IEEE1588 or NTP the default for > draft-ietf-mpls-loss-delay. Much as I would like to suggest that we should > go back to NTP for consistency with other IETF protocols, I have difficulty > reconciling this with the situation in network deployments and thus suggest > that we continue to use IEEE1588. > > What is the opinion of the working group? > > Stewart (speaking as a draft editor) > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > --20cf307c9b725fedd5049d98f0e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    I apologize in advance if my comments below whe= re already been discussed.

    The draft specify using PTPv1 timestamp f= ormat and not PTPv2 timestamp format. The seconds part of the PTPv2 timesta= mp is 48bits, and not 32bits as written in the draft. NTP timestamps will r= oll over in 2036. PTPv2 timestamps do not rollover.

    I don't think its advisable to include timestamps that rolls over ~= 20 years from now.

    In addition, NTP timestamp, unlike PTP timestamp= , 'jumps' in leap seconds events. This makes calculation of time di= fferences hard, and would render some measurements ambiguous. It is much ea= sier to use continuous timescale like PTP.

    In my opinion changing the timestamp format to PTPv2 timestamp format (= i.e. 48bit/32bit sec/ns) should be the right way to go. I would also remove= the NTP timestamp format option to avoid leap seconds confusion and 2036 r= ollover events.

    Best,
    Ron


    On Thu, Mar 3, 2011 = at 8:26 PM, <= PDiamond@semtech.com> wrote:
    My feeling is 1588 is the right answer in the long run since it is already<= br> coupled to the hardware and widely deployed in networks using the "pac= ket
    clock derived time" in precise time and frequency delivery.

    Pat



    =A0 =A0 =A0 =A0 =A0 =A0 "Shahram Davari"
    =A0 =A0 =A0 =A0 =A0 =A0 <davari@broadcom.
    =A0 =A0 =A0 =A0 =A0 =A0 com> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 To
    =A0 =A0 =A0 =A0 =A0 =A0 Sent by: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"= stbryant@cisco.com"
    =A0 =A0 =A0 =A0 =A0 =A0 tictoc-bounces@ie =A0 =A0 =A0 =A0 <stbryant@cisco.com>,
    =A0 =A0 =A0 =A0 =A0 =A0 tf.org= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"mpls@ietf.org" <mpls@i= etf.org>
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 "tictoc@ietf.org" <= tictoc@ietf.org>
    =A0 =A0 =A0 =A0 =A0 =A0 03/03/2011 10:05 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Subject
    =A0 =A0 =A0 =A0 =A0 =A0 AM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Re: [TICTOC]
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-ietf-mpls-loss-delay
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 Timestamp










    Hi Stewart,

    Accurate delay measurement requires the Timestamp to be done in HW. It is true that most routers support NTP today, but the majority of those are
    really maintained in Software and AFAIK most HW based timestamps
    implementations are 1588 based and really the industry is shifting toward 1588 and SyncE for network synchronization. So I support 1588 as being the<= br> default.

    Thanks,
    Shahram

    From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.or= g] On Behalf Of
    Stewart Bryant
    Sent: Thursday, March 03, 2011 8:07 AM
    To: mpls@ietf.org
    Cc: tictoc@ietf.org
    Subject: [TICTOC] draft-ietf-mpls-loss-delay Timestamp


    We have received a LC comment on draft-ietf-mpls-loss-delay concerning the<= br> default timestamp.

    In the first version of the draft we proposed NTP, but following initial comments from the MPLS-TP community we changed to IEEE1588. This
    requirement for IEEE1588 can be traced back to the choice of using IEEE1588=
    in Y.1731.

    We have now received a LC request to change the default back to NTP.

    NTP is the "natural" choice for an IETF protocol. NTP is specifie= d in IETF
    and is used in other MPLS protocols such as LSP ping. It is implemented on<= br> almost every host and every router. However in general the implementations<= br> provides a relatively low precision timestamp, and the NTP time
    distribution infrastructure operates on a best effort basis. Thus even a good client implementation would normally have a relatively low quality
    path to the server, which would result in a low quality of timestamp. NTP could be made to work to higher accuracy, but defacto upgrading NTP and
    providing high quality NTP paths to the time servers is not getting much attention. Computing timestamp differences is easier with NTP.

    On the other hand IEEE1588 has defacto become the two way time tranfer
    protocol for precision applications. IEEE1588 only provides high quality time in well engineered networks with some form of hop by hop assistance. It is not widely implemented other than in equipment targeted to specific markets, although one of those markets is in mobile backhaul applications where we expect to see significant initial deployment of MPLS-TP. Computing=
    timestamp differences is harder with IEEE1588

    The loss-delay work is targeting to be able to do one way packet delay
    measurement, so it does need a higher quality of timestamp than is required=
    in general purpose network instrumentation.

    Converting from IEEE1588 to NTP is not trivial, since they use different epochs, and different representations of sub-second time. In a
    "traditional" NTP implementation the time error due to on the fly=
    conversion is likely to be small compared to the time error in the time
    synchronization system, but an IEEE1588 system would need hardware
    conversion to maintain the accuracy for an NTP timestamp.

    So the question arises, should we make IEEE1588 or NTP the default for
    draft-ietf-mpls-loss-delay. Much as I would like to suggest that we should<= br> go back to NTP for consistency with other IETF protocols, I have difficulty=
    reconciling this with the situation in network deployments and thus suggest=
    that we continue to use IEEE1588.

    What is the opinion of the working group?

    Stewart (speaking as a draft editor)
    _______________________________________________
    TICTOC mailing list
    TICTOC@ietf.org
    = https://www.ietf.org/mailman/listinfo/tictoc


    _______________________________________________
    TICTOC mailing list
    TICTOC@ietf.org
    = https://www.ietf.org/mailman/listinfo/tictoc

    --20cf307c9b725fedd5049d98f0e3-- From ronc.ntear@gmail.com Thu Mar 3 13:34:06 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF7E3A68AC; Thu, 3 Mar 2011 13:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 H54GMCQ40JR5; Thu, 3 Mar 2011 13:34:04 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 92B693A6834; Thu, 3 Mar 2011 13:34:03 -0800 (PST) Received: by vws6 with SMTP id 6so1607093vws.31 for ; Thu, 03 Mar 2011 13:35:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8dddAJev5LpNck2ZsudelAdrZa3kEIbyxyGrvizgxJI=; b=YiCvTf1/opyfoY37NN2g03nvSBjwJ2Y1GC7YZS26CkEVzFdd/ApxE+VHM6yi2e3Iao J1ExdljN0OSxUmp7PajfjOWLuEiO6DmrefjLt1R+x8mtc78Dmkv6qv/emo7ywTFsaOO7 qFLCSc5Avs3FGPQF6jPrBqqxf7o8dndjMT+RI= 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=gHm6y/bkbuZgzx7gcu7daH1gRwRFWv4CufK8zuVoKsxNOFLFOmqlhcVluejRfLcrSH 7WVUYnDPHJOai1bU5bbmkbioczjeP8SQc0Y3r3nG0Gv9UKUGa6vM2Yy/RCprO7vQXZ9Z lK36nS6LfU8WyIzgIFHp9aPfuklekIPV567+g= MIME-Version: 1.0 Received: by 10.52.160.66 with SMTP id xi2mr2582127vdb.223.1299188111181; Thu, 03 Mar 2011 13:35:11 -0800 (PST) Received: by 10.52.162.97 with HTTP; Thu, 3 Mar 2011 13:35:11 -0800 (PST) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6956C29995E@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6956C122C58@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD6956C29995E@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 3 Mar 2011 23:35:11 +0200 Message-ID: From: Ron Cohen To: Shahram Davari Content-Type: multipart/alternative; boundary=bcaec53f9741dd08b8049d9acd63 X-Mailman-Approved-At: Thu, 17 Mar 2011 10:28:29 -0700 Cc: "mpls@ietf.org" , "PDiamond@semtech.com" , "tictoc-bounces@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] draft-ietf-mpls-loss-delay Timestamp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 21:34:06 -0000 --bcaec53f9741dd08b8049d9acd63 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Shahram, I guess adding a requirement to take timestamp rollover into account would do. If there is a strong reason to also leave NTP timestamp a= s an option, a note explaining the ramification of leap seconds should be added. I suggest that a continuous timescale (i.e. PTP) would be selected i= n the draft as the default/must option. Best, Ron On Thu, Mar 3, 2011 at 9:45 PM, Shahram Davari wrote: > Hi Ron, > > > > Although the PTPv2 is 80 bytes, but I don=92t see a need to use all 80 by= tes > for delay measurement. The upper 2^32 seconds covers almost 136 years, wh= ich > should be good enough to measure delay. Also lets=92 be compatible with Y= .1731 > format since that HW already exist. > > > > Thx > > Shahram > > > > *From:* Ron Cohen [mailto:ronc.ntear@gmail.com] > *Sent:* Thursday, March 03, 2011 11:22 AM > *To:* PDiamond@semtech.com > *Cc:* Shahram Davari; mpls@ietf.org; tictoc-bounces@ietf.org; > tictoc@ietf.org > *Subject:* Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp > > > > Hi, > > I apologize in advance if my comments below where already been discussed. > > The draft specify using PTPv1 timestamp format and not PTPv2 timestamp > format. The seconds part of the PTPv2 timestamp is 48bits, and not 32bits= as > written in the draft. NTP timestamps will roll over in 2036. PTPv2 > timestamps do not rollover. > > I don't think its advisable to include timestamps that rolls over ~20 yea= rs > from now. > > In addition, NTP timestamp, unlike PTP timestamp, 'jumps' in leap seconds > events. This makes calculation of time differences hard, and would render > some measurements ambiguous. It is much easier to use continuous timescal= e > like PTP. > > In my opinion changing the timestamp format to PTPv2 timestamp format (i.= e. > 48bit/32bit sec/ns) should be the right way to go. I would also remove th= e > NTP timestamp format option to avoid leap seconds confusion and 2036 > rollover events. > > Best, > Ron > > On Thu, Mar 3, 2011 at 8:26 PM, wrote: > > My feeling is 1588 is the right answer in the long run since it is alread= y > coupled to the hardware and widely deployed in networks using the "packet > clock derived time" in precise time and frequency delivery. > > Pat > > > > "Shahram Davari" > com> To > Sent by: "stbryant@cisco.com" > tictoc-bounces@ie , > tf.org "mpls@ietf.org" > cc > "tictoc@ietf.org" > 03/03/2011 10:05 Subject > AM Re: [TICTOC] > > draft-ietf-mpls-loss-delay > Timestamp > > > > > > > > > > > Hi Stewart, > > Accurate delay measurement requires the Timestamp to be done in HW. It is > true that most routers support NTP today, but the majority of those are > really maintained in Software and AFAIK most HW based timestamps > implementations are 1588 based and really the industry is shifting toward > 1588 and SyncE for network synchronization. So I support 1588 as being th= e > default. > > Thanks, > Shahram > > From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf > Of > Stewart Bryant > Sent: Thursday, March 03, 2011 8:07 AM > To: mpls@ietf.org > Cc: tictoc@ietf.org > Subject: [TICTOC] draft-ietf-mpls-loss-delay Timestamp > > > We have received a LC comment on draft-ietf-mpls-loss-delay concerning th= e > default timestamp. > > In the first version of the draft we proposed NTP, but following initial > comments from the MPLS-TP community we changed to IEEE1588. This > requirement for IEEE1588 can be traced back to the choice of using IEEE15= 88 > in Y.1731. > > We have now received a LC request to change the default back to NTP. > > NTP is the "natural" choice for an IETF protocol. NTP is specified in IET= F > and is used in other MPLS protocols such as LSP ping. It is implemented o= n > almost every host and every router. However in general the implementation= s > provides a relatively low precision timestamp, and the NTP time > distribution infrastructure operates on a best effort basis. Thus even a > good client implementation would normally have a relatively low quality > path to the server, which would result in a low quality of timestamp. NTP > could be made to work to higher accuracy, but defacto upgrading NTP and > providing high quality NTP paths to the time servers is not getting much > attention. Computing timestamp differences is easier with NTP. > > On the other hand IEEE1588 has defacto become the two way time tranfer > protocol for precision applications. IEEE1588 only provides high quality > time in well engineered networks with some form of hop by hop assistance. > It is not widely implemented other than in equipment targeted to specific > markets, although one of those markets is in mobile backhaul applications > where we expect to see significant initial deployment of MPLS-TP. Computi= ng > timestamp differences is harder with IEEE1588 > > The loss-delay work is targeting to be able to do one way packet delay > measurement, so it does need a higher quality of timestamp than is requir= ed > in general purpose network instrumentation. > > Converting from IEEE1588 to NTP is not trivial, since they use different > epochs, and different representations of sub-second time. In a > "traditional" NTP implementation the time error due to on the fly > conversion is likely to be small compared to the time error in the time > synchronization system, but an IEEE1588 system would need hardware > conversion to maintain the accuracy for an NTP timestamp. > > So the question arises, should we make IEEE1588 or NTP the default for > draft-ietf-mpls-loss-delay. Much as I would like to suggest that we shoul= d > go back to NTP for consistency with other IETF protocols, I have difficul= ty > reconciling this with the situation in network deployments and thus sugge= st > that we continue to use IEEE1588. > > What is the opinion of the working group? > > Stewart (speaking as a draft editor) > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > > > --bcaec53f9741dd08b8049d9acd63 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    Hi Shahram, I guess adding a requirement to take timestamp= rollover into account would do. If there is a strong reason to also leave = NTP timestamp as an option, a note explaining the ramification of leap seco= nds should be added. I suggest that a continuous timescale (i.e. PTP) would= be selected in the draft as the default/must option. Best, Ron

    On Thu, Mar 3, 2011 at 9:45 PM, Shahram Dava= ri <davari@broa= dcom.com> wrote:

    Hi Ron,

    =A0

    Although the PTPv2 is 80 bytes, but I don=92t see a need to use all 8= 0 bytes for delay measurement. The upper 2^32 seconds covers almost 136 yea= rs, which should be good enough to measure delay. Also lets=92 be compatibl= e with Y.1731 format since that HW already exist.

    =A0

    Thx

    Shahram

    =A0

    From:= Ron Cohen [mailto:ronc.ntear@gmail.com]
    Sent: Thursday, March 03, 2011 11:22 AM
    To: PDiamo= nd@semtech.com
    Cc: Shahram Davari; mpls@ietf.org; tictoc-bounces@ietf.org; tictoc@ietf.org
    Subject: Re: [TICTOC] draft-ietf-mpls-loss-delay Timestamp

    =A0

    Hi,

    I apologi= ze in advance if my comments below where already been discussed.

    The draft specify using PTPv1 timestamp format and not PTPv2 timestamp = format. The seconds part of the PTPv2 timestamp is 48bits, and not 32bits a= s written in the draft. NTP timestamps will roll over in 2036. PTPv2 timest= amps do not rollover.

    I don't think its advisable to include timestamps that rolls over ~= 20 years from now.

    In addition, NTP timestamp, unlike PTP timestamp= , 'jumps' in leap seconds events. This makes calculation of time di= fferences hard, and would render some measurements ambiguous. It is much ea= sier to use continuous timescale like PTP.

    In my opinion changing the timestamp format to PTPv2 timestamp format (= i.e. 48bit/32bit sec/ns) should be the right way to go. I would also remove= the NTP timestamp format option to avoid leap seconds confusion and 2036 r= ollover events.

    Best,
    Ron

    On Thu, Mar 3, 2011= at 8:26 PM, <= PDiamond@semtech.com> wrote:

    My feeling is= 1588 is the right answer in the long run since it is already
    coupled to the hardware and widely deployed in networks using the "pac= ket
    clock derived time" in precise time and frequency delivery.
    =
    Pat



    =A0 =A0 =A0 =A0 =A0 =A0 "Shahram Davari"=A0 =A0 =A0 =A0 =A0 =A0 <davari@broadcom.
    =A0 =A0 =A0 =A0 =A0 =A0 com> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 To
    =A0 = =A0 =A0 =A0 =A0 =A0 Sent by: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"stbryant@cisco.com&q= uot;
    =A0 =A0 =A0 =A0 =A0 =A0 tictoc-bounces@ie =A0 =A0 =A0 =A0 <stbryant@cisco.com&g= t;,
    =A0 =A0 =A0 =A0 =A0 =A0 tf.org<= /a> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"mpls@ietf.org" <mpls@ietf.org>
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cc
    = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= "tictoc@ietf.org= " <tictoc@= ietf.org>
    =A0 =A0 =A0 =A0 =A0 =A0 03/03/2011 10:05 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Subject
    =A0 =A0 =A0 =A0 =A0 = =A0 AM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Re: [TICTOC]

    =

    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-ietf-mpls-loss-delay
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Timestamp










    Hi Stewart,

    Ac= curate delay measurement requires the Timestamp to be done in HW. It is
    = true that most routers support NTP today, but the majority of those are
    really maintained in Software and AFAIK most HW based timestamps
    impleme= ntations are 1588 based and really the industry is shifting toward
    1588 = and SyncE for network synchronization. So I support 1588 as being the
    default.

    Thanks,
    Shahram

    From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf= .org] On Behalf Of
    Stewart Bryant
    Sent: Thursday, March 03, 2011 8:07 AM
    To: mpls@ietf.org
    Cc: tictoc@ietf.org
    Subject: = [TICTOC] draft-ietf-mpls-loss-delay Timestamp


    We have received a LC comment on draft-ietf-mpls-loss-delay concern= ing the
    default timestamp.

    In the first version of the draft we p= roposed NTP, but following initial
    comments from the MPLS-TP community w= e changed to IEEE1588. This
    requirement for IEEE1588 can be traced back to the choice of using IEEE1588=
    in Y.1731.

    We have now received a LC request to change the defau= lt back to NTP.

    NTP is the "natural" choice for an IETF pr= otocol. NTP is specified in IETF
    and is used in other MPLS protocols such as LSP ping. It is implemented on<= br>almost every host and every router. However in general the implementatio= ns
    provides a relatively low precision timestamp, and the NTP time
    distribution infrastructure operates on a best effort basis. Thus even agood client implementation would normally have a relatively low qualitypath to the server, which would result in a low quality of timestamp. NTP<= br> could be made to work to higher accuracy, but defacto upgrading NTP and
    = providing high quality NTP paths to the time servers is not getting muchattention. Computing timestamp differences is easier with NTP.

    On the other hand IEEE1588 has defacto become the two way time tranfer
    p= rotocol for precision applications. IEEE1588 only provides high quality
    = time in well engineered networks with some form of hop by hop assistance. It is not widely implemented other than in equipment targeted to specificmarkets, although one of those markets is in mobile backhaul applications=
    where we expect to see significant initial deployment of MPLS-TP. Compu= ting
    timestamp differences is harder with IEEE1588

    The loss-delay work is= targeting to be able to do one way packet delay
    measurement, so it does= need a higher quality of timestamp than is required
    in general purpose = network instrumentation.

    Converting from IEEE1588 to NTP is not trivial, since they use differen= t
    epochs, and different representations of sub-second time. In a
    &quo= t;traditional" NTP implementation the time error due to on the fly
    conversion is likely to be small compared to the time error in the time
    = synchronization system, but an IEEE1588 system would need hardware
    conve= rsion to maintain the accuracy for an NTP timestamp.

    So the question= arises, should we make IEEE1588 or NTP the default for
    draft-ietf-mpls-loss-delay. Much as I would like to suggest that we should<= br>go back to NTP for consistency with other IETF protocols, I have difficu= lty
    reconciling this with the situation in network deployments and thus = suggest
    that we continue to use IEEE1588.

    What is the opinion of the working= group?

    Stewart (speaking as a draft editor)

    _______________________________________________
    TICTOC ma= iling list
    TICTOC@ietf.orghttps://www.ietf.org/mailman/listinfo/tictoc


    ______________= _________________________________
    TICTOC mailing list
    TICTOC@ietf.org
    https://www.ietf.org/mailman/listinfo/tictoc

    =A0


    --bcaec53f9741dd08b8049d9acd63-- From rdroms.ietf@gmail.com Tue Mar 15 11:59:08 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3BE73A6B1D; Tue, 15 Mar 2011 11:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 TejoxVsdhu+f; Tue, 15 Mar 2011 11:59:07 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id EF6D43A6A7C; Tue, 15 Mar 2011 11:59:06 -0700 (PDT) Received: by iwl42 with SMTP id 42so1047408iwl.31 for ; Tue, 15 Mar 2011 12:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=elGUfmAXt/YnTV9Ryi5Qh8C0p1f/gPCaIcXs1dH5V2A=; b=pfyzlgWROPWVZNUcfxn78DMgCeczQtuQCeE06zX86Upqme6U7WnWhFvmkh+41kTwK3 qRJHfx3LIDQtGQKRp9mD5YlrsKaztjmpj0+5UwENyOO5iDmEi8QGq/qM9MLECmEdhxF4 qj/O7IROxAXobaC9i7XevDc6ZCeYlcs+JHqDc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=gkFm6qJkNoiZY5wxJvJ5ft/krSmyhvr9a/FiAHheeG67eQAbz1Qc9z6qo+PuqrIKiN adRdVW4XmjYNAOavQyWqmieq5YlgMC0Grp0owKD9WcWuClgma8fkCJGYU8wUM6Mai1om YiyYIa2Cc/R3JMvx7ZIPR70FceCYuRl484g9k= Received: by 10.42.168.2 with SMTP id u2mr16186863icy.389.1300215632069; Tue, 15 Mar 2011 12:00:32 -0700 (PDT) Received: from [10.87.217.6] (mobile-166-137-137-093.mycingular.net [166.137.137.93]) by mx.google.com with ESMTPS id xi12sm45218icb.18.2011.03.15.12.00.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2011 12:00:30 -0700 (PDT) References: <20110314154647.E3A7D3A6DE0@core3.amsl.com> In-Reply-To: <20110314154647.E3A7D3A6DE0@core3.amsl.com> Mime-Version: 1.0 (iPhone Mail 8F190) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8F190) From: Ralph Droms Date: Tue, 15 Mar 2011 15:00:23 -0400 To: "tsbsg15@itu.int" X-Mailman-Approved-At: Thu, 17 Mar 2011 10:28:29 -0700 Cc: "mpls@ietf.org" , "greg.jones@itu.int" , "Steve.Trowbridge@alcatel-lucent.com" , "iab-chair@iab.org" , "yoichi.maeda@ttc.or.jp" , "chair@ietf.org" , "hiroshi.ota@itu.int" , "iesg@ietf.org" , "tsbsg15@itu.int" , "rcallon@juniper.net" , "paf@cisco.com" , "stbryant@cisco.com" , "adrian.farrel@huawei.com" , "iab@iab.org" Subject: Re: [mpls] New Liaison Statement, "LS293 - Request for G-ACh channel codepoint to support traditional transport environment" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 18:59:08 -0000 Do we have time to wait until we meet in Prague to develop a response to thi= s liaison by Apr 1. - Ralph On Mar 14, 2011, at 11:46 AM, Greg Jones(ITU-T SG 15) wrot= e: >=20 > Title: LS293 - Request for G-ACh channel codepoint to support traditional t= ransport environment > Submission Date: 2011-03-14 > URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_deta= il.cgi?detail_id=3D1033=20 > Please reply by 2011-04-01 >=20 > From: Greg Jones(ITU-T SG 15) > To: IESG, IAB, IETF MPLS WG(chair@ietf.org,iab-chair@iab.org,rcallon@junip= er.net,swallow@cisco.com,loa@pi.nu) > Cc: paf@cisco.com > stbryant@cisco.com > adrian.farrel@huawei.com > mpls@ietf.org > iab@iab.org > iesg@ietf.org > yoichi.maeda@ttc.or.jp > Steve.Trowbridge@alcatel-lucent.com > Reponse Contact: tsbsg15@itu.int > greg.jones@itu.int > hiroshi.ota@itu.int > Technical Contact: yoichi.maeda@ttc.or.jp > Purpose: For action=20 > Body: At the February meeting of ITU-T Study Group 15, we have reached the= conclusion that the needs of many of the operators participating in this wo= rk are not met by the solutions currently under development in the IETF. The= refore, we have decided to progress this work through ITU-T Recommendations.= We request that the IETF provide the necessary G-ACh codepoint allocations t= o support this work through advancement of draft-tsb-mpls-tp-ach-ptn. Note t= hat we have done additional work during this meeting to more clearly define t= he network environment for this application and produced a scope of applicab= ility in TD522/WP3 (attached). draft-tsb-mpls-tp-ach-ptn will be updated to i= nclude this scope statement. > The use of this G-ACh code point will fully comply with the framework and a= rchitecture for MPLS-TP that is currently being defined by IETF in cooperati= on with ITU-T. Allocation of this code point will allow ITU-T to develop th= e tools required to address the unique needs of the transport network and wi= ll make more efficient use of the resources of both organizations. Providin= g this codepoint will allow ITU-T to satisfy the immediate needs expressed a= t the recent Study Group 15 meeting recognizing that it is very important fo= r ITU-T and IETF to provide timely solutions to maintain support for the MPL= S-TP agreements. >=20 > Attach: TD522/WP3 and C-1124 Appendix I. > Attachment(s): > LS293 - Request for G-ACh channel codepoint to support traditional tra= nsport environment - pdf body (https://datatracker.ietf.org/documents/LIAISO= N/file1208.pdf) > LS293 - Request for G-ACh channel codepoint to support traditional tra= nsport environment - pdf TD522/WP3 (https://datatracker.ietf.org/documents/L= IAISON/file1209.pdf) > LS293 - Request for G-ACh channel codepoint to support traditional tra= nsport environment - pdf C-1124 Appendix I (https://datatracker.ietf.org/doc= uments/LIAISON/file1210.pdf) >=20 >=20 >=20 From rdroms.ietf@gmail.com Tue Mar 15 12:52:25 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 419A93A6EB8; Tue, 15 Mar 2011 12:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 PWdnKL8kV19a; Tue, 15 Mar 2011 12:52:23 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id CB7E13A6EA7; Tue, 15 Mar 2011 12:52:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,190,1299456000"; d="scan'208";a="320620232" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2011 19:53:48 +0000 Received: from bxb-rdroms-8711.cisco.com (bxb-rdroms-8711.cisco.com [10.98.10.82]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2FJrkAL024065; Tue, 15 Mar 2011 19:53:46 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Tue, 15 Mar 2011 15:53:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110314154647.E3A7D3A6DE0@core3.amsl.com> To: Droms Ralph X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Thu, 17 Mar 2011 10:28:29 -0700 Cc: mpls@ietf.org, greg.jones@itu.int, Steve.Trowbridge@alcatel-lucent.com, iab-chair@iab.org, yoichi.maeda@ttc.or.jp, chair@ietf.org, hiroshi.ota@itu.int, The IESG , Ross Callon , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Stewart Bryant , Adrian Farrel , IAB IAB Subject: Re: [mpls] New Liaison Statement, "LS293 - Request for G-ACh channel codepoint to support traditional transport environment" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 19:52:25 -0000 Please ignore; this was intended for the IESG. - Ralph On Mar 15, 2011, at 3:00 PM 3/15/11, Ralph Droms wrote: > Do we have time to wait until we meet in Prague to develop a response = to this liaison by Apr 1. >=20 > - Ralph >=20 > On Mar 14, 2011, at 11:46 AM, Greg Jones(ITU-T SG 15) = wrote: >=20 >>=20 >> Title: LS293 - Request for G-ACh channel codepoint to support = traditional transport environment >> Submission Date: 2011-03-14 >> URL of the IETF Web page: = https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D1033=20= >> Please reply by 2011-04-01 >>=20 >> From: Greg Jones(ITU-T SG 15) >> To: IESG, IAB, IETF MPLS = WG(chair@ietf.org,iab-chair@iab.org,rcallon@juniper.net,swallow@cisco.com,= loa@pi.nu) >> Cc: paf@cisco.com >> stbryant@cisco.com >> adrian.farrel@huawei.com >> mpls@ietf.org >> iab@iab.org >> iesg@ietf.org >> yoichi.maeda@ttc.or.jp >> Steve.Trowbridge@alcatel-lucent.com >> Reponse Contact: tsbsg15@itu.int >> greg.jones@itu.int >> hiroshi.ota@itu.int >> Technical Contact: yoichi.maeda@ttc.or.jp >> Purpose: For action=20 >> Body: At the February meeting of ITU-T Study Group 15, we have = reached the conclusion that the needs of many of the operators = participating in this work are not met by the solutions currently under = development in the IETF. Therefore, we have decided to progress this = work through ITU-T Recommendations. We request that the IETF provide the = necessary G-ACh codepoint allocations to support this work through = advancement of draft-tsb-mpls-tp-ach-ptn. Note that we have done = additional work during this meeting to more clearly define the network = environment for this application and produced a scope of applicability = in TD522/WP3 (attached). draft-tsb-mpls-tp-ach-ptn will be updated to = include this scope statement. >> The use of this G-ACh code point will fully comply with the framework = and architecture for MPLS-TP that is currently being defined by IETF in = cooperation with ITU-T. Allocation of this code point will allow ITU-T = to develop the tools required to address the unique needs of the = transport network and will make more efficient use of the resources of = both organizations. Providing this codepoint will allow ITU-T to = satisfy the immediate needs expressed at the recent Study Group 15 = meeting recognizing that it is very important for ITU-T and IETF to = provide timely solutions to maintain support for the MPLS-TP agreements. >>=20 >> Attach: TD522/WP3 and C-1124 Appendix I. >> Attachment(s): >> LS293 - Request for G-ACh channel codepoint to support traditional = transport environment - pdf body = (https://datatracker.ietf.org/documents/LIAISON/file1208.pdf) >> LS293 - Request for G-ACh channel codepoint to support traditional = transport environment - pdf TD522/WP3 = (https://datatracker.ietf.org/documents/LIAISON/file1209.pdf) >> LS293 - Request for G-ACh channel codepoint to support traditional = transport environment - pdf C-1124 Appendix I = (https://datatracker.ietf.org/documents/LIAISON/file1210.pdf) >>=20 >>=20 >>=20 From malcolm.betts@zte.com.cn Thu Mar 17 14:05:14 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F793A693B; Thu, 17 Mar 2011 14:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.283 X-Spam-Level: X-Spam-Status: No, score=-101.283 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 bbpeRGEWZrox; Thu, 17 Mar 2011 14:05:13 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id A01E23A6B11; Thu, 17 Mar 2011 14:05:11 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 50833924098393; Fri, 18 Mar 2011 05:05:49 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 96281.7699619906; Fri, 18 Mar 2011 04:56:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p2HL6Wjw067402; Fri, 18 Mar 2011 05:06:32 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <20110314154647.E3A7D3A6DE0@core3.amsl.com> To: mpls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Thu, 17 Mar 2011 16:06:32 -0500 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-18 05:06:32, Serialize complete at 2011-03-18 05:06:32 Content-Type: multipart/alternative; boundary="=_alternative 0073F27785257856_=" X-MAIL: mse02.zte.com.cn p2HL6Wjw067402 Cc: mpls@ietf.org, iab-chair@iab.org, chair@ietf.org, iesg@ietf.org, rcallon@juniper.net, stbryant@cisco.com, iab@iab.org Subject: Re: [mpls] New Liaison Statement, "LS293 - Request for G-ACh channel codepoint to support traditional transport environment" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 21:05:14 -0000 This is a multipart message in MIME format. --=_alternative 0073F27785257856_= Content-Type: text/plain; charset="US-ASCII" This liaison and draft-tsb-mpls-tp-ach-ptn should be discussed during the next IETF meeting. I have request a slot for a presentation in the MPLS WG meeting. Regards, Malcolm Greg Jones(ITU-T SG 15) Sent by: mpls-bounces@ietf.org 14/03/2011 11:46 AM Please respond to tsbsg15@itu.int To chair@ietf.org, iab-chair@iab.org, rcallon@juniper.net, swallow@cisco.com, loa@pi.nu cc mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, Steve.Trowbridge@alcatel-lucent.com, yoichi.maeda@ttc.or.jp, iab@iab.org, paf@cisco.com, iesg@ietf.org, tsbsg15@itu.int, stbryant@cisco.com, adrian.farrel@huawei.com Subject [mpls] New Liaison Statement, "LS293 - Request for G-ACh channel codepoint to support traditional transport environment" Title: LS293 - Request for G-ACh channel codepoint to support traditional transport environment Submission Date: 2011-03-14 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1033 Please reply by 2011-04-01 From: Greg Jones(ITU-T SG 15) To: IESG, IAB, IETF MPLS WG(chair@ietf.org,iab-chair@iab.org,rcallon@juniper.net,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org iab@iab.org iesg@ietf.org yoichi.maeda@ttc.or.jp Steve.Trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: yoichi.maeda@ttc.or.jp Purpose: For action Body: At the February meeting of ITU-T Study Group 15, we have reached the conclusion that the needs of many of the operators participating in this work are not met by the solutions currently under development in the IETF. Therefore, we have decided to progress this work through ITU-T Recommendations. We request that the IETF provide the necessary G-ACh codepoint allocations to support this work through advancement of draft-tsb-mpls-tp-ach-ptn. Note that we have done additional work during this meeting to more clearly define the network environment for this application and produced a scope of applicability in TD522/WP3 (attached). draft-tsb-mpls-tp-ach-ptn will be updated to include this scope statement. The use of this G-ACh code point will fully comply with the framework and architecture for MPLS-TP that is currently being defined by IETF in cooperation with ITU-T. Allocation of this code point will allow ITU-T to develop the tools required to address the unique needs of the transport network and will make more efficient use of the resources of both organizations. Providing this codepoint will allow ITU-T to satisfy the immediate needs expressed at the recent Study Group 15 meeting recognizing that it is very important for ITU-T and IETF to provide timely solutions to maintain support for the MPLS-TP agreements. Attach: TD522/WP3 and C-1124 Appendix I. Attachment(s): LS293 - Request for G-ACh channel codepoint to support traditional transport environment - pdf body ( https://datatracker.ietf.org/documents/LIAISON/file1208.pdf) LS293 - Request for G-ACh channel codepoint to support traditional transport environment - pdf TD522/WP3 ( https://datatracker.ietf.org/documents/LIAISON/file1209.pdf) LS293 - Request for G-ACh channel codepoint to support traditional transport environment - pdf C-1124 Appendix I ( https://datatracker.ietf.org/documents/LIAISON/file1210.pdf) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --=_alternative 0073F27785257856_= Content-Type: text/html; charset="US-ASCII"
    This liaison and draft-tsb-mpls-tp-ach-ptn should be discussed during the next IETF meeting.  I have request a slot for a presentation in the MPLS WG meeting.

    Regards,

    Malcolm



    Greg Jones(ITU-T SG 15) <tsbsg15@itu.int>
    Sent by: mpls-bounces@ietf.org

    14/03/2011 11:46 AM
    Please respond to
    tsbsg15@itu.int
    To
    		chair@ietf.org, iab-chair@iab.org, rcallon@juniper.net, swallow@cisco.com, loa@pi.nu
    cc
    		mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, Steve.Trowbridge@alcatel-lucent.com, yoichi.maeda@ttc.or.jp, iab@iab.org, paf@cisco.com, iesg@ietf.org, tsbsg15@itu.int, stbryant@cisco.com, adrian.farrel@huawei.com
    Subject
    		[mpls] New Liaison Statement, "LS293 - Request for G-ACh channel codepoint to support traditional transport environment"






    Title: LS293 - Request for G-ACh channel codepoint to support traditional transport environment
    Submission Date: 2011-03-14
    URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1033
    Please reply by 2011-04-01

    From: Greg Jones(ITU-T SG 15) <tsbsg15@itu.int>
    To: IESG, IAB, IETF MPLS WG(chair@ietf.org,iab-chair@iab.org,rcallon@juniper.net,swallow@cisco.com,loa@pi.nu)
    Cc: paf@cisco.com
    stbryant@cisco.com
    adrian.farrel@huawei.com
    mpls@ietf.org
    iab@iab.org
    iesg@ietf.org
    yoichi.maeda@ttc.or.jp
    Steve.Trowbridge@alcatel-lucent.com
    Reponse Contact: tsbsg15@itu.int
    greg.jones@itu.int
    hiroshi.ota@itu.int
    Technical Contact: yoichi.maeda@ttc.or.jp
    Purpose: For action
    Body: At the February meeting of ITU-T Study Group 15, we have reached the conclusion that the needs of many of the operators participating in this work are not met by the solutions currently under development in the IETF. Therefore, we have decided to progress this work through ITU-T Recommendations. We request that the IETF provide the necessary G-ACh codepoint allocations to support this work through advancement of draft-tsb-mpls-tp-ach-ptn. Note that we have done additional work during this meeting to more clearly define the network environment for this application and produced a scope of applicability in TD522/WP3 (attached). draft-tsb-mpls-tp-ach-ptn will be updated to include this scope statement.
    The use of this G-ACh code point will fully comply with the framework and architecture for MPLS-TP that is currently being defined by IETF in cooperation with ITU-T.  Allocation of this code point will allow ITU-T to develop the tools required to address the unique needs of the transport network and will make more efficient use of the resources of both organizations.  Providing this codepoint will allow ITU-T to satisfy the immediate needs expressed at the recent Study Group 15 meeting recognizing that it is very important for ITU-T and IETF to provide timely solutions to maintain support for the MPLS-TP agreements.

    Attach: TD522/WP3 and C-1124 Appendix I.
    Attachment(s):
        LS293 - Request for G-ACh channel codepoint to support traditional transport environment - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1208.pdf)
        LS293 - Request for G-ACh channel codepoint to support traditional transport environment - pdf TD522/WP3 (https://datatracker.ietf.org/documents/LIAISON/file1209.pdf)
        LS293 - Request for G-ACh channel codepoint to support traditional transport environment - pdf C-1124 Appendix I (https://datatracker.ietf.org/documents/LIAISON/file1210.pdf)



    _______________________________________________
    mpls mailing list
    mpls@ietf.org
    https://www.ietf.org/mailman/listinfo/mpls
    --=_alternative 0073F27785257856_=-- From jmh@joelhalpern.com Thu Mar 17 15:28:53 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A59D3A6A64 for ; Thu, 17 Mar 2011 15:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, 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 YyAtKXXe-mLY for ; Thu, 17 Mar 2011 15:28:51 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id DDA103A6B12 for ; Thu, 17 Mar 2011 15:28:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9E4D44300D2 for ; Thu, 17 Mar 2011 15:30:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-147.clppva.btas.verizon.net [71.161.52.147]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 249024300D1 for ; Thu, 17 Mar 2011 15:30:20 -0700 (PDT) Message-ID: <4D828B81.2060600@joelhalpern.com> Date: Thu, 17 Mar 2011 18:30:25 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Comments on draft-ietf-mpls-tp-on-demand-cv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 22:28:53 -0000 As the chairs have issued the last call for this, I have taken another look at it. The format description (section 2) has some problems that need to be fixed before this goes to the AD. Section 2.1.1 is called "DSMAP/DDMAP Based Non-IP Address TLV." And it refers to an "address TLV". The problem is that RFC 4379 does not actually use the terminology DSMAP or DDMAP. I would not be surprised if somehow these terms are a reference to the downstream mapping TLV from RFC 4379, but if so that needs to be stated explicitly. Further, 4379 does not refer to the contents of the Dowstream Mapping TLV as an "address TLV". In fact, the contents that are being referred to are not a "TLV", as the length is implied by the type, not included in the field. Some clearer reference is needed. Similarly, section 2.2 talks about the Source/Destination Address TLV. I first assumed that referenced the TLV defined in 2.2.1. However, the text then goes on to talk about 4379 and about the information defined in section 2.1.1 (which is not even a TLV.) Minor: The information in these source and destination TLVs in 2.2 is not an address. It would be a good idea to call them something else. Is it worth stating in section 3 that the Pad TLV from 4379 is used when needed to meet the padding requirement of the framework? The wording choice for describing the usage in section 3.3 is a bit confusing, appearing as it does after 3.2. 3.2 says that you can use IP encapsulation with ACH, and that you use the IP ACH type. Section 3.3 then refers to "using On-demand CV via LSP-Ping with the ACH header" when referring to messages that will not have IP headers. But the text just finished telling me that I might have an ACH header and an IP header. Some other way of identifying the two cases would be helpful. There seems to be an inconsistency between sections 3.4.1 and 3.4.2. Section 3.4.1 says that if the R flag is set, the egress LSR "SHOULD" return reverse path FEC information. Section 3.4.2 says that if the R flag is set, the egress LSR "MAY" return the information. Which is it? Yours, Joel M. Halpern From hffellow@hotmail.com Thu Mar 17 18:43:35 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42F063A6A30; Thu, 17 Mar 2011 18:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.97 X-Spam-Level: *** X-Spam-Status: No, score=3.97 tagged_above=-999 required=5 tests=[AWL=-2.122, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, SARE_SUB_ENC_GB2312=1.345] 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 nOF0t4AyOg0S; Thu, 17 Mar 2011 18:43:34 -0700 (PDT) Received: from blu0-omc1-s27.blu0.hotmail.com (blu0-omc1-s27.blu0.hotmail.com [65.55.116.38]) by core3.amsl.com (Postfix) with ESMTP id 2DD073A69CF; Thu, 17 Mar 2011 18:43:34 -0700 (PDT) Received: from BLU0-SMTP164 ([65.55.116.9]) by blu0-omc1-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 18:45:02 -0700 X-Originating-IP: [112.64.191.37] X-Originating-Email: [hffellow@hotmail.com] Message-ID: Received: from [172.25.23.78] ([112.64.191.37]) by BLU0-SMTP164.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 18:45:00 -0700 References: <765245.77484.qm@web15603.mail.cnb.yahoo.com> In-Reply-To: <765245.77484.qm@web15603.mail.cnb.yahoo.com> MIME-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="GB2312" X-Mailer: iPhone Mail (8C148) From: Huang Feng Date: Fri, 18 Mar 2011 09:44:59 +0800 To: Larry X-OriginalArrivalTime: 18 Mar 2011 01:45:01.0566 (UTC) FILETIME=[18A069E0:01CBE50E] Cc: "mpls@ietf.org" , "greg.jones@itu.int" , "Steve.Trowbridge@alcatel-lucent.com" , "stbryant@cisco.com" , "iab-chair@iab.org" , "yoichi.maeda@ttc.or.jp" , "chair@ietf.org" , "hiroshi.ota@itu.int" , "iesg@ietf.org" , "rcallon@juniper.net" , "tsbsg15@itu.int" , "paf@cisco.com" , "adrian.farrel@huawei.com" , "iab@iab.org" Subject: Re: [mpls] =?gb2312?b?u9i4tKO6ICBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJM?= =?gb2312?b?UzI5MyAtIFJlcXVlc3QgZm9yIEctQUNoIGNoYW5uZWwgY29kZXBvaW50IHRv?= =?gb2312?b?IHN1cHBvcnQgdHJhZGl0aW9uYWwgdHJhbnNwb3J0IGVudmlyb25tZW50Ig==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 01:43:35 -0000 +1 It is an important issue for MPLA group, it should be discussied! Feng =B7=A2=D7=D4=CE=D2=B5=C4 iPhone =D4=DA 2011-3-16=A3=AC0:18=A3=ACLarry =D0=B4=B5=C0= =A3=BA > Support! >=20 > ************************************************************************* > Han Li, Ph.D=20 > China Mobile Research Institute > Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China=20 > Fax: +86 10 63601087=20 > MOBILE: 13501093385=20 > ************************************************************************* >=20 >=20 > --- 11=C4=EA3=D4=C214=C8=D5=A3=AC=D6=DC=D2=BB, Greg Jones =D0=B4=B5=C0=A3=BA >=20 >> =B7=A2=BC=FE=C8=CB: Greg Jones >> =D6=F7=CC=E2: [mpls] New Liaison Statement, "LS293 - Request for G-ACh ch= annel codepoint to support traditional transport environment" >> =CA=D5=BC=FE=C8=CB: chair@ietf.org, iab-chair@iab.org, rcallon@juniper.ne= t, swallow@cisco.com, loa@pi.nu >> =B3=AD=CB=CD: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, Ste= ve.Trowbridge@alcatel-lucent.com, yoichi.maeda@ttc.or.jp, iab@iab.org, paf@c= isco.com, iesg@ietf.org, tsbsg15@itu.int, stbryant@cisco.com, adrian.farrel@= huawei.com >> =C8=D5=C6=DA: 2011=C4=EA3=D4=C214=C8=D5,=D6=DC=D2=BB,=CF=C2=CE=E711:46 >>=20 >> Title: LS293 - Request for G-ACh channel codepoint to >> support traditional transport environment >> Submission Date: 2011-03-14 >> URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_det= ail.cgi?detail_id=3D1033 >>=20 >> Please reply by 2011-04-01 >>=20 >> From: Greg Jones(ITU-T SG 15) >> To: IESG, IAB, IETF MPLS WG(chair@ietf.org,iab-chair@iab.org,rcallon@juni= per.net,swallow@cisco.com,loa@pi.nu) >> Cc: paf@cisco.com >> stbryant@cisco.com >> adrian.farrel@huawei.com >> mpls@ietf.org >> iab@iab.org >> iesg@ietf.org >> yoichi.maeda@ttc.or.jp >> Steve.Trowbridge@alcatel-lucent.com >> Reponse Contact: tsbsg15@itu.int >> greg.jones@itu.int >> hiroshi.ota@itu.int >> Technical Contact: yoichi.maeda@ttc.or.jp >> Purpose: For action=20 >> Body: At the February meeting of ITU-T Study Group 15, we >> have reached the conclusion that the needs of many of the >> operators participating in this work are not met by the >> solutions currently under development in the IETF. >> Therefore, we have decided to progress this work through >> ITU-T Recommendations. We request that the IETF provide the >> necessary G-ACh codepoint allocations to support this work >> through advancement of draft-tsb-mpls-tp-ach-ptn. Note that >> we have done additional work during this meeting to more >> clearly define the network environment for this application >> and produced a scope of applicability in TD522/WP3 >> (attached). draft-tsb-mpls-tp-ach-ptn will be updated to >> include this scope statement. >> The use of this G-ACh code point will fully comply with the >> framework and architecture for MPLS-TP that is currently >> being defined by IETF in cooperation with ITU-T.=20 >> Allocation of this code point will allow ITU-T to develop >> the tools required to address the unique needs of the >> transport network and will make more efficient use of the >> resources of both organizations. Providing this >> codepoint will allow ITU-T to satisfy the immediate needs >> expressed at the recent Study Group 15 meeting recognizing >> that it is very important for ITU-T and IETF to provide >> timely solutions to maintain support for the MPLS-TP >> agreements. >>=20 >> Attach: TD522/WP3 and C-1124 Appendix I. >> Attachment(s): >> LS293 - Request for G-ACh channel >> codepoint to support traditional transport environment - pdf >> body (https://datatracker.ietf.org/documents/LIAISON/file1208.pdf) >> LS293 - Request for G-ACh channel >> codepoint to support traditional transport environment - pdf >> TD522/WP3 (https://datatracker.ietf.org/documents/LIAISON/file1209.pdf) >> LS293 - Request for G-ACh channel >> codepoint to support traditional transport environment - pdf >> C-1124 Appendix I (https://datatracker.ietf.org/documents/LIAISON/file121= 0.pdf) >>=20 >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From liu.guoman@zte.com.cn Thu Mar 17 19:23:36 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA8553A69D8 for ; Thu, 17 Mar 2011 19:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 gwCdD8tAHfwY for ; Thu, 17 Mar 2011 19:23:35 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 415BF3A67EE for ; Thu, 17 Mar 2011 19:23:35 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 5083806486374; Fri, 18 Mar 2011 10:24:13 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 84746.3730301063; Fri, 18 Mar 2011 10:25:01 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p2I2OtWP049871; Fri, 18 Mar 2011 10:24:55 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) To: elisa.bellagamba@ericsson.com, loa.andersson@ericsson.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Fri, 18 Mar 2011 10:25:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-18 10:24:56, Serialize complete at 2011-03-18 10:24:56 Content-Type: multipart/alternative; boundary="=_alternative 000D548748257857_=" X-MAIL: mse02.zte.com.cn p2I2OtWP049871 Cc: mpls@ietf.org Subject: [mpls] a few comments for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 02:23:36 -0000 This is a multipart message in MIME format. --=_alternative 000D548748257857_= Content-Type: text/plain; charset="US-ASCII" hi,both today i reivew this draft, In my mind, there need a few question to be clarified for this draft . 1 for BFD Configuration sub-TLV, I only see MPLS OAM SOURCE MEP-ID sub-TLV based on per-node MEP; if considing of per-interface MEP , is it necessary to add the field for the interface? 2 for MPLS OAM PM Delay sub-TLV, I personally think that it is unnecessary to have E or C flag for DM function like PM Loss sub-TLV. but in section 3.2.3, there is the context of Configuration Flags including E or C flag. 3 for MPLS OAM FMS sub-TLV, In my mind, LDI is only flag bit in the AIS packet. so the Refresh timer of LDI should be the same as one of AIS. I think it is unnecessary to have D Flag bit in the format of FMS sub-TLV? it is only personally understanding , do i miss something important? B.R. liu -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000D548748257857_= Content-Type: text/html; charset="US-ASCII"
    hi,both
      today i reivew this draft, In my mind, there need a few question to be clarified for this draft .
    1 for BFD Configuration sub-TLV, I only see  MPLS OAM SOURCE MEP-ID sub-TLV based on per-node MEP;
      if considing of per-interface MEP , is it necessary to add the field for the interface?

    2 for MPLS OAM PM Delay sub-TLV, I personally think that it is unnecessary to have E or C flag
      for DM function like PM Loss sub-TLV. but in section 3.2.3, there is the context of Configuration Flags including
      E or C flag.

    3 for MPLS OAM FMS sub-TLV, In my mind, LDI is only flag bit in the AIS packet. so
      the Refresh timer of LDI should be the same as one of AIS. I think it is unnecessary to
      have D Flag bit in the format of FMS sub-TLV?

    it is only personally understanding , do i miss something important?

    B.R.
    liu 




    --------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
    --=_alternative 000D548748257857_=-- From gregimirsky@gmail.com Thu Mar 17 21:32:31 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7B583A6A17; Thu, 17 Mar 2011 21:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 GDR35FozUpjx; Thu, 17 Mar 2011 21:32:30 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 136E93A69D3; Thu, 17 Mar 2011 21:32:29 -0700 (PDT) Received: by vxg33 with SMTP id 33so3807059vxg.31 for ; Thu, 17 Mar 2011 21:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=dZR1m8JO3m+/i1NIMPhOEgQqZ2QbbL/gChQTNDEEOOo=; b=htU3LVk32CjgxUw+Uk8gqWYlrIz96PhX0NC0dnU9Z5KAxfmBiU65VIWhanjNzWlEpZ Zt0A8lGkwxTzli+MSYQcSpP0bCkDRuLEZLUFbwxSYhkYonKX/1KsAWA0ftwfuehOYy2V 02kUcCgEeT9s2Bc/Lrg/J+p7Y+x/q2AGT9Xkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=kDI2ZiBlD11va9fsX7M1jRcOVla9Opkei91Y55SjqpxmrfEDrhnoj+IQZ2+1Pvmwwc fkpe74Mb6znvmdwi18FbXMeYhZHRDu1BP6M7IQuk5otaQ/wN+qE17EYTxJNdQaKiSYsw N4XpmpIo7oiq6hUql0gF1Fg8aRll3fOOOIcuk= MIME-Version: 1.0 Received: by 10.52.159.3 with SMTP id wy3mr835884vdb.289.1300422838577; Thu, 17 Mar 2011 21:33:58 -0700 (PDT) Received: by 10.52.169.35 with HTTP; Thu, 17 Mar 2011 21:33:58 -0700 (PDT) Date: Thu, 17 Mar 2011 21:33:58 -0700 Message-ID: From: Greg Mirsky To: zhang.fei3@zte.com.cn, wu.bo@zte.com.cn, Elisa Bellagamba , Attila Takacs , dai.xuehui@zte.com.cn, xiao.min2@zte.com.cn, mpls@ietf.org, pwe3 Content-Type: multipart/alternative; boundary=bcaec53f979759f0a2049eba49b8 Subject: [mpls] Comments on draft-zhang-mpls-tp-pw-oam-config-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 04:32:32 -0000 --bcaec53f979759f0a2049eba49b8 Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, Editors, and All, Please kindly find my comments to the document below - Editorial. In Introduction, para 2 's/In contract/In contrast/' - section 4.1 positions proactive CC-CV-RDI as extension of BFD and states that BFD should evolve to close gaps existing between if and OAM solutions defined in ietf-mpls-tp-cc-cv-rdi. I don't consider solution described for proactive CC/CV/RDI as extension of VCCV BFD, RFC 5885 and I think that mechanisms defined for proactive CC/CV/RDI can be applied for SS-PW and MS-PW as well as they are applicable to p2p bi-directional LSPs, co-routed and associated. If that's the case, then VCCV BFD can be used as defined in RFC 5885, without modifications and the ietf-mpls-tp-cc-cv-rdi will address proactive CV gap for PW. - Section 7.1 I'd propose to define 'C' bit to indicate support of CC/CV/RDI in addition to bits L, D, and F because support of VCCV BFD not necessarily equates to support of ietf-mpls-tp-cc-cv-rdi. Regards, Greg --bcaec53f979759f0a2049eba49b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors, Editors, and All,
    Please kindly find my comments to the do= cument below
    • Editorial. In Introduction, para 2 's/In contra= ct/In contrast/'
    • section 4.1 positions proactive CC-CV-RDI as e= xtension of BFD and states that BFD should evolve to close gaps existing be= tween if and OAM solutions defined in ietf-mpls-tp-cc-cv-rdi. I don't c= onsider solution described for proactive CC/CV/RDI as extension of VCCV BFD= , RFC 5885 and I think that mechanisms defined for proactive CC/CV/RDI can = be applied for SS-PW and MS-PW as well as they are applicable to p2p bi-dir= ectional LSPs, co-routed and associated. If that's the case, then VCCV = BFD can be used as defined in RFC 5885, without modifications and the ietf-= mpls-tp-cc-cv-rdi will address proactive CV gap for PW.
    • Section 7.1 I'd propose to define 'C' bit to indicate suppo= rt of CC/CV/RDI in addition to bits L, D, and F because support of VCCV BFD= not necessarily equates to support of ietf-mpls-tp-cc-cv-rdi.
    Regards,
    Greg
    --bcaec53f979759f0a2049eba49b8-- From AMukherjee@ixiacom.com Fri Mar 18 00:18:49 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28BCD3A6AEB; Fri, 18 Mar 2011 00:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] 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 Dw5Zl+YohS6u; Fri, 18 Mar 2011 00:18:48 -0700 (PDT) Received: from ixqw-mail-out.ixiacom.com (ixqw-mail-out.ixiacom.com [66.77.12.12]) by core3.amsl.com (Postfix) with ESMTP id 6BFBD3A6A81; Fri, 18 Mar 2011 00:18:48 -0700 (PDT) Received: from ixcaexch07.ixiacom.com ([fe80:0000:0000:0000:e021:fcf5:238.143.231.20]) by IXCA-HC2.ixiacom.com ([10.200.2.51]) with mapi; Fri, 18 Mar 2011 00:20:18 -0700 From: Apratim Mukherjee To: "mpls-tp@ietf.org" , "mpls@ietf.org" Date: Fri, 18 Mar 2011 00:20:14 -0700 Thread-Topic: Query on draft-ietf-mpls-tp-linear-protection-06.txt Thread-Index: AcvlPOyTCSA0TXCZTEmZ4FL/Q5bxdw== Message-ID: <716209EC190CA740BA799AC4ACCBFB5D1852AD8AFE@IXCAEXCH07.ixiacom.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] Query on draft-ietf-mpls-tp-linear-protection-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 07:18:49 -0000 To the authors. Say a PSC State Machine ( referred to as SM below ) is in state Normal. Now PSC SM gets SF on Protect as input event, hence goes to Unavailable. Next PSC SM gets SF on Working , so stays in Unavailable.=20 ( At this point this LSP group is incapable of carrying client traffic)=20 Next PSC SM gets SF Clear on Protect as input event. As per the draft , now= the PSC SM moves to Normal state.=20 But should it not be going to PSC Protecting Failure state since client tra= ffic should be using the Protect Path in this state ? I did see a similar query and reply from Yaacov which seems to suggest that= when we move Normal state here , this is something=20 Like a temporary transitioning state and the SF on Working should now be pr= ovided as input so that the SM can move to the correct=20 Protecting Failure State.=20 Specifically : 'In essence, as pointed out in the comment in row #80 of the= LC comments the state machine dictates that you=20 transition through Normal to arrive at the Protecting failure state.' , tho= ugh the context was a slightly different sequence of=20 steps involving SF , FS and Clear .=20 Does this mean that in certain cases , we need to store the other pending e= vents to the PSC state machine to be provided as input later ? In any case , can you please also point me to the location of the LC commen= ts for this draft. Regards, Apratim =20 From zhang.fei3@zte.com.cn Fri Mar 18 00:55:43 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F9133A680A; Fri, 18 Mar 2011 00:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.163 X-Spam-Level: X-Spam-Status: No, score=-98.163 tagged_above=-999 required=5 tests=[AWL=-0.529, 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 YcT8zjV2UGeE; Fri, 18 Mar 2011 00:55:42 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 091BC3A67F7; Fri, 18 Mar 2011 00:55:41 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 50832203882679; Fri, 18 Mar 2011 15:56:19 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 96281.6544722859; Fri, 18 Mar 2011 15:47:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p2I7usCI018693; Fri, 18 Mar 2011 15:56:54 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Greg Mirsky MIME-Version: 1.0 X-KeepSent: 88A79A88:1B81C977-48257857:0029F3BE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 18 Mar 2011 15:56:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-18 15:56:55, Serialize complete at 2011-03-18 15:56:55 Content-Type: multipart/alternative; boundary="=_alternative 002BA94248257857_=" X-MAIL: mse01.zte.com.cn p2I7usCI018693 Cc: mpls@ietf.org, wu.bo@zte.com.cn, Attila Takacs , pwe3 , Elisa Bellagamba Subject: Re: [mpls] Comments on draft-zhang-mpls-tp-pw-oam-config-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 07:55:43 -0000 This is a multipart message in MIME format. --=_alternative 002BA94248257857_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR3JlZw0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMsIHBsZWFzZSBzZWUgdGhlIHJlc3Bv bnNlIGZvciB0aGVtLg0KDQogQ29tbWVudHMgMTogVGhpcyB3aWxsIGJlIHJldmlzZWQgaW4gdGhl IG5leHQgdmVyc2lvbg0KIENvbW1lbnRzIDI6IEp1c3QgYXMgeW91IHNhaWQsIHRoZSBmdW5jdGlv biBvZiBDQyBtb2RlIGRlZmluZSBpbiANCltDQy1DVi1SREldIGlzIHRvdGFsbHkgdGhlIHNhbWUg YXMgVkNDViBCRkQsIHNvIHRoZXJlIGFyZSB0d28gY2hvaWNlcyBmb3IgDQpNUExTLVRQIFBXLg0K ICAgICAgICAgICAgICgxKVZDQ1YgQkZEIGlzIHVzZWQgZm9yIHRoZSBDQyBtb2RlLCBhbmQgQ0Mt Q1YtUkRJIHVzZWQgZm9yIA0KdGhlIENWIG1vZGUNCiAgICAgICAgICAgICAoMilDQy1DVi1SREkg aXMgdXNlZCBmb3IgYm90aCB0aGUgQ0MgYW5kIENWIG1vZGVzLCBhbmQgVkNDViANCkJGRCBpcyBu b3QgdXNlZC4NCiAgICAgICAgICAgICBGb3IgYmFrd2FyZCBjb21wYXRpYmlsaXR5LCBjaG9pY2Ug MSBpcyB0aGUgYmV0dGVyIGNob2ljZTsgYW5kIA0KdGhpcyB3aWxsIGJlIHJldmlzZWQgaW4gdGhl IG5leHQgdmVyc2lvbiANCkNvbW1lbnRzIDM6IEFncmVlLCBpZiBWQ0NWIEJGRCBpcyBub3QgdXNl ZCwgYm90aCBDQyBhbmQgQ1YgYml0cyBTSE9VTEQgYmUgDQpkZWZpbmVkOyBpZiBWQ0NWIEJGRCBp cyB1c2VkIGZvciB0aGUgQ0MgbW9kZSwgb25seSBDViBiaXQgU0hPVUxEIGJlIA0KZGVmaW5lZC4N Cg0KDQpCLlIuDQoNCkZlaQ0KDQoNCg0KR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNv bT4gDQoyMDExLTAzLTE4IDEyOjMzDQoNCsrVvP7Iyw0KemhhbmcuZmVpM0B6dGUuY29tLmNuLCB3 dS5ib0B6dGUuY29tLmNuLCBFbGlzYSBCZWxsYWdhbWJhIA0KPGVsaXNhLmJlbGxhZ2FtYmFAZXJp Y3Nzb24uY29tPiwgQXR0aWxhIFRha2FjcyANCjxBdHRpbGEuVGFrYWNzQGVyaWNzc29uLmNvbT4s IGRhaS54dWVodWlAenRlLmNvbS5jbiwgeGlhby5taW4yQHp0ZS5jb20uY24sIA0KbXBsc0BpZXRm Lm9yZywgcHdlMyA8cHdlM0BpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0KQ29tbWVudHMgb24gZHJh ZnQtemhhbmctbXBscy10cC1wdy1vYW0tY29uZmlnLTA0DQoNCg0KDQoNCg0KDQpEZWFyIEF1dGhv cnMsIEVkaXRvcnMsIGFuZCBBbGwsDQpQbGVhc2Uga2luZGx5IGZpbmQgbXkgY29tbWVudHMgdG8g dGhlIGRvY3VtZW50IGJlbG93DQpFZGl0b3JpYWwuIEluIEludHJvZHVjdGlvbiwgcGFyYSAyICdz L0luIGNvbnRyYWN0L0luIGNvbnRyYXN0LycNCnNlY3Rpb24gNC4xIHBvc2l0aW9ucyBwcm9hY3Rp dmUgQ0MtQ1YtUkRJIGFzIGV4dGVuc2lvbiBvZiBCRkQgYW5kIHN0YXRlcyANCnRoYXQgQkZEIHNo b3VsZCBldm9sdmUgdG8gY2xvc2UgZ2FwcyBleGlzdGluZyBiZXR3ZWVuIGlmIGFuZCBPQU0gc29s dXRpb25zIA0KZGVmaW5lZCBpbiBpZXRmLW1wbHMtdHAtY2MtY3YtcmRpLiBJIGRvbid0IGNvbnNp ZGVyIHNvbHV0aW9uIGRlc2NyaWJlZCBmb3IgDQpwcm9hY3RpdmUgQ0MvQ1YvUkRJIGFzIGV4dGVu c2lvbiBvZiBWQ0NWIEJGRCwgUkZDIDU4ODUgYW5kIEkgdGhpbmsgdGhhdCANCm1lY2hhbmlzbXMg ZGVmaW5lZCBmb3IgcHJvYWN0aXZlIENDL0NWL1JESSBjYW4gYmUgYXBwbGllZCBmb3IgU1MtUFcg YW5kIA0KTVMtUFcgYXMgd2VsbCBhcyB0aGV5IGFyZSBhcHBsaWNhYmxlIHRvIHAycCBiaS1kaXJl Y3Rpb25hbCBMU1BzLCBjby1yb3V0ZWQgDQphbmQgYXNzb2NpYXRlZC4gSWYgdGhhdCdzIHRoZSBj YXNlLCB0aGVuIFZDQ1YgQkZEIGNhbiBiZSB1c2VkIGFzIGRlZmluZWQgDQppbiBSRkMgNTg4NSwg d2l0aG91dCBtb2RpZmljYXRpb25zIGFuZCB0aGUgaWV0Zi1tcGxzLXRwLWNjLWN2LXJkaSB3aWxs IA0KYWRkcmVzcyBwcm9hY3RpdmUgQ1YgZ2FwIGZvciBQVy4NClNlY3Rpb24gNy4xIEknZCBwcm9w b3NlIHRvIGRlZmluZSAnQycgYml0IHRvIGluZGljYXRlIHN1cHBvcnQgb2YgQ0MvQ1YvUkRJIA0K aW4gYWRkaXRpb24gdG8gYml0cyBMLCBELCBhbmQgRiBiZWNhdXNlIHN1cHBvcnQgb2YgVkNDViBC RkQgbm90IA0KbmVjZXNzYXJpbHkgZXF1YXRlcyB0byBzdXBwb3J0IG9mIGlldGYtbXBscy10cC1j Yy1jdi1yZGkuDQpSZWdhcmRzLA0KR3JlZw0KDQo= --=_alternative 002BA94248257857_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdyZWc8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciBjb21t ZW50cywgcGxlYXNlIHNlZQ0KdGhlIHJlc3BvbnNlIGZvciB0aGVtLjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7Q29tbWVudHMgMTogVGhpcyB3 aWxsIGJlIHJldmlzZWQNCmluIHRoZSBuZXh0IHZlcnNpb248L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO0NvbW1lbnRzIDI6IEp1c3QgYXMgeW91IHNhaWQs DQp0aGUgZnVuY3Rpb24gb2YgQ0MgbW9kZSBkZWZpbmUgaW4gW0NDLUNWLVJESV0gaXMgdG90YWxs eSB0aGUgc2FtZSBhcyBWQ0NWDQpCRkQsIHNvIHRoZXJlIGFyZSB0d28gY2hvaWNlcyBmb3IgTVBM Uy1UUCBQVy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsoMSlWQ0NWIEJGRCBp cyB1c2VkIGZvciB0aGUgQ0MgbW9kZSwgYW5kIENDLUNWLVJESSB1c2VkIGZvciB0aGUgQ1YNCm1v ZGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsoMilDQy1DVi1SREkgaXMgdXNl ZCBmb3IgYm90aCB0aGUgQ0MgYW5kIENWIG1vZGVzLCBhbmQgVkNDViBCRkQgaXMNCm5vdCB1c2Vk LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO0ZvciBiYWt3YXJkIGNvbXBhdGli aWxpdHksIGNob2ljZSAxIGlzIHRoZSBiZXR0ZXIgY2hvaWNlOyBhbmQgdGhpcw0Kd2lsbCBiZSBy ZXZpc2VkIGluIHRoZSBuZXh0IHZlcnNpb24gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5Db21tZW50cyAzOiBBZ3JlZSwgaWYgVkNDViBCRkQgaXMgbm90DQp1c2Vk LCBib3RoIENDIGFuZCBDViBiaXRzIFNIT1VMRCBiZSBkZWZpbmVkOyBpZiBWQ0NWIEJGRCBpcyB1 c2VkIGZvciB0aGUNCkNDIG1vZGUsIG9ubHkgQ1YgYml0IFNIT1VMRCBiZSBkZWZpbmVkLjwvZm9u dD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Qi5SLjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RmVpPC9mb250 Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkdyZWcgTWly c2t5ICZsdDtncmVnaW1pcnNreUBnbWFpbC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDMtMTggMTI6MzM8L2ZvbnQ+DQo8dGQgd2lk dGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+emhhbmcuZmVpM0B6dGUu Y29tLmNuLCB3dS5ib0B6dGUuY29tLmNuLA0KRWxpc2EgQmVsbGFnYW1iYSAmbHQ7ZWxpc2EuYmVs bGFnYW1iYUBlcmljc3Nvbi5jb20mZ3Q7LCBBdHRpbGEgVGFrYWNzICZsdDtBdHRpbGEuVGFrYWNz QGVyaWNzc29uLmNvbSZndDssDQpkYWkueHVlaHVpQHp0ZS5jb20uY24sIHhpYW8ubWluMkB6dGUu Y29tLmNuLCBtcGxzQGlldGYub3JnLCBwd2UzICZsdDtwd2UzQGlldGYub3JnJmd0OzwvZm9udD4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Q29tbWVu dHMgb24gZHJhZnQtemhhbmctbXBscy10cC1wdy1vYW0tY29uZmlnLTA0PC9mb250PjwvdGFibGU+ DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJy PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkRlYXIgQXV0aG9ycywgRWRp dG9ycywgYW5kIEFsbCw8YnI+DQpQbGVhc2Uga2luZGx5IGZpbmQgbXkgY29tbWVudHMgdG8gdGhl IGRvY3VtZW50IGJlbG93PC9mb250Pg0KPHVsPg0KPGxpPjxmb250IHNpemU9Mz5FZGl0b3JpYWwu IEluIEludHJvZHVjdGlvbiwgcGFyYSAyICdzL0luIGNvbnRyYWN0L0luIGNvbnRyYXN0Lyc8L2Zv bnQ+DQo8bGk+PGZvbnQgc2l6ZT0zPnNlY3Rpb24gNC4xIHBvc2l0aW9ucyBwcm9hY3RpdmUgQ0Mt Q1YtUkRJIGFzIGV4dGVuc2lvbg0Kb2YgQkZEIGFuZCBzdGF0ZXMgdGhhdCBCRkQgc2hvdWxkIGV2 b2x2ZSB0byBjbG9zZSBnYXBzIGV4aXN0aW5nIGJldHdlZW4NCmlmIGFuZCBPQU0gc29sdXRpb25z IGRlZmluZWQgaW4gaWV0Zi1tcGxzLXRwLWNjLWN2LXJkaS4gSSBkb24ndCBjb25zaWRlcg0Kc29s dXRpb24gZGVzY3JpYmVkIGZvciBwcm9hY3RpdmUgQ0MvQ1YvUkRJIGFzIGV4dGVuc2lvbiBvZiBW Q0NWIEJGRCwgUkZDDQo1ODg1IGFuZCBJIHRoaW5rIHRoYXQgbWVjaGFuaXNtcyBkZWZpbmVkIGZv ciBwcm9hY3RpdmUgQ0MvQ1YvUkRJIGNhbiBiZQ0KYXBwbGllZCBmb3IgU1MtUFcgYW5kIE1TLVBX IGFzIHdlbGwgYXMgdGhleSBhcmUgYXBwbGljYWJsZSB0byBwMnAgYmktZGlyZWN0aW9uYWwNCkxT UHMsIGNvLXJvdXRlZCBhbmQgYXNzb2NpYXRlZC4gSWYgdGhhdCdzIHRoZSBjYXNlLCB0aGVuIFZD Q1YgQkZEIGNhbiBiZQ0KdXNlZCBhcyBkZWZpbmVkIGluIFJGQyA1ODg1LCB3aXRob3V0IG1vZGlm aWNhdGlvbnMgYW5kIHRoZSBpZXRmLW1wbHMtdHAtY2MtY3YtcmRpDQp3aWxsIGFkZHJlc3MgcHJv YWN0aXZlIENWIGdhcCBmb3IgUFcuPC9mb250Pg0KPGxpPjxmb250IHNpemU9Mz5TZWN0aW9uIDcu MSBJJ2QgcHJvcG9zZSB0byBkZWZpbmUgJ0MnIGJpdCB0byBpbmRpY2F0ZQ0Kc3VwcG9ydCBvZiBD Qy9DVi9SREkgaW4gYWRkaXRpb24gdG8gYml0cyBMLCBELCBhbmQgRiBiZWNhdXNlIHN1cHBvcnQg b2YNClZDQ1YgQkZEIG5vdCBuZWNlc3NhcmlseSBlcXVhdGVzIHRvIHN1cHBvcnQgb2YgaWV0Zi1t cGxzLXRwLWNjLWN2LXJkaS48L2ZvbnQ+PC91bD48Zm9udCBzaXplPTM+UmVnYXJkcyw8YnI+DQpH cmVnPC9mb250Pg0KPGJyPg0K --=_alternative 002BA94248257857_=-- From alessandro.dalessandro@telecomitalia.it Fri Mar 18 07:22:24 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6226C3A692D for ; Fri, 18 Mar 2011 07:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 gA9mSTpwCr5E for ; Fri, 18 Mar 2011 07:22:23 -0700 (PDT) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by core3.amsl.com (Postfix) with ESMTP id 6107F3A6934 for ; Fri, 18 Mar 2011 07:21:19 -0700 (PDT) Received: from grfhub703rm001.griffon.local (10.19.3.10) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 18 Mar 2011 15:22:45 +0100 Received: from GRFMBX702RM001.griffon.local ([10.19.3.19]) by grfhub703rm001.griffon.local ([10.19.9.236]) with mapi; Fri, 18 Mar 2011 15:22:45 +0100 From: D'Alessandro Alessandro Gerardo To: "mpls@ietf.org" , Rui Costa Date: Fri, 18 Mar 2011 15:22:41 +0100 Thread-Topic: draft-tsb-mpls-tp-ach-ptn Thread-Index: AcvfnOeVV3ZPtvhwS+WvdnOPEqon7QF2jZow Message-ID: References: <52981DB05D3C5247A12D0AEE309F3CC201EB24B1CBBC@INOAVREX11.ptin.corpPT.com> In-Reply-To: <52981DB05D3C5247A12D0AEE309F3CC201EB24B1CBBC@INOAVREX11.ptin.corpPT.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 Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 14:22:24 -0000 Definitely it's worth to have a discussion on draft-tsb-mpls-tp-ach-ptn dur= ing the meeting in Prague. I support the request for a time slot allocation= . Best regards, Alessandro ------------------------------------------------------------------ Telecom Italia Alessandro D'Alessandro Transport & OPB Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rui= Costa Sent: venerd=EC 11 marzo 2011 4.32 To: mpls@ietf.org Subject: [mpls] draft-tsb-mpls-tp-ach-ptn Hello, The draft provided by the TSB draft-tsb-mpls-tp-ach-ptn requests the alloca= tion of an Associated Channel Type value that will allow ITU-T to develop O= AM tools required to address the needs identified by some ITU-T members. Al= location of this value will make more efficient use of resources of both IE= TF and ITU-T. The use of this associated channel type fully complies with t= he framework and architecture for MPLS-TP. The draft also describes the cases where networks that run the ITU defined = OAM tools are interconnected to networks that run the IETF defined OAM tool= s. In most cases it is a client/server relationship and no interworking is = required. If a LSP or PW originates in one domain and terminates in the oth= er domain then the IETF OAM tools must be used. This draft should be discussed in Prague. Best Regards, Rui _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From jdrake@juniper.net Fri Mar 18 08:10:55 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669343A692D for ; Fri, 18 Mar 2011 08:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 XTFV6KNgWmGE for ; Fri, 18 Mar 2011 08:10:54 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 1743A3A6916 for ; Fri, 18 Mar 2011 08:10:47 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTYN2Tga6Bug9F85xlCSOoITrN0q8n9/g@postini.com; Fri, 18 Mar 2011 08:12:23 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 18 Mar 2011 08:07:50 -0700 From: John E Drake To: D'Alessandro Alessandro Gerardo , "mpls@ietf.org" , Rui Costa Date: Fri, 18 Mar 2011 08:08:59 -0700 Thread-Topic: draft-tsb-mpls-tp-ach-ptn Thread-Index: AcvfnOeVV3ZPtvhwS+WvdnOPEqon7QF2jZowAAGaJ4A= Message-ID: <5E893DB832F57341992548CDBB33316399F1DA7062@EMBX01-HQ.jnpr.net> References: <52981DB05D3C5247A12D0AEE309F3CC201EB24B1CBBC@INOAVREX11.ptin.corpPT.com> In-Reply-To: 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 Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 15:10:55 -0000 What is the rush? The ITU document for which this code point has been requ= ested has just started a long and arduous approval process from which it ma= y never emerge. Wouldn't it make more sense to delay discussion of this dr= aft until the fate of the ITU document is more certain? I.e., why allocate a code point to an ITU document that may never get appro= ved? Sent from my iPhone > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > D'Alessandro Alessandro Gerardo > Sent: Friday, March 18, 2011 7:23 AM > To: mpls@ietf.org; Rui Costa > Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn >=20 > Definitely it's worth to have a discussion on draft-tsb-mpls-tp-ach-ptn > during the meeting in Prague. I support the request for a time slot > allocation. >=20 > Best regards, > Alessandro >=20 > ------------------------------------------------------------------ > Telecom Italia > Alessandro D'Alessandro > Transport & OPB Innovation > Via Reiss Romoli, 274 - 10148 Torino > phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07 >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rui Costa > Sent: venerd=EC 11 marzo 2011 4.32 > To: mpls@ietf.org > Subject: [mpls] draft-tsb-mpls-tp-ach-ptn >=20 > Hello, >=20 > The draft provided by the TSB draft-tsb-mpls-tp-ach-ptn requests the > allocation of an Associated Channel Type value that will allow ITU-T to > develop OAM tools required to address the needs identified by some ITU- > T members. Allocation of this value will make more efficient use of > resources of both IETF and ITU-T. The use of this associated channel > type fully complies with the framework and architecture for MPLS-TP. >=20 > The draft also describes the cases where networks that run the ITU > defined OAM tools are interconnected to networks that run the IETF > defined OAM tools. In most cases it is a client/server relationship and > no interworking is required. If a LSP or PW originates in one domain > and terminates in the other domain then the IETF OAM tools must be > used. >=20 > This draft should be discussed in Prague. >=20 > Best Regards, > Rui >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. > Dissemination, copying, printing or use by anybody else is > unauthorised. If you are not the intended recipient, please delete this > message and any attachments and advise the sender by return e-mail, > Thanks. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From wwwrun@core3.amsl.com Fri Mar 18 09:04:41 2011 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 294EE3A691B; Fri, 18 Mar 2011 09:04:40 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: rcallon@juniper.net,swallow@cisco.com,loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110318160441.294EE3A691B@core3.amsl.com> Date: Fri, 18 Mar 2011 09:04:41 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, Steve.Trowbridge@alcatel-lucent.com, yoichi.maeda@ttc.or.jp, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "LS298 - Response to request for early review on two MPLS WG documents [Ref #048.02]" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:04:41 -0000 Title: LS298 - Response to request for early review on two MPLS WG documents [Ref #048.02] Submission Date: 2011-03-18 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1037 Please reply by 2011-06-01 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(rcallon@juniper.net,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com mpls@ietf.org yoichi.maeda@ttc.or.jp Steve.Trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: koike.yoshinori@lab.ntt.co.jp Kam.Lam@alcatel-lucent.com Purpose: For action Body: Thank you for your liaison statement (ref #048.01) requesting early review on two MPLS working group documents: �{ "Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview" (draft-ietf-mpls-tp-mib-management-overview-02.txt) �{ "A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations" (draft-ietf-mpls-tp-rosetta-stone-03) Due to logistic reasons, we could not respond in time by the requested 28 February 2011 deadline. However, comments from the ITU-T experts have been collected based on their review on the mib-management-overview-03 and the rosetta-stone-03 drafts. Attached are the marked up version of the drafts, which include the comments. Attach: Marked-up draft-ietf-mpls-tp-mib-management-overview-03. Marked-up draft-ietf-mpls-tp-rosetta-stone-03. Attachment(s): LS298 - Response to request for early review on two MPLS WG documents [Ref #048.02] - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1215.pdf) Marked-up draft-ietf-mpls-tp-mib-management-overview-03 - pdf (https://datatracker.ietf.org/documents/LIAISON/file1216.pdf) Marked-up draft-ietf-mpls-tp-rosetta-stone-03 - pdf (https://datatracker.ietf.org/documents/LIAISON/file1217.pdf) From tnadeau@lucidvision.com Fri Mar 18 09:21:10 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199033A69E1 for ; Fri, 18 Mar 2011 09:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 D5X0fJ2oj-jZ for ; Fri, 18 Mar 2011 09:21:09 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 1A6B03A6995 for ; Fri, 18 Mar 2011 09:21:07 -0700 (PDT) Received: from [10.66.110.196] (mobile-166-137-136-251.mycingular.net [166.137.136.251]) by lucidvision.com (Postfix) with ESMTP id 9D1081A80EB7; Fri, 18 Mar 2011 12:22:34 -0400 (EDT) References: <52981DB05D3C5247A12D0AEE309F3CC201EB24B1CBBC@INOAVREX11.ptin.corpPT.com> <5E893DB832F57341992548CDBB33316399F1DA7062@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB33316399F1DA7062@EMBX01-HQ.jnpr.net> Mime-Version: 1.0 (iPhone Mail 8F190) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Message-Id: <5515E8D7-250C-4731-9372-CF775F3FB790@lucidvision.com> X-Mailer: iPhone Mail (8F190) From: Thomas Nadeau Date: Fri, 18 Mar 2011 12:22:27 -0400 To: John E Drake Cc: "mpls@ietf.org" , Rui Costa Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:21:10 -0000 I agree. Tom On Mar 18, 2011, at 11:08 AM, John E Drake wrote: > What is the rush? The ITU document for which this code point has been req= uested has just started a long and arduous approval process from which it ma= y never emerge. Wouldn't it make more sense to delay discussion of this dra= ft until the fate of the ITU document is more certain? >=20 > I.e., why allocate a code point to an ITU document that may never get appr= oved? >=20 > Sent from my iPhone >=20 >=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> D'Alessandro Alessandro Gerardo >> Sent: Friday, March 18, 2011 7:23 AM >> To: mpls@ietf.org; Rui Costa >> Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn >>=20 >> Definitely it's worth to have a discussion on draft-tsb-mpls-tp-ach-ptn >> during the meeting in Prague. I support the request for a time slot >> allocation. >>=20 >> Best regards, >> Alessandro >>=20 >> ------------------------------------------------------------------ >> Telecom Italia >> Alessandro D'Alessandro >> Transport & OPB Innovation >> Via Reiss Romoli, 274 - 10148 Torino >> phone: +39 011 228 5887 >> mobile: +39 335 766 9607 >> fax: +39 06 418 639 07 >>=20 >>=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Rui Costa >> Sent: venerd=A8=AC 11 marzo 2011 4.32 >> To: mpls@ietf.org >> Subject: [mpls] draft-tsb-mpls-tp-ach-ptn >>=20 >> Hello, >>=20 >> The draft provided by the TSB draft-tsb-mpls-tp-ach-ptn requests the >> allocation of an Associated Channel Type value that will allow ITU-T to >> develop OAM tools required to address the needs identified by some ITU- >> T members. Allocation of this value will make more efficient use of >> resources of both IETF and ITU-T. The use of this associated channel >> type fully complies with the framework and architecture for MPLS-TP. >>=20 >> The draft also describes the cases where networks that run the ITU >> defined OAM tools are interconnected to networks that run the IETF >> defined OAM tools. In most cases it is a client/server relationship and >> no interworking is required. If a LSP or PW originates in one domain >> and terminates in the other domain then the IETF OAM tools must be >> used. >>=20 >> This draft should be discussed in Prague. >>=20 >> Best Regards, >> Rui >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >> persone indicate. La diffusione, copia o qualsiasi altra azione >> derivante dalla conoscenza di queste informazioni sono rigorosamente >> vietate. Qualora abbiate ricevuto questo documento per errore siete >> cortesemente pregati di darne immediata comunicazione al mittente e di >> provvedere alla sua distruzione, Grazie. >>=20 >> This e-mail and any attachments is confidential and may contain >> privileged information intended for the addressee(s) only. >> Dissemination, copying, printing or use by anybody else is >> unauthorised. If you are not the intended recipient, please delete this >> message and any attachments and advise the sender by return e-mail, >> Thanks. >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From loa@pi.nu Fri Mar 18 10:46:25 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73AD03A69AC for ; Fri, 18 Mar 2011 10:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.37 X-Spam-Level: X-Spam-Status: No, score=-102.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, 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 KCUZ1VhDEOkC for ; Fri, 18 Mar 2011 10:46:24 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 949273A698F for ; Fri, 18 Mar 2011 10:46:24 -0700 (PDT) Received: from pi.nu (localhost [127.0.0.1]) by mail.pi.nu (Postfix) with ESMTP id 492942A8002; Fri, 18 Mar 2011 18:47:52 +0100 (CET) Received: from 129.192.170.250 (SquirrelMail authenticated user loa@pi.nu) by pi.nu with HTTP; Fri, 18 Mar 2011 18:47:53 +0100 Message-ID: In-Reply-To: <4D0B5321.2050508@pi.nu> References: <4D0B5321.2050508@pi.nu> Date: Fri, 18 Mar 2011 18:47:53 +0100 From: loa@pi.nu To: "Loa Andersson" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Ross Callon , "mpls@ietf.org" Subject: Re: [mpls] poll on draft-boutros-mpls-lsp-ping-ttl-tlv-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 17:46:25 -0000 Working Group, hmmmmm.... this poll has ended; we have a new working group document. Could the authors please publish draft-ietf-mpls-lsp-ping-ttl-tlv-00 according to our normal procedures. /Loa PS. It is kind of obvious that this poll had ended, it actually fell between the chairs (no pun intended) when I took an extended period off over the holiday season. I'm sorry about that. If anyone is aware of any other things that got dropped and has not been picked up, please let me know. > All, > > this is to start a "two week" working group poll on making > draft-boutros-mpls-lsp-ping-ttl-tlv-02 > an mpls wg document. > > Please send your comments to the mpls@ietf.org mailing list. > > Since this is across the holidays the poll ends on January 6th. > > /Loa > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From gregimirsky@gmail.com Fri Mar 18 13:59:47 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B2C03A6A3E for ; Fri, 18 Mar 2011 13:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.723 X-Spam-Level: X-Spam-Status: No, score=-2.723 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 c6HTPywYVOrZ for ; Fri, 18 Mar 2011 13:59:46 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id ACE6E3A69B6 for ; Fri, 18 Mar 2011 13:59:45 -0700 (PDT) Received: by vxg33 with SMTP id 33so4594037vxg.31 for ; Fri, 18 Mar 2011 14:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=2Du63FRvQ1Am1tXAIoK6WHy5LtDid0Ad09AbPYL68QE=; b=JodWhWslpNPasgK7chsi/retpYt/Y3eLnQZ8IP2wX6M/MLFu6tsN+kXEfgoDIR9fBt 7KlZxy8PXIC17b1s8aE8dpZIA6X9Vd2AZekHUIO9stC8WRLZPIFR5GSdu7ra9T25uSOH HoEMMZDYU2Uah0xbfXbNiQJyF+B1WNdrtMEyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=xxF8qJ84dm1/qjYvKbLgGt6zPs5AA9clCPgu9QPporhEddrD7/W9kF6NBU1xF0r+CC aUV5YZWYyWpPRLyhKnjU998US3B9AIkpfEBmWppjkOM/TBF/XDyOBpgFxBp2m3u+CLHl WoT6WGAaNPPlx0i6b7zM/w5REZ1QXx95w0AiM= MIME-Version: 1.0 Received: by 10.52.100.37 with SMTP id ev5mr2307122vdb.87.1300482075078; Fri, 18 Mar 2011 14:01:15 -0700 (PDT) Received: by 10.52.168.6 with HTTP; Fri, 18 Mar 2011 14:01:15 -0700 (PDT) Date: Fri, 18 Mar 2011 14:01:15 -0700 Message-ID: From: Greg Mirsky To: Elisa Bellagamba , Loa Andersson , pontus.skoldstrom@acreo.se, David Ward , John E Drake , mpls@ietf.org Content-Type: multipart/alternative; boundary=bcaec50163b31f315f049ec81446 Subject: [mpls] Comments on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 20:59:47 -0000 --bcaec50163b31f315f049ec81446 Content-Type: text/plain; charset=ISO-8859-1 Dear Editors, Authors, and All, please kindly consider my comments to the document: - perhaps second para on Introduction can be re-worded as Because the Transport Profile of MPLS, by definition [RFC5654], must be capable of operating without a control plane, there are two options for *configuring and controlling *in-band OAM: by using an NMS or by using LSP Ping. - it might be useful to mention in the Introduction the obvious dependency when using LSP Ping to configure, enable, and control in-band MPLS OAM. Proactive OAM cannot be configured, enabled before the LSP itself is operational. So, we configure OAM on implicitly specified LSP. I think that it might be useful to configure OAM for explicitly specified LSP as well. - last sentence of 3rd para in the Introduction might be edited to reflect the scope of draft-ietf-mpls-tp-cc-cv-rdi to BFD can be used to track the liveliness and detect data plane failures of MPLS-TP point-to-point *bi-directional* and might also be extended to p2mp *and p2p uni-directional *connections. - first sentence in 5th para in the Introduction might be edited to reflect that pro-active OAM tool set is not limited by CC/CV/RDI mechanism that in MPLS-TP is based on BFD. PM (LM/DM), and FMS as well are pro-active or could be used as pro-active but in MPLS-TP OAM they don't use BFD as their principle of operation. - Section 3.2 As I understand, the head-end MEP indicates set of OAM functions it expects remote MEP to support. If not all functions can be supported, how the set can be negotiated? Is it expected the the tail-end MEP includes OAM Functions TLV in LSP Echo Reply with its set of supported functions? If sets are not matching but have an overlap, should Return Code be set to 0 or new proposed "MPLS OAM Unsupported Functionality"? In the latter case, how to identify which of MPLS OAM functions is not supported? - Section 3.2.1 If Symmetric session cannot be supported, then how that will be indicated? Note that Section 3.1 has forward reference "Section 3.3.1 includes a detailed explanation of such configuration" but the Section 3.3.1 doesn't exist in the current text. Though there's explanation of operation with S-bit in Section 3.2.1.2. One option - use LSP Echo reply to negotiate timer increase. Any other options? - Sections 3.2.2 and 3.2.3 LM and DM might be run not only between MEPs but between MEP and MIP (as suggested in Section 2.7.4 Intermediate Nodes in draft-ietf-mpls-loss-delay-01). Then there's possible scenario when addressee of OAM configuration by LSP Echo request is not only MEP but a MIP on the given LSP. Hence there's need, in my opinion, to have MIP-ID sub-TLV. Such sub-TLV can be used to configure MPLS OAM on a MIP. (Discussion of nodal, in- or out- MIP addressing is in draft-farrel-mpls-tp-mip-mep-map-03). - Section 3.2.3 I support inclusion of Delay Measurement Timestamp Format indication/negotiation in the MPLS OAM PM Delay sub-TLV - Section 4 OAM Configuration Errors doesn't mention referred in Section 3.2.1 "OAM Problem/Unsupported OAM Version" error. Regards, Greg --bcaec50163b31f315f049ec81446 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Editors, Authors, and All,
    please kindly consider my comments to th= e document:
    • perhaps second para on Introduction can be re-worded= as
    Because the Transport Profile of MPLS, by definition [RFC5654]= , must be capable of operating without a control plane, there are two opt= ions for configuring and controlling in-band OAM: by using an NMS or= by using LSP Ping.
    • it might be useful to mention in the Introduction the obvious depen= dency when using LSP Ping to configure, enable, and control in-band MPLS OA= M. Proactive OAM cannot be configured, enabled before the LSP itself is ope= rational. So, we configure OAM on implicitly specified LSP. I think that it= might be useful to configure OAM for explicitly specified LSP as well.
    • last sentence of 3rd para in the Introduction might be edited to reflec= t the scope of draft-ietf-mpls-tp-cc-cv-rdi to
    BFD can be used to = track the liveliness and detect data plane failures of MPLS-TP point-to-poi= nt bi-directional and might also be extended to p2mp and p2p un= i-directional connections.
    • first sentence in 5th para in the Introduction might be edited to r= eflect that pro-active OAM tool set is not limited by CC/CV/RDI mechanism t= hat in MPLS-TP is based on BFD. PM (LM/DM), and FMS as well are pro-active = or could be used as pro-active but in MPLS-TP OAM they don't use BFD as= their principle of operation.
    • Section 3.2 As I understand, the head-end MEP indicates set of OAM func= tions it expects remote MEP to support. If not all functions can be support= ed, how the set can be negotiated? Is it expected the the tail-end MEP incl= udes OAM Functions TLV in LSP Echo Reply with its set of supported function= s? If sets are not matching but have an overlap, should Return Code be set = to 0 or new proposed "MPLS OAM Unsupported Functionality"? In the= latter case, how to identify which of MPLS OAM functions is not supported?=
    • Section 3.2.1 If Symmetric session cannot be supported, then how that w= ill be indicated? Note that Section 3.1 has forward reference "Section= 3.3.1 includes a detailed explanation of such configuration" but the = Section 3.3.1 doesn't exist in the current text. Though there's exp= lanation of operation with S-bit in Section 3.2.1.2. One option - use LSP E= cho reply to negotiate timer increase. Any other options?
    • Sections 3.2.2 and 3.2.3 LM and DM might be run not only between MEPs b= ut between MEP and MIP (as suggested in Section 2.7.4 Intermediate Nodes in= draft-ietf-mpls-loss-delay-01). Then there's possible scenario when ad= dressee of OAM configuration by LSP Echo request is not only MEP but a MIP = on the given LSP. Hence there's need, in my opinion, to have MIP-ID sub= -TLV. Such sub-TLV can be used to configure MPLS OAM on a MIP. (Discussion = of nodal, in- or out- MIP addressing is in draft-farrel-mpls-tp-mip-mep-map= -03).
    • Section 3.2.3 I support inclusion of Delay Measurement Timestamp Format= indication/negotiation in the MPLS OAM PM Delay sub-TLV
    • Section 4 OAM Configuration Errors doesn't mention referred in Sect= ion 3.2.1 "OAM Problem/Unsupported OAM Version" error.
      • Regards,
      Greg
      --bcaec50163b31f315f049ec81446-- From yaacov.weingarten@nsn.com Sun Mar 20 10:41:37 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2269C3A6AAB; Sun, 20 Mar 2011 10:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Xkh2B1cjl-cZ; Sun, 20 Mar 2011 10:41:36 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 7E7F63A695F; Sun, 20 Mar 2011 10:41:35 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p2KHh6DH015145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 20 Mar 2011 18:43:06 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p2KHh3RW021860; Sun, 20 Mar 2011 18:43:04 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 Mar 2011 18:42:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CBE726.2A1E6FA0" Date: Sun, 20 Mar 2011 18:42:16 +0100 Message-ID: In-Reply-To: <716209EC190CA740BA799AC4ACCBFB5D1852AD8AFE@IXCAEXCH07.ixiacom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Query on draft-ietf-mpls-tp-linear-protection-06.txt Thread-Index: AcvlPOyTCSA0TXCZTEmZ4FL/Q5bxdwB6Odqw References: <716209EC190CA740BA799AC4ACCBFB5D1852AD8AFE@IXCAEXCH07.ixiacom.com> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: "ext Apratim Mukherjee" , , X-OriginalArrivalTime: 20 Mar 2011 17:42:21.0666 (UTC) FILETIME=[2A6B9C20:01CBE726] Subject: Re: [mpls] [mpls-tp] Query on draft-ietf-mpls-tp-linear-protection-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 17:41:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE726.2A1E6FA0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, Since I am not sure that this attachment was delivered to the mailing list the first time it was sent I am resending. The attachment contains the LC comments and their resolution after discussion by the editors of the Linear Protection draft. Best regards, Yaacov ------_=_NextPart_001_01CBE726.2A1E6FA0 Content-Type: application/octet-stream; name="LastCallCommentsResolved.xlsx" Content-Transfer-Encoding: base64 Content-Description: LastCallCommentsResolved.xlsx Content-Disposition: attachment; filename="LastCallCommentsResolved.xlsx" UEsDBBQABgAIAAAAIQCnlfmZhAEAABQGAAATAN0BW0NvbnRlbnRfVHlwZXNdLnhtbCCi2QEooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAMxUyW7CMBC9V+o/RL5WxEClqqoSOHQ5tkjQDzDxQCwS2/IMFP6+k1BQqdJI NBx6SZTFb5tnJ+NtWUQbCGicTcUg7osIbOa0sctUvM9eevciQlJWq8JZSMUOUIxH11fJbOcBI15t MRU5kX+QErMcSoWx82D5y8KFUhE/hqX0KlupJchhv38nM2cJLPWowhCj5AkWal1Q9Lzl13slc2NF 9Lj/r6JKhfK+MJkiFio3Vv8g6bnFwmSgXbYuGTpGH0BpzAGoLGIfDDOGKRCxMRRylLyx6WA0RBMV 6FWVzCC3hSR2APvrIGYPnUTUYDcVyu+ESLsCsDPVqd896IG5Id4ABZ5n7WuAMa+sZ4C58djC0J5d eyYfLqzmzq0unUrVhrhUxh50N5WAKzQJzqPkwnUWAFWjNeieZ0gIZOCYWRM3F7DyXtcWZX0bdtZw Wo0jflsGDTpu/4mO7rvyb3lgrgLoKfFJsrz4dv2O3TaXYzczF+D8gRz2cLW6oZGyPtNHnwAAAP// AwBQSwMEFAAGAAgAAAAhALVVMCP1AAAATAIAAAsAzgFfcmVscy8ucmVscyCiygEooAACAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySz07DMAzG 70i8Q+T76m5ICKGlu0xIuyFUHsAk7h+1jaMkQPf2hAOCSmPb0fbnzz9b3u7maVQfHGIvTsO6KEGx M2J712p4rZ9WD6BiImdpFMcajhxhV93ebF94pJSbYtf7qLKLixq6lPwjYjQdTxQL8exypZEwUcph aNGTGahl3JTlPYa/HlAtPNXBaggHeweqPvo8+bK3NE1veC/mfWKXToxAnhM7y3blQ2YLqc/bqJpC y0mDFfOc0xHJ+yJjA54m2lxP9P+2OHEiS4nQSODzPN+Kc0Dr64Eun2ip+L3OPOKnhOFNZPhhwcUP VF8AAAD//wMAUEsDBBQABgAIAAAAIQDeCf0oAgEAANQDAAAaAAgBeGwvX3JlbHMvd29ya2Jvb2su eG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8k89qwzAMxu+DvYPR fXGSbmWUOr2MQa9b9wAmUeLQxDaW9idvP5NDukDJLqEXgyT8fT/Qp/3hp+/EFwZqnVWQJSkItKWr Wtso+Di9PjyDINa20p2zqGBAgkNxf7d/w05z/ESm9SSiiiUFhtnvpKTSYK8pcR5tnNQu9JpjGRrp dXnWDco8Tbcy/NWAYqYpjpWCcKw2IE6Dj87/a7u6bkt8ceVnj5avWMhvF85kEDmK6tAgK5haJMfJ JonEIK/D5DeGyZdgshvDZEsw2zVhyOiA1TuHmEK6rGrWXoJ5WhWGhy6GfgoMjfWS/eOa9hxPCS/u YynHd9qHnN1i8QsAAP//AwBQSwMEFAAGAAgAAAAhAFJHLkRdAQAAcAIAAA8AAAB4bC93b3JrYm9v ay54bWyMUstOwzAQvCPxD5bvNKn7gFZNKiFA9IKQKO3ZxJvGqmNHtkPav2ftqqEIDpx2xzsZz46z WB5qRT7BOml0RoeDlBLQhRFS7zL6vn66uaPEea4FV0ZDRo/g6DK/vlp0xu4/jNkTFNAuo5X3zTxJ XFFBzd3ANKBxUhpbc4/Q7hLXWODCVQC+VglL02lSc6npSWFu/6NhylIW8GCKtgbtTyIWFPdo31Wy cTRflFLB5rQR4U3zwmv0fVCUKO78o5AeREbHCE0HPw5s29y3UoXpJJ3SJO+XfLVEQMlb5de43lkd 82JjxiIzRLGR0LnvjwIkh63UwnQZHU0x2uMZBdDFyVYKX6HSZHzXnz2D3FU+o7N0lgYbyYV6zA9v iZXouNxbyHSIDxXqCv1jb+cSG7sSw6Dwi80u2Nj3bPYne3TBxr5nj6K7KI6WCq4KTCqUaIJNbtkk Ms4/S/4FAAD//wMAUEsDBBQABgAIAAAAIQDppiW4ggYAAFMbAAATAAAAeGwvdGhlbWUvdGhlbWUx LnhtbOxZT2/bNhS/D9h3IHRvbSe2Gwd1itixm61NG8Ruhx5pmZZYU6JA0kl9G9rjgAHDumGXAbvt MGwr0AK7dJ8mW4etA/oV9khKshjLS9IGG9bVh0Qif3z/3+MjdfXag4ihQyIk5XHbq12ueojEPh/T OGh7d4b9SxsekgrHY8x4TNrenEjv2tb7713FmyokEUGwPpabuO2FSiWblYr0YRjLyzwhMcxNuIiw glcRVMYCHwHdiFXWqtVmJcI09lCMIyB7ezKhPkFDTdLbyoj3GLzGSuoBn4mBJk2cFQY7ntY0Qs5l lwl0iFnbAz5jfjQkD5SHGJYKJtpe1fy8ytbVCt5MFzG1Ym1hXd/80nXpgvF0zfAUwShnWuvXW1d2 cvoGwNQyrtfrdXu1nJ4BYN8HTa0sRZr1/katk9EsgOzjMu1utVGtu/gC/fUlmVudTqfRSmWxRA3I PtaX8BvVZn17zcEbkMU3lvD1zna323TwBmTxzSV8/0qrWXfxBhQyGk+X0Nqh/X5KPYdMONsthW8A fKOawhcoiIY8ujSLCY/VqliL8H0u+gDQQIYVjZGaJ2SCfYjiLo5GgmLNAG8SXJixQ75cGtK8kPQF TVTb+zDBkBELeq+ef//q+VP06vmT44fPjh/+dPzo0fHDHy0tZ+EujoPiwpfffvbn1x+jP55+8/Lx F+V4WcT/+sMnv/z8eTkQMmgh0Ysvn/z27MmLrz79/bvHJfBtgUdF+JBGRKJb5Agd8Ah0M4ZxJScj cb4VwxBTZwUOgXYJ6Z4KHeCtOWZluA5xjXdXQPEoA16f3XdkHYRipmgJ5xth5AD3OGcdLkoNcEPz Klh4OIuDcuZiVsQdYHxYxruLY8e1vVkCVTMLSsf23ZA4Yu4zHCsckJgopOf4lJAS7e5R6th1j/qC Sz5R6B5FHUxLTTKkIyeQFot2aQR+mZfpDK52bLN3F3U4K9N6hxy6SEgIzEqEHxLmmPE6nikclZEc 4ogVDX4Tq7BMyMFc+EVcTyrwdEAYR70xkbJszW0B+hacfgNDvSp1+x6bRy5SKDoto3kTc15E7vBp N8RRUoYd0DgsYj+QUwhRjPa5KoPvcTdD9Dv4Accr3X2XEsfdpxeCOzRwRFoEiJ6ZCe1LKNRO/Y1o /HfFmFGoxjYG3hXjtrcNW1NZSuyeKMGrcP/BwruDZ/E+gVhf3nje1d13ddd76+vuqlw+a7VdFFio vbp5sH2x6ZKjlU3yhDI2UHNGbkrTJ0vYLMZ9GNTrzAGR5IemJITHtLg7uEBgswYJrj6iKhyEOIEe u+ZpIoFMSQcSJVzC2c4Ml9LWeOjTlT0ZNvSZwdYDidUeH9vhdT2cHQ1yMmbLCcz5M2O0rgmcldn6 lZQoqP06zGpaqDNzqxnRTKlzuOUqgw+XVYPB3JrQhSDoXcDKTTiia9ZwNsGMjLXd7QacucV44SJd JEM8JqmPtN7LPqoZJ2WxYi4DIHZKfKTPeadYrcCtpcm+AbezOKnIrr6CXea9N/FSFsELL+m8PZGO LC4mJ4vRUdtrNdYaHvJx0vYmcKyFxygBr0vd+GEWwN2Qr4QN+1OT2WT5wputTDE3CWpwU2HtvqSw UwcSIdUOlqENDTOVhgCLNScr/1oDzHpRCthIfw0p1jcgGP41KcCOrmvJZEJ8VXR2YUTbzr6mpZTP FBGDcHyERmwmDjC4X4cq6DOmEm4nTEXQL3CVpq1tptzinCZd8QLL4Ow4ZkmI03KrUzTLZAs3eZzL YN4K4oFupbIb5c6vikn5C1KlGMb/M1X0fgLXBetj7QEfbnIFRjpf2x4XKuRQhZKQ+n0BjYOpHRAt cB0L0xBUcJ9s/gtyqP/bnLM0TFrDqU8d0AAJCvuRCgUh+1CWTPSdQqyW7l2WJEsJmYgqiCsTK/aI HBI21DWwqfd2D4UQ6qaapGXA4E7Gn/ueZtAo0E1OMd+cGpLvvTYH/unOxyYzKOXWYdPQZPbPRSzZ Ve16szzbe4uK6IlFm1XPsgKYFbaCVpr2rynCObdaW7GWNF5rZMKBF5c1hsG8IUrg0gfpP7D/UeEz +3FCb6hDfgC1FcG3Bk0Mwgai+pJtPJAukHZwBI2THbTBpElZ06atk7ZatllfcKeb8z1hbC3ZWfx9 TmPnzZnLzsnFizR2amHH1nZspanBsydTFIYm2UHGOMZ81Sp+eOKj++DoHbjinzElTTDBZyWBofUc mDyA5LcczdKtvwAAAP//AwBQSwMEFAAGAAgAAAAhADttMkvBAAAAQgEAACMAAAB4bC93b3Jrc2hl ZXRzL19yZWxzL3NoZWV0MS54bWwucmVsc4SPwYrCMBRF9wP+Q3h7k9aFDENTNyK4VecDYvraBtuX kPcU/XuzHGXA5eVwz+U2m/s8qRtmDpEs1LoCheRjF2iw8HvaLb9BsTjq3BQJLTyQYdMuvpoDTk5K iceQWBULsYVRJP0Yw37E2bGOCamQPubZSYl5MMn5ixvQrKpqbfJfB7QvTrXvLOR9V4M6PVJZ/uyO fR88bqO/zkjyz4RJOZBgPqJIOchF7fKAYkHrd/aea30OBKZtzMvz9gkAAP//AwBQSwMEFAAGAAgA AAAhALhKSy0TAQAAtwEAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0Mi54bWyMUMFKxDAQvQv+Q5i7 TVdZlaXtIiyLHgQR9Z5tJ23YJBOSWVf/3rRlF8GLt3l5b17mvWr95az4xJgM+RoWRQkCfUud8X0N 72/bq3sQiZXvlCWPNXxjgnVzeVEdKe7TgMgiO/hUw8AcVlKmdkCnUkEBfWY0Rac4w9jLFCKqblpy Vl6X5a10yniYHVbxPx6ktWlxQ+3BoefZJKJVnO9PgwkJmqozmRsDiYi6hocFyKaavv0weEy/ZjGm 2BHtR+Kpq6EcpfKPdjuleImiQ60Oll/p+IimHzhXtjy7bxSrvB5Uj88q9sYnYVFnTVncgYizfpqZ wvS6BLEjZnInNOSCMBdRFjcgNBGfwHjWufLmBwAA//8DAFBLAwQUAAYACAAAACEAuEpLLRMBAAC3 AQAAGAAAAHhsL3dvcmtzaGVldHMvc2hlZXQzLnhtbIxQwUrEMBC9C/5DmLtNV1mVpe0iLIseBBH1 nm0nbdgkE5JZV//etGUXwYu3eXlvXua9av3lrPjEmAz5GhZFCQJ9S53xfQ3vb9urexCJle+UJY81 fGOCdXN5UR0p7tOAyCI7+FTDwBxWUqZ2QKdSQQF9ZjRFpzjD2MsUIqpuWnJWXpflrXTKeJgdVvE/ HqS1aXFD7cGh59kkolWc70+DCQmaqjOZGwOJiLqGhwXIppq+/TB4TL9mMabYEe1H4qmroRyl8o92 O6V4iaJDrQ6WX+n4iKYfOFe2PLtvFKu8HlSPzyr2xidhUWdNWdyBiLN+mpnC9LoEsSNmcic05IIw F1EWNyA0EZ/AeNa58uYHAAD//wMAUEsDBBQABgAIAAAAIQBWUf5afxAAABtXAAAYAAAAeGwvd29y a3NoZWV0cy9zaGVldDEueG1slFxNc+O4Eb2nKv9BpXtkAhRFaWo8W0uRW9lDqlLZTXLW2vJYtbbl SJqZzb8PgG4R/QVxMgfbIz428PAajSfw4+MPf7y+zL7uT+fD8e1+7hbVfLZ/ezg+Ht4+38//+etP f1nPZ+fL7u1x93J829/P/7s/z3/49Oc/ffx2PP1+ft7vL7MQ4e18P3++XN4/3N2dH573r7vz4vi+ fwtHno6n190l/Pf0+e78ftrvHtNJry93vqpWd6+7w9scInw4fU+M49PT4WHfHx++vO7fLhDktH/Z XUL/z8+H9/P808fHQzgWCc1O+6f7+Y/uw+Dqzfzu08fU9r8O+29n8vfssvvtl/3L/uGyfwxDMJ9F ar8dj79H4M/hoyrEPCdAjLl7uBy+7rf7l5f7+RDQ5/+kVsKfoYG7sQX697W1n9Jg/P00e9w/7b68 XP5x/PbX/eHz8yU028TTH44vARt+zl4PUY757HX3B/Tp8Hh5Dn8tF+umWa7WbTOfPXw5X46v/8Yj eD6c6fHM8PsbHq8XTVvVzocTz5f/vgQtb4eoMUT4jSFqr0KEgzd6scQQ4TeGWLqFXzeuWZFu3I4R OpnGIPzGGL5dLH3TrikVM8YdDGeSpN9ddp8+no7fZiHNomrvu5i07kMcjvt56CHwAIkSJMkS0v/y fHj4vTtGkUIiPMQAP8YI6azwaUy5r5+qj3dfg+YPiOg0wnHEFhCr0MA1hueIXiNqjkj5dz9nMep2 xNwFviPpkAqUdGTXBEGR36/Hd8ovgu/n4efYt+UYNY1AB4h4+rX3zq84ZguYoM2IaTii14g1Rwwa 4f1mxDCGoSHJcLUMDK+ixeO3SQHiNinAhJ8jKUG714jc4TR4g0a4dU4gRipkpiTl/HoR5s+VVkTc pgUITitnSerSFjCUlkD0GuFyn4GXhnifBWW8Qm8kL+9aolYE3KYFiNu0AENpOTnLDIiYqoOG+Dpz Z7zCXFS8VmvCKwJu8wLEbV6AYbzk3DIgsnwYkHXmzni1mpdb5oIYD3NWTlYMgNymBRhGS84uAyIy dQCIC+VznKPe5+4wXtHfkLUglUW3CMvrdXpFQGQWi7xbuIr9y4MFVRHAnKMgsAUM45jnSArTGxBZ QjTE+zwOjOJGU2R1MR7/boYAvs0QMJShz7MFGBoQMZaDhrh1nruMoQu29baKCZFJ5jigGx6+TQtB jJecdBZGNDYYGLfOU5Mzix5A5KdrapqgMc+JfqK1Dg8zao3Ipi2CKDW3kpqZIKkaguIvMvnyMHF2 cXXP7K5TzsGiD3POL0QTHR5mjJT3QBBl5PMYQxJamFwmEmYwMMW12oXWCJ1ZLCZspiXANQsNYvH8 5MvHodOmCmMwYqLE9BYmFwckBo2xOHUeaq5TXNizTomYX1ET4mDpL0oGhyckM+yDrIzYDuu1SObB wLh11pUzC12aYBYRNzSDwxPMAER7TfwDJqOByXKgZhrj1qW5FRd3oRlPRlj9i5LBYUZM1w3DQazU NLNAokwNzgCtc15z0eICL6g1bNF2YAGAm+hPhwdvMusRRCVzq5xEqIdhRtZ5ovFOxxVbdHq1ioUc v3qOWwGj9XCwyIdqONaDOqudutAhhpHRxVC7hVoI0GMgSrhWfHUcTwJxvnH9Fnw3Ln7hhG/aBl1Y 8VE0Xfavh/NoOFKw0nBsneEaSA8TqDdBIksGC7TO5Yhx9Zb/CNWsxDThrzWlVkzxMNNUarFFENXL yezoTVCeVZDFFqj0ddRbfsTF7zdlsld/knWrRRe6FFaufHkigbYIooxroVpvYJzADBZmnRcRrix3 KGnlc64h3+c8NSuGlnCYaUmMOjIDEGMm2PfYDsVoZjqOKzILkeT89Oybqo+ImKVZuKXwhB1iJuhB INr1Os8kmJMYiGI0PR2n6MV8NBOi/Lh2Qz1Lgkzxs4yLkGaLgWjf65xPyE+bG83PwBTlC0Mu+W3i TnVq7se0vzrFLYaYnHQAotyWwpb02BjDiOVlMDBuk7OJT7roBYR2zLp4MAu3MxMwE5lpuA6yY4XS GSBVUwzMJo8Tp2fYF+6m/dW+kJknEqpDDOcn6uoWQUwZ0fXewsiF38CUZ55hdAQ97WuanApp0DsP mAl62o8shUHqMRAbAjFMg4Ep0zN8DU9O7VN02QTMBDvtZZai9PTewIjSOhiY4qpQG04mXDu7lpV0 eKKsIOY2NwRRVZo8XWDeWRhZVhDDthuK0tWGeWmrW94lnTHFF/zNBF8AUb6OXMdAwhrUiNk6YI9Y oFIdraMdEHWUf09KiCl+YCom+AGIdqsRRaTHxhhGzNbBwLhNFp3V0TpEkvTIEpgOT3GLIeQSKKrD FgOxfotq3FsYEWcwMG6T9eXcDPtC5yE4BboAyu26rgYM103Ujy2CGDeB6S2MrDEGxm1yAnBuoUtE t7G2xI+5XqusPKwKNWA4JzHOWwRRTk5tt5ig8bpiam2wMKUvRnU0AGKu8VUvIQQ/UfI6xEzw015D 7kz0GIiOgdyXGQyMd3kwuWaGZ6H5qA1Lm9VH7QAzwQ1ArN+iRvS1gcndRuk0xm1yIM7NMCyUm3Yr mpvlVsQ82tbarawEprcwaq7pOOX1PPoDkZauam5uOwXuciJqwoCZEFObk1b4vB4bY4KL4joYGLfJ ijMxl4aBIYtCOswnoeKGGM5NCLVFEO13K2Zzb2FERRsMjNvkxjg3w7+Ii0HhkqzSLqc9TETEMH6t AG0RRPm5No95itSboNx5mIoWaJNzmjM0HIurPL3ctQSnQZc+2fkOMYyh2hRFEGXY5tUYCUJjFKO+ tRtx3CanMOcXIqnpKG7niBCRoUKcbgmYCX4ACj/H3eM2dwv5GRgh8oCN0Tie7Ltxfrdty1LbFq2d ZVtEn7YYiPapFXnXW5icdpib0BiNU+YWhltpx7YClxHBpSNXrFOLHWK4dKLrWwTRbpH7MlA6aIxh RHEdMA77duTJRODaTTqYJRgPOvXcSuUmgBhBed2ox0i0824lRB4sUMl+LeN6L9e5mAGlLfh0gtBK zI4OMYwKGb2kwxZBlAq5mI9aaTdCLkgmzGDE8eSKNZcqOgDBln+xW4JHgGspy0W1Yf/ESHeIniCq bQe59ohENUbXS40J9wKP1psTNexL7cJNpKGrRWWv9iXesTNN3TIyaj5qI0OuTSJ1jdHUNcZX2TUw 6o0wMqGwhLOBtLhLdVltbm1ipEj38zbdwjQ5IIgOIo3LhlMXLBDEkl4MWm9hZP01ML7KFokPiOF+ mnQTQjEVGnBD4efIheyVJN06xNzOfQRRvmR3FxLAwKivXAbGV9l0cL7Re8hJPsEX7Arl6+SWYdcA iBGWl2O2CKKE3VKo15sgUUQHA+R9SeLQnqRch1vjywLHE2IV/6653gCaMdepDaDwM+dM7i5KrTFq rmNjNI4nF3G51NGGCKnXQcVSiWvAtnwvbUAz2lLwHkPS7rqlWCcGA+Sr/D2fcwrt/V+cIp4vyE5+ Pe4aADEq0lxsEcSorFTuQiQOUrmrQd6X6rVhn1yb7rAvynj1U5C9Isu6xnBSOl0BRHmQPUVMV43R 6aoxvsrejktrmC2+19WA4aFOkXypxcILGKalclcYiNHLCYf0tLsiWz0JMxhxipcJmmhQxGwk+0Hp ME9UzQ08zgQ3bYTIrgZy0xgtnYEp+eQmOpAb3MCg3NYNMJybWPy3qZ37OdNNTUEIxDBqBmqMr3JZ Ymm54o7puq+cPp7QCzG3OSGI9jfcDj4aVxDMAuUFHpLRwhBfwklFCyMEC1dExityq3h8ih1gGDtV NTEQY6d260yQmI+DAfJVThBOL5oRSS88aHbrtrgVGJjr6idGt8PDjK2qKwhibIkTRy2hIQ4SVXow IvkqpzpnG0JJtrxwriKCy+nI2KV+dQhiDKWePYJY5+UO5WCAyp03TIrYm1tdfUn2TkbvDTuiljWM xHpPnAbqA5E4SKTDYETyVS4zXJ8wpFIfscG6ipBJgQDEBNIUAcR7n1dcpGiBcv1LoAH7RCN58mwW pxjXeTnh+A7rCqwAXQQMFQHEKYqObTES7ZhzeW4gRe081BJnBPLkmRLO0HAnrGJqbxJ8Gi/j3cow J3qKaePh5BbygJHoGHhX8JCruJILcdqW3rOWECL91JNWCJrQxnANpG6hNgZITTADU1zN4nIuCLKb Z1aw3rPc0/wAxPjJLzRbjETH3cm7jHoTlMXB6WV4EFeoIC33IPoRkAQQAsqbPDoE3SaIIE5Q5HFv guSCbYA8uZWYza7W8CM8RRNikqFhSZSEGIkzlBXSBIlCNFigkkVu46ovcpTf8psQkwzBPExoCCDO MFslmITYHAeJKjoYIE9us+YahlCSIbchbUQIhvLiUYcgxlBeztkiiHW+VZ2H5hioKI9hQ0QCGi6E PBWfBrVrDReiE9AwGOrOXowUn+obd4ycvONvuKJC3mdUkWMYUykQ39+P/lgK5MTU6BDEBFJOGEFs 7Ik/whSE5hiIOAyok0YkT5625ilo2BBymb41LIimZ1gQLaHhLpaiAPbYHKMnbyQdDJAnRoXTMzxI nZ7aLO7ptYYtIXfjYNYatkQZS4zE2BDHgYoa3kWu7FagYsoa1kWkLPgEvrSLWte1AOIpK0BbBHGC auUzbAmRC1MWQOwCaXFfqDXMi3gXQ4KIuqlFNOyLFlGbDkdMB4pogIgtRo4a5IkJZ3m7NuyLoJgg UxQRxGUUi/IWQUxGcsUTKJog6dAQxGQMb5MYPT3naDgYsr0X991VZRVd7xA0wQ8icX4yTTESA8l5 iBhGr5ila8O+8MU9IYSC8pmODkGMoSquCGKdXyqGhsdZKooa5Inv5wKG9uTq6Jt0T9t1z28dIYKi mocIYhTV8oggRpG8SwKTFJrjILEaD0YkT9Y0TtEwOeFWk7jCli4mrK+uJ76Gir74Zx1OIsM1DlH8 OA6RwvOlecRfl2SF52vdiL+uZwofa2721yMeSrHRn1i/DDyUNY0PNsLCp48tvhteD679SR+beD7B RjxksNGfmBy6/xvIGQPPtR/jl/Td2Pqmj83+2/puSvpuqL75jS/pYzM+1ZfgS/puqL4EX9I37LmT Ac0nwOdWj1xFJaZnXGu9zNGwr1loo6Syq6jMtI2Szq6iQtMzSkqHG3cLvSrNZVdRsWkbJbXDTl+h jdJ8dpUtOHxu62FL7qqi5umdKddJRHjgu1T0LHJxtRynHT2jqHl61YfVRlFz9sIP2kZR8/RuCquN oubx9geTR1Hz9CoFq42i5ullB9YZRc3T2wKsM0qzPJjXAo+i5um5dKMNfF7d0Dw92W2dUdQ8PVVt nVHUPD2obJ1R1Jw9ikyyZHz+WFWf9LCs1UZR8/RErHVGUfP0SKd1RlHz9JSkdUZR8/TkoXVGUfP0 PJ9xBj7nZ2jOHuojozs+uqdGlz0WR88oap6e3LJ6VdQ8PQ9lnVGc5+lhI+uMoubp+R3rjKLm6ckZ 64yi5ul5FOuMoubpYQ3rDKU5vCwV3sz5vvu8/9vu9Pnwdp697J/CFlm1CJ06wdtR09+X+IrK8FcY j9+Ol/Dm0+v/nsNbZffhrZzVIsjxdDxerv8Jyse4v+wvX95nx9MhvDE2vSj2fv5+PF1Ou8MltPDh 8Hg/P/38CO9vHV9r++l/AgAAAP//AwBQSwMEFAAGAAgAAAAhAAKwL94MMwAAyIwAABQAAAB4bC9z aGFyZWRTdHJpbmdzLnhtbMyd224c2ZWm7w34HaKzgDaFIZMiqUOVXCWBRYlTNHTgiKwRXIYxCGYG ybDy5IxMUewrv0NfDdANzFU/yDyKn2S+f629I3ZEJCVVVbsxsmFLmRH7sI7/Ouyd3z77OJ1kH4pl Vc5n3w32hvcHWTEbzcfl7Oq7wY/nxztfD7Jqlc/G+WQ+K74b3BbV4NnT3/7m26paZbw7q74bXK9W iye7u9Xoupjm1XC+KGZ8czlfTvMV/1xe7VaLZZGPq+uiWE0nu/v37z/aneblbJCN5uvZ6rvBwdff DLL1rPzrujjyT/YPvh48/bYqn367enpWjFYs79vd1dNvd/VR+Hi+Xo6K7qdH8+m0mK2KcXZefFx1 vz1dzhfzKp90P9db/Rl4euVzZ2erfFVkR/P5EtLkWk62dXp2dK870Pl1kY3no7XWkK2romKLs6qs Vvx7cput+HpVLKfZzXz5Hhpni3x1vZ1drFdZCdmTJ5fFaA5fbsMT9T9Xy3xWLebLVfcLJihXt9vZ hifjV4tmP5p32F38YTYuLstZadubX2bHeTlZL4uMv4oU89F8oicgSZWVVTYtq4o9DDM2zVN8Mp+x xzzT5kWhcpY9GO4PDyBVM/PqdlFkl2UxGd/L5sv4zINs623Bflflh/rb1XXeIsvoVk+LhB/yybrI LorVTVHMsov56hqpHWeLeTljaRPJWraaZ/ksyyc51D774fDlS57PKlambzTINJ/lV4UxqrqFQVPn w+qajfDf2XyVVevLy3JU8tLv9QqbzEUO/TUTMY0iKIeYfFlerZcuGRAG0UcdquzmuhxdZ9X1fD0Z awG2nmLcI/15FIy//+3f0LdV8fe//XtcRb5grsWy5FOjdYaGhZnGRTValhdIu1GGZY+X+eUKEWRu 7SBfsbGF7XkUhbewtQfBtsmG2Ql7vboqUOq1eNoIasK5s5uSTenbVA+6QvRj5SLelnxfuIk+OxTt wvwSxLBXjMRlsVyymTHchUslzByZZkqVbIu19M9gPjpU9Sh5/OY0CCn/F2eBSMxd5gknbON9Rrwo jbuITvFxMYH5ENOIvIhacT2fjHfml5fZqpwiB8gwwy6KUYmooH1sAQtq68+zcXlp/xZH3CjsSj9l osYuKzcmVsyZXa5nZufEdlaO7omtsLEoxn2JkfF9Ui3yEUYZwlXF8kMxeCoxGq2hIWIeZzQ9RRya VfrMGGg++6G1GwQBlQuKjNQuZbSCOruQVYFvB8O94V62tUCFsm/uoWq21mAAXh3+0RmO2a9kCCqJ 3EV+YSYQrTYluypm8GQU6MgzrYlenb482zk/zc7Wyw/lh/yinGDesuNlPi3E+GZ7W3FJD4bf3Buy oRsZEpNgI0xKikQRsQWTyx0UF0rPJNQ1vUSYcrqYmG3ANW5nk/J9kZ2c/7hznv334df3D/a0Iz32 QsKCKA6z7LAWAidvPVx1nU8mbptqmZKZhGIoFJYBLZ1eYD20P7Nat40s6AlUW5pQjdB77a8lfiwk GO2CQcPjEid7XKbbaO1mwcX0VrvNW0ag1mxppqzaMOvq9VmBTDPupMC+jIrJpKd5Egjtymx+9/XX hSuWryZ6yBk01KBfzOwgIoG7tRWp6g1IKTPso8EP6eH84i8SWdwKtHh4f4oiVKjpX9fl0hgM607c q3zpIrY1O34A0pu8A4yi6PIBfhmVOLifYeeO2d7D+zvMmVi8eq3bPPIf2L64ArEyEKY7RTkbs9zR qp4HmQjjbxo5yoG2u43waKlvXxy9efXqxevnL56zftNBoEpxma8nfA9iWuJVXV7kgZe4gtX1EqYD c5i2qthWhSd98+PL5/Jks3mGb70yTcNaHgwPptVQlpw/GJGqKNi20ZvJ/7JmOJ6amxUdZt8L8Niy 8uwir2QEupa9zSNGvIFv+eQmv61SNWrZDFfRhCJtY1tF89Z6KWi01Ln4mEvvh9kRa2V9cthjjG8m fj/LTi4dzY351ziT4iJSrmd6uyXa27h+CUkxqYpnXWU4F8YInlqIC8IaiNn7b65Be0/2BIed5yAp GCPFSr++SL9lX6lx2opmye0yG9zDZJmZYN0apT34dqYJ4wytkQ2azgAS/SUNs3eI0d//9r/BWqiw I5J8IlyGyRrbh4DaCYACrYBS/SGeNdARcXo/m9+A2BZyu42LKlfbuEA3Hkj9pLjKAYI9cRHcMTQZ 956ddyWqjxXEZq09X2OHl6hzy1pKaMtLB+3Jqtzyl6seV08bVJMvAUoCH2tEwJAhLE6cjwkVuzGR Cf6rKySn4FhQjyEKoYxlIRD0YPh4+FFQ6E9yjDuXN+//nJ3sPO8ZY5kecXrEGGYCKinO4GS2gf+g 2mS5qNlCgMKCqDhR+eGYmbZxGxviC2E4mRg0RZxDxgLEjlFOwy2LOwbdrcocHAs/F9m+9tbZnAdS 75KQyYQ1obcNm50TWZWz+WR+VbbJPSmvZn0I9fRtMSXGyt4Wfx1mjx7ZmI8e9yh5OFrOZ7dT2duX L94GrKpoDZg1Ej4KitV78eg6n+EKeK9Gznob2vDRi/GVMH7vpfPoWlCIaTFiCIIJvVOtFxb2Xc4n k/mNXHjixIhYgjCZVcGjZDv1vrZAIEu9gHi3bGNlEXQlix2ffpxt7T3Bh9Wi3ItwE3LgGX4GOQK1 2bsYJ5Cxaf/P6wjU9ezlm+3s+eu3xhz9HyKiuHMDNw/HBA7N2z3KthZ+HhY+M6yIYo2dgrhEBVC9 l5PFn+nd3gOJMNbcJk6arZYEzS+RyFFH6DcD+KAFBjBldokVcEgK/PCAZEs8iixmyMWINQvvyUVZ yI6XWJHzMFJdTOaj9wZ1Er+mLaaO4okZP/zYwl2ZTKG8fWvZUmytxKG9RyiIo4F3dD2FBxLTy3y5 Q3DjJsfD3nxSIb7X8xubjoXJndUDVYWABrjSPr9YlijGLtgc3ZovPYoQ8cNM6OpaUWqwpY5TrhTQ L+frK2jRWs//zCe4SWD10XUxet/HtH+cry280sKhYvaqSQkoSMMjVrvlTNThAS3SyJrNiEHGZg9s zXFNxmXJBl4NovFf3kKTPpRjnAD2OMAL/0xeMSjlu7fn0litZpoTGYheivr0PgFKxfu8/AGLjBNZ k0/ARKNGRxNlJrIzjBsUVbKmNXl0mvi4N4ev5EHOFCTGkXoSHEWvI6dP4+e9F04MgxZDMkA1pjUq nQXuZd8bN7UNZ6h9G50CC2rMTMhmCYOYs5iCvprgWc9ZriXiUAOaaEQqm+JPlJvM5SimX2w9DlPi 7JqpM32FPsyF+XB/ozK4zRHk4yMN3t1WwNBuRUXf5iGFG/Xj8bly9t4RRisBM54rFdol7mbrsIfk X6wnGIQn0mVk4I2lgpg7yCuGXKsI2ZGQKeJryRVmk7xKFGye08KWJWmfFidqXiKT56KpOx7EsX5V VhiAIQvkxm5bqrNGCuM/jwAvy20M3+h9wMmntUvZzgjZLfYIuUbzXn96e3z04MH+4z/fk2nWJtwi yMtJ4+XVR26F4NuIgAQf75mwZvvSOjY59nfxzSBPw1h4biFycio2dP89Hly6meFRczMIQQEfx9kH 8kYyi1H4zMBigMeWoHEEmZpNW2mI4FB74Jd2Y4BKAWltxckxYByYAKn7RawMpnQM6CHDLACO2NVM sq0Xmbbz/zWru/ZmH82MQm6RZOJF0MQRUSeptgIX48lV2VnR181g9EvjDOm2rNiSOPUWEd9CTPhM qZR8nC9Isiouse/uKaLE4TgvmMQAgVvZ1hieTlY07hGKGVzsoHvVFyQVFootO6kgk8Cb6LxjHIYC r/EkyvzM1+wB8EoYeIsYkjI0vIZcaGdHJ//r7OwYxgImSkoFWvblcg4qNLEym27b8LjaZms9DIXI LUojsxsKBzFBePLi/NhcQ8xeGkWG2XMlj7G/Frx1XNfhyVl2s/vy+QnfRiI8y563M6SYzCReIkIu ZvBMvkz4xdxbvT5L6zpPLS+lPcVMaNcoPrWkY1deHgCBorwEo4i7a5aHSZT/80RHkvRHHNI80ZRo iwDE2LeazyekI7GZnkIGVlzGWsiSz66WOXRhDw683Mo0WSzzYAbWFZeYuTCmhOSJIwqIlKwxsBp7 iRFtAQq5uu6Wz0KunreWxeJ6SYwnC/LL1yiTa1gyGUUesrdVpbyyEI3f4Urbu682LP8cHkvctebU cEYAJbeeBljSxp4shOjKbWfjXIIHErI6StG3NLVLxnQdmOJYLKgdoPsc0eZnL2gDIzetICAyN1Bd 41JjPSmdhHEGDJdxWlA7wFRhbUbvJ5T8gIuoa4DE8SGFNMqY1S4+4JTyElmm3CU5VikvlcIILqUv R0fadf4BuSdvX/SIB/pqEhpeTAl+RuA3wCazoyTCZhpOBlgjN2J/T1NowRs5jLZncgaLfJl3Wefl B+GhTd9+kqzdoSQFzC9o1intsLgmU6i43CuEnadieBMrfMpfuSPRZj3/gkHpEbAlwMhLHyhlWy/f 3ENJ/jWDaTKMNWwJoMinAa4qNkhBuMUdUZ7NCGEZ89mtLUcq2VsNqmiYLYYTz93IBeH3kNvkiVRe HTBukPLewBbQk2KDkQqx7p6n9+aRZ1hs56gnQjjF+hQkgsF1jratFNt9cTN2xksz9wWgVpQMWC+C ywDtGrcavq+ryhG4t43btsjTlSflIZoyoEHdWKGS1O6TlFWin43AE62FROE0+yr/wm3AZ2Xy2EsL cmdbr84+KyuO+HMVtWVI3NAhRIYmrNoaaocmMsEnhXI3nkxyo2QRf0KVjTB/RqDjwfyD4QH/eWSZ 71n26syspsNxniKJ40AY8bmiUH8V8bQee3W2tbe9R/XuJOmCYInX+YcSVqOar840dZfWIujBpg8f bPwwu8tgvA7RtmOz3VhWB2wCmia3XdY8VeZb64YLFhqUM4A+NX+gmUQiO8GBEVzB3Am2NnuQzQGX AE82IodH2fZ90U8gvzt/2102VpZpZpjIYDXhVsyk8Li+VBBRKpuAk9xYx08wjzc69Lbjy6UzpirR MsUjEwIKVxTLYbJu67mocDarYoFfMHDgmEqpDW1V66lr4izMMI+VCxnwcm258Fcn37fBcS+Ljp4a mt628XxWi8diPZ6ozrZMtvlJtkc2cLYmOeTLii0hD22Be/vh28raN+TwrNplg4p0D+P3PYqYQEwJ 3nhJLRZWt+oXEM5W80WMuJ5QD1GQLc57zf6ZNOWNYr6GNHxf8dICPoL1A1a3VNO2MXY8z24wT2s3 Dc17+RVZAg34hrDaJxHdTUClTDxpQKAu7ckpWFuX+eL5CNRPVZvElfpIQqlYoflNTvKQATSapoPM pddyeqw5bzE5uPjWbjbkD2PnB4lJli1J9kik69JyZb2uMY0uhl7uR3DUBUUayeP2hB4IoCxWih89 RQBZa6og+mQl2G1LPqnvWTCEVGtAlpVDpEXsMZBZ7taOegJyfkNSaz6xaIzEUV2gIt87XsPxPMyh CWJuBgoLaGgtFSnE8ET8lq0bXGqx9eWb3eOzXWxp7frj45BGpO/srGs/xLK1SrcyPepYi6j4Xnam NqO0KmXiXofX2BJcjVVxmQpvQZ0WoQX+y+h6tQRJh3iKkVR4kSNhi/IdsaXN8IamHvw4q6GkzzyQ 63CXsR+ARciPJuUqkSpB5p4rM/F3/SCAjgAVarCfQUi+Es3NZIGU4hK59Z2tbnO6zSLLh13i2Ua7 HxqeqVvkAt/xA6chgECV8nZGxiaXW4A4cttn+rssBAs0yoZS0oYgRywI3l6c7JPCO9tAK1gHEVSl Et/smh48CgK8VYuO5cZM2D25renNTFDFVSNCd6vRK4bwPORbogCmEF98ly3rqck7S7ldgCGsQ282 x5yaNU/XCsPl4I2vjhdgmwCSHheccGervcxU4LANmnHFHh6OIJ/6VbUbPWI+vGaQhp0hxw5RxNE9 ly/rGGExqLrhIcNACYEjBIpRrv2b3jh0W7PEJIp9jBJ03hSSMYqYBmyD9zRVawNSCyOME+VCfWFF 9lo4YhJ4CFU/I1Y9G43EtMxsSjyEz2WDma/LKyIa9TnR5KViEvw3U43LM4PYJiPth3N66G4xBN50 2STnLZ2B12uoLK3er9NztqAcvqpowtBxRZ7n4rPVPHZeEmL56jtMjLPvNsuNUMoSSZTYfGMswkQg tNHI0Fu2MPQTuFvuCSl0Obk09yuf6ShVaVN5o4mXq/A2ISQIOEztAmZePK83yqNlT2xsyFkjl4Rn ELuhma0WMGXFk1xpcnhOjg/rGuXNAiZSQVb6iuFhiFNsib5V37flbrTzHltJ69B9hvk2ulDXMFW5 pP6GcGkOfR5LGIoypWue2uMBe7m277Cu4HGkxnjqpOEpp8ymRJVZ0OFe17BA8HdKCmhu0SuBz5lK 3uo0Cj2gajgwEsQQTQuIUiJ+mlXXQDlGyNJ3BoXpR1mU7E6O3BqVIS1i7y1NMZO/Ycmbg8fnFrAY WlP0iRSPtUpqjpVFRHE39cpooFhQuYPsVBZjNSpGm7KW5myh9oweqWyKfcq2ymEx3FZ125qHa00L pSxgUTBqbATbqNBU/KtLXukDoofHbTx2b7vJXnoHgNXSmuzNuJCFt/CBsZdjOGwyq3woFCsRVKeb 0zRSL8n/1Fn3EB8eAuaYlX1qJVVO+yTEr9RVqZZaclYROlSAzRBzyIepGTO8gzGsA8AlXT9L6i2V hVAaU8IXO3L1b7NC/QrvOV/JRBAkWJI9FYe66Q12trrjzCk/lNMgwwuDm2DX5D6kyxE97AOi7Gld OfXEBkryHwwzuVBz81Sir3pVvqfvrI9/mZNQXlxrLK330uRkRpeTCaxYoD68DvFr3S2UARO66b4W 9o1laWlByEJjEnjg0rrWxQCLRhqwMFSBL/VqTVZUxoadenOhaB/jqpqgYd13dhFuJPjGhkKrQP5K BppnUyimPyIwlT1vwYaFIcBkxQfDA1oYRfOLtbofp4APs06i9EPvRqlovUm+kLrPdiZAX8+eR1CQ Nlm0w91223ASZ2gSlVXn72t5kx5oBkVN+De6kFo9P9LRqTSLx6af4eWhOpAt6ZBM2S0S45pz0oho JiM7uyXR3jPL8kjGYGVxieVqhcDU0mNqyOcxf2DYJ5JisVSrB6DJcssSVMd/MwWCifz9HmjnTX6i AlvCyoZMQOi5DuhEVl7fSzaZEemGQCyYQsiEbnj7qqWUCHZuuPvwj0FH9bbLZizK9iDBuR7Z1GlF C92l+IHc4F7kvGL1jPWyNk8CaU2xfux4wvJA/lL8ovUCrgvTB228/RGNDBASS2/ZXdr3vcKpKo9I F2pPzORFKoQZHxcok+Z+fQH1rHeuuXEIhbQCVo2HnP6qz64QKtAVMX7S9eZGK2sYjuTU9iXIDkbL GXJMkjPkGe9WDnEcEo7A/NYw7CwVtD88peyoXicWL7qM5fhbA21NJFo0jah9655HTeavGRPvJnQG 9KeicJ66ANO60aigGixgj+4z05OszWQ+2vmHMXngZqnOqBoD3fPggICNWpfaNsXYXyMJ5gME9gVG zQVrxF8kFYTu9GC7ttZ1OkW3YBcSK0KYag4G4AFpO/LZOncQO+5fnp26kFLYyvWGwndGMYdPWijI oyTBcYOsR3jmcs1hheTPmzVZFgQEEw537ZWA1E0cuqQNk7nNA9phOlBwb/j4PNNvrucIlp1ms/NO gi8KhVzRpUWFgaeQB66pnZqKvuaDjoCCbvXl2R0Siy6hXQfhj8lDsytxwgAwe5bDuwc2GAzZRuq5 GHdMRyeEdY6cHe+cxuAqREOk0yyeYRXSH4nRnTaFNUuK3UAbjmcyqxDIsxHK19alsTmy0tgU4kOZ eumv6tvoZtsE1laPiCUmGKpsq92+7g8REQCCm4csrLE9cLZHsZeqqNpHs9sYvq7wsIruQ/irbCS7 BprxuCIfb07aKj7KiGzud7pn2WdmwGhXesGOghpZipxuPh8KPtjsYcg4v8A3HtSymDTCI/e1EIUI SesGWOfl0noXNvuAWkVeQVNtwvd7SaAcILVxyrMkEjRriCSKke4oH40qGp6XJUZQ1H+FbrFKWWXr VfYzn7yoF2rVYc86+8ouAolgqpTMNESc9n8GCXYHHRtLQEJ+lI4Ba0ZKEFy9GkQa1ALuA0NERWps QTLZAgdcZAbMAHoIxQZDV5qtVQerNGw0EAI0Qzra7ISu18RdBYzACGT6IAF7rPwSsyq+kcoyWqrj TZZS50EIo12wNXs88mPeslEHq5uwyJpxjYl7rWZYW7iSyOOygod2xoIq8/vMURCLdPf4P77Z3Xso g8DOwUrhsMt17npraejGatcehyagtbcgscI35AouEPb9+3v32RWZjHKK9S1E1e10GphEfgGzIPyo WE/NTNZir9VabzLr8iVsfTi4Z1L2YQ6OEhK0cyIbtiuDXmM9SY9R3/y8mcQ5JKzJ8WTDxB2T38N6 D0AF/Lmr1SB8nWUvVcpTsNUFQEk18C5DKMH+0rKgFnOCF8FqQjZjEWKNzmjwRKpcWRSmGgK3iLOX DzxnCPMRWriHmUHIrOASSvLm8hL7L49gp6mjtbFCy2YUVLeixcwV6h5D/DAVwNVRO4qXbCDk6s0a 22oEHiQULWXPP3EOHRJ0mWEcMKSMeHqHu3V0+skxx9AYCgTxbTDe4TC6iO0pLUuiidfR6kczj1Fx Kx4P9FNys6m0rez4lMqHgwGsncMj46Djdk7LovgtNws5NDRH+/wwfED498OTejlhCk8n9Q6K5fDW jqlZvgj7bM/HIi6N+ObY79oM/vA2rF7WUQRp1o9qRtEzECN71nyrzYrMIaKMDqmnWKHDZQu7sUe9 ycmAHFNCQWYlvvDa/m0NdXzQG6J/6rT3yPOmQCsUw3ia8P692JLsbsKUxeuPlorBStVJ03aqe0PF 4LN5HB153e9KosrBo+u5ECI3asBKkohULJsscNAcPZBPdEPGrVcAIW8a2/R0+g/JwTRLgcKdZtRk rh6tzm8X8yeRE86GbOefr7jeIHAntP10t3L23HG8zipa2qtpK5NFboS0Tl7EDN8MxAJExxVQ+Unv KsBzbTxp4+y8EM386AuvwlZWIBjYrzB5jKlpaNIMR+hxdFbr8rqCjA7KHBUDmZPVywWm8Eq0pVqN wGvERk4+e18UKq2avXK9irZAnRE9jiB0j2NVOVDymDB9N5Az26IVbPco9COeTvJZsRt61IhlQy+x 9b0zoSZwImOyqYN561dti/S1/HkQESWf0PSGAzX0svQo5kql7hjdnh3vOitFrzBR0leB4LnNCWhX TxiSYlkCwioxinyU3NaA+lrmYFHvVWvXFwrzCsUUpMtSexL54mOx1GGLpkoZ64vMaYl7BZP1U3xo RXJWoXDfUDK5KGYvSQ9jz0DK8oaCt8QFrWgzluoaMOYgked813UHaHPwTj5N8F81VHYpkyHkGBF5 2nOHwQRiWi2RxgQuF2gve+FnKrVU3QdgaNTC8ZiGS1iovypHr9SOqxxvuUl4G3OXtk1gdezZFKz6 OpzAd4hVYylXEff30eFEKMupi+zho4cP6iP48orhaDxukn+tsq++fnCvx7hD3ZDhvFvWmf648GyK iVLVifTAZA0kDGs5xlhcrpeQmyJSki4LQUs9oK6xueQZ2Lxp273FWMXx284FQWw7Fs+/DwVoUpwq hykoADoTglmCIB7Dl0+rixtKQ4bj5sYrTiRJLfuVCJdv1DRloJCA3epDnqLp3I2eMgsiFw7LJe4l tAL0NviaFl87iCZzW7e31O0whgWSLqNQm7cHWbQlCzb25hxZI8wv7oKx1wUfNEITvCjQ1aG1mu8v YrLov7I9xnZvqt3QqSsj52itpT/oirYUZg2TgY44S8EJRTJSF9M44Qj3mOEbKznGrzYNn19cKHNq j2RHpGLEQqd74ioCPkliMTC/nsbikRpo4QMisGkYpXsCECmJ/oS/qt26J0racpParm7ZGAfKZeSk cirGgRCOR9kWk9sy+7of2na6u/WPe200h3S7saqP2WH3heab3ioT5VXxwoF5aDUw4EYlBgNRu0Ur pZrDjpUHfyVCd9N7DJKd4EQuRW//U5foIg4ApZuB4n/i42H+MFiwIoym2oaKIpewxCTNhpdCxHnV Q3BFvXaYHcZjnZZdiZPZki3pHxIslqVqrR0zfHa8DQLyrIZ/F72k2n57xBOL70geY6e4oKtbY2ar uOCVmC9xIwhjhBiwxwDT2Ot5I/+KR+3ihFKq8aFoigUz0AXUQaK0CtDKKrviAXAYR96UOTJ7H4xg vHxB00pRCvhaebFJ43CNFs2yY0kzYaFqH1qbWRhwkqqksSXlzjU3O/INQoNG8kyRLA/nhtyMvaWJ zKhy/ZFcmdW+rGnbZczOE3fF+W2T7IjU38gab8gSERDf2ajkhLe2l9DZVtwCTnogWXSwtdHQQjg6 bHR9GoMaTpbrhNZWOrqiYkeecStJmN1QktssN5fz+Qq6F9mfHv8Z4A3oidLJiKfHT949eemQzn1O 3KgMJVkE8QC7cVFIB8wAi3WelAsmDq+w5vYr5KJLvxOFoEBeIuVE39sAkjxuKRFW05Ro8uPhk5dv WFJwrVX25ognPBZumsWiJ3/9TJe4sEDIFNMVfopQenpht8kxteQNn/nyjUaKpOUz13PNkPj6hqrW ZMvUIi6DNT1BzsnY2cJMcdXuSV4Hj+LU7ZGl1+HWEgzvk25EihVLbeLumMyNPVAxowQWM4HKeCsv ojv/VCwUi0SVdyZ6+uYn638itRtMmUG4/WF4C3orjczoOokY3tUjPqgOrQRh2Q3GU87M9yt3vGs9 zrVjzv6Zm3d+b4hMWMLmOvC5fmp4q8dtPpuEh3yd9WQMq0dqmJVOh6CSZwznG2Iz0dbrt0pNhD8P ks3p6G+V6etmxp/S3WmiXX+gM98rikDWxxJnc35576Be8yZ5GFXRogkaXc9U7NKeydS2HrBmbAQP xqRbPkTb/tWejMTlrRcfFy362oZtA9reox4x23s7TIn5q/cmbZIUmkax/SXQ2XjKSgiUXUZk8J2B jrUJ2pE/6OP00tfagyyJr5UcIiLX04+QZmpphczfJZBDw9W60XuT2KJng85/3MZVr7ufn0eHGFOa jrNo/LAbHlsOW1bjasJ9d3616hpsVQAPVHi2iM8C0a2ooa38yb0n7o/8Iiqcvp37bSp3UAh7ZFfh Ued4F67EYQhVPYgaPRfcXXwCpl7+ioNmlBq8VwtaJAZQ28G2i79YzPCQBc2xC6ExkWJqfTllHK8z FtkaC5+7u9DBKrwMUZp5EjsETRYCb86nMbkSz5D2eP2HeTHJfsgnsGLWGXlzzx8jjnS5Xx0+0YKz 9hudmFKOzjNadjQk9d8k4qWweqJhSZIpwGnbrTB2XAEZyZPbl4a84sGp5S84CiLdmKFKq6Wfj1bT jy6PNPCpKxcUnjRBCMoTVgk/Ovt8ihAzmnkInfPw6y0Ny9lsFi3b37T2eiDDbiRYvABYbxrcu1gv SasFyKiqaGctNhbc1YkId8lWzaCHG8Ky9Lq/j7FJKqkNQ40v7WUvdQfwH/wz/q7/nvI/1b+oDMid xfcHu0+/JVmCErDsKfdh7umT5TFk9keOUBi6KPXpZT4tgTT25r4+sFuL7UbZ7wa6PGqpD3dthtXT nsgwb3MD8WaxeXNJvcXuxYPPEiARriaqETswsNq2qyX29/a+4ZXZ1ZpjGg6vi4/KAYaOFJyJU6tO TUTAW3+jVCkxBtnlzR2QpMykJq2ZJLGGZT2jganVhX1cbryAYeBSJKzNh9VTj+96R+s2WEtr/jBb ZTX/RMHdSquHaY0omo1fcxua4cwZdl7Uqv2pQ5SYk9U1P1yMYw3yhgJnqEUudPFe8UAwkkY7dSoz fOyTZcyNi4nL8EV1T0JpcVIEr88LPvg4voKOlK6kXElcbYxuMiJknDEkLP/MLXQ4+cK1x7oucv8x dj8g6Gah0Xjg/1oL9VvYjLDQK0IZPwnSYE55VuaDaIiJF0hfp2cLtDt/J6a3oOXrt1v3tymdhEG/ uD/67JUj9/2eyXlbTJAk27pCVmRUtjEJdTgr0JOo9OSvmYRsSd+l8iaGKW1jab/f78rfeTXnd69/ J05DFgzCejrrSrAiNCznO8687azmO5ha2uBl6mRP4a5J1HisGJU1SxGU9sWS4kH5WssnwuIr9mD3 fO4/9hqDNsk51fDpwT5/xcy8i1gmfbcnOCex6Vqzi2XciFWt1kh1IwuSzf6Kmc/SBZLNBirBQjAt 7yaX9aH96p6Z0gtB8UGt0EnuSesOaMTtT5Meirp3ga6aCPOoi+w3iKzHfJ9bJTrka/mZItsT14vi irmiuFpTx5eI7NPwhucdoERTu6QPBERpWp7YKMNnli4nOlf4Jw/3AZMVTgh2pUodAk32sPstRDJz KFOimdO8dwwJ/0sOO3jzs7fhKE+w+dDXDVVLCaK1FpdIovl0s9QhHa54kAqBxOsLzlhIuAQNtHXf rlxR9GU9ZYBahyFgTKBqwhxPg99h7byXTrLvgLx36tD2ESWIHbx80zJ4Uj/xKSTmLTzZwpLu/HRv gy3kGLgulIJI6HfMNpPVImYOO+Xz2rYAnFTot7tk6xSFLzPuNCb1loXuLJaZodnMcBF/x6VJjdpv xLyweT0pL9MzqRjoC2KE0IsVptaYsMRvKd7/FP0p1ox4ycE7NNU9eF9I99MQiuC6Nh2G7HLh2I// R6kA3neVyKFH76j/fxYDWltlz1/OiOOzOjf/j+BBaqWT1D4MlJgmamE26w7uRAzQ1wkXTjt5FA9a K9zW2LRBLIPvjtyUJm842upp6ZZxrk1tTmDa0rBNanTOdNAxoCUzvLW/CQrpTRlaV7xEEUNx17qR 8GMO2f5H7+7SxLi88vvqNgg3U9OpAiwA76mLDzKY44pUuEumUbuuGW+JVRQqoQmPH9v5ofT9kP9k Iz55p5mlVyzHnvyjdDNczRF1cxP/fr0Wwl7nxM/SPd76T7d/P6zzm6Lsmp+Beq3CTeVSOjtAJ4Zh 03W1sGFTRVmIC6HIX0IfStNipLuvE21NQ/5sS8DWcFz7Wm6zku125mYIVzq9qVuem8/lXDlwmN4O jq2nGv2LZmmyFrSb9a5tfmedr7dcW0oGQj3ayimQ/MRV0fkUf25EUEMuiSMbkVDtq82TxTeJIkb5 so09y74PmfYmqHg8BICjY4udyn49otA92dYM8MTOUvSvQE8p2CwCewPO0eLTC1nDbwBRIEMm0sVb FBGD886XIekzUcocHx1he2i+bo0TriiwkyEn2RVHCKpMRNaBhy5RrLlAh2Fa5MZoegNT6EeBAyOi HTpXeFLSQOpB3QkGF+r+5Y7QBBfOuzVBMF0/EBLxHjTx2/ywllO7DE+NBEBp+Gbfjjc2d0mL1A1m V+iKRQPA1SBafsYavMwvyNPpduzsrda7FBkGp2fndugEAvDzF355XAgALT13dvrqBVXS9cXOqWTd MvDFzLqeXlg3KmUjbbg+ZMb6UVcsvDvSJuAJQgSB/FY1EZh1yQzrqk6rPuR+I3i/Fy1cMW1jd03I CT1sIfY/sCjLJav+BYkJue3Jzj79PBdRkLfIJLJwFmJn5vMLtR4hcOaOJF/+zoHeoeVWtVu9ohsO 9H8cwR8Oh9ZlHQYnc0Ck6P8g9aCHHjGFUG8YqtfZ9iA7WEpmlt39VCTCdEJnZ0Gynxubk3/QJMuI UA2hD7995ZYwtlhbH3IPeiqM0mWOGyYbqOFNO/41J6Ak+B7f1gkmBSX1UYU0MGsyN825lJ79kzQb gvJmqoq0Itqqo09oeK1WWrbjLBFfHQOoVADz8h75xNI7MjNeikPMeEKvJcZFi3+W9S0uMencjv/a K4xhXaY9Ng4yLfZYo3iHckDydOmgH+FHDuzbGEKgXhwWi2gwJqCaPJuDLxBSZ5FaOL3QNhbLseu9 59l9JHHQ4ziPuhYEOsTrJkWg1m3/yt8RfrgSY4z7z3dW0ZvKAoiuDGNdFe9hGLk63MwWske/Ko3+ SrL5qfYJFy2SJ3I39sTy8eKNRKeuLHlq/EHTEZlSRb94xgaM0pw1yqhBByMZFb2mA1ur8+sQwTW+ nkUG0zsV4s9NJbvWLMGqUyKgkzg9AxcNTrBmdeNmsgO/jMIP7bc9QRu7uAYp4+QHBGoPhMq7ozDR xR7gceNF4JZK9YOXK5OpcKlBmpFSp0F6l0ul61AStgvrdACSViZetFdjJjUmrpIlxbA/XcAbcokM 0FotrTrsLvI45lfJr3kvX4xPGiJqZc2/OjwhJb916vAoNPfhyMOFji78ZEeQPcKKGzviHdrS0R31 ml5dr/p9GmfkpVwC4+pUJbJ915t0K5IsRhppafPOZ1bmTwyRM1jiHQc3FpNRwKJ7/c+MuxFEHgnG 142MOGtu5PHjaqyfTcSsL381yrlMi7rtI9hyxXiAJ7/9zeA8qFfATDgEXZdHyjL+jF9rk3cl8ESO wW9/c/KKX5AIAVf9nqgtodFPzuA068MabgliwJeQAA579Jw4CT8k0Rqz/sUeg59so0trqMA+7Ro6 i9lEWsUNLXMnTdLqEh6o2YZ3dflIVzDd0YTcHCxyvuiSEDRKFRBnvKkgKwqb0/iO4EITgt927jyL jGep3Q1ERxAvde6DoJ/OX3Ts7OZCmfbRPnmRnG5p0mYg9jSL5550x9xZd20QKB1iJx7CoRlBqXAd BBRfBCLJ6+e6AaebeeOj+q7n3eiOGqf3GQdNB9xvf2NtvwFWtltKNXk0+Z7Q2h/SlSNCeN2G79MN +F7rcnnopdYL7PTnL45fbe10SDMzsscPKaZeB2JhTGbKINbwretON3N0EGSLpoXTo7NoPgTv1fGO aHpWFNs6z9Jn0bP/+3+CzA16FaRQdYx3d3b3QHcUdeNi3P38bcyh+i8ihKS1kJpvENmm912t7903 44hcHG5dow0ZUCgpKz+4GDstTLl6wLA7wqTU71mIz/5rYez/0cHOo4cGxx8/2Hn8zV1rwBfprEoI OCzNQI+FN0u9pljalNL2+9csxWUMs7chfAkD3T0bMQomQkbxK27P9Hn2Ht79/Ds1MIVkN+FEwP1W /ESYCXRkdiyksXPPTlAkYbaecqQUH5WUmzfcs9rswOjQgO2B6UDsoODcqSrg4YIklMNsn7nleDgs 7VZgZeJFc1rIjit+on9Bv+Di/Qutd4LWXLCNhBEPhOTzppuhJx1RMoNN5+kZyoZVUl1lYbFEjEms abyrfE9rqnT5ko4sS2/AldXV4CR0oTOlBe3pqnuznAKFOTLssMxUzM8piMdN9zKRjp8oErUvw9EO qpecZRPr5d9gsY4oMRklyHhbUX3subuHenOZyRYyYkdglI9mYkRnUBvvZoM44c2XGovPXd+qzzoa POwxqVnG94S3dUTGL6ua5AIg7l44KssbjbDuZAZpJsXsivArSJ83AYo+7InlxDt842GNuMtPLY3f NdI1ZA5Wm/lsNnW++Rz8Gqvm4Hu14an+o4tD6xtoHUgehaYk65/Cj0Fr05H6DhzpNL74HOJhEK2B KeykmcnkSr+qXPdMCcK0hiZEcSPKy3X/iqNPNAzgo1W61WCRYCTdhIHvLojItKB6sj5dGukPRiz7 6uAThjXaRI1qRx+s4SbsO3jXnlI0YhGvFmSvSLYGiVYvunjuwm5duRpuXBVsRGv0hrFM5kLKow8S sfQsoA64YSdBMPraIOhu8LK8prZCEmik5VI73PJXIbo1nM4IX6B28GthF9jzuG3Jcl7ppqCRFtUj TsOA7AWN577FwgI+y3MeDA+Ms/i9JWPHFJHdQVaM/+luhUpZxULo9TGUK4bd/VKjHPStJ1B+y1wH 1BNFPWay6Mu4Eg5OgU78x38GvRpSlADQgZDeWB1JKwskPEvHwLVd+qfenhoS/Rh/kSWUbL1lvn71 U8R97nPabV1Q0bEjVPErFKI4Ui7k5MJS3SsWO7AwrTTcAEGBS3/lh0E/NdNRc7dFJ/QOIYyMiZpy SWt4m1Q4fKBNybb52tQpQMAqxvnJii7XGrIkamUMcedyTHlQzkopgXCT+J2S3Iz1mu2GsgNksmPf nod0GnxiEeeIRjiMqFAxSEVOeoJmy7K6RuktTA+Bo3w3PY0kO5WFk+WUcgISrU4EjczmaaRNB7Ka BbcY1QIESVbI7WDMTTUnSGSN07utgnWmVdSuVAq1GVYuvzx2EaLpD6lVTMmCY/2VnywfuX1STkn+ KsaDCi0/IdKv42+4SorDGdJPSVdtph/3MPgnvooKWF/uypYQbA6s7D3+c4enm+OUZoTURlBkoEMl uDa3zJ0fb3h0rx+dNMyTzHizWgy1zXqaqeOr0EfjAxujTBUqU0++9p/0sSyjLCf8SDMnzfF1/YTy tPwXP07oNisqad19qx/H8jBUp28ldzagZwpmmDZ+zXmpPtigns0PSNZnhwAMId50gfF3r3BF+slT 1wO76UZWtLcphB+XTeNq/3d7GoK5tNu7MYE+xa0w/JLjQ7jEka8clSdrzhaC1zwEu2BI7NBinY7R KTzkevNqgoO+mAuVyvWwZgyg7urjvdr5f0pWkW3xQ3PAGvyDd+gMcAM2uvgFULShvVWGT1g2wrle YBXEDqZlcj4nzVu4lpmS+pOwvreATRg8Yr5BOMpoWG0QWhZ6OPZMXFC2UKhBFawdDDb/op/yq4f3 O+rytMcciZR+bc1+mQwtk981geJXAfmR9YndqhrMg8IuJy13RJO+7+2mNXpCClWNZy7QwWgNOB/G 9boDcUm2ij74dZ3Ptjk+ZWIa/X6HeVOEOs2X7w1ktSMUyUHN/eg3PURvxFK/VuhFG//xliBll5Oc 2+ia+Nt+9b6ObzWhTK1Du+Cyah/xGco47NKNLCaovKaamN/ecy/EXmKJaYSgY8c3dwrnGiQBQJ7+ II/hXQvc5BGs/NvnJ72FNaRsTCXDmWXD0Q1c1EPKur5+uj6V2zKgSuTs3+OGftU/6CY1+0eGwFuj tUtGjLS2h/VBE2oKHoeLKeAaHbdoTHVd8mskseZuq4HkOpJmFXbP2UppA2gOkUZvn41onrM9c678 Rs6i9PMeHsFCuCr+TPVBLS1BNhD92hUb2K2rNp+Yy7KY3IcMK+K+gyllEVyWQvm7zAkBhNvl4wzN YOfi9XPxkQjx0Gx6+O1q6SSvYoLfRhPxfvTP6f9NCDz0i7fhGAgskUDV6CZI6Zk1WsSf0Dhe8sJn bACExl7a9UIktmUOooky/pEy4He0lhngUrCqbq4KXjE5JWBuQf9TTj8Zk4izIQHmRlj0bHyhdmU/ SEqZog7SddJeppvMBb8QjyWFVWFF6TOSafKK/ksbd4RcMc7zO0mEDD8jGVDHva6id0RcHea1T4bs eaZf02lS6J8aTnhKGzQUGGwtQ3hu9dEnxaAx1FZTk73Rz6VwonhHad3jN+F+yE9OL/lBlnA7Xz3q xeSN8p01z2UbH6zCT640K96tqtXT/ycAAAAA//8DAFBLAwQUAAYACAAAACEAY+Snyw4DAACDDAAA DQAAAHhsL3N0eWxlcy54bWy8V1tvmzAUfp+0/4D8vhJoLs0EVFOlaJO2alIzaa8GDFjzBRmnI/31 O7aBkC5pGintQ4s5+JzvO8fn4kS3LWfeI1ENlSJGwdUEeURkMqeijNGv9erTDfIajUWOmRQkRlvS oNvk44eo0VtGHipCtAcmRBOjSuv6s+83WUU4bq5kTQR8KaTiWMOrKv2mVgTnjVHizA8nk7nPMRUo iQopdONlciN0jOadIImaJ+8RM+AVID+JMsmk8jSYByJWIjAnbscdZjRV1GwrMKds68Sh1auwaoCn M7VYGJll2elyKqQyQt/QcGSSKDW7evxra2eMbyVviT9gT/7DfnPfL4N9OsaXwdk7tn2Trzugl4ha 4w0kBWVsyNBrk6EgSKIaa02UWMGL163X2xryU0C5uJyy+07sLhXeBuHs9QqNZDQ3LMq7cVZCtWpq amhydb1cLhez2c0sWIZT+LNJk3bbqchJS3KoNYc5csOUgaVsH+B5KlUODaKvzhBQnSiJGCk0lImi ZWWeWtbwP5VaSw6LnOJSCsxg6fca/fMFTeg30FpipCua/QGwvbKf7hycgoM308V0spjOwrmtdIAx 2IehOw7gUUYYezAgv4s9t9rCExu+4vobRAY6oWkH/RJC0i2dC+4FXDumFID+ISWQ47pm2/sNT4la 2fZo0azUJNLu7QujpeDEHmin9lNJTTJt27XtDP7YG+fbyK3AHNcxisbFQxRB3hYnHQxPaztPVxDG rmEfY3K2LWd5FJ8A/IQZ4MLlVVLRJ4A1wyOD+BHX39vieDAuTeGvwvWatL3n/kvYo1wBGrsEA7k7 iD5pXHr0b5d0/xW5cPmYv4Pf3jnncOkcOJCGZ/F5k0N5ZwbnxB+6+6mGtN9STqTkOdizd8C2vRq6 82gE7Q2goZV75uISo69wXYabuAd5OfSBdEMZzHjTngN7lX2udG9GCus1IIVGGs8mBhDJ290MtF81 TuFib6bjQA1s5KTAG6bXw8cY7dY/SE43fDns+kkfpbYmYrRbfze3hGBu7zh2xNtfD8k/AAAA//8D AFBLAwQUAAYACAAAACEAb0VVDhwLAAC0GwAAJwAAAHhsL3ByaW50ZXJTZXR0aW5ncy9wcmludGVy U2V0dGluZ3MxLmJpbuxXZ1CTWRe+CSxIFaS7oICKUgMifSHSlSZCFJAmJYTQAiE0abrShEUXFZC2 KDYQMCKClNAEQVCQokaaYKhSpBNq2DeoM9/4Y2dnvu/XN5w7557znFvmvc/kmTmxA3bgJDABKKAN LIEpOAXkoaEAVU9A+YntKn1WBEeBDlT/2WCMgKkPfNxruQXgMAADE6y4Xa5Q3A2sIQyHZjiETAAa EKCBBnggCo4AVSAHlKAsGHIFaIgDyZ8v/gcM+77GCEU45D/wz0fMLU6epcj/XP3vseD2FVyH6QMA un+zWnCT4UdOj/8JfuR6AlzAzpgBuOvSv/6b0Xn72RSGFBl+gYpb0Brdf5z/ed8O/v9m4OdfRi30 XEtTlBH91VzgCbDe1hRuW0lWAAfpyxPoQjUfSG14KIpCOlOG1KsKZeaQwgEwQTu5Yn0w+q4YNADm Thi0JfYCGqoSCGj8NrZAY7A4HwD0Any90MHfgxkOFeDt7IUGFmh/nFcAgb5DWV4+GHJXXyz9a/6d 6QkAoGBmYU1/FzuU/1vLGX7czQTpAMnCBR2BAWZRNt7FbXJMLXUN6LeIs9BnAGS+BcAA+6YrNXkA LKAaHZ1CfF/8HhCIMz4uOG9fPNrfH+0qq+dEcEIgQJSMV9qrXacQusYvz3l62RnyaVHXuDXMOnk1 nhWIYDKOXelSxS57MxR6aHCEl10tVm443jXYY+ZC+djWaDZlYRScXJ2HKmGF9RhIhWONjSOfmRrb ijE+uq2zS49FH6WtIwozErX+RSx6Pst/9OuncNcSLCkIQ9AcyBpTwbRlpvmTRbI0wwM4/PnFCASH 3v4OoZnHI8/Vc54/UkN88naMD8qQiuz/w7WEonFW1IbBTj+lih97CM/Ae7DyJclL5xkZO51ftnxh kJVSPc2RXoUXup4YryJfbed30898TsFnr0Xf21WrI4+HN/YJsYl+vQiT1axTwsEf34dlDOeJhtbw L9tHDe97+RBhMH+xLUjyS1j+ydeN5VN1G+gZ3+76+P0eenhrt8P3DY+tK7XRSgelEqLnROpJLM1B fM8RhvNxzsgxpFQ/u3+bCzYY5Vkw1oN00kkZ4Xrq2PFUOsQCKWu+rJgWt+T3cGpMvegstcH80/DN IFVxTcbPsryCcdHOy8RnDtcsZ/xEusZIh2EeuSrsIUjpJyNmufXU5GYzVHG25QYY2i+pVf90rZDi ac3ZpF/yipY1WtWiGNkUHUkMZiZvJlD2K9KIuxL5urTudifahecdKktVCi6nWEYcbE3h5OkiTVrn 9ch8zaHtqQ2ULsntTzFZV3htssBkHFBjaBsRF9r7aEWysSre8TzJdA7f6KfonH1y3XTtZGFxzGRY C3764XSKJ5LD+svmIva1TDtGeNZGNjzdGIfaEB4S+YLtOzhrGqPRyq6F6dSuH3a7wZlG+PglosF1 Cn9Ui+jihW4LRWnFCisJ+ktNl3RqnO9rzvStvcewrCb6+aKkdJX9g8JFfrXbZasHTnC2ECQ8AIaR FiA2I6y7mHvS8ZhiWPM9RMai9/SXjgsHI81pfrE1pxfa2JUeeinVzK3dTJ/5+kJKUx/r46MUaRU6 kPw+dPEyNeKFkU0XMr7hUV6GgTurX9Sedq8MxdSOiySzdvZVrEYn4/QdueHEu87wvGxx3vtcJUlV OumonHOZzq9KNwM9/iirVct/XPe12LLnHe7cm+OnVQ70aHg7lXkdIhZRbBpvxJhGKevk6wYrs37S 0zzPxTvik0o9QmMKme1VbG3r7+mdVE2YqunGqmVabCi3Hap8oEOuLNeZF5dnWGZ9mXHJU/rdsDdO wcLAkp075l1QZpjzna1EnvreCzNbrUWn7AbIUoZNVpLsreq/S6Q658oJXn/I3HHzxWAfPAU2u5Tg evn8ft0KAT+RZOV37eSoLp9bq2eESDoxqXgnB6ekQhXSxDjnBR4KJq2wbZCP2wH2BGvcLD0oRNRf 5Di3q7i9NMo9MYEcQJBduqSL8dA8IFkefTv2854FW5Mgiy74Hh/PhXn88Acmn6t94ofIxbIEgdUn M66yih8UPFa89ri9abKxRHzwu/g1Zbr1aMJocmo94lanomHg/WFqQINAYtZKbgL5rLpoaRAysbPw eP1gUqmIdnfh/Wci/BfGbiRd01NOzuBAUBXq7Hoa+DXmWdtb9hBd+VpZiUhZiXnMXEU0E1Zmd75v sw03Zzui49hiQrk9hfKe2YYjnrSc7n9jVd9u46ZnnqDcbV3eqLaZOvXHhLmKvS7X2rlML3fkju9d iE9b6Erqe3Ddz1bHkd9mM4T7dEKC1WhLtHzp8886FfYEmn3mNWk70lpRvIpupYRooZOLJFzyr6Lr ntbS4dFm6ZuChDmPtx9DP8Xacm/BNtdCZTv4hCZvfbiDn12Di880dfmaGtqT+jQQZ5ncnotVW+WR tFLq8sMyVcO450SDW7XdrMqDl3SGqPUG7NpbPAYL9XJCBsYFq4kEZMBlstM4DT0aFmYwRS6zlv2U dMO5SnmI3XcZveZm/+hXL57wG2tFMQ/rPMO1HezzMqzfBfCwtbRlRTosEXaLxObPs83uVZm8lW21 u93g3vQLOcY+iau2a6hO6qrNAFNFqlyj+tfoLGsrXoS9/vvSi5Moj2yyIlap//B8D/OvgSHaDiog 8bWcYE5/CJo/w9CtJK6b5tK5cg11dqtIoinSZO9WUssE8sPIyrWTQ0gLm80mfTXagQX8hsES8lY0 mTZEEd46HaL/NDhkEqks7ta7PmwzrRniPpOBnwqfL1j+67diqi1X8eb0vbnneQW05eNXawrX+Fo7 EbhNbzaFXqKp22oJir+mVKoJSldKUBI1pepQOrrk2exSE6h91THjzST5elPE9HXhmpQQ70vhggx3 WWgH7flrll/QK0U+b+OYjdFznpPcxTP5q9MTUtbm87PVPX/6O2r+ivhweH6qukJ9rDpdhlJtdKia WCruFpl9ooV6RajjiFQXlUV5pZs6PlaXz8b/+2YPy0cEsiAtAr0k9/H9/AL3Vrv6hSelS6VnegeG MtlmZ992izjX3uq7LfhUTA3e6H721fzR4qQMo/37x8eyEzfSpC6lFz8NSWBJdg9Sv2v/JDeQz51K /CPwDuVBYqC/0PSLl3MN/o+SiLuLzWe0ZfpplEbbQ877GieyCzbf3hCoWqo5sN+gzX5pTI6yamVC qzgac9qw6NRrnohBF84uwWzvhriNmjjypUjDMwGCTTlm8S/3chsU/+UXbD5cO+TD9brW8ctSAjHo c2j1G9sjxKbbTdLzB1XtDgztu7i4G55IWS6vjKoUVSExcvp1hxYHN7bkJMeGe3msbMg0XW2f/XOc YVK0N4fypj8sVsBu/feu0+VfQivFd6/jcSoOsanh3SoxEWpxBvFa7m+RwtK1d8p01zfqpX9R5Q2C qW7NesA4X9pLtCE3noDYOENhB+lasQnuWDKbb1xIw2dbLRruiqQagkeOySHmQKOZ+rKC2MBhQ3eB Keqxgg83mUkRkmOjjI2V+hHZ4wxGuy6Lvb3ntD5S0do7G7yReCVfAKexUX3fyp5ToMB0SGkU6+42 NtVg4Thikrw5Qy1fFX5K/G3hDdrQpXVdqm+AtxXpYjiCpLmZTDRhj7E0Z/e2rq8ahcNHt5gxFuN9 a0PVHvzj9QOIrOoeLfB8iwG+BRkAiFO6p0yV4EAQYKHGMBj4Aq/thhEN/RmjYzRghFrKEBAEZVio gcQAJ6iFZPqH/ezQCbpxQLtgALdrgnUb7kw7DOwwsMPADgM7DOwwsMPADgM7DOwwsMPADgP/Gwb+ BgAA//8DAFBLAwQUAAYACAAAACEAfbg+HmUBAAClAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIE ASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlJJfS8MwFMXfBb9DyJOCXdpOtIa2A5Ux YRvCKlPfQnK3FdukJHF/vr1pu83KfFDoS3rO/XHuSeLBtizQGrTJlUxw0PMxAsmVyOUywS/Z0Isw MpZJwQolIcE7MHiQnp/FvKJcaXjWqgJtczDIkaShvErwytqKEmL4Ckpmes4hnbhQumTWHfWSVIx/ sCWQ0PdvSAmWCWYZqYFedSTiPVLwI7L61EUDEJxAASVIa0jQC8i314Iuza8DjdJxlrndVW6nfdwu W/BWPLq3Jj8aN5tNb9NvYrj8AXmdjGfNql4u66444DQWnHINzCqdzsG1ybQFeYXeGONqjS6msyny 0NOYjJRAIzZbMa3kZUw6Y3XFBTN24m5jkYO43/2LdDrtMjUVtMFAILcUbSs4KPP+w2M2xGnoB4Hn 992XBSH1IxrevtfhfszXS7Y/yn3EvxDvsiCi1xH1/Q7xAEhjcvKw0i8AAAD//wMAUEsDBBQABgAI AAAAIQDXACmEpAEAAF0DAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAJyTwW7bMAyG7wP2DoLujZx0GIZAVjGkG3rYugBOu7Mq07EQWzJE1kv2 9JNsuHG67VKdKP7Ej08kJW+ObcN6CGi9y/lykXEGzvjSun3OH3Zfrz5xhqRdqRvvIOcnQH6j3r+T 2+A7CGQBWbRwmPOaqFsLgaaGVuMiyi4qlQ+tpngNe+Gryhq49ea5BUdilWUfBRwJXAnlVfdiyEfH dU9vNS29SXz4uDt1EVjJz13XWKMpvlJ9tyZ49BWxL0cDjRRzUUa6AsxzsHRSmRTzqyyMbmATjVWl GwQpzgl5Bzo1battQCV7WvdgyAeG9nds24qzJ42QcHLe62C1o4iVysbLEDcdUlA/fThgDUAoRSwY k0M4r53H9oO6HgpicFmYDEaQKFwi7iw1gD+qrQ70D+LrOfHAMPKOOEXiW875XkgHafV/aSSdv2po VOR7RbTxbafdSd37g9WssBCXBtk90K/UICkmXX6z7oAP3c7faoJpNJdJWdQ6QBmnOennhLyLUwlN MtnU2u2hnGr+FtIiPY6/RS1XiyyeYX+mnBTnf6H+AAAA//8DAFBLAQItABQABgAIAAAAIQCnlfmZ hAEAABQGAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA AAAhALVVMCP1AAAATAIAAAsAAAAAAAAAAAAAAAAAkgMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA AAAhAN4J/SgCAQAA1AMAABoAAAAAAAAAAAAAAAAAfgYAAHhsL19yZWxzL3dvcmtib29rLnhtbC5y ZWxzUEsBAi0AFAAGAAgAAAAhAFJHLkRdAQAAcAIAAA8AAAAAAAAAAAAAAAAAwAgAAHhsL3dvcmti b29rLnhtbFBLAQItABQABgAIAAAAIQDppiW4ggYAAFMbAAATAAAAAAAAAAAAAAAAAEoKAAB4bC90 aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhADttMkvBAAAAQgEAACMAAAAAAAAAAAAAAAAA /RAAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhALhK Sy0TAQAAtwEAABgAAAAAAAAAAAAAAAAA/xEAAHhsL3dvcmtzaGVldHMvc2hlZXQyLnhtbFBLAQIt ABQABgAIAAAAIQC4SkstEwEAALcBAAAYAAAAAAAAAAAAAAAAAEgTAAB4bC93b3Jrc2hlZXRzL3No ZWV0My54bWxQSwECLQAUAAYACAAAACEAVlH+Wn8QAAAbVwAAGAAAAAAAAAAAAAAAAACRFAAAeGwv d29ya3NoZWV0cy9zaGVldDEueG1sUEsBAi0AFAAGAAgAAAAhAAKwL94MMwAAyIwAABQAAAAAAAAA AAAAAAAARiUAAHhsL3NoYXJlZFN0cmluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAGPkp8sOAwAAgwwA AA0AAAAAAAAAAAAAAAAAhFgAAHhsL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEAb0VVDhwLAAC0 GwAAJwAAAAAAAAAAAAAAAAC9WwAAeGwvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEu YmluUEsBAi0AFAAGAAgAAAAhAH24Ph5lAQAApQIAABEAAAAAAAAAAAAAAAAAHmcAAGRvY1Byb3Bz L2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhANcAKYSkAQAAXQMAABAAAAAAAAAAAAAAAAAAumkAAGRv Y1Byb3BzL2FwcC54bWxQSwUGAAAAAA4ADgCyAwAAlGwAAAAA ------_=_NextPart_001_01CBE726.2A1E6FA0-- From zhang.fei3@zte.com.cn Sun Mar 20 21:19:25 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B783B3A65A5; Sun, 20 Mar 2011 21:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.712 X-Spam-Level: X-Spam-Status: No, score=-100.712 tagged_above=-999 required=5 tests=[AWL=1.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 zG5p1LLKOwro; Sun, 20 Mar 2011 21:19:24 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 803EA3A6405; Sun, 20 Mar 2011 21:19:23 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35102043691617; Mon, 21 Mar 2011 12:18:31 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 84746.6608455112; Mon, 21 Mar 2011 12:20:17 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p2L4K6Fc020799; Mon, 21 Mar 2011 12:20:07 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) To: matthew.bocci@alcatel-lucent.com, swallow@cisco.com, eric.gray@ericsson.com, loa.andersson@ericsson.com, lberger@labn.net, lufang@cisco.com, nabil.n.bitar@verizon.com, , , MIME-Version: 1.0 X-KeepSent: 3561E763:B9BE287F-4825785A:000F8990; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Mon, 21 Mar 2011 12:20:12 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-21 12:20:07, Serialize complete at 2011-03-21 12:20:07 Content-Type: multipart/alternative; boundary="=_alternative 0017CE3C4825785A_=" X-MAIL: mse02.zte.com.cn p2L4K6Fc020799 Subject: [mpls] Query on the mismatch of draft-ietf-mpls-tp-identifiers-04 and draft-ietf-ccamp-mpls-tp-cp-framework-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 04:19:25 -0000 This is a multipart message in MIME format. --=_alternative 0017CE3C4825785A_= Content-Type: text/plain; charset="US-ASCII" Hi all I have read the draft draft-ietf-mpls-tp-identifiers-04 recently, and the identifer of a co-routed bidirectioanl LSP is described in section 5.2.1, whose format is: East-Node_ID::East-Tunnel_Num::West-Node_ID::West-Tunnel_Num::LSP_Num I agree that the introduction of West-Tunnel_Num is convenient for the acess of bidirectional services, which is described clearly in the first paragraph of secion 5:(A transport service may be composed of multiple LSPs. Further the LSPs providing a service may change over time due to protection and restoration events. In order to clearly identify the service we use the term "MPLS-TP Tunnel" or simply "tunnel" for a service provided by (for example) a working LSP and protected by a protection LSP.) The establishment of co-routed bidirectional LSP is based on the [RFC3473], but the current solution is not enough if West_Tunnel_Num is introduced. (draft-ietf-ccamp-mpls-tp-cp-framework-06 did not catch the gaps up to now.) Following is the format of the Session Object, Sender Template Object, and Session Attribute Object (cited from RFC3209 for reference) Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel end point address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_Type = 8 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SESSION_ATTRIBUTE class = 207, LSP_TUNNEL C-Type = 7 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Prio | Holding Prio | Flags | Name Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Session Name (NULL padded display string) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As we can see, there is no field to fill the West-Tunnel_Num. Fortunately, this can be easily achieved by defining a new C-type in Session Class. For example, the format for the new C-type is below (of course, a new defined object is possible): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel end point address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | West-Tunnel_Num | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In conclusion: (1) The West-Tunnel_Num defined in draft-ietf-mpls-tp-identifiers-04 is useful, but draft-ietf-ccamp-mpls-tp-cp-framework-06 SHOULD catch the gaps. (2) The establishment of MPLS-TP co-routed bidirectional SHOULD be described cleary by a individual document or any other existing documents. Just my two cents Fei --=_alternative 0017CE3C4825785A_= Content-Type: text/html; charset="US-ASCII"
      Hi all

      I have read the draft draft-ietf-mpls-tp-identifiers-04 recently, and the identifer of a co-routed bidirectioanl LSP is described in section 5.2.1, whose format is: East-Node_ID::East-Tunnel_Num::West-Node_ID::West-Tunnel_Num::LSP_Num

      I agree that the introduction of West-Tunnel_Num is convenient for the acess of bidirectional services, which is described clearly in the first paragraph of secion 5:(A transport service may be composed of multiple LSPs. Further the LSPs providing a service may change over time due to protection and restoration events.  In order to clearly identify the service we use the term "MPLS-TP Tunnel" or simply "tunnel" for a service provided by (for example) a working LSP and protected by a protection LSP.)

      The establishment of co-routed bidirectional LSP is based on the [RFC3473], but the current solution is not enough if West_Tunnel_Num is introduced. (draft-ietf-ccamp-mpls-tp-cp-framework-06 did not catch the gaps up to now.)

      Following is the format of the Session Object, Sender Template Object, and Session Attribute Object (cited from RFC3209 for reference)

         Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7  

        0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   IPv4 tunnel end point address               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  MUST be zero                 |      Tunnel ID                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Extended Tunnel ID                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_Type = 8

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   IPv4 tunnel sender address                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  MUST be zero                 |            LSP ID             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


         SESSION_ATTRIBUTE class = 207, LSP_TUNNEL C-Type = 7

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Setup Prio  | Holding Prio  |     Flags     |  Name Length  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        //          Session Name      (NULL padded display string)      //
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      As we can see, there is no field to fill the West-Tunnel_Num. Fortunately, this can be easily achieved by defining a new C-type in Session Class. For example,

      the format for the new C-type is below (of course, a new defined object is possible):

        0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   IPv4 tunnel end point address               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  West-Tunnel_Num              |      Tunnel ID                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Extended Tunnel ID                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      In conclusion:

      (1) The West-Tunnel_Num defined in draft-ietf-mpls-tp-identifiers-04 is useful, but draft-ietf-ccamp-mpls-tp-cp-framework-06 SHOULD catch the gaps.

      (2) The establishment of MPLS-TP co-routed bidirectional SHOULD be described cleary by a individual document or any other existing documents.

      Just my two cents

      Fei --=_alternative 0017CE3C4825785A_=-- From gregimirsky@gmail.com Sun Mar 20 22:35:44 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2BA73A66B4 for ; Sun, 20 Mar 2011 22:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 g3ggcDJpBjAs for ; Sun, 20 Mar 2011 22:35:42 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2EDAB3A67AF for ; Sun, 20 Mar 2011 22:35:42 -0700 (PDT) Received: by iwl42 with SMTP id 42so7138130iwl.31 for ; Sun, 20 Mar 2011 22:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=fnELAQo8iOoTen65U6PK+daN4PFHb8bP8PZoXcbj2LA=; b=m73ZWn2ylPiEMDaYv+hnJhaZddiTN7zff8bJ8W79V9+crFVU/MdqKmPwSDWpIlc7oE hVRuvDUiF0qPsukGLSwy7zvF47DJtWgcGrYYroXX+4imV5QlX13GVh08IJuc70YHoeta Dintj+CbdKwrfrr+w8m7ZPa6uJg75/Lkwml88= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FhjhuLUzImJmHr/GxQ0DfAvrgdYXEd70/rw5SlQh9yBvdxuDuXEY/TQPUe/kgrh5g/ 4rmO0rKvF415o2Uq/qDXSkSRGV4orCtYWnxdZX8J/mY+zD63Z0aNECZm1+xr6mxz+3t5 8LMxlZ+foieAcfx0wUlRvlrJJKC4IPmkWD/HE= MIME-Version: 1.0 Received: by 10.42.156.8 with SMTP id x8mr6294159icw.126.1300685834296; Sun, 20 Mar 2011 22:37:14 -0700 (PDT) Received: by 10.231.17.198 with HTTP; Sun, 20 Mar 2011 22:37:14 -0700 (PDT) Date: Sun, 20 Mar 2011 22:37:14 -0700 Message-ID: From: Greg Mirsky To: Nitin Bahadur , Rahul Aggarwal , Sami Boutros , Eric Gray , mpls@ietf.org Content-Type: multipart/alternative; boundary=90e6ba6e8ba01e1d7d049ef78524 Subject: [mpls] Questions on draft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 05:35:45 -0000 --90e6ba6e8ba01e1d7d049ef78524 Content-Type: text/plain; charset=ISO-8859-1 Dear Authors and All, I've got to ask couple questions related to the Destination Address TLV. - Section 2.2.3 mandates that only single Destination Address TLV might be present in on-demand Echo Request. I assume that it is applicable to p2p as well as p2mp MPLS-TP LSPs. If that is the case, then would the limiting number of Destination TLV in on-demand CV, for p2mp LSP, equal to use of P2MP Responder Identifier TLV defined in draft-ietf-mpls-p2mp-lsp-ping-16? - Can these two be used in the same Echo request? - And does MPLS-TP limits modes of responding to Echo request sent over p2mp LSP i.e. response from a single egress? Regards, Greg --90e6ba6e8ba01e1d7d049ef78524 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors and All,
      I've got to ask couple questions related to th= e Destination Address TLV.
      • Section 2.2.3 mandates that only sin= gle Destination Address TLV might be present in on-demand Echo Request. I a= ssume that it is applicable to p2p as well as p2mp MPLS-TP LSPs. If that is= the case, then would the limiting number of Destination TLV in on-demand C= V, for p2mp LSP, equal to use of=A0 P2MP Responder Identifier TLV defined i= n draft-ietf-mpls-p2mp-lsp-ping-16?
      • Can these two be used in the same Echo request?
      • And d= oes MPLS-TP limits modes of responding to Echo request sent over p2mp LSP i= .e. response from a single egress?

      Regards,
      Greg
      --90e6ba6e8ba01e1d7d049ef78524-- From alessandro.dalessandro@telecomitalia.it Mon Mar 21 02:03:59 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76CA3A67F5 for ; Mon, 21 Mar 2011 02:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 dhEBJn7IiI2R for ; Mon, 21 Mar 2011 02:03:58 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by core3.amsl.com (Postfix) with ESMTP id 4E6F03A6783 for ; Mon, 21 Mar 2011 02:03:58 -0700 (PDT) Received: from grfhub701rm001.griffon.local (10.19.3.8) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 21 Mar 2011 10:05:25 +0100 Received: from GRFMBX702RM001.griffon.local ([10.19.3.19]) by grfhub701rm001.griffon.local ([10.19.9.234]) with mapi; Mon, 21 Mar 2011 10:05:25 +0100 From: D'Alessandro Alessandro Gerardo To: John E Drake , "mpls@ietf.org" Date: Mon, 21 Mar 2011 10:05:22 +0100 Thread-Topic: draft-tsb-mpls-tp-ach-ptn Thread-Index: AcvfnOeVV3ZPtvhwS+WvdnOPEqon7QF2jZowAAGaJ4AAijy3IA== Message-ID: References: <52981DB05D3C5247A12D0AEE309F3CC201EB24B1CBBC@INOAVREX11.ptin.corpPT.com> <5E893DB832F57341992548CDBB33316399F1DA7062@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB33316399F1DA7062@EMBX01-HQ.jnpr.net> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Rui Costa Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 09:04:00 -0000 Hi John, This is a formal request from the ITU-T and therefore should be considered = promptly. As you are aware, approval of the G.8113.1 is dependent on having= an ACh code point assigned. I would suggest having a very open discussion that can help making the righ= t decision. It is also worth because I think the majority of the participants at the IE= TF meeting were not present at the last ITU-T meeting and therefore it is a= ppropriate to make them aware of the overall ongoing discussions... rationa= le, technical reasons, operational reasons, etc. to collect their feedback. One further point worth noting is that the reason that approval process wil= l be longer than normal is that some people wrongly asserted that the ACh c= ode point (a protocol identifier) impact naming and numbering and therefore= is a "regulatory concern". We should correct this error in classification. Best regards, Alessandro ------------------------------------------------------------------ Telecom Italia Alessandro D'Alessandro Transport & OPB Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net] Sent: venerd=EC 18 marzo 2011 16.09 To: D'Alessandro Alessandro Gerardo; mpls@ietf.org; Rui Costa Subject: RE: draft-tsb-mpls-tp-ach-ptn What is the rush? The ITU document for which this code point has been requ= ested has just started a long and arduous approval process from which it ma= y never emerge. Wouldn't it make more sense to delay discussion of this dr= aft until the fate of the ITU document is more certain? I.e., why allocate a code point to an ITU document that may never get appro= ved? Sent from my iPhone > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > D'Alessandro Alessandro Gerardo > Sent: Friday, March 18, 2011 7:23 AM > To: mpls@ietf.org; Rui Costa > Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn > > Definitely it's worth to have a discussion on draft-tsb-mpls-tp-ach-ptn > during the meeting in Prague. I support the request for a time slot > allocation. > > Best regards, > Alessandro > > ------------------------------------------------------------------ > Telecom Italia > Alessandro D'Alessandro > Transport & OPB Innovation > Via Reiss Romoli, 274 - 10148 Torino > phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07 > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rui Costa > Sent: venerd=EC 11 marzo 2011 4.32 > To: mpls@ietf.org > Subject: [mpls] draft-tsb-mpls-tp-ach-ptn > > Hello, > > The draft provided by the TSB draft-tsb-mpls-tp-ach-ptn requests the > allocation of an Associated Channel Type value that will allow ITU-T to > develop OAM tools required to address the needs identified by some ITU- > T members. Allocation of this value will make more efficient use of > resources of both IETF and ITU-T. The use of this associated channel > type fully complies with the framework and architecture for MPLS-TP. > > The draft also describes the cases where networks that run the ITU > defined OAM tools are interconnected to networks that run the IETF > defined OAM tools. In most cases it is a client/server relationship and > no interworking is required. If a LSP or PW originates in one domain > and terminates in the other domain then the IETF OAM tools must be > used. > > This draft should be discussed in Prague. > > Best Regards, > Rui > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. > Dissemination, copying, printing or use by anybody else is > unauthorised. If you are not the intended recipient, please delete this > message and any attachments and advise the sender by return e-mail, > Thanks. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From martin.vigoureux@alcatel-lucent.com Mon Mar 21 03:01:28 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8E13A6810 for ; Mon, 21 Mar 2011 03:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 FY2pArdZJP5i for ; Mon, 21 Mar 2011 03:01:27 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 5D3373A680C for ; Mon, 21 Mar 2011 03:01:27 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p2LA2duC025328 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 21 Mar 2011 11:02:56 +0100 Received: from [172.27.205.171] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 21 Mar 2011 11:02:48 +0100 Message-ID: <4D872247.6040701@alcatel-lucent.com> Date: Mon, 21 Mar 2011 11:02:47 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "MPLS @ IETF" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [mpls] IETF 80 - MPLS Sessions - Preliminary Agenda X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 10:01:28 -0000 All, you can find the preliminary agenda at: http://www.ietf.org/proceedings/80/agenda/mpls.txt It is still draft. Please note that draft-tsb-mpls-tp-ach-ptn might be discussed at the rtgarea meeting (to be confirmed). best regards, martin From yang.jian90@zte.com.cn Fri Mar 18 01:50:08 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25FA83A679C; Fri, 18 Mar 2011 01:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.791 X-Spam-Level: X-Spam-Status: No, score=-92.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 yIQBJtwAgqin; Fri, 18 Mar 2011 01:50:06 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 137C93A680B; Fri, 18 Mar 2011 01:50:04 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35104902023453; Fri, 18 Mar 2011 16:48:19 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84746.8048794811; Fri, 18 Mar 2011 16:51:26 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p2I8pIPM012188; Fri, 18 Mar 2011 16:51:18 +0800 (GMT-8) (envelope-from yang.jian90@zte.com.cn) In-Reply-To: To: chair@ietf.org, iab@iab.org, iab-chair@iab.org, iesg@ietf.org, mpls@ietf.org, mpls-bounces@ietf.org, rcallon@juniper.net, stbryant@cisco.com X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: yang.jian90@zte.com.cn Date: Fri, 18 Mar 2011 16:51:17 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-18 16:51:19 MIME-Version: 1.0 Content-type: text/plain; charset=GB2312 Content-transfer-encoding: base64 X-MAIL: mse01.zte.com.cn p2I8pIPM012188 X-Mailman-Approved-At: Mon, 21 Mar 2011 08:24:07 -0700 Cc: Malcolm.BETTS@zte.com.cn Subject: [mpls] =?gb2312?b?tPC4tDogUmU6ICBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQs?= =?gb2312?b?ICJMUzI5MyAtIFJlcXVlc3QgZm9yIEctQUNoIGNoYW5uZWwgY29kZXBvaW50?= =?gb2312?b?IHRvIHN1cHBvcnQgdHJhZGl0aW9uYWwgdHJhbnNwb3J0IGVudmlyb25tZW50?= =?gb2312?b?Ig==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 08:50:08 -0000 SGkgQWxsLA0KDQpJIHN1cHBvcnQgdG8gcHJlc2VudCB0aGlzIGltcG9ydGFudCBpc3N1ZSBpbiBN UExTIFdHIG1lZXRpbmcgYW5kIGxldCBhbGwNCnRoZSBwZW9wbGUgaW50ZXJlc3RlZCBpbiBNUExT LVRQIGtub3cgaXQuDQoNCg0KDQpCUiwNCkppYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCg0KDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICBN YWxjb2xtLkJFVFRTQCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KICAgICAgICAgICAgIHp0ZS5jb20uY24gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgt6K8/sjLOiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIMrVvP7IyyANCiAgICAgICAgICAg ICBtcGxzLWJvdW5jZXNAaSAgICAgICAgIG1wbHNAaWV0Zi5vcmcgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KICAgICAgICAgICAgIGV0Zi5vcmcgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgILOty80gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBtcGxzQGlldGYub3JnLCBpYWItY2hhaXJAaWFiLm9yZywgICAgICANCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNoYWlyQGlldGYub3JnLCBpZXNnQGlldGYub3Jn LCAgICAgICAgIA0KICAgICAgICAgICAgIDIwMTEtMDMtMTggICAgICAgICAgICAgcmNhbGxvbkBq dW5pcGVyLm5ldCwgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgMDU6MDYgICAgICAg ICAgICAgICAgICBzdGJyeWFudEBjaXNjby5jb20sIGlhYkBpYWIub3JnICAgICAgICANCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICDW98ziIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmU6IFtt cGxzXSBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICAgICAgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAiTFMyOTMgLSBSZXF1ZXN0IGZvciBHLUFDaCBjaGFubmVsICAgICANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvZGVwb2ludCB0byBzdXBwb3J0IHRy YWRpdGlvbmFsICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHJh bnNwb3J0IGVudmlyb25tZW50IiAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KDQoNCg0KVGhp cyBsaWFpc29uIGFuZCBkcmFmdC10c2ItbXBscy10cC1hY2gtcHRuIHNob3VsZCBiZSBkaXNjdXNz ZWQgZHVyaW5nIHRoZQ0KbmV4dCBJRVRGIG1lZXRpbmcuICBJIGhhdmUgcmVxdWVzdCBhIHNsb3Qg Zm9yIGEgcHJlc2VudGF0aW9uIGluIHRoZSBNUExTIFdHDQptZWV0aW5nLg0KDQpSZWdhcmRzLA0K DQpNYWxjb2xtDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogR3JlZyBKb25lcyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAo SVRVLVQgU0cgMTUpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KIDx0c2JzZzE1QGl0dS4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVG8gDQogaW50PiAgICAgICAgICAgICAg IGNoYWlyQGlldGYub3JnLCBpYWItY2hhaXJAaWFiLm9yZywgICAgICAgICAgICAgICAgICAgICAN CiBTZW50IGJ5OiAgICAgICAgICAgcmNhbGxvbkBqdW5pcGVyLm5ldCwgc3dhbGxvd0BjaXNjby5j b20sIGxvYUBwaS5udSAgICAgIA0KIG1wbHMtYm91bmNlc0AgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2MgDQogaWV0Zi5vcmcgICAgICAg ICAgIG1wbHNAaWV0Zi5vcmcsIGhpcm9zaGkub3RhQGl0dS5pbnQsICAgICAgICAgICAgICAgICAg ICANCiAgICAgICAgICAgICAgICAgICAgZ3JlZy5qb25lc0BpdHUuaW50LCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICBTdGV2ZS5Ucm93YnJp ZGdlQGFsY2F0ZWwtbHVjZW50LmNvbSwgICAgICAgICAgICAgICAgICAgDQogMTQvMDMvMjAxMSAg ICAgICAgIHlvaWNoaS5tYWVkYUB0dGMub3IuanAsIGlhYkBpYWIub3JnLCBwYWZAY2lzY28uY29t LCAgICANCiAxMTo0NiBBTSAgICAgICAgICAgaWVzZ0BpZXRmLm9yZywgdHNic2cxNUBpdHUuaW50 LCBzdGJyeWFudEBjaXNjby5jb20sICAgIA0KICAgICAgICAgICAgICAgICAgICBhZHJpYW4uZmFy cmVsQGh1YXdlaS5jb20gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg U3ViamVjdCANCiAgICAgUGxlYXNlICAgICAgICAgW21wbHNdIE5ldyBMaWFpc29uIFN0YXRlbWVu dCwgIkxTMjkzIC0gUmVxdWVzdCBmb3IgICAgIA0KICAgcmVzcG9uZCB0byAgICAgICBHLUFDaCBj aGFubmVsIGNvZGVwb2ludCB0byBzdXBwb3J0IHRyYWRpdGlvbmFsICAgICAgICAgDQogIHRzYnNn MTVAaXR1LiAgICAgIHRyYW5zcG9ydCBlbnZpcm9ubWVudCIgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCiAgICAgIGludCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNCg0KDQoNCg0KVGl0bGU6 IExTMjkzIC0gUmVxdWVzdCBmb3IgRy1BQ2ggY2hhbm5lbCBjb2RlcG9pbnQgdG8gc3VwcG9ydCB0 cmFkaXRpb25hbA0KdHJhbnNwb3J0IGVudmlyb25tZW50DQpTdWJtaXNzaW9uIERhdGU6IDIwMTEt MDMtMTQNClVSTCBvZiB0aGUgSUVURiBXZWIgcGFnZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvcHVibGljL2xpYWlzb25fZGV0YWlsLmNnaT9kZXRhaWxfaWQ9MTAzMw0KUGxlYXNlIHJl cGx5IGJ5IDIwMTEtMDQtMDENCg0KRnJvbTogR3JlZyBKb25lcyhJVFUtVCBTRyAxNSkgPHRzYnNn MTVAaXR1LmludD4NClRvOiBJRVNHLCBJQUIsIElFVEYgTVBMUyBXRw0KKGNoYWlyQGlldGYub3Jn LGlhYi1jaGFpckBpYWIub3JnLHJjYWxsb25AanVuaXBlci5uZXQsc3dhbGxvd0BjaXNjby5jb20s bG9hQHBpLm51KQ0KDQpDYzogcGFmQGNpc2NvLmNvbQ0Kc3RicnlhbnRAY2lzY28uY29tDQphZHJp YW4uZmFycmVsQGh1YXdlaS5jb20NCm1wbHNAaWV0Zi5vcmcNCmlhYkBpYWIub3JnDQppZXNnQGll dGYub3JnDQp5b2ljaGkubWFlZGFAdHRjLm9yLmpwDQpTdGV2ZS5Ucm93YnJpZGdlQGFsY2F0ZWwt bHVjZW50LmNvbQ0KUmVwb25zZSBDb250YWN0OiB0c2JzZzE1QGl0dS5pbnQNCmdyZWcuam9uZXNA aXR1LmludA0KaGlyb3NoaS5vdGFAaXR1LmludA0KVGVjaG5pY2FsIENvbnRhY3Q6IHlvaWNoaS5t YWVkYUB0dGMub3IuanANClB1cnBvc2U6IEZvciBhY3Rpb24NCkJvZHk6IEF0IHRoZSBGZWJydWFy eSBtZWV0aW5nIG9mIElUVS1UIFN0dWR5IEdyb3VwIDE1LCB3ZSBoYXZlIHJlYWNoZWQgdGhlDQpj b25jbHVzaW9uIHRoYXQgdGhlIG5lZWRzIG9mIG1hbnkgb2YgdGhlIG9wZXJhdG9ycyBwYXJ0aWNp cGF0aW5nIGluIHRoaXMNCndvcmsgYXJlIG5vdCBtZXQgYnkgdGhlIHNvbHV0aW9ucyBjdXJyZW50 bHkgdW5kZXIgZGV2ZWxvcG1lbnQgaW4gdGhlIElFVEYuDQpUaGVyZWZvcmUsIHdlIGhhdmUgZGVj aWRlZCB0byBwcm9ncmVzcyB0aGlzIHdvcmsgdGhyb3VnaCBJVFUtVA0KUmVjb21tZW5kYXRpb25z LiBXZSByZXF1ZXN0IHRoYXQgdGhlIElFVEYgcHJvdmlkZSB0aGUgbmVjZXNzYXJ5IEctQUNoDQpj b2RlcG9pbnQgYWxsb2NhdGlvbnMgdG8gc3VwcG9ydCB0aGlzIHdvcmsgdGhyb3VnaCBhZHZhbmNl bWVudCBvZg0KZHJhZnQtdHNiLW1wbHMtdHAtYWNoLXB0bi4gTm90ZSB0aGF0IHdlIGhhdmUgZG9u ZSBhZGRpdGlvbmFsIHdvcmsgZHVyaW5nDQp0aGlzIG1lZXRpbmcgdG8gbW9yZSBjbGVhcmx5IGRl ZmluZSB0aGUgbmV0d29yayBlbnZpcm9ubWVudCBmb3IgdGhpcw0KYXBwbGljYXRpb24gYW5kIHBy b2R1Y2VkIGEgc2NvcGUgb2YgYXBwbGljYWJpbGl0eSBpbiBURDUyMi9XUDMgKGF0dGFjaGVkKS4N CmRyYWZ0LXRzYi1tcGxzLXRwLWFjaC1wdG4gd2lsbCBiZSB1cGRhdGVkIHRvIGluY2x1ZGUgdGhp cyBzY29wZSBzdGF0ZW1lbnQuDQpUaGUgdXNlIG9mIHRoaXMgRy1BQ2ggY29kZSBwb2ludCB3aWxs IGZ1bGx5IGNvbXBseSB3aXRoIHRoZSBmcmFtZXdvcmsgYW5kDQphcmNoaXRlY3R1cmUgZm9yIE1Q TFMtVFAgdGhhdCBpcyBjdXJyZW50bHkgYmVpbmcgZGVmaW5lZCBieSBJRVRGIGluDQpjb29wZXJh dGlvbiB3aXRoIElUVS1ULiAgQWxsb2NhdGlvbiBvZiB0aGlzIGNvZGUgcG9pbnQgd2lsbCBhbGxv dyBJVFUtVCB0bw0KZGV2ZWxvcCB0aGUgdG9vbHMgcmVxdWlyZWQgdG8gYWRkcmVzcyB0aGUgdW5p cXVlIG5lZWRzIG9mIHRoZSB0cmFuc3BvcnQNCm5ldHdvcmsgYW5kIHdpbGwgbWFrZSBtb3JlIGVm ZmljaWVudCB1c2Ugb2YgdGhlIHJlc291cmNlcyBvZiBib3RoDQpvcmdhbml6YXRpb25zLiAgUHJv dmlkaW5nIHRoaXMgY29kZXBvaW50IHdpbGwgYWxsb3cgSVRVLVQgdG8gc2F0aXNmeSB0aGUNCmlt bWVkaWF0ZSBuZWVkcyBleHByZXNzZWQgYXQgdGhlIHJlY2VudCBTdHVkeSBHcm91cCAxNSBtZWV0 aW5nIHJlY29nbml6aW5nDQp0aGF0IGl0IGlzIHZlcnkgaW1wb3J0YW50IGZvciBJVFUtVCBhbmQg SUVURiB0byBwcm92aWRlIHRpbWVseSBzb2x1dGlvbnMgdG8NCm1haW50YWluIHN1cHBvcnQgZm9y IHRoZSBNUExTLVRQIGFncmVlbWVudHMuDQoNCkF0dGFjaDogVEQ1MjIvV1AzIGFuZCBDLTExMjQg QXBwZW5kaXggSS4NCkF0dGFjaG1lbnQocyk6DQogICAgTFMyOTMgLSBSZXF1ZXN0IGZvciBHLUFD aCBjaGFubmVsIGNvZGVwb2ludCB0byBzdXBwb3J0IHRyYWRpdGlvbmFsDQp0cmFuc3BvcnQgZW52 aXJvbm1lbnQgLSBwZGYgYm9keSAoDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvY3Vt ZW50cy9MSUFJU09OL2ZpbGUxMjA4LnBkZikNCiAgICBMUzI5MyAtIFJlcXVlc3QgZm9yIEctQUNo IGNoYW5uZWwgY29kZXBvaW50IHRvIHN1cHBvcnQgdHJhZGl0aW9uYWwNCnRyYW5zcG9ydCBlbnZp cm9ubWVudCAtIHBkZiBURDUyMi9XUDMgKA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2N1bWVudHMvTElBSVNPTi9maWxlMTIwOS5wZGYpDQogICAgTFMyOTMgLSBSZXF1ZXN0IGZvciBH LUFDaCBjaGFubmVsIGNvZGVwb2ludCB0byBzdXBwb3J0IHRyYWRpdGlvbmFsDQp0cmFuc3BvcnQg ZW52aXJvbm1lbnQgLSBwZGYgQy0xMTI0IEFwcGVuZGl4IEkgKA0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2N1bWVudHMvTElBSVNPTi9maWxlMTIxMC5wZGYpDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxp c3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBscw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscw0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNl OiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVy dHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24g aXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8g bWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNv bnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBh bnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20g dGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3 cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBz ZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3Bh bSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== From yang.jian90@zte.com.cn Fri Mar 18 02:00:14 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C9263A680C; Fri, 18 Mar 2011 02:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.791 X-Spam-Level: X-Spam-Status: No, score=-92.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 0-YGtoR7M89e; Fri, 18 Mar 2011 02:00:11 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id CDC533A679C; Fri, 18 Mar 2011 02:00:08 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35104902023453; Fri, 18 Mar 2011 16:59:16 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84746.8048794811; Fri, 18 Mar 2011 16:59:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p2I8xgte028605; Fri, 18 Mar 2011 16:59:42 +0800 (GMT-8) (envelope-from yang.jian90@zte.com.cn) In-Reply-To: To: chair@ietf.org, iab@iab.org, iab-chair@iab.org, iesg@ietf.org, mpls@ietf.org, mpls-bounces@ietf.org, rcallon@juniper.net, stbryant@cisco.com, Malcolm.BETTS@zte.com.cn X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: yang.jian90@zte.com.cn Date: Fri, 18 Mar 2011 16:59:41 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-18 16:59:43 MIME-Version: 1.0 Content-type: text/plain; charset=GB2312 Content-transfer-encoding: base64 X-MAIL: mse01.zte.com.cn p2I8xgte028605 X-Mailman-Approved-At: Mon, 21 Mar 2011 08:24:07 -0700 Subject: [mpls] =?gb2312?b?tPC4tDogUmU6ICBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQs?= =?gb2312?b?ICJMUzI5MyAtIFJlcXVlc3QgZm9yIEctQUNoIGNoYW5uZWwgY29kZXBvaW50?= =?gb2312?b?IHRvIHN1cHBvcnQgdHJhZGl0aW9uYWwgdHJhbnNwb3J0IGVudmlyb25tZW50?= =?gb2312?b?Ig==?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 09:00:14 -0000 SGkgQWxso6wNCg0KSSBzdXBwb3J0IHRvIHByZXNlbnQgdGhpcyBpbXBvcnRhbnQgaXNzdWUgaW4g TVBMUyBXRyBtZWV0aW5nIGFuZCBsZXQgQWxsDQp0aGUgcGVvcGxlIGludGVyZXN0ZWQgaW4gTVBM Uy1UUCBrbm93IGl0Lg0KDQpCUiwNCg0KSmlhbg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAg TWFsY29sbS5CRVRUU0AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCiAgICAgICAgICAgICB6dGUuY29tLmNuICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgILeivP7IyzogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDK1bz+yMsgDQogICAgICAgICAg ICAgbXBscy1ib3VuY2VzQGkgICAgICAgICBtcGxzQGlldGYub3JnICAgICAgICAgICAgICAgICAg ICAgICAgICANCiAgICAgICAgICAgICBldGYub3JnICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICCzrcvNIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgbXBsc0BpZXRmLm9yZywgaWFiLWNoYWlyQGlhYi5vcmcsICAgICAgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjaGFpckBpZXRmLm9yZywgaWVzZ0BpZXRmLm9y ZywgICAgICAgICANCiAgICAgICAgICAgICAyMDExLTAzLTE4ICAgICAgICAgICAgIHJjYWxsb25A anVuaXBlci5uZXQsICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgIDA1OjA2ICAgICAg ICAgICAgICAgICAgc3RicnlhbnRAY2lzY28uY29tLCBpYWJAaWFiLm9yZyAgICAgICAgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAg1vfM4iANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJlOiBb bXBsc10gTmV3IExpYWlzb24gU3RhdGVtZW50LCAgICAgIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIkxTMjkzIC0gUmVxdWVzdCBmb3IgRy1BQ2ggY2hhbm5lbCAgICAgDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb2RlcG9pbnQgdG8gc3VwcG9ydCB0 cmFkaXRpb25hbCAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRy YW5zcG9ydCBlbnZpcm9ubWVudCIgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNCg0KDQoNClRo aXMgbGlhaXNvbiBhbmQgZHJhZnQtdHNiLW1wbHMtdHAtYWNoLXB0biBzaG91bGQgYmUgZGlzY3Vz c2VkIGR1cmluZyB0aGUNCm5leHQgSUVURiBtZWV0aW5nLiAgSSBoYXZlIHJlcXVlc3QgYSBzbG90 IGZvciBhIHByZXNlbnRhdGlvbiBpbiB0aGUgTVBMUyBXRw0KbWVldGluZy4NCg0KUmVnYXJkcywN Cg0KTWFsY29sbQ0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KIEdyZWcgSm9uZXMgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQog KElUVS1UIFNHIDE1KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCiA8dHNic2cxNUBpdHUuICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRvIA0KIGludD4gICAgICAgICAgICAg ICBjaGFpckBpZXRmLm9yZywgaWFiLWNoYWlyQGlhYi5vcmcsICAgICAgICAgICAgICAgICAgICAg DQogU2VudCBieTogICAgICAgICAgIHJjYWxsb25AanVuaXBlci5uZXQsIHN3YWxsb3dAY2lzY28u Y29tLCBsb2FAcGkubnUgICAgICANCiBtcGxzLWJvdW5jZXNAICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNjIA0KIGlldGYub3JnICAgICAg ICAgICBtcGxzQGlldGYub3JnLCBoaXJvc2hpLm90YUBpdHUuaW50LCAgICAgICAgICAgICAgICAg ICAgDQogICAgICAgICAgICAgICAgICAgIGdyZWcuam9uZXNAaXR1LmludCwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgU3RldmUuVHJvd2Jy aWRnZUBhbGNhdGVsLWx1Y2VudC5jb20sICAgICAgICAgICAgICAgICAgIA0KIDE0LzAzLzIwMTEg ICAgICAgICB5b2ljaGkubWFlZGFAdHRjLm9yLmpwLCBpYWJAaWFiLm9yZywgcGFmQGNpc2NvLmNv bSwgICAgDQogMTE6NDYgQU0gICAgICAgICAgIGllc2dAaWV0Zi5vcmcsIHRzYnNnMTVAaXR1Lmlu dCwgc3RicnlhbnRAY2lzY28uY29tLCAgICANCiAgICAgICAgICAgICAgICAgICAgYWRyaWFuLmZh cnJlbEBodWF3ZWkuY29tICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFN1YmplY3QgDQogICAgIFBsZWFzZSAgICAgICAgIFttcGxzXSBOZXcgTGlhaXNvbiBTdGF0ZW1l bnQsICJMUzI5MyAtIFJlcXVlc3QgZm9yICAgICANCiAgIHJlc3BvbmQgdG8gICAgICAgRy1BQ2gg Y2hhbm5lbCBjb2RlcG9pbnQgdG8gc3VwcG9ydCB0cmFkaXRpb25hbCAgICAgICAgIA0KICB0c2Jz ZzE1QGl0dS4gICAgICB0cmFuc3BvcnQgZW52aXJvbm1lbnQiICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQogICAgICBpbnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQoNCg0KDQoNClRpdGxl OiBMUzI5MyAtIFJlcXVlc3QgZm9yIEctQUNoIGNoYW5uZWwgY29kZXBvaW50IHRvIHN1cHBvcnQg dHJhZGl0aW9uYWwNCnRyYW5zcG9ydCBlbnZpcm9ubWVudA0KU3VibWlzc2lvbiBEYXRlOiAyMDEx LTAzLTE0DQpVUkwgb2YgdGhlIElFVEYgV2ViIHBhZ2U6DQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL3B1YmxpYy9saWFpc29uX2RldGFpbC5jZ2k/ZGV0YWlsX2lkPTEwMzMNClBsZWFzZSBy ZXBseSBieSAyMDExLTA0LTAxDQoNCkZyb206IEdyZWcgSm9uZXMoSVRVLVQgU0cgMTUpIDx0c2Jz ZzE1QGl0dS5pbnQ+DQpUbzogSUVTRywgSUFCLCBJRVRGIE1QTFMgV0cNCihjaGFpckBpZXRmLm9y ZyxpYWItY2hhaXJAaWFiLm9yZyxyY2FsbG9uQGp1bmlwZXIubmV0LHN3YWxsb3dAY2lzY28uY29t LGxvYUBwaS5udSkNCg0KQ2M6IHBhZkBjaXNjby5jb20NCnN0YnJ5YW50QGNpc2NvLmNvbQ0KYWRy aWFuLmZhcnJlbEBodWF3ZWkuY29tDQptcGxzQGlldGYub3JnDQppYWJAaWFiLm9yZw0KaWVzZ0Bp ZXRmLm9yZw0KeW9pY2hpLm1hZWRhQHR0Yy5vci5qcA0KU3RldmUuVHJvd2JyaWRnZUBhbGNhdGVs LWx1Y2VudC5jb20NClJlcG9uc2UgQ29udGFjdDogdHNic2cxNUBpdHUuaW50DQpncmVnLmpvbmVz QGl0dS5pbnQNCmhpcm9zaGkub3RhQGl0dS5pbnQNClRlY2huaWNhbCBDb250YWN0OiB5b2ljaGku bWFlZGFAdHRjLm9yLmpwDQpQdXJwb3NlOiBGb3IgYWN0aW9uDQpCb2R5OiBBdCB0aGUgRmVicnVh cnkgbWVldGluZyBvZiBJVFUtVCBTdHVkeSBHcm91cCAxNSwgd2UgaGF2ZSByZWFjaGVkIHRoZQ0K Y29uY2x1c2lvbiB0aGF0IHRoZSBuZWVkcyBvZiBtYW55IG9mIHRoZSBvcGVyYXRvcnMgcGFydGlj aXBhdGluZyBpbiB0aGlzDQp3b3JrIGFyZSBub3QgbWV0IGJ5IHRoZSBzb2x1dGlvbnMgY3VycmVu dGx5IHVuZGVyIGRldmVsb3BtZW50IGluIHRoZSBJRVRGLg0KVGhlcmVmb3JlLCB3ZSBoYXZlIGRl Y2lkZWQgdG8gcHJvZ3Jlc3MgdGhpcyB3b3JrIHRocm91Z2ggSVRVLVQNClJlY29tbWVuZGF0aW9u cy4gV2UgcmVxdWVzdCB0aGF0IHRoZSBJRVRGIHByb3ZpZGUgdGhlIG5lY2Vzc2FyeSBHLUFDaA0K Y29kZXBvaW50IGFsbG9jYXRpb25zIHRvIHN1cHBvcnQgdGhpcyB3b3JrIHRocm91Z2ggYWR2YW5j ZW1lbnQgb2YNCmRyYWZ0LXRzYi1tcGxzLXRwLWFjaC1wdG4uIE5vdGUgdGhhdCB3ZSBoYXZlIGRv bmUgYWRkaXRpb25hbCB3b3JrIGR1cmluZw0KdGhpcyBtZWV0aW5nIHRvIG1vcmUgY2xlYXJseSBk ZWZpbmUgdGhlIG5ldHdvcmsgZW52aXJvbm1lbnQgZm9yIHRoaXMNCmFwcGxpY2F0aW9uIGFuZCBw cm9kdWNlZCBhIHNjb3BlIG9mIGFwcGxpY2FiaWxpdHkgaW4gVEQ1MjIvV1AzIChhdHRhY2hlZCku DQpkcmFmdC10c2ItbXBscy10cC1hY2gtcHRuIHdpbGwgYmUgdXBkYXRlZCB0byBpbmNsdWRlIHRo aXMgc2NvcGUgc3RhdGVtZW50Lg0KVGhlIHVzZSBvZiB0aGlzIEctQUNoIGNvZGUgcG9pbnQgd2ls bCBmdWxseSBjb21wbHkgd2l0aCB0aGUgZnJhbWV3b3JrIGFuZA0KYXJjaGl0ZWN0dXJlIGZvciBN UExTLVRQIHRoYXQgaXMgY3VycmVudGx5IGJlaW5nIGRlZmluZWQgYnkgSUVURiBpbg0KY29vcGVy YXRpb24gd2l0aCBJVFUtVC4gIEFsbG9jYXRpb24gb2YgdGhpcyBjb2RlIHBvaW50IHdpbGwgYWxs b3cgSVRVLVQgdG8NCmRldmVsb3AgdGhlIHRvb2xzIHJlcXVpcmVkIHRvIGFkZHJlc3MgdGhlIHVu aXF1ZSBuZWVkcyBvZiB0aGUgdHJhbnNwb3J0DQpuZXR3b3JrIGFuZCB3aWxsIG1ha2UgbW9yZSBl ZmZpY2llbnQgdXNlIG9mIHRoZSByZXNvdXJjZXMgb2YgYm90aA0Kb3JnYW5pemF0aW9ucy4gIFBy b3ZpZGluZyB0aGlzIGNvZGVwb2ludCB3aWxsIGFsbG93IElUVS1UIHRvIHNhdGlzZnkgdGhlDQpp bW1lZGlhdGUgbmVlZHMgZXhwcmVzc2VkIGF0IHRoZSByZWNlbnQgU3R1ZHkgR3JvdXAgMTUgbWVl dGluZyByZWNvZ25pemluZw0KdGhhdCBpdCBpcyB2ZXJ5IGltcG9ydGFudCBmb3IgSVRVLVQgYW5k IElFVEYgdG8gcHJvdmlkZSB0aW1lbHkgc29sdXRpb25zIHRvDQptYWludGFpbiBzdXBwb3J0IGZv ciB0aGUgTVBMUy1UUCBhZ3JlZW1lbnRzLg0KDQpBdHRhY2g6IFRENTIyL1dQMyBhbmQgQy0xMTI0 IEFwcGVuZGl4IEkuDQpBdHRhY2htZW50KHMpOg0KICAgIExTMjkzIC0gUmVxdWVzdCBmb3IgRy1B Q2ggY2hhbm5lbCBjb2RlcG9pbnQgdG8gc3VwcG9ydCB0cmFkaXRpb25hbA0KdHJhbnNwb3J0IGVu dmlyb25tZW50IC0gcGRmIGJvZHkgKA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2N1 bWVudHMvTElBSVNPTi9maWxlMTIwOC5wZGYpDQogICAgTFMyOTMgLSBSZXF1ZXN0IGZvciBHLUFD aCBjaGFubmVsIGNvZGVwb2ludCB0byBzdXBwb3J0IHRyYWRpdGlvbmFsDQp0cmFuc3BvcnQgZW52 aXJvbm1lbnQgLSBwZGYgVEQ1MjIvV1AzICgNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jdW1lbnRzL0xJQUlTT04vZmlsZTEyMDkucGRmKQ0KICAgIExTMjkzIC0gUmVxdWVzdCBmb3Ig Ry1BQ2ggY2hhbm5lbCBjb2RlcG9pbnQgdG8gc3VwcG9ydCB0cmFkaXRpb25hbA0KdHJhbnNwb3J0 IGVudmlyb25tZW50IC0gcGRmIEMtMTEyNCBBcHBlbmRpeCBJICgNCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jdW1lbnRzL0xJQUlTT04vZmlsZTEyMTAucGRmKQ0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBs aXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGlj ZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3Bl cnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9u IGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRv IG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBj b250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQg YW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9t IHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmll d3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwg c2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNw YW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= From gregimirsky@gmail.com Mon Mar 21 16:50:35 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ADCB28C1A6 for ; Mon, 21 Mar 2011 16:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.734 X-Spam-Level: X-Spam-Status: No, score=-2.734 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 XFPDxQJAGNO1 for ; Mon, 21 Mar 2011 16:50:34 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id CE86528C175 for ; Mon, 21 Mar 2011 16:50:33 -0700 (PDT) Received: by vxg33 with SMTP id 33so6348596vxg.31 for ; Mon, 21 Mar 2011 16:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=nLMwwpt8tB6X39iqvpK4vdJLATfe7B5lwRkD7EIqa9A=; b=bptRcNOajMRMK8yarzrBE3Uz/00asdeljXPjip2P8ss33Yia2UL4x36CeYyiRTQDKC Km5Jekx+4XUZqJZjdTiwOEq+2exE00ihd9EkXFUo7AgE6LYjGipqTNOZMRtpbwlIVcd2 xIvcBIRbaBafqaGXhJMPZeU0Fk5LJj27RHTUU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XIhs+2n+7F9OciCkhS7KkIqqRWjF1FBZHsFHLsIPQm32kCaqP+9qDrFMqnXkxeC2Mi BtOwMdWXz7hu5YttGFSwCI65d47/1Phk/W4ypKj4MP9bqe3o/geUMPYbaJ8RPL1mdhK/ pwIDvMjK8w7yOSMIhaMJSFPl16hMGLr0UIppc= MIME-Version: 1.0 Received: by 10.220.88.230 with SMTP id b38mr1315114vcm.247.1300751526150; Mon, 21 Mar 2011 16:52:06 -0700 (PDT) Received: by 10.52.168.6 with HTTP; Mon, 21 Mar 2011 16:52:06 -0700 (PDT) Date: Mon, 21 Mar 2011 16:52:06 -0700 Message-ID: From: Greg Mirsky To: Huaimochen@huawei.com, "So, Ning" , mpls@ietf.org Content-Type: multipart/alternative; boundary=001636310911a842d0049f06d0bc Subject: [mpls] Comment on draft-chen-mpls-p2mp-egress-protection-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 23:50:35 -0000 --001636310911a842d0049f06d0bc Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, please kindly consider my comments and questions to the document before upcoming IETF meeting: - I believe that referring to the presented use case as LSP egress protection is not entirely accurate. The case on the Figure 1 presents service protection case as it provides protection from CE perspective, not from perspective of LSP itself as new egress nodes/PEs being created as result of proposed solution - Much of proposed solution is based on assumption that "previous-hop node" is able to set up a path to a backup egress node for the given egress on p2mp LSP. How the mechanics of the proposed solution changes if the immediate upstream node can not set path to backup/redundant egress? Is it only the previous-hop node can set up redundant egress or any upstream node given that there's OAM session between it and egress node being protected? - Would proposed solution of creating redundant egress nodes be equally applicable to cases when protected egress node is a bud node? - I believe that section 4.3 describes proprietary implementation - Section 4.4 discusses OAM sessions between "previous-hop node" and protected edge node as well as "previous-hop node" and a CE. I assume that the edge node is a downstream node relative to the "previous-hop node" for the given p2mp LSP. If that is the case, then I'd encourage Authors to expand on OAM part to demonstrate what mechanisms, existing or required development, can be used to detect first types of failures mentioned in the document. - The second class of failures described in the Section 4.4 requires, in my view, interworking between service OAM and MPLS LSP OAM. I'd encourage Authors to expand on OAM interworking subject if the proposed solution is intended to address such type of failures as well - Section 4.4 mentions that the "previous-hop node" switches LSP traffic towards redundant egress nodes onto the protecting LSP after it detects or receives signal that the protected egress node have failed. I believe that it is important to address notification toward the CE otherwise switching to a redundant egress node would not restore the service. I hope Authors will find it possible to address my notes before or at the meeting itself. Regards, Greg --001636310911a842d0049f06d0bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors,
      please kindly consider my comments and questions to the do= cument before upcoming IETF meeting:
      • I believe that referring to= the presented use case as LSP egress protection is not entirely accurate. = The case on the Figure 1 presents service protection case as it provides pr= otection from CE perspective, not from perspective of LSP itself as new egr= ess nodes/PEs being created as result of proposed solution
      • Much of proposed solution is based on assumption that "previo= us-hop node" is able to set up a path to a backup egress node for the = given egress on p2mp LSP. How the mechanics of the proposed solution change= s if the immediate upstream node can not set path to backup/redundant egres= s? Is it only the previous-hop node can set up redundant egress or any upst= ream node given that there's OAM session between it and egress node bei= ng protected?
      • Would proposed solution of creating redundant egress nodes be equa= lly applicable to cases when protected egress node is a bud node?
      • I= believe that section 4.3 describes proprietary implementation
      • Section 4.4 discusses OAM sessions between "previous-hop node" an= d protected edge node as well as "previous-hop node" and a CE. I = assume that the edge node is a downstream node relative to the "previo= us-hop node" for the given p2mp LSP. If that is the case, then I'd= encourage Authors to expand on OAM part to demonstrate what mechanisms, ex= isting or required development, can be used to detect first types of failur= es mentioned in the document.
      • The second class of failures described in the Section 4.4 requires, in = my view, interworking between service OAM and MPLS LSP OAM. I'd encoura= ge Authors to expand on OAM interworking subject if the proposed solution i= s intended to address such type of failures as well
      • Section 4.4 mentions that the "previous-hop node" switches LS= P traffic towards redundant egress nodes onto the protecting LSP after it d= etects or receives signal that the protected egress node have failed. I bel= ieve that it is important to address notification toward the CE otherwise s= witching to a redundant egress node would not restore the service.

      I hope Authors will find it possible to address my notes before or= at the meeting itself.


      Regards,
      Greg
      --001636310911a842d0049f06d0bc-- From Rolf.Winter@neclab.eu Tue Mar 22 01:55:10 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90CA53A67CC for ; Tue, 22 Mar 2011 01:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 lMuZ4ZlhvgIO for ; Tue, 22 Mar 2011 01:55:09 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id AA1003A67AA for ; Tue, 22 Mar 2011 01:55:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id CC1C528000192; Tue, 22 Mar 2011 09:57:58 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRaBa93ngwDn; Tue, 22 Mar 2011 09:57:58 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id ACCE72800018C; Tue, 22 Mar 2011 09:57:48 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Tue, 22 Mar 2011 09:56:32 +0100 From: Rolf Winter To: "loa@pi.nu" , "mpls@ietf.org" Thread-Topic: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand-cv-03 Thread-Index: AQHL42huOL0wlOx/O0GvtamNNTMxZZQ5Evtw Date: Tue, 22 Mar 2011 08:56:31 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> In-Reply-To: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 08:55:10 -0000 Hi, some comments below: Section 1.3 says: " In certain MPLS-TP deployment scenarios IP addressing m= ight not be available or it may be preferred to use some form of non-IP encapsulation for On-demand CV, route tracing and BFD packets. In such scenarios, On-demand CV and/or route tracing SHOULD be run without IP addressing..." I am not sure the "SHOULD" is right here. If no IP addressing is available,= this thing MUST be run without IP addressing, mustn't it? I think some additional text regarding per-interface MIP addressing would b= e nice. As far as I understand the document, all TLVs will be inside the LS= P ping packet (rather than as ACH TLVs). Some people had concerns earlier, that addressing information should be in = a fixed location for easier processing. Is this the case here I wonder? It would be nice if you could address this in your presentation in Prague. Thanks, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > loa@pi.nu > Sent: Mittwoch, 16. M=E4rz 2011 00:26 > To: mpls@ietf.org > Cc: MPLS-TP ad hoc team > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand- > cv-03 >=20 > Working Group, >=20 > this is to start a 3 week working group last call on >=20 > draft-ietf-mpls-tp-on-demand-cv-03 >=20 > Please send comments to the working group mailing list > mpls@ietf.org >=20 > The working group last call ends on April 8, 2011. >=20 > /Loa >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Robert.Rennison@ecitele.com Tue Mar 22 09:20:54 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C67353A6864; Tue, 22 Mar 2011 09:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 FOv9b1iy6P0G; Tue, 22 Mar 2011 09:20:42 -0700 (PDT) Received: from uspitbmg01.ecitele.com (uspitbmg01-out.ecitele.com [63.94.127.136]) by core3.amsl.com (Postfix) with ESMTP id D74903A684D; Tue, 22 Mar 2011 09:20:41 -0700 (PDT) X-AuditID: 3f5e7f87-b7bf5ae000004c45-7f-4d88f422f96d Received: from uspitexch02.ecitele.com ( [10.0.0.72]) by uspitbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id B1.60.19525.224F88D4; Tue, 22 Mar 2011 15:10:26 -0400 (EDT) Received: from USPITMAIL01.ecitele.com ([10.0.0.81]) by uspitexch02.ecitele.com ([10.0.0.72]) with mapi; Tue, 22 Mar 2011 12:22:13 -0400 From: Robert Rennison To: Alexander Vainshtein , Greg Mirsky , Luca Martini Date: Tue, 22 Mar 2011 12:22:12 -0400 Thread-Topic: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Thread-Index: AcvgIJCjINO9d7bvQ8uZXoqo8NcncgAAI1awAiJ1VXA= Message-ID: <786AD2EC3D80A1428B921CDC9BE9EE546569F9F8E1@USPITMAIL01.ecitele.com> References: <4D5E9442.3030101@cisco.com> <4D7A2439.6010508@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_786AD2EC3D80A1428B921CDC9BE9EE546569F9F8E1USPITMAIL01ec_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "lihan@chinamobile.com" , "mpls@ietf.org" , pwe3 , HUANG Feng F , "mpls-tp@ietf.org" Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 16:20:54 -0000 --_000_786AD2EC3D80A1428B921CDC9BE9EE546569F9F8E1USPITMAIL01ec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Luca, Thomas, A couple of clarification questions. I'm trying to understand what the combination of the two drafts, -lm-pwe3-m= pls-tp-gal-in-pw, and draft-nadeau-pwe3-vccv-2 amounts to. So, I think I understood the draft-nadeau-pwe3-vccv-2 in that it's saying u= se VCCV type 1 where possible and if not then use the new type 4, whereby = in type 4 the exception mechanism is triggered by the use of the GAL, and = I appreciated the diagram in section 3 to lock this is, so far so good. Now I read -pwe3-mpls-tp-gal-in-pw and I'm thinking , Ok these two drafts c= ould work together since this one is trying to lay the "legal framework" i.= e fix up the RFCs which mandated that the GAL could not be used with the PW= . Then I get hit with a brick wall in the form of the statements in the last = 2 paras of section 3 of tp-gal-in-pw which state. - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack. It's the bit about the GAL MUST be at the bottom of the label stack, this = is clearly inconsistent with what is proposed in the draft-nadeau-pwe3 wher= e one can clearly see the GAL above the PW label and if one has to use a G= AL with a PW this would be the place to put it, Now I can hear you saying "oh but look at the text below this, where we sta= te .."However, in other MPLS environments , this document places no restric= tions on where the GAL may appear within the label stack. This is consisten= t with draft-nadeau " In which case I'd retort with ; what are we to do f= or PWs in MPLS-TP, since what's in draft-nadeau would not be allowed ? Clarification /explanation appreciated. Cheers Rob Rennison From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Friday, March 11, 2011 2:22 PM To: Greg Mirsky; Luca Martini Cc: lihan@chinamobile.com; mpls-tp@ietf.org; pwe3; HUANG Feng F; mpls@ietf.= org Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Greg, Luca, As I've already stated in my comment on draft-nadeau-pwe3-vccv-2, IMHO it m= akes draft-lm-pwe3-mpls-tp-gal-in-pw completely useless. My 2c, Sasha From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gre= g Mirsky Sent: Friday, March 11, 2011 9:14 PM To: Luca Martini Cc: lihan@chinamobile.com; mpls@ietf.org; pwe3; HUANG Feng F; mpls-tp@ietf.= org Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Dear Luca, thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my attention. I'll se= nd my comments to it in a separate e-mail. I'll have to miss another opportunity to discuss your proposal in a meeting= . Please add my comments below to my earlier expressed WG LC comments: * the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution that ad= dresses applicability of GAL in PW VCCV, e.g. solution proposed in draft-na= deau-pwe3-vccv-2-01; * the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs to mention such dependenc= y and refer to any existing proposal; * I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be advanced = in lock with document that addresses use of GAL in PW VCCV. Regards, Greg On Fri, Mar 11, 2011 at 5:31 AM, Luca Martini > wrote: Greg , Some On 02/18/11 11:15, Greg Mirsky wrote: > Dear Luca, > I see at least two issues: > > * use of GAL for PW, in my view, is another VCCV CC type that has > to be negotiated as described in RFC 5085. > These are valid points, but this document in question does not define, not discussed VCCV. We have since posted a draft that proposes a new VCCV mode , and we welcome comments regarding that document. (draft-nadeau-pwe3-vccv-2-01.txt) > * use of GAL creates ambiguous situation when PW CW is used. The > benefit from extending GAL in PW, as I see, is for PWs that are > not required to use PW CW. That might be a good enough reason to > update RFC 5586 as proposed in the document but we must address > use cases of GAL in PWs that require presence PW CW. If we > prohibit or even discourage use of GAL for these PWs that have > PW VCCV as native Associated Channel, then architecture of ACh > for MPLS-TP PW not simplified as result of adopting the proposal. > > Regard Greg, The GAL is basically a notifier that the packet following the end of the MPLS label stack, is explicitly defined as a G-ACH format. Normally the packet would be decoded as an IP packet , unless the last label on the stack indicated otherwise. The GAL can certainly be applied to a PW OAM packet on a PW that uses the CW, and this document does not define that , nor restricts it. The scope of this document is limited to removing an unnecessary restriction in rfc5586, hence this comment not applicable to this document= . Thanks. Luca > s, > Greg > > On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini > >> wrote: > > Greg, > > Sorry, but I do not remember the point you mention. > Can you explain again here ? > Thanks. > Luca > > > On 02/17/11 23:47, Greg Mirsky wrote: > > Dear Authors and All, > > prior to the meeting in Bejing and acceptance of this proposal as W= G > > document Luca and I agreed that use of GAL with PW VCCV presents a > > problem. > > I was not attending the IETF-79, nor I found discussion of this > issue > > in the minutes. I think that this issue should be specified, > > explained. In my view, this document updates not only RFC 5586 > > but RFC 5085 too. > > > > Regards, > > Greg > > > > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > > > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > > > > >>> wrote: > > > > Greg, > > > > You are correct , the proposed update does not propose any > changes > > to VCCV. > > However the problem with vccv is not as simple as to ask for > a new > > code point from IANA. > > Given the good amount of discussion on this point, we should > > probably have a discussion in Beijing. > > > > Luca > > > > > > > > On 10/29/2010 05:07 PM, Greg Mirsky wrote: > >> Dear Authors, > >> I think that proposed update of the Section 4.2. RFC 5586 > makes it possible > >> to use GAL on MPLS-TP PW that uses Control Word. I consider > it to be > >> conflict between PW VCCV CC types because use of GAL is not > negotiated > >> through PW VCCV negotiation. To avoid such situation I propose= : > >> > >> - in Section 5 request IANA to assign new CC Type "MPLS > Generic > >> Associated Channel Label" > >> - assign precedence to new CC Type that affects Section > 7 RFC 5085 > >> > >> Regards, > >> Greg > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > > >> > >> https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > --_000_786AD2EC3D80A1428B921CDC9BE9EE546569F9F8E1USPITMAIL01ec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

      Luca, Tho= mas,

       

      A couple of clarification questions.

       

      <= p class=3DMsoNormal>I’m trying to understand what the combinat= ion of the two drafts, -lm-pwe3-mpls-tp-gal-in-pw, and draft-= nadeau-pwe3-vccv-2 amounts to.

       

      So, I think I understood the draft-nadeau-pwe3-vccv-2 in tha= t it’s saying use VCCV type 1 where possible and if not then use the = new type 4, whereby  in type 4 the exception mechanism is triggered by= the use of the GAL,  and I appreciated the diagram in section 3 to lo= ck this is, so far so good.

       

      Now I read -pwe3-= mpls-tp-gal-in-pw and I’m thinking , Ok these two drafts could work t= ogether since this one is trying to lay the “legal framework” i= .e fix up the RFCs which mandated that the GAL could not be used with the P= W.

       

      Then I get hit with a brick wall in the f= orm of the statements in the last 2 paras of section 3 of tp-gal-in-pw whic= h state.

       =

      - Section 4.2.= (GAL Applicability and Usage) in [RFC5586], = the

        &nb= sp;   original text:

       

      =           In MPLS-TP, the GAL = MUST be used with packets on a G-ACh on

               = LSPs, Concatenated Segments of LSPs, and with Sections, and

           &n= bsp;    MUST NOT be used with PWs. It MUST always be at the = bottom of

       &nb= sp;        the label stack (i.e., S bit = set to 1). However, in other MPLS

            &nb= sp;   the GAL may appear within the label stack or its use with P= Ws.

       

          &nb= sp; is replaced by:

       

        = ;        In MPLS-TP, the GAL MUST be use= d with packets on a G-ACh on

                LSPs, Conc= atenated Segments of LSPs, and with Sections, and

             &n= bsp;  MAY be used with PWs. It MUST always be at the bottom of the

      <= span style=3D'font-family:"Courier New";color:black'>   &nbs= p;      label stack (i.e., S bit set to 1). Howeve= r, in other MPLS

      &n= bsp;         environments, this doc= ument places no restrictions on where

                t= he GAL may appear within the label stack.

       

       

      It’s the bit abo= ut the GAL MUST be at the bottom of the label stack,  this is clearly = inconsistent with what is proposed in the draft-nadeau-pwe3 where one can c= learly see the GAL above the PW label and if one has to use  a GAL wit= h a PW this would be the place to put it,

       

      Now= I can hear you saying “oh but look at the text below this, where we = state ..”However, in other MPLS environments , this document places n= o restrictions on where the GAL may appear within the label stack. This is = consistent with draft-nadeau “   In which case I’d re= tort with ; what are we to do for PWs in   MPLS-TP, since what= 217;s in draft-nadeau would not be allowed ?

       

      Clarification /explanation appreciated.

       

      Che= ers

       

      Rob Rennison

       

       

      From: mpls-b= ounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alexande= r Vainshtein
      Sent: Friday, March 11, 2011 2:22 PM
      To: G= reg Mirsky; Luca Martini
      Cc: lihan@chinamobile.com; mpls-tp@ietf.= org; pwe3; HUANG Feng F; mpls@ietf.org
      Subject: Re: [mpls] WG LC = draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

       

      Greg, Lu= ca,

      As I’ve already = stated in my comment on draft-nadeau-pwe3-vccv-2, IMHO it makes draft-lm-pw= e3-mpls-tp-gal-in-pw completely useless.

       

      My 2= c,

          = ; Sasha

       <= /span>

      From: mpls-bounces@ietf.= org [mailto:mpls-bounces@ietf.org] On Behalf Of Greg Mirsky
      Se= nt: Friday, March 11, 2011 9:14 PM
      To: Luca Martini
      Cc:= lihan@chinamobile.com; mpls@ietf.org; pwe3; HUANG Feng F; mpls-tp@ietf= .org
      Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00= .txt

       

      Dear Luca,
      thank you for bringing draft-nadeau= -pwe3-vccv-2-01 to my attention. I'll send my comments to it in a separate = e-mail.
      I'll have to miss another opportunity to discuss your proposal i= n a meeting. Please add my comments below to my earlier expressed WG LC com= ments:

      • the dr= aft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution that addresses app= licability of GAL in PW VCCV, e.g. solution proposed in draft-nadeau-pwe3-v= ccv-2-01;
      • the draft-lm-pwe3-= mpls-tp-gal-in-pw-00 needs to mention such dependency and refer to any exis= ting proposal;
      • I believe tha= t the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be advanced in lock with docum= ent that addresses use of GAL in PW VCCV.

      Regards,
      Greg

      =

      On Fri, Mar 11, 2011 at 5:31 AM, Luca Martini <lmartini@cisco.com> wrote:

      Greg ,
      Some


      On 02/18/11 11:15, Greg Mirsky wrote:
      > Dear Luca,
      >= ; I see at least two issues:
      >
      >     * use of GAL for= PW, in my view, is another VCCV CC type that has
      >     &nb= sp; to be negotiated as described in RFC 5085.
      >

      =

      These are valid points, but this document in question = does not define,
      not discussed VCCV.
      We have since posted a draft tha= t proposes a new VCCV mode , and we
      welcome comments regarding that docu= ment.
      (draft-nadeau-pwe3-vccv-2-01.txt)

      >     * use = of GAL creates ambiguous situation when PW CW is used. The

      >       benefit from extending GA= L in PW, as I see, is for PWs that are
      >       not req= uired to use PW CW. That might be a good enough reason to
      >   &n= bsp;   update RFC 5586 as proposed in the document but we must address=
      >       use cases of GAL in PWs that require presence= PW CW. If we
      >       prohibit or even discourage use = of GAL for these PWs that have
      >       PW VCCV as nati= ve Associated Channel, then architecture of ACh
      >      = ; for MPLS-TP PW not simplified as result of adopting the proposal.
      >=
      > Regard

      Greg,
      The GAL i= s basically a notifier that the packet following the end of the
      MPLS lab= el stack, is explicitly defined as a G-ACH format.
      Normally the packet w= ould be decoded as an IP packet , unless the last
      label on the stack ind= icated otherwise.

      The GAL can certainly be applied  to a PW OAM= packet on a PW that uses
      the CW, and this document does not define that= , nor restricts it.

      The scope of this document is limited to removi= ng an unnecessary
      restriction in rfc5586, hence  this comment not a= pplicable to this document.

      Thanks.
      Luca


      > s,
      > Greg
      >
      > On Fri, Feb 18, 20= 11 at 7:46 AM, Luca Martini <lmart= ini@cisco.com

      > <ma= ilto:lmartini@cisco.com>> w= rote:
      >
      >     Greg,
      >
      >     Sor= ry, but I do not remember the point you mention.
      >     Can = you explain again here ?
      >     Thanks.
      >    = ; Luca
      >
      >
      >     On 02/17/11 23:47, Greg Mirsky= wrote:
      >     > Dear Authors and All,
      >   &nb= sp; > prior to the meeting in Bejing and acceptance of this proposal as = WG
      >     > document Luca and I agreed that use of GAL wi= th PW VCCV presents a
      >     > problem.
      >   &n= bsp; > I was not attending the IETF-79, nor I found discussion of this>     issue
      >     > in the minutes. I thi= nk that this issue should be specified,
      >     > explaine= d. In my view, this document updates not only RFC 5586
      >    = ; > but RFC 5085 too.
      >     >
      >     &= gt; Regards,
      >     > Greg
      >     >
      = >     > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt>     >
      >     > On Sat, Oct 30, 2010 a= t 10:14 AM, Luca Martini
      >     <lmartini@cisco.com <mailto:lmartini@cisco.com>

      >     > <mailto:lmartini@cisco.com <mailto:lmartini@cisco.com>>> wrote:
      >     &g= t;
      >     >     Greg,
      >     >= ;
      >     >     You are correct , the proposed u= pdate does not propose any
      >     changes
      >   &nb= sp; >     to VCCV.
      >     >     Ho= wever the problem with vccv is not as simple as to ask for
      >   &= nbsp; a new
      >     >     code point from IANA.<= br>>     >     Given the good amount of discussio= n on this point, we should
      >     >     probabl= y have a discussion in Beijing.
      >     >
      >   &= nbsp; >     Luca
      >     >
      >   &nb= sp; >
      >     >
      >     >    = ; On 10/29/2010 05:07 PM, Greg Mirsky wrote:
      >     >>=     Dear Authors,
      >     >>     I= think that proposed update of the Section 4.2. RFC 5586
      >   &nb= sp; makes it possible
      >     >>     to use G= AL on MPLS-TP PW that uses Control Word. I consider
      >     i= t to be
      >     >>     conflict between PW VC= CV CC types because use of GAL is not
      >     negotiated
      &= gt;     >>     through PW VCCV negotiation. To av= oid such situation I propose:
      >     >>
      >  =   >>        - in Section 5 request IANA to = assign new CC Type "MPLS
      >     Generic
      >   =   >>        Associated Channel Label">     >>        - assign precedenc= e to new CC Type that affects Section
      >     7 RFC 5085
      &= gt;     >>
      >     >>     Reg= ards,
      >     >>     Greg
      >   &nbs= p; >>
      >     >>
      >     >>>     >>     _______________________________= ________________
      >     >>     mpls mailing = list

      >     >= >     mpls@ietf.org <m= ailto:mpls@ietf.org> <mailto:mpls@ietf.org

       

    = --_000_786AD2EC3D80A1428B921CDC9BE9EE546569F9F8E1USPITMAIL01ec_-- From loa@pi.nu Wed Mar 23 00:36:32 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02B103A68FC for ; Wed, 23 Mar 2011 00:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 fUcRP5vqN5Kz for ; Wed, 23 Mar 2011 00:36:31 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id EC6B83A68FA for ; Wed, 23 Mar 2011 00:36:30 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 8756C2A8001; Wed, 23 Mar 2011 08:38:02 +0100 (CET) Message-ID: <4D89A358.2040705@pi.nu> Date: Wed, 23 Mar 2011 08:38:00 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , MPLS-TP ad hoc team , draft-ietf-mpls-tp-oam-analysis@tools.ietf.org, draft-fang-mpls-tp-oam-toolset@tools.ietf.org Subject: [mpls] merging two draft: "OAM Analysis" and "OAM toolset" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 07:36:32 -0000 Working Group, Early in the process of defining the MLS-TP OAM tool set we agreed on a document called "OAM Analysis". The main purpose of the document was to define the OAM functionality need and also look into how much of this already was present in existing MPLS specifications and to advice on what needed to be specified as new work. This document has served its purpose well and has been an important piece in the creating a coherent MLS-TP OAM solution. At one point in time it was realized that it would be beneficial to split the draft into two different drafts - one that gives an overview of the MLS-TP OAM tool set and another that documented the more "tutorial" parts of the earlier document. The working group chairs instructed the authors of the OAM Analysis document to split the document along those lines. This was reported and agreed in Maastricht. Recently a new document "MPLS-TP OAM Toolset" was published, it is clear that there is a substantial overlap between the two documents and that the goals are very similar. After discussion with the co-authors the working group co-chairs has instructed the co-authors to merge the two documents into a single, using the title "Overview of the OAM Tool Set for MPLS based Transport Networks" and publish it with the file name "draft-ietf-mpls-tp-oam-analysis-04" Loa for the MPLS Working Group co-chairs. -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From stbryant@cisco.com Tue Mar 22 10:58:49 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7103B28C159; Tue, 22 Mar 2011 10:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.465 X-Spam-Level: X-Spam-Status: No, score=-110.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 LmlzcuiIo6vA; Tue, 22 Mar 2011 10:58:40 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id C3A8228C150; Tue, 22 Mar 2011 10:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=44897; q=dns/txt; s=iport; t=1300816812; x=1302026412; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=ldUhwkW5m/3VnHP2DGVxUIPuh2f/nr/FUsRSr+lnMaA=; b=OXUjKhjekI9mjjb3GIon8Sd7FgPiedAYKFm4wVSuW7tTrsS8qRlcGYCV DigVSoTYk7ebm2qQSR/qj3qdDk2gjz3YOSkauVWOuWHM4WD+YwGkZjctk By+bPrX0l+X9WqBO74p7M3xnTOPsM1Q9GS3N+Cu3GUL5wmxAZWQFJ0RdO Y=; X-IronPort-AV: E=Sophos;i="4.63,226,1299456000"; d="scan'208,217";a="22723818" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 22 Mar 2011 18:00:11 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2MI0BaE011913; Tue, 22 Mar 2011 18:00:11 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p2MI08U07504; Tue, 22 Mar 2011 18:00:08 GMT Message-ID: <4D88E3A7.4040502@cisco.com> Date: Tue, 22 Mar 2011 18:00:07 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Robert Rennison References: <4D5E9442.3030101@cisco.com> <4D7A2439.6010508@cisco.com> <786AD2EC3D80A1428B921CDC9BE9EE546569F9F8E1@USPITMAIL01.ecitele.com> In-Reply-To: <786AD2EC3D80A1428B921CDC9BE9EE546569F9F8E1@USPITMAIL01.ecitele.com> Content-Type: multipart/alternative; boundary="------------050303000603040509070000" X-Mailman-Approved-At: Wed, 23 Mar 2011 09:33:06 -0700 Cc: Alexander Vainshtein , "mpls@ietf.org" , "mpls-tp@ietf.org" , "lihan@chinamobile.com" , pwe3 , HUANG Feng F Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 17:58:49 -0000 This is a multi-part message in MIME format. --------------050303000603040509070000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit If there is IETF consensus to update RFC5586 with this change then the process is relatively simple: The document making the update notes that it does the update, and the AD draws attention to this in the IETF LC. Stewart On 22/03/2011 16:22, Robert Rennison wrote: > > Luca, Thomas, > > A couple of clarification questions. > > I'm trying to understand what the combination of the two drafts, > -lm-pwe3-mpls-tp-gal-in-pw, and draft-nadeau-pwe3-vccv-2amounts to. > > So, I think I understood the draft-nadeau-pwe3-vccv-2 in that it's > saying use VCCV type 1 where possible and if not then use the new type > 4, whereby in type 4 the exception mechanism is triggered by the use > of the GAL, and I appreciated the diagram in section 3 to lock this > is, so far so good. > > Now I read -pwe3-mpls-tp-gal-in-pw and I'm thinking , Ok these two > drafts could work together since this one is trying to lay the "legal > framework" i.e fix up the RFCs which mandated that the GAL could not > be used with the PW. > > Then I get hit with a brick wall in the form of the statements in the > last 2 paras of section 3 of tp-gal-in-pw which state. > > - Section 4.2 > . > (GAL Applicability and Usage) in [RFC5586 > ], the > > original text: > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > > LSPs, Concatenated Segments of LSPs, and with Sections, and > > MUST NOT be used with PWs. It MUST always be at the bottom of > > the label stack (i.e., S bit set to 1). However, in other MPLS > > environments, this document places no restrictions on where > > the GAL may appear within the label stack or its use with PWs. > > is replaced by: > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > > LSPs, Concatenated Segments of LSPs, and with Sections, and > > MAY be used with PWs. It MUST always be at the bottom of the > > label stack (i.e., S bit set to 1). However, in other MPLS > > environments, this document places no restrictions on where > > the GAL may appear within the label stack. > > It's the bit about the GAL MUST be at the bottom of the label stack, > this is clearly inconsistent with what is proposed in the > draft-nadeau-pwe3 where one can clearly see the GAL above the PW label > and if one has to use a GAL with a PW this would be the place to put it, > > Now I can hear you saying "oh but look at the text below this, where > we state .."However, in other MPLS environments , this document places > no restrictions on where the GAL may appear within the label stack. > This is consistent with draft-nadeau " In which case I'd retort with > ; what are we to do for PWs in MPLS-TP, since what's in draft-nadeau > would not be allowed ? > > Clarification /explanation appreciated. > > Cheers > > Rob Rennison > > *From:*mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf > Of *Alexander Vainshtein > *Sent:* Friday, March 11, 2011 2:22 PM > *To:* Greg Mirsky; Luca Martini > *Cc:* lihan@chinamobile.com; mpls-tp@ietf.org; pwe3; HUANG Feng F; > mpls@ietf.org > *Subject:* Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > Greg, Luca, > > As I've already stated in my comment on draft-nadeau-pwe3-vccv-2, IMHO > it makes draft-lm-pwe3-mpls-tp-gal-in-pw completely useless. > > My 2c, > > Sasha > > *From:*mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf > Of *Greg Mirsky > *Sent:* Friday, March 11, 2011 9:14 PM > *To:* Luca Martini > *Cc:* lihan@chinamobile.com; mpls@ietf.org; pwe3; HUANG Feng F; > mpls-tp@ietf.org > *Subject:* Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > Dear Luca, > thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my attention. > I'll send my comments to it in a separate e-mail. > I'll have to miss another opportunity to discuss your proposal in a > meeting. Please add my comments below to my earlier expressed WG LC > comments: > > * the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution > that addresses applicability of GAL in PW VCCV, e.g. solution > proposed in draft-nadeau-pwe3-vccv-2-01; > * the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs to mention such > dependency and refer to any existing proposal; > * I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be > advanced in lock with document that addresses use of GAL in PW VCCV. > > Regards, > Greg > > On Fri, Mar 11, 2011 at 5:31 AM, Luca Martini > wrote: > > Greg , > Some > > > On 02/18/11 11:15, Greg Mirsky wrote: > > Dear Luca, > > I see at least two issues: > > > > * use of GAL for PW, in my view, is another VCCV CC type that has > > to be negotiated as described in RFC 5085. > > > > These are valid points, but this document in question does not define, > not discussed VCCV. > We have since posted a draft that proposes a new VCCV mode , and we > welcome comments regarding that document. > (draft-nadeau-pwe3-vccv-2-01.txt) > > > * use of GAL creates ambiguous situation when PW CW is used. The > > > benefit from extending GAL in PW, as I see, is for PWs that are > > not required to use PW CW. That might be a good enough reason to > > update RFC 5586 as proposed in the document but we must address > > use cases of GAL in PWs that require presence PW CW. If we > > prohibit or even discourage use of GAL for these PWs that have > > PW VCCV as native Associated Channel, then architecture of ACh > > for MPLS-TP PW not simplified as result of adopting the proposal. > > > > Regard > > Greg, > The GAL is basically a notifier that the packet following the end of the > MPLS label stack, is explicitly defined as a G-ACH format. > Normally the packet would be decoded as an IP packet , unless the last > label on the stack indicated otherwise. > > The GAL can certainly be applied to a PW OAM packet on a PW that uses > the CW, and this document does not define that , nor restricts it. > > The scope of this document is limited to removing an unnecessary > restriction in rfc5586, hence this comment not applicable to this > document. > > Thanks. > Luca > > > > s, > > Greg > > > > On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini > > > >> wrote: > > > > Greg, > > > > Sorry, but I do not remember the point you mention. > > Can you explain again here ? > > Thanks. > > Luca > > > > > > On 02/17/11 23:47, Greg Mirsky wrote: > > > Dear Authors and All, > > > prior to the meeting in Bejing and acceptance of this proposal as WG > > > document Luca and I agreed that use of GAL with PW VCCV presents a > > > problem. > > > I was not attending the IETF-79, nor I found discussion of this > > issue > > > in the minutes. I think that this issue should be specified, > > > explained. In my view, this document updates not only RFC 5586 > > > but RFC 5085 too. > > > > > > Regards, > > > Greg > > > > > > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > > > > > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > > > > > > > > > >>> wrote: > > > > > > Greg, > > > > > > You are correct , the proposed update does not propose any > > changes > > > to VCCV. > > > However the problem with vccv is not as simple as to ask for > > a new > > > code point from IANA. > > > Given the good amount of discussion on this point, we should > > > probably have a discussion in Beijing. > > > > > > Luca > > > > > > > > > > > > On 10/29/2010 05:07 PM, Greg Mirsky wrote: > > >> Dear Authors, > > >> I think that proposed update of the Section 4.2. RFC 5586 > > makes it possible > > >> to use GAL on MPLS-TP PW that uses Control Word. I consider > > it to be > > >> conflict between PW VCCV CC types because use of GAL is not > > negotiated > > >> through PW VCCV negotiation. To avoid such situation I propose: > > >> > > >> - in Section 5 request IANA to assign new CC Type "MPLS > > Generic > > >> Associated Channel Label" > > >> - assign precedence to new CC Type that affects Section > > 7 RFC 5085 > > >> > > >> Regards, > > >> Greg > > >> > > >> > > >> > > >> _______________________________________________ > > >> mpls mailing list > > > >> mpls@ietf.org > > > > >> > > >> https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------050303000603040509070000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit If there is IETF consensus to update RFC5586 with this change then the process is relatively simple:

    The document making the update notes that it does the update, and the AD draws attention to
    this in the IETF LC.

    Stewart



    On 22/03/2011 16:22, Robert Rennison wrote:

    Luca, Thomas,

     

    A couple of clarification questions.

     

    I’m trying to understand what the combination of the two drafts, -lm-pwe3-mpls-tp-gal-in-pw, and draft-nadeau-pwe3-vccv-2 amounts to.

     

    So, I think I understood the draft-nadeau-pwe3-vccv-2 in that it’s saying use VCCV type 1 where possible and if not then use the new type 4, whereby  in type 4 the exception mechanism is triggered by the use of the GAL,  and I appreciated the diagram in section 3 to lock this is, so far so good.

     

    Now I read -pwe3-mpls-tp-gal-in-pw and I’m thinking , Ok these two drafts could work together since this one is trying to lay the “legal framework” i.e fix up the RFCs which mandated that the GAL could not be used with the PW.

     

    Then I get hit with a brick wall in the form of the statements in the last 2 paras of section 3 of tp-gal-in-pw which state.

     

    - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the

          original text:

     

              In MPLS-TP, the GAL MUST be used with packets on a G-ACh on

              LSPs, Concatenated Segments of LSPs, and with Sections, and

              MUST NOT be used with PWs. It MUST always be at the bottom of

              the label stack (i.e., S bit set to 1). However, in other MPLS

              environments, this document places no restrictions on where

              the GAL may appear within the label stack or its use with PWs.

     

          is replaced by:

     

              In MPLS-TP, the GAL MUST be used with packets on a G-ACh on

              LSPs, Concatenated Segments of LSPs, and with Sections, and

              MAY be used with PWs. It MUST always be at the bottom of the

              label stack (i.e., S bit set to 1). However, in other MPLS

              environments, this document places no restrictions on where

              the GAL may appear within the label stack.

     

     

    It’s the bit about the GAL MUST be at the bottom of the label stack,  this is clearly inconsistent with what is proposed in the draft-nadeau-pwe3 where one can clearly see the GAL above the PW label and if one has to use  a GAL with a PW this would be the place to put it,

     

    Now I can hear you saying “oh but look at the text below this, where we state ..”However, in other MPLS environments , this document places no restrictions on where the GAL may appear within the label stack. This is consistent with draft-nadeau “   In which case I’d retort with ; what are we to do for PWs in   MPLS-TP, since what’s in draft-nadeau would not be allowed ?

     

    Clarification /explanation appreciated.

     

    Cheers

     

    Rob Rennison

     

     

    From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein
    Sent: Friday, March 11, 2011 2:22 PM
    To: Greg Mirsky; Luca Martini
    Cc: lihan@chinamobile.com; mpls-tp@ietf.org; pwe3; HUANG Feng F; mpls@ietf.org
    Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

     

    Greg, Luca,

    As I’ve already stated in my comment on draft-nadeau-pwe3-vccv-2, IMHO it makes draft-lm-pwe3-mpls-tp-gal-in-pw completely useless.

     

    My 2c,

         Sasha

     

    From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Greg Mirsky
    Sent: Friday, March 11, 2011 9:14 PM
    To: Luca Martini
    Cc: lihan@chinamobile.com; mpls@ietf.org; pwe3; HUANG Feng F; mpls-tp@ietf.org
    Subject: Re: [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

     

    Dear Luca,
    thank you for bringing draft-nadeau-pwe3-vccv-2-01 to my attention. I'll send my comments to it in a separate e-mail.
    I'll have to miss another opportunity to discuss your proposal in a meeting. Please add my comments below to my earlier expressed WG LC comments:

    • the draft-lm-pwe3-mpls-tp-gal-in-pw-00 depends on any solution that addresses applicability of GAL in PW VCCV, e.g. solution proposed in draft-nadeau-pwe3-vccv-2-01;
    • the draft-lm-pwe3-mpls-tp-gal-in-pw-00 needs to mention such dependency and refer to any existing proposal;
    • I believe that the draft-lm-pwe3-mpls-tp-gal-in-pw-00 can be advanced in lock with document that addresses use of GAL in PW VCCV.

    Regards,
    Greg

    On Fri, Mar 11, 2011 at 5:31 AM, Luca Martini <lmartini@cisco.com> wrote:

    Greg ,
    Some


    On 02/18/11 11:15, Greg Mirsky wrote:
    > Dear Luca,
    > I see at least two issues:
    >
    >     * use of GAL for PW, in my view, is another VCCV CC type that has
    >       to be negotiated as described in RFC 5085.
    >

    These are valid points, but this document in question does not define,
    not discussed VCCV.
    We have since posted a draft that proposes a new VCCV mode , and we
    welcome comments regarding that document.
    (draft-nadeau-pwe3-vccv-2-01.txt)

    >     * use of GAL creates ambiguous situation when PW CW is used. The

    >       benefit from extending GAL in PW, as I see, is for PWs that are
    >       not required to use PW CW. That might be a good enough reason to
    >       update RFC 5586 as proposed in the document but we must address
    >       use cases of GAL in PWs that require presence PW CW. If we
    >       prohibit or even discourage use of GAL for these PWs that have
    >       PW VCCV as native Associated Channel, then architecture of ACh
    >       for MPLS-TP PW not simplified as result of adopting the proposal.
    >
    > Regard

    Greg,
    The GAL is basically a notifier that the packet following the end of the
    MPLS label stack, is explicitly defined as a G-ACH format.
    Normally the packet would be decoded as an IP packet , unless the last
    label on the stack indicated otherwise.

    The GAL can certainly be applied  to a PW OAM packet on a PW that uses
    the CW, and this document does not define that , nor restricts it.

    The scope of this document is limited to removing an unnecessary
    restriction in rfc5586, hence  this comment not applicable to this document.

    Thanks.
    Luca


    > s,
    > Greg
    >
    > On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini <lmartini@cisco.com

    > <mailto:lmartini@cisco.com>> wrote:
    >
    >     Greg,
    >
    >     Sorry, but I do not remember the point you mention.
    >     Can you explain again here ?
    >     Thanks.
    >     Luca
    >
    >
    >     On 02/17/11 23:47, Greg Mirsky wrote:
    >     > Dear Authors and All,
    >     > prior to the meeting in Bejing and acceptance of this proposal as WG
    >     > document Luca and I agreed that use of GAL with PW VCCV presents a
    >     > problem.
    >     > I was not attending the IETF-79, nor I found discussion of this
    >     issue
    >     > in the minutes. I think that this issue should be specified,
    >     > explained. In my view, this document updates not only RFC 5586
    >     > but RFC 5085 too.
    >     >
    >     > Regards,
    >     > Greg
    >     >
    >     > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt
    >     >
    >     > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini
    >     <lmartini@cisco.com <mailto:lmartini@cisco.com>

    >     > <mailto:lmartini@cisco.com <mailto:lmartini@cisco.com>>> wrote:
    >     >
    >     >     Greg,
    >     >
    >     >     You are correct , the proposed update does not propose any
    >     changes
    >     >     to VCCV.
    >     >     However the problem with vccv is not as simple as to ask for
    >     a new
    >     >     code point from IANA.
    >     >     Given the good amount of discussion on this point, we should
    >     >     probably have a discussion in Beijing.
    >     >
    >     >     Luca
    >     >
    >     >
    >     >
    >     >     On 10/29/2010 05:07 PM, Greg Mirsky wrote:
    >     >>     Dear Authors,
    >     >>     I think that proposed update of the Section 4.2. RFC 5586
    >     makes it possible
    >     >>     to use GAL on MPLS-TP PW that uses Control Word. I consider
    >     it to be
    >     >>     conflict between PW VCCV CC types because use of GAL is not
    >     negotiated
    >     >>     through PW VCCV negotiation. To avoid such situation I propose:
    >     >>
    >     >>        - in Section 5 request IANA to assign new CC Type "MPLS
    >     Generic
    >     >>        Associated Channel Label"
    >     >>        - assign precedence to new CC Type that affects Section
    >     7 RFC 5085
    >     >>
    >     >>     Regards,
    >     >>     Greg
    >     >>
    >     >>
    >     >>
    >     >>     _______________________________________________
    >     >>     mpls mailing list

    >     >>     mpls@ietf.org <mailto:mpls@ietf.org> <mailto:mpls@ietf.org

    >     <mailto:mpls@ietf.org>>
    >     >>     https://www.ietf.org/mailman/listinfo/mpls
    >     >
    >     >
    >     >
    >     > _______________________________________________
    >     > mpls mailing list
    >     > mpls@ietf.org <mailto:mpls@ietf.org>
    >     > https://www.ietf.org/mailman/listinfo/mpls
    >
    >

     

    
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls



    -- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
    --------------050303000603040509070000-- From gregimirsky@gmail.com Wed Mar 23 13:55:44 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0609C3A694C; Wed, 23 Mar 2011 13:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.723 X-Spam-Level: X-Spam-Status: No, score=-2.723 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 s87bvyV0xvNg; Wed, 23 Mar 2011 13:55:42 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id CC3923A68D6; Wed, 23 Mar 2011 13:55:41 -0700 (PDT) Received: by vxg33 with SMTP id 33so7539893vxg.31 for ; Wed, 23 Mar 2011 13:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NATeo5XlpGZjwKhbS8DSmt+xmeeeS6PxwljJdmX/Lb8=; b=aKWN0f/v5jdXOL7vKGrnEOvs7roOATLrTQxzbZzQ/dxUH8eMd3DreItestBsdmv3fg nZoXDlDVF1eeeeSMy48akcPOBNTAFTwFttVZCoxiz3A7+rtTrthAKMtZOKqssIrxt+J3 53pi/vk4dw8emxVUxTmkPjRlqydHwVeTxnaCk= 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=gSqBhoGDxJLTTUB4rH+akqz2yPlrggnRbrRLWIovu9zl6CL/z+0H7admn5+qON3m5u Irbsu8EP+lwpKkU2gKXEOe1dwk6IbgT9Fsje2Wjs24ZT5SCZPrHCWXZgEt53DlwCOaQZ odXVGNW5DfWFTYdOqQ8S9HcZT176drjE449hI= MIME-Version: 1.0 Received: by 10.52.67.73 with SMTP id l9mr7406761vdt.287.1300913835406; Wed, 23 Mar 2011 13:57:15 -0700 (PDT) Received: by 10.52.168.6 with HTTP; Wed, 23 Mar 2011 13:57:15 -0700 (PDT) In-Reply-To: <201103232025.p2NKPr2t076600@harbor.orleans.occnc.com> References: <4D88E3A7.4040502@cisco.com> <201103232025.p2NKPr2t076600@harbor.orleans.occnc.com> Date: Wed, 23 Mar 2011 13:57:15 -0700 Message-ID: From: Greg Mirsky To: curtis@occnc.com Content-Type: multipart/alternative; boundary=20cf307f32040af5a2049f2c9b4c Cc: Robert Rennison , "mpls@ietf.org" , "mpls-tp@ietf.org" , "lihan@chinamobile.com" , pwe3 , HUANG Feng F , stbryant@cisco.com Subject: Re: [mpls] [PWE3] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 20:55:44 -0000 --20cf307f32040af5a2049f2c9b4c Content-Type: text/plain; charset=ISO-8859-1 Dear Curtis and All, I believe that any restriction on placing GAL in a label stack set in Section 4.2, RFC 5886 is relevant only for MPLS-TP PSN. For non-TP PSNs there are no restrictions set in RFC 5886 on where in a label stack GAL might appear. Some of use cases mentioned by Curtis are outside of MPLS-TP scope and, as I understand, use of GAL in these cases is not regulated by the RFC 5886. As to the issue of using GAL in PW there would not be a problem if not for possible conflict with PW VCCV CC Type 1. If GAL presents PW VCCV CC Type 4, properly updates RFC 5085, and for MPLS-TP PWs complies with the RFC 5886 - we might be good. Regards, Greg On Wed, Mar 23, 2011 at 1:25 PM, Curtis Villamizar wrote: > > In message <4D88E3A7.4040502@cisco.com> > Stewart Bryant writes: > > > > If there is IETF consensus to update RFC5586 with this change then the > > process is relatively simple: > > > > The document making the update notes that it does the update, and the AD > > draws attention to > > this in the IETF LC. > > > > Stewart > > > Stewart, > > The restriction that GAL be at the bottom of stack was simply a > mistake IMHO. I stated that during MPLS WG discussion before it > became an RFC but it went through as is anyway with that restriction. > Even then it was said that if there were a strong reason to relax it > that it could be considered later. That time may have come. > > There are a number of reasons that labels might want to go below GAL, > including to use OAM to diagnose the connectivity (or lack of) that is > experienced only for a specific label stack combinations where > multipath (link bundle, LAG, less applicable is ECMP in this case) is > used. > > In this case though, the GAL under the LSP label currently indicates > that after the POP that OAM needs to be done (or more accurately that > a G-Ach of some type is being carried). If the GAL is put above the > PW label it is in that same place and there is an ambiguity. It is an > ambiguity that for some but not all defined OAM can be resolved by > looking at information in BFD that makes it unambiguous. Unless I'm > mistaken, in CC/CV the label stack above GAL provides the context. > > Another solution would be to put GAL under the PW label. It would > probably be best to put GAL under PW but over the fat-pw label. The > PW implementation, seeing the PW was not BOS, could look at the next > label to see if the label is reserved and specifically if it is GAL, > and if not process as payload (unless CW is also used). If CW was not > used the only advantage is 4 bytes less in payload but the same size > in OAM packets. This is an advantage though. > > On a related topic, if we must put ELI plus entropy label on the stack > we have saved nothing relative to fat-pw plus CW. ELI as a > termination of hash search may have other uses though (MPLS-TP). > > I would be in favor of a very short draft just relaxing the > requirement that GAL be at the bottom of stack, independent of the > reason for doing so, since a number of reasons have emerged. The > behavior would be to throw away the rest of the label stack when the > GAL label is exposed and look at the MPLS payload interpreting it as > an G-Ach channel (most often, but not exclusively, as OAM). This > relaxation of the BOS restriction would be independent of usage. > > Curtis > > > > On 22/03/2011 16:22, Robert Rennison wrote: > > > > > > Luca, Thomas, > > > > > > A couple of clarification questions. > > > > > > I'm trying to understand what the combination of the two drafts, > > > -lm-pwe3-mpls-tp-gal-in-pw, and draft-nadeau-pwe3-vccv-2amounts to. > > > > > > So, I think I understood the draft-nadeau-pwe3-vccv-2 in that it's > > > saying use VCCV type 1 where possible and if not then use the new type > > > 4, whereby in type 4 the exception mechanism is triggered by the use > > > of the GAL, and I appreciated the diagram in section 3 to lock this > > > is, so far so good. > > > > > > Now I read -pwe3-mpls-tp-gal-in-pw and I'm thinking , Ok these two > > > drafts could work together since this one is trying to lay the "legal > > > framework" i.e fix up the RFCs which mandated that the GAL could not > > > be used with the PW. > > > > > > Then I get hit with a brick wall in the form of the statements in the > > > last 2 paras of section 3 of tp-gal-in-pw which state. > > > > > > - Section 4.2 > > > < > http://tools.ietf.org/html/draft-lm-pwe3-mpls-tp-gal-in-pw-00#section-4.2 > >. > > > (GAL Applicability and Usage) in [RFC5586 > > > ], the > > > > > > original text: > > > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > > > > > > LSPs, Concatenated Segments of LSPs, and with Sections, and > > > > > > MUST NOT be used with PWs. It MUST always be at the bottom of > > > > > > the label stack (i.e., S bit set to 1). However, in other > MPLS > > > > > > environments, this document places no restrictions on where > > > > > > the GAL may appear within the label stack or its use with > PWs. > > > > > > is replaced by: > > > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > > > > > > LSPs, Concatenated Segments of LSPs, and with Sections, and > > > > > > MAY be used with PWs. It MUST always be at the bottom of the > > > > > > label stack (i.e., S bit set to 1). However, in other MPLS > > > > > > environments, this document places no restrictions on where > > > > > > the GAL may appear within the label stack. > > > > > > It's the bit about the GAL MUST be at the bottom of the label stack, > > > this is clearly inconsistent with what is proposed in the > > > draft-nadeau-pwe3 where one can clearly see the GAL above the PW label > > > and if one has to use a GAL with a PW this would be the place to put > it, > > > > > > Now I can hear you saying "oh but look at the text below this, where > > > we state .."However, in other MPLS environments , this document places > > > no restrictions on where the GAL may appear within the label stack. > > > This is consistent with draft-nadeau " In which case I'd retort with > > > ; what are we to do for PWs in MPLS-TP, since what's in draft-nadeau > > > would not be allowed ? > > > > > > Clarification /explanation appreciated. > > > > > > Cheers > > > > > > Rob Rennison > > > > [snipped ...] --20cf307f32040af5a2049f2c9b4c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Curtis and All,
    I believe that any restriction on placing GAL in a = label stack set in Section 4.2, RFC 5886 is relevant only for MPLS-TP PSN. = For non-TP PSNs there are no restrictions set in RFC 5886 on where in a lab= el stack GAL might appear. Some of use cases mentioned by Curtis are outsid= e of MPLS-TP scope and, as I understand, use of GAL in these cases is not r= egulated by the RFC 5886.
    As to the issue of using GAL in PW there would not be a problem if not for = possible conflict with PW VCCV CC Type 1. If GAL presents PW VCCV CC Type 4= , properly updates RFC 5085, and for MPLS-TP PWs complies with the RFC 5886= - we might be good.

    Regards,
    Greg

    On Wed, Mar 23, 2011= at 1:25 PM, Curtis Villamizar <curtis@occnc.com> wrote:

    In message <4D88E3A7.40405= 02@cisco.com>
    Stewart Bryant writes:
    >
    > If there is IETF consensus to update RFC5586 with this change then the=
    > process is relatively simple:
    >
    > The document making the update notes that it does the update, and the = AD
    > draws attention to
    > this in the IETF LC.
    >
    > Stewart


    Stewart,

    The restriction that GAL be at the bottom of stack was simply a
    mistake IMHO. =A0I stated that during MPLS WG discussion before it
    became an RFC but it went through as is anyway with that restriction.
    Even then it was said that if there were a strong reason to relax it
    that it could be considered later. =A0That time may have come.

    There are a number of reasons that labels might want to go below GAL,
    including to use OAM to diagnose the connectivity (or lack of) that is
    experienced only for a specific label stack combinations where
    multipath (link bundle, LAG, less applicable is ECMP in this case) is
    used.

    In this case though, the GAL under the LSP label currently indicates
    that after the POP that OAM needs to be done (or more accurately that
    a G-Ach of some type is being carried). =A0If the GAL is put above the
    PW label it is in that same place and there is an ambiguity. =A0It is an ambiguity that for some but not all defined OAM can be resolved by
    looking at information in BFD that makes it unambiguous. =A0Unless I'm<= br> mistaken, in CC/CV the label stack above GAL provides the context.

    Another solution would be to put GAL under the PW label. =A0It would
    probably be best to put GAL under PW but over the fat-pw label. =A0The
    PW implementation, seeing the PW was not BOS, could look at the next
    label to see if the label is reserved and specifically if it is GAL,
    and if not process as payload (unless CW is also used). =A0If CW was not used the only advantage is 4 bytes less in payload but the same size
    in OAM packets. =A0This is an advantage though.

    On a related topic, if we must put ELI plus entropy label on the stack
    we have saved nothing relative to fat-pw plus CW. =A0ELI as a
    termination of hash search may have other uses though (MPLS-TP).

    I would be in favor of a very short draft just relaxing the
    requirement that GAL be at the bottom of stack, independent of the
    reason for doing so, since a number of reasons have emerged. =A0The
    behavior would be to throw away the rest of the label stack when the
    GAL label is exposed and look at the MPLS payload interpreting it as
    an G-Ach channel (most often, but not exclusively, as OAM). =A0This
    relaxation of the BOS restriction would be independent of usage.

    Curtis


    > On 22/03/2011 16:22, Robert Rennison wrote:
    > >
    > > Luca, Thomas,
    > >
    > > A couple of clarification questions.
    > >
    > > I'm trying to understand what the combination of the two draf= ts,
    > > -lm-pwe3-mpls-tp-gal-in-pw, and draft-nadeau-pwe3-vccv-2amo= unts to.
    > >
    > > So, I think I understood the draft-nadeau-pwe3-vccv-2 in that it&= #39;s
    > > saying use VCCV type 1 where possible and if not then use the new= type
    > > 4, whereby =A0in type 4 the exception mechanism is triggered by t= he use
    > > of the GAL, =A0and I appreciated the diagram in section 3 to lock= this
    > > is, so far so good.
    > >
    > > Now I read -pwe3-mpls-tp-gal-in-pw and I'm thinking , Ok thes= e two
    > > drafts could work together since this one is trying to lay the &q= uot;legal
    > > framework" i.e fix up the RFCs which mandated that the GAL c= ould not
    > > be used with the PW.
    > >
    > > Then I get hit with a brick wall in the form of the statements in= the
    > > last 2 paras of section 3 of tp-gal-in-pw which state.
    > >
    > > - Section 4.2
    > > <http://tools.ietf.org/html= /draft-lm-pwe3-mpls-tp-gal-in-pw-00#section-4.2>.
    > > (GAL Applicability and Usage) in [RFC5586
    > > <http://tools.ietf.org/html/rfc5586>], the
    > >
    > > =A0 =A0 =A0 original text:
    > >
    > > =A0 =A0 =A0 =A0 =A0 In MPLS-TP, the GAL MUST be used with packets= on a G-ACh on
    > >
    > > =A0 =A0 =A0 =A0 =A0 LSPs, Concatenated Segments of LSPs, and with= Sections, and
    > >
    > > =A0 =A0 =A0 =A0 =A0 MUST NOT be used with PWs. It MUST always be = at the bottom of
    > >
    > > =A0 =A0 =A0 =A0 =A0 the label stack (i.e., S bit set to 1). Howev= er, in other MPLS
    > >
    > > =A0 =A0 =A0 =A0 =A0 environments, this document places no restric= tions on where
    > >
    > > =A0 =A0 =A0 =A0 =A0 the GAL may appear within the label stack or = its use with PWs.
    > >
    > > =A0 =A0 =A0 is replaced by:
    > >
    > > =A0 =A0 =A0 =A0 =A0 In MPLS-TP, the GAL MUST be used with packets= on a G-ACh on
    > >
    > > =A0 =A0 =A0 =A0 =A0 LSPs, Concatenated Segments of LSPs, and with= Sections, and
    > >
    > > =A0 =A0 =A0 =A0 =A0 MAY be used with PWs. It MUST always be at th= e bottom of the
    > >
    > > =A0 =A0 =A0 =A0 =A0 label stack (i.e., S bit set to 1). However, = in other MPLS
    > >
    > > =A0 =A0 =A0 =A0 =A0 environments, this document places no restric= tions on where
    > >
    > > =A0 =A0 =A0 =A0 =A0 the GAL may appear within the label stack. > >
    > > It's the bit about the GAL MUST be at the bottom of the label= stack,
    > > this is clearly inconsistent with what is proposed in the
    > > draft-nadeau-pwe3 where one can clearly see the GAL above the PW = label
    > > and if one has to use =A0a GAL with a PW this would be the place = to put it,
    > >
    > > Now I can hear you saying "oh but look at the text below thi= s, where
    > > we state .."However, in other MPLS environments , this docum= ent places
    > > no restrictions on where the GAL may appear within the label stac= k.
    > > This is consistent with draft-nadeau " =A0 In which case I&#= 39;d retort with
    > > ; what are we to do for PWs in =A0 MPLS-TP, since what's in d= raft-nadeau
    > > would not be allowed ?
    > >
    > > Clarification /explanation appreciated.
    > >
    > > Cheers
    > >
    > > Rob Rennison
    > >
    [snipped ...]
    --20cf307f32040af5a2049f2c9b4c-- From lufang@cisco.com Wed Mar 23 18:15:44 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080E23A63CA for ; Wed, 23 Mar 2011 18:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 uaFjVIT+vw0l for ; Wed, 23 Mar 2011 18:15:43 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 267033A63C9 for ; Wed, 23 Mar 2011 18:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=1008; q=dns/txt; s=iport; t=1300929437; x=1302139037; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=EFowsH622ODIfXQM0fK8KJ2zQrovchlz9VqC7zWJA10=; b=gcW/8Y2/5cP6kL8KKWWNeNZyvCoq5G9doTTa7EuBggY+Va0+RxmGk6dI mxaRUWyahUIT0o6wk0+cKUhnYRyZewJtW+xO49o6GbbkQnUBcGxG9N/V3 h1VSQaQog9t7kBUnEZ0zPx11ZXIV2efoduvE/skPPYfcbvbxvF19tq2se A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQHAKc4ik2tJV2Y/2dsb2JhbACYSox4d6Y5nDWFaQSFN4sQ X-IronPort-AV: E=Sophos;i="4.63,234,1299456000"; d="scan'208";a="417583952" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-1.cisco.com with ESMTP; 24 Mar 2011 01:17:17 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2O1HHin016849 for ; Thu, 24 Mar 2011 01:17:17 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Mar 2011 20:17:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Mar 2011 20:17:14 -0500 Message-ID: <238542D917511A45B6B8AA806E875E25050C3371@XMB-RCD-201.cisco.com> In-Reply-To: <4D89A358.2040705@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPLS 2011 International Conference - Call for Papers Thread-Index: AcvpLUjPTJtZsM9tSkyq356Xw8PFVgAkxd4w References: <4D89A358.2040705@pi.nu> From: "Luyuan Fang (lufang)" To: X-OriginalArrivalTime: 24 Mar 2011 01:17:17.0301 (UTC) FILETIME=[37203A50:01CBE9C1] Subject: [mpls] MPLS 2011 International Conference - Call for Papers X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 01:15:44 -0000 Dear colleagues, The MPLS 2011 International Conference, the 14th Annual International Conference on MPLS and Related Technologies, will be held October 16 - 19, 2011, in Washington, DC. The Technical Program Committee is soliciting abstracts summarizing a proposed presentation representing original/unpublished work covering cutting-edge topics. Presentations covering new technologies and operational experience are solicited from network equipment vendors, service/transport providers, government agencies, the research community, and enterprise users. The deadline for submission of presentation proposals is April 29, 2011. If you want further information on MPLS 2010 or want to submit a presentation abstract, please see the following URL: http://www.isocore.com/mpls2011/call_for_papers/cfp.htm Many of these topics have been of interest to members of this community in the past, and many people active on this list have been presenters at past events. Regards, Luyuan From Alexander.Vainshtein@ecitele.com Wed Mar 23 22:43:12 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCBCC3A67EE; Wed, 23 Mar 2011 22:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 vHFHunwhl07F; Wed, 23 Mar 2011 22:43:09 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id 5F0673A67EC; Wed, 23 Mar 2011 22:43:07 -0700 (PDT) X-AuditID: 93eaf2e8-b7bb7ae000004cb7-7a-4d8ad9e27c25 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Brightmail Gateway) with SMTP id D1.C9.19639.2E9DA8D4; Thu, 24 Mar 2011 07:42:58 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 24 Mar 2011 07:44:40 +0200 From: Alexander Vainshtein To: Greg Mirsky , "curtis@occnc.com" Date: Thu, 24 Mar 2011 07:44:39 +0200 Thread-Topic: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Thread-Index: AcvpnOiGGRabzLeyRbyIkrfThDWZpQARrqfo Message-ID: References: <4D88E3A7.4040502@cisco.com> <201103232025.p2NKPr2t076600@harbor.orleans.occnc.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEACEILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" , "lihan@chinamobile.com" , pwe3 , HUANG, Feng F , Robert Rennison Subject: Re: [mpls] [mpls-tp] [PWE3] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 05:43:12 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEACEILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greg, Curtis and all, I think that the linkage between TP/non-TP differentiation and restrictions= on GAL usage is highly problematic. E.g., consider an MS-PW with some segments crossing TP domains and some - n= on-TP ones (this is a realistic example). IMHO GAL is part of the data plane that is shared by IP/MPLS and MPLS-TP-TP= , and hence the same restrictions should apply uniformly. IMHO RFC 5960 com= plies with this principle. RFC 5960 also seems to impose the restriction on GAL being at the bottom of= stack. E.g., please look at the following text fragment: If the TTL of an LSP label expires, then the label with the S (Bottom of Stack) bit set is inspected to determine if it is a reserved label. If it is a reserved label, the packet is processed according to the rules of that reserved label. For example, if it is a Generic Associated Channel Label (GAL), then it is processed as a packet on the Generic Associated Channel (G-ACh); see Section 4. If the TTL of a PW expires at an S-PE or T-PE, then the packet is examined to determine if a Generic Associated Channel Header (ACH) is present immediately below the PW label. If so, then the packet is processed as a packet on the G-ACh. And, last but not least, if we decide to allow GAL in the middle of the lab= el stack (overriding RFC 5586 and RFC 5960), we must also define how a pack= et with GAL in the middle of the label stack is forwarded when GAL is expos= ed, similar to what has been done in RFC 3032 for RAL. My 2c, Sasha ________________________________ From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Greg= Mirsky [gregimirsky@gmail.com] Sent: Wednesday, March 23, 2011 10:57 PM To: curtis@occnc.com Cc: Robert Rennison; mpls@ietf.org; mpls-tp@ietf.org; lihan@chinamobile.com= ; pwe3; HUANG Feng F Subject: Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-= 00.txt Dear Curtis and All, I believe that any restriction on placing GAL in a label stack set in Secti= on 4.2, RFC 5886 is relevant only for MPLS-TP PSN. For non-TP PSNs there ar= e no restrictions set in RFC 5886 on where in a label stack GAL might appea= r. Some of use cases mentioned by Curtis are outside of MPLS-TP scope and, = as I understand, use of GAL in these cases is not regulated by the RFC 5886= . As to the issue of using GAL in PW there would not be a problem if not for = possible conflict with PW VCCV CC Type 1. If GAL presents PW VCCV CC Type 4= , properly updates RFC 5085, and for MPLS-TP PWs complies with the RFC 5886= - we might be good. Regards, Greg On Wed, Mar 23, 2011 at 1:25 PM, Curtis Villamizar > wrote: In message <4D88E3A7.4040502@cisco.com> Stewart Bryant writes: > > If there is IETF consensus to update RFC5586 with this change then the > process is relatively simple: > > The document making the update notes that it does the update, and the AD > draws attention to > this in the IETF LC. > > Stewart Stewart, The restriction that GAL be at the bottom of stack was simply a mistake IMHO. I stated that during MPLS WG discussion before it became an RFC but it went through as is anyway with that restriction. Even then it was said that if there were a strong reason to relax it that it could be considered later. That time may have come. There are a number of reasons that labels might want to go below GAL, including to use OAM to diagnose the connectivity (or lack of) that is experienced only for a specific label stack combinations where multipath (link bundle, LAG, less applicable is ECMP in this case) is used. In this case though, the GAL under the LSP label currently indicates that after the POP that OAM needs to be done (or more accurately that a G-Ach of some type is being carried). If the GAL is put above the PW label it is in that same place and there is an ambiguity. It is an ambiguity that for some but not all defined OAM can be resolved by looking at information in BFD that makes it unambiguous. Unless I'm mistaken, in CC/CV the label stack above GAL provides the context. Another solution would be to put GAL under the PW label. It would probably be best to put GAL under PW but over the fat-pw label. The PW implementation, seeing the PW was not BOS, could look at the next label to see if the label is reserved and specifically if it is GAL, and if not process as payload (unless CW is also used). If CW was not used the only advantage is 4 bytes less in payload but the same size in OAM packets. This is an advantage though. On a related topic, if we must put ELI plus entropy label on the stack we have saved nothing relative to fat-pw plus CW. ELI as a termination of hash search may have other uses though (MPLS-TP). I would be in favor of a very short draft just relaxing the requirement that GAL be at the bottom of stack, independent of the reason for doing so, since a number of reasons have emerged. The behavior would be to throw away the rest of the label stack when the GAL label is exposed and look at the MPLS payload interpreting it as an G-Ach channel (most often, but not exclusively, as OAM). This relaxation of the BOS restriction would be independent of usage. Curtis > On 22/03/2011 16:22, Robert Rennison wrote: > > > > Luca, Thomas, > > > > A couple of clarification questions. > > > > I'm trying to understand what the combination of the two drafts, > > -lm-pwe3-mpls-tp-gal-in-pw, and draft-nadeau-pwe3-vccv-2amounts to. > > > > So, I think I understood the draft-nadeau-pwe3-vccv-2 in that it's > > saying use VCCV type 1 where possible and if not then use the new type > > 4, whereby in type 4 the exception mechanism is triggered by the use > > of the GAL, and I appreciated the diagram in section 3 to lock this > > is, so far so good. > > > > Now I read -pwe3-mpls-tp-gal-in-pw and I'm thinking , Ok these two > > drafts could work together since this one is trying to lay the "legal > > framework" i.e fix up the RFCs which mandated that the GAL could not > > be used with the PW. > > > > Then I get hit with a brick wall in the form of the statements in the > > last 2 paras of section 3 of tp-gal-in-pw which state. > > > > - Section 4.2 > > . > > (GAL Applicability and Usage) in [RFC5586 > > ], the > > > > original text: > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > > > > LSPs, Concatenated Segments of LSPs, and with Sections, and > > > > MUST NOT be used with PWs. It MUST always be at the bottom of > > > > the label stack (i.e., S bit set to 1). However, in other MPL= S > > > > environments, this document places no restrictions on where > > > > the GAL may appear within the label stack or its use with PWs= . > > > > is replaced by: > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > > > > LSPs, Concatenated Segments of LSPs, and with Sections, and > > > > MAY be used with PWs. It MUST always be at the bottom of the > > > > label stack (i.e., S bit set to 1). However, in other MPLS > > > > environments, this document places no restrictions on where > > > > the GAL may appear within the label stack. > > > > It's the bit about the GAL MUST be at the bottom of the label stack, > > this is clearly inconsistent with what is proposed in the > > draft-nadeau-pwe3 where one can clearly see the GAL above the PW label > > and if one has to use a GAL with a PW this would be the place to put i= t, > > > > Now I can hear you saying "oh but look at the text below this, where > > we state .."However, in other MPLS environments , this document places > > no restrictions on where the GAL may appear within the label stack. > > This is consistent with draft-nadeau " In which case I'd retort with > > ; what are we to do for PWs in MPLS-TP, since what's in draft-nadeau > > would not be allowed ? > > > > Clarification /explanation appreciated. > > > > Cheers > > > > Rob Rennison > > [snipped ...] --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEACEILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Greg, Curtis and all,
    I think that the linkage between TP/non= -TP differentiation and restrictions on GAL usage is highly problematic.
     
    E.g., consider an MS-PW with some segme= nts crossing TP domains and some - non-TP ones (this is a realistic example= ). 
     
    IMHO GAL is part of the data plane that= is shared by IP/MPLS and MPLS-TP-TP, and hence the same r= estrictions should apply uniformly. IMHO RFC 5960 complies with= this principle.
     
    RFC 5960 also seems to impose the restr= iction on GAL being at the bottom of stack. E.g., please look at the following text fragment:
     
       I=
f the TTL of an LSP label expires, then the label with the=20
   S (Bottom of Stack) bit set is inspected to determine if it is a
   reserved label.  If it is a reserved label, the packet is processed
   according to the rules of that reserved label.  For example, if it is
   a Generic Associated Channel Label (GAL), then it is processed as a
   packet on the Generic Associated Channel (G-ACh); see Sect=
ion 4.  If
   the TTL of a PW expires at an S-PE or T-PE, then the packet is
   examined to determine if a Generic Associated Channel Header (ACH) is
   present immediately below the PW label.  If so, then the packet is
   processed as a packet on the G-ACh.
    And, last but not least, if we decide t= o allow GAL in the middle of the label stack (overriding RFC 5586 and RFC 5= 960), we must also define how a packet with GAL in the middle of the label = stack is forwarded when GAL is exposed, similar to what has been done in RFC 3032 for RAL.
     
    My 2c,
         Sasha
     
     
    From: mpls-tp-bou= nces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky [gregimir= sky@gmail.com]
    Sent: Wednesday, March 23, 2011 10:57 PM
    To: curtis@occnc.com
    Cc: Robert Rennison; mpls@ietf.org; mpls-tp@ietf.org; lihan@chinamob= ile.com; pwe3; HUANG Feng F
    Subject: Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal= -in-pw-00.txt

    Dear Curtis and All,
    I believe that any restriction on placing GAL in a label stack set in Secti= on 4.2, RFC 5886 is relevant only for MPLS-TP PSN. For non-TP PSNs there ar= e no restrictions set in RFC 5886 on where in a label stack GAL might appea= r. Some of use cases mentioned by Curtis are outside of MPLS-TP scope and, as I understand, use of GAL in th= ese cases is not regulated by the RFC 5886.
    As to the issue of using GAL in PW there would not be a problem if not for = possible conflict with PW VCCV CC Type 1. If GAL presents PW VCCV CC Type 4= , properly updates RFC 5085, and for MPLS-TP PWs complies with the RFC 5886= - we might be good.

    Regards,
    Greg

    On Wed, Mar 23, 2011 at 1:25 PM, Curtis Villamiz= ar <curtis@occnc.com> wro= te:

    In message <4D88E3A7.40405= 02@cisco.com>
    Stewart Bryant writes:
    >
    > If there is IETF consensus to update RFC5586 with this change then the=
    > process is relatively simple:
    >
    > The document making the update notes that it does the update, and the = AD
    > draws attention to
    > this in the IETF LC.
    >
    > Stewart


    Stewart,

    The restriction that GAL be at the bottom of stack was simply a
    mistake IMHO.  I stated that during MPLS WG discussion before it
    became an RFC but it went through as is anyway with that restriction.
    Even then it was said that if there were a strong reason to relax it
    that it could be considered later.  That time may have come.

    There are a number of reasons that labels might want to go below GAL,
    including to use OAM to diagnose the connectivity (or lack of) that is
    experienced only for a specific label stack combinations where
    multipath (link bundle, LAG, less applicable is ECMP in this case) is
    used.

    In this case though, the GAL under the LSP label currently indicates
    that after the POP that OAM needs to be done (or more accurately that
    a G-Ach of some type is being carried).  If the GAL is put above the PW label it is in that same place and there is an ambiguity.  It is an=
    ambiguity that for some but not all defined OAM can be resolved by
    looking at information in BFD that makes it unambiguous.  Unless I'm mistaken, in CC/CV the label stack above GAL provides the context.

    Another solution would be to put GAL under the PW label.  It would
    probably be best to put GAL under PW but over the fat-pw label.  The PW implementation, seeing the PW was not BOS, could look at the next
    label to see if the label is reserved and specifically if it is GAL,
    and if not process as payload (unless CW is also used).  If CW was not=
    used the only advantage is 4 bytes less in payload but the same size
    in OAM packets.  This is an advantage though.

    On a related topic, if we must put ELI plus entropy label on the stack
    we have saved nothing relative to fat-pw plus CW.  ELI as a
    termination of hash search may have other uses though (MPLS-TP).

    I would be in favor of a very short draft just relaxing the
    requirement that GAL be at the bottom of stack, independent of the
    reason for doing so, since a number of reasons have emerged.  The
    behavior would be to throw away the rest of the label stack when the
    GAL label is exposed and look at the MPLS payload interpreting it as
    an G-Ach channel (most often, but not exclusively, as OAM).  This
    relaxation of the BOS restriction would be independent of usage.

    Curtis


    > On 22/03/2011 16:22, Robert Rennison wrote:
    > >
    > > Luca, Thomas,
    > >
    > > A couple of clarification questions.
    > >
    > > I'm trying to understand what the combination of the two drafts,<= br>
    > > -lm-pwe3-mpls-tp-gal-in-pw, and draft-nadeau-pwe3-vccv-2amounts t= o.
    > >
    > > So, I think I understood the draft-nadeau-pwe3-vccv-2 in that it'= s
    > > saying use VCCV type 1 where possible and if not then use the new= type
    > > 4, whereby  in type 4 the exception mechanism is triggered b= y the use
    > > of the GAL,  and I appreciated the diagram in section 3 to l= ock this
    > > is, so far so good.
    > >
    > > Now I read -pwe3-mpls-tp-gal-in-pw and I'm thinking , Ok these tw= o
    > > drafts could work together since this one is trying to lay the &q= uot;legal
    > > framework" i.e fix up the RFCs which mandated that the GAL c= ould not
    > > be used with the PW.
    > >
    > > Then I get hit with a brick wall in the form of the statements in= the
    > > last 2 paras of section 3 of tp-gal-in-pw which state.
    > >
    > > - Section 4.2
    > > <http://tools.ietf.org/html/draft= -lm-pwe3-mpls-tp-gal-in-pw-00#section-4.2>.
    > > (GAL Applicability and Usage) in [RFC5586
    > > <http://tools.ietf.org/html/rfc5586>], the
    > >
    > >       original text:
    > >
    > >           In MPLS-TP, the GAL MUST be us= ed with packets on a G-ACh on
    > >
    > >           LSPs, Concatenated Segments of= LSPs, and with Sections, and
    > >
    > >           MUST NOT be used with PWs. It = MUST always be at the bottom of
    > >
    > >           the label stack (i.e., S bit s= et to 1). However, in other MPLS
    > >
    > >           environments, this document pl= aces no restrictions on where
    > >
    > >           the GAL may appear within the = label stack or its use with PWs.
    > >
    > >       is replaced by:
    > >
    > >           In MPLS-TP, the GAL MUST be us= ed with packets on a G-ACh on
    > >
    > >           LSPs, Concatenated Segments of= LSPs, and with Sections, and
    > >
    > >           MAY be used with PWs. It MUST = always be at the bottom of the
    > >
    > >           label stack (i.e., S bit set t= o 1). However, in other MPLS
    > >
    > >           environments, this document pl= aces no restrictions on where
    > >
    > >           the GAL may appear within the = label stack.
    > >
    > > It's the bit about the GAL MUST be at the bottom of the label sta= ck,
    > > this is clearly inconsistent with what is proposed in the
    > > draft-nadeau-pwe3 where one can clearly see the GAL above the PW = label
    > > and if one has to use  a GAL with a PW this would be the pla= ce to put it,
    > >
    > > Now I can hear you saying "oh but look at the text below thi= s, where
    > > we state .."However, in other MPLS environments , this docum= ent places
    > > no restrictions on where the GAL may appear within the label stac= k.
    > > This is consistent with draft-nadeau "   In which case = I'd retort with
    > > ; what are we to do for PWs in   MPLS-TP, since what's in dr= aft-nadeau
    > > would not be allowed ?
    > >
    > > Clarification /explanation appreciated.
    > >
    > > Cheers
    > >
    > > Rob Rennison
    > >
    [snipped ...]
    --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEACEILPTMAIL02eci_-- From gregimirsky@gmail.com Wed Mar 23 23:32:16 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906A03A6808; Wed, 23 Mar 2011 23:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.213 X-Spam-Level: X-Spam-Status: No, score=-3.213 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 xcFFyHjZer5a; Wed, 23 Mar 2011 23:32:14 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 231B23A67EE; Wed, 23 Mar 2011 23:32:13 -0700 (PDT) Received: by vws12 with SMTP id 12so7319701vws.31 for ; Wed, 23 Mar 2011 23:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ie+9k5NnCumygPyA4nifKt5f2LogXDebqXOozZsCLtQ=; b=egBGjsFHgggyDHUsmHrJnQlLvVWUd5nNkYJ1zVk4dI/Afg8UiZCZrDfp/2TDBuE54M YatqBJOhC2c3cGeW4Yi1XEUEOKYMZBJvRYeATwongnJ58HRQWSSUvigsN0s1x6V48bMp Frw7UJf/0HY5wd4cU/Biw2b3vXd7dj47MD9R4= 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=pbuQvzAx/AIDMt8IsSUzYdcG+E7yqMEWZKnktZL0IHiPnvczG5kcdSSST+uvnnlzjr 4iLga03kKehqck+uSg0RioaTV1nINgfzBJWViZndBEES7AP/7hKUMRvMh7QTQpnTzM3R 7MtSNrlOaEKRL+HLqmCKNDMV+/gyBhGaLUIBc= MIME-Version: 1.0 Received: by 10.52.65.195 with SMTP id z3mr7998753vds.175.1300948426212; Wed, 23 Mar 2011 23:33:46 -0700 (PDT) Received: by 10.52.161.198 with HTTP; Wed, 23 Mar 2011 23:33:45 -0700 (PDT) In-Reply-To: References: <4D88E3A7.4040502@cisco.com> <201103232025.p2NKPr2t076600@harbor.orleans.occnc.com> Date: Wed, 23 Mar 2011 23:33:45 -0700 Message-ID: From: Greg Mirsky To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=20cf307abd5fd0c651049f34a871 Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" , "lihan@chinamobile.com" , pwe3 , HUANG Feng F , Robert Rennison Subject: Re: [mpls] [mpls-tp] [PWE3] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 06:32:16 -0000 --20cf307abd5fd0c651049f34a871 Content-Type: text/plain; charset=ISO-8859-1 Dear Sasha, I don't think that TP and non-TP networks should be peers, not server and client to each other. Even though nothing precludes them from being peers. I think that allowing TP and non-TP to be peers would create many, for example, OAM issues since much of MPLS, i.e. IP/MPLS, is outside of scope of MPLS-TP OAM. For instance, what is ME of merged LSP? Is it between LER's or between LER and MP? Regards, Greg On Wed, Mar 23, 2011 at 10:44 PM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Greg, Curtis and all, > I think that the linkage between TP/non-TP differentiation and restrictions > on GAL usage is highly problematic. > > E.g., consider an MS-PW with some segments crossing TP domains and some - > non-TP ones (this is a realistic example). > > IMHO GAL is part of the data plane that is shared by IP/MPLS andMPLS-TP-TP, and hence the same restrictions shouldapply uniformly. IMHO RFC 5960 complies with this principle. > > RFC 5960 also seems to impose the restriction on GAL being at the bottom of > stack. E.g., please look at the following text fragment: > > > If the TTL of an LSP label expires, then the label with the > S (Bottom of Stack) bit set is inspected to determine if it is a > reserved label. If it is a reserved label, the packet is processed > according to the rules of that reserved label. For example, if it is > a Generic Associated Channel Label (GAL), then it is processed as a > packet on the Generic Associated Channel (G-ACh); see Section 4. If > the TTL of a PW expires at an S-PE or T-PE, then the packet is > examined to determine if a Generic Associated Channel Header (ACH) is > present immediately below the PW label. If so, then the packet is > processed as a packet on the G-ACh. > > And, last but not least, if we decide to allow GAL in the middle of the > label stack (overriding RFC 5586 and RFC 5960), we must also define how a > packet with GAL in the middle of the label stack is forwarded when GAL is > exposed, similar to what has been done in RFC 3032 for RAL. > > My 2c, > Sasha > > > ------------------------------ > *From:* mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of > Greg Mirsky [gregimirsky@gmail.com] > *Sent:* Wednesday, March 23, 2011 10:57 PM > *To:* curtis@occnc.com > *Cc:* Robert Rennison; mpls@ietf.org; mpls-tp@ietf.org; > lihan@chinamobile.com; pwe3; HUANG Feng F > *Subject:* Re: [mpls-tp] [PWE3] [mpls] WG LC > draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > Dear Curtis and All, > I believe that any restriction on placing GAL in a label stack set in > Section 4.2, RFC 5886 is relevant only for MPLS-TP PSN. For non-TP PSNs > there are no restrictions set in RFC 5886 on where in a label stack GAL > might appear. Some of use cases mentioned by Curtis are outside of MPLS-TP > scope and, as I understand, use of GAL in these cases is not regulated by > the RFC 5886. > As to the issue of using GAL in PW there would not be a problem if not for > possible conflict with PW VCCV CC Type 1. If GAL presents PW VCCV CC Type 4, > properly updates RFC 5085, and for MPLS-TP PWs complies with the RFC 5886 - > we might be good. > > Regards, > Greg > > On Wed, Mar 23, 2011 at 1:25 PM, Curtis Villamizar wrote: > >> >> In message <4D88E3A7.4040502@cisco.com> >> Stewart Bryant writes: >> > >> > If there is IETF consensus to update RFC5586 with this change then the >> > process is relatively simple: >> > >> > The document making the update notes that it does the update, and the AD >> > draws attention to >> > this in the IETF LC. >> > >> > Stewart >> >> >> Stewart, >> >> The restriction that GAL be at the bottom of stack was simply a >> mistake IMHO. I stated that during MPLS WG discussion before it >> became an RFC but it went through as is anyway with that restriction. >> Even then it was said that if there were a strong reason to relax it >> that it could be considered later. That time may have come. >> >> There are a number of reasons that labels might want to go below GAL, >> including to use OAM to diagnose the connectivity (or lack of) that is >> experienced only for a specific label stack combinations where >> multipath (link bundle, LAG, less applicable is ECMP in this case) is >> used. >> >> In this case though, the GAL under the LSP label currently indicates >> that after the POP that OAM needs to be done (or more accurately that >> a G-Ach of some type is being carried). If the GAL is put above the >> PW label it is in that same place and there is an ambiguity. It is an >> ambiguity that for some but not all defined OAM can be resolved by >> looking at information in BFD that makes it unambiguous. Unless I'm >> mistaken, in CC/CV the label stack above GAL provides the context. >> >> Another solution would be to put GAL under the PW label. It would >> probably be best to put GAL under PW but over the fat-pw label. The >> PW implementation, seeing the PW was not BOS, could look at the next >> label to see if the label is reserved and specifically if it is GAL, >> and if not process as payload (unless CW is also used). If CW was not >> used the only advantage is 4 bytes less in payload but the same size >> in OAM packets. This is an advantage though. >> >> On a related topic, if we must put ELI plus entropy label on the stack >> we have saved nothing relative to fat-pw plus CW. ELI as a >> termination of hash search may have other uses though (MPLS-TP). >> >> I would be in favor of a very short draft just relaxing the >> requirement that GAL be at the bottom of stack, independent of the >> reason for doing so, since a number of reasons have emerged. The >> behavior would be to throw away the rest of the label stack when the >> GAL label is exposed and look at the MPLS payload interpreting it as >> an G-Ach channel (most often, but not exclusively, as OAM). This >> relaxation of the BOS restriction would be independent of usage. >> >> Curtis >> >> >> > On 22/03/2011 16:22, Robert Rennison wrote: >> > > >> > > Luca, Thomas, >> > > >> > > A couple of clarification questions. >> > > >> > > I'm trying to understand what the combination of the two drafts, >> > > -lm-pwe3-mpls-tp-gal-in-pw, and draft-nadeau-pwe3-vccv-2amounts to. >> > > >> > > So, I think I understood the draft-nadeau-pwe3-vccv-2 in that it's >> > > saying use VCCV type 1 where possible and if not then use the new type >> > > 4, whereby in type 4 the exception mechanism is triggered by the use >> > > of the GAL, and I appreciated the diagram in section 3 to lock this >> > > is, so far so good. >> > > >> > > Now I read -pwe3-mpls-tp-gal-in-pw and I'm thinking , Ok these two >> > > drafts could work together since this one is trying to lay the "legal >> > > framework" i.e fix up the RFCs which mandated that the GAL could not >> > > be used with the PW. >> > > >> > > Then I get hit with a brick wall in the form of the statements in the >> > > last 2 paras of section 3 of tp-gal-in-pw which state. >> > > >> > > - Section 4.2 >> > > < >> http://tools.ietf.org/html/draft-lm-pwe3-mpls-tp-gal-in-pw-00#section-4.2 >> >. >> > > (GAL Applicability and Usage) in [RFC5586 >> > > ], the >> > > >> > > original text: >> > > >> > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on >> > > >> > > LSPs, Concatenated Segments of LSPs, and with Sections, and >> > > >> > > MUST NOT be used with PWs. It MUST always be at the bottom >> of >> > > >> > > the label stack (i.e., S bit set to 1). However, in other >> MPLS >> > > >> > > environments, this document places no restrictions on where >> > > >> > > the GAL may appear within the label stack or its use with >> PWs. >> > > >> > > is replaced by: >> > > >> > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on >> > > >> > > LSPs, Concatenated Segments of LSPs, and with Sections, and >> > > >> > > MAY be used with PWs. It MUST always be at the bottom of the >> > > >> > > label stack (i.e., S bit set to 1). However, in other MPLS >> > > >> > > environments, this document places no restrictions on where >> > > >> > > the GAL may appear within the label stack. >> > > >> > > It's the bit about the GAL MUST be at the bottom of the label stack, >> > > this is clearly inconsistent with what is proposed in the >> > > draft-nadeau-pwe3 where one can clearly see the GAL above the PW label >> > > and if one has to use a GAL with a PW this would be the place to put >> it, >> > > >> > > Now I can hear you saying "oh but look at the text below this, where >> > > we state .."However, in other MPLS environments , this document places >> > > no restrictions on where the GAL may appear within the label stack. >> > > This is consistent with draft-nadeau " In which case I'd retort with >> > > ; what are we to do for PWs in MPLS-TP, since what's in draft-nadeau >> > > would not be allowed ? >> > > >> > > Clarification /explanation appreciated. >> > > >> > > Cheers >> > > >> > > Rob Rennison >> > > >> > [snipped ...] > --20cf307abd5fd0c651049f34a871 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Sasha,
    I don't think that TP and non-TP networks should be peer= s, not server and client to each other. Even though nothing precludes them = from being peers. I think that allowing TP and non-TP to be peers would cre= ate many, for example, OAM issues since much of MPLS, i.e. IP/MPLS, is outs= ide of scope of MPLS-TP OAM. For instance, what is ME of merged LSP? Is it = between LER's or between LER and MP?

    Regards,
    Greg

    On Wed, Mar 23, 2011= at 10:44 PM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com><= /span> wrote:
    Greg, Curtis and all,
    I think that the linkage between TP/non= -TP differentiation and restrictions on GAL usage is highly problematic.
    =A0
    E.g., consider an MS-PW with some segme= nts crossing TP domains and some - non-TP ones (this is a realistic example= ).=A0
    =A0
    IMHO GAL is part of the data plane that= is=A0shared by IP/MPLS=A0and MPLS-TP-TP, and hence the same restric= tions=A0should apply uniformly. IMHO RFC 5960 complies with this pri= nciple.
    =A0
    RFC 5960 also seems to impose the restr= iction on GAL being at the bottom of stack. E.g., please look at=A0the following text fragment:
    =A0
       =
If the TTL of an LSP label expires, then the label with the=20
   S (Bottom of Stack) bit set is inspected to determine if it is a
   reserved label.  If it is a reserved label, the packet is processed
   according to the rules of that reserved label.  For example, if it is
   a Generic Associated Channel Label (GAL), then it is processed as a
   packet on the Generic Associated Channel (G-ACh); see Sect=
ion 4.  If
   the TTL of a PW expires at an S-PE or T-PE, then the packet is
   examined to determine if a Generic Associated Channel Header (ACH) is
   present immediately below the PW label.  If so, then the packet is
   processed as a packet on the G-ACh.
    And, last but not least, if we decide t= o allow GAL in the middle of the label stack (overriding RFC 5586 and RFC 5= 960), we must also define how a packet with GAL in the middle of the label = stack is forwarded when GAL is exposed, similar to what has been done in RFC 3032 for RAL.
    =A0
    My 2c,
    =A0=A0=A0=A0 Sasha
    =A0
    =A0
    From: mpls-tp-bounces@ietf.org= [mpls-tp= -bounces@ietf.org] On Behalf Of Greg Mirsky [gregimirsky@gmail.com]
    Sent: Wednesday, March 23, 2011 10:57 PM
    To: curtis@occ= nc.com
    Cc: Robert Rennison; mpls@ietf.org; mpls-tp@ietf.org; lihan@chinamobile.com; pwe3; HUANG Feng F
    Subject: Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal= -in-pw-00.txt

    Dear Curtis and All,
    I believe that any restriction on placing GAL in a label stack set in Secti= on 4.2, RFC 5886 is relevant only for MPLS-TP PSN. For non-TP PSNs there ar= e no restrictions set in RFC 5886 on where in a label stack GAL might appea= r. Some of use cases mentioned by Curtis are outside of MPLS-TP scope and, as I understand, use of GAL in th= ese cases is not regulated by the RFC 5886.
    As to the issue of using GAL in PW there would not be a problem if not for = possible conflict with PW VCCV CC Type 1. If GAL presents PW VCCV CC Type 4= , properly updates RFC 5085, and for MPLS-TP PWs complies with the RFC 5886= - we might be good.

    Regards,
    Greg

    On Wed, Mar 23, 2011 at 1:25 PM, Curtis Villamiz= ar <curtis@occnc.com<= /a>> wrote:

    In message <    4D88E3A7.4040502@cisco.com>
    Stewart Bryant writes:
    >
    > If there is IETF consensus to update RFC5586 with this change then the=
    > process is relatively simple:
    >
    > The document making the update notes that it does the update, and the = AD
    > draws attention to
    > this in the IETF LC.
    >
    > Stewart


    Stewart,

    The restriction that GAL be at the bottom of stack was simply a
    mistake IMHO. =A0I stated that during MPLS WG discussion before it
    became an RFC but it went through as is anyway with that restriction.
    Even then it was said that if there were a strong reason to relax it
    that it could be considered later. =A0That time may have come.

    There are a number of reasons that labels might want to go below GAL,
    including to use OAM to diagnose the connectivity (or lack of) that is
    experienced only for a specific label stack combinations where
    multipath (link bundle, LAG, less applicable is ECMP in this case) is
    used.

    In this case though, the GAL under the LSP label currently indicates
    that after the POP that OAM needs to be done (or more accurately that
    a G-Ach of some type is being carried). =A0If the GAL is put above the
    PW label it is in that same place and there is an ambiguity. =A0It is an ambiguity that for some but not all defined OAM can be resolved by
    looking at information in BFD that makes it unambiguous. =A0Unless I'm<= br> mistaken, in CC/CV the label stack above GAL provides the context.

    Another solution would be to put GAL under the PW label. =A0It would
    probably be best to put GAL under PW but over the fat-pw label. =A0The
    PW implementation, seeing the PW was not BOS, could look at the next
    label to see if the label is reserved and specifically if it is GAL,
    and if not process as payload (unless CW is also used). =A0If CW was not used the only advantage is 4 bytes less in payload but the same size
    in OAM packets. =A0This is an advantage though.

    On a related topic, if we must put ELI plus entropy label on the stack
    we have saved nothing relative to fat-pw plus CW. =A0ELI as a
    termination of hash search may have other uses though (MPLS-TP).

    I would be in favor of a very short draft just relaxing the
    requirement that GAL be at the bottom of stack, independent of the
    reason for doing so, since a number of reasons have emerged. =A0The
    behavior would be to throw away the rest of the label stack when the
    GAL label is exposed and look at the MPLS payload interpreting it as
    an G-Ach channel (most often, but not exclusively, as OAM). =A0This
    relaxation of the BOS restriction would be independent of usage.

    Curtis


    > On 22/03/2011 16:22, Robert Rennison wrote:
    > >
    > > Luca, Thomas,
    > >
    > > A couple of clarification questions.
    > >
    > > I'm trying to understand what the combination of the two draf= ts,
    > > -lm-pwe3-mpls-tp-gal-in-pw, and draft-nadeau-pwe3-vccv-2amounts t= o.
    > >
    > > So, I think I understood the draft-nadeau-pwe3-vccv-2 in that it&= #39;s
    > > saying use VCCV type 1 where possible and if not then use the new= type
    > > 4, whereby =A0in type 4 the exception mechanism is triggered by t= he use
    > > of the GAL, =A0and I appreciated the diagram in section 3 to lock= this
    > > is, so far so good.
    > >
    > > Now I read -pwe3-mpls-tp-gal-in-pw and I'm thinking , Ok thes= e two
    > > drafts could work together since this one is trying to lay the &q= uot;legal
    > > framework" i.e fix up the RFCs which mandated that the GAL c= ould not
    > > be used with the PW.
    > >
    > > Then I get hit with a brick wall in the form of the statements in= the
    > > last 2 paras of section 3 of tp-gal-in-pw which state.
    > >
    > > - Section 4.2
    > > <http://tools.ietf.org/html/draft= -lm-pwe3-mpls-tp-gal-in-pw-00#section-4.2>.
    > > (GAL Applicability and Usage) in [RFC5586
    > > <http://tools.ietf.org/html/rfc5586>], the
    > >
    > > =A0 =A0 =A0 original text:
    > >
    > > =A0 =A0 =A0 =A0 =A0 In MPLS-TP, the GAL MUST be used with packets= on a G-ACh on
    > >
    > > =A0 =A0 =A0 =A0 =A0 LSPs, Concatenated Segments of LSPs, and with= Sections, and
    > >
    > > =A0 =A0 =A0 =A0 =A0 MUST NOT be used with PWs. It MUST always be = at the bottom of
    > >
    > > =A0 =A0 =A0 =A0 =A0 the label stack (i.e., S bit set to 1). Howev= er, in other MPLS
    > >
    > > =A0 =A0 =A0 =A0 =A0 environments, this document places no restric= tions on where
    > >
    > > =A0 =A0 =A0 =A0 =A0 the GAL may appear within the label stack or = its use with PWs.
    > >
    > > =A0 =A0 =A0 is replaced by:
    > >
    > > =A0 =A0 =A0 =A0 =A0 In MPLS-TP, the GAL MUST be used with packets= on a G-ACh on
    > >
    > > =A0 =A0 =A0 =A0 =A0 LSPs, Concatenated Segments of LSPs, and with= Sections, and
    > >
    > > =A0 =A0 =A0 =A0 =A0 MAY be used with PWs. It MUST always be at th= e bottom of the
    > >
    > > =A0 =A0 =A0 =A0 =A0 label stack (i.e., S bit set to 1). However, = in other MPLS
    > >
    > > =A0 =A0 =A0 =A0 =A0 environments, this document places no restric= tions on where
    > >
    > > =A0 =A0 =A0 =A0 =A0 the GAL may appear within the label stack. > >
    > > It's the bit about the GAL MUST be at the bottom of the label= stack,
    > > this is clearly inconsistent with what is proposed in the
    > > draft-nadeau-pwe3 where one can clearly see the GAL above the PW = label
    > > and if one has to use =A0a GAL with a PW this would be the place = to put it,
    > >
    > > Now I can hear you saying "oh but look at the text below thi= s, where
    > > we state .."However, in other MPLS environments , this docum= ent places
    > > no restrictions on where the GAL may appear within the label stac= k.
    > > This is consistent with draft-nadeau " =A0 In which case I&#= 39;d retort with
    > > ; what are we to do for PWs in =A0 MPLS-TP, since what's in d= raft-nadeau
    > > would not be allowed ?
    > >
    > > Clarification /explanation appreciated.
    > >
    > > Cheers
    > >
    > > Rob Rennison
    > >
    [snipped ...]

    --20cf307abd5fd0c651049f34a871-- From Alexander.Vainshtein@ecitele.com Wed Mar 23 23:57:42 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6217A28B56A; Wed, 23 Mar 2011 23:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 N9wEiVOHewle; Wed, 23 Mar 2011 23:57:40 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id D0C023A681B; Wed, 23 Mar 2011 23:57:34 -0700 (PDT) X-AuditID: 93eaf2e8-b7bb7ae000004cb7-e9-4d8aeb555937 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Brightmail Gateway) with SMTP id 3B.FB.19639.55BEA8D4; Thu, 24 Mar 2011 08:57:25 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 24 Mar 2011 08:59:07 +0200 From: Alexander Vainshtein To: Greg Mirsky Date: Thu, 24 Mar 2011 08:59:06 +0200 Thread-Topic: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Thread-Index: Acvp7W+jtuI8lyY6RYaU9LJSDSFsMAAAWBCJ Message-ID: References: <4D88E3A7.4040502@cisco.com> <201103232025.p2NKPr2t076600@harbor.orleans.occnc.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAD0ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" , "lihan@chinamobile.com" , pwe3 , HUANG Feng F , Robert Rennison Subject: Re: [mpls] [mpls-tp] [PWE3] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 06:57:42 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAD0ILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greg, Lots of thanks for a prompt response. I see the problem a bit differently: 1. RFC 5654 explicitly states that data plane interoperability between IP= /MPLS and MPLS-TP "MUST NOT require a gateway function". I.e., nothing in t= he data plane prevents the people from peering IP/MPLS and MPLS-TP domains. 2. Some forms of peering may be indeed problematic when it comes to OAM. = But IMHO these problems do not exist in the case of MS-PWs which perfectly= fit the definition of a co-routed bi-directional LSP in MPLS-TP (even if t= hey have been defined before the MPLS-TP work has began). 3. I think it is high time to state explicitly that when it comes to PWs,= the IP/MPLS vs. MPLS-TP differentiation does not exist, be it in the data = plane, OAM toolset, control plane or management plane. And, BTW, I believe = that the original restriction of non-usage of GAL with PWs has been driven = by implicit understanding of this fact. My 2c, Sasha ________________________________ From: Greg Mirsky [gregimirsky@gmail.com] Sent: Thursday, March 24, 2011 8:33 AM To: Alexander Vainshtein Cc: curtis@occnc.com; Robert Rennison; mpls@ietf.org; mpls-tp@ietf.org; lih= an@chinamobile.com; pwe3; HUANG Feng F Subject: Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-= 00.txt Dear Sasha, I don't think that TP and non-TP networks should be peers, not server and c= lient to each other. Even though nothing precludes them from being peers. I= think that allowing TP and non-TP to be peers would create many, for examp= le, OAM issues since much of MPLS, i.e. IP/MPLS, is outside of scope of MPL= S-TP OAM. For instance, what is ME of merged LSP? Is it between LER's or be= tween LER and MP? Regards, Greg On Wed, Mar 23, 2011 at 10:44 PM, Alexander Vainshtein > wrote: Greg, Curtis and all, I think that the linkage between TP/non-TP differentiation and restrictions= on GAL usage is highly problematic. E.g., consider an MS-PW with some segments crossing TP domains and some - n= on-TP ones (this is a realistic example). IMHO GAL is part of the data plane that is shared by IP/MPLS and MPLS-TP-TP= , and hence the same restrictions should apply uniformly. IMHO RFC 5960 com= plies with this principle. RFC 5960 also seems to impose the restriction on GAL being at the bottom of= stack. E.g., please look at the following text fragment: If the TTL of an LSP label expires, then the label with the S (Bottom of Stack) bit set is inspected to determine if it is a reserved label. If it is a reserved label, the packet is processed according to the rules of that reserved label. For example, if it is a Generic Associated Channel Label (GAL), then it is processed as a packet on the Generic Associated Channel (G-ACh); see Section 4. If the TTL of a PW expires at an S-PE or T-PE, then the packet is examined to determine if a Generic Associated Channel Header (ACH) is present immediately below the PW label. If so, then the packet is processed as a packet on the G-ACh. And, last but not least, if we decide to allow GAL in the middle of the lab= el stack (overriding RFC 5586 and RFC 5960), we must also define how a pack= et with GAL in the middle of the label stack is forwarded when GAL is expos= ed, similar to what has been done in RFC 3032 for RAL. My 2c, Sasha ________________________________ From: mpls-tp-bounces@ietf.org [mpls-tp-bo= unces@ietf.org] On Behalf Of Greg Mirsky [= gregimirsky@gmail.com] Sent: Wednesday, March 23, 2011 10:57 PM To: curtis@occnc.com Cc: Robert Rennison; mpls@ietf.org; mpls-tp@ietf.org<= mailto:mpls-tp@ietf.org>; lihan@chinamobile.com; pwe3; HUANG Feng F Subject: Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-= 00.txt Dear Curtis and All, I believe that any restriction on placing GAL in a label stack set in Secti= on 4.2, RFC 5886 is relevant only for MPLS-TP PSN. For non-TP PSNs there ar= e no restrictions set in RFC 5886 on where in a label stack GAL might appea= r. Some of use cases mentioned by Curtis are outside of MPLS-TP scope and, = as I understand, use of GAL in these cases is not regulated by the RFC 5886= . As to the issue of using GAL in PW there would not be a problem if not for = possible conflict with PW VCCV CC Type 1. If GAL presents PW VCCV CC Type 4= , properly updates RFC 5085, and for MPLS-TP PWs complies with the RFC 5886= - we might be good. Regards, Greg On Wed, Mar 23, 2011 at 1:25 PM, Curtis Villamizar > wrote: In message <4D88E3A7.4040502@cisco.com> Stewart Bryant writes: > > If there is IETF consensus to update RFC5586 with this change then the > process is relatively simple: > > The document making the update notes that it does the update, and the AD > draws attention to > this in the IETF LC. > > Stewart Stewart, The restriction that GAL be at the bottom of stack was simply a mistake IMHO. I stated that during MPLS WG discussion before it became an RFC but it went through as is anyway with that restriction. Even then it was said that if there were a strong reason to relax it that it could be considered later. That time may have come. There are a number of reasons that labels might want to go below GAL, including to use OAM to diagnose the connectivity (or lack of) that is experienced only for a specific label stack combinations where multipath (link bundle, LAG, less applicable is ECMP in this case) is used. In this case though, the GAL under the LSP label currently indicates that after the POP that OAM needs to be done (or more accurately that a G-Ach of some type is being carried). If the GAL is put above the PW label it is in that same place and there is an ambiguity. It is an ambiguity that for some but not all defined OAM can be resolved by looking at information in BFD that makes it unambiguous. Unless I'm mistaken, in CC/CV the label stack above GAL provides the context. Another solution would be to put GAL under the PW label. It would probably be best to put GAL under PW but over the fat-pw label. The PW implementation, seeing the PW was not BOS, could look at the next label to see if the label is reserved and specifically if it is GAL, and if not process as payload (unless CW is also used). If CW was not used the only advantage is 4 bytes less in payload but the same size in OAM packets. This is an advantage though. On a related topic, if we must put ELI plus entropy label on the stack we have saved nothing relative to fat-pw plus CW. ELI as a termination of hash search may have other uses though (MPLS-TP). I would be in favor of a very short draft just relaxing the requirement that GAL be at the bottom of stack, independent of the reason for doing so, since a number of reasons have emerged. The behavior would be to throw away the rest of the label stack when the GAL label is exposed and look at the MPLS payload interpreting it as an G-Ach channel (most often, but not exclusively, as OAM). This relaxation of the BOS restriction would be independent of usage. Curtis > On 22/03/2011 16:22, Robert Rennison wrote: > > > > Luca, Thomas, > > > > A couple of clarification questions. > > > > I'm trying to understand what the combination of the two drafts, > > -lm-pwe3-mpls-tp-gal-in-pw, and draft-nadeau-pwe3-vccv-2amounts to. > > > > So, I think I understood the draft-nadeau-pwe3-vccv-2 in that it's > > saying use VCCV type 1 where possible and if not then use the new type > > 4, whereby in type 4 the exception mechanism is triggered by the use > > of the GAL, and I appreciated the diagram in section 3 to lock this > > is, so far so good. > > > > Now I read -pwe3-mpls-tp-gal-in-pw and I'm thinking , Ok these two > > drafts could work together since this one is trying to lay the "legal > > framework" i.e fix up the RFCs which mandated that the GAL could not > > be used with the PW. > > > > Then I get hit with a brick wall in the form of the statements in the > > last 2 paras of section 3 of tp-gal-in-pw which state. > > > > - Section 4.2 > > . > > (GAL Applicability and Usage) in [RFC5586 > > ], the > > > > original text: > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > > > > LSPs, Concatenated Segments of LSPs, and with Sections, and > > > > MUST NOT be used with PWs. It MUST always be at the bottom of > > > > the label stack (i.e., S bit set to 1). However, in other MPL= S > > > > environments, this document places no restrictions on where > > > > the GAL may appear within the label stack or its use with PWs= . > > > > is replaced by: > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > > > > LSPs, Concatenated Segments of LSPs, and with Sections, and > > > > MAY be used with PWs. It MUST always be at the bottom of the > > > > label stack (i.e., S bit set to 1). However, in other MPLS > > > > environments, this document places no restrictions on where > > > > the GAL may appear within the label stack. > > > > It's the bit about the GAL MUST be at the bottom of the label stack, > > this is clearly inconsistent with what is proposed in the > > draft-nadeau-pwe3 where one can clearly see the GAL above the PW label > > and if one has to use a GAL with a PW this would be the place to put i= t, > > > > Now I can hear you saying "oh but look at the text below this, where > > we state .."However, in other MPLS environments , this document places > > no restrictions on where the GAL may appear within the label stack. > > This is consistent with draft-nadeau " In which case I'd retort with > > ; what are we to do for PWs in MPLS-TP, since what's in draft-nadeau > > would not be allowed ? > > > > Clarification /explanation appreciated. > > > > Cheers > > > > Rob Rennison > > [snipped ...] --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAD0ILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Greg,
    Lots of thanks for a prompt response.
     
    I see the problem a bit differently:
    1. RFC 5654 explicitly states that data pla= ne interoperability between IP/MPLS and MPLS-TP "MUST NOT require a ga= teway function". I.e., nothing in the data plane prevents the people f= rom peering IP/MPLS and MPLS-TP domains.
    2. Some forms of peering may be indeed= problematic when it comes to OAM. But IMHO these problems do not exist in = the case of MS-PWs  which perfectly fit the definition of a co-routed = bi-directional LSP in MPLS-TP (even if they have been defined before the MPLS-TP work has began).
    3. I think it is high time to state explicitly that= when it comes to PWs, the IP/MPLS vs. MPLS-TP differentiation does not exi= st, be it in the data plane, OAM toolset, control plane or management plane= . And, BTW, I believe that the original restriction of non-usage of GAL with PWs has been driven by i= mplicit understanding of this fact.

    My 2c,

         Sasha

    From: Greg Mirsky= [gregimirsky@gmail.com]
    Sent: Thursday, March 24, 2011 8:33 AM
    To: Alexander Vainshtein
    Cc: curtis@occnc.com; Robert Rennison; mpls@ietf.org; mpls-tp@ietf.o= rg; lihan@chinamobile.com; pwe3; HUANG Feng F
    Subject: Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal= -in-pw-00.txt

    Dear Sasha,
    I don't think that TP and non-TP networks should be peers, not server and c= lient to each other. Even though nothing precludes them from being peers. I= think that allowing TP and non-TP to be peers would create many, for examp= le, OAM issues since much of MPLS, i.e. IP/MPLS, is outside of scope of MPLS-TP OAM. For instance, what is ME= of merged LSP? Is it between LER's or between LER and MP?

    Regards,
    Greg

    On Wed, Mar 23, 2011 at 10:44 PM, Alexander Vain= shtein <Alexander.Vainshtei= n@ecitele.com> wrote:
    Greg, Curtis and all,
    I think that the linkage between TP/non= -TP differentiation and restrictions on GAL usage is highly problematic.
     
    E.g., consider an MS-PW with some segme= nts crossing TP domains and some - non-TP ones (this is a realistic example= ). 
     
    IMHO GAL is part of the data plane that= is shared by IP/MPLS and MPLS-TP-TP, and hence the same r= estrictions should apply uniformly. IMHO RFC 5960 complies with= this principle.
     
    RFC 5960 also seems to impose the restr= iction on GAL being at the bottom of stack. E.g., please look at the following text fragment:
     
       I=
f the TTL of an LSP label expires, then the label with the=20
   S (Bottom of Stack) bit set is inspected to determine if it is a
   reserved label.  If it is a reserved label, the packet is processed
   according to the rules of that reserved label.  For example, if it is
   a Generic Associated Channel Label (GAL), then it is processed as a
   packet on the Generic Associated Channel (G-ACh); see Sect=
ion 4.  If
   the TTL of a PW expires at an S-PE or T-PE, then the packet is
   examined to determine if a Generic Associated Channel Header (ACH) is
   present immediately below the PW label.  If so, then the packet is
   processed as a packet on the G-ACh.
    And, last but not least, if we decide t= o allow GAL in the middle of the label stack (overriding RFC 5586 and RFC 5= 960), we must also define how a packet with GAL in the middle of the label = stack is forwarded when GAL is exposed, similar to what has been done in RFC 3032 for RAL.
     
    My 2c,
         Sasha
     
     
    From: mpls-tp-bounces@ietf.org [m= pls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky [gregimirsky@gmail.com]
    Sent: Wednesday, March 23, 2011 10:57 PM
    To: curtis@occnc.com
    Cc: Robert Rennison; mpls@ietf.org<= /a>; mpls-tp@ietf.org; lihan@chinam= obile.com; pwe3; HUANG Feng F
    Subject: Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal= -in-pw-00.txt

    Dear Curtis and All,
    I believe that any restriction on placing GAL in a label stack set in Secti= on 4.2, RFC 5886 is relevant only for MPLS-TP PSN. For non-TP PSNs there ar= e no restrictions set in RFC 5886 on where in a label stack GAL might appea= r. Some of use cases mentioned by Curtis are outside of MPLS-TP scope and, as I understand, use of GAL in th= ese cases is not regulated by the RFC 5886.
    As to the issue of using GAL in PW there would not be a problem if not for = possible conflict with PW VCCV CC Type 1. If GAL presents PW VCCV CC Type 4= , properly updates RFC 5085, and for MPLS-TP PWs complies with the RFC 5886= - we might be good.

    Regards,
    Greg

    On Wed, Mar 23, 2011 at 1:25 PM, Curtis Villamiz= ar <curtis@occnc.com> wro= te:

    In message <4D88E3A7.40405= 02@cisco.com>
    Stewart Bryant writes:
    >
    > If there is IETF consensus to update RFC5586 with this change then the=
    > process is relatively simple:
    >
    > The document making the update notes that it does the update, and the = AD
    > draws attention to
    > this in the IETF LC.
    >
    > Stewart


    Stewart,

    The restriction that GAL be at the bottom of stack was simply a
    mistake IMHO.  I stated that during MPLS WG discussion before it
    became an RFC but it went through as is anyway with that restriction.
    Even then it was said that if there were a strong reason to relax it
    that it could be considered later.  That time may have come.

    There are a number of reasons that labels might want to go below GAL,
    including to use OAM to diagnose the connectivity (or lack of) that is
    experienced only for a specific label stack combinations where
    multipath (link bundle, LAG, less applicable is ECMP in this case) is
    used.

    In this case though, the GAL under the LSP label currently indicates
    that after the POP that OAM needs to be done (or more accurately that
    a G-Ach of some type is being carried).  If the GAL is put above the PW label it is in that same place and there is an ambiguity.  It is an=
    ambiguity that for some but not all defined OAM can be resolved by
    looking at information in BFD that makes it unambiguous.  Unless I'm mistaken, in CC/CV the label stack above GAL provides the context.

    Another solution would be to put GAL under the PW label.  It would
    probably be best to put GAL under PW but over the fat-pw label.  The PW implementation, seeing the PW was not BOS, could look at the next
    label to see if the label is reserved and specifically if it is GAL,
    and if not process as payload (unless CW is also used).  If CW was not=
    used the only advantage is 4 bytes less in payload but the same size
    in OAM packets.  This is an advantage though.

    On a related topic, if we must put ELI plus entropy label on the stack
    we have saved nothing relative to fat-pw plus CW.  ELI as a
    termination of hash search may have other uses though (MPLS-TP).

    I would be in favor of a very short draft just relaxing the
    requirement that GAL be at the bottom of stack, independent of the
    reason for doing so, since a number of reasons have emerged.  The
    behavior would be to throw away the rest of the label stack when the
    GAL label is exposed and look at the MPLS payload interpreting it as
    an G-Ach channel (most often, but not exclusively, as OAM).  This
    relaxation of the BOS restriction would be independent of usage.

    Curtis


    > On 22/03/2011 16:22, Robert Rennison wrote:
    > >
    > > Luca, Thomas,
    > >
    > > A couple of clarification questions.
    > >
    > > I'm trying to understand what the combination of the two drafts,<= br>
    > > -lm-pwe3-mpls-tp-gal-in-pw, and draft-nadeau-pwe3-vccv-2amounts t= o.
    > >
    > > So, I think I understood the draft-nadeau-pwe3-vccv-2 in that it'= s
    > > saying use VCCV type 1 where possible and if not then use the new= type
    > > 4, whereby  in type 4 the exception mechanism is triggered b= y the use
    > > of the GAL,  and I appreciated the diagram in section 3 to l= ock this
    > > is, so far so good.
    > >
    > > Now I read -pwe3-mpls-tp-gal-in-pw and I'm thinking , Ok these tw= o
    > > drafts could work together since this one is trying to lay the &q= uot;legal
    > > framework" i.e fix up the RFCs which mandated that the GAL c= ould not
    > > be used with the PW.
    > >
    > > Then I get hit with a brick wall in the form of the statements in= the
    > > last 2 paras of section 3 of tp-gal-in-pw which state.
    > >
    > > - Section 4.2
    > > <http://tools.ietf.org/html/draft= -lm-pwe3-mpls-tp-gal-in-pw-00#section-4.2>.
    > > (GAL Applicability and Usage) in [RFC5586
    > > <http://tools.ietf.org/html/rfc5586>], the
    > >
    > >       original text:
    > >
    > >           In MPLS-TP, the GAL MUST be us= ed with packets on a G-ACh on
    > >
    > >           LSPs, Concatenated Segments of= LSPs, and with Sections, and
    > >
    > >           MUST NOT be used with PWs. It = MUST always be at the bottom of
    > >
    > >           the label stack (i.e., S bit s= et to 1). However, in other MPLS
    > >
    > >           environments, this document pl= aces no restrictions on where
    > >
    > >           the GAL may appear within the = label stack or its use with PWs.
    > >
    > >       is replaced by:
    > >
    > >           In MPLS-TP, the GAL MUST be us= ed with packets on a G-ACh on
    > >
    > >           LSPs, Concatenated Segments of= LSPs, and with Sections, and
    > >
    > >           MAY be used with PWs. It MUST = always be at the bottom of the
    > >
    > >           label stack (i.e., S bit set t= o 1). However, in other MPLS
    > >
    > >           environments, this document pl= aces no restrictions on where
    > >
    > >           the GAL may appear within the = label stack.
    > >
    > > It's the bit about the GAL MUST be at the bottom of the label sta= ck,
    > > this is clearly inconsistent with what is proposed in the
    > > draft-nadeau-pwe3 where one can clearly see the GAL above the PW = label
    > > and if one has to use  a GAL with a PW this would be the pla= ce to put it,
    > >
    > > Now I can hear you saying "oh but look at the text below thi= s, where
    > > we state .."However, in other MPLS environments , this docum= ent places
    > > no restrictions on where the GAL may appear within the label stac= k.
    > > This is consistent with draft-nadeau "   In which case = I'd retort with
    > > ; what are we to do for PWs in   MPLS-TP, since what's in dr= aft-nadeau
    > > would not be allowed ?
    > >
    > > Clarification /explanation appreciated.
    > >
    > > Cheers
    > >
    > > Rob Rennison
    > >
    [snipped ...]

    --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEAD0ILPTMAIL02eci_-- From martin.vigoureux@alcatel-lucent.com Thu Mar 24 06:52:18 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A60D3A68AA for ; Thu, 24 Mar 2011 06:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 OQfzAm-qKIPY for ; Thu, 24 Mar 2011 06:52:17 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 7423F3A6859 for ; Thu, 24 Mar 2011 06:52:16 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p2ODrFP5012608 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 24 Mar 2011 14:53:48 +0100 Received: from [172.27.205.206] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 24 Mar 2011 14:53:26 +0100 Message-ID: <4D8B4CD6.8020601@alcatel-lucent.com> Date: Thu, 24 Mar 2011 14:53:26 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "MPLS @ IETF" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [mpls] IETF 80 - MPLS Sessions - Slides X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 13:52:18 -0000 All, it is time to send me the slides. Sessions are scheduled Tuesday and Thursday and the agenda can be found here: http://www.ietf.org/proceedings/80/agenda/mpls.txt Slides for Tuesday's session should be in my mailbox on Monday the 28th, midnight at the latest Slides for Thursday's session should be in my mailbox on Wednesday the 30th, midnight at the latest The agenda is pretty packed, do not take the risk of loosing your slot because we do not have your slides in time. Thank you. martin From gash5107@yahoo.com Thu Mar 24 11:52:54 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3704C28C0D6 for ; Thu, 24 Mar 2011 11:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 8yaaAAmmw2VF for ; Thu, 24 Mar 2011 11:52:52 -0700 (PDT) Received: from web63606.mail.re1.yahoo.com (web63606.mail.re1.yahoo.com [69.147.97.76]) by core3.amsl.com (Postfix) with SMTP id 73F2A3A68B7 for ; Thu, 24 Mar 2011 11:52:52 -0700 (PDT) Received: (qmail 92020 invoked by uid 60001); 24 Mar 2011 18:54:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1300992863; bh=EB/MGMFMAq1mppFQy+U9uTM+6/vF294VSmu5mJ3tT7Q=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=um5WGzHH30odl30uIiUTX4PBS7IDq1tO/9oNngMCtupDhNciZfKk/Z0aNg37wWJlAFHrr/mdViOTNgNIwWrUo6RtkerNcEOtmb4yfWYfH5iSqSn5U8ncosgT6zUsE0BP/3D7G9kvzCwyjytTGoLnI0wgeoiDORYjZj3qKaNqz+w= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=k0qVluP2NRKx+GHGeiBkxdEagU58MM3gGAnz7RaFFsihtM/xKs0JSFo6MnMtMCTeo7RF6hAX82de7wthYv056SEZgqo5BYI486I4ileUyWSiIlp/KJ9SH34PfMhpHaua9A1KAGP42VUye5lFlsZecAESGp6ZO89TKJOtxEJNG1Q=; Message-ID: <88735.36990.qm@web63606.mail.re1.yahoo.com> X-YMail-OSG: 1K.gIXsVM1mnkIxP2U0ch.n9_hBDV4j_pYbzs2mihYUhMoa DbYXXJB5w6mayWlY4hzhcA0N4O.8BEJu6BN.M7uaIrSVLmNxLummjq3Ow3.l 5XgQyUBe8hA2vpd6PMhD4L7iqDSpHvBuh1lW0GsKG4jfLEiBeKGQDk0k2Kr5 UCBjJPusyxZZs5q1uIf9zQxnA.h9DuOMP1Vx0.jlN4wis_D21zdV.CpMxAU3 ilcDX7GlkAKZba_DpgEQYGFscROBehHlXaqeEBERWK1N7xGBiLwEVSxd4h.L G_HwfNWp1VlbzQV.YZlJG4NRRVdb_9pOM5vEjt5XF7TaHar3zPztcI3j4aFd uaWcIQKNtZHcbbDhnVYsLhNLnNmj21MRcZH4EgI79ogfrfg-- Received: from [24.91.94.247] by web63606.mail.re1.yahoo.com via HTTP; Thu, 24 Mar 2011 11:54:22 PDT X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Thu, 24 Mar 2011 11:54:22 -0700 (PDT) From: Gerald Ash To: mpls@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-321216715-1300992862=:36990" Subject: [mpls] Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 18:52:54 -0000 --0-321216715-1300992862=:36990 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All, =A0 Please review the draft "Generic Connection Admission Control (GCAC) Algori= thm Specification for IP/MPLS Networks", available=A0at =A0http://www.ietf.= org/id/draft-ash-gcac-algorithm-spec-00.txt=A0(abstract in the announcement= below). The underlying goal of the work is to specify an optional GCAC algorithm fo= r IP/MPLS networks,=A0to be adopted and implemented by vendors and service = providers, that interoperates between vendor equipment and across multiple = service provider domains.=A0 This would be analogous to the PNNI GCAC that = was widely adopted and=A0helped promote=A0interoperability of ATM networks.= =A0 In addition, the approach: o=A0is=A0based on=A0CSPF, widely implemented by vendors o=A0does=A0NOT include aspects of CAC that might be considered vendor propr= ietary implementations, such as detailed path selection mechanisms o relies on=A0available standard mechanisms for MPLS based networks, such a= s RSVP, DSTE, PCE... Comments appreciated. =A0 Thanks, Jerry =A0 From: Internet-Drafts@ietf.org=A0 To: i-d-announce@ietf.org=A0 Reply-to: Internet-Drafts@ietf.org=A0 Subject: I-D ACTION:draft-ash-gcac-algorithm-spec-00.txt=A0 X-RSN: 1/0/935/34473/37870=A0 =A0 A New Internet-Draft is available from the on-line Internet-Drafts =A0 directories.=A0 =A0 =A0 Title : Generic Connection Admission Control (GCAC) Algorithm Specification= for IP/MPLS Networks=A0 Author(s) : G. Ash, D. McDysan=A0 Filename : draft-ash-gcac-algorithm-spec-00.txt=A0 Pages : 23=A0 Date : 2011-1-11=A0 =A0 This document presents a generic connection admission control (GCAC)=A0 reference model and algorithm for IP/MPLS-based networks. Service=A0 provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, for=A0 example, to reject voice over Internet Protocol (VoIP) calls when=A0 additional calls would adversely affect calls already in progress.=A0 =A0 Without MPLS GCAC, connections on congested links will suffer=A0 degraded quality. The MPLS GCAC algorithm can be optionally=A0 implemented in vendor equipment and deployed by service providers.=A0 MPLS GCAC interoperates between vendor equipment and across multiple=A0 service provider domains. The MPLS GCAC algorithm uses available=A0 standard mechanisms for MPLS based networks, such as RSVP, DSTE, PCE,=A0 NSIS, DiffServ, and OSPF. The MPLS GCAC algorithm does not include=A0 aspects of CAC that might be considered vendor proprietary=A0 implementations, such as detailed path selection mechanisms. MPLS=A0 GCAC functions are implemented in a distributed manner to deliver the=A0 objective QoS for specified QoS constraints. The source is able to=A0 compute a source route with high likelihood that MPLS GCAC via=A0 elements along the selected path will in fact admit the request.=A0 MPLS GCAC is applicable to any service or flow that must meet an=A0 objective QoS (delay, jitter, packet loss rate) for a specified=A0 quantity of traffic.=A0 =A0 A URL for this Internet-Draft is:=A0 http://www.ietf.org/internet-drafts/draft-ash-gcac-algorithm-spec-00.txt =A0 Internet-Drafts are also available by anonymous FTP at:=A0 ftp://ftp.ietf.org/internet-drafts/ =A0 Below is the data which will enable a MIME compliant mail reader=A0 implementation to automatically retrieve the ASCII version of the=A0 Internet-Draft.=A0 _______________________________________________=A0 I-D-Announce mailing list=A0 I-D-Announce@ietf.org=A0 https://www.ietf.org/mailman/listinfo/i-d-announce=A0 Internet-Draft directories: http://www.ietf.org/shadow.html=A0 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=A0 =A0 *****=A0 Click below to download the attachment(s) in this message:=A0 Attachment: draft_ash_gcac_algorithm_spec_00= .txt (1K)=A0 =A0=0A=0A=0A --0-321216715-1300992862=:36990 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    All,
     
    Please review the draft "Generic Connection Admission Control (GCAC) A= lgorithm Specification for IP/MPLS Networks", available at  http://w= ww.ietf.org/id/draft-ash-gcac-algorithm-spec-00.txt (abstract in t= he announcement below).
    The underlying goal of the work = is to specify an optional GCAC algorithm for IP/MPLS networks, to be a= dopted and implemented by vendors and service providers, that interoperates= between vendor equipment and across multiple service provider domains.&nbs= p; This would be analogous to the PNNI GCAC that was widely adopted and&nbs= p;helped promote interoperability of ATM networks.  In addition, = the approach:
    o is based on CSP= F, widely implemented by vendors
    o does NOT include asp= ects of CAC that might be considered vendor proprietary implementations, su= ch as detailed path selection mechanisms
    o relies on available stand= ard mechanisms for MPLS based networks, such as RSVP, DSTE, PCE...
    Comments appreciated.
     
    Thanks,
    Jerry
     
    From: Internet-Drafts@ietf.org&n= bsp;
    To: i-d-announce@ietf.org 
    Reply-to: Internet-Drafts@ietf.o= rg 
    Subject: I-D ACTION:draft-ash-gcac-algorithm-spec-00.txt <= BR>X-RSN: 1/0/935/34473/37870 
     
    A New Internet-Draft is av= ailable from the on-line Internet-Drafts  
    directories. 
    &n= bsp;
     
    Title : Generic Connection Admission Control (GCAC) Algor= ithm Specification for IP/MPLS Networks 
    Author(s) : G. Ash, D. McD= ysan 
    Filename : draft-ash-gcac-algorithm-spec-00.txt 
    Page= s : 23 
    Date : 2011-1-11 
     
    This document presents = a generic connection admission control (GCAC) 
    reference model and = algorithm for IP/MPLS-based networks. Service 
    provider (SP) IP/MPL= S networks need an MPLS GCAC mechanism, for 
    example, to reject voi= ce over Internet Protocol (VoIP) calls when 
    additional calls would adversely affect calls already in progress. 
     
    Witho= ut MPLS GCAC, connections on congested links will suffer 
    degraded = quality. The MPLS GCAC algorithm can be optionally 
    implemented in = vendor equipment and deployed by service providers. 
    MPLS GCAC inte= roperates between vendor equipment and across multiple 
    service pro= vider domains. The MPLS GCAC algorithm uses available 
    standard mec= hanisms for MPLS based networks, such as RSVP, DSTE, PCE, 
    NSIS, Di= ffServ, and OSPF. The MPLS GCAC algorithm does not include 
    aspects= of CAC that might be considered vendor proprietary 
    implementation= s, such as detailed path selection mechanisms. MPLS 
    GCAC functions= are implemented in a distributed manner to deliver the 
    objective = QoS for specified QoS constraints. The source is able to 
    compute a= source route with high likelihood that MPLS GCAC via 
    elements along the selected path will in fact admit the reque= st. 
    MPLS GCAC is applicable to any service or flow that must meet = an 
    objective QoS (delay, jitter, packet loss rate) for a specified=  
    quantity of traffic. 
     
    A URL for this Internet-D= raft is: 
    http://www.ietf.org/internet-drafts/draft-ash-g= cac-algorithm-spec-00.txt
     
    Internet-Drafts are also available by anonymous FTP at: = ;
    ftp://ftp.ietf.org/int= ernet-drafts/
     
    Below is the data which will enable a MIME compliant mail re= ader 
    implementation to automatically retrieve the ASCII version of= the 
    Internet-Draft. 
    ____________________________________= ___________ 
    I-D-Announce mailing list 
    I-D-Announce@ietf.o= rg 
    https://www.ietf.org/mailman/listinfo/i-d-announce 
    Int= ernet-Draft directories: http://www.ietf.org/shadow.html 
    or ftp://= ftp.ietf.org/ietf/1shadow-sites.txt 
     
    ***** 
    Click= below to download the attachment(s) in this message: 
    <A HREF= =3D"http://www.ietf.org/ibin/c5i?mid=3D6&gid=3D0&rid=3D8&k1=3D9= 35&file=3Di-d-announce.37870.1.txt">Attachment: draft_ash_gcac_algor= ithm_spec_00.txt</A> (1K) 
     

    = =0A=0A=0A=0A=0A=0A=0A=0A --0-321216715-1300992862=:36990-- From gregimirsky@gmail.com Thu Mar 24 17:50:12 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A470228C13D for ; Thu, 24 Mar 2011 17:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 5emKcXiaF31S for ; Thu, 24 Mar 2011 17:50:11 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 9D37828C113 for ; Thu, 24 Mar 2011 17:50:11 -0700 (PDT) Received: by vxg33 with SMTP id 33so497109vxg.31 for ; Thu, 24 Mar 2011 17:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=z+X/38kY5f9Rs0PiZU5orU0/u1PorLmZwL0+jQBAVF8=; b=vWMEv/tOrIRhwHiGTJ5frgGBNwVZSD0xQT5opVwZ01l1U77vHCE7ZjUnZgSpyQkWfZ rnYLTtFwSywzWIDNh7ReJXAxPSl1WPkaQyfjIWyTM0OP01I/hwESDcfDMbzTosuvELVd Gz9oAcvwSSUUr3QLw7Lh95fmqEfpq/g23KzyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=CdQKZYolRFAKxG5z/NnpKqP804jZwUipPKc2MvhadJjr5Y+CeGotvMaSBCJsJZiykr l+zsUgefO0YYnur5k0D38sRsGp+BUiotH3ZJxtbdlkAwldhEHHwo0XiaSmxUya04H0Am rZAEXpcLY/nr5F8Iifgk5M7K/8CrrZd+GDrFQ= MIME-Version: 1.0 Received: by 10.52.159.70 with SMTP id xa6mr200993vdb.135.1301014306333; Thu, 24 Mar 2011 17:51:46 -0700 (PDT) Received: by 10.52.161.198 with HTTP; Thu, 24 Mar 2011 17:51:46 -0700 (PDT) Date: Thu, 24 Mar 2011 17:51:46 -0700 Message-ID: From: Greg Mirsky To: David Allan I , swallow@cisco.com, John E Drake , mpls@ietf.org Content-Type: multipart/alternative; boundary=bcaec53f978793a57f049f43fff7 Subject: [mpls] Questions RE: draft-ietf-mpls-tp-cc-cv-rdi-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 00:50:12 -0000 --bcaec53f978793a57f049f43fff7 Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, am I late for WG LC? Hope you'll kindly consider my comments, questions below. - I think that "MPLS Proactive CV" is not the most descriptive tag for CV mode ACH code point because, as mentioned in Section 3, both CV and CC messages allowed when this ACH used. I propose to name ACH code point for CV mode "MPLS Proactive CC/CV" as in Figure 1 ACH Indication of MPLS-TP Connectivity Verification. I'd note that in Figure 3 ACH should be changed from "0xHH BFD CV Code Point" to "0xHH BFD CC/CV Code Point". And it might be useful to add new Diag code "Unintended connectivity error" and request code point from BFD registry. - Since IP encapsulation of BFD proactive CC/CV can be used then it might be helpful to mention that proactive CC/CV operates in CV mode supporting CC and CV functions. As for RDI, interpretation of Diag value 3 "Neighbor Signaled Session Down" might not be consistent with one given in the document as "a consequence of the sink MEP receiving AIS with LDI set". It could be that Diag value 5 "Path Down" is better suited to be used as indication of MEP receiving AIS with LDI being set. - Section 3.5.1 states that messages in DOWN and INIT states transmitted at rate one per second, "In both the DOWN and INIT states messages are transmitted at a rate of one per second ..." But the second part of the sentence refers Detection Time to both states even though it has significance, as in RFC 5880, only in the INIT state "... and the defect detection interval is fixed at 3.5 seconds". Perhaps if the sentence split in to will make it stricter: "In both the DOWN and INIT states messages are transmitted at a rate of one per second. Defect Detection Time in INIT state is fixed at 3.5 seconds". Regards Greg --bcaec53f978793a57f049f43fff7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors,
    am I late for WG LC? Hope you'll kindly consider my co= mments, questions below.
    • I think that "MPLS Proactive CV&qu= ot; is not the most descriptive tag for CV mode ACH code point because, as = mentioned in Section 3, both CV and CC messages allowed when this ACH used.= I propose to name ACH code point for CV mode "MPLS Proactive CC/CV&qu= ot; as in Figure 1 ACH Indication of MPLS-TP Connectivity Verification. I&#= 39;d note that in Figure 3 ACH should be changed from "0xHH BFD CV Co= de Point" to "0xHH BFD CC/CV Code Point". And it might be = useful to add new Diag code "Unintended connectivity error" and r= equest code point from BFD registry.
    • Since IP encapsulation of BFD proactive CC/CV can be used then it might= be helpful to mention that proactive CC/CV operates in CV mode supporting = CC and CV functions. As for RDI, interpretation of Diag value 3 "Neigh= bor Signaled Session Down" might not be consistent with one given in t= he document as "a consequence of the sink MEP receiving AIS with LD= I set". It could be that Diag value 5 "Path Down" is better = suited to be used as indication of MEP receiving AIS with LDI being set.
    • Section 3.5.1 states that messages in DOWN and INIT states transmitted = at rate one per second, "In both the DOWN and INIT states messages = are transmitted at a rate of one per second ..." But the second part o= f the sentence refers Detection Time to both states even though it has sign= ificance, as in RFC 5880, only in the INIT state "... and the defect = detection interval is fixed at 3.5 seconds". Perhaps if the sentence= split in to will make it stricter:
    "In both the DOWN and INIT stat= es messages are transmitted at a rate of one per second. Defect Detectio= n Time in INIT state is fixed at 3.5 seconds".

    Regards Greg
    --bcaec53f978793a57f049f43fff7-- From hideki.endo.es@hitachi.com Fri Mar 25 04:50:54 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7773A69A7 for ; Fri, 25 Mar 2011 04:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.462 X-Spam-Level: **** X-Spam-Status: No, score=4.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_BASE64_TEXT=1.753, SUBJ_RE_NUM=2.799] 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 Cs7Cz53bws5x for ; Fri, 25 Mar 2011 04:50:53 -0700 (PDT) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by core3.amsl.com (Postfix) with ESMTP id DC6443A686E for ; Fri, 25 Mar 2011 04:50:51 -0700 (PDT) Received: from mlsv5.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 2A61737AC5; Fri, 25 Mar 2011 20:52:26 +0900 (JST) Received: from mfilter2.hitachi.co.jp by mlsv5.hitachi.co.jp (8.13.1/8.13.1) id p2PBqQWG004900; Fri, 25 Mar 2011 20:52:26 +0900 Received: from vshuts3.hitachi.co.jp (vshuts3.hitachi.co.jp [10.201.6.72]) by mfilter2.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id p2PBqPjw019481; Fri, 25 Mar 2011 20:52:25 +0900 X-AuditID: b753bd60-9e356ba000007e19-c8-4d8c81f8c880 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id E8385774256; Fri, 25 Mar 2011 20:52:24 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p2PBqOS25215148; Fri, 25 Mar 2011 20:52:24 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: multipart/mixed; boundary="GMAILSMTPBOUND01110325205216" To: From: Date: Fri, 25 Mar 2011 20:52:06 +0900 References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> Priority: normal Importance: normal X400-Content-Identifier: X4D8C81D200000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml281103252051464BV] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Rolf.Winter@neclab.eu Subject: Re: [mpls] =?iso-8859-1?q?Working_Group_Las_Call_ondraft-ietf-mpls-tp?= =?iso-8859-1?q?-on-demand-cv-03?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 11:50:54 -0000 --GMAILSMTPBOUND01110325205216 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 SGkgQXV0aGVycyBvZiBkcmFmdC1vbi1kZW1hbmQtY3YsDQoNCkkgYWdyZWUgd2l0aCBSb2xm IHJlZ2FyZGluZyBNSVAgYWRkcmVzc2luZyBhbmQgaXRzIFRMViBsb2NhdGlvbi4NCg0KSW4g b3JkZXIgdG8gaWRlbnRpZnkgYSBwZXItaW50ZXJmYWNlIE1JUCwNCnRoZSB0YXJnZXQgVExW IG9mIE1JUCBJRCBpcyBuZWVkZWQuDQpBbmQsIGZpeGVkIGxvY2F0aW9uIG9mIE1JUCBJRCBU TFYgaW4gUGluZyBwYWNrZXQNCm1ha2VzIEhXIGltcGxlbWVudGF0aW9uIGVhc2llci4NCg0K RnVydGhlcm1vcmUsIHBpbmcgZXh0ZW50aW9uIG9mIFRUTCBUTFYgaGFzIGJlZW4NCldHIGRv YyBhcyBkcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctdHRsLXRsdi0wMC4NClRoaXMgZXh0ZW50 aW9uIGVuYWJsZXMgTFNQIHBpbmcgYmV0d2VlbiBMU1JzKE1JUHMpLg0KSSBleHBlY3QgdGhp cyBleHRlbnRpb24gd2lsbCBiZSBhcHBsaWVkIHRvIE1QTFMtVFAgT24tZGVtYW5kIENWIGJl dHdlZW4gTUlQcywNCmJlY2F1c2UgTVBMUy1UUCBvbi1kZW1hbmQgQ1YgaXMgYmFzZWQgb24g TVBMUyBMU1AgUGluZy4NCkRvIHlvdSBjb25zaWRlciB0aGlzIGV4dGVuc2lvbiBmb3IgZHJh ZnQtb24tZGVtYW5kLWN2IGF0IHRoaXMgcG9pbnQ/DQpJZiB5ZXMsIG5vdCBvbmx5IHRoZSB0 YXJnZXQgVExWIG9mIE1JUCBJRCBidXQgYWxzbyB0aGUgc291cmNlIFRMViBvZiBNSVAgSUQN CmlzIG5lZWRlZCB0byBleGVjdXRlIG9uLWRlbWFuZCBDViBiZXR3ZWVuIHBlci1pbnRlcmZh Y2UgTUlQcy4NCg0KVGhhbmtzLA0KSGlkZWtpIA0KDQoNCj5IaSwNCj4NCj5zb21lIGNvbW1l bnRzIGJlbG93Og0KPg0KPlNlY3Rpb24gMS4zIHNheXM6ICIgSW4gY2VydGFpbiBNUExTLVRQ IGRlcGxveW1lbnQgc2NlbmFyaW9zIElQIGFkZHJlc3NpbmcgbWlnaHQgbm90IGJlDQo+ICAg YXZhaWxhYmxlIG9yIGl0IG1heSBiZSBwcmVmZXJyZWQgdG8gdXNlIHNvbWUgZm9ybSBvZiBu b24tSVANCj4gICBlbmNhcHN1bGF0aW9uIGZvciBPbi1kZW1hbmQgQ1YsIHJvdXRlIHRyYWNp bmcgYW5kIEJGRCBwYWNrZXRzLiAgSW4NCj4gICBzdWNoIHNjZW5hcmlvcywgT24tZGVtYW5k IENWIGFuZC9vciByb3V0ZSB0cmFjaW5nIFNIT1VMRCBiZSBydW4NCj4gICB3aXRob3V0IElQ IGFkZHJlc3NpbmcuLi4iDQo+DQo+SSBhbSBub3Qgc3VyZSB0aGUgIlNIT1VMRCIgaXMgcmln aHQgaGVyZS4gSWYgbm8gSVAgYWRkcmVzc2luZyBpcyBhdmFpbGFibGUsIHRoaXMgdGhpbmcg TVVTVCBiZSBydW4gd2l0aG91dCBJUCBhZGRyZXNzaW5nLCBtdXN0bid0IGl0Pw0KPg0KPkkg dGhpbmsgc29tZSBhZGRpdGlvbmFsIHRleHQgcmVnYXJkaW5nIHBlci1pbnRlcmZhY2UgTUlQ IGFkZHJlc3Npbmcgd291bGQgYmUgbmljZS4gQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCB0aGUg ZG9jdW1lbnQsIGFsbCBUTFZzIHdpbGwgYmUgaW5zaWRlIHRoZSBMU1AgcGluZyBwYWNrZXQg KHJhdGhlciB0aGFuIGFzIEFDSCBUTFZzKS4NCj4NCj5Tb21lIHBlb3BsZSBoYWQgY29uY2Vy bnMgZWFybGllciwgdGhhdCBhZGRyZXNzaW5nIGluZm9ybWF0aW9uIHNob3VsZCBiZSBpbiBh IGZpeGVkIGxvY2F0aW9uIGZvciBlYXNpZXIgcHJvY2Vzc2luZy4gSXMgdGhpcyB0aGUgY2Fz ZSBoZXJlIEkgd29uZGVyPw0KPg0KPkl0IHdvdWxkIGJlIG5pY2UgaWYgeW91IGNvdWxkIGFk ZHJlc3MgdGhpcyBpbiB5b3VyIHByZXNlbnRhdGlvbiBpbiBQcmFndWUuDQo+DQo+VGhhbmtz LA0KPg0KPlJvbGYNCj4NCj4NCj5ORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVkIE9m ZmljZTogTkVDIEhvdXNlLCAxIFZpY3RvcmlhIFJvYWQsIExvbmRvbiBXMyA2QkwgfCBSZWdp c3RlcmVkIGluIEVuZ2xhbmQgMjgzMjAxNCANCj4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPj4gbG9hQHBpLm51DQo+PiBTZW50 OiBNaXR0d29jaCwgMTYuIE3kcnogMjAxMSAwMDoyNg0KPj4gVG86IG1wbHNAaWV0Zi5vcmcN Cj4+IENjOiBNUExTLVRQIGFkIGhvYyB0ZWFtDQo+PiBTdWJqZWN0OiBbbXBsc10gV29ya2lu ZyBHcm91cCBMYXMgQ2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtb24tZGVtYW5kLQ0KPj4g Y3YtMDMNCj4+IA0KPj4gV29ya2luZyBHcm91cCwNCj4+IA0KPj4gdGhpcyBpcyB0byBzdGFy dCBhIDMgd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbg0KPj4gDQo+PiBkcmFmdC1p ZXRmLW1wbHMtdHAtb24tZGVtYW5kLWN2LTAzDQo+PiANCj4+IFBsZWFzZSBzZW5kIGNvbW1l bnRzIHRvIHRoZSB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPj4gbXBsc0BpZXRmLm9y Zw0KPj4gDQo+PiBUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBBcHJpbCA4 LCAyMDExLg0KPj4gDQo+PiAvTG9hDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBtcGxzIG1haWxp bmcgbGlzdA0KPj4gbXBsc0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj5tcGxzIG1haWxpbmcgbGlzdA0KPm1wbHNAaWV0Zi5vcmcNCj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4NCg== --GMAILSMTPBOUND01110325205216-- From martin.vigoureux@alcatel-lucent.com Fri Mar 25 09:32:50 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0579A3A67C2 for ; Fri, 25 Mar 2011 09:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.603 X-Spam-Level: X-Spam-Status: No, score=-105.603 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, HELO_EQ_FR=0.35, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, 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 T6Rb37YUBmd3 for ; Fri, 25 Mar 2011 09:32:48 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 4B8393A67B5 for ; Fri, 25 Mar 2011 09:32:47 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p2PGYL9M009851 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 25 Mar 2011 17:34:21 +0100 Received: from [172.27.205.206] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 25 Mar 2011 17:34:21 +0100 Message-ID: <4D8CC40D.1070206@alcatel-lucent.com> Date: Fri, 25 Mar 2011 17:34:21 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 CC: "MPLS @ IETF" References: <4D872247.6040701@alcatel-lucent.com> In-Reply-To: <4D872247.6040701@alcatel-lucent.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [mpls] IETF 80 - MPLS Sessions - Preliminary Agenda X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 16:32:50 -0000 All, the agenda has been slightly updated. regards, martin Le 21/03/2011 11:02, Martin Vigoureux a écrit : > All, > > you can find the preliminary agenda at: > http://www.ietf.org/proceedings/80/agenda/mpls.txt > > It is still draft. > > Please note that draft-tsb-mpls-tp-ach-ptn might be discussed at the > rtgarea meeting (to be confirmed). > > best regards, > martin > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From Adrian.Farrel@huawei.com Fri Mar 25 09:40:54 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2B23A67CF for ; Fri, 25 Mar 2011 09:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 3ydSLcUY33lm for ; Fri, 25 Mar 2011 09:40:54 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 23A4B3A67B7 for ; Fri, 25 Mar 2011 09:40:54 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIM00F3SH2T3V@usaga01-in.huawei.com> for mpls@ietf.org; Fri, 25 Mar 2011 11:42:29 -0500 (CDT) Received: from 950129200 (dhcp-55ae.meeting.ietf.org [130.129.85.174]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIM0071DH2RNO@usaga01-in.huawei.com> for mpls@ietf.org; Fri, 25 Mar 2011 11:42:29 -0500 (CDT) Date: Fri, 25 Mar 2011 17:42:31 +0100 From: Adrian Farrel In-reply-to: To: mpls@ietf.org Message-id: <019101cbeb0b$a3abe430$eb03ac90$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AQKg0lDJukwwRXBST427SVqvd2ae5wJbPnsVATMyc8ABYkHIKpJs7D6A References: <52981DB05D3C5247A12D0AEE309F3CC201EB24B1CBBC@INOAVREX11.ptin.corpPT.com> <5E893DB832F57341992548CDBB33316399F1DA7062@EMBX01-HQ.jnpr.net> Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 16:40:54 -0000 FYI > > This draft should be discussed in Prague. There is 30 minutes allocated to this topic in the Routing Area Open Meeting. Wednesday 13:00 Adrian From curtis@occnc.com Fri Mar 25 19:01:44 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C23928C0D6; Fri, 25 Mar 2011 19:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 cokGVTy6vMtH; Fri, 25 Mar 2011 19:01:42 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 70DAE3A6877; Fri, 25 Mar 2011 19:01:42 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p2Q22vsK065505; Fri, 25 Mar 2011 22:02:57 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201103260202.p2Q22vsK065505@harbor.orleans.occnc.com> To: Alexander Vainshtein From: Curtis Villamizar In-reply-to: Your message of "Thu, 24 Mar 2011 07:44:39 +0200." Date: Fri, 25 Mar 2011 22:02:57 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" , "lihan@chinamobile.com" , pwe3 , HUANG Feng F , Robert Rennison Subject: Re: [mpls] [mpls-tp] [PWE3] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 02:01:44 -0000 In message Alexander Vainshtein writes: > > Greg, Curtis and all, > I think that the linkage between TP/non-TP differentiation and restrictions= > on GAL usage is highly problematic. Yes. I agree. > E.g., consider an MS-PW with some segments crossing TP domains and some - n= > on-TP ones (this is a realistic example). > > IMHO GAL is part of the data plane that is shared by IP/MPLS and MPLS-TP-TP= > , and hence the same restrictions should apply uniformly. IMHO RFC 5960 com= > plies with this principle. > > RFC 5960 also seems to impose the restriction on GAL being at the bottom of= > stack. E.g., please look at the following text fragment: > > > If the TTL of an LSP label expires, then the label with the > S (Bottom of Stack) bit set is inspected to determine if it is a > reserved label. If it is a reserved label, the packet is processed > according to the rules of that reserved label. For example, if it is > a Generic Associated Channel Label (GAL), then it is processed as a > packet on the Generic Associated Channel (G-ACh); see Section 4. If > the TTL of a PW expires at an S-PE or T-PE, then the packet is > examined to determine if a Generic Associated Channel Header (ACH) is > present immediately below the PW label. If so, then the packet is > processed as a packet on the G-ACh. This is used in the traceroute cacpability where TTL is set to a low value and increased until the egress is reached. This would have to be changed to look for GAL in any position, not just at the bottom of stack. If each label entry has to be inspected, this is about the same effort as looking for the S bit (bit test vs mask and 20 bit compare). This only occurs on TTL expired, which is always more work than normal forwarding. The alternate, to keep fate-sharing, is to put GAL under the fat-pw label in a PW. This requires more work on every packet forwarded to check for this additional label. Some hardware (none I've had a hand in designing) assumes that a PW has a fixed overhead below it and looks for zero in CW at a fixed offset from the PW label. Keeping GAL on the bottom, trying to acheive fate-sharing with fat-pw, and putting GAL below the fat-pw, would burden the common case of forwarding. Allowing GAL anywhere burdens the far less common TTL expired processing operation. > And, last but not least, if we decide to allow GAL in the middle of the lab= > el stack (overriding RFC 5586 and RFC 5960), we must also define how a pack= > et with GAL in the middle of the label stack is forwarded when GAL is expos= > ed, similar to what has been done in RFC 3032 for RAL. > > My 2c, > Sasha If GAL is encountered, then it is processed just as it would be if TTL was set high and GAL was encountered as a result of the final POP in a containing LSP exposing only the GAL. The G-Ach is after the bottom of stack, where ever bottom of stack is found. Curtis > ________________________________ > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Greg= > Mirsky [gregimirsky@gmail.com] > Sent: Wednesday, March 23, 2011 10:57 PM > To: curtis@occnc.com > Cc: Robert Rennison; mpls@ietf.org; mpls-tp@ietf.org; lihan@chinamobile.com= > ; pwe3; HUANG Feng F > Subject: Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-= > 00.txt > > Dear Curtis and All, > I believe that any restriction on placing GAL in a label stack set in Secti= > on 4.2, RFC 5886 is relevant only for MPLS-TP PSN. For non-TP PSNs there ar= > e no restrictions set in RFC 5886 on where in a label stack GAL might appea= > r. Some of use cases mentioned by Curtis are outside of MPLS-TP scope and, = > as I understand, use of GAL in these cases is not regulated by the RFC 5886= > . > As to the issue of using GAL in PW there would not be a problem if not for = > possible conflict with PW VCCV CC Type 1. If GAL presents PW VCCV CC Type 4= > , properly updates RFC 5085, and for MPLS-TP PWs complies with the RFC 5886= > - we might be good. > > Regards, > Greg > > On Wed, Mar 23, 2011 at 1:25 PM, Curtis Villamizar :curtis@occnc.com>> wrote: > > In message <4D88E3A7.4040502@cisco.com> > Stewart Bryant writes: > > > > If there is IETF consensus to update RFC5586 with this change then the > > process is relatively simple: > > > > The document making the update notes that it does the update, and the AD > > draws attention to > > this in the IETF LC. > > > > Stewart > > > Stewart, > > The restriction that GAL be at the bottom of stack was simply a > mistake IMHO. I stated that during MPLS WG discussion before it > became an RFC but it went through as is anyway with that restriction. > Even then it was said that if there were a strong reason to relax it > that it could be considered later. That time may have come. > > There are a number of reasons that labels might want to go below GAL, > including to use OAM to diagnose the connectivity (or lack of) that is > experienced only for a specific label stack combinations where > multipath (link bundle, LAG, less applicable is ECMP in this case) is > used. > > In this case though, the GAL under the LSP label currently indicates > that after the POP that OAM needs to be done (or more accurately that > a G-Ach of some type is being carried). If the GAL is put above the > PW label it is in that same place and there is an ambiguity. It is an > ambiguity that for some but not all defined OAM can be resolved by > looking at information in BFD that makes it unambiguous. Unless I'm > mistaken, in CC/CV the label stack above GAL provides the context. > > Another solution would be to put GAL under the PW label. It would > probably be best to put GAL under PW but over the fat-pw label. The > PW implementation, seeing the PW was not BOS, could look at the next > label to see if the label is reserved and specifically if it is GAL, > and if not process as payload (unless CW is also used). If CW was not > used the only advantage is 4 bytes less in payload but the same size > in OAM packets. This is an advantage though. > > On a related topic, if we must put ELI plus entropy label on the stack > we have saved nothing relative to fat-pw plus CW. ELI as a > termination of hash search may have other uses though (MPLS-TP). > > I would be in favor of a very short draft just relaxing the > requirement that GAL be at the bottom of stack, independent of the > reason for doing so, since a number of reasons have emerged. The > behavior would be to throw away the rest of the label stack when the > GAL label is exposed and look at the MPLS payload interpreting it as > an G-Ach channel (most often, but not exclusively, as OAM). This > relaxation of the BOS restriction would be independent of usage. > > Curtis > > > > On 22/03/2011 16:22, Robert Rennison wrote: > > > > > > Luca, Thomas, > > > > > > A couple of clarification questions. > > > > > > I'm trying to understand what the combination of the two drafts, > > > -lm-pwe3-mpls-tp-gal-in-pw, and draft-nadeau-pwe3-vccv-2amounts to. > > > > > > So, I think I understood the draft-nadeau-pwe3-vccv-2 in that it's > > > saying use VCCV type 1 where possible and if not then use the new type > > > 4, whereby in type 4 the exception mechanism is triggered by the use > > > of the GAL, and I appreciated the diagram in section 3 to lock this > > > is, so far so good. > > > > > > Now I read -pwe3-mpls-tp-gal-in-pw and I'm thinking , Ok these two > > > drafts could work together since this one is trying to lay the "legal > > > framework" i.e fix up the RFCs which mandated that the GAL could not > > > be used with the PW. > > > > > > Then I get hit with a brick wall in the form of the statements in the > > > last 2 paras of section 3 of tp-gal-in-pw which state. > > > > > > - Section 4.2 > > > 4.2>. > > > (GAL Applicability and Usage) in [RFC5586 > > > ], the > > > > > > original text: > > > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > > > > > > LSPs, Concatenated Segments of LSPs, and with Sections, and > > > > > > MUST NOT be used with PWs. It MUST always be at the bottom of > > > > > > the label stack (i.e., S bit set to 1). However, in other MPL= > S > > > > > > environments, this document places no restrictions on where > > > > > > the GAL may appear within the label stack or its use with PWs= > . > > > > > > is replaced by: > > > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > > > > > > LSPs, Concatenated Segments of LSPs, and with Sections, and > > > > > > MAY be used with PWs. It MUST always be at the bottom of the > > > > > > label stack (i.e., S bit set to 1). However, in other MPLS > > > > > > environments, this document places no restrictions on where > > > > > > the GAL may appear within the label stack. > > > > > > It's the bit about the GAL MUST be at the bottom of the label stack, > > > this is clearly inconsistent with what is proposed in the > > > draft-nadeau-pwe3 where one can clearly see the GAL above the PW label > > > and if one has to use a GAL with a PW this would be the place to put i= > t, > > > > > > Now I can hear you saying "oh but look at the text below this, where > > > we state .."However, in other MPLS environments , this document places > > > no restrictions on where the GAL may appear within the label stack. > > > This is consistent with draft-nadeau " In which case I'd retort with > > > ; what are we to do for PWs in MPLS-TP, since what's in draft-nadeau > > > would not be allowed ? > > > > > > Clarification /explanation appreciated. > > > > > > Cheers > > > > > > Rob Rennison > > > > [snipped ...] From Alexander.Vainshtein@ecitele.com Fri Mar 25 23:42:18 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4F23A68CF; Fri, 25 Mar 2011 23:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] 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 6LDbXfxLDkSk; Fri, 25 Mar 2011 23:42:17 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id EF1C83A688C; Fri, 25 Mar 2011 23:42:15 -0700 (PDT) X-AuditID: 93eaf2e8-b7bb7ae000004cb7-ca-4d8d8abfde9a Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Brightmail Gateway) with SMTP id DF.24.19639.FBA8D8D4; Sat, 26 Mar 2011 08:42:07 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sat, 26 Mar 2011 08:43:49 +0200 From: Alexander Vainshtein To: "curtis@occnc.com" Date: Sat, 26 Mar 2011 08:39:33 +0200 Thread-Topic: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Thread-Index: AcvrWff/aNFHUZqgQHWML9VSACl+fQAJpkhh Message-ID: References: Your message of "Thu, 24 Mar 2011 07:44:39 +0200." ,<201103260202.p2Q22vsK065505@harbor.orleans.occnc.com> In-Reply-To: <201103260202.p2Q22vsK065505@harbor.orleans.occnc.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" , "lihan@chinamobile.com" , pwe3 , HUANG Feng F , Robert Rennison Subject: Re: [mpls] [mpls-tp] [PWE3] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 06:42:18 -0000 Curtis,=20 Please see inline below. I've snipped the text that is not relevant to my c= omment. Regards, Sasha ________________________________________ From: curtis@occnc.com [curtis@occnc.com] Sent: Saturday, March 26, 2011 4:02 AM To: Alexander Vainshtein Cc: Greg Mirsky; curtis@occnc.com; Robert Rennison; mpls@ietf.org; mpls-tp@= ietf.org; lihan@chinamobile.com; pwe3; HUANG Feng F Subject: Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-= 00.txt In message Alexander Vainshtein writes: > ... snipped ... >> And, last but not least, if we decide to allow GAL in the middle of the = label stack=20 >> (overriding RFC 5586 and RFC 5960), we must also define how a pack et wi= th GAL=20 >> in the middle of the label stack is forwarded when GAL is exposed,=20 >> similar to what has been done in RFC 3032 for RAL. >> >> My 2c, >> Sasha > If GAL is encountered, then it is processed just as it would be if TTL > was set high and GAL was encountered as a result of the final POP in a > containing LSP exposing only the GAL. The G-Ach is after the bottom > of stack, where ever bottom of stack is found. > Curtis IMHO this would not work for, say MS-PWs with GAL above the PW label as pro= posed in draft-nadeu. > ________________________________ > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Gr= eg=3D > Mirsky [gregimirsky@gmail.com] > Sent: Wednesday, March 23, 2011 10:57 PM > To: curtis@occnc.com > Cc: Robert Rennison; mpls@ietf.org; mpls-tp@ietf.org; lihan@chinamobile.c= om=3D > ; pwe3; HUANG Feng F > Subject: Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-p= w-=3D > 00.txt > > Dear Curtis and All, > I believe that any restriction on placing GAL in a label stack set in Sec= ti=3D > on 4.2, RFC 5886 is relevant only for MPLS-TP PSN. For non-TP PSNs there = ar=3D > e no restrictions set in RFC 5886 on where in a label stack GAL might app= ea=3D > r. Some of use cases mentioned by Curtis are outside of MPLS-TP scope and= , =3D > as I understand, use of GAL in these cases is not regulated by the RFC 58= 86=3D > . > As to the issue of using GAL in PW there would not be a problem if not fo= r =3D > possible conflict with PW VCCV CC Type 1. If GAL presents PW VCCV CC Type= 4=3D > , properly updates RFC 5085, and for MPLS-TP PWs complies with the RFC 58= 86=3D > - we might be good. > > Regards, > Greg > > On Wed, Mar 23, 2011 at 1:25 PM, Curtis Villamizar :curtis@occnc.com>> wrote: > > In message <4D88E3A7.4040502@cisco.com= > > Stewart Bryant writes: > > > > If there is IETF consensus to update RFC5586 with this change then the > > process is relatively simple: > > > > The document making the update notes that it does the update, and the A= D > > draws attention to > > this in the IETF LC. > > > > Stewart > > > Stewart, > > The restriction that GAL be at the bottom of stack was simply a > mistake IMHO. I stated that during MPLS WG discussion before it > became an RFC but it went through as is anyway with that restriction. > Even then it was said that if there were a strong reason to relax it > that it could be considered later. That time may have come. > > There are a number of reasons that labels might want to go below GAL, > including to use OAM to diagnose the connectivity (or lack of) that is > experienced only for a specific label stack combinations where > multipath (link bundle, LAG, less applicable is ECMP in this case) is > used. > > In this case though, the GAL under the LSP label currently indicates > that after the POP that OAM needs to be done (or more accurately that > a G-Ach of some type is being carried). If the GAL is put above the > PW label it is in that same place and there is an ambiguity. It is an > ambiguity that for some but not all defined OAM can be resolved by > looking at information in BFD that makes it unambiguous. Unless I'm > mistaken, in CC/CV the label stack above GAL provides the context. > > Another solution would be to put GAL under the PW label. It would > probably be best to put GAL under PW but over the fat-pw label. The > PW implementation, seeing the PW was not BOS, could look at the next > label to see if the label is reserved and specifically if it is GAL, > and if not process as payload (unless CW is also used). If CW was not > used the only advantage is 4 bytes less in payload but the same size > in OAM packets. This is an advantage though. > > On a related topic, if we must put ELI plus entropy label on the stack > we have saved nothing relative to fat-pw plus CW. ELI as a > termination of hash search may have other uses though (MPLS-TP). > > I would be in favor of a very short draft just relaxing the > requirement that GAL be at the bottom of stack, independent of the > reason for doing so, since a number of reasons have emerged. The > behavior would be to throw away the rest of the label stack when the > GAL label is exposed and look at the MPLS payload interpreting it as > an G-Ach channel (most often, but not exclusively, as OAM). This > relaxation of the BOS restriction would be independent of usage. > > Curtis > > > > On 22/03/2011 16:22, Robert Rennison wrote: > > > > > > Luca, Thomas, > > > > > > A couple of clarification questions. > > > > > > I'm trying to understand what the combination of the two drafts, > > > -lm-pwe3-mpls-tp-gal-in-pw, and draft-nadeau-pwe3-vccv-2amounts to. > > > > > > So, I think I understood the draft-nadeau-pwe3-vccv-2 in that it's > > > saying use VCCV type 1 where possible and if not then use the new typ= e > > > 4, whereby in type 4 the exception mechanism is triggered by the use > > > of the GAL, and I appreciated the diagram in section 3 to lock this > > > is, so far so good. > > > > > > Now I read -pwe3-mpls-tp-gal-in-pw and I'm thinking , Ok these two > > > drafts could work together since this one is trying to lay the "legal > > > framework" i.e fix up the RFCs which mandated that the GAL could not > > > be used with the PW. > > > > > > Then I get hit with a brick wall in the form of the statements in the > > > last 2 paras of section 3 of tp-gal-in-pw which state. > > > > > > - Section 4.2 > > > 4.2>. > > > (GAL Applicability and Usage) in [RFC5586 > > > ], the > > > > > > original text: > > > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > > > > > > LSPs, Concatenated Segments of LSPs, and with Sections, and > > > > > > MUST NOT be used with PWs. It MUST always be at the bottom = of > > > > > > the label stack (i.e., S bit set to 1). However, in other M= PL=3D > S > > > > > > environments, this document places no restrictions on where > > > > > > the GAL may appear within the label stack or its use with P= Ws=3D > . > > > > > > is replaced by: > > > > > > In MPLS-TP, the GAL MUST be used with packets on a G-ACh on > > > > > > LSPs, Concatenated Segments of LSPs, and with Sections, and > > > > > > MAY be used with PWs. It MUST always be at the bottom of th= e > > > > > > label stack (i.e., S bit set to 1). However, in other MPLS > > > > > > environments, this document places no restrictions on where > > > > > > the GAL may appear within the label stack. > > > > > > It's the bit about the GAL MUST be at the bottom of the label stack, > > > this is clearly inconsistent with what is proposed in the > > > draft-nadeau-pwe3 where one can clearly see the GAL above the PW labe= l > > > and if one has to use a GAL with a PW this would be the place to put= i=3D > t, > > > > > > Now I can hear you saying "oh but look at the text below this, where > > > we state .."However, in other MPLS environments , this document place= s > > > no restrictions on where the GAL may appear within the label stack. > > > This is consistent with draft-nadeau " In which case I'd retort wit= h > > > ; what are we to do for PWs in MPLS-TP, since what's in draft-nadea= u > > > would not be allowed ? > > > > > > Clarification /explanation appreciated. > > > > > > Cheers > > > > > > Rob Rennison > > > > [snipped ...]= From curtis@occnc.com Sun Mar 27 12:00:29 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5B3F3A6950; Sun, 27 Mar 2011 12:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 M+IFinKuQuqi; Sun, 27 Mar 2011 12:00:26 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 3C7B13A68F8; Sun, 27 Mar 2011 12:00:25 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p2RJ1j3k011592; Sun, 27 Mar 2011 15:01:45 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201103271901.p2RJ1j3k011592@harbor.orleans.occnc.com> To: Alexander Vainshtein From: Curtis Villamizar In-reply-to: Your message of "Sat, 26 Mar 2011 08:39:33 +0200." Date: Sun, 27 Mar 2011 15:01:45 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" , "lihan@chinamobile.com" , pwe3 , HUANG Feng F , Robert Rennison Subject: Re: [mpls] [PWE3] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 19:00:30 -0000 Sasha, Thanks for trimming. I further trimmed and also dropped mpls-tp. This email has suggested change to the internet-draft below. It is important that any proposal to use GAL with PW not break traceroute on the containing LSP. Since a goal is to also suport MS-PW (as you point out below) and LSP hierarchy, an LSR needs to be able to forward payload containing GAL. See inline to keep the context. Btw - the new name of the document is: draft-ietf-pwe3-mpls-tp-gal-in-pw-00.txt Another suggestion is why not drop the -TP from the title. GAL applies to all MPLS, not just -TP. Curtis In message Alexander Vainshtein writes: > > Curtis, > Please see inline below. I've snipped the text that is not relevant > to my comment. > > Regards, > Sasha > > ________________________________________ > From: curtis@occnc.com [curtis@occnc.com] > Sent: Saturday, March 26, 2011 4:02 AM > To: Alexander Vainshtein > Cc: Greg Mirsky; curtis@occnc.com; Robert Rennison; mpls@ietf.org; mpls-tp@ietf.org; lihan@chinamobile.com; pwe3; HUANG Feng F > Subject: Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > In message > Alexander Vainshtein writes: > > > ... snipped ... > >> And, last but not least, if we decide to allow GAL in the middle > >> of the label stack > >> (overriding RFC 5586 and RFC 5960), we must also define how a > >> pack et with GAL > >> in the middle of the label stack is forwarded when GAL is exposed, > >> similar to what has been done in RFC 3032 for RAL. > >> > >> My 2c, > >> Sasha > > > If GAL is encountered, then it is processed just as it would be if TTL > > was set high and GAL was encountered as a result of the final POP in a > > containing LSP exposing only the GAL. The G-Ach is after the bottom > > of stack, where ever bottom of stack is found. > > > Curtis > > IMHO this would not work for, say MS-PWs with GAL above the PW label > as proposed in draft-nadeu. A few simple rules would work for LSP ping (not using TTL), LSP traceroute (using TTL), PW ping (including MS-PW, not using TTL), and MS-PW traceroute (using TTL to identify the set of S-PE). original (rfc5586.txt): In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. Where the GAL is at the bottom of the label stack (i.e., S bit set to 1), then it MUST always be followed by an ACH. The GAL MUST NOT appear in the label stack when transporting normal user-plane packets. Furthermore, when present, the GAL MUST NOT appear more than once in the label stack. replacement: In MPLS and MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections. GAL MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). GAL must appear immediately below the label for which a G-Ach is associated. The ingress SHOULD determine whether labels below GAL are supported by intermediate and egress LSR, otherwise GAL must also be at the bottom of the stack. The GAL MUST NOT be added to normal user-plane packets. User-plane packets which already contain GAL may be transported. When present, the GAL MUST NOT appear more than once in the label stack. At some later point in the document (could be section 3 and 4) add: Backwards compatibility: In order to insure that LSR which strictly conform to [RFC5586] and require that GAL be on the bottom of the stack, an ingress SHOULD determine whether all intermediate LSR and the egress LSR support labels after the GAL label. <<< add mechanism to advertise capability here or disclaimer that it is elsewere in some ISIS or OSPF extensions >>> Rules for handling GAL and TTL expired with GAL: GAL MUST be place directly beneath label for the LSP or PW for which the channel is relevant. Additional labels MAY be placed below GAL to affect packet entropy based decisions at multipoint links such as link bundles and Ethernet LAG. See [Backwards compatibility] for limitations on labels below GAL. LSR using label stack based packet entropy based decisions at multipoint links SHOULD ignore a GAL label for the purpose of entropy harvesting and continue entropy harvesting as though GAL were not present. When processing TTL Expiration on a packet, if the label immediately following is GAL, then a ACH MUST be immediately below the bottom of the MSPL stack and the ACH must be processed. When a LSP POP or PW POP occurs, if the next label is GAL, then a ACH MUST be immediately below the bottom of the MSPL stack and the ACH must be processed. Note that for PW, GAL is after the PW label and before the fat-pw label (if present). We also need to change the security section a bit. Refer to [RFC5586] for general MPLS security considerations. GAL in user payload must be forwarded to support GAL at a client layer. If an LSR interprets GAL at the bottom of stack to be relevant to a G-Ach for the label for which a TTL has expired, then a client layer G-Ach payload may be applied to a server layer. Use of the uniform model, or a pipe model TTL set too low with an attack which increases hop count (physical attack), plus an LSR that erroneously interprets GAL anywhere in the stack or at bottom of stack to be a G-Ach at the layer for which TTL has expired, provides a low probability attack vector. This attack vector would only exist if intermediate LSR on the path interpretted TTL anywhere in the stack or at bottom of stack as their own G-Ach. This document requires that the GAL only be considered if it is immediately following a TTL expire or POP. [RFC5586] is silent on forwarding (or not forwarding packets contraining GAL at the ingress to a hierarchical LSP, and is unclear as to whether TTL expired can be applied to GAL at the bottom of stack well below the label for which TTL expired. The vulnerability is associated with the behaviour defined in [RFC5586] and would be fixed if all LSR conformed to the updates to [RFC5586] in this document. The potential for this attack vector to become exploitable as a result of an older LSR which adheres only to [RFC5586] can be eliminated by offering an option to block forwarding of traffic containing GAL if the backward compatibility check defined in [Backwards compatibility] reveals intermediate or egres LSR not advertising the capability defined in this document. LSR SHOULD provide such an option. From curtis@occnc.com Sun Mar 27 13:37:49 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C22628C13E for ; Sun, 27 Mar 2011 13:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 VjRk4B63Cjy3 for ; Sun, 27 Mar 2011 13:37:47 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 6DA273A6943 for ; Sun, 27 Mar 2011 13:37:47 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p2RKd7xX028798; Sun, 27 Mar 2011 16:39:07 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201103272039.p2RKd7xX028798@harbor.orleans.occnc.com> To: Adrian.Farrel@huawei.com From: Curtis Villamizar In-reply-to: Your message of "Fri, 25 Mar 2011 17:42:31 BST." <019101cbeb0b$a3abe430$eb03ac90$@huawei.com> Date: Sun, 27 Mar 2011 16:39:07 -0400 Sender: curtis@occnc.com Cc: mpls@ietf.org Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 20:37:49 -0000 In message <019101cbeb0b$a3abe430$eb03ac90$@huawei.com> Adrian Farrel writes: > > FYI > > > > This draft should be discussed in Prague. > > There is 30 minutes allocated to this topic in the Routing Area Open > Meeting. Wednesday 13:00 > > Adrian Adrian, I suggest that we approach this draft any liason but treating with its contents at face value and pointing out how this sort of action would not fit into the IETF process in general, the IETF process for MPLS and MPLS-TP agreed to by ITU. Curtis draft-tsb-mpls-tp-ach-ptn-00, "Assignment of an Associated Channel Type for Packet Transport Network Applications" is asking for an identifier to address a perceived layering problem related to MPLS-TP OAM being jointly defined by IETF and ITU. MPLS-TP allows layering in the data plane using multiple labels, one per layer, in addition to any link layer below MPLS. Existing MPLS and PW mechansisms support this layering and support an OAM instance per layer. In addition there are specific mechanisms being defined within the IETF to provide interworking with PW associated channels of various types. This work is draft-ietf-pwe3-mpls-eth-oam-iwk-04, "PLS and Ethernet OAM Interworking" and draft-ietf-pwe3-oam-msg-map-14 "Pseudowire (PW) OAM Message Mapping". The latter covers most legacy protocols such as ATM, FR, and low speed TDM, plus others and has completed WG last call. A key assertion of draft-tsb-mpls-tp-ach-ptn-00 is that more than one OAM instance is needed per layer. The following two paragraphs are in conflict with MPLS-TP RFCs published to date. When MPLS-TP is deployed in PTN environment, application specific mechanisms (e.g., OAM) are required to allow service providers retaining the same operational experience in the MPLS-TP network as they had in their existing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN) networks. When MPLS-TP is deployed in other environments, e.g. in a Packet Switched Network (PSN), application specific mechanisms (e.g., OAM) are required to allow service providers retaining the same operational experience in the MPLS-TP network as they had in their existing IP and MPLS networks. The MPLS-TP OAM is defined as supporting the capabilities of existing transport technologies, though using different protocol mechanisms that are not specific to any particular link layer. The following statement proposes to break existing agreements between ITU and IETF and deviate from existing IETF standards. Allocation of one Associated Channel Type value will allow ITU-T to develop the tools required to address the unique needs of PTN application and will make more efficient use of the resources of both organizations while providing a mechanism to prevent the accidental interconnection between PTN and PSN application specific tools. The use of this code point fully complies with the framework and architecture for MPLS-TP. This document proposes that there is a new requirement and proposes that the IETF delegate the ITU to come up with a solution, with no further input from IETF. The normal process within IETF is to bring a protocol through the standardization process to some level of standardization and in the final steps of that process replace the IANA considerations section with code points allocated by IANA. Not only is this a deviation from this process but no completed protocol is defined or referenced in this document for which to assign a code point. The distinction between a PTN and PSN is defined in this draft-tsb-mpls-tp-ach-ptn-00 and there is in fact no concensus that such a distinction exists. Section 5 of draft-tsb-mpls-tp-ach-ptn-00 make the assertion that separation is needed between a PTN and a PSN and provides no justification other than figures which attempt to illustrate a distinction. Even assuming that the assertion that a distinction exists between a PTN and a PSN, and that multiple instances of OAM are needed, this does not justify multiple instances of different protocols, it would if such a requirement existed, justify two instance, which could be of the same protocol. Regardless as to whether two instances were of the same protocol, the same protocol with extension to address some yet unstated requirement of PTN that differs from PSN, or whether some yet unstated requirement of PTN that differs from PSN so greatly as to justify a different OAM protocol, those requirements must be stated in IETF documents and any protocol changes to MPLS made within the IETF process as per agreement among IETF and ITU-T. Finally, the motivation for this request from ITU is speculated to be driven primarily by perceived compatibility issues with pre-standard implementations of T-MPLS. This motivation may be reflected in the following statements in draft-tsb-mpls-tp-ach-ptn-00. 1.1. PTN Application Description In this application MPLS-TP will be used to add packet transport capability to an existing circuit switched (SDH/OTN) transport network. Note that in many such networks Ethernet technology has been deployed to address some of these needs, also that Ethernet is a primary packet transport service. The primary requirements are driven by a desire for compatibility with the existing transport network operational processes and in particular compatibility with the existing OAM mechanisms. Interworking with legacy ATM, FR, low speed TDM, and SONET is addressed by draft-ietf-pwe3-oam-msg-map-14 "Pseudowire (PW) OAM Message Mapping". Interworking with Ethernet is addressed by draft-ietf-pwe3-mpls-eth-oam-iwk-04, "PLS and Ethernet OAM Interworking". If the motivation behind draft-tsb-mpls-tp-ach-ptn-00 is to address perceived compatibility issues with pre-standard implementations of T-MPLS, then that requirement should be stated. If so, perhaps a more productive approach would be to document transition issues, and propose any temporary interworking capability that would be needed to accommodate a transition from pre-standards T-MPLS OAM to MPLS-TP OAM. Work toward defining requirements for a transition from pre-standards T-MPLS OAM to MPLS-TP OAM and work toward providing guidance or if necessary transitional protocol interworking extensions required to support such a transition can and should be undertaken in the IETF. From Adrian.Farrel@huawei.com Mon Mar 28 01:23:19 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEF3F3A6915 for ; Mon, 28 Mar 2011 01:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, 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 VVmDrJBTzes6 for ; Mon, 28 Mar 2011 01:23:08 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id F38163A6912 for ; Mon, 28 Mar 2011 01:23:07 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIR005XEE186N@usaga01-in.huawei.com> for mpls@ietf.org; Mon, 28 Mar 2011 03:24:45 -0500 (CDT) Received: from 950129200 (dhcp-15a5.meeting.ietf.org [130.129.21.165]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIR00HVOE17VP@usaga01-in.huawei.com> for mpls@ietf.org; Mon, 28 Mar 2011 03:24:44 -0500 (CDT) Date: Mon, 28 Mar 2011 10:24:41 +0200 From: Adrian Farrel In-reply-to: <201103272039.p2RKd7xX028798@harbor.orleans.occnc.com> To: curtis@occnc.com Message-id: <030801cbed21$97b953c0$c72bfb40$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AQK2Zm4tzdU7lVIRX51Wl1ywMUmX2JJtdcHg References: "Your message of Fri, 25 Mar 2011 17:42:31 BST." <019101cbeb0b$a3abe430$eb03ac90$@huawei.com> <201103272039.p2RKd7xX028798@harbor.orleans.occnc.com> Cc: mpls@ietf.org Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 08:23:20 -0000 Hi Curtis, Thanks for your thoughts. I agree that we must treat this draft as we would treat any other draft, and that we should treat the associated liaison as we treat all liaisons. Furthermore, we have no option but to treat drafts and liaisons at face value. The slides for Wednesday's Routing Area Open Meeting have been posted. Thanks, Adrian > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: 27 March 2011 22:39 > To: Adrian.Farrel@huawei.com > Cc: mpls@ietf.org > Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn > > > In message <019101cbeb0b$a3abe430$eb03ac90$@huawei.com> > Adrian Farrel writes: > > > > FYI > > > > > > This draft should be discussed in Prague. > > > > There is 30 minutes allocated to this topic in the Routing Area Open > > Meeting. Wednesday 13:00 > > > > Adrian > > > Adrian, > > I suggest that we approach this draft any liason but treating with its > contents at face value and pointing out how this sort of action would > not fit into the IETF process in general, the IETF process for MPLS > and MPLS-TP agreed to by ITU. > > Curtis > > > > draft-tsb-mpls-tp-ach-ptn-00, "Assignment of an Associated Channel > Type for Packet Transport Network Applications" is asking for an > identifier to address a perceived layering problem related to MPLS-TP > OAM being jointly defined by IETF and ITU. > > MPLS-TP allows layering in the data plane using multiple labels, one > per layer, in addition to any link layer below MPLS. Existing MPLS > and PW mechansisms support this layering and support an OAM instance > per layer. > > In addition there are specific mechanisms being defined within the > IETF to provide interworking with PW associated channels of various > types. This work is draft-ietf-pwe3-mpls-eth-oam-iwk-04, "PLS and > Ethernet OAM Interworking" and draft-ietf-pwe3-oam-msg-map-14 > "Pseudowire (PW) OAM Message Mapping". The latter covers most legacy > protocols such as ATM, FR, and low speed TDM, plus others and has > completed WG last call. > > A key assertion of draft-tsb-mpls-tp-ach-ptn-00 is that more than one > OAM instance is needed per layer. > > The following two paragraphs are in conflict with MPLS-TP RFCs > published to date. > > When MPLS-TP is deployed in PTN environment, application specific > mechanisms (e.g., OAM) are required to allow service providers > retaining the same operational experience in the MPLS-TP network as > they had in their existing Synchronous Optical Network/Synchronous > Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN) > networks. > > When MPLS-TP is deployed in other environments, e.g. in a Packet > Switched Network (PSN), application specific mechanisms (e.g., OAM) > are required to allow service providers retaining the same > operational experience in the MPLS-TP network as they had in their > existing IP and MPLS networks. > > The MPLS-TP OAM is defined as supporting the capabilities of existing > transport technologies, though using different protocol mechanisms > that are not specific to any particular link layer. > > The following statement proposes to break existing agreements between > ITU and IETF and deviate from existing IETF standards. > > Allocation of one Associated Channel Type value will allow ITU-T > to develop the tools required to address the unique needs of PTN > application and will make more efficient use of the resources of > both organizations while providing a mechanism to prevent the > accidental interconnection between PTN and PSN application > specific tools. The use of this code point fully complies with > the framework and architecture for MPLS-TP. > > > This document proposes that there is a new requirement and proposes > that the IETF delegate the ITU to come up with a solution, with no > further input from IETF. > > The normal process within IETF is to bring a protocol through the > standardization process to some level of standardization and in the > final steps of that process replace the IANA considerations section > with code points allocated by IANA. > > Not only is this a deviation from this process but no completed > protocol is defined or referenced in this document for which to assign > a code point. > > The distinction between a PTN and PSN is defined in this > draft-tsb-mpls-tp-ach-ptn-00 and there is in fact no concensus that > such a distinction exists. > > Section 5 of draft-tsb-mpls-tp-ach-ptn-00 make the assertion that > separation is needed between a PTN and a PSN and provides no > justification other than figures which attempt to illustrate a > distinction. > > Even assuming that the assertion that a distinction exists between a > PTN and a PSN, and that multiple instances of OAM are needed, this > does not justify multiple instances of different protocols, it would > if such a requirement existed, justify two instance, which could be of > the same protocol. > > Regardless as to whether two instances were of the same protocol, the > same protocol with extension to address some yet unstated requirement > of PTN that differs from PSN, or whether some yet unstated requirement > of PTN that differs from PSN so greatly as to justify a different OAM > protocol, those requirements must be stated in IETF documents and any > protocol changes to MPLS made within the IETF process as per agreement > among IETF and ITU-T. > > Finally, the motivation for this request from ITU is speculated to be > driven primarily by perceived compatibility issues with pre-standard > implementations of T-MPLS. This motivation may be reflected in the > following statements in draft-tsb-mpls-tp-ach-ptn-00. > > 1.1. PTN Application Description > > In this application MPLS-TP will be used to add packet transport > capability to an existing circuit switched (SDH/OTN) transport > network. Note that in many such networks Ethernet technology has > been deployed to address some of these needs, also that Ethernet is > a primary packet transport service. The primary requirements are > driven by a desire for compatibility with the existing transport > network operational processes and in particular compatibility with > the existing OAM mechanisms. > > Interworking with legacy ATM, FR, low speed TDM, and SONET is > addressed by draft-ietf-pwe3-oam-msg-map-14 "Pseudowire (PW) OAM > Message Mapping". Interworking with Ethernet is addressed by > draft-ietf-pwe3-mpls-eth-oam-iwk-04, "PLS and Ethernet OAM > Interworking". > > If the motivation behind draft-tsb-mpls-tp-ach-ptn-00 is to address > perceived compatibility issues with pre-standard implementations of > T-MPLS, then that requirement should be stated. If so, perhaps a more > productive approach would be to document transition issues, and > propose any temporary interworking capability that would be needed to > accommodate a transition from pre-standards T-MPLS OAM to MPLS-TP OAM. > > Work toward defining requirements for a transition from pre-standards > T-MPLS OAM to MPLS-TP OAM and work toward providing guidance or if > necessary transitional protocol interworking extensions required to > support such a transition can and should be undertaken in the IETF. From eric.gray@ericsson.com Mon Mar 28 02:41:29 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695B73A6940 for ; Mon, 28 Mar 2011 02:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.187 X-Spam-Level: X-Spam-Status: No, score=-5.187 tagged_above=-999 required=5 tests=[AWL=1.413, 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 tFVWx7gJtvtN for ; Mon, 28 Mar 2011 02:41:28 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 545AE3A681B for ; Mon, 28 Mar 2011 02:41:28 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p2S9h4wQ019204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Mar 2011 04:43:05 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 28 Mar 2011 05:43:03 -0400 From: Eric Gray To: Rolf Winter Date: Mon, 28 Mar 2011 05:43:01 -0400 Thread-Topic: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand-cv-03 Thread-Index: AQHL42huOL0wlOx/O0GvtamNNTMxZZQ5EvtwgAl5cFA= Message-ID: References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> 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@ietf.org" Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 09:41:29 -0000 Rolf, With regard to the use of SHOULD (verses MUST) - the intent (according to RFC 2119 - see the quote below) is consistent with this case. If - for some reason - one had a really good reason to use IP addressing in some specific case, one could take steps to make IP addressing available. This could be said to introduce a logical disconnect, but we are saved from going down that path by the fact that the statement also includes the case where (for some reason) there is a case in which some other addressing scheme might be preferred. In many of the cases where another addressing scheme may be preferred, it is still possible (in fact likely) that IP addressing is available. Otherwise, it would not have been necessary to distinguish this case from the one in which IP addressing is not available. For the case where IP addressing is not the preferred mode, we are recommending a mode in which it is not necessary. With regard to having addresses located in the same place, this protocol is meant for connectivity testing on an on-demand=20 basis and is therefore not optimized for processing in hardware. Whether addresses or identifiers, if we are talking about TLV contents, there are issues with trying to guarantee location of specific content, because of the fact that the TLV in question will probably follow other TLVs - thus making locations difficult to predict in any case. With regard to needing more text on per-interface MIPs, do you have specific suggestions as to what text we might add? I understand (from discussion with WG chairs) that we are not allowed to explicitly address last call comments during the IETF meeting in Prague, because the last call is still ongoing at that time. -- Eric PS - >From RFC 2119 -=20 'SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to=20 ignore a particular item, but the full implications must=20 be understood and carefully weighed before choosing a=20 different course.' -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rol= f Winter Sent: Tuesday, March 22, 2011 4:57 AM To: loa@pi.nu; mpls@ietf.org Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand-= cv-03 Hi, some comments below: Section 1.3 says: " In certain MPLS-TP deployment scenarios IP addressing m= ight not be available or it may be preferred to use some form of non-IP encapsulation for On-demand CV, route tracing and BFD packets. In such scenarios, On-demand CV and/or route tracing SHOULD be run without IP addressing..." I am not sure the "SHOULD" is right here. If no IP addressing is available,= this thing MUST be run without IP addressing, mustn't it? I think some additional text regarding per-interface MIP addressing would b= e nice. As far as I understand the document, all TLVs will be inside the LS= P ping packet (rather than as ACH TLVs). Some people had concerns earlier, that addressing information should be in = a fixed location for easier processing. Is this the case here I wonder? It would be nice if you could address this in your presentation in Prague. Thanks, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > loa@pi.nu > Sent: Mittwoch, 16. M=E4rz 2011 00:26 > To: mpls@ietf.org > Cc: MPLS-TP ad hoc team > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand- > cv-03 >=20 > Working Group, >=20 > this is to start a 3 week working group last call on >=20 > draft-ietf-mpls-tp-on-demand-cv-03 >=20 > Please send comments to the working group mailing list > mpls@ietf.org >=20 > The working group last call ends on April 8, 2011. >=20 > /Loa >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Rolf.Winter@neclab.eu Mon Mar 28 03:17:40 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2054F3A6A53 for ; Mon, 28 Mar 2011 03:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.228 X-Spam-Level: X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 ySSXqNssh6f2 for ; Mon, 28 Mar 2011 03:17:39 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id D36673A6A31 for ; Mon, 28 Mar 2011 03:17:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A2A0F2800018E; Mon, 28 Mar 2011 12:20:32 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1B5IS+mc3ku; Mon, 28 Mar 2011 12:20:32 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7DA7628000171; Mon, 28 Mar 2011 12:20:22 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.246]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Mon, 28 Mar 2011 12:19:05 +0200 From: Rolf Winter To: Eric Gray Thread-Topic: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand-cv-03 Thread-Index: AQHL42huOL0wlOx/O0GvtamNNTMxZZQ5EvtwgAl5cFCAAAu7gA== Date: Mon, 28 Mar 2011 10:19:04 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.201] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 10:17:40 -0000 Hi, I still think there is a logical error. Let me explain. In case there is no= IP you simply cannot use it. You say you could enable IP but then that is = not a case where there is no IP. In order to be constructive here is a text= change suggestion: "In certain MPLS-TP deployment scenarios IP addressing might not be availab= le. In those cases On-demand CV and/or route tracing MUST be run without IP= addressing, using the ACH channel type specified in Section 3. In other ca= ses it might be available, however, it may be preferred to use some form of= non-IP encapsulation. In those cases, the procedures as outlined in sectio= n 3 SHOULD also be used." Regarding the per-interface MIP discussion. The HW aspect also popped up in= the PWE3 session and I think this is an important consideration, in partic= ular for OAM. Even if we talk about TLVs, we could make it a MUST that an A= ddress TLV is always the first one to appear. If you can facilitate an easy= implementation in hardware, I see no reason to deliberately not do it. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Montag, 28. M=E4rz 2011 11:43 > To: Rolf Winter > Cc: loa@pi.nu; mpls@ietf.org > Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > demand-cv-03 >=20 > Rolf, >=20 > With regard to the use of SHOULD (verses MUST) - the intent > (according to RFC 2119 - see the quote below) is consistent with > this case. If - for some reason - one had a really good reason to > use IP addressing in some specific case, one could take steps to > make IP addressing available. >=20 > This could be said to introduce a logical disconnect, but we > are saved from going down that path by the fact that the statement > also includes the case where (for some reason) there is a case in > which some other addressing scheme might be preferred. In many of > the cases where another addressing scheme may be preferred, it is > still possible (in fact likely) that IP addressing is available. >=20 > Otherwise, it would not have been necessary to distinguish > this case from the one in which IP addressing is not available. >=20 > For the case where IP addressing is not the preferred mode, > we are recommending a mode in which it is not necessary. >=20 > With regard to having addresses located in the same place, > this protocol is meant for connectivity testing on an on-demand > basis and is therefore not optimized for processing in hardware. >=20 > Whether addresses or identifiers, if we are talking about > TLV contents, there are issues with trying to guarantee location > of specific content, because of the fact that the TLV in question > will probably follow other TLVs - thus making locations difficult > to predict in any case. >=20 > With regard to needing more text on per-interface MIPs, do > you have specific suggestions as to what text we might add? >=20 > I understand (from discussion with WG chairs) that we are > not allowed to explicitly address last call comments during the > IETF meeting in Prague, because the last call is still ongoing > at that time. >=20 > -- > Eric >=20 > PS - > From RFC 2119 - > 'SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to > ignore a particular item, but the full implications must > be understood and carefully weighed before choosing a > different course.' >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rolf Winter > Sent: Tuesday, March 22, 2011 4:57 AM > To: loa@pi.nu; mpls@ietf.org > Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > demand-cv-03 >=20 > Hi, >=20 > some comments below: >=20 > Section 1.3 says: " In certain MPLS-TP deployment scenarios IP > addressing might not be > available or it may be preferred to use some form of non-IP > encapsulation for On-demand CV, route tracing and BFD packets. In > such scenarios, On-demand CV and/or route tracing SHOULD be run > without IP addressing..." >=20 > I am not sure the "SHOULD" is right here. If no IP addressing is > available, this thing MUST be run without IP addressing, mustn't it? >=20 > I think some additional text regarding per-interface MIP addressing > would be nice. As far as I understand the document, all TLVs will be > inside the LSP ping packet (rather than as ACH TLVs). >=20 > Some people had concerns earlier, that addressing information should be > in a fixed location for easier processing. Is this the case here I > wonder? >=20 > It would be nice if you could address this in your presentation in > Prague. >=20 > Thanks, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > loa@pi.nu > > Sent: Mittwoch, 16. M=E4rz 2011 00:26 > > To: mpls@ietf.org > > Cc: MPLS-TP ad hoc team > > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > demand- > > cv-03 > > > > Working Group, > > > > this is to start a 3 week working group last call on > > > > draft-ietf-mpls-tp-on-demand-cv-03 > > > > Please send comments to the working group mailing list > > mpls@ietf.org > > > > The working group last call ends on April 8, 2011. > > > > /Loa > > > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Mon Mar 28 04:40:20 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0A8A3A6808 for ; Mon, 28 Mar 2011 04:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.343 X-Spam-Level: X-Spam-Status: No, score=-5.343 tagged_above=-999 required=5 tests=[AWL=1.256, 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 yBk4FU1uWlAn for ; Mon, 28 Mar 2011 04:40:19 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 978CB3A67FA for ; Mon, 28 Mar 2011 04:40:18 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p2SBftaS021571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Mar 2011 06:41:55 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 28 Mar 2011 07:41:54 -0400 From: Eric Gray To: Rolf Winter Date: Mon, 28 Mar 2011 07:41:52 -0400 Thread-Topic: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand-cv-03 Thread-Index: AQHL42huOL0wlOx/O0GvtamNNTMxZZQ5EvtwgAl5cFCAAAu7gIAAFtzg Message-ID: References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> 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@ietf.org" Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 11:40:20 -0000 Rolf, The words you propose are okay with me. =20 I thought the MIP/interface and address location issues were separate. I've personally had problems with protocol specifications that require ordering of TLVs. In particular, this is not very robust in terms of "future-proofing." What happens if new TLVs=20 are added later on; for instance, suppose at some point we have multiple "address" TLVs? =20 Also, the fact that implementations are allowed to attach TLVs in any arbitrary order allows considerable flexibilty in=20 implementation. Messages can be built in arbitrarily many ways. This too can be a future-proofing issue. I would prefer not to start down the road of requiring a subset of TLVs to appear in a certain order, and saying we have one TLV that needs to be first is doing just that. -- Eric -----Original Message----- From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 Sent: Monday, March 28, 2011 6:19 AM To: Eric Gray Cc: mpls@ietf.org Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand-= cv-03 Importance: High Hi, I still think there is a logical error. Let me explain. In case there is no= IP you simply cannot use it. You say you could enable IP but then that is = not a case where there is no IP. In order to be constructive here is a text= change suggestion: "In certain MPLS-TP deployment scenarios IP addressing might not be availab= le. In those cases On-demand CV and/or route tracing MUST be run without IP= addressing, using the ACH channel type specified in Section 3. In other ca= ses it might be available, however, it may be preferred to use some form of= non-IP encapsulation. In those cases, the procedures as outlined in sectio= n 3 SHOULD also be used." Regarding the per-interface MIP discussion. The HW aspect also popped up in= the PWE3 session and I think this is an important consideration, in partic= ular for OAM. Even if we talk about TLVs, we could make it a MUST that an A= ddress TLV is always the first one to appear. If you can facilitate an easy= implementation in hardware, I see no reason to deliberately not do it. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Montag, 28. M=E4rz 2011 11:43 > To: Rolf Winter > Cc: loa@pi.nu; mpls@ietf.org > Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > demand-cv-03 >=20 > Rolf, >=20 > With regard to the use of SHOULD (verses MUST) - the intent > (according to RFC 2119 - see the quote below) is consistent with > this case. If - for some reason - one had a really good reason to > use IP addressing in some specific case, one could take steps to > make IP addressing available. >=20 > This could be said to introduce a logical disconnect, but we > are saved from going down that path by the fact that the statement > also includes the case where (for some reason) there is a case in > which some other addressing scheme might be preferred. In many of > the cases where another addressing scheme may be preferred, it is > still possible (in fact likely) that IP addressing is available. >=20 > Otherwise, it would not have been necessary to distinguish > this case from the one in which IP addressing is not available. >=20 > For the case where IP addressing is not the preferred mode, > we are recommending a mode in which it is not necessary. >=20 > With regard to having addresses located in the same place, > this protocol is meant for connectivity testing on an on-demand > basis and is therefore not optimized for processing in hardware. >=20 > Whether addresses or identifiers, if we are talking about > TLV contents, there are issues with trying to guarantee location > of specific content, because of the fact that the TLV in question > will probably follow other TLVs - thus making locations difficult > to predict in any case. >=20 > With regard to needing more text on per-interface MIPs, do > you have specific suggestions as to what text we might add? >=20 > I understand (from discussion with WG chairs) that we are > not allowed to explicitly address last call comments during the > IETF meeting in Prague, because the last call is still ongoing > at that time. >=20 > -- > Eric >=20 > PS - > From RFC 2119 - > 'SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to > ignore a particular item, but the full implications must > be understood and carefully weighed before choosing a > different course.' >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rolf Winter > Sent: Tuesday, March 22, 2011 4:57 AM > To: loa@pi.nu; mpls@ietf.org > Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > demand-cv-03 >=20 > Hi, >=20 > some comments below: >=20 > Section 1.3 says: " In certain MPLS-TP deployment scenarios IP > addressing might not be > available or it may be preferred to use some form of non-IP > encapsulation for On-demand CV, route tracing and BFD packets. In > such scenarios, On-demand CV and/or route tracing SHOULD be run > without IP addressing..." >=20 > I am not sure the "SHOULD" is right here. If no IP addressing is > available, this thing MUST be run without IP addressing, mustn't it? >=20 > I think some additional text regarding per-interface MIP addressing > would be nice. As far as I understand the document, all TLVs will be > inside the LSP ping packet (rather than as ACH TLVs). >=20 > Some people had concerns earlier, that addressing information should be > in a fixed location for easier processing. Is this the case here I > wonder? >=20 > It would be nice if you could address this in your presentation in > Prague. >=20 > Thanks, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > loa@pi.nu > > Sent: Mittwoch, 16. M=E4rz 2011 00:26 > > To: mpls@ietf.org > > Cc: MPLS-TP ad hoc team > > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > demand- > > cv-03 > > > > Working Group, > > > > this is to start a 3 week working group last call on > > > > draft-ietf-mpls-tp-on-demand-cv-03 > > > > Please send comments to the working group mailing list > > mpls@ietf.org > > > > The working group last call ends on April 8, 2011. > > > > /Loa > > > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From hideki.endo.es@hitachi.com Mon Mar 28 05:09:14 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3F33A68BB for ; Mon, 28 Mar 2011 05:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.462 X-Spam-Level: **** X-Spam-Status: No, score=4.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_BASE64_TEXT=1.753, SUBJ_RE_NUM=2.799] 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 GzPScX3dW5K2 for ; Mon, 28 Mar 2011 05:09:13 -0700 (PDT) Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by core3.amsl.com (Postfix) with ESMTP id C37883A68AF for ; Mon, 28 Mar 2011 05:09:12 -0700 (PDT) Received: from mlsv2.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id AD13C33CC3; Mon, 28 Mar 2011 21:10:49 +0900 (JST) Received: from mfilter1.hitachi.co.jp by mlsv2.hitachi.co.jp (8.13.1/8.13.1) id p2SCAnBx000464; Mon, 28 Mar 2011 21:10:49 +0900 Received: from vshuts4.hitachi.co.jp (vshuts4.hitachi.co.jp [10.201.6.80]) by mfilter1.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id p2SCAmeV012006; Mon, 28 Mar 2011 21:10:49 +0900 X-AuditID: b753bd60-a5abcba000004916-1b-4d907ac83cf0 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts4.hitachi.co.jp (Symantec Mail Security) with ESMTP id 79BD42042E0; Mon, 28 Mar 2011 21:10:48 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p2SCAmU21434522; Mon, 28 Mar 2011 21:10:48 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: multipart/mixed; boundary="GMAILSMTPBOUND01110328211045" To: , From: Date: Mon, 28 Mar 2011 21:10:31 +0900 References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> Priority: normal Importance: normal X400-Content-Identifier: X4D907AAA00000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28110328211018TUT] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mpls@ietf.org Subject: Re: [mpls] =?iso-8859-1?q?Working_Group_Las_Call_ondraft-ietf-mpls-tp?= =?iso-8859-1?q?-on-demand-cv-03?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:09:14 -0000 --GMAILSMTPBOUND01110328211045 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 SGkgRXJpYyBhbmQgUm9sZiwNCg0KSSdtIHNvcnJ5IGZvciBpbnRlcnJ1cHRpbmcuDQoNCkkg YWdyZWUgd2l0aCBSb2xmIHJlZ2FyZGluZyB0aGUgcGVyLWludGVyZmFjZSBNSVAgZGlzY3Vz c2lvbi4NCldlIGhhdmUgdG8gY29uc2lkZXIgdGhlIEhXIGltcGxlbWVudGF0aW9uIGFzcGVj dCwNCmJlY2F1c2UgdHJhcHBpbmcgb2YgYW4gT0FNIHBhY2tldCBpcyBIVyBydWxlL2Z1bmN0 aW9uYWxpdHkgZXZlbiBpbiByb3V0ZXJzLg0KDQpJZiBldmVyeSBPQU0gcGFja2V0IGlzIHRy YXBwZWQgdG8gQ1BVDQphbmQgdGhlIE9BTSBwYWNrZXRzIHdoaWNoIHNob3VsZCBOT1QgYmUg cHJvY2Vzc2VkIGluIHRoZSBJbnRlcmZhY2UNCmFyZSByZXR1cm5lZCB0byBEYXRhLXBsYW5l LA0KaXQgaXMgZGlmZmVyZW50IGZvcndhcmRpbmcgcGF0aCBmcm9tIHVzZXIgcGFja2V0cywN CndoaWNoIGlzIE5PVCB0aGUgQ29ubmVjdGl2aXR5IFZlcmlmaWNhdGlvbiBvZiB0aGUgdXNl ciBwYXRoLiANCg0KVGhlcmVmb3JlLCB3ZSBzaG91bGQgdGFrZSB0aGUgSFcgYXNwZWN0IGFu ZCBmbGV4aWJpbHR5IGludG8gYWNjb3VudCBjb25jdXJyZW50bHkuDQpJZiBhbiBhZGRyZXNz IFRMViBNVVNUIGJlIHRoZSBmaXJzdCBpbiBUTFZzLA0KaXQgaXMgZW5vdWdoIHRvIG1ha2Ug SFcgaW1wbGVtZW50YXRpb24gZWFzeS4NCg0KQlIsDQpIaWRla2kNCg0KDQoNCj5Sb2xmLA0K Pg0KPglUaGUgd29yZHMgeW91IHByb3Bvc2UgYXJlIG9rYXkgd2l0aCBtZS4gIA0KPg0KPglJ IHRob3VnaHQgdGhlIE1JUC9pbnRlcmZhY2UgYW5kIGFkZHJlc3MgbG9jYXRpb24gaXNzdWVz DQo+d2VyZSBzZXBhcmF0ZS4NCj4NCj4JSSd2ZSBwZXJzb25hbGx5IGhhZCBwcm9ibGVtcyB3 aXRoIHByb3RvY29sIHNwZWNpZmljYXRpb25zDQo+dGhhdCByZXF1aXJlIG9yZGVyaW5nIG9m IFRMVnMuICBJbiBwYXJ0aWN1bGFyLCB0aGlzIGlzIG5vdCB2ZXJ5DQo+cm9idXN0IGluIHRl cm1zIG9mICJmdXR1cmUtcHJvb2ZpbmcuIiAgV2hhdCBoYXBwZW5zIGlmIG5ldyBUTFZzIA0K PmFyZSBhZGRlZCBsYXRlciBvbjsgZm9yIGluc3RhbmNlLCBzdXBwb3NlIGF0IHNvbWUgcG9p bnQgd2UgaGF2ZQ0KPm11bHRpcGxlICJhZGRyZXNzIiBUTFZzPyAgDQo+DQo+CUFsc28sIHRo ZSBmYWN0IHRoYXQgaW1wbGVtZW50YXRpb25zIGFyZSBhbGxvd2VkIHRvIGF0dGFjaA0KPlRM VnMgaW4gYW55IGFyYml0cmFyeSBvcmRlciBhbGxvd3MgY29uc2lkZXJhYmxlIGZsZXhpYmls dHkgaW4gDQo+aW1wbGVtZW50YXRpb24uICBNZXNzYWdlcyBjYW4gYmUgYnVpbHQgaW4gYXJi aXRyYXJpbHkgbWFueSB3YXlzLg0KPlRoaXMgdG9vIGNhbiBiZSBhIGZ1dHVyZS1wcm9vZmlu ZyBpc3N1ZS4NCj4NCj4JSSB3b3VsZCBwcmVmZXIgbm90IHRvIHN0YXJ0IGRvd24gdGhlIHJv YWQgb2YgcmVxdWlyaW5nIGENCj5zdWJzZXQgb2YgVExWcyB0byBhcHBlYXIgaW4gYSBjZXJ0 YWluIG9yZGVyLCBhbmQgc2F5aW5nIHdlIGhhdmUNCj5vbmUgVExWIHRoYXQgbmVlZHMgdG8g YmUgZmlyc3QgaXMgZG9pbmcganVzdCB0aGF0Lg0KPg0KPi0tDQo+RXJpYw0KPg0KPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogUm9sZiBXaW50ZXIgW21haWx0bzpSb2xm LldpbnRlckBuZWNsYWIuZXVdIA0KPlNlbnQ6IE1vbmRheSwgTWFyY2ggMjgsIDIwMTEgNjox OSBBTQ0KPlRvOiBFcmljIEdyYXkNCj5DYzogbXBsc0BpZXRmLm9yZw0KPlN1YmplY3Q6IFJF OiBbbXBsc10gV29ya2luZyBHcm91cCBMYXMgQ2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAt b24tZGVtYW5kLWN2LTAzDQo+SW1wb3J0YW5jZTogSGlnaA0KPg0KPkhpLA0KPg0KPkkgc3Rp bGwgdGhpbmsgdGhlcmUgaXMgYSBsb2dpY2FsIGVycm9yLiBMZXQgbWUgZXhwbGFpbi4gSW4g Y2FzZSB0aGVyZSBpcyBubyBJUCB5b3Ugc2ltcGx5IGNhbm5vdCB1c2UgaXQuIFlvdSBzYXkg eW91IGNvdWxkIGVuYWJsZSBJUCBidXQgdGhlbiB0aGF0IGlzIG5vdCBhIGNhc2Ugd2hlcmUg dGhlcmUgaXMgbm8gSVAuIEluIG9yZGVyIHRvIGJlIGNvbnN0cnVjdGl2ZSBoZXJlIGlzIGEg dGV4dCBjaGFuZ2Ugc3VnZ2VzdGlvbjoNCj4NCj4iSW4gY2VydGFpbiBNUExTLVRQIGRlcGxv eW1lbnQgc2NlbmFyaW9zIElQIGFkZHJlc3NpbmcgbWlnaHQgbm90IGJlIGF2YWlsYWJsZS4g SW4gdGhvc2UgY2FzZXMgT24tZGVtYW5kIENWIGFuZC9vciByb3V0ZSB0cmFjaW5nIE1VU1Qg YmUgcnVuIHdpdGhvdXQgSVAgYWRkcmVzc2luZywgdXNpbmcgdGhlIEFDSCBjaGFubmVsIHR5 cGUgc3BlY2lmaWVkIGluIFNlY3Rpb24gMy4gSW4gb3RoZXIgY2FzZXMgaXQgbWlnaHQgYmUg YXZhaWxhYmxlLCBob3dldmVyLCBpdCBtYXkgYmUgcHJlZmVycmVkIHRvIHVzZSBzb21lIGZv cm0gb2Ygbm9uLUlQIGVuY2Fwc3VsYXRpb24uIEluIHRob3NlIGNhc2VzLCB0aGUgcHJvY2Vk dXJlcyBhcyBvdXRsaW5lZCBpbiBzZWN0aW9uIDMgU0hPVUxEIGFsc28gYmUgdXNlZC4iDQo+ DQo+UmVnYXJkaW5nIHRoZSBwZXItaW50ZXJmYWNlIE1JUCBkaXNjdXNzaW9uLiBUaGUgSFcg YXNwZWN0IGFsc28gcG9wcGVkIHVwIGluIHRoZSBQV0UzIHNlc3Npb24gYW5kIEkgdGhpbmsg dGhpcyBpcyBhbiBpbXBvcnRhbnQgY29uc2lkZXJhdGlvbiwgaW4gcGFydGljdWxhciBmb3Ig T0FNLiBFdmVuIGlmIHdlIHRhbGsgYWJvdXQgVExWcywgd2UgY291bGQgbWFrZSBpdCBhIE1V U1QgdGhhdCBhbiBBZGRyZXNzIFRMViBpcyBhbHdheXMgdGhlIGZpcnN0IG9uZSB0byBhcHBl YXIuIElmIHlvdSBjYW4gZmFjaWxpdGF0ZSBhbiBlYXN5IGltcGxlbWVudGF0aW9uIGluIGhh cmR3YXJlLCBJIHNlZSBubyByZWFzb24gdG8gZGVsaWJlcmF0ZWx5IG5vdCBkbyBpdC4NCj4N Cj5CZXN0LA0KPg0KPlJvbGYNCj4NCj4NCj5ORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3Rl cmVkIE9mZmljZTogTkVDIEhvdXNlLCAxIFZpY3RvcmlhIFJvYWQsIExvbmRvbiBXMyA2Qkwg fCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgMjgzMjAxNCANCj4NCj4NCj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBFcmljIEdyYXkgW21haWx0bzplcmljLmdyYXlA ZXJpY3Nzb24uY29tXQ0KPj4gU2VudDogTW9udGFnLCAyOC4gTeRyeiAyMDExIDExOjQzDQo+ PiBUbzogUm9sZiBXaW50ZXINCj4+IENjOiBsb2FAcGkubnU7IG1wbHNAaWV0Zi5vcmcNCj4+ IFN1YmplY3Q6IFJFOiBbbXBsc10gV29ya2luZyBHcm91cCBMYXMgQ2FsbCBvbiBkcmFmdC1p ZXRmLW1wbHMtdHAtb24tDQo+PiBkZW1hbmQtY3YtMDMNCj4+IA0KPj4gUm9sZiwNCj4+IA0K Pj4gCVdpdGggcmVnYXJkIHRvIHRoZSB1c2Ugb2YgU0hPVUxEICh2ZXJzZXMgTVVTVCkgLSB0 aGUgaW50ZW50DQo+PiAoYWNjb3JkaW5nIHRvIFJGQyAyMTE5IC0gc2VlIHRoZSBxdW90ZSBi ZWxvdykgaXMgY29uc2lzdGVudCB3aXRoDQo+PiB0aGlzIGNhc2UuICBJZiAtIGZvciBzb21l IHJlYXNvbiAtIG9uZSBoYWQgYSByZWFsbHkgZ29vZCByZWFzb24gdG8NCj4+IHVzZSBJUCBh ZGRyZXNzaW5nIGluIHNvbWUgc3BlY2lmaWMgY2FzZSwgb25lIGNvdWxkIHRha2Ugc3RlcHMg dG8NCj4+IG1ha2UgSVAgYWRkcmVzc2luZyBhdmFpbGFibGUuDQo+PiANCj4+IAlUaGlzIGNv dWxkIGJlIHNhaWQgdG8gaW50cm9kdWNlIGEgbG9naWNhbCBkaXNjb25uZWN0LCBidXQgd2UN Cj4+IGFyZSBzYXZlZCBmcm9tIGdvaW5nIGRvd24gdGhhdCBwYXRoIGJ5IHRoZSBmYWN0IHRo YXQgdGhlIHN0YXRlbWVudA0KPj4gYWxzbyBpbmNsdWRlcyB0aGUgY2FzZSB3aGVyZSAoZm9y IHNvbWUgcmVhc29uKSB0aGVyZSBpcyBhIGNhc2UgaW4NCj4+IHdoaWNoIHNvbWUgb3RoZXIg YWRkcmVzc2luZyBzY2hlbWUgbWlnaHQgYmUgcHJlZmVycmVkLiAgSW4gbWFueSBvZg0KPj4g dGhlIGNhc2VzIHdoZXJlIGFub3RoZXIgYWRkcmVzc2luZyBzY2hlbWUgbWF5IGJlIHByZWZl cnJlZCwgaXQgaXMNCj4+IHN0aWxsIHBvc3NpYmxlIChpbiBmYWN0IGxpa2VseSkgdGhhdCBJ UCBhZGRyZXNzaW5nIGlzIGF2YWlsYWJsZS4NCj4+IA0KPj4gCU90aGVyd2lzZSwgaXQgd291 bGQgbm90IGhhdmUgYmVlbiBuZWNlc3NhcnkgdG8gZGlzdGluZ3Vpc2gNCj4+IHRoaXMgY2Fz ZSBmcm9tIHRoZSBvbmUgaW4gd2hpY2ggSVAgYWRkcmVzc2luZyBpcyBub3QgYXZhaWxhYmxl Lg0KPj4gDQo+PiAJRm9yIHRoZSBjYXNlIHdoZXJlIElQIGFkZHJlc3NpbmcgaXMgbm90IHRo ZSBwcmVmZXJyZWQgbW9kZSwNCj4+IHdlIGFyZSByZWNvbW1lbmRpbmcgYSBtb2RlIGluIHdo aWNoIGl0IGlzIG5vdCBuZWNlc3NhcnkuDQo+PiANCj4+IAlXaXRoIHJlZ2FyZCB0byBoYXZp bmcgYWRkcmVzc2VzIGxvY2F0ZWQgaW4gdGhlIHNhbWUgcGxhY2UsDQo+PiB0aGlzIHByb3Rv Y29sIGlzIG1lYW50IGZvciBjb25uZWN0aXZpdHkgdGVzdGluZyBvbiBhbiBvbi1kZW1hbmQN Cj4+IGJhc2lzIGFuZCBpcyB0aGVyZWZvcmUgbm90IG9wdGltaXplZCBmb3IgcHJvY2Vzc2lu ZyBpbiBoYXJkd2FyZS4NCj4+IA0KPj4gCVdoZXRoZXIgYWRkcmVzc2VzIG9yIGlkZW50aWZp ZXJzLCBpZiB3ZSBhcmUgdGFsa2luZyBhYm91dA0KPj4gVExWIGNvbnRlbnRzLCB0aGVyZSBh cmUgaXNzdWVzIHdpdGggdHJ5aW5nIHRvIGd1YXJhbnRlZSBsb2NhdGlvbg0KPj4gb2Ygc3Bl Y2lmaWMgY29udGVudCwgYmVjYXVzZSBvZiB0aGUgZmFjdCB0aGF0IHRoZSBUTFYgaW4gcXVl c3Rpb24NCj4+IHdpbGwgcHJvYmFibHkgZm9sbG93IG90aGVyIFRMVnMgLSB0aHVzIG1ha2lu ZyBsb2NhdGlvbnMgZGlmZmljdWx0DQo+PiB0byBwcmVkaWN0IGluIGFueSBjYXNlLg0KPj4g DQo+PiAJV2l0aCByZWdhcmQgdG8gbmVlZGluZyBtb3JlIHRleHQgb24gcGVyLWludGVyZmFj ZSBNSVBzLCBkbw0KPj4geW91IGhhdmUgc3BlY2lmaWMgc3VnZ2VzdGlvbnMgYXMgdG8gd2hh dCB0ZXh0IHdlIG1pZ2h0IGFkZD8NCj4+IA0KPj4gCUkgdW5kZXJzdGFuZCAoZnJvbSBkaXNj dXNzaW9uIHdpdGggV0cgY2hhaXJzKSB0aGF0IHdlIGFyZQ0KPj4gbm90IGFsbG93ZWQgdG8g ZXhwbGljaXRseSBhZGRyZXNzIGxhc3QgY2FsbCBjb21tZW50cyBkdXJpbmcgdGhlDQo+PiBJ RVRGIG1lZXRpbmcgaW4gUHJhZ3VlLCBiZWNhdXNlIHRoZSBsYXN0IGNhbGwgaXMgc3RpbGwg b25nb2luZw0KPj4gYXQgdGhhdCB0aW1lLg0KPj4gDQo+PiAtLQ0KPj4gRXJpYw0KPj4gDQo+ PiBQUyAtDQo+PiBGcm9tIFJGQyAyMTE5IC0NCj4+ICdTSE9VTEQgICBUaGlzIHdvcmQsIG9y IHRoZSBhZGplY3RpdmUgIlJFQ09NTUVOREVEIiwgbWVhbiB0aGF0IHRoZXJlDQo+PiAgICAg ICAgICAgbWF5IGV4aXN0IHZhbGlkIHJlYXNvbnMgaW4gcGFydGljdWxhciBjaXJjdW1zdGFu Y2VzIHRvDQo+PiAgICAgICAgICAgaWdub3JlIGEgcGFydGljdWxhciBpdGVtLCBidXQgdGhl IGZ1bGwgaW1wbGljYXRpb25zIG11c3QNCj4+ICAgICAgICAgICBiZSB1bmRlcnN0b29kIGFu ZCBjYXJlZnVsbHkgd2VpZ2hlZCBiZWZvcmUgY2hvb3NpbmcgYQ0KPj4gICAgICAgICAgIGRp ZmZlcmVudCBjb3Vyc2UuJw0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YNCj4+IFJvbGYgV2ludGVyDQo+PiBTZW50OiBUdWVzZGF5 LCBNYXJjaCAyMiwgMjAxMSA0OjU3IEFNDQo+PiBUbzogbG9hQHBpLm51OyBtcGxzQGlldGYu b3JnDQo+PiBTdWJqZWN0OiBSZTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENhbGwgb24g ZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLQ0KPj4gZGVtYW5kLWN2LTAzDQo+PiANCj4+IEhpLA0K Pj4gDQo+PiBzb21lIGNvbW1lbnRzIGJlbG93Og0KPj4gDQo+PiBTZWN0aW9uIDEuMyBzYXlz OiAiIEluIGNlcnRhaW4gTVBMUy1UUCBkZXBsb3ltZW50IHNjZW5hcmlvcyBJUA0KPj4gYWRk cmVzc2luZyBtaWdodCBub3QgYmUNCj4+ICAgIGF2YWlsYWJsZSBvciBpdCBtYXkgYmUgcHJl ZmVycmVkIHRvIHVzZSBzb21lIGZvcm0gb2Ygbm9uLUlQDQo+PiAgICBlbmNhcHN1bGF0aW9u IGZvciBPbi1kZW1hbmQgQ1YsIHJvdXRlIHRyYWNpbmcgYW5kIEJGRCBwYWNrZXRzLiAgSW4N Cj4+ICAgIHN1Y2ggc2NlbmFyaW9zLCBPbi1kZW1hbmQgQ1YgYW5kL29yIHJvdXRlIHRyYWNp bmcgU0hPVUxEIGJlIHJ1bg0KPj4gICAgd2l0aG91dCBJUCBhZGRyZXNzaW5nLi4uIg0KPj4g DQo+PiBJIGFtIG5vdCBzdXJlIHRoZSAiU0hPVUxEIiBpcyByaWdodCBoZXJlLiBJZiBubyBJ UCBhZGRyZXNzaW5nIGlzDQo+PiBhdmFpbGFibGUsIHRoaXMgdGhpbmcgTVVTVCBiZSBydW4g d2l0aG91dCBJUCBhZGRyZXNzaW5nLCBtdXN0bid0IGl0Pw0KPj4gDQo+PiBJIHRoaW5rIHNv bWUgYWRkaXRpb25hbCB0ZXh0IHJlZ2FyZGluZyBwZXItaW50ZXJmYWNlIE1JUCBhZGRyZXNz aW5nDQo+PiB3b3VsZCBiZSBuaWNlLiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kIHRoZSBkb2N1 bWVudCwgYWxsIFRMVnMgd2lsbCBiZQ0KPj4gaW5zaWRlIHRoZSBMU1AgcGluZyBwYWNrZXQg KHJhdGhlciB0aGFuIGFzIEFDSCBUTFZzKS4NCj4+IA0KPj4gU29tZSBwZW9wbGUgaGFkIGNv bmNlcm5zIGVhcmxpZXIsIHRoYXQgYWRkcmVzc2luZyBpbmZvcm1hdGlvbiBzaG91bGQgYmUN Cj4+IGluIGEgZml4ZWQgbG9jYXRpb24gZm9yIGVhc2llciBwcm9jZXNzaW5nLiBJcyB0aGlz IHRoZSBjYXNlIGhlcmUgSQ0KPj4gd29uZGVyPw0KPj4gDQo+PiBJdCB3b3VsZCBiZSBuaWNl IGlmIHlvdSBjb3VsZCBhZGRyZXNzIHRoaXMgaW4geW91ciBwcmVzZW50YXRpb24gaW4NCj4+ IFByYWd1ZS4NCj4+IA0KPj4gVGhhbmtzLA0KPj4gDQo+PiBSb2xmDQo+PiANCj4+IA0KPj4g TkVDIEV1cm9wZSBMaW1pdGVkIHwgUmVnaXN0ZXJlZCBPZmZpY2U6IE5FQyBIb3VzZSwgMSBW aWN0b3JpYSBSb2FkLA0KPj4gTG9uZG9uIFczIDZCTCB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFu ZCAyODMyMDE0DQo+PiANCj4+IA0KPj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4gPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZg0KPj4gT2YNCj4+ID4gbG9hQHBpLm51DQo+PiA+IFNlbnQ6 IE1pdHR3b2NoLCAxNi4gTeRyeiAyMDExIDAwOjI2DQo+PiA+IFRvOiBtcGxzQGlldGYub3Jn DQo+PiA+IENjOiBNUExTLVRQIGFkIGhvYyB0ZWFtDQo+PiA+IFN1YmplY3Q6IFttcGxzXSBX b3JraW5nIEdyb3VwIExhcyBDYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1vbi0NCj4+IGRl bWFuZC0NCj4+ID4gY3YtMDMNCj4+ID4NCj4+ID4gV29ya2luZyBHcm91cCwNCj4+ID4NCj4+ ID4gdGhpcyBpcyB0byBzdGFydCBhIDMgd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBv bg0KPj4gPg0KPj4gPiBkcmFmdC1pZXRmLW1wbHMtdHAtb24tZGVtYW5kLWN2LTAzDQo+PiA+ DQo+PiA+IFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRoZSB3b3JraW5nIGdyb3VwIG1haWxp bmcgbGlzdA0KPj4gPiBtcGxzQGlldGYub3JnDQo+PiA+DQo+PiA+IFRoZSB3b3JraW5nIGdy b3VwIGxhc3QgY2FsbCBlbmRzIG9uIEFwcmlsIDgsIDIwMTEuDQo+PiA+DQo+PiA+IC9Mb2EN Cj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4+ID4g bXBsc0BpZXRmLm9yZw0KPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4gbXBsc0BpZXRmLm9yZw0KPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5tcGxzIG1haWxpbmcgbGlz dA0KPm1wbHNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMNCj4NCg== --GMAILSMTPBOUND01110328211045-- From eric.gray@ericsson.com Mon Mar 28 05:43:09 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E89783A69FC for ; Mon, 28 Mar 2011 05:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[AWL=1.130, 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 Lgz1FOPXxpLd for ; Mon, 28 Mar 2011 05:43:07 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id DBE223A691A for ; Mon, 28 Mar 2011 05:43:06 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2SCifv7027429; Mon, 28 Mar 2011 07:44:42 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 28 Mar 2011 08:44:35 -0400 From: Eric Gray To: "hideki.endo.es@hitachi.com" , "Rolf.Winter@neclab.eu" Date: Mon, 28 Mar 2011 08:44:32 -0400 Thread-Topic: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-cv-03 Thread-Index: AcvtQTQ+h8YFVlrMQrKOVaV1Y/oR2gAAMc5g Message-ID: References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> In-Reply-To: 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@ietf.org" Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:43:09 -0000 Hideki, What you're saying is true, but not relevant in this case. The "addresses" in this discussion are not used to determine how to forward OAM packets. They are used only by the recipient MIP/MEP to verify that the OAM packet was properly delivered. By the way, this discussion is an indication of the confusing injected by calling these things addresses. My mistake and I bring it up now to help to stem the tide of further comments resulting from that confusion. In the version we post after last call is complete,=20 we will be changing the source and destination "address"=20 TLVs to source and destination "identifier" TLVs. We will also be correcting the reference to DSMAP, and DDMAP, address TLVs (which is incorrect, because the format for DSMAP/DDMAP doesn't include a "length" field). The format of the Downstream Mapping (DSMAP) TLV is defined in RFC 4379, and we are not changing the format of that TLV. These changes are driven by last call comments we have already received (see Joel Halpern's comments on the mailing list) and are - in part - to correct accidental=20 use of the word "address" for source and destination=20 identifier TLVs (which is what we had discussed before I generated the -03 version among the authors of several of the current set of MPLS-TP drafts). In the case of source and destination identifiers, these will be used exclusively to verify that an OAM PDU has been correctly received by its intended recipient. Because this is an on-demand connectivity verification protocol, that is expected to be used only on those occasions when there is a network problem that needs to be diagnosed, and the information is not seen (and not visible - without layer violations), optimizing these=20 objects for software makes sense. In addition, since either may be included (which includes the possibility of including both), it is the case already that we would then need to decide which is to go first - assuming we wanted to do this (which we do not). -- Eric=20 -----Original Message----- From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com]=20 Sent: Monday, March 28, 2011 8:11 AM To: Eric Gray; Rolf.Winter@neclab.eu Cc: mpls@ietf.org Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-deman= d-cv-03 Importance: High Hi Eric and Rolf, I'm sorry for interrupting. I agree with Rolf regarding the per-interface MIP discussion. We have to consider the HW implementation aspect, because trapping of an OAM packet is HW rule/functionality even in routers. If every OAM packet is trapped to CPU and the OAM packets which should NOT be processed in the Interface are returned to Data-plane, it is different forwarding path from user packets, which is NOT the Connectivity Verification of the user path.=20 Therefore, we should take the HW aspect and flexibilty into account concurr= ently. If an address TLV MUST be the first in TLVs, it is enough to make HW implementation easy. BR, Hideki >Rolf, > > The words you propose are okay with me. =20 > > I thought the MIP/interface and address location issues >were separate. > > I've personally had problems with protocol specifications >that require ordering of TLVs. In particular, this is not very >robust in terms of "future-proofing." What happens if new TLVs=20 >are added later on; for instance, suppose at some point we have >multiple "address" TLVs? =20 > > Also, the fact that implementations are allowed to attach >TLVs in any arbitrary order allows considerable flexibilty in=20 >implementation. Messages can be built in arbitrarily many ways. >This too can be a future-proofing issue. > > I would prefer not to start down the road of requiring a >subset of TLVs to appear in a certain order, and saying we have >one TLV that needs to be first is doing just that. > >-- >Eric > >-----Original Message----- >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 >Sent: Monday, March 28, 2011 6:19 AM >To: Eric Gray >Cc: mpls@ietf.org >Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-demand= -cv-03 >Importance: High > >Hi, > >I still think there is a logical error. Let me explain. In case there is n= o IP you simply cannot use it. You say you could enable IP but then that is= not a case where there is no IP. In order to be constructive here is a tex= t change suggestion: > >"In certain MPLS-TP deployment scenarios IP addressing might not be availa= ble. In those cases On-demand CV and/or route tracing MUST be run without I= P addressing, using the ACH channel type specified in Section 3. In other c= ases it might be available, however, it may be preferred to use some form o= f non-IP encapsulation. In those cases, the procedures as outlined in secti= on 3 SHOULD also be used." > >Regarding the per-interface MIP discussion. The HW aspect also popped up i= n the PWE3 session and I think this is an important consideration, in parti= cular for OAM. Even if we talk about TLVs, we could make it a MUST that an = Address TLV is always the first one to appear. If you can facilitate an eas= y implementation in hardware, I see no reason to deliberately not do it. > >Best, > >Rolf > > >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London= W3 6BL | Registered in England 2832014=20 > > >> -----Original Message----- >> From: Eric Gray [mailto:eric.gray@ericsson.com] >> Sent: Montag, 28. M=E4rz 2011 11:43 >> To: Rolf Winter >> Cc: loa@pi.nu; mpls@ietf.org >> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >> demand-cv-03 >>=20 >> Rolf, >>=20 >> With regard to the use of SHOULD (verses MUST) - the intent >> (according to RFC 2119 - see the quote below) is consistent with >> this case. If - for some reason - one had a really good reason to >> use IP addressing in some specific case, one could take steps to >> make IP addressing available. >>=20 >> This could be said to introduce a logical disconnect, but we >> are saved from going down that path by the fact that the statement >> also includes the case where (for some reason) there is a case in >> which some other addressing scheme might be preferred. In many of >> the cases where another addressing scheme may be preferred, it is >> still possible (in fact likely) that IP addressing is available. >>=20 >> Otherwise, it would not have been necessary to distinguish >> this case from the one in which IP addressing is not available. >>=20 >> For the case where IP addressing is not the preferred mode, >> we are recommending a mode in which it is not necessary. >>=20 >> With regard to having addresses located in the same place, >> this protocol is meant for connectivity testing on an on-demand >> basis and is therefore not optimized for processing in hardware. >>=20 >> Whether addresses or identifiers, if we are talking about >> TLV contents, there are issues with trying to guarantee location >> of specific content, because of the fact that the TLV in question >> will probably follow other TLVs - thus making locations difficult >> to predict in any case. >>=20 >> With regard to needing more text on per-interface MIPs, do >> you have specific suggestions as to what text we might add? >>=20 >> I understand (from discussion with WG chairs) that we are >> not allowed to explicitly address last call comments during the >> IETF meeting in Prague, because the last call is still ongoing >> at that time. >>=20 >> -- >> Eric >>=20 >> PS - >> From RFC 2119 - >> 'SHOULD This word, or the adjective "RECOMMENDED", mean that there >> may exist valid reasons in particular circumstances to >> ignore a particular item, but the full implications must >> be understood and carefully weighed before choosing a >> different course.' >>=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Rolf Winter >> Sent: Tuesday, March 22, 2011 4:57 AM >> To: loa@pi.nu; mpls@ietf.org >> Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >> demand-cv-03 >>=20 >> Hi, >>=20 >> some comments below: >>=20 >> Section 1.3 says: " In certain MPLS-TP deployment scenarios IP >> addressing might not be >> available or it may be preferred to use some form of non-IP >> encapsulation for On-demand CV, route tracing and BFD packets. In >> such scenarios, On-demand CV and/or route tracing SHOULD be run >> without IP addressing..." >>=20 >> I am not sure the "SHOULD" is right here. If no IP addressing is >> available, this thing MUST be run without IP addressing, mustn't it? >>=20 >> I think some additional text regarding per-interface MIP addressing >> would be nice. As far as I understand the document, all TLVs will be >> inside the LSP ping packet (rather than as ACH TLVs). >>=20 >> Some people had concerns earlier, that addressing information should be >> in a fixed location for easier processing. Is this the case here I >> wonder? >>=20 >> It would be nice if you could address this in your presentation in >> Prague. >>=20 >> Thanks, >>=20 >> Rolf >>=20 >>=20 >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >> London W3 6BL | Registered in England 2832014 >>=20 >>=20 >> > -----Original Message----- >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of >> > loa@pi.nu >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26 >> > To: mpls@ietf.org >> > Cc: MPLS-TP ad hoc team >> > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >> demand- >> > cv-03 >> > >> > Working Group, >> > >> > this is to start a 3 week working group last call on >> > >> > draft-ietf-mpls-tp-on-demand-cv-03 >> > >> > Please send comments to the working group mailing list >> > mpls@ietf.org >> > >> > The working group last call ends on April 8, 2011. >> > >> > /Loa >> > >> > >> > >> > >> > _______________________________________________ >> > mpls mailing list >> > mpls@ietf.org >> > https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From Rolf.Winter@neclab.eu Mon Mar 28 06:01:30 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A3C3A68EA for ; Mon, 28 Mar 2011 06:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 aX2ilvWFKoeS for ; Mon, 28 Mar 2011 06:01:29 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id BE6713A67DA for ; Mon, 28 Mar 2011 06:01:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 23EE728000171; Mon, 28 Mar 2011 15:04:23 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEN5QcrGKa0V; Mon, 28 Mar 2011 15:04:23 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0015828003888; Mon, 28 Mar 2011 15:04:07 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.246]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Mon, 28 Mar 2011 15:02:51 +0200 From: Rolf Winter To: Eric Gray , "hideki.endo.es@hitachi.com" Thread-Topic: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-cv-03 Thread-Index: AQHL7UEzNDkNsNSfrUy2+prVZl2z35RCj7sAgAAj/7A= Date: Mon, 28 Mar 2011 13:02:49 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.201] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:01:30 -0000 Eric, I generally agree but I think there is one case actually which needs a clos= er look in this regard (which I hinted at earlier), which are the per-inter= face MIPs. Your TTL expires (the actual addressing bit here), the identifie= r tells you it is not intended for the ingress MIP, so it needs to be forwa= rded to the egress MIP through the forwarding engine. Now if you pull the p= acket out of the fast path and inject it back in, is the OAM packet still f= ate sharing? If you can do this in HW on the line card, then it will and it= will just be forwarded as normal. I know this is a different draft, but th= is will be in particular important for performance monitoring. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Eric Gray [mailto:eric.gray@ericsson.com] > Sent: Montag, 28. M=E4rz 2011 14:45 > To: hideki.endo.es@hitachi.com; Rolf Winter > Cc: mpls@ietf.org > Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp- > on-demand-cv-03 >=20 > Hideki, >=20 > What you're saying is true, but not relevant in this > case. The "addresses" in this discussion are not used to > determine how to forward OAM packets. They are used only > by the recipient MIP/MEP to verify that the OAM packet was > properly delivered. >=20 > By the way, this discussion is an indication of the > confusing injected by calling these things addresses. My > mistake and I bring it up now to help to stem the tide of > further comments resulting from that confusion. >=20 > In the version we post after last call is complete, > we will be changing the source and destination "address" > TLVs to source and destination "identifier" TLVs. >=20 > We will also be correcting the reference to DSMAP, > and DDMAP, address TLVs (which is incorrect, because the > format for DSMAP/DDMAP doesn't include a "length" field). >=20 > The format of the Downstream Mapping (DSMAP) TLV is > defined in RFC 4379, and we are not changing the format > of that TLV. >=20 > These changes are driven by last call comments we > have already received (see Joel Halpern's comments on the > mailing list) and are - in part - to correct accidental > use of the word "address" for source and destination > identifier TLVs (which is what we had discussed before > I generated the -03 version among the authors of several > of the current set of MPLS-TP drafts). >=20 > In the case of source and destination identifiers, > these will be used exclusively to verify that an OAM PDU > has been correctly received by its intended recipient. > Because this is an on-demand connectivity verification > protocol, that is expected to be used only on those > occasions when there is a network problem that needs to > be diagnosed, and the information is not seen (and not > visible - without layer violations), optimizing these > objects for software makes sense. >=20 > In addition, since either may be included (which > includes the possibility of including both), it is the > case already that we would then need to decide which is > to go first - assuming we wanted to do this (which we > do not). >=20 > -- > Eric >=20 > -----Original Message----- > From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] > Sent: Monday, March 28, 2011 8:11 AM > To: Eric Gray; Rolf.Winter@neclab.eu > Cc: mpls@ietf.org > Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on- > demand-cv-03 > Importance: High >=20 > Hi Eric and Rolf, >=20 > I'm sorry for interrupting. >=20 > I agree with Rolf regarding the per-interface MIP discussion. > We have to consider the HW implementation aspect, > because trapping of an OAM packet is HW rule/functionality even in > routers. >=20 > If every OAM packet is trapped to CPU > and the OAM packets which should NOT be processed in the Interface > are returned to Data-plane, > it is different forwarding path from user packets, > which is NOT the Connectivity Verification of the user path. >=20 > Therefore, we should take the HW aspect and flexibilty into account > concurrently. > If an address TLV MUST be the first in TLVs, > it is enough to make HW implementation easy. >=20 > BR, > Hideki >=20 >=20 >=20 > >Rolf, > > > > The words you propose are okay with me. > > > > I thought the MIP/interface and address location issues > >were separate. > > > > I've personally had problems with protocol specifications > >that require ordering of TLVs. In particular, this is not very > >robust in terms of "future-proofing." What happens if new TLVs > >are added later on; for instance, suppose at some point we have > >multiple "address" TLVs? > > > > Also, the fact that implementations are allowed to attach > >TLVs in any arbitrary order allows considerable flexibilty in > >implementation. Messages can be built in arbitrarily many ways. > >This too can be a future-proofing issue. > > > > I would prefer not to start down the road of requiring a > >subset of TLVs to appear in a certain order, and saying we have > >one TLV that needs to be first is doing just that. > > > >-- > >Eric > > > >-----Original Message----- > >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > >Sent: Monday, March 28, 2011 6:19 AM > >To: Eric Gray > >Cc: mpls@ietf.org > >Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > demand-cv-03 > >Importance: High > > > >Hi, > > > >I still think there is a logical error. Let me explain. In case there > is no IP you simply cannot use it. You say you could enable IP but then > that is not a case where there is no IP. In order to be constructive > here is a text change suggestion: > > > >"In certain MPLS-TP deployment scenarios IP addressing might not be > available. In those cases On-demand CV and/or route tracing MUST be run > without IP addressing, using the ACH channel type specified in Section > 3. In other cases it might be available, however, it may be preferred > to use some form of non-IP encapsulation. In those cases, the > procedures as outlined in section 3 SHOULD also be used." > > > >Regarding the per-interface MIP discussion. The HW aspect also popped > up in the PWE3 session and I think this is an important consideration, > in particular for OAM. Even if we talk about TLVs, we could make it a > MUST that an Address TLV is always the first one to appear. If you can > facilitate an easy implementation in hardware, I see no reason to > deliberately not do it. > > > >Best, > > > >Rolf > > > > > >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > > > >> -----Original Message----- > >> From: Eric Gray [mailto:eric.gray@ericsson.com] > >> Sent: Montag, 28. M=E4rz 2011 11:43 > >> To: Rolf Winter > >> Cc: loa@pi.nu; mpls@ietf.org > >> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > >> demand-cv-03 > >> > >> Rolf, > >> > >> With regard to the use of SHOULD (verses MUST) - the intent > >> (according to RFC 2119 - see the quote below) is consistent with > >> this case. If - for some reason - one had a really good reason to > >> use IP addressing in some specific case, one could take steps to > >> make IP addressing available. > >> > >> This could be said to introduce a logical disconnect, but we > >> are saved from going down that path by the fact that the statement > >> also includes the case where (for some reason) there is a case in > >> which some other addressing scheme might be preferred. In many of > >> the cases where another addressing scheme may be preferred, it is > >> still possible (in fact likely) that IP addressing is available. > >> > >> Otherwise, it would not have been necessary to distinguish > >> this case from the one in which IP addressing is not available. > >> > >> For the case where IP addressing is not the preferred mode, > >> we are recommending a mode in which it is not necessary. > >> > >> With regard to having addresses located in the same place, > >> this protocol is meant for connectivity testing on an on-demand > >> basis and is therefore not optimized for processing in hardware. > >> > >> Whether addresses or identifiers, if we are talking about > >> TLV contents, there are issues with trying to guarantee location > >> of specific content, because of the fact that the TLV in question > >> will probably follow other TLVs - thus making locations difficult > >> to predict in any case. > >> > >> With regard to needing more text on per-interface MIPs, do > >> you have specific suggestions as to what text we might add? > >> > >> I understand (from discussion with WG chairs) that we are > >> not allowed to explicitly address last call comments during the > >> IETF meeting in Prague, because the last call is still ongoing > >> at that time. > >> > >> -- > >> Eric > >> > >> PS - > >> From RFC 2119 - > >> 'SHOULD This word, or the adjective "RECOMMENDED", mean that there > >> may exist valid reasons in particular circumstances to > >> ignore a particular item, but the full implications must > >> be understood and carefully weighed before choosing a > >> different course.' > >> > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > >> Rolf Winter > >> Sent: Tuesday, March 22, 2011 4:57 AM > >> To: loa@pi.nu; mpls@ietf.org > >> Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > >> demand-cv-03 > >> > >> Hi, > >> > >> some comments below: > >> > >> Section 1.3 says: " In certain MPLS-TP deployment scenarios IP > >> addressing might not be > >> available or it may be preferred to use some form of non-IP > >> encapsulation for On-demand CV, route tracing and BFD packets. > In > >> such scenarios, On-demand CV and/or route tracing SHOULD be run > >> without IP addressing..." > >> > >> I am not sure the "SHOULD" is right here. If no IP addressing is > >> available, this thing MUST be run without IP addressing, mustn't it? > >> > >> I think some additional text regarding per-interface MIP addressing > >> would be nice. As far as I understand the document, all TLVs will be > >> inside the LSP ping packet (rather than as ACH TLVs). > >> > >> Some people had concerns earlier, that addressing information should > be > >> in a fixed location for easier processing. Is this the case here I > >> wonder? > >> > >> It would be nice if you could address this in your presentation in > >> Prague. > >> > >> Thanks, > >> > >> Rolf > >> > >> > >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > >> London W3 6BL | Registered in England 2832014 > >> > >> > >> > -----Original Message----- > >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > >> Of > >> > loa@pi.nu > >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26 > >> > To: mpls@ietf.org > >> > Cc: MPLS-TP ad hoc team > >> > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > >> demand- > >> > cv-03 > >> > > >> > Working Group, > >> > > >> > this is to start a 3 week working group last call on > >> > > >> > draft-ietf-mpls-tp-on-demand-cv-03 > >> > > >> > Please send comments to the working group mailing list > >> > mpls@ietf.org > >> > > >> > The working group last call ends on April 8, 2011. > >> > > >> > /Loa > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > mpls mailing list > >> > mpls@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mpls > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > From hideki.endo.es@hitachi.com Mon Mar 28 06:42:15 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A100B3A69CF for ; Mon, 28 Mar 2011 06:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.462 X-Spam-Level: **** X-Spam-Status: No, score=4.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_BASE64_TEXT=1.753, SUBJ_RE_NUM=2.799] 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 forV9OL8sUXD for ; Mon, 28 Mar 2011 06:42:14 -0700 (PDT) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by core3.amsl.com (Postfix) with ESMTP id 61C943A6878 for ; Mon, 28 Mar 2011 06:42:13 -0700 (PDT) Received: from mlsv4.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 21C8137AC3; Mon, 28 Mar 2011 22:43:50 +0900 (JST) Received: from mfilter1.hitachi.co.jp by mlsv4.hitachi.co.jp (8.13.1/8.13.1) id p2SDhoj4018145; Mon, 28 Mar 2011 22:43:50 +0900 Received: from vshuts3.hitachi.co.jp (vshuts3.hitachi.co.jp [10.201.6.72]) by mfilter1.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id p2SDhnFm009337; Mon, 28 Mar 2011 22:43:49 +0900 X-AuditID: b753bd60-9f758ba000007e19-cc-4d909094a03d Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id CF963774260; Mon, 28 Mar 2011 22:43:48 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p2SDhmT22982806; Mon, 28 Mar 2011 22:43:48 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: multipart/mixed; boundary="GMAILSMTPBOUND01110328224346" To: , From: Date: Mon, 28 Mar 2011 22:43:35 +0900 References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> Priority: normal Importance: normal X400-Content-Identifier: X4D90907700000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28110328224319UWW] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mpls@ietf.org Subject: Re: [mpls] =?iso-8859-1?q?Working_Group_Las_Callondraft-ietf-mpls-tp-?= =?iso-8859-1?q?on-demand-cv-03?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:42:15 -0000 --GMAILSMTPBOUND01110328224346 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 SGkgRXJpYywNCg0KV2hhdCBJJ2QgbGlrZSB0byBzYXkgd2FzIGV4cGxhbmVkIGJ5IFJvbGYu DQpNeSBjb25jZXJuIGlzIHdoZXRoZXIgdGhlIE9BTSBwYWNrZXQgaXMgZmF0ZSBzaGFyaW5n IHdpdGggdXNlciBwYWNrZXQgb3IgTk9ULg0KSWYgZHJhZnQtb24tZGVtYW5kLWN2IGRvZXNu J3QgY2FyZSBhbnl0aGluZyBmb3IgZmF0ZSBzaGFyaW5nIA0KaW4gdGhlIGNhc2Ugb2YgcGVy LWludGVyZmFjZSBNSVAsDQp0aGUgcGVyLWludGVyZmFjZSBNSVAgY2FuIE5PVCBiZSBpbXBs ZW1lbnRlZCBieSBIVyByZWFzb25hYmx5Lg0KDQpCUiwNCkhpZGVraQ0KDQo+RXJpYywNCj4N Cj5JIGdlbmVyYWxseSBhZ3JlZSBidXQgSSB0aGluayB0aGVyZSBpcyBvbmUgY2FzZSBhY3R1 YWxseSB3aGljaCBuZWVkcyBhIGNsb3NlciBsb29rIGluIHRoaXMgcmVnYXJkICh3aGljaCBJ IGhpbnRlZCBhdCBlYXJsaWVyKSwgd2hpY2ggYXJlIHRoZSBwZXItaW50ZXJmYWNlIE1JUHMu IFlvdXIgVFRMIGV4cGlyZXMgKHRoZSBhY3R1YWwgYWRkcmVzc2luZyBiaXQgaGVyZSksIHRo ZSBpZGVudGlmaWVyIHRlbGxzIHlvdSBpdCBpcyBub3QgaW50ZW5kZWQgZm9yIHRoZSBpbmdy ZXNzIE1JUCwgc28gaXQgbmVlZHMgdG8gYmUgZm9yd2FyZGVkIHRvIHRoZSBlZ3Jlc3MgTUlQ IHRocm91Z2ggdGhlIGZvcndhcmRpbmcgZW5naW5lLiBOb3cgaWYgeW91IHB1bGwgdGhlIHBh Y2tldCBvdXQgb2YgdGhlIGZhc3QgcGF0aCBhbmQgaW5qZWN0IGl0IGJhY2sgaW4sIGlzIHRo ZSBPQU0gcGFja2V0IHN0aWxsIGZhdGUgc2hhcmluZz8gSWYgeW91IGNhbiBkbyB0aGlzIGlu IEhXIG9uIHRoZSBsaW5lIGNhcmQsIHRoZW4gaXQgd2lsbCBhbmQgaXQgd2lsbCBqdXN0IGJl IGZvcndhcmRlZCBhcyBub3JtYWwuIEkga25vdyB0aGlzIGlzIGEgZGlmZmVyZW50IGRyYWZ0 LCBidXQgdGhpcyB3aWxsIGJlIGluIHBhcnRpY3VsYXIgaW1wb3J0YW50IGZvciBwZXJmb3Jt YW5jZSBtb25pdG9yaW5nLg0KPg0KPkJlc3QsDQo+DQo+Um9sZg0KPg0KPg0KPg0KPk5FQyBF dXJvcGUgTGltaXRlZCB8IFJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2UsIDEgVmljdG9y aWEgUm9hZCwgTG9uZG9uIFczIDZCTCB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODMyMDE0 IA0KPg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IEVyaWMg R3JheSBbbWFpbHRvOmVyaWMuZ3JheUBlcmljc3Nvbi5jb21dDQo+PiBTZW50OiBNb250YWcs IDI4LiBN5HJ6IDIwMTEgMTQ6NDUNCj4+IFRvOiBoaWRla2kuZW5kby5lc0BoaXRhY2hpLmNv bTsgUm9sZiBXaW50ZXINCj4+IENjOiBtcGxzQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSRTog UmVbMl06IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9uZHJhZnQtaWV0Zi1tcGxz LXRwLQ0KPj4gb24tZGVtYW5kLWN2LTAzDQo+PiANCj4+IEhpZGVraSwNCj4+IA0KPj4gCVdo YXQgeW91J3JlIHNheWluZyBpcyB0cnVlLCBidXQgbm90IHJlbGV2YW50IGluIHRoaXMNCj4+ IGNhc2UuICBUaGUgImFkZHJlc3NlcyIgaW4gdGhpcyBkaXNjdXNzaW9uIGFyZSBub3QgdXNl ZCB0bw0KPj4gZGV0ZXJtaW5lIGhvdyB0byBmb3J3YXJkIE9BTSBwYWNrZXRzLiAgVGhleSBh cmUgdXNlZCBvbmx5DQo+PiBieSB0aGUgcmVjaXBpZW50IE1JUC9NRVAgdG8gdmVyaWZ5IHRo YXQgdGhlIE9BTSBwYWNrZXQgd2FzDQo+PiBwcm9wZXJseSBkZWxpdmVyZWQuDQo+PiANCj4+ IAlCeSB0aGUgd2F5LCB0aGlzIGRpc2N1c3Npb24gaXMgYW4gaW5kaWNhdGlvbiBvZiB0aGUN Cj4+IGNvbmZ1c2luZyBpbmplY3RlZCBieSBjYWxsaW5nIHRoZXNlIHRoaW5ncyBhZGRyZXNz ZXMuICBNeQ0KPj4gbWlzdGFrZSBhbmQgSSBicmluZyBpdCB1cCBub3cgdG8gaGVscCB0byBz dGVtIHRoZSB0aWRlIG9mDQo+PiBmdXJ0aGVyIGNvbW1lbnRzIHJlc3VsdGluZyBmcm9tIHRo YXQgY29uZnVzaW9uLg0KPj4gDQo+PiAJSW4gdGhlIHZlcnNpb24gd2UgcG9zdCBhZnRlciBs YXN0IGNhbGwgaXMgY29tcGxldGUsDQo+PiB3ZSB3aWxsIGJlIGNoYW5naW5nIHRoZSBzb3Vy Y2UgYW5kIGRlc3RpbmF0aW9uICJhZGRyZXNzIg0KPj4gVExWcyB0byBzb3VyY2UgYW5kIGRl c3RpbmF0aW9uICJpZGVudGlmaWVyIiBUTFZzLg0KPj4gDQo+PiAJV2Ugd2lsbCBhbHNvIGJl IGNvcnJlY3RpbmcgdGhlIHJlZmVyZW5jZSB0byBEU01BUCwNCj4+IGFuZCBERE1BUCwgYWRk cmVzcyBUTFZzICh3aGljaCBpcyBpbmNvcnJlY3QsIGJlY2F1c2UgdGhlDQo+PiBmb3JtYXQg Zm9yIERTTUFQL0RETUFQIGRvZXNuJ3QgaW5jbHVkZSBhICJsZW5ndGgiIGZpZWxkKS4NCj4+ IA0KPj4gCVRoZSBmb3JtYXQgb2YgdGhlIERvd25zdHJlYW0gTWFwcGluZyAoRFNNQVApIFRM ViBpcw0KPj4gZGVmaW5lZCBpbiBSRkMgNDM3OSwgYW5kIHdlIGFyZSBub3QgY2hhbmdpbmcg dGhlIGZvcm1hdA0KPj4gb2YgdGhhdCBUTFYuDQo+PiANCj4+IAlUaGVzZSBjaGFuZ2VzIGFy ZSBkcml2ZW4gYnkgbGFzdCBjYWxsIGNvbW1lbnRzIHdlDQo+PiBoYXZlIGFscmVhZHkgcmVj ZWl2ZWQgKHNlZSBKb2VsIEhhbHBlcm4ncyBjb21tZW50cyBvbiB0aGUNCj4+IG1haWxpbmcg bGlzdCkgYW5kIGFyZSAtIGluIHBhcnQgLSB0byBjb3JyZWN0IGFjY2lkZW50YWwNCj4+IHVz ZSBvZiB0aGUgd29yZCAiYWRkcmVzcyIgZm9yIHNvdXJjZSBhbmQgZGVzdGluYXRpb24NCj4+ IGlkZW50aWZpZXIgVExWcyAod2hpY2ggaXMgd2hhdCB3ZSBoYWQgZGlzY3Vzc2VkIGJlZm9y ZQ0KPj4gSSBnZW5lcmF0ZWQgdGhlIC0wMyB2ZXJzaW9uIGFtb25nIHRoZSBhdXRob3JzIG9m IHNldmVyYWwNCj4+IG9mIHRoZSBjdXJyZW50IHNldCBvZiBNUExTLVRQIGRyYWZ0cykuDQo+ PiANCj4+IAlJbiB0aGUgY2FzZSBvZiBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIGlkZW50aWZp ZXJzLA0KPj4gdGhlc2Ugd2lsbCBiZSB1c2VkIGV4Y2x1c2l2ZWx5IHRvIHZlcmlmeSB0aGF0 IGFuIE9BTSBQRFUNCj4+IGhhcyBiZWVuIGNvcnJlY3RseSByZWNlaXZlZCBieSBpdHMgaW50 ZW5kZWQgcmVjaXBpZW50Lg0KPj4gQmVjYXVzZSB0aGlzIGlzIGFuIG9uLWRlbWFuZCBjb25u ZWN0aXZpdHkgdmVyaWZpY2F0aW9uDQo+PiBwcm90b2NvbCwgdGhhdCBpcyBleHBlY3RlZCB0 byBiZSB1c2VkIG9ubHkgb24gdGhvc2UNCj4+IG9jY2FzaW9ucyB3aGVuIHRoZXJlIGlzIGEg bmV0d29yayBwcm9ibGVtIHRoYXQgbmVlZHMgdG8NCj4+IGJlIGRpYWdub3NlZCwgYW5kIHRo ZSBpbmZvcm1hdGlvbiBpcyBub3Qgc2VlbiAoYW5kIG5vdA0KPj4gdmlzaWJsZSAtIHdpdGhv dXQgbGF5ZXIgdmlvbGF0aW9ucyksIG9wdGltaXppbmcgdGhlc2UNCj4+IG9iamVjdHMgZm9y IHNvZnR3YXJlIG1ha2VzIHNlbnNlLg0KPj4gDQo+PiAJSW4gYWRkaXRpb24sIHNpbmNlIGVp dGhlciBtYXkgYmUgaW5jbHVkZWQgKHdoaWNoDQo+PiBpbmNsdWRlcyB0aGUgcG9zc2liaWxp dHkgb2YgaW5jbHVkaW5nIGJvdGgpLCBpdCBpcyB0aGUNCj4+IGNhc2UgYWxyZWFkeSB0aGF0 IHdlIHdvdWxkIHRoZW4gbmVlZCB0byBkZWNpZGUgd2hpY2ggaXMNCj4+IHRvIGdvIGZpcnN0 IC0gYXNzdW1pbmcgd2Ugd2FudGVkIHRvIGRvIHRoaXMgKHdoaWNoIHdlDQo+PiBkbyBub3Qp Lg0KPj4gDQo+PiAtLQ0KPj4gRXJpYw0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj4gRnJvbTogaGlkZWtpLmVuZG8uZXNAaGl0YWNoaS5jb20gW21haWx0bzpoaWRl a2kuZW5kby5lc0BoaXRhY2hpLmNvbV0NCj4+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMjgsIDIw MTEgODoxMSBBTQ0KPj4gVG86IEVyaWMgR3JheTsgUm9sZi5XaW50ZXJAbmVjbGFiLmV1DQo+ PiBDYzogbXBsc0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmVbMl06IFttcGxzXSBXb3JraW5n IEdyb3VwIExhcyBDYWxsIG9uZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLQ0KPj4gZGVtYW5kLWN2 LTAzDQo+PiBJbXBvcnRhbmNlOiBIaWdoDQo+PiANCj4+IEhpIEVyaWMgYW5kIFJvbGYsDQo+ PiANCj4+IEknbSBzb3JyeSBmb3IgaW50ZXJydXB0aW5nLg0KPj4gDQo+PiBJIGFncmVlIHdp dGggUm9sZiByZWdhcmRpbmcgdGhlIHBlci1pbnRlcmZhY2UgTUlQIGRpc2N1c3Npb24uDQo+ PiBXZSBoYXZlIHRvIGNvbnNpZGVyIHRoZSBIVyBpbXBsZW1lbnRhdGlvbiBhc3BlY3QsDQo+ PiBiZWNhdXNlIHRyYXBwaW5nIG9mIGFuIE9BTSBwYWNrZXQgaXMgSFcgcnVsZS9mdW5jdGlv bmFsaXR5IGV2ZW4gaW4NCj4+IHJvdXRlcnMuDQo+PiANCj4+IElmIGV2ZXJ5IE9BTSBwYWNr ZXQgaXMgdHJhcHBlZCB0byBDUFUNCj4+IGFuZCB0aGUgT0FNIHBhY2tldHMgd2hpY2ggc2hv dWxkIE5PVCBiZSBwcm9jZXNzZWQgaW4gdGhlIEludGVyZmFjZQ0KPj4gYXJlIHJldHVybmVk IHRvIERhdGEtcGxhbmUsDQo+PiBpdCBpcyBkaWZmZXJlbnQgZm9yd2FyZGluZyBwYXRoIGZy b20gdXNlciBwYWNrZXRzLA0KPj4gd2hpY2ggaXMgTk9UIHRoZSBDb25uZWN0aXZpdHkgVmVy aWZpY2F0aW9uIG9mIHRoZSB1c2VyIHBhdGguDQo+PiANCj4+IFRoZXJlZm9yZSwgd2Ugc2hv dWxkIHRha2UgdGhlIEhXIGFzcGVjdCBhbmQgZmxleGliaWx0eSBpbnRvIGFjY291bnQNCj4+ IGNvbmN1cnJlbnRseS4NCj4+IElmIGFuIGFkZHJlc3MgVExWIE1VU1QgYmUgdGhlIGZpcnN0 IGluIFRMVnMsDQo+PiBpdCBpcyBlbm91Z2ggdG8gbWFrZSBIVyBpbXBsZW1lbnRhdGlvbiBl YXN5Lg0KPj4gDQo+PiBCUiwNCj4+IEhpZGVraQ0KPj4gDQo+PiANCj4+IA0KPj4gPlJvbGYs DQo+PiA+DQo+PiA+CVRoZSB3b3JkcyB5b3UgcHJvcG9zZSBhcmUgb2theSB3aXRoIG1lLg0K Pj4gPg0KPj4gPglJIHRob3VnaHQgdGhlIE1JUC9pbnRlcmZhY2UgYW5kIGFkZHJlc3MgbG9j YXRpb24gaXNzdWVzDQo+PiA+d2VyZSBzZXBhcmF0ZS4NCj4+ID4NCj4+ID4JSSd2ZSBwZXJz b25hbGx5IGhhZCBwcm9ibGVtcyB3aXRoIHByb3RvY29sIHNwZWNpZmljYXRpb25zDQo+PiA+ dGhhdCByZXF1aXJlIG9yZGVyaW5nIG9mIFRMVnMuICBJbiBwYXJ0aWN1bGFyLCB0aGlzIGlz IG5vdCB2ZXJ5DQo+PiA+cm9idXN0IGluIHRlcm1zIG9mICJmdXR1cmUtcHJvb2ZpbmcuIiAg V2hhdCBoYXBwZW5zIGlmIG5ldyBUTFZzDQo+PiA+YXJlIGFkZGVkIGxhdGVyIG9uOyBmb3Ig aW5zdGFuY2UsIHN1cHBvc2UgYXQgc29tZSBwb2ludCB3ZSBoYXZlDQo+PiA+bXVsdGlwbGUg ImFkZHJlc3MiIFRMVnM/DQo+PiA+DQo+PiA+CUFsc28sIHRoZSBmYWN0IHRoYXQgaW1wbGVt ZW50YXRpb25zIGFyZSBhbGxvd2VkIHRvIGF0dGFjaA0KPj4gPlRMVnMgaW4gYW55IGFyYml0 cmFyeSBvcmRlciBhbGxvd3MgY29uc2lkZXJhYmxlIGZsZXhpYmlsdHkgaW4NCj4+ID5pbXBs ZW1lbnRhdGlvbi4gIE1lc3NhZ2VzIGNhbiBiZSBidWlsdCBpbiBhcmJpdHJhcmlseSBtYW55 IHdheXMuDQo+PiA+VGhpcyB0b28gY2FuIGJlIGEgZnV0dXJlLXByb29maW5nIGlzc3VlLg0K Pj4gPg0KPj4gPglJIHdvdWxkIHByZWZlciBub3QgdG8gc3RhcnQgZG93biB0aGUgcm9hZCBv ZiByZXF1aXJpbmcgYQ0KPj4gPnN1YnNldCBvZiBUTFZzIHRvIGFwcGVhciBpbiBhIGNlcnRh aW4gb3JkZXIsIGFuZCBzYXlpbmcgd2UgaGF2ZQ0KPj4gPm9uZSBUTFYgdGhhdCBuZWVkcyB0 byBiZSBmaXJzdCBpcyBkb2luZyBqdXN0IHRoYXQuDQo+PiA+DQo+PiA+LS0NCj4+ID5Fcmlj DQo+PiA+DQo+PiA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID5Gcm9tOiBSb2xm IFdpbnRlciBbbWFpbHRvOlJvbGYuV2ludGVyQG5lY2xhYi5ldV0NCj4+ID5TZW50OiBNb25k YXksIE1hcmNoIDI4LCAyMDExIDY6MTkgQU0NCj4+ID5UbzogRXJpYyBHcmF5DQo+PiA+Q2M6 IG1wbHNAaWV0Zi5vcmcNCj4+ID5TdWJqZWN0OiBSRTogW21wbHNdIFdvcmtpbmcgR3JvdXAg TGFzIENhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLQ0KPj4gZGVtYW5kLWN2LTAzDQo+ PiA+SW1wb3J0YW5jZTogSGlnaA0KPj4gPg0KPj4gPkhpLA0KPj4gPg0KPj4gPkkgc3RpbGwg dGhpbmsgdGhlcmUgaXMgYSBsb2dpY2FsIGVycm9yLiBMZXQgbWUgZXhwbGFpbi4gSW4gY2Fz ZSB0aGVyZQ0KPj4gaXMgbm8gSVAgeW91IHNpbXBseSBjYW5ub3QgdXNlIGl0LiBZb3Ugc2F5 IHlvdSBjb3VsZCBlbmFibGUgSVAgYnV0IHRoZW4NCj4+IHRoYXQgaXMgbm90IGEgY2FzZSB3 aGVyZSB0aGVyZSBpcyBubyBJUC4gSW4gb3JkZXIgdG8gYmUgY29uc3RydWN0aXZlDQo+PiBo ZXJlIGlzIGEgdGV4dCBjaGFuZ2Ugc3VnZ2VzdGlvbjoNCj4+ID4NCj4+ID4iSW4gY2VydGFp biBNUExTLVRQIGRlcGxveW1lbnQgc2NlbmFyaW9zIElQIGFkZHJlc3NpbmcgbWlnaHQgbm90 IGJlDQo+PiBhdmFpbGFibGUuIEluIHRob3NlIGNhc2VzIE9uLWRlbWFuZCBDViBhbmQvb3Ig cm91dGUgdHJhY2luZyBNVVNUIGJlIHJ1bg0KPj4gd2l0aG91dCBJUCBhZGRyZXNzaW5nLCB1 c2luZyB0aGUgQUNIIGNoYW5uZWwgdHlwZSBzcGVjaWZpZWQgaW4gU2VjdGlvbg0KPj4gMy4g SW4gb3RoZXIgY2FzZXMgaXQgbWlnaHQgYmUgYXZhaWxhYmxlLCBob3dldmVyLCBpdCBtYXkg YmUgcHJlZmVycmVkDQo+PiB0byB1c2Ugc29tZSBmb3JtIG9mIG5vbi1JUCBlbmNhcHN1bGF0 aW9uLiBJbiB0aG9zZSBjYXNlcywgdGhlDQo+PiBwcm9jZWR1cmVzIGFzIG91dGxpbmVkIGlu IHNlY3Rpb24gMyBTSE9VTEQgYWxzbyBiZSB1c2VkLiINCj4+ID4NCj4+ID5SZWdhcmRpbmcg dGhlIHBlci1pbnRlcmZhY2UgTUlQIGRpc2N1c3Npb24uIFRoZSBIVyBhc3BlY3QgYWxzbyBw b3BwZWQNCj4+IHVwIGluIHRoZSBQV0UzIHNlc3Npb24gYW5kIEkgdGhpbmsgdGhpcyBpcyBh biBpbXBvcnRhbnQgY29uc2lkZXJhdGlvbiwNCj4+IGluIHBhcnRpY3VsYXIgZm9yIE9BTS4g RXZlbiBpZiB3ZSB0YWxrIGFib3V0IFRMVnMsIHdlIGNvdWxkIG1ha2UgaXQgYQ0KPj4gTVVT VCB0aGF0IGFuIEFkZHJlc3MgVExWIGlzIGFsd2F5cyB0aGUgZmlyc3Qgb25lIHRvIGFwcGVh ci4gSWYgeW91IGNhbg0KPj4gZmFjaWxpdGF0ZSBhbiBlYXN5IGltcGxlbWVudGF0aW9uIGlu IGhhcmR3YXJlLCBJIHNlZSBubyByZWFzb24gdG8NCj4+IGRlbGliZXJhdGVseSBub3QgZG8g aXQuDQo+PiA+DQo+PiA+QmVzdCwNCj4+ID4NCj4+ID5Sb2xmDQo+PiA+DQo+PiA+DQo+PiA+ TkVDIEV1cm9wZSBMaW1pdGVkIHwgUmVnaXN0ZXJlZCBPZmZpY2U6IE5FQyBIb3VzZSwgMSBW aWN0b3JpYSBSb2FkLA0KPj4gTG9uZG9uIFczIDZCTCB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFu ZCAyODMyMDE0DQo+PiA+DQo+PiA+DQo+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4gPj4gRnJvbTogRXJpYyBHcmF5IFttYWlsdG86ZXJpYy5ncmF5QGVyaWNzc29uLmNv bV0NCj4+ID4+IFNlbnQ6IE1vbnRhZywgMjguIE3kcnogMjAxMSAxMTo0Mw0KPj4gPj4gVG86 IFJvbGYgV2ludGVyDQo+PiA+PiBDYzogbG9hQHBpLm51OyBtcGxzQGlldGYub3JnDQo+PiA+ PiBTdWJqZWN0OiBSRTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENhbGwgb24gZHJhZnQt aWV0Zi1tcGxzLXRwLW9uLQ0KPj4gPj4gZGVtYW5kLWN2LTAzDQo+PiA+Pg0KPj4gPj4gUm9s ZiwNCj4+ID4+DQo+PiA+PiAJV2l0aCByZWdhcmQgdG8gdGhlIHVzZSBvZiBTSE9VTEQgKHZl cnNlcyBNVVNUKSAtIHRoZSBpbnRlbnQNCj4+ID4+IChhY2NvcmRpbmcgdG8gUkZDIDIxMTkg LSBzZWUgdGhlIHF1b3RlIGJlbG93KSBpcyBjb25zaXN0ZW50IHdpdGgNCj4+ID4+IHRoaXMg Y2FzZS4gIElmIC0gZm9yIHNvbWUgcmVhc29uIC0gb25lIGhhZCBhIHJlYWxseSBnb29kIHJl YXNvbiB0bw0KPj4gPj4gdXNlIElQIGFkZHJlc3NpbmcgaW4gc29tZSBzcGVjaWZpYyBjYXNl LCBvbmUgY291bGQgdGFrZSBzdGVwcyB0bw0KPj4gPj4gbWFrZSBJUCBhZGRyZXNzaW5nIGF2 YWlsYWJsZS4NCj4+ID4+DQo+PiA+PiAJVGhpcyBjb3VsZCBiZSBzYWlkIHRvIGludHJvZHVj ZSBhIGxvZ2ljYWwgZGlzY29ubmVjdCwgYnV0IHdlDQo+PiA+PiBhcmUgc2F2ZWQgZnJvbSBn b2luZyBkb3duIHRoYXQgcGF0aCBieSB0aGUgZmFjdCB0aGF0IHRoZSBzdGF0ZW1lbnQNCj4+ ID4+IGFsc28gaW5jbHVkZXMgdGhlIGNhc2Ugd2hlcmUgKGZvciBzb21lIHJlYXNvbikgdGhl cmUgaXMgYSBjYXNlIGluDQo+PiA+PiB3aGljaCBzb21lIG90aGVyIGFkZHJlc3Npbmcgc2No ZW1lIG1pZ2h0IGJlIHByZWZlcnJlZC4gIEluIG1hbnkgb2YNCj4+ID4+IHRoZSBjYXNlcyB3 aGVyZSBhbm90aGVyIGFkZHJlc3Npbmcgc2NoZW1lIG1heSBiZSBwcmVmZXJyZWQsIGl0IGlz DQo+PiA+PiBzdGlsbCBwb3NzaWJsZSAoaW4gZmFjdCBsaWtlbHkpIHRoYXQgSVAgYWRkcmVz c2luZyBpcyBhdmFpbGFibGUuDQo+PiA+Pg0KPj4gPj4gCU90aGVyd2lzZSwgaXQgd291bGQg bm90IGhhdmUgYmVlbiBuZWNlc3NhcnkgdG8gZGlzdGluZ3Vpc2gNCj4+ID4+IHRoaXMgY2Fz ZSBmcm9tIHRoZSBvbmUgaW4gd2hpY2ggSVAgYWRkcmVzc2luZyBpcyBub3QgYXZhaWxhYmxl Lg0KPj4gPj4NCj4+ID4+IAlGb3IgdGhlIGNhc2Ugd2hlcmUgSVAgYWRkcmVzc2luZyBpcyBu b3QgdGhlIHByZWZlcnJlZCBtb2RlLA0KPj4gPj4gd2UgYXJlIHJlY29tbWVuZGluZyBhIG1v ZGUgaW4gd2hpY2ggaXQgaXMgbm90IG5lY2Vzc2FyeS4NCj4+ID4+DQo+PiA+PiAJV2l0aCBy ZWdhcmQgdG8gaGF2aW5nIGFkZHJlc3NlcyBsb2NhdGVkIGluIHRoZSBzYW1lIHBsYWNlLA0K Pj4gPj4gdGhpcyBwcm90b2NvbCBpcyBtZWFudCBmb3IgY29ubmVjdGl2aXR5IHRlc3Rpbmcg b24gYW4gb24tZGVtYW5kDQo+PiA+PiBiYXNpcyBhbmQgaXMgdGhlcmVmb3JlIG5vdCBvcHRp bWl6ZWQgZm9yIHByb2Nlc3NpbmcgaW4gaGFyZHdhcmUuDQo+PiA+Pg0KPj4gPj4gCVdoZXRo ZXIgYWRkcmVzc2VzIG9yIGlkZW50aWZpZXJzLCBpZiB3ZSBhcmUgdGFsa2luZyBhYm91dA0K Pj4gPj4gVExWIGNvbnRlbnRzLCB0aGVyZSBhcmUgaXNzdWVzIHdpdGggdHJ5aW5nIHRvIGd1 YXJhbnRlZSBsb2NhdGlvbg0KPj4gPj4gb2Ygc3BlY2lmaWMgY29udGVudCwgYmVjYXVzZSBv ZiB0aGUgZmFjdCB0aGF0IHRoZSBUTFYgaW4gcXVlc3Rpb24NCj4+ID4+IHdpbGwgcHJvYmFi bHkgZm9sbG93IG90aGVyIFRMVnMgLSB0aHVzIG1ha2luZyBsb2NhdGlvbnMgZGlmZmljdWx0 DQo+PiA+PiB0byBwcmVkaWN0IGluIGFueSBjYXNlLg0KPj4gPj4NCj4+ID4+IAlXaXRoIHJl Z2FyZCB0byBuZWVkaW5nIG1vcmUgdGV4dCBvbiBwZXItaW50ZXJmYWNlIE1JUHMsIGRvDQo+ PiA+PiB5b3UgaGF2ZSBzcGVjaWZpYyBzdWdnZXN0aW9ucyBhcyB0byB3aGF0IHRleHQgd2Ug bWlnaHQgYWRkPw0KPj4gPj4NCj4+ID4+IAlJIHVuZGVyc3RhbmQgKGZyb20gZGlzY3Vzc2lv biB3aXRoIFdHIGNoYWlycykgdGhhdCB3ZSBhcmUNCj4+ID4+IG5vdCBhbGxvd2VkIHRvIGV4 cGxpY2l0bHkgYWRkcmVzcyBsYXN0IGNhbGwgY29tbWVudHMgZHVyaW5nIHRoZQ0KPj4gPj4g SUVURiBtZWV0aW5nIGluIFByYWd1ZSwgYmVjYXVzZSB0aGUgbGFzdCBjYWxsIGlzIHN0aWxs IG9uZ29pbmcNCj4+ID4+IGF0IHRoYXQgdGltZS4NCj4+ID4+DQo+PiA+PiAtLQ0KPj4gPj4g RXJpYw0KPj4gPj4NCj4+ID4+IFBTIC0NCj4+ID4+IEZyb20gUkZDIDIxMTkgLQ0KPj4gPj4g J1NIT1VMRCAgIFRoaXMgd29yZCwgb3IgdGhlIGFkamVjdGl2ZSAiUkVDT01NRU5ERUQiLCBt ZWFuIHRoYXQgdGhlcmUNCj4+ID4+ICAgICAgICAgICBtYXkgZXhpc3QgdmFsaWQgcmVhc29u cyBpbiBwYXJ0aWN1bGFyIGNpcmN1bXN0YW5jZXMgdG8NCj4+ID4+ICAgICAgICAgICBpZ25v cmUgYSBwYXJ0aWN1bGFyIGl0ZW0sIGJ1dCB0aGUgZnVsbCBpbXBsaWNhdGlvbnMgbXVzdA0K Pj4gPj4gICAgICAgICAgIGJlIHVuZGVyc3Rvb2QgYW5kIGNhcmVmdWxseSB3ZWlnaGVkIGJl Zm9yZSBjaG9vc2luZyBhDQo+PiA+PiAgICAgICAgICAgZGlmZmVyZW50IGNvdXJzZS4nDQo+ PiA+Pg0KPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+IEZyb206IG1w bHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmDQo+PiBPZg0KPj4gPj4gUm9sZiBXaW50ZXINCj4+ID4+IFNlbnQ6IFR1ZXNkYXks IE1hcmNoIDIyLCAyMDExIDQ6NTcgQU0NCj4+ID4+IFRvOiBsb2FAcGkubnU7IG1wbHNAaWV0 Zi5vcmcNCj4+ID4+IFN1YmplY3Q6IFJlOiBbbXBsc10gV29ya2luZyBHcm91cCBMYXMgQ2Fs bCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtb24tDQo+PiA+PiBkZW1hbmQtY3YtMDMNCj4+ID4+ DQo+PiA+PiBIaSwNCj4+ID4+DQo+PiA+PiBzb21lIGNvbW1lbnRzIGJlbG93Og0KPj4gPj4N Cj4+ID4+IFNlY3Rpb24gMS4zIHNheXM6ICIgSW4gY2VydGFpbiBNUExTLVRQIGRlcGxveW1l bnQgc2NlbmFyaW9zIElQDQo+PiA+PiBhZGRyZXNzaW5nIG1pZ2h0IG5vdCBiZQ0KPj4gPj4g ICAgYXZhaWxhYmxlIG9yIGl0IG1heSBiZSBwcmVmZXJyZWQgdG8gdXNlIHNvbWUgZm9ybSBv ZiBub24tSVANCj4+ID4+ICAgIGVuY2Fwc3VsYXRpb24gZm9yIE9uLWRlbWFuZCBDViwgcm91 dGUgdHJhY2luZyBhbmQgQkZEIHBhY2tldHMuDQo+PiBJbg0KPj4gPj4gICAgc3VjaCBzY2Vu YXJpb3MsIE9uLWRlbWFuZCBDViBhbmQvb3Igcm91dGUgdHJhY2luZyBTSE9VTEQgYmUgcnVu DQo+PiA+PiAgICB3aXRob3V0IElQIGFkZHJlc3NpbmcuLi4iDQo+PiA+Pg0KPj4gPj4gSSBh bSBub3Qgc3VyZSB0aGUgIlNIT1VMRCIgaXMgcmlnaHQgaGVyZS4gSWYgbm8gSVAgYWRkcmVz c2luZyBpcw0KPj4gPj4gYXZhaWxhYmxlLCB0aGlzIHRoaW5nIE1VU1QgYmUgcnVuIHdpdGhv dXQgSVAgYWRkcmVzc2luZywgbXVzdG4ndCBpdD8NCj4+ID4+DQo+PiA+PiBJIHRoaW5rIHNv bWUgYWRkaXRpb25hbCB0ZXh0IHJlZ2FyZGluZyBwZXItaW50ZXJmYWNlIE1JUCBhZGRyZXNz aW5nDQo+PiA+PiB3b3VsZCBiZSBuaWNlLiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kIHRoZSBk b2N1bWVudCwgYWxsIFRMVnMgd2lsbCBiZQ0KPj4gPj4gaW5zaWRlIHRoZSBMU1AgcGluZyBw YWNrZXQgKHJhdGhlciB0aGFuIGFzIEFDSCBUTFZzKS4NCj4+ID4+DQo+PiA+PiBTb21lIHBl b3BsZSBoYWQgY29uY2VybnMgZWFybGllciwgdGhhdCBhZGRyZXNzaW5nIGluZm9ybWF0aW9u IHNob3VsZA0KPj4gYmUNCj4+ID4+IGluIGEgZml4ZWQgbG9jYXRpb24gZm9yIGVhc2llciBw cm9jZXNzaW5nLiBJcyB0aGlzIHRoZSBjYXNlIGhlcmUgSQ0KPj4gPj4gd29uZGVyPw0KPj4g Pj4NCj4+ID4+IEl0IHdvdWxkIGJlIG5pY2UgaWYgeW91IGNvdWxkIGFkZHJlc3MgdGhpcyBp biB5b3VyIHByZXNlbnRhdGlvbiBpbg0KPj4gPj4gUHJhZ3VlLg0KPj4gPj4NCj4+ID4+IFRo YW5rcywNCj4+ID4+DQo+PiA+PiBSb2xmDQo+PiA+Pg0KPj4gPj4NCj4+ID4+IE5FQyBFdXJv cGUgTGltaXRlZCB8IFJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2UsIDEgVmljdG9yaWEg Um9hZCwNCj4+ID4+IExvbmRvbiBXMyA2QkwgfCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgMjgz MjAxNA0KPj4gPj4NCj4+ID4+DQo+PiA+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+PiA+PiA+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91 bmNlc0BpZXRmLm9yZ10gT24NCj4+IEJlaGFsZg0KPj4gPj4gT2YNCj4+ID4+ID4gbG9hQHBp Lm51DQo+PiA+PiA+IFNlbnQ6IE1pdHR3b2NoLCAxNi4gTeRyeiAyMDExIDAwOjI2DQo+PiA+ PiA+IFRvOiBtcGxzQGlldGYub3JnDQo+PiA+PiA+IENjOiBNUExTLVRQIGFkIGhvYyB0ZWFt DQo+PiA+PiA+IFN1YmplY3Q6IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9uIGRy YWZ0LWlldGYtbXBscy10cC1vbi0NCj4+ID4+IGRlbWFuZC0NCj4+ID4+ID4gY3YtMDMNCj4+ ID4+ID4NCj4+ID4+ID4gV29ya2luZyBHcm91cCwNCj4+ID4+ID4NCj4+ID4+ID4gdGhpcyBp cyB0byBzdGFydCBhIDMgd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbg0KPj4gPj4g Pg0KPj4gPj4gPiBkcmFmdC1pZXRmLW1wbHMtdHAtb24tZGVtYW5kLWN2LTAzDQo+PiA+PiA+ DQo+PiA+PiA+IFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRoZSB3b3JraW5nIGdyb3VwIG1h aWxpbmcgbGlzdA0KPj4gPj4gPiBtcGxzQGlldGYub3JnDQo+PiA+PiA+DQo+PiA+PiA+IFRo ZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIEFwcmlsIDgsIDIwMTEuDQo+PiA+ PiA+DQo+PiA+PiA+IC9Mb2ENCj4+ID4+ID4NCj4+ID4+ID4NCj4+ID4+ID4NCj4+ID4+ID4N Cj4+ID4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+ID4+ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4+ID4+ID4gbXBsc0BpZXRmLm9yZw0K Pj4gPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+ ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiA+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4gPj4gbXBsc0BpZXRmLm9yZw0KPj4gPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+PiA+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID5tcGxzIG1haWxp bmcgbGlzdA0KPj4gPm1wbHNAaWV0Zi5vcmcNCj4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+ID4NCj4NCg== --GMAILSMTPBOUND01110328224346-- From Internet-Drafts@ietf.org Mon Mar 28 10:00:03 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140F83A6820; Mon, 28 Mar 2011 10:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, 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 AZzqMmlKIexL; Mon, 28 Mar 2011 10:00:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C0C43A6825; Mon, 28 Mar 2011 10:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.13 Message-ID: <20110328170002.8399.48338.idtracker@localhost> Date: Mon, 28 Mar 2011 10:00:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-ldp-ipv6-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Updates to LDP for IPv6 Author(s) : V. Manral, et al. Filename : draft-ietf-mpls-ldp-ipv6-02.txt Pages : 13 Date : 2011-03-28 The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4, IPv6 or both networks. This document corrects and clarifies the LDP behavior when IPv6 network is used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ipv6-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-ipv6-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-28095017.I-D@ietf.org> --NextPart-- From sboutros@cisco.com Mon Mar 28 13:14:51 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2B4928C0F0 for ; Mon, 28 Mar 2011 13:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ny2W3FKXUz0I for ; Mon, 28 Mar 2011 13:14:49 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D48D63A6904 for ; Mon, 28 Mar 2011 13:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=13259; q=dns/txt; s=iport; t=1301343386; x=1302552986; h=date:to:from:subject:cc:in-reply-to:references: mime-version:content-transfer-encoding:message-id; bh=sWOxx9D7IPyBPUypcunbcaSte4TKmrMXALj4aTQ/6OA=; b=Ud0si3YX4TDX9Nhd1CXTcXFfD/379lOvuCPUkVigqwLfa3E6BiyGSvsO Ja+nnx/QHDO/VsXMNfxYgIowdUCVAeZAMgExEo9Cx2i3GE+dG4u7VwPy0 eMDP/8MxFcy3B37kY2a+nh/KRMKvuOdthsxFF52pW5dWNoQL2FK7wjb8S Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8AABvskE2rRDoG/2dsb2JhbACHWZAwjTl3qFmcH4MPgloEhTqLFw X-IronPort-AV: E=Sophos;i="4.63,257,1299456000"; d="scan'208";a="284359970" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 28 Mar 2011 20:08:37 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2SK8aaG011933; Mon, 28 Mar 2011 20:08:38 GMT Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 13:08:37 -0700 Received: from sboutros-wxp02.ciswco.com ([10.21.85.111]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 13:08:36 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Mar 2011 13:08:34 -0700 To: Rolf Winter , Eric Gray , "hideki.endo.es@hitachi.com" From: Sami Boutros In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office .hd> References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 28 Mar 2011 20:08:36.0496 (UTC) FILETIME=[EBEE6900:01CBED83] Cc: "mpls@ietf.org" Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 20:14:51 -0000 At 06:02 AM 3/28/2011, Rolf Winter wrote: >Eric, > >I generally agree but I think there is one case=20 >actually which needs a closer look in this=20 >regard (which I hinted at earlier), which are=20 >the per-interface MIPs. Your TTL expires (the=20 >actual addressing bit here), the identifier=20 >tells you it is not intended for the ingress=20 >MIP, so it needs to be forwarded to the egress=20 >MIP through the forwarding engine. Now if you=20 >pull the packet out of the fast path and inject=20 >it back in, is the OAM packet still fate=20 >sharing? If you can do this in HW on the line=20 >card, then it will and it will just be forwarded as normal. It can still fate share based on the=20 implementation, if the packet get injected via=20 the same HW path, and be punted again on the Egress LineCard. >I know this is a different draft, but this will=20 >be in particular important for performance monitoring. I assume you will put the egress MIP in loopback for this monitoring.. Thanks, Sami >Best, > >Rolf > > > >NEC Europe Limited | Registered Office: NEC=20 >House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > > > -----Original Message----- > > From: Eric Gray [mailto:eric.gray@ericsson.com] > > Sent: Montag, 28. M=E4rz 2011 14:45 > > To: hideki.endo.es@hitachi.com; Rolf Winter > > Cc: mpls@ietf.org > > Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp- > > on-demand-cv-03 > > > > Hideki, > > > > What you're saying is true, but not relevant in this > > case. The "addresses" in this discussion are not used to > > determine how to forward OAM packets. They are used only > > by the recipient MIP/MEP to verify that the OAM packet was > > properly delivered. > > > > By the way, this discussion is an indication of the > > confusing injected by calling these things addresses. My > > mistake and I bring it up now to help to stem the tide of > > further comments resulting from that confusion. > > > > In the version we post after last call is complete, > > we will be changing the source and destination "address" > > TLVs to source and destination "identifier" TLVs. > > > > We will also be correcting the reference to DSMAP, > > and DDMAP, address TLVs (which is incorrect, because the > > format for DSMAP/DDMAP doesn't include a "length" field). > > > > The format of the Downstream Mapping (DSMAP) TLV is > > defined in RFC 4379, and we are not changing the format > > of that TLV. > > > > These changes are driven by last call comments we > > have already received (see Joel Halpern's comments on the > > mailing list) and are - in part - to correct accidental > > use of the word "address" for source and destination > > identifier TLVs (which is what we had discussed before > > I generated the -03 version among the authors of several > > of the current set of MPLS-TP drafts). > > > > In the case of source and destination identifiers, > > these will be used exclusively to verify that an OAM PDU > > has been correctly received by its intended recipient. > > Because this is an on-demand connectivity verification > > protocol, that is expected to be used only on those > > occasions when there is a network problem that needs to > > be diagnosed, and the information is not seen (and not > > visible - without layer violations), optimizing these > > objects for software makes sense. > > > > In addition, since either may be included (which > > includes the possibility of including both), it is the > > case already that we would then need to decide which is > > to go first - assuming we wanted to do this (which we > > do not). > > > > -- > > Eric > > > > -----Original Message----- > > From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] > > Sent: Monday, March 28, 2011 8:11 AM > > To: Eric Gray; Rolf.Winter@neclab.eu > > Cc: mpls@ietf.org > > Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on- > > demand-cv-03 > > Importance: High > > > > Hi Eric and Rolf, > > > > I'm sorry for interrupting. > > > > I agree with Rolf regarding the per-interface MIP discussion. > > We have to consider the HW implementation aspect, > > because trapping of an OAM packet is HW rule/functionality even in > > routers. > > > > If every OAM packet is trapped to CPU > > and the OAM packets which should NOT be processed in the Interface > > are returned to Data-plane, > > it is different forwarding path from user packets, > > which is NOT the Connectivity Verification of the user path. > > > > Therefore, we should take the HW aspect and flexibilty into account > > concurrently. > > If an address TLV MUST be the first in TLVs, > > it is enough to make HW implementation easy. > > > > BR, > > Hideki > > > > > > > > >Rolf, > > > > > > The words you propose are okay with me. > > > > > > I thought the MIP/interface and address location issues > > >were separate. > > > > > > I've personally had problems with protocol specifications > > >that require ordering of TLVs. In particular, this is not very > > >robust in terms of "future-proofing." What happens if new TLVs > > >are added later on; for instance, suppose at some point we have > > >multiple "address" TLVs? > > > > > > Also, the fact that implementations are allowed to attach > > >TLVs in any arbitrary order allows considerable flexibilty in > > >implementation. Messages can be built in arbitrarily many ways. > > >This too can be a future-proofing issue. > > > > > > I would prefer not to start down the road of requiring a > > >subset of TLVs to appear in a certain order, and saying we have > > >one TLV that needs to be first is doing just that. > > > > > >-- > > >Eric > > > > > >-----Original Message----- > > >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > > >Sent: Monday, March 28, 2011 6:19 AM > > >To: Eric Gray > > >Cc: mpls@ietf.org > > >Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > > demand-cv-03 > > >Importance: High > > > > > >Hi, > > > > > >I still think there is a logical error. Let me explain. In case there > > is no IP you simply cannot use it. You say you could enable IP but then > > that is not a case where there is no IP. In order to be constructive > > here is a text change suggestion: > > > > > >"In certain MPLS-TP deployment scenarios IP addressing might not be > > available. In those cases On-demand CV and/or route tracing MUST be run > > without IP addressing, using the ACH channel type specified in Section > > 3. In other cases it might be available, however, it may be preferred > > to use some form of non-IP encapsulation. In those cases, the > > procedures as outlined in section 3 SHOULD also be used." > > > > > >Regarding the per-interface MIP discussion. The HW aspect also popped > > up in the PWE3 session and I think this is an important consideration, > > in particular for OAM. Even if we talk about TLVs, we could make it a > > MUST that an Address TLV is always the first one to appear. If you can > > facilitate an easy implementation in hardware, I see no reason to > > deliberately not do it. > > > > > >Best, > > > > > >Rolf > > > > > > > > >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > > > > >> -----Original Message----- > > >> From: Eric Gray [mailto:eric.gray@ericsson.com] > > >> Sent: Montag, 28. M=E4rz 2011 11:43 > > >> To: Rolf Winter > > >> Cc: loa@pi.nu; mpls@ietf.org > > >> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > > >> demand-cv-03 > > >> > > >> Rolf, > > >> > > >> With regard to the use of SHOULD (verses MUST) - the intent > > >> (according to RFC 2119 - see the quote below) is consistent with > > >> this case. If - for some reason - one had a really good reason to > > >> use IP addressing in some specific case, one could take steps to > > >> make IP addressing available. > > >> > > >> This could be said to introduce a logical disconnect, but we > > >> are saved from going down that path by the fact that the statement > > >> also includes the case where (for some reason) there is a case in > > >> which some other addressing scheme might be preferred. In many of > > >> the cases where another addressing scheme may be preferred, it is > > >> still possible (in fact likely) that IP addressing is available. > > >> > > >> Otherwise, it would not have been necessary to distinguish > > >> this case from the one in which IP addressing is not available. > > >> > > >> For the case where IP addressing is not the preferred mode, > > >> we are recommending a mode in which it is not necessary. > > >> > > >> With regard to having addresses located in the same place, > > >> this protocol is meant for connectivity testing on an on-demand > > >> basis and is therefore not optimized for processing in hardware. > > >> > > >> Whether addresses or identifiers, if we are talking about > > >> TLV contents, there are issues with trying to guarantee location > > >> of specific content, because of the fact that the TLV in question > > >> will probably follow other TLVs - thus making locations difficult > > >> to predict in any case. > > >> > > >> With regard to needing more text on per-interface MIPs, do > > >> you have specific suggestions as to what text we might add? > > >> > > >> I understand (from discussion with WG chairs) that we are > > >> not allowed to explicitly address last call comments during the > > >> IETF meeting in Prague, because the last call is still ongoing > > >> at that time. > > >> > > >> -- > > >> Eric > > >> > > >> PS - > > >> From RFC 2119 - > > >> 'SHOULD This word, or the adjective "RECOMMENDED", mean that there > > >> may exist valid reasons in particular circumstances to > > >> ignore a particular item, but the full implications must > > >> be understood and carefully weighed before choosing a > > >> different course.' > > >> > > >> -----Original Message----- > > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > >> Rolf Winter > > >> Sent: Tuesday, March 22, 2011 4:57 AM > > >> To: loa@pi.nu; mpls@ietf.org > > >> Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > > >> demand-cv-03 > > >> > > >> Hi, > > >> > > >> some comments below: > > >> > > >> Section 1.3 says: " In certain MPLS-TP deployment scenarios IP > > >> addressing might not be > > >> available or it may be preferred to use some form of non-IP > > >> encapsulation for On-demand CV, route tracing and BFD packets. > > In > > >> such scenarios, On-demand CV and/or route tracing SHOULD be run > > >> without IP addressing..." > > >> > > >> I am not sure the "SHOULD" is right here. If no IP addressing is > > >> available, this thing MUST be run without IP addressing, mustn't it? > > >> > > >> I think some additional text regarding per-interface MIP addressing > > >> would be nice. As far as I understand the document, all TLVs will be > > >> inside the LSP ping packet (rather than as ACH TLVs). > > >> > > >> Some people had concerns earlier, that addressing information should > > be > > >> in a fixed location for easier processing. Is this the case here I > > >> wonder? > > >> > > >> It would be nice if you could address this in your presentation in > > >> Prague. > > >> > > >> Thanks, > > >> > > >> Rolf > > >> > > >> > > >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > >> London W3 6BL | Registered in England 2832014 > > >> > > >> > > >> > -----Original Message----- > > >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf > > >> Of > > >> > loa@pi.nu > > >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26 > > >> > To: mpls@ietf.org > > >> > Cc: MPLS-TP ad hoc team > > >> > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > > >> demand- > > >> > cv-03 > > >> > > > >> > Working Group, > > >> > > > >> > this is to start a 3 week working group last call on > > >> > > > >> > draft-ietf-mpls-tp-on-demand-cv-03 > > >> > > > >> > Please send comments to the working group mailing list > > >> > mpls@ietf.org > > >> > > > >> > The working group last call ends on April 8, 2011. > > >> > > > >> > /Loa > > >> > > > >> > > > >> > > > >> > > > >> > _______________________________________________ > > >> > mpls mailing list > > >> > mpls@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/mpls > > >> _______________________________________________ > > >> mpls mailing list > > >> mpls@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mpls > > >_______________________________________________ > > >mpls mailing list > > >mpls@ietf.org > > >https://www.ietf.org/mailman/listinfo/mpls > > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From sboutros@cisco.com Mon Mar 28 13:31:40 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011683A693D for ; Mon, 28 Mar 2011 13:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 sxIJjkZBw4df for ; Mon, 28 Mar 2011 13:31:38 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 212693A68C2 for ; Mon, 28 Mar 2011 13:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=13824; q=dns/txt; s=iport; t=1301344395; x=1302553995; h=date:to:from:subject:cc:in-reply-to:references: mime-version:content-transfer-encoding:message-id; bh=aZLBsBliKCYAhAmP+qAegXttF4et/4kiU3XGJDvvnyY=; b=TlfqYaeY9LBqt+Z26FlRrfYw616F4jwYRkF5rL8flSsDAhZMkoqdgpA0 81H7P+4gkfwrRWYjTr8dz2iYm7Zpb/ZYv7VTwbcZjMWbeF3gXGmqSiI5k 5tY3Q0ccShDbv7aAH6LNsCOIN7HaK389Nzdo5Wtw9Ek03b2sLeafDEY8/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8AAJ/vkE2rRDoJ/2dsb2JhbACHWZAwjTl3qGKcJIMPgloEhTqLFw X-IronPort-AV: E=Sophos;i="4.63,257,1299456000"; d="scan'208";a="284383052" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 28 Mar 2011 20:33:14 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2SKXF7U031941; Mon, 28 Mar 2011 20:33:15 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 13:33:15 -0700 Received: from sboutros-wxp02.ciswco.com ([10.21.85.111]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 13:33:14 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Mar 2011 13:33:15 -0700 To: , , From: Sami Boutros In-Reply-To: References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 28 Mar 2011 20:33:15.0057 (UTC) FILETIME=[5D38EA10:01CBED87] Cc: mpls@ietf.org Subject: Re: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 20:31:40 -0000 At 06:43 AM 3/28/2011, hideki.endo.es@hitachi.com wrote: >Hi Eric, > >What I'd like to say was explaned by Rolf. >My concern is whether the OAM packet is fate sharing with user packet or= NOT. >If draft-on-demand-cv doesn't care anything for fate sharing >in the case of per-interface MIP, >the per-interface MIP can NOT be implemented by HW reasonably. Keep in mind that a node decrement TTL once, and=20 this per-interface MIP seems to require a node to decrement twice.. Thanks, Sami >BR, >Hideki > > >Eric, > > > >I generally agree but I think there is one=20 > case actually which needs a closer look in this=20 > regard (which I hinted at earlier), which are=20 > the per-interface MIPs. Your TTL expires (the=20 > actual addressing bit here), the identifier=20 > tells you it is not intended for the ingress=20 > MIP, so it needs to be forwarded to the egress=20 > MIP through the forwarding engine. Now if you=20 > pull the packet out of the fast path and inject=20 > it back in, is the OAM packet still fate=20 > sharing? If you can do this in HW on the line=20 > card, then it will and it will just be=20 > forwarded as normal. I know this is a different=20 > draft, but this will be in particular important for performance= monitoring. > > > >Best, > > > >Rolf > > > > > > > >NEC Europe Limited | Registered Office: NEC=20 > House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > > > > >> -----Original Message----- > >> From: Eric Gray [mailto:eric.gray@ericsson.com] > >> Sent: Montag, 28. M=E4rz 2011 14:45 > >> To: hideki.endo.es@hitachi.com; Rolf Winter > >> Cc: mpls@ietf.org > >> Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp- > >> on-demand-cv-03 > >> > >> Hideki, > >> > >> What you're saying is true, but not relevant in this > >> case. The "addresses" in this discussion are not used to > >> determine how to forward OAM packets. They are used only > >> by the recipient MIP/MEP to verify that the OAM packet was > >> properly delivered. > >> > >> By the way, this discussion is an indication of the > >> confusing injected by calling these things addresses. My > >> mistake and I bring it up now to help to stem the tide of > >> further comments resulting from that confusion. > >> > >> In the version we post after last call is complete, > >> we will be changing the source and destination "address" > >> TLVs to source and destination "identifier" TLVs. > >> > >> We will also be correcting the reference to DSMAP, > >> and DDMAP, address TLVs (which is incorrect, because the > >> format for DSMAP/DDMAP doesn't include a "length" field). > >> > >> The format of the Downstream Mapping (DSMAP) TLV is > >> defined in RFC 4379, and we are not changing the format > >> of that TLV. > >> > >> These changes are driven by last call comments we > >> have already received (see Joel Halpern's comments on the > >> mailing list) and are - in part - to correct accidental > >> use of the word "address" for source and destination > >> identifier TLVs (which is what we had discussed before > >> I generated the -03 version among the authors of several > >> of the current set of MPLS-TP drafts). > >> > >> In the case of source and destination identifiers, > >> these will be used exclusively to verify that an OAM PDU > >> has been correctly received by its intended recipient. > >> Because this is an on-demand connectivity verification > >> protocol, that is expected to be used only on those > >> occasions when there is a network problem that needs to > >> be diagnosed, and the information is not seen (and not > >> visible - without layer violations), optimizing these > >> objects for software makes sense. > >> > >> In addition, since either may be included (which > >> includes the possibility of including both), it is the > >> case already that we would then need to decide which is > >> to go first - assuming we wanted to do this (which we > >> do not). > >> > >> -- > >> Eric > >> > >> -----Original Message----- > >> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] > >> Sent: Monday, March 28, 2011 8:11 AM > >> To: Eric Gray; Rolf.Winter@neclab.eu > >> Cc: mpls@ietf.org > >> Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on- > >> demand-cv-03 > >> Importance: High > >> > >> Hi Eric and Rolf, > >> > >> I'm sorry for interrupting. > >> > >> I agree with Rolf regarding the per-interface MIP discussion. > >> We have to consider the HW implementation aspect, > >> because trapping of an OAM packet is HW rule/functionality even in > >> routers. > >> > >> If every OAM packet is trapped to CPU > >> and the OAM packets which should NOT be processed in the Interface > >> are returned to Data-plane, > >> it is different forwarding path from user packets, > >> which is NOT the Connectivity Verification of the user path. > >> > >> Therefore, we should take the HW aspect and flexibilty into account > >> concurrently. > >> If an address TLV MUST be the first in TLVs, > >> it is enough to make HW implementation easy. > >> > >> BR, > >> Hideki > >> > >> > >> > >> >Rolf, > >> > > >> > The words you propose are okay with me. > >> > > >> > I thought the MIP/interface and address location issues > >> >were separate. > >> > > >> > I've personally had problems with protocol specifications > >> >that require ordering of TLVs. In particular, this is not very > >> >robust in terms of "future-proofing." What happens if new TLVs > >> >are added later on; for instance, suppose at some point we have > >> >multiple "address" TLVs? > >> > > >> > Also, the fact that implementations are allowed to attach > >> >TLVs in any arbitrary order allows considerable flexibilty in > >> >implementation. Messages can be built in arbitrarily many ways. > >> >This too can be a future-proofing issue. > >> > > >> > I would prefer not to start down the road of requiring a > >> >subset of TLVs to appear in a certain order, and saying we have > >> >one TLV that needs to be first is doing just that. > >> > > >> >-- > >> >Eric > >> > > >> >-----Original Message----- > >> >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > >> >Sent: Monday, March 28, 2011 6:19 AM > >> >To: Eric Gray > >> >Cc: mpls@ietf.org > >> >Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > >> demand-cv-03 > >> >Importance: High > >> > > >> >Hi, > >> > > >> >I still think there is a logical error. Let me explain. In case there > >> is no IP you simply cannot use it. You say you could enable IP but then > >> that is not a case where there is no IP. In order to be constructive > >> here is a text change suggestion: > >> > > >> >"In certain MPLS-TP deployment scenarios IP addressing might not be > >> available. In those cases On-demand CV and/or route tracing MUST be run > >> without IP addressing, using the ACH channel type specified in Section > >> 3. In other cases it might be available, however, it may be preferred > >> to use some form of non-IP encapsulation. In those cases, the > >> procedures as outlined in section 3 SHOULD also be used." > >> > > >> >Regarding the per-interface MIP discussion. The HW aspect also popped > >> up in the PWE3 session and I think this is an important consideration, > >> in particular for OAM. Even if we talk about TLVs, we could make it a > >> MUST that an Address TLV is always the first one to appear. If you can > >> facilitate an easy implementation in hardware, I see no reason to > >> deliberately not do it. > >> > > >> >Best, > >> > > >> >Rolf > >> > > >> > > >> >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > >> London W3 6BL | Registered in England 2832014 > >> > > >> > > >> >> -----Original Message----- > >> >> From: Eric Gray [mailto:eric.gray@ericsson.com] > >> >> Sent: Montag, 28. M=E4rz 2011 11:43 > >> >> To: Rolf Winter > >> >> Cc: loa@pi.nu; mpls@ietf.org > >> >> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > >> >> demand-cv-03 > >> >> > >> >> Rolf, > >> >> > >> >> With regard to the use of SHOULD (verses MUST) - the intent > >> >> (according to RFC 2119 - see the quote below) is consistent with > >> >> this case. If - for some reason - one had a really good reason to > >> >> use IP addressing in some specific case, one could take steps to > >> >> make IP addressing available. > >> >> > >> >> This could be said to introduce a logical disconnect, but we > >> >> are saved from going down that path by the fact that the statement > >> >> also includes the case where (for some reason) there is a case in > >> >> which some other addressing scheme might be preferred. In many of > >> >> the cases where another addressing scheme may be preferred, it is > >> >> still possible (in fact likely) that IP addressing is available. > >> >> > >> >> Otherwise, it would not have been necessary to distinguish > >> >> this case from the one in which IP addressing is not available. > >> >> > >> >> For the case where IP addressing is not the preferred mode, > >> >> we are recommending a mode in which it is not necessary. > >> >> > >> >> With regard to having addresses located in the same place, > >> >> this protocol is meant for connectivity testing on an on-demand > >> >> basis and is therefore not optimized for processing in hardware. > >> >> > >> >> Whether addresses or identifiers, if we are talking about > >> >> TLV contents, there are issues with trying to guarantee location > >> >> of specific content, because of the fact that the TLV in question > >> >> will probably follow other TLVs - thus making locations difficult > >> >> to predict in any case. > >> >> > >> >> With regard to needing more text on per-interface MIPs, do > >> >> you have specific suggestions as to what text we might add? > >> >> > >> >> I understand (from discussion with WG chairs) that we are > >> >> not allowed to explicitly address last call comments during the > >> >> IETF meeting in Prague, because the last call is still ongoing > >> >> at that time. > >> >> > >> >> -- > >> >> Eric > >> >> > >> >> PS - > >> >> From RFC 2119 - > >> >> 'SHOULD This word, or the adjective "RECOMMENDED", mean that there > >> >> may exist valid reasons in particular circumstances to > >> >> ignore a particular item, but the full implications must > >> >> be understood and carefully weighed before choosing a > >> >> different course.' > >> >> > >> >> -----Original Message----- > >> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > >> Of > >> >> Rolf Winter > >> >> Sent: Tuesday, March 22, 2011 4:57 AM > >> >> To: loa@pi.nu; mpls@ietf.org > >> >> Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > >> >> demand-cv-03 > >> >> > >> >> Hi, > >> >> > >> >> some comments below: > >> >> > >> >> Section 1.3 says: " In certain MPLS-TP deployment scenarios IP > >> >> addressing might not be > >> >> available or it may be preferred to use some form of non-IP > >> >> encapsulation for On-demand CV, route tracing and BFD packets. > >> In > >> >> such scenarios, On-demand CV and/or route tracing SHOULD be run > >> >> without IP addressing..." > >> >> > >> >> I am not sure the "SHOULD" is right here. If no IP addressing is > >> >> available, this thing MUST be run without IP addressing, mustn't it? > >> >> > >> >> I think some additional text regarding per-interface MIP addressing > >> >> would be nice. As far as I understand the document, all TLVs will be > >> >> inside the LSP ping packet (rather than as ACH TLVs). > >> >> > >> >> Some people had concerns earlier, that addressing information should > >> be > >> >> in a fixed location for easier processing. Is this the case here I > >> >> wonder? > >> >> > >> >> It would be nice if you could address this in your presentation in > >> >> Prague. > >> >> > >> >> Thanks, > >> >> > >> >> Rolf > >> >> > >> >> > >> >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > >> >> London W3 6BL | Registered in England 2832014 > >> >> > >> >> > >> >> > -----Original Message----- > >> >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >> Behalf > >> >> Of > >> >> > loa@pi.nu > >> >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26 > >> >> > To: mpls@ietf.org > >> >> > Cc: MPLS-TP ad hoc team > >> >> > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > >> >> demand- > >> >> > cv-03 > >> >> > > >> >> > Working Group, > >> >> > > >> >> > this is to start a 3 week working group last call on > >> >> > > >> >> > draft-ietf-mpls-tp-on-demand-cv-03 > >> >> > > >> >> > Please send comments to the working group mailing list > >> >> > mpls@ietf.org > >> >> > > >> >> > The working group last call ends on April 8, 2011. > >> >> > > >> >> > /Loa > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > mpls mailing list > >> >> > mpls@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/mpls > >> >> _______________________________________________ > >> >> mpls mailing list > >> >> mpls@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/mpls > >> >_______________________________________________ > >> >mpls mailing list > >> >mpls@ietf.org > >> >https://www.ietf.org/mailman/listinfo/mpls > >> > > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From gregimirsky@gmail.com Mon Mar 28 15:03:09 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C423F3A6956 for ; Mon, 28 Mar 2011 15:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 5VtIu-HCcgTS for ; Mon, 28 Mar 2011 15:03:06 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 8B87A3A677C for ; Mon, 28 Mar 2011 15:03:06 -0700 (PDT) Received: by vws12 with SMTP id 12so3143784vws.31 for ; Mon, 28 Mar 2011 15:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5VUe3XqDB5MdwOmROnnhy5HGUymEWKEeZ6o2FmION24=; b=bzT38hJoPRfdXQY2hWIibQ6ybv2d1hPwTHBl9CNBgfFsrdrui5bkZ+QdA0G4F/bS2F 3TBxTMwvRvt+DFAbKJc4frrKBIAMiaBifhC9mQAUS6uN7E8ODYhGFCS7WSduCHOSCPgI +a5dBVH58UGK/V/8UCjcyVfra+2MwEbg10RZo= 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=mdjdHMj2NDL1UwZr+fqUci3nCOKwOnxP4tLJ/J+KO0eAjf27xFheqVmEFy6t20Xs4o YLV1Cr8v1ajWzE2zsGzakT+BoH2GoFroUrBKIhfh3lqCMMkxdFolHOc2+J2y7C59xEVr xgKxYIvJ/VoXyqX6EA//sWth03YoIC2d4UNL4= MIME-Version: 1.0 Received: by 10.52.0.7 with SMTP id 7mr6071458vda.255.1301349883391; Mon, 28 Mar 2011 15:04:43 -0700 (PDT) Received: by 10.52.161.198 with HTTP; Mon, 28 Mar 2011 15:04:43 -0700 (PDT) In-Reply-To: References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> Date: Mon, 28 Mar 2011 15:04:43 -0700 Message-ID: From: Greg Mirsky To: Sami Boutros Content-Type: multipart/alternative; boundary=20cf30549f69872df8049f9221be Cc: mpls@ietf.org, Rolf.Winter@neclab.eu Subject: Re: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:03:09 -0000 --20cf30549f69872df8049f9221be Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Sami, alternative to decrementing TTL for out-MIP approach, to use reserved Outgoing MIP Label (OML), presented in draft-farrel-mpls-tp-mip-mep-map-03. Considering that few proposed MPLS-TP OAM mechanisms use ACH TLV Header per RFC 5586 OML might be the better solution to address out-MIP. Regards, Greg On Mon, Mar 28, 2011 at 1:33 PM, Sami Boutros wrote: > At 06:43 AM 3/28/2011, hideki.endo.es@hitachi.com wrote: > >> Hi Eric, >> >> What I'd like to say was explaned by Rolf. >> My concern is whether the OAM packet is fate sharing with user packet or >> NOT. >> If draft-on-demand-cv doesn't care anything for fate sharing >> in the case of per-interface MIP, >> the per-interface MIP can NOT be implemented by HW reasonably. >> > > Keep in mind that a node decrement TTL once, and this per-interface MIP > seems to require a node to decrement twice.. > > Thanks, > > Sami > > > BR, >> Hideki >> >> >Eric, >> > >> >I generally agree but I think there is one case actually which needs a >> closer look in this regard (which I hinted at earlier), which are the >> per-interface MIPs. Your TTL expires (the actual addressing bit here), t= he >> identifier tells you it is not intended for the ingress MIP, so it needs= to >> be forwarded to the egress MIP through the forwarding engine. Now if you >> pull the packet out of the fast path and inject it back in, is the OAM >> packet still fate sharing? If you can do this in HW on the line card, th= en >> it will and it will just be forwarded as normal. I know this is a differ= ent >> draft, but this will be in particular important for performance monitori= ng. >> > >> >Best, >> > >> >Rolf >> > >> > >> > >> >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >> London W3 6BL | Registered in England 2832014 >> > >> > >> >> -----Original Message----- >> >> From: Eric Gray [mailto:eric.gray@ericsson.com] >> >> Sent: Montag, 28. M=E4rz 2011 14:45 >> >> To: hideki.endo.es@hitachi.com; Rolf Winter >> >> Cc: mpls@ietf.org >> >> Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-t= p- >> >> on-demand-cv-03 >> >> >> >> Hideki, >> >> >> >> What you're saying is true, but not relevant in this >> >> case. The "addresses" in this discussion are not used to >> >> determine how to forward OAM packets. They are used only >> >> by the recipient MIP/MEP to verify that the OAM packet was >> >> properly delivered. >> >> >> >> By the way, this discussion is an indication of the >> >> confusing injected by calling these things addresses. My >> >> mistake and I bring it up now to help to stem the tide of >> >> further comments resulting from that confusion. >> >> >> >> In the version we post after last call is complete, >> >> we will be changing the source and destination "address" >> >> TLVs to source and destination "identifier" TLVs. >> >> >> >> We will also be correcting the reference to DSMAP, >> >> and DDMAP, address TLVs (which is incorrect, because the >> >> format for DSMAP/DDMAP doesn't include a "length" field). >> >> >> >> The format of the Downstream Mapping (DSMAP) TLV is >> >> defined in RFC 4379, and we are not changing the format >> >> of that TLV. >> >> >> >> These changes are driven by last call comments we >> >> have already received (see Joel Halpern's comments on the >> >> mailing list) and are - in part - to correct accidental >> >> use of the word "address" for source and destination >> >> identifier TLVs (which is what we had discussed before >> >> I generated the -03 version among the authors of several >> >> of the current set of MPLS-TP drafts). >> >> >> >> In the case of source and destination identifiers, >> >> these will be used exclusively to verify that an OAM PDU >> >> has been correctly received by its intended recipient. >> >> Because this is an on-demand connectivity verification >> >> protocol, that is expected to be used only on those >> >> occasions when there is a network problem that needs to >> >> be diagnosed, and the information is not seen (and not >> >> visible - without layer violations), optimizing these >> >> objects for software makes sense. >> >> >> >> In addition, since either may be included (which >> >> includes the possibility of including both), it is the >> >> case already that we would then need to decide which is >> >> to go first - assuming we wanted to do this (which we >> >> do not). >> >> >> >> -- >> >> Eric >> >> >> >> -----Original Message----- >> >> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >> >> Sent: Monday, March 28, 2011 8:11 AM >> >> To: Eric Gray; Rolf.Winter@neclab.eu >> >> Cc: mpls@ietf.org >> >> Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on= - >> >> demand-cv-03 >> >> Importance: High >> >> >> >> Hi Eric and Rolf, >> >> >> >> I'm sorry for interrupting. >> >> >> >> I agree with Rolf regarding the per-interface MIP discussion. >> >> We have to consider the HW implementation aspect, >> >> because trapping of an OAM packet is HW rule/functionality even in >> >> routers. >> >> >> >> If every OAM packet is trapped to CPU >> >> and the OAM packets which should NOT be processed in the Interface >> >> are returned to Data-plane, >> >> it is different forwarding path from user packets, >> >> which is NOT the Connectivity Verification of the user path. >> >> >> >> Therefore, we should take the HW aspect and flexibilty into account >> >> concurrently. >> >> If an address TLV MUST be the first in TLVs, >> >> it is enough to make HW implementation easy. >> >> >> >> BR, >> >> Hideki >> >> >> >> >> >> >> >> >Rolf, >> >> > >> >> > The words you propose are okay with me. >> >> > >> >> > I thought the MIP/interface and address location issues >> >> >were separate. >> >> > >> >> > I've personally had problems with protocol specifications >> >> >that require ordering of TLVs. In particular, this is not very >> >> >robust in terms of "future-proofing." What happens if new TLVs >> >> >are added later on; for instance, suppose at some point we have >> >> >multiple "address" TLVs? >> >> > >> >> > Also, the fact that implementations are allowed to attach >> >> >TLVs in any arbitrary order allows considerable flexibilty in >> >> >implementation. Messages can be built in arbitrarily many ways. >> >> >This too can be a future-proofing issue. >> >> > >> >> > I would prefer not to start down the road of requiring a >> >> >subset of TLVs to appear in a certain order, and saying we have >> >> >one TLV that needs to be first is doing just that. >> >> > >> >> >-- >> >> >Eric >> >> > >> >> >-----Original Message----- >> >> >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >> >> >Sent: Monday, March 28, 2011 6:19 AM >> >> >To: Eric Gray >> >> >Cc: mpls@ietf.org >> >> >Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >> >> demand-cv-03 >> >> >Importance: High >> >> > >> >> >Hi, >> >> > >> >> >I still think there is a logical error. Let me explain. In case ther= e >> >> is no IP you simply cannot use it. You say you could enable IP but th= en >> >> that is not a case where there is no IP. In order to be constructive >> >> here is a text change suggestion: >> >> > >> >> >"In certain MPLS-TP deployment scenarios IP addressing might not be >> >> available. In those cases On-demand CV and/or route tracing MUST be r= un >> >> without IP addressing, using the ACH channel type specified in Sectio= n >> >> 3. In other cases it might be available, however, it may be preferred >> >> to use some form of non-IP encapsulation. In those cases, the >> >> procedures as outlined in section 3 SHOULD also be used." >> >> > >> >> >Regarding the per-interface MIP discussion. The HW aspect also poppe= d >> >> up in the PWE3 session and I think this is an important consideration= , >> >> in particular for OAM. Even if we talk about TLVs, we could make it a >> >> MUST that an Address TLV is always the first one to appear. If you ca= n >> >> facilitate an easy implementation in hardware, I see no reason to >> >> deliberately not do it. >> >> > >> >> >Best, >> >> > >> >> >Rolf >> >> > >> >> > >> >> >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >> >> London W3 6BL | Registered in England 2832014 >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: Eric Gray [mailto:eric.gray@ericsson.com] >> >> >> Sent: Montag, 28. M=E4rz 2011 11:43 >> >> >> To: Rolf Winter >> >> >> Cc: loa@pi.nu; mpls@ietf.org >> >> >> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-o= n- >> >> >> demand-cv-03 >> >> >> >> >> >> Rolf, >> >> >> >> >> >> With regard to the use of SHOULD (verses MUST) - the intent >> >> >> (according to RFC 2119 - see the quote below) is consistent with >> >> >> this case. If - for some reason - one had a really good reason to >> >> >> use IP addressing in some specific case, one could take steps to >> >> >> make IP addressing available. >> >> >> >> >> >> This could be said to introduce a logical disconnect, but we >> >> >> are saved from going down that path by the fact that the statement >> >> >> also includes the case where (for some reason) there is a case in >> >> >> which some other addressing scheme might be preferred. In many of >> >> >> the cases where another addressing scheme may be preferred, it is >> >> >> still possible (in fact likely) that IP addressing is available. >> >> >> >> >> >> Otherwise, it would not have been necessary to distinguish >> >> >> this case from the one in which IP addressing is not available. >> >> >> >> >> >> For the case where IP addressing is not the preferred mode, >> >> >> we are recommending a mode in which it is not necessary. >> >> >> >> >> >> With regard to having addresses located in the same place, >> >> >> this protocol is meant for connectivity testing on an on-demand >> >> >> basis and is therefore not optimized for processing in hardware. >> >> >> >> >> >> Whether addresses or identifiers, if we are talking about >> >> >> TLV contents, there are issues with trying to guarantee location >> >> >> of specific content, because of the fact that the TLV in question >> >> >> will probably follow other TLVs - thus making locations difficult >> >> >> to predict in any case. >> >> >> >> >> >> With regard to needing more text on per-interface MIPs, do >> >> >> you have specific suggestions as to what text we might add? >> >> >> >> >> >> I understand (from discussion with WG chairs) that we are >> >> >> not allowed to explicitly address last call comments during the >> >> >> IETF meeting in Prague, because the last call is still ongoing >> >> >> at that time. >> >> >> >> >> >> -- >> >> >> Eric >> >> >> >> >> >> PS - >> >> >> From RFC 2119 - >> >> >> 'SHOULD This word, or the adjective "RECOMMENDED", mean that the= re >> >> >> may exist valid reasons in particular circumstances to >> >> >> ignore a particular item, but the full implications must >> >> >> be understood and carefully weighed before choosing a >> >> >> different course.' >> >> >> >> >> >> -----Original Message----- >> >> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf >> >> Of >> >> >> Rolf Winter >> >> >> Sent: Tuesday, March 22, 2011 4:57 AM >> >> >> To: loa@pi.nu; mpls@ietf.org >> >> >> Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-o= n- >> >> >> demand-cv-03 >> >> >> >> >> >> Hi, >> >> >> >> >> >> some comments below: >> >> >> >> >> >> Section 1.3 says: " In certain MPLS-TP deployment scenarios IP >> >> >> addressing might not be >> >> >> available or it may be preferred to use some form of non-IP >> >> >> encapsulation for On-demand CV, route tracing and BFD packets. >> >> In >> >> >> such scenarios, On-demand CV and/or route tracing SHOULD be run >> >> >> without IP addressing..." >> >> >> >> >> >> I am not sure the "SHOULD" is right here. If no IP addressing is >> >> >> available, this thing MUST be run without IP addressing, mustn't i= t? >> >> >> >> >> >> I think some additional text regarding per-interface MIP addressin= g >> >> >> would be nice. As far as I understand the document, all TLVs will = be >> >> >> inside the LSP ping packet (rather than as ACH TLVs). >> >> >> >> >> >> Some people had concerns earlier, that addressing information shou= ld >> >> be >> >> >> in a fixed location for easier processing. Is this the case here I >> >> >> wonder? >> >> >> >> >> >> It would be nice if you could address this in your presentation in >> >> >> Prague. >> >> >> >> >> >> Thanks, >> >> >> >> >> >> Rolf >> >> >> >> >> >> >> >> >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road= , >> >> >> London W3 6BL | Registered in England 2832014 >> >> >> >> >> >> >> >> >> > -----Original Message----- >> >> >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> >> Behalf >> >> >> Of >> >> >> > loa@pi.nu >> >> >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26 >> >> >> > To: mpls@ietf.org >> >> >> > Cc: MPLS-TP ad hoc team >> >> >> > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >> >> >> demand- >> >> >> > cv-03 >> >> >> > >> >> >> > Working Group, >> >> >> > >> >> >> > this is to start a 3 week working group last call on >> >> >> > >> >> >> > draft-ietf-mpls-tp-on-demand-cv-03 >> >> >> > >> >> >> > Please send comments to the working group mailing list >> >> >> > mpls@ietf.org >> >> >> > >> >> >> > The working group last call ends on April 8, 2011. >> >> >> > >> >> >> > /Loa >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > _______________________________________________ >> >> >> > mpls mailing list >> >> >> > mpls@ietf.org >> >> >> > https://www.ietf.org/mailman/listinfo/mpls >> >> >> _______________________________________________ >> >> >> mpls mailing list >> >> >> mpls@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/mpls >> >> >_______________________________________________ >> >> >mpls mailing list >> >> >mpls@ietf.org >> >> >https://www.ietf.org/mailman/listinfo/mpls >> >> > >> > >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --20cf30549f69872df8049f9221be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Sami,
    alternative to decrementing TTL for out-MIP approach, to use re= served Outgoing MIP Label (OML), presented in draft-farrel-mpls-tp-mip-mep-= map-03. Considering that few proposed MPLS-TP OAM mechanisms use ACH TLV He= ader per RFC 5586 OML might be the better solution to address out-MIP.

    Regards,
    Greg

    On Mon, Mar 28, 2011= at 1:33 PM, Sami Boutros <sboutros@cisco.com> wrote:
    At 06:43 AM 3/28/2011, hideki.endo.es@hitachi.com wrote:
    Hi Eric,

    What I'd like to say was explaned by Rolf.
    My concern is whether the OAM packet is fate sharing with user packet or NO= T.
    If draft-on-demand-cv doesn't care anything for fate sharing
    in the case of per-interface MIP,
    the per-interface MIP can NOT be implemented by HW reasonably.

    Keep in mind that a node decrement TTL once, and this per-interface MIP see= ms to require a node to decrement twice..

    Thanks,

    Sami


    BR,
    Hideki

    >Eric,
    >
    >I generally agree but I think there is one case actually which needs a = closer look in this regard (which I hinted at earlier), which are the per-i= nterface MIPs. Your TTL expires (the actual addressing bit here), the ident= ifier tells you it is not intended for the ingress MIP, so it needs to be f= orwarded to the egress MIP through the forwarding engine. Now if you pull t= he packet out of the fast path and inject it back in, is the OAM packet sti= ll fate sharing? If you can do this in HW on the line card, then it will an= d it will just be forwarded as normal. I know this is a different draft, bu= t this will be in particular important for performance monitoring.
    >
    >Best,
    >
    >Rolf
    >
    >
    >
    >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lon= don W3 6BL | Registered in England 2832014
    >
    >
    >> -----Original Message-----
    >> From: Eric Gray [mailto:eric.gray@ericsson.com]
    >> Sent: Montag, 28. M=E4rz 2011 14:45
    >> To: hideki.end= o.es@hitachi.com; = Rolf Winter
    >> Cc: mpls@ietf.o= rg
    >> Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpl= s-tp-
    >> on-demand-cv-03
    >>
    >> Hideki,
    >>
    >> =A0 =A0 =A0What you're saying is true, but not relevant in thi= s
    >> case. =A0The "addresses" in this discussion are not used= to
    >> determine how to forward OAM packets. =A0They are used only
    >> by the recipient MIP/MEP to verify that the OAM packet was
    >> properly delivered.
    >>
    >> =A0 =A0 =A0By the way, this discussion is an indication of the
    >> confusing injected by calling these things addresses. =A0My
    >> mistake and I bring it up now to help to stem the tide of
    >> further comments resulting from that confusion.
    >>
    >> =A0 =A0 =A0In the version we post after last call is complete,
    >> we will be changing the source and destination "address"=
    >> TLVs to source and destination "identifier" TLVs.
    >>
    >> =A0 =A0 =A0We will also be correcting the reference to DSMAP,
    >> and DDMAP, address TLVs (which is incorrect, because the
    >> format for DSMAP/DDMAP doesn't include a "length" fi= eld).
    >>
    >> =A0 =A0 =A0The format of the Downstream Mapping (DSMAP) TLV is
    >> defined in RFC 4379, and we are not changing the format
    >> of that TLV.
    >>
    >> =A0 =A0 =A0These changes are driven by last call comments we
    >> have already received (see Joel Halpern's comments on the
    >> mailing list) and are - in part - to correct accidental
    >> use of the word "address" for source and destination
    >> identifier TLVs (which is what we had discussed before
    >> I generated the -03 version among the authors of several
    >> of the current set of MPLS-TP drafts).
    >>
    >> =A0 =A0 =A0In the case of source and destination identifiers,
    >> these will be used exclusively to verify that an OAM PDU
    >> has been correctly received by its intended recipient.
    >> Because this is an on-demand connectivity verification
    >> protocol, that is expected to be used only on those
    >> occasions when there is a network problem that needs to
    >> be diagnosed, and the information is not seen (and not
    >> visible - without layer violations), optimizing these
    >> objects for software makes sense.
    >>
    >> =A0 =A0 =A0In addition, since either may be included (which
    >> includes the possibility of including both), it is the
    >> case already that we would then need to decide which is
    >> to go first - assuming we wanted to do this (which we
    >> do not).
    >>
    >> --
    >> Eric
    >>
    >> -----Original Message-----
    >> From: hideki.e= ndo.es@hitachi.com= [mailto:hi= deki.endo.es@hitachi.com]
    >> Sent: Monday, March 28, 2011 8:11 AM
    >> To: Eric Gray; Rolf.Winter@neclab.eu
    >> Cc: mpls@ietf.o= rg
    >> Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp= -on-
    >> demand-cv-03
    >> Importance: High
    >>
    >> Hi Eric and Rolf,
    >>
    >> I'm sorry for interrupting.
    >>
    >> I agree with Rolf regarding the per-interface MIP discussion.
    >> We have to consider the HW implementation aspect,
    >> because trapping of an OAM packet is HW rule/functionality even in=
    >> routers.
    >>
    >> If every OAM packet is trapped to CPU
    >> and the OAM packets which should NOT be processed in the Interface=
    >> are returned to Data-plane,
    >> it is different forwarding path from user packets,
    >> which is NOT the Connectivity Verification of the user path.
    >>
    >> Therefore, we should take the HW aspect and flexibilty into accoun= t
    >> concurrently.
    >> If an address TLV MUST be the first in TLVs,
    >> it is enough to make HW implementation easy.
    >>
    >> BR,
    >> Hideki
    >>
    >>
    >>
    >> >Rolf,
    >> >
    >> > =A0 =A0The words you propose are okay with me.
    >> >
    >> > =A0 =A0I thought the MIP/interface and address location issue= s
    >> >were separate.
    >> >
    >> > =A0 =A0I've personally had problems with protocol specifi= cations
    >> >that require ordering of TLVs. =A0In particular, this is not v= ery
    >> >robust in terms of "future-proofing." =A0What happen= s if new TLVs
    >> >are added later on; for instance, suppose at some point we hav= e
    >> >multiple "address" TLVs?
    >> >
    >> > =A0 =A0Also, the fact that implementations are allowed to att= ach
    >> >TLVs in any arbitrary order allows considerable flexibilty in<= br> >> >implementation. =A0Messages can be built in arbitrarily many w= ays.
    >> >This too can be a future-proofing issue.
    >> >
    >> > =A0 =A0I would prefer not to start down the road of requiring= a
    >> >subset of TLVs to appear in a certain order, and saying we hav= e
    >> >one TLV that needs to be first is doing just that.
    >> >
    >> >--
    >> >Eric
    >> >
    >> >-----Original Message-----
    >> >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]
    >> >Sent: Monday, March 28, 2011 6:19 AM
    >> >To: Eric Gray
    >> >Cc: mpls@ie= tf.org
    >> >Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-= tp-on-
    >> demand-cv-03
    >> >Importance: High
    >> >
    >> >Hi,
    >> >
    >> >I still think there is a logical error. Let me explain. In cas= e there
    >> is no IP you simply cannot use it. You say you could enable IP but= then
    >> that is not a case where there is no IP. In order to be constructi= ve
    >> here is a text change suggestion:
    >> >
    >> >"In certain MPLS-TP deployment scenarios IP addressing mi= ght not be
    >> available. In those cases On-demand CV and/or route tracing MUST b= e run
    >> without IP addressing, using the ACH channel type specified in Sec= tion
    >> 3. In other cases it might be available, however, it may be prefer= red
    >> to use some form of non-IP encapsulation. In those cases, the
    >> procedures as outlined in section 3 SHOULD also be used."
    >> >
    >> >Regarding the per-interface MIP discussion. The HW aspect also= popped
    >> up in the PWE3 session and I think this is an important considerat= ion,
    >> in particular for OAM. Even if we talk about TLVs, we could make i= t a
    >> MUST that an Address TLV is always the first one to appear. If you= can
    >> facilitate an easy implementation in hardware, I see no reason to<= br> >> deliberately not do it.
    >> >
    >> >Best,
    >> >
    >> >Rolf
    >> >
    >> >
    >> >NEC Europe Limited | Registered Office: NEC House, 1 Victoria = Road,
    >> London W3 6BL | Registered in England 2832014
    >> >
    >> >
    >> >> -----Original Message-----
    >> >> From: Eric Gray [mailto:eric.gray@ericsson.com]
    >> >> Sent: Montag, 28. M=E4rz 2011 11:43
    >> >> To: Rolf Winter
    >> >> Cc: loa@pi= .nu; mpls@ietf.org
    >> >> Subject: RE: [mpls] Working Group Las Call on draft-ietf-= mpls-tp-on-
    >> >> demand-cv-03
    >> >>
    >> >> Rolf,
    >> >>
    >> >> =A0 With regard to the use of SHOULD (verses MUST) - the = intent
    >> >> (according to RFC 2119 - see the quote below) is consiste= nt with
    >> >> this case. =A0If - for some reason - one had a really goo= d reason to
    >> >> use IP addressing in some specific case, one could take s= teps to
    >> >> make IP addressing available.
    >> >>
    >> >> =A0 This could be said to introduce a logical disconnect,= but we
    >> >> are saved from going down that path by the fact that the = statement
    >> >> also includes the case where (for some reason) there is a= case in
    >> >> which some other addressing scheme might be preferred. = =A0In many of
    >> >> the cases where another addressing scheme may be preferre= d, it is
    >> >> still possible (in fact likely) that IP addressing is ava= ilable.
    >> >>
    >> >> =A0 Otherwise, it would not have been necessary to distin= guish
    >> >> this case from the one in which IP addressing is not avai= lable.
    >> >>
    >> >> =A0 For the case where IP addressing is not the preferred= mode,
    >> >> we are recommending a mode in which it is not necessary.<= br> >> >>
    >> >> =A0 With regard to having addresses located in the same p= lace,
    >> >> this protocol is meant for connectivity testing on an on-= demand
    >> >> basis and is therefore not optimized for processing in ha= rdware.
    >> >>
    >> >> =A0 Whether addresses or identifiers, if we are talking a= bout
    >> >> TLV contents, there are issues with trying to guarantee l= ocation
    >> >> of specific content, because of the fact that the TLV in = question
    >> >> will probably follow other TLVs - thus making locations d= ifficult
    >> >> to predict in any case.
    >> >>
    >> >> =A0 With regard to needing more text on per-interface MIP= s, do
    >> >> you have specific suggestions as to what text we might ad= d?
    >> >>
    >> >> =A0 I understand (from discussion with WG chairs) that we= are
    >> >> not allowed to explicitly address last call comments duri= ng the
    >> >> IETF meeting in Prague, because the last call is still on= going
    >> >> at that time.
    >> >>
    >> >> --
    >> >> Eric
    >> >>
    >> >> PS -
    >> >> From RFC 2119 -
    >> >> 'SHOULD =A0 This word, or the adjective "RECOMME= NDED", mean that there
    >> >> =A0 =A0 =A0 =A0 =A0 may exist valid reasons in particular= circumstances to
    >> >> =A0 =A0 =A0 =A0 =A0 ignore a particular item, but the ful= l implications must
    >> >> =A0 =A0 =A0 =A0 =A0 be understood and carefully weighed b= efore choosing a
    >> >> =A0 =A0 =A0 =A0 =A0 different course.'
    >> >>
    >> >> -----Original Message-----
    >> >> From:     mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf
    >> Of
    >> >> Rolf Winter
    >> >> Sent: Tuesday, March 22, 2011 4:57 AM
    >> >> To: loa@pi= .nu; mpls@ietf.org
    >> >> Subject: Re: [mpls] Working Group Las Call on draft-ietf-= mpls-tp-on-
    >> >> demand-cv-03
    >> >>
    >> >> Hi,
    >> >>
    >> >> some comments below:
    >> >>
    >> >> Section 1.3 says: " In certain MPLS-TP deployment sc= enarios IP
    >> >> addressing might not be
    >> >> =A0 =A0available or it may be preferred to use some form = of non-IP
    >> >> =A0 =A0encapsulation for On-demand CV, route tracing and = BFD packets.
    >> In
    >> >> =A0 =A0such scenarios, On-demand CV and/or route tracing = SHOULD be run
    >> >> =A0 =A0without IP addressing..."
    >> >>
    >> >> I am not sure the "SHOULD" is right here. If no= IP addressing is
    >> >> available, this thing MUST be run without IP addressing, = mustn't it?
    >> >>
    >> >> I think some additional text regarding per-interface MIP = addressing
    >> >> would be nice. As far as I understand the document, all T= LVs will be
    >> >> inside the LSP ping packet (rather than as ACH TLVs).
    >> >>
    >> >> Some people had concerns earlier, that addressing informa= tion should
    >> be
    >> >> in a fixed location for easier processing. Is this the ca= se here I
    >> >> wonder?
    >> >>
    >> >> It would be nice if you could address this in your presen= tation in
    >> >> Prague.
    >> >>
    >> >> Thanks,
    >> >>
    >> >> Rolf
    >> >>
    >> >>
    >> >> NEC Europe Limited | Registered Office: NEC House, 1 Vict= oria Road,
    >> >> London W3 6BL | Registered in England 2832014
    >> >>
    >> >>
    >> >> > -----Original Message-----
    >> >> > From:     mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On
    >> Behalf
    >> >> Of
    >> >> > loa@p= i.nu
    >> >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26
    >> >> > To: mpls@ietf.org
    >> >> > Cc: MPLS-TP ad hoc team
    >> >> > Subject: [mpls] Working Group Las Call on draft-ietf= -mpls-tp-on-
    >> >> demand-
    >> >> > cv-03
    >> >> >
    >> >> > Working Group,
    >> >> >
    >> >> > this is to start a 3 week working group last call on=
    >> >> >
    >> >> > draft-ietf-mpls-tp-on-demand-cv-03
    >> >> >
    >> >> > Please send comments to the working group mailing li= st
    >> >> > m= pls@ietf.org
    >> >> >
    >> >> > The working group last call ends on April 8, 2011. >> >> >
    >> >> > /Loa
    >> >> >
    >> >> >
    >> >> >
    >> >> >
    >> >> > _______________________________________________
    >> >> > mpls mailing list
    >> >> > m= pls@ietf.org
    >> >> > https://www.ietf.org/mailman/listinfo/mpls
    >> >> _______________________________________________
    >> >> mpls mailing list
    >> >> mpls@i= etf.org
    >> >> https://www.ietf.org/mailman/listinfo/mpls
    >> >_______________________________________________
    >> >mpls mailing list
    >> >mpls@ietf.o= rg
    >> >https://www.ietf.org/mailman/listinfo/mpls
    >> >
    >
    _______________________________________________
    mpls mailing list
    mpls@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/mpls


    _______________________________________________
    mpls mailing list
    mpls@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/mpls

    --20cf30549f69872df8049f9221be-- From huaimo.chen@huawei.com Mon Mar 28 15:07:38 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357773A6A7D for ; Mon, 28 Mar 2011 15:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xNwNPyVGsKP9 for ; Mon, 28 Mar 2011 15:07:31 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 53E083A6A6B for ; Mon, 28 Mar 2011 15:07:31 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIS001HUG78X9@usaga02-in.huawei.com> for mpls@ietf.org; Mon, 28 Mar 2011 15:09:08 -0700 (PDT) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LIS00NCLG771W@usaga02-in.huawei.com> for mpls@ietf.org; Mon, 28 Mar 2011 15:09:08 -0700 (PDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 28 Mar 2011 15:09:05 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.54]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Mon, 28 Mar 2011 15:09:07 -0700 Date: Mon, 28 Mar 2011 22:09:07 +0000 From: Huaimo Chen In-reply-to: X-Originating-IP: [10.212.244.152] To: Greg Mirsky , "So, Ning" , "mpls@ietf.org" Message-id: <5316A0AB3C851246A7CA5758973207D40493D490@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_AmCgyljZaunaInjR/qDGQw)" Content-language: en-US Accept-Language: en-US Thread-topic: Comment on draft-chen-mpls-p2mp-egress-protection-02 Thread-index: AQHL6CMP8XjHBllih064b0TuY3q7/JRCt5iw X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: Re: [mpls] Comment on draft-chen-mpls-p2mp-egress-protection-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:07:38 -0000 --Boundary_(ID_AmCgyljZaunaInjR/qDGQw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thanks for your comments! See my answer inline, Best Regards, Huaimo ________________________________ From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Monday, March 21, 2011 6:52 PM To: Huaimo Chen; So, Ning; mpls@ietf.org Subject: Comment on draft-chen-mpls-p2mp-egress-protection-02 Dear Authors, please kindly consider my comments and questions to the document before upcoming IETF meeting: * I believe that referring to the presented use case as LSP egress protection is not entirely accurate. The case on the Figure 1 presents service protection case as it provides protection from CE perspective, not from perspective of LSP itself as new egress nodes/PEs being created as result of proposed solution Huaimo: Can you give more details regarding to what you mentioned "LSP egress protection is not entirely accurate"? The egress protection that is described in the draft is to protect the failure of an egress node mainly. * Much of proposed solution is based on assumption that "previous-hop node" is able to set up a path to a backup egress node for the given egress on p2mp LSP. How the mechanics of the proposed solution changes if the immediate upstream node can not set path to backup/redundant egress? Is it only the previous-hop node can set up redundant egress or any upstream node given that there's OAM session between it and egress node being protected? Huaimo: In the case of that the immediate upstream node of an egress node can not set up a protecting LSP to backup/redundant egress, the protection to the egress node can not be provided or may be transferred to the previous (previous) hop node (we considered this). To allow any previous hop of an egress node to provide protection to the egress node may be complicated. * Would proposed solution of creating redundant egress nodes be equally applicable to cases when protected egress node is a bud node? Huaimo: Why not? * I believe that section 4.3 describes proprietary implementation Huaimo: This is just for information. * Section 4.4 discusses OAM sessions between "previous-hop node" and protected edge node as well as "previous-hop node" and a CE. I assume that the edge node is a downstream node relative to the "previous-hop node" for the given p2mp LSP. If that is the case, then I'd encourage Authors to expand on OAM part to demonstrate what mechanisms, existing or required development, can be used to detect first types of failures mentioned in the document. Huaimo: We may consider this. * The second class of failures described in the Section 4.4 requires, in my view, interworking between service OAM and MPLS LSP OAM. I'd encourage Authors to expand on OAM interworking subject if the proposed solution is intended to address such type of failures as well Huaimo: We may consider this. * Section 4.4 mentions that the "previous-hop node" switches LSP traffic towards redundant egress nodes onto the protecting LSP after it detects or receives signal that the protected egress node have failed. I believe that it is important to address notification toward the CE otherwise switching to a redundant egress node would not restore the service. Huaimo: Regarding to the service on the backup egress node, we have had some discussions and considerations. We may write more details in the draft. The backup egress node should have the information about the service on the egress node. It should forward the traffic coming from the protecting LSP in a way which is the same as or similar to the way that the egress does. I hope Authors will find it possible to address my notes before or at the meeting itself. Regards, Greg --Boundary_(ID_AmCgyljZaunaInjR/qDGQw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

    Thanks for your comments!

     

    See my answer inline,

     

    Best= Regards,

    Huai= mo

     

    From: Greg Mirsky [mailto:gregimirsky@gmail.com]
    Sent: Monday, March 21, 2011= 6:52 PM
    To: Huaimo Chen; So, Ning; m= pls@ietf.org
    Subject: Comment on draft-ch= en-mpls-p2mp-egress-protection-02

     

    Dear Authors,
    please kindly consider my comments and questions to the document before upc= oming IETF meeting:

    • I believe that referring to the presented use case as LSP eg= ress protection is not entirely accurate. The case on the Figure 1 presents= service  protect= ion case as it provides protection from CE perspective, not from perspectiv= e of LSP itself as new egress nodes/PEs being created as result of proposed= solution

    Huaimo: Can you give more details regarding t= o what you mentioned “LSP egress protection is not ent= irely accurate”? The egress protection that is described in the draft= is to protect the failure of an egress node mainly.

    • Much of proposed solution is based on assumption that "= previous-hop node" is able to set up a path to a backup egress node fo= r the given egress on p2mp LSP. How the mechanics of the proposed solution changes if the immediate upstream node can not se= t path to backup/redundant egress? Is it only the previous-hop node can set= up redundant egress or any upstream node given that there's OAM session be= tween it and egress node being protected?

    Huaimo: In the case of that the immediate upstream node of an egress= node can not set up a protecting LSP to backup/redundant egress, the prote= ction to the egress node can not be provided or may be transferred to the p= revious (previous) hop node (we considered this). To allow any previous hop of an egress node to provide protection t= o the egress node may be complicated.

    • Would proposed solution of creating redundant egress nodes b= e equally applicable to cases when protected egress node is a bud node?

    Huaimo: Why not?

    • I believe that section 4.3 describes proprietary implementat= ion

    Huaimo: This is just for information.

    • Section 4.4 discusses OAM sessions between "previous-ho= p node" and protected edge node as well as "previous-hop node&quo= t; and a CE. I assume that the edge node is a downstream node relative to the "previous-hop node" for the given p2mp LSP. If t= hat is the case, then I'd encourage Authors to expand on OAM part to demons= trate what mechanisms, existing or required development, can be used to det= ect first types of failures mentioned in the document.

    Huaimo: We may consider this.

    • The second class of failures described in the Section 4.4 re= quires, in my view, interworking between service OAM and MPLS LSP OAM. I'd = encourage Authors to expand on OAM interworking subject if the proposed solution is intended to address such type of failu= res as well

    Huaimo: We may consider this.

    • Section 4.4 mentions that the "previous-hop node" = switches LSP traffic towards redundant egress nodes onto the protecting LSP= after it detects or receives signal that the protected egress node have failed. I believe that it is important to address notific= ation toward the CE otherwise switching to a redundant egress node would no= t restore the service.

    Huaimo: Regarding to the service on the backu= p egress node, we have had some discussions and considerations. We may write more details in= the draft. The backup egress node should have the information about the se= rvice on the egress node. It should forward the traffic coming from the pro= tecting LSP in a way which is the same as or similar to the way that the egress does.


    I hope Authors will find it possible to address my notes before or at the m= eeting itself.


    Regards,
    Greg

    --Boundary_(ID_AmCgyljZaunaInjR/qDGQw)-- From gregimirsky@gmail.com Mon Mar 28 23:12:24 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8EB13A6AB6 for ; Mon, 28 Mar 2011 23:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.254 X-Spam-Level: X-Spam-Status: No, score=-3.254 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 IDwBhfgSVCHa for ; Mon, 28 Mar 2011 23:12:21 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id E80423A6A8A for ; Mon, 28 Mar 2011 23:12:20 -0700 (PDT) Received: by vws12 with SMTP id 12so3368137vws.31 for ; Mon, 28 Mar 2011 23:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=+qGS+zVwjBi4kFfWflvw1pc3kg+ZLzHHBlqbxXfQm7U=; b=iWvRGeYDalWx5HifwPZsDvc6Skj1Y2bDCxjyTT+oWFcpTg9VBdw/Bzw4PMx/VThNlv HTTCh9auLk7z2olENIve0Zmrt2Frgpk199t5Esir78NnLW3eo02S8ij9l2BCxZSPd+bO wco37Iu7TfmiZxZdyVW5/F2/Jj6Fw184V/6XE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=O+TEWk83R1WKXDo8K65ZPcZkDEdJ6fKPbs+In5eR+cyOcRkm6ELnVJIt+7BZRahSuD aiBdKNgMvSNj6WJq2IrhhF7PBY7FIXxTAlcihDY4/8F48mB7x78iLM4tQmdxiBhUMGU2 NodsRgmcRWg1aS9So7nBC1LCk0ZqlGjpwhG5c= MIME-Version: 1.0 Received: by 10.52.65.195 with SMTP id z3mr6560706vds.175.1301379238645; Mon, 28 Mar 2011 23:13:58 -0700 (PDT) Received: by 10.52.161.198 with HTTP; Mon, 28 Mar 2011 23:13:58 -0700 (PDT) Date: Mon, 28 Mar 2011 23:13:58 -0700 Message-ID: From: Greg Mirsky To: ppan@infinera.com, ssingamsetty@infinera.com, rrao@infinera.com, blu@infinera.com, sam.aldrin@huawei.com, mpls@ietf.org Content-Type: multipart/alternative; boundary=20cf307abd5f3cce73049f98f77f Subject: [mpls] Comments on draft-pan-shared-mesh-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 06:12:25 -0000 --20cf307abd5f3cce73049f98f77f Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, please kindly consider my comments to your proposal. - Section 2. I think that "make-before-break" is more often used in reference to tunnel recovery, re-routing rather than protection since MBB takes advantage of available resources already used by a tunnel. In protection diversity of working and protecting paths usually required. - Section 3. the path in the example assumed to be bi-directional. I think that it is important that they been assumed to be co-routed as well. If authors believe that protocol works equally for co-routed as well as associated bi-directional MPLS-TP connections, please clarify. - I'd suggest to enumerate figures in the text. Will make referencing them much easier. - Section 6.2 It appears that proposed solution doesn't use ACH TLVs. If that is the case, then there's no need to reserve ACH TLV Header - Presented formats of STATUS and NOTIFY messages use "Exp" instead of "TC" in presenting SLE format - Section 7. That is probably my biggest issue with the proposal. Effectively, the mechanism is based on MIP generating an OAM message. But according to draft-ietf-mpls-tp-oam-framework-11 Section 3.4 generated by MIP OAM packet must be sent to the MEP that originated OAM request. In proposed mechanism MIP generates OAM packet but it's sent in opposite direction. If I may, I'd consider using Section OAM with GAL as only label and the context provided by MPLS-TP ID, i.e.MPLS-TP LSP ID as in draft-ietf-mpls-tp-identifiers-02. Then Activation message format will require ACH TLV Header as in document's Section 6.2. Regards, Greg --20cf307abd5f3cce73049f98f77f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors,
    please kindly consider my comments to your proposal.
  3. Section 2. I think that "make-before-break" is more often u= sed in reference to tunnel recovery, re-routing rather than protection sinc= e MBB takes advantage of available resources already used by a tunnel. In p= rotection diversity of working and protecting paths usually required.
  4. Section 3. the path in the example assumed to be bi-directional. I thin= k that it is important that they been assumed to be co-routed as well. If a= uthors believe that protocol works equally for co-routed as well as associa= ted bi-directional MPLS-TP connections, please clarify.
  5. I'd suggest to enumerate figures in the text. Will make referencing= them much easier.
  6. Section 6.2 It appears that proposed solution do= esn't use ACH TLVs. If that is the case, then there's no need to re= serve ACH TLV Header
  7. Presented formats of STATUS and NOTIFY messages use "Exp" ins= tead of "TC" in presenting SLE format
  8. Section 7. That is = probably my biggest issue with the proposal. Effectively, the mechanism is = based on MIP generating an OAM message. But according to draft-ietf-mpls-tp= -oam-framework-11 Section 3.4 generated by MIP OAM packet must be sent to t= he MEP that originated OAM request. In proposed mechanism MIP generates OAM= packet but it's sent in opposite direction.
    9. If I may, I'd consider using Sec= tion OAM with GAL as only label and the context provided by MPLS-TP ID, i.e= .MPLS-TP LSP ID as in draft-ietf-mpls-tp-identifiers-02. Then Activation me= ssage format will require ACH TLV Header as in document's Section 6.2.<= br>
    Regards,
    Greg
    --20cf307abd5f3cce73049f98f77f-- From rcallon@juniper.net Tue Mar 29 00:19:55 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E786F3A6855 for ; Tue, 29 Mar 2011 00:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 b8i1cVBqvIOq for ; Tue, 29 Mar 2011 00:19:48 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id C85C13A67FC for ; Tue, 29 Mar 2011 00:19:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTZGIckdhQONxH0JRg5LUVAxvv2RPnx3S@postini.com; Tue, 29 Mar 2011 00:21:24 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 29 Mar 2011 00:15:57 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 29 Mar 2011 03:17:25 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Tue, 29 Mar 2011 03:17:24 -0400 Thread-Topic: mpls wg last call on draft-ietf-mpls-ldp-p2mp Thread-Index: AcvDrJhCOwxbl7gbTh6wLaZt8CCDPAUkW1CwAAAOGjABmRK/gAPPrDog Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] mpls wg last call on draft-ietf-mpls-ldp-p2mp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:19:56 -0000 The WG last call on draft-ietf-mpls-ldp-p2mp has been completed.=20 Thanks, Ross -----Original Message----- From: Ross Callon=20 Sent: Wednesday, March 09, 2011 4:43 PM To: mpls@ietf.org Subject: RE: mpls wg last call on draft-ietf-mpls-ldp-p2mp OOps. The most recent version is -12. Thus the last call is on: "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths" (draft-ietf-mpls-ldp-p2mp-12). Just in case anyone was confused by this error, we will extend the last cal= l to March 23, 2011.=20 Thanks, Ross -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Tuesday, March 01, 2011 9:27 PM To: mpls@ietf.org Subject: [mpls] mpls wg last call on draft-ietf-mpls-ldp-p2mp-11 Working Group, This is to start a two week working group last call on "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths" (draft-ietf-mpls-ldp-p2mp-11). Please send comments to the mpls@ietf.org mailing list. This working group last call ends on March 16, 2011.=20 Ross, George, and Loa MPLS WG co-chairs _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Rolf.Winter@neclab.eu Tue Mar 29 00:24:12 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4080E3A67AC for ; Tue, 29 Mar 2011 00:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, 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 CyPij6GOuw6Z for ; Tue, 29 Mar 2011 00:24:11 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 069EE3A676A for ; Tue, 29 Mar 2011 00:24:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id AB0B82C0002E7; Tue, 29 Mar 2011 09:28:26 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pk05IC2twG9u; Tue, 29 Mar 2011 09:28:26 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 8E18E2C000202; Tue, 29 Mar 2011 09:28:06 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.246]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Tue, 29 Mar 2011 09:25:28 +0200 From: Rolf Winter To: Sami Boutros , "hideki.endo.es@hitachi.com" , "eric.gray@ericsson.com" Thread-Topic: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-demand-cv-03 Thread-Index: AQHL7YdjG4j++77GG0yKCjb8Qx0mppRD6CgQ Date: Tue, 29 Mar 2011 07:25:27 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05E177AF@Polydeuces.office.hd> References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:24:12 -0000 Hi Sami, see inline. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 >=20 > Keep in mind that a node decrement TTL once, and > this per-interface MIP seems to require a node to decrement twice.. >=20 > Thanks, >=20 I don't think this is a good idea. This is not how the TTL works today. I t= hink this is very unwise and touching a pretty fundamental principle here. = FWIW, we have proposed an alternative and presented it the last IETF. Unfor= tunately, we have received little feedback on it. But I think the discussio= n we have right now is good and not too late. The OAM framework document in= cludes per-interface MIPs and I think the group needs to start thinking har= d now to make sure this is thought about before we finish off all these OAM= tools. This way we do not need to come back later and change things. I don= 't think it will be overly hard, we just need to agree on something. Best, Rolf From hideki.endo.es@hitachi.com Tue Mar 29 00:32:05 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E35AC3A6A8B for ; Tue, 29 Mar 2011 00:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.762 X-Spam-Level: **** X-Spam-Status: No, score=4.762 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_31=0.6, MIME_BASE64_TEXT=1.753, SUBJ_RE_NUM=2.799] 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 CM6LtXDfuWyy for ; Tue, 29 Mar 2011 00:32:04 -0700 (PDT) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by core3.amsl.com (Postfix) with ESMTP id 1FE113A6A73 for ; Tue, 29 Mar 2011 00:32:03 -0700 (PDT) Received: from mlsv5.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 326AF37ACD; Tue, 29 Mar 2011 16:33:40 +0900 (JST) Received: from mfilter2.hitachi.co.jp by mlsv5.hitachi.co.jp (8.13.1/8.13.1) id p2T7XeBK001548; Tue, 29 Mar 2011 16:33:40 +0900 Received: from hitachi.com (localhost.localdomain [127.0.0.1]) by mfilter2.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id p2T7WasS011794; Tue, 29 Mar 2011 16:33:40 +0900 Received: from vshuts2.hitachi.co.jp ([vshuts2.hitachi.co.jp [10.201.6.71]]) by mfilter2.hitachi.co.jp with RELAY id p2T7Xcvk012601 ; Tue, 29 Mar 2011 16:33:40 +0900 X-AuditID: b753bd60-a274aba0000001d0-8c-4d918b528235 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id B225B8B02B6; Tue, 29 Mar 2011 16:33:38 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p2T7XcI12763282; Tue, 29 Mar 2011 16:33:38 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: multipart/mixed; boundary="GMAILSMTPBOUND01110329163334" To: , From: Date: Tue, 29 Mar 2011 16:33:22 +0900 References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> Priority: normal Importance: normal X400-Content-Identifier: X4D918B1100000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28110329163233PX7] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mpls@ietf.org, Rolf.Winter@neclab.eu Subject: Re: [mpls] =?iso-8859-1?q?Working_Group_Las_Callondraft-ietf-mpls-tp-?= =?iso-8859-1?q?_on-demand-cv-03?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:32:06 -0000 --GMAILSMTPBOUND01110329163334 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SGkgU2FtaSwNCg0KSSBkb24ndCB0aGluayB0aGF0IHRoZSBwZXItaW50ZXJmYWNlIE1JUCBy ZXF1aXJlcyBhIG5vZGUgdG8gZGVjcmVtZW50IFRUTCB0d2ljZS4NCkkgaGF2ZSBwcm9wb3Nl ZCBkcmFmdC1taXAtbWVwLW1hcCB0byBhdm9pZCB0d2ljZSBkZWNyZW1lbnQgb2YgVFRMLg0K SG93ZXZlciwgd2UsIGF1dGhlcnMsIGRvbid0IHB1c2ggc3BlY2lmaWMgc29sdXRpb24gZm9y IHBlci1pbnRlcmZhY2UgTUlQIGF0IHRoaXMgcG9pbnQsDQp3aGljaCBwcmVzZW50ZWQgYnkg Um9sZiBhdCBwcmV2aW91cyBtZWV0aW5nIGF0IEJlaWppbmcuDQoNCldlIGhhdmUgc2V2ZXJh bCBvcHRpb25zIHRvIGlkZW50aWZ5IHBlci1pbnRlcmZhY2UgTUlQIHdpdGhvdXQgdHdpY2Ug ZGVjcmVtZW50IG9mIFRUTDsNCigxKU1JUCBJRCBpbiBBQ0gtVExWDQooMilNSVAgSUQgaW4g UGluZyBhZGRyZXNzIFRMVg0KKDMpT01MDQooNClHQUwgVFRMKEkgcHJvcG9zZWQgYmVmb3Jl LCBidXQgbm93IHJlbW92ZWQgZnJvbSBvdXIgZHJhZnQpDQoNCldlIGNhbiBkaXNjdXNzIHRo ZSBiZXN0IHNvbHV0aW9uIGluIHRoaXMgbWVldGluZy4NCg0KQlIsDQpIaWRla2kNCg0KDQo+ SGkgU2FtaSwNCj5hbHRlcm5hdGl2ZSB0byBkZWNyZW1lbnRpbmcgVFRMIGZvciBvdXQtTUlQ IGFwcHJvYWNoLCB0byB1c2UgcmVzZXJ2ZWQNCj5PdXRnb2luZyBNSVAgTGFiZWwgKE9NTCks IHByZXNlbnRlZCBpbiBkcmFmdC1mYXJyZWwtbXBscy10cC1taXAtbWVwLW1hcC0wMy4NCj5D b25zaWRlcmluZyB0aGF0IGZldyBwcm9wb3NlZCBNUExTLVRQIE9BTSBtZWNoYW5pc21zIHVz ZSBBQ0ggVExWIEhlYWRlciBwZXINCj5SRkMgNTU4NiBPTUwgbWlnaHQgYmUgdGhlIGJldHRl ciBzb2x1dGlvbiB0byBhZGRyZXNzIG91dC1NSVAuDQo+DQo+UmVnYXJkcywNCj5HcmVnDQo+ DQo+T24gTW9uLCBNYXIgMjgsIDIwMTEgYXQgMTozMyBQTSwgU2FtaSBCb3V0cm9zIDxzYm91 dHJvc0BjaXNjby5jb20+IHdyb3RlOg0KPg0KPj4gQXQgMDY6NDMgQU0gMy8yOC8yMDExLCBo aWRla2kuZW5kby5lc0BoaXRhY2hpLmNvbSB3cm90ZToNCj4+DQo+Pj4gSGkgRXJpYywNCj4+ Pg0KPj4+IFdoYXQgSSdkIGxpa2UgdG8gc2F5IHdhcyBleHBsYW5lZCBieSBSb2xmLg0KPj4+ IE15IGNvbmNlcm4gaXMgd2hldGhlciB0aGUgT0FNIHBhY2tldCBpcyBmYXRlIHNoYXJpbmcg d2l0aCB1c2VyIHBhY2tldCBvcg0KPj4+IE5PVC4NCj4+PiBJZiBkcmFmdC1vbi1kZW1hbmQt Y3YgZG9lc24ndCBjYXJlIGFueXRoaW5nIGZvciBmYXRlIHNoYXJpbmcNCj4+PiBpbiB0aGUg Y2FzZSBvZiBwZXItaW50ZXJmYWNlIE1JUCwNCj4+PiB0aGUgcGVyLWludGVyZmFjZSBNSVAg Y2FuIE5PVCBiZSBpbXBsZW1lbnRlZCBieSBIVyByZWFzb25hYmx5Lg0KPj4+DQo+Pg0KPj4g S2VlcCBpbiBtaW5kIHRoYXQgYSBub2RlIGRlY3JlbWVudCBUVEwgb25jZSwgYW5kIHRoaXMg cGVyLWludGVyZmFjZSBNSVANCj4+IHNlZW1zIHRvIHJlcXVpcmUgYSBub2RlIHRvIGRlY3Jl bWVudCB0d2ljZS4uDQo+Pg0KPj4gVGhhbmtzLA0KPj4NCj4+IFNhbWkNCj4+DQo+Pg0KPj4g IEJSLA0KPj4+IEhpZGVraQ0KPj4+DQo+Pj4gPkVyaWMsDQo+Pj4gPg0KPj4+ID5JIGdlbmVy YWxseSBhZ3JlZSBidXQgSSB0aGluayB0aGVyZSBpcyBvbmUgY2FzZSBhY3R1YWxseSB3aGlj aCBuZWVkcyBhDQo+Pj4gY2xvc2VyIGxvb2sgaW4gdGhpcyByZWdhcmQgKHdoaWNoIEkgaGlu dGVkIGF0IGVhcmxpZXIpLCB3aGljaCBhcmUgdGhlDQo+Pj4gcGVyLWludGVyZmFjZSBNSVBz LiBZb3VyIFRUTCBleHBpcmVzICh0aGUgYWN0dWFsIGFkZHJlc3NpbmcgYml0IGhlcmUpLCB0 aGUNCj4+PiBpZGVudGlmaWVyIHRlbGxzIHlvdSBpdCBpcyBub3QgaW50ZW5kZWQgZm9yIHRo ZSBpbmdyZXNzIE1JUCwgc28gaXQgbmVlZHMgdG8NCj4+PiBiZSBmb3J3YXJkZWQgdG8gdGhl IGVncmVzcyBNSVAgdGhyb3VnaCB0aGUgZm9yd2FyZGluZyBlbmdpbmUuIE5vdyBpZiB5b3UN Cj4+PiBwdWxsIHRoZSBwYWNrZXQgb3V0IG9mIHRoZSBmYXN0IHBhdGggYW5kIGluamVjdCBp dCBiYWNrIGluLCBpcyB0aGUgT0FNDQo+Pj4gcGFja2V0IHN0aWxsIGZhdGUgc2hhcmluZz8g SWYgeW91IGNhbiBkbyB0aGlzIGluIEhXIG9uIHRoZSBsaW5lIGNhcmQsIHRoZW4NCj4+PiBp dCB3aWxsIGFuZCBpdCB3aWxsIGp1c3QgYmUgZm9yd2FyZGVkIGFzIG5vcm1hbC4gSSBrbm93 IHRoaXMgaXMgYSBkaWZmZXJlbnQNCj4+PiBkcmFmdCwgYnV0IHRoaXMgd2lsbCBiZSBpbiBw YXJ0aWN1bGFyIGltcG9ydGFudCBmb3IgcGVyZm9ybWFuY2UgbW9uaXRvcmluZy4NCj4+PiA+ DQo+Pj4gPkJlc3QsDQo+Pj4gPg0KPj4+ID5Sb2xmDQo+Pj4gPg0KPj4+ID4NCj4+PiA+DQo+ Pj4gPk5FQyBFdXJvcGUgTGltaXRlZCB8IFJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2Us IDEgVmljdG9yaWEgUm9hZCwNCj4+PiBMb25kb24gVzMgNkJMIHwgUmVnaXN0ZXJlZCBpbiBF bmdsYW5kIDI4MzIwMTQNCj4+PiA+DQo+Pj4gPg0KPj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4gPj4gRnJvbTogRXJpYyBHcmF5IFttYWlsdG86ZXJpYy5ncmF5QGVy aWNzc29uLmNvbV0NCj4+PiA+PiBTZW50OiBNb250YWcsIDI4LiBN5HJ6IDIwMTEgMTQ6NDUN Cj4+PiA+PiBUbzogaGlkZWtpLmVuZG8uZXNAaGl0YWNoaS5jb207IFJvbGYgV2ludGVyDQo+ Pj4gPj4gQ2M6IG1wbHNAaWV0Zi5vcmcNCj4+PiA+PiBTdWJqZWN0OiBSRTogUmVbMl06IFtt cGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9uZHJhZnQtaWV0Zi1tcGxzLXRwLQ0KPj4+ ID4+IG9uLWRlbWFuZC1jdi0wMw0KPj4+ID4+DQo+Pj4gPj4gSGlkZWtpLA0KPj4+ID4+DQo+ Pj4gPj4gICAgICBXaGF0IHlvdSdyZSBzYXlpbmcgaXMgdHJ1ZSwgYnV0IG5vdCByZWxldmFu dCBpbiB0aGlzDQo+Pj4gPj4gY2FzZS4gIFRoZSAiYWRkcmVzc2VzIiBpbiB0aGlzIGRpc2N1 c3Npb24gYXJlIG5vdCB1c2VkIHRvDQo+Pj4gPj4gZGV0ZXJtaW5lIGhvdyB0byBmb3J3YXJk IE9BTSBwYWNrZXRzLiAgVGhleSBhcmUgdXNlZCBvbmx5DQo+Pj4gPj4gYnkgdGhlIHJlY2lw aWVudCBNSVAvTUVQIHRvIHZlcmlmeSB0aGF0IHRoZSBPQU0gcGFja2V0IHdhcw0KPj4+ID4+ IHByb3Blcmx5IGRlbGl2ZXJlZC4NCj4+PiA+Pg0KPj4+ID4+ICAgICAgQnkgdGhlIHdheSwg dGhpcyBkaXNjdXNzaW9uIGlzIGFuIGluZGljYXRpb24gb2YgdGhlDQo+Pj4gPj4gY29uZnVz aW5nIGluamVjdGVkIGJ5IGNhbGxpbmcgdGhlc2UgdGhpbmdzIGFkZHJlc3Nlcy4gIE15DQo+ Pj4gPj4gbWlzdGFrZSBhbmQgSSBicmluZyBpdCB1cCBub3cgdG8gaGVscCB0byBzdGVtIHRo ZSB0aWRlIG9mDQo+Pj4gPj4gZnVydGhlciBjb21tZW50cyByZXN1bHRpbmcgZnJvbSB0aGF0 IGNvbmZ1c2lvbi4NCj4+PiA+Pg0KPj4+ID4+ICAgICAgSW4gdGhlIHZlcnNpb24gd2UgcG9z dCBhZnRlciBsYXN0IGNhbGwgaXMgY29tcGxldGUsDQo+Pj4gPj4gd2Ugd2lsbCBiZSBjaGFu Z2luZyB0aGUgc291cmNlIGFuZCBkZXN0aW5hdGlvbiAiYWRkcmVzcyINCj4+PiA+PiBUTFZz IHRvIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gImlkZW50aWZpZXIiIFRMVnMuDQo+Pj4gPj4N Cj4+PiA+PiAgICAgIFdlIHdpbGwgYWxzbyBiZSBjb3JyZWN0aW5nIHRoZSByZWZlcmVuY2Ug dG8gRFNNQVAsDQo+Pj4gPj4gYW5kIERETUFQLCBhZGRyZXNzIFRMVnMgKHdoaWNoIGlzIGlu Y29ycmVjdCwgYmVjYXVzZSB0aGUNCj4+PiA+PiBmb3JtYXQgZm9yIERTTUFQL0RETUFQIGRv ZXNuJ3QgaW5jbHVkZSBhICJsZW5ndGgiIGZpZWxkKS4NCj4+PiA+Pg0KPj4+ID4+ICAgICAg VGhlIGZvcm1hdCBvZiB0aGUgRG93bnN0cmVhbSBNYXBwaW5nIChEU01BUCkgVExWIGlzDQo+ Pj4gPj4gZGVmaW5lZCBpbiBSRkMgNDM3OSwgYW5kIHdlIGFyZSBub3QgY2hhbmdpbmcgdGhl IGZvcm1hdA0KPj4+ID4+IG9mIHRoYXQgVExWLg0KPj4+ID4+DQo+Pj4gPj4gICAgICBUaGVz ZSBjaGFuZ2VzIGFyZSBkcml2ZW4gYnkgbGFzdCBjYWxsIGNvbW1lbnRzIHdlDQo+Pj4gPj4g aGF2ZSBhbHJlYWR5IHJlY2VpdmVkIChzZWUgSm9lbCBIYWxwZXJuJ3MgY29tbWVudHMgb24g dGhlDQo+Pj4gPj4gbWFpbGluZyBsaXN0KSBhbmQgYXJlIC0gaW4gcGFydCAtIHRvIGNvcnJl Y3QgYWNjaWRlbnRhbA0KPj4+ID4+IHVzZSBvZiB0aGUgd29yZCAiYWRkcmVzcyIgZm9yIHNv dXJjZSBhbmQgZGVzdGluYXRpb24NCj4+PiA+PiBpZGVudGlmaWVyIFRMVnMgKHdoaWNoIGlz IHdoYXQgd2UgaGFkIGRpc2N1c3NlZCBiZWZvcmUNCj4+PiA+PiBJIGdlbmVyYXRlZCB0aGUg LTAzIHZlcnNpb24gYW1vbmcgdGhlIGF1dGhvcnMgb2Ygc2V2ZXJhbA0KPj4+ID4+IG9mIHRo ZSBjdXJyZW50IHNldCBvZiBNUExTLVRQIGRyYWZ0cykuDQo+Pj4gPj4NCj4+PiA+PiAgICAg IEluIHRoZSBjYXNlIG9mIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gaWRlbnRpZmllcnMsDQo+ Pj4gPj4gdGhlc2Ugd2lsbCBiZSB1c2VkIGV4Y2x1c2l2ZWx5IHRvIHZlcmlmeSB0aGF0IGFu IE9BTSBQRFUNCj4+PiA+PiBoYXMgYmVlbiBjb3JyZWN0bHkgcmVjZWl2ZWQgYnkgaXRzIGlu dGVuZGVkIHJlY2lwaWVudC4NCj4+PiA+PiBCZWNhdXNlIHRoaXMgaXMgYW4gb24tZGVtYW5k IGNvbm5lY3Rpdml0eSB2ZXJpZmljYXRpb24NCj4+PiA+PiBwcm90b2NvbCwgdGhhdCBpcyBl eHBlY3RlZCB0byBiZSB1c2VkIG9ubHkgb24gdGhvc2UNCj4+PiA+PiBvY2Nhc2lvbnMgd2hl biB0aGVyZSBpcyBhIG5ldHdvcmsgcHJvYmxlbSB0aGF0IG5lZWRzIHRvDQo+Pj4gPj4gYmUg ZGlhZ25vc2VkLCBhbmQgdGhlIGluZm9ybWF0aW9uIGlzIG5vdCBzZWVuIChhbmQgbm90DQo+ Pj4gPj4gdmlzaWJsZSAtIHdpdGhvdXQgbGF5ZXIgdmlvbGF0aW9ucyksIG9wdGltaXppbmcg dGhlc2UNCj4+PiA+PiBvYmplY3RzIGZvciBzb2Z0d2FyZSBtYWtlcyBzZW5zZS4NCj4+PiA+ Pg0KPj4+ID4+ICAgICAgSW4gYWRkaXRpb24sIHNpbmNlIGVpdGhlciBtYXkgYmUgaW5jbHVk ZWQgKHdoaWNoDQo+Pj4gPj4gaW5jbHVkZXMgdGhlIHBvc3NpYmlsaXR5IG9mIGluY2x1ZGlu ZyBib3RoKSwgaXQgaXMgdGhlDQo+Pj4gPj4gY2FzZSBhbHJlYWR5IHRoYXQgd2Ugd291bGQg dGhlbiBuZWVkIHRvIGRlY2lkZSB3aGljaCBpcw0KPj4+ID4+IHRvIGdvIGZpcnN0IC0gYXNz dW1pbmcgd2Ugd2FudGVkIHRvIGRvIHRoaXMgKHdoaWNoIHdlDQo+Pj4gPj4gZG8gbm90KS4N Cj4+PiA+Pg0KPj4+ID4+IC0tDQo+Pj4gPj4gRXJpYw0KPj4+ID4+DQo+Pj4gPj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiA+PiBGcm9tOiBoaWRla2kuZW5kby5lc0BoaXRh Y2hpLmNvbSBbbWFpbHRvOmhpZGVraS5lbmRvLmVzQGhpdGFjaGkuY29tXQ0KPj4+ID4+IFNl bnQ6IE1vbmRheSwgTWFyY2ggMjgsIDIwMTEgODoxMSBBTQ0KPj4+ID4+IFRvOiBFcmljIEdy YXk7IFJvbGYuV2ludGVyQG5lY2xhYi5ldQ0KPj4+ID4+IENjOiBtcGxzQGlldGYub3JnDQo+ Pj4gPj4gU3ViamVjdDogUmVbMl06IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9u ZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLQ0KPj4+ID4+IGRlbWFuZC1jdi0wMw0KPj4+ID4+IElt cG9ydGFuY2U6IEhpZ2gNCj4+PiA+Pg0KPj4+ID4+IEhpIEVyaWMgYW5kIFJvbGYsDQo+Pj4g Pj4NCj4+PiA+PiBJJ20gc29ycnkgZm9yIGludGVycnVwdGluZy4NCj4+PiA+Pg0KPj4+ID4+ IEkgYWdyZWUgd2l0aCBSb2xmIHJlZ2FyZGluZyB0aGUgcGVyLWludGVyZmFjZSBNSVAgZGlz Y3Vzc2lvbi4NCj4+PiA+PiBXZSBoYXZlIHRvIGNvbnNpZGVyIHRoZSBIVyBpbXBsZW1lbnRh dGlvbiBhc3BlY3QsDQo+Pj4gPj4gYmVjYXVzZSB0cmFwcGluZyBvZiBhbiBPQU0gcGFja2V0 IGlzIEhXIHJ1bGUvZnVuY3Rpb25hbGl0eSBldmVuIGluDQo+Pj4gPj4gcm91dGVycy4NCj4+ PiA+Pg0KPj4+ID4+IElmIGV2ZXJ5IE9BTSBwYWNrZXQgaXMgdHJhcHBlZCB0byBDUFUNCj4+ PiA+PiBhbmQgdGhlIE9BTSBwYWNrZXRzIHdoaWNoIHNob3VsZCBOT1QgYmUgcHJvY2Vzc2Vk IGluIHRoZSBJbnRlcmZhY2UNCj4+PiA+PiBhcmUgcmV0dXJuZWQgdG8gRGF0YS1wbGFuZSwN Cj4+PiA+PiBpdCBpcyBkaWZmZXJlbnQgZm9yd2FyZGluZyBwYXRoIGZyb20gdXNlciBwYWNr ZXRzLA0KPj4+ID4+IHdoaWNoIGlzIE5PVCB0aGUgQ29ubmVjdGl2aXR5IFZlcmlmaWNhdGlv biBvZiB0aGUgdXNlciBwYXRoLg0KPj4+ID4+DQo+Pj4gPj4gVGhlcmVmb3JlLCB3ZSBzaG91 bGQgdGFrZSB0aGUgSFcgYXNwZWN0IGFuZCBmbGV4aWJpbHR5IGludG8gYWNjb3VudA0KPj4+ ID4+IGNvbmN1cnJlbnRseS4NCj4+PiA+PiBJZiBhbiBhZGRyZXNzIFRMViBNVVNUIGJlIHRo ZSBmaXJzdCBpbiBUTFZzLA0KPj4+ID4+IGl0IGlzIGVub3VnaCB0byBtYWtlIEhXIGltcGxl bWVudGF0aW9uIGVhc3kuDQo+Pj4gPj4NCj4+PiA+PiBCUiwNCj4+PiA+PiBIaWRla2kNCj4+ PiA+Pg0KPj4+ID4+DQo+Pj4gPj4NCj4+PiA+PiA+Um9sZiwNCj4+PiA+PiA+DQo+Pj4gPj4g PiAgICBUaGUgd29yZHMgeW91IHByb3Bvc2UgYXJlIG9rYXkgd2l0aCBtZS4NCj4+PiA+PiA+ DQo+Pj4gPj4gPiAgICBJIHRob3VnaHQgdGhlIE1JUC9pbnRlcmZhY2UgYW5kIGFkZHJlc3Mg bG9jYXRpb24gaXNzdWVzDQo+Pj4gPj4gPndlcmUgc2VwYXJhdGUuDQo+Pj4gPj4gPg0KPj4+ ID4+ID4gICAgSSd2ZSBwZXJzb25hbGx5IGhhZCBwcm9ibGVtcyB3aXRoIHByb3RvY29sIHNw ZWNpZmljYXRpb25zDQo+Pj4gPj4gPnRoYXQgcmVxdWlyZSBvcmRlcmluZyBvZiBUTFZzLiAg SW4gcGFydGljdWxhciwgdGhpcyBpcyBub3QgdmVyeQ0KPj4+ID4+ID5yb2J1c3QgaW4gdGVy bXMgb2YgImZ1dHVyZS1wcm9vZmluZy4iICBXaGF0IGhhcHBlbnMgaWYgbmV3IFRMVnMNCj4+ PiA+PiA+YXJlIGFkZGVkIGxhdGVyIG9uOyBmb3IgaW5zdGFuY2UsIHN1cHBvc2UgYXQgc29t ZSBwb2ludCB3ZSBoYXZlDQo+Pj4gPj4gPm11bHRpcGxlICJhZGRyZXNzIiBUTFZzPw0KPj4+ ID4+ID4NCj4+PiA+PiA+ICAgIEFsc28sIHRoZSBmYWN0IHRoYXQgaW1wbGVtZW50YXRpb25z IGFyZSBhbGxvd2VkIHRvIGF0dGFjaA0KPj4+ID4+ID5UTFZzIGluIGFueSBhcmJpdHJhcnkg b3JkZXIgYWxsb3dzIGNvbnNpZGVyYWJsZSBmbGV4aWJpbHR5IGluDQo+Pj4gPj4gPmltcGxl bWVudGF0aW9uLiAgTWVzc2FnZXMgY2FuIGJlIGJ1aWx0IGluIGFyYml0cmFyaWx5IG1hbnkg d2F5cy4NCj4+PiA+PiA+VGhpcyB0b28gY2FuIGJlIGEgZnV0dXJlLXByb29maW5nIGlzc3Vl Lg0KPj4+ID4+ID4NCj4+PiA+PiA+ICAgIEkgd291bGQgcHJlZmVyIG5vdCB0byBzdGFydCBk b3duIHRoZSByb2FkIG9mIHJlcXVpcmluZyBhDQo+Pj4gPj4gPnN1YnNldCBvZiBUTFZzIHRv IGFwcGVhciBpbiBhIGNlcnRhaW4gb3JkZXIsIGFuZCBzYXlpbmcgd2UgaGF2ZQ0KPj4+ID4+ ID5vbmUgVExWIHRoYXQgbmVlZHMgdG8gYmUgZmlyc3QgaXMgZG9pbmcganVzdCB0aGF0Lg0K Pj4+ID4+ID4NCj4+PiA+PiA+LS0NCj4+PiA+PiA+RXJpYw0KPj4+ID4+ID4NCj4+PiA+PiA+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiA+PiA+RnJvbTogUm9sZiBXaW50ZXIg W21haWx0bzpSb2xmLldpbnRlckBuZWNsYWIuZXVdDQo+Pj4gPj4gPlNlbnQ6IE1vbmRheSwg TWFyY2ggMjgsIDIwMTEgNjoxOSBBTQ0KPj4+ID4+ID5UbzogRXJpYyBHcmF5DQo+Pj4gPj4g PkNjOiBtcGxzQGlldGYub3JnDQo+Pj4gPj4gPlN1YmplY3Q6IFJFOiBbbXBsc10gV29ya2lu ZyBHcm91cCBMYXMgQ2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtb24tDQo+Pj4gPj4gZGVt YW5kLWN2LTAzDQo+Pj4gPj4gPkltcG9ydGFuY2U6IEhpZ2gNCj4+PiA+PiA+DQo+Pj4gPj4g PkhpLA0KPj4+ID4+ID4NCj4+PiA+PiA+SSBzdGlsbCB0aGluayB0aGVyZSBpcyBhIGxvZ2lj YWwgZXJyb3IuIExldCBtZSBleHBsYWluLiBJbiBjYXNlIHRoZXJlDQo+Pj4gPj4gaXMgbm8g SVAgeW91IHNpbXBseSBjYW5ub3QgdXNlIGl0LiBZb3Ugc2F5IHlvdSBjb3VsZCBlbmFibGUg SVAgYnV0IHRoZW4NCj4+PiA+PiB0aGF0IGlzIG5vdCBhIGNhc2Ugd2hlcmUgdGhlcmUgaXMg bm8gSVAuIEluIG9yZGVyIHRvIGJlIGNvbnN0cnVjdGl2ZQ0KPj4+ID4+IGhlcmUgaXMgYSB0 ZXh0IGNoYW5nZSBzdWdnZXN0aW9uOg0KPj4+ID4+ID4NCj4+PiA+PiA+IkluIGNlcnRhaW4g TVBMUy1UUCBkZXBsb3ltZW50IHNjZW5hcmlvcyBJUCBhZGRyZXNzaW5nIG1pZ2h0IG5vdCBi ZQ0KPj4+ID4+IGF2YWlsYWJsZS4gSW4gdGhvc2UgY2FzZXMgT24tZGVtYW5kIENWIGFuZC9v ciByb3V0ZSB0cmFjaW5nIE1VU1QgYmUgcnVuDQo+Pj4gPj4gd2l0aG91dCBJUCBhZGRyZXNz aW5nLCB1c2luZyB0aGUgQUNIIGNoYW5uZWwgdHlwZSBzcGVjaWZpZWQgaW4gU2VjdGlvbg0K Pj4+ID4+IDMuIEluIG90aGVyIGNhc2VzIGl0IG1pZ2h0IGJlIGF2YWlsYWJsZSwgaG93ZXZl ciwgaXQgbWF5IGJlIHByZWZlcnJlZA0KPj4+ID4+IHRvIHVzZSBzb21lIGZvcm0gb2Ygbm9u LUlQIGVuY2Fwc3VsYXRpb24uIEluIHRob3NlIGNhc2VzLCB0aGUNCj4+PiA+PiBwcm9jZWR1 cmVzIGFzIG91dGxpbmVkIGluIHNlY3Rpb24gMyBTSE9VTEQgYWxzbyBiZSB1c2VkLiINCj4+ PiA+PiA+DQo+Pj4gPj4gPlJlZ2FyZGluZyB0aGUgcGVyLWludGVyZmFjZSBNSVAgZGlzY3Vz c2lvbi4gVGhlIEhXIGFzcGVjdCBhbHNvIHBvcHBlZA0KPj4+ID4+IHVwIGluIHRoZSBQV0Uz IHNlc3Npb24gYW5kIEkgdGhpbmsgdGhpcyBpcyBhbiBpbXBvcnRhbnQgY29uc2lkZXJhdGlv biwNCj4+PiA+PiBpbiBwYXJ0aWN1bGFyIGZvciBPQU0uIEV2ZW4gaWYgd2UgdGFsayBhYm91 dCBUTFZzLCB3ZSBjb3VsZCBtYWtlIGl0IGENCj4+PiA+PiBNVVNUIHRoYXQgYW4gQWRkcmVz cyBUTFYgaXMgYWx3YXlzIHRoZSBmaXJzdCBvbmUgdG8gYXBwZWFyLiBJZiB5b3UgY2FuDQo+ Pj4gPj4gZmFjaWxpdGF0ZSBhbiBlYXN5IGltcGxlbWVudGF0aW9uIGluIGhhcmR3YXJlLCBJ IHNlZSBubyByZWFzb24gdG8NCj4+PiA+PiBkZWxpYmVyYXRlbHkgbm90IGRvIGl0Lg0KPj4+ ID4+ID4NCj4+PiA+PiA+QmVzdCwNCj4+PiA+PiA+DQo+Pj4gPj4gPlJvbGYNCj4+PiA+PiA+ DQo+Pj4gPj4gPg0KPj4+ID4+ID5ORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVkIE9m ZmljZTogTkVDIEhvdXNlLCAxIFZpY3RvcmlhIFJvYWQsDQo+Pj4gPj4gTG9uZG9uIFczIDZC TCB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODMyMDE0DQo+Pj4gPj4gPg0KPj4+ID4+ID4N Cj4+PiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ID4+ID4+IEZyb206 IEVyaWMgR3JheSBbbWFpbHRvOmVyaWMuZ3JheUBlcmljc3Nvbi5jb21dDQo+Pj4gPj4gPj4g U2VudDogTW9udGFnLCAyOC4gTeRyeiAyMDExIDExOjQzDQo+Pj4gPj4gPj4gVG86IFJvbGYg V2ludGVyDQo+Pj4gPj4gPj4gQ2M6IGxvYUBwaS5udTsgbXBsc0BpZXRmLm9yZw0KPj4+ID4+ ID4+IFN1YmplY3Q6IFJFOiBbbXBsc10gV29ya2luZyBHcm91cCBMYXMgQ2FsbCBvbiBkcmFm dC1pZXRmLW1wbHMtdHAtb24tDQo+Pj4gPj4gPj4gZGVtYW5kLWN2LTAzDQo+Pj4gPj4gPj4N Cj4+PiA+PiA+PiBSb2xmLA0KPj4+ID4+ID4+DQo+Pj4gPj4gPj4gICBXaXRoIHJlZ2FyZCB0 byB0aGUgdXNlIG9mIFNIT1VMRCAodmVyc2VzIE1VU1QpIC0gdGhlIGludGVudA0KPj4+ID4+ ID4+IChhY2NvcmRpbmcgdG8gUkZDIDIxMTkgLSBzZWUgdGhlIHF1b3RlIGJlbG93KSBpcyBj b25zaXN0ZW50IHdpdGgNCj4+PiA+PiA+PiB0aGlzIGNhc2UuICBJZiAtIGZvciBzb21lIHJl YXNvbiAtIG9uZSBoYWQgYSByZWFsbHkgZ29vZCByZWFzb24gdG8NCj4+PiA+PiA+PiB1c2Ug SVAgYWRkcmVzc2luZyBpbiBzb21lIHNwZWNpZmljIGNhc2UsIG9uZSBjb3VsZCB0YWtlIHN0 ZXBzIHRvDQo+Pj4gPj4gPj4gbWFrZSBJUCBhZGRyZXNzaW5nIGF2YWlsYWJsZS4NCj4+PiA+ PiA+Pg0KPj4+ID4+ID4+ICAgVGhpcyBjb3VsZCBiZSBzYWlkIHRvIGludHJvZHVjZSBhIGxv Z2ljYWwgZGlzY29ubmVjdCwgYnV0IHdlDQo+Pj4gPj4gPj4gYXJlIHNhdmVkIGZyb20gZ29p bmcgZG93biB0aGF0IHBhdGggYnkgdGhlIGZhY3QgdGhhdCB0aGUgc3RhdGVtZW50DQo+Pj4g Pj4gPj4gYWxzbyBpbmNsdWRlcyB0aGUgY2FzZSB3aGVyZSAoZm9yIHNvbWUgcmVhc29uKSB0 aGVyZSBpcyBhIGNhc2UgaW4NCj4+PiA+PiA+PiB3aGljaCBzb21lIG90aGVyIGFkZHJlc3Np bmcgc2NoZW1lIG1pZ2h0IGJlIHByZWZlcnJlZC4gIEluIG1hbnkgb2YNCj4+PiA+PiA+PiB0 aGUgY2FzZXMgd2hlcmUgYW5vdGhlciBhZGRyZXNzaW5nIHNjaGVtZSBtYXkgYmUgcHJlZmVy cmVkLCBpdCBpcw0KPj4+ID4+ID4+IHN0aWxsIHBvc3NpYmxlIChpbiBmYWN0IGxpa2VseSkg dGhhdCBJUCBhZGRyZXNzaW5nIGlzIGF2YWlsYWJsZS4NCj4+PiA+PiA+Pg0KPj4+ID4+ID4+ ICAgT3RoZXJ3aXNlLCBpdCB3b3VsZCBub3QgaGF2ZSBiZWVuIG5lY2Vzc2FyeSB0byBkaXN0 aW5ndWlzaA0KPj4+ID4+ID4+IHRoaXMgY2FzZSBmcm9tIHRoZSBvbmUgaW4gd2hpY2ggSVAg YWRkcmVzc2luZyBpcyBub3QgYXZhaWxhYmxlLg0KPj4+ID4+ID4+DQo+Pj4gPj4gPj4gICBG b3IgdGhlIGNhc2Ugd2hlcmUgSVAgYWRkcmVzc2luZyBpcyBub3QgdGhlIHByZWZlcnJlZCBt b2RlLA0KPj4+ID4+ID4+IHdlIGFyZSByZWNvbW1lbmRpbmcgYSBtb2RlIGluIHdoaWNoIGl0 IGlzIG5vdCBuZWNlc3NhcnkuDQo+Pj4gPj4gPj4NCj4+PiA+PiA+PiAgIFdpdGggcmVnYXJk IHRvIGhhdmluZyBhZGRyZXNzZXMgbG9jYXRlZCBpbiB0aGUgc2FtZSBwbGFjZSwNCj4+PiA+ PiA+PiB0aGlzIHByb3RvY29sIGlzIG1lYW50IGZvciBjb25uZWN0aXZpdHkgdGVzdGluZyBv biBhbiBvbi1kZW1hbmQNCj4+PiA+PiA+PiBiYXNpcyBhbmQgaXMgdGhlcmVmb3JlIG5vdCBv cHRpbWl6ZWQgZm9yIHByb2Nlc3NpbmcgaW4gaGFyZHdhcmUuDQo+Pj4gPj4gPj4NCj4+PiA+ PiA+PiAgIFdoZXRoZXIgYWRkcmVzc2VzIG9yIGlkZW50aWZpZXJzLCBpZiB3ZSBhcmUgdGFs a2luZyBhYm91dA0KPj4+ID4+ID4+IFRMViBjb250ZW50cywgdGhlcmUgYXJlIGlzc3VlcyB3 aXRoIHRyeWluZyB0byBndWFyYW50ZWUgbG9jYXRpb24NCj4+PiA+PiA+PiBvZiBzcGVjaWZp YyBjb250ZW50LCBiZWNhdXNlIG9mIHRoZSBmYWN0IHRoYXQgdGhlIFRMViBpbiBxdWVzdGlv bg0KPj4+ID4+ID4+IHdpbGwgcHJvYmFibHkgZm9sbG93IG90aGVyIFRMVnMgLSB0aHVzIG1h a2luZyBsb2NhdGlvbnMgZGlmZmljdWx0DQo+Pj4gPj4gPj4gdG8gcHJlZGljdCBpbiBhbnkg Y2FzZS4NCj4+PiA+PiA+Pg0KPj4+ID4+ID4+ICAgV2l0aCByZWdhcmQgdG8gbmVlZGluZyBt b3JlIHRleHQgb24gcGVyLWludGVyZmFjZSBNSVBzLCBkbw0KPj4+ID4+ID4+IHlvdSBoYXZl IHNwZWNpZmljIHN1Z2dlc3Rpb25zIGFzIHRvIHdoYXQgdGV4dCB3ZSBtaWdodCBhZGQ/DQo+ Pj4gPj4gPj4NCj4+PiA+PiA+PiAgIEkgdW5kZXJzdGFuZCAoZnJvbSBkaXNjdXNzaW9uIHdp dGggV0cgY2hhaXJzKSB0aGF0IHdlIGFyZQ0KPj4+ID4+ID4+IG5vdCBhbGxvd2VkIHRvIGV4 cGxpY2l0bHkgYWRkcmVzcyBsYXN0IGNhbGwgY29tbWVudHMgZHVyaW5nIHRoZQ0KPj4+ID4+ ID4+IElFVEYgbWVldGluZyBpbiBQcmFndWUsIGJlY2F1c2UgdGhlIGxhc3QgY2FsbCBpcyBz dGlsbCBvbmdvaW5nDQo+Pj4gPj4gPj4gYXQgdGhhdCB0aW1lLg0KPj4+ID4+ID4+DQo+Pj4g Pj4gPj4gLS0NCj4+PiA+PiA+PiBFcmljDQo+Pj4gPj4gPj4NCj4+PiA+PiA+PiBQUyAtDQo+ Pj4gPj4gPj4gRnJvbSBSRkMgMjExOSAtDQo+Pj4gPj4gPj4gJ1NIT1VMRCAgIFRoaXMgd29y ZCwgb3IgdGhlIGFkamVjdGl2ZSAiUkVDT01NRU5ERUQiLCBtZWFuIHRoYXQgdGhlcmUNCj4+ PiA+PiA+PiAgICAgICAgICAgbWF5IGV4aXN0IHZhbGlkIHJlYXNvbnMgaW4gcGFydGljdWxh ciBjaXJjdW1zdGFuY2VzIHRvDQo+Pj4gPj4gPj4gICAgICAgICAgIGlnbm9yZSBhIHBhcnRp Y3VsYXIgaXRlbSwgYnV0IHRoZSBmdWxsIGltcGxpY2F0aW9ucyBtdXN0DQo+Pj4gPj4gPj4g ICAgICAgICAgIGJlIHVuZGVyc3Rvb2QgYW5kIGNhcmVmdWxseSB3ZWlnaGVkIGJlZm9yZSBj aG9vc2luZyBhDQo+Pj4gPj4gPj4gICAgICAgICAgIGRpZmZlcmVudCBjb3Vyc2UuJw0KPj4+ ID4+ID4+DQo+Pj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiA+PiA+ PiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uDQo+Pj4gQmVoYWxmDQo+Pj4gPj4gT2YNCj4+PiA+PiA+PiBSb2xmIFdpbnRl cg0KPj4+ID4+ID4+IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDIyLCAyMDExIDQ6NTcgQU0NCj4+ PiA+PiA+PiBUbzogbG9hQHBpLm51OyBtcGxzQGlldGYub3JnDQo+Pj4gPj4gPj4gU3ViamVj dDogUmU6IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9uIGRyYWZ0LWlldGYtbXBs cy10cC1vbi0NCj4+PiA+PiA+PiBkZW1hbmQtY3YtMDMNCj4+PiA+PiA+Pg0KPj4+ID4+ID4+ IEhpLA0KPj4+ID4+ID4+DQo+Pj4gPj4gPj4gc29tZSBjb21tZW50cyBiZWxvdzoNCj4+PiA+ PiA+Pg0KPj4+ID4+ID4+IFNlY3Rpb24gMS4zIHNheXM6ICIgSW4gY2VydGFpbiBNUExTLVRQ IGRlcGxveW1lbnQgc2NlbmFyaW9zIElQDQo+Pj4gPj4gPj4gYWRkcmVzc2luZyBtaWdodCBu b3QgYmUNCj4+PiA+PiA+PiAgICBhdmFpbGFibGUgb3IgaXQgbWF5IGJlIHByZWZlcnJlZCB0 byB1c2Ugc29tZSBmb3JtIG9mIG5vbi1JUA0KPj4+ID4+ID4+ICAgIGVuY2Fwc3VsYXRpb24g Zm9yIE9uLWRlbWFuZCBDViwgcm91dGUgdHJhY2luZyBhbmQgQkZEIHBhY2tldHMuDQo+Pj4g Pj4gSW4NCj4+PiA+PiA+PiAgICBzdWNoIHNjZW5hcmlvcywgT24tZGVtYW5kIENWIGFuZC9v ciByb3V0ZSB0cmFjaW5nIFNIT1VMRCBiZSBydW4NCj4+PiA+PiA+PiAgICB3aXRob3V0IElQ IGFkZHJlc3NpbmcuLi4iDQo+Pj4gPj4gPj4NCj4+PiA+PiA+PiBJIGFtIG5vdCBzdXJlIHRo ZSAiU0hPVUxEIiBpcyByaWdodCBoZXJlLiBJZiBubyBJUCBhZGRyZXNzaW5nIGlzDQo+Pj4g Pj4gPj4gYXZhaWxhYmxlLCB0aGlzIHRoaW5nIE1VU1QgYmUgcnVuIHdpdGhvdXQgSVAgYWRk cmVzc2luZywgbXVzdG4ndCBpdD8NCj4+PiA+PiA+Pg0KPj4+ID4+ID4+IEkgdGhpbmsgc29t ZSBhZGRpdGlvbmFsIHRleHQgcmVnYXJkaW5nIHBlci1pbnRlcmZhY2UgTUlQIGFkZHJlc3Np bmcNCj4+PiA+PiA+PiB3b3VsZCBiZSBuaWNlLiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kIHRo ZSBkb2N1bWVudCwgYWxsIFRMVnMgd2lsbCBiZQ0KPj4+ID4+ID4+IGluc2lkZSB0aGUgTFNQ IHBpbmcgcGFja2V0IChyYXRoZXIgdGhhbiBhcyBBQ0ggVExWcykuDQo+Pj4gPj4gPj4NCj4+ PiA+PiA+PiBTb21lIHBlb3BsZSBoYWQgY29uY2VybnMgZWFybGllciwgdGhhdCBhZGRyZXNz aW5nIGluZm9ybWF0aW9uIHNob3VsZA0KPj4+ID4+IGJlDQo+Pj4gPj4gPj4gaW4gYSBmaXhl ZCBsb2NhdGlvbiBmb3IgZWFzaWVyIHByb2Nlc3NpbmcuIElzIHRoaXMgdGhlIGNhc2UgaGVy ZSBJDQo+Pj4gPj4gPj4gd29uZGVyPw0KPj4+ID4+ID4+DQo+Pj4gPj4gPj4gSXQgd291bGQg YmUgbmljZSBpZiB5b3UgY291bGQgYWRkcmVzcyB0aGlzIGluIHlvdXIgcHJlc2VudGF0aW9u IGluDQo+Pj4gPj4gPj4gUHJhZ3VlLg0KPj4+ID4+ID4+DQo+Pj4gPj4gPj4gVGhhbmtzLA0K Pj4+ID4+ID4+DQo+Pj4gPj4gPj4gUm9sZg0KPj4+ID4+ID4+DQo+Pj4gPj4gPj4NCj4+PiA+ PiA+PiBORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVkIE9mZmljZTogTkVDIEhvdXNl LCAxIFZpY3RvcmlhIFJvYWQsDQo+Pj4gPj4gPj4gTG9uZG9uIFczIDZCTCB8IFJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCAyODMyMDE0DQo+Pj4gPj4gPj4NCj4+PiA+PiA+Pg0KPj4+ID4+ID4+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiA+PiA+PiA+IEZyb206IG1wbHMt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+ PiA+PiBCZWhhbGYNCj4+PiA+PiA+PiBPZg0KPj4+ID4+ID4+ID4gbG9hQHBpLm51DQo+Pj4g Pj4gPj4gPiBTZW50OiBNaXR0d29jaCwgMTYuIE3kcnogMjAxMSAwMDoyNg0KPj4+ID4+ID4+ ID4gVG86IG1wbHNAaWV0Zi5vcmcNCj4+PiA+PiA+PiA+IENjOiBNUExTLVRQIGFkIGhvYyB0 ZWFtDQo+Pj4gPj4gPj4gPiBTdWJqZWN0OiBbbXBsc10gV29ya2luZyBHcm91cCBMYXMgQ2Fs bCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtb24tDQo+Pj4gPj4gPj4gZGVtYW5kLQ0KPj4+ID4+ ID4+ID4gY3YtMDMNCj4+PiA+PiA+PiA+DQo+Pj4gPj4gPj4gPiBXb3JraW5nIEdyb3VwLA0K Pj4+ID4+ID4+ID4NCj4+PiA+PiA+PiA+IHRoaXMgaXMgdG8gc3RhcnQgYSAzIHdlZWsgd29y a2luZyBncm91cCBsYXN0IGNhbGwgb24NCj4+PiA+PiA+PiA+DQo+Pj4gPj4gPj4gPiBkcmFm dC1pZXRmLW1wbHMtdHAtb24tZGVtYW5kLWN2LTAzDQo+Pj4gPj4gPj4gPg0KPj4+ID4+ID4+ ID4gUGxlYXNlIHNlbmQgY29tbWVudHMgdG8gdGhlIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBs aXN0DQo+Pj4gPj4gPj4gPiBtcGxzQGlldGYub3JnDQo+Pj4gPj4gPj4gPg0KPj4+ID4+ID4+ ID4gVGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgb24gQXByaWwgOCwgMjAxMS4N Cj4+PiA+PiA+PiA+DQo+Pj4gPj4gPj4gPiAvTG9hDQo+Pj4gPj4gPj4gPg0KPj4+ID4+ID4+ ID4NCj4+PiA+PiA+PiA+DQo+Pj4gPj4gPj4gPg0KPj4+ID4+ID4+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiA+PiA+PiA+IG1wbHMg bWFpbGluZyBsaXN0DQo+Pj4gPj4gPj4gPiBtcGxzQGlldGYub3JnDQo+Pj4gPj4gPj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+PiA+PiA+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ID4+ ID4+IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4gPj4gPj4gbXBsc0BpZXRmLm9yZw0KPj4+ID4+ ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4+ID4+ ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ ID4+ID5tcGxzIG1haWxpbmcgbGlzdA0KPj4+ID4+ID5tcGxzQGlldGYub3JnDQo+Pj4gPj4g Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4+ID4+ID4N Cj4+PiA+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+IG1wbHNAaWV0Zi5vcmcNCj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+Pg0KPj4NCj4+ DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+IG1wbHNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4NCj4NCg== --GMAILSMTPBOUND01110329163334-- From ping@pingpan.org Tue Mar 29 00:45:46 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83DCD3A6948 for ; Tue, 29 Mar 2011 00:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 RRNrAU40iqPi for ; Tue, 29 Mar 2011 00:45:45 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with SMTP id 091923A6919 for ; Tue, 29 Mar 2011 00:45:44 -0700 (PDT) Received: from source ([209.85.214.174]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTZGOinbkTYar76PWeiX6PYiNCU/5VP56@postini.com; Tue, 29 Mar 2011 00:47:23 PDT Received: by mail-iw0-f174.google.com with SMTP id 34so4541939iwn.19 for ; Tue, 29 Mar 2011 00:47:22 -0700 (PDT) Received: by 10.42.135.74 with SMTP id o10mr8502158ict.12.1301384842388; Tue, 29 Mar 2011 00:47:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.195.202 with HTTP; Tue, 29 Mar 2011 00:46:42 -0700 (PDT) In-Reply-To: References: From: Ping Pan Date: Tue, 29 Mar 2011 09:46:42 +0200 Message-ID: To: Greg Mirsky Content-Type: multipart/alternative; boundary=90e6ba6e88883f2375049f9a4559 Cc: sam.aldrin@huawei.com, mpls@ietf.org, Luyuan Fang Subject: Re: [mpls] Comments on draft-pan-shared-mesh-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:45:46 -0000 --90e6ba6e88883f2375049f9a4559 Content-Type: text/plain; charset=ISO-8859-1 Hi, Greg, Thanks for the feedback. On Tue, Mar 29, 2011 at 8:13 AM, Greg Mirsky wrote: > Dear Authors, > please kindly consider my comments to your proposal. > > - Section 2. I think that "make-before-break" is more often used in > reference to tunnel recovery, re-routing rather than protection since MBB > takes advantage of available resources already used by a tunnel. In > protection diversity of working and protecting paths usually required. > - Section 3. the path in the example assumed to be bi-directional. I > think that it is important that they been assumed to be co-routed as well. > If authors believe that protocol works equally for co-routed as well as > associated bi-directional MPLS-TP connections, please clarify. > > Yes. Will do. > > - I'd suggest to enumerate figures in the text. Will make referencing > them much easier. > > Yes. Will do. > > - Section 6.2 It appears that proposed solution doesn't use ACH TLVs. > If that is the case, then there's no need to reserve ACH TLV Header > > > - Presented formats of STATUS and NOTIFY messages use "Exp" instead of > "TC" in presenting SLE format > > OK. Will fix. > > - Section 7. That is probably my biggest issue with the proposal. > Effectively, the mechanism is based on MIP generating an OAM message. But > according to draft-ietf-mpls-tp-oam-framework-11 Section 3.4 generated by > MIP OAM packet must be sent to the MEP that originated OAM request. In > proposed mechanism MIP generates OAM packet but it's sent in opposite > direction. > > I don't think this is the case. First, this is about shared mesh protection, as required in MPLS-TP (RFC5654). Don't think this is about OAM. The proposed operation is quite simple: - The operators set up some protection LSP's for a working one - The protection LSP's use the network resources shared by other LSP's - When there is a failure, the headend sends a message to a protection LSP, saying "activate me" - The intermediate nodes will do the following: - if the resources are not taken, occupy the resources and relay the message downstream - if the resources are taken by a connection with less importance, take over the resources, relay the message but tell the preempted edge node "you are gone" - else, reply a message to the headend "activation failed" - The tailend always sends a message back to the headend with either "success" or "failure" This is about it! We may optimize further for performance. However, simplicity is one of the key design objectives. After all, we intend to process the activation/de-activation at data-plane with special code, including hardware assistance, so that we can satisfy TP's performance objective of 50-msec. Many thanks! Regards, Ping > > If I may, I'd consider using Section OAM with GAL as only label and the > context provided by MPLS-TP ID, i.e.MPLS-TP LSP ID as in > draft-ietf-mpls-tp-identifiers-02. Then Activation message format will > require ACH TLV Header as in document's Section 6.2. > > Regards, > Greg > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --90e6ba6e88883f2375049f9a4559 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Greg,

    Thanks for the feedback.

    <= div>
    On Tue, Mar 29, 2011 at 8:13 AM, Greg Mirsky <= ;gregimirsky@gmail.com> wrote:
    Dear Author= s,
    please kindly consider my comments to your proposal.
    • Secti= on 2. I think that "make-before-break" is more often used in refe= rence to tunnel recovery, re-routing rather than protection since MBB takes= advantage of available resources already used by a tunnel. In protection d= iversity of working and protecting paths usually required.
    • Section 3. the path in the example assumed to be bi-directional. I thin= k that it is important that they been assumed to be co-routed as well. If a= uthors believe that protocol works equally for co-routed as well as associa= ted bi-directional MPLS-TP connections, please clarify.

    Yes. Will do.
    =A0
    • I'd suggest to enumerate figures in the text. Will make referencing= them much easier.

    Yes. Will do.<= /div>
    =A0
    • Section 6.2 It appears that proposed solution doesn't use ACH T= LVs. If that is the case, then there's no need to reserve ACH TLV Heade= r
    • Presented formats of STATUS and NOTIFY messages use "Exp" ins= tead of "TC" in presenting SLE format
    =
    OK. Will fix.
    • Section 7. That is probably my biggest issue with the proposal. Eff= ectively, the mechanism is based on MIP generating an OAM message. But acco= rding to draft-ietf-mpls-tp-oam-framework-11 Section 3.4 generated by MIP O= AM packet must be sent to the MEP that originated OAM request. In proposed = mechanism MIP generates OAM packet but it's sent in opposite direction.=

    I don't think this is the case.

    First, this is about shared mesh protection, as req= uired in MPLS-TP (RFC5654). Don't think this is about OAM.

    The proposed operation is quite simple:

    =
    - The operators set up some protection LSP's for a working one
    - The protection LSP's use the network resources shared by other= LSP's

    - When there is a failure, the headend sends a message = to a protection LSP, saying "activate me"

    - The intermediate nodes will do the following:
    =A0=A0 - if the= resources are not taken, occupy the resources and relay the message downst= ream
    =A0=A0 - if the resources are taken by a connection with less importan= ce, take over the resources, relay the message but tell the preempted edge = node "you are gone"
    =A0=A0 - else, reply a message to t= he headend "activation failed"

    - The tailend always sends a message back to the headen= d with either "success" or "failure"

    This is about it!

    We may optimize further f= or performance. However, simplicity is one of the key design objectives. Af= ter all, we intend to process the activation/de-activation at data-plane wi= th special code, including hardware assistance, so that we can=A0satisfy TP= 's performance objective of 50-msec.=A0
    =A0
    Many thanks!

    Regards,

    Ping

    If I may, I'd consider using Secti= on OAM with GAL as only label and the context provided by MPLS-TP ID, i.e.M= PLS-TP LSP ID as in draft-ietf-mpls-tp-identifiers-02. Then Activation mess= age format will require ACH TLV Header as in document's Section 6.2.
    Regards,
    Greg

    _______________________________________________
    mpls mailing list
    mpls@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/mpls


    --90e6ba6e88883f2375049f9a4559-- From sboutros@cisco.com Tue Mar 29 00:50:21 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98D43A6873 for ; Tue, 29 Mar 2011 00:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.201 X-Spam-Level: X-Spam-Status: No, score=-8.201 tagged_above=-999 required=5 tests=[AWL=-2.397, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, SUBJ_RE_NUM=2.799] 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 OhIhZRuyx6JN for ; Tue, 29 Mar 2011 00:50:20 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E68873A683F for ; Tue, 29 Mar 2011 00:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=16823; q=dns/txt; s=iport; t=1301385118; x=1302594718; h=date:to:from:subject:cc:in-reply-to:references: mime-version:content-transfer-encoding:message-id; bh=TybVbWbd74iBZBRoPrA3zz2GQv4d8e/F46PU2OCu8jo=; b=Glg0Sy+p+fwFoDdkS+/IJGA5qXl8bC+TQxKeMXqlL2MDUzo8l2Erp2YG YBWd49O+SJlir9dqdTO/ZdZYSEf6zw1RqOAhqkJDCmlNUCo80YibHhy8P /uCckvcfrs6giRyXYgivxVMvUNtTd3/2tqfEd1WUWYkvWDcpRi9NaOR2/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAABCPkU2rRDoI/2dsb2JhbACHXZAyjF5Yd6dVnD2CfBOCWwSFPIsg X-IronPort-AV: E=Sophos;i="4.63,260,1299456000"; d="scan'208";a="284707596" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2011 07:51:57 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2T7pviA001538; Tue, 29 Mar 2011 07:51:57 GMT Received: from xfe-sjc-231.amer.cisco.com ([128.107.191.114]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Mar 2011 00:51:57 -0700 Received: from sboutros-wxp02.ciswco.com ([10.21.118.222]) by xfe-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Mar 2011 00:51:56 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Mar 2011 00:51:52 -0700 To: , From: Sami Boutros In-Reply-To: References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 29 Mar 2011 07:51:56.0738 (UTC) FILETIME=[2D3C5220:01CBEDE6] Cc: mpls@ietf.org, Rolf.Winter@neclab.eu Subject: Re: [mpls] Working Group Las Cal londraft-ietf-mpls-tp- on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:50:22 -0000 Agreed folks, The solution options you propose on the draft=20 would work and will be transparent to the on-demand-cv draft. Thanks, Sami At 12:33 AM 3/29/2011, hideki.endo.es@hitachi.com wrote: >Hi Sami, > >I don't think that the per-interface MIP=20 >requires a node to decrement TTL twice. >I have proposed draft-mip-mep-map to avoid twice decrement of TTL. >However, we, authers, don't push specific=20 >solution for per-interface MIP at this point, >which presented by Rolf at previous meeting at Beijing. > >We have several options to identify=20 >per-interface MIP without twice decrement of TTL; >(1)MIP ID in ACH-TLV >(2)MIP ID in Ping address TLV >(3)OML >(4)GAL TTL(I proposed before, but now removed from our draft) > >We can discuss the best solution in this meeting. > >BR, >Hideki > > > >Hi Sami, > >alternative to decrementing TTL for out-MIP approach, to use reserved > >Outgoing MIP Label (OML), presented in= draft-farrel-mpls-tp-mip-mep-map-03. > >Considering that few proposed MPLS-TP OAM mechanisms use ACH TLV Header= per > >RFC 5586 OML might be the better solution to address out-MIP. > > > >Regards, > >Greg > > > >On Mon, Mar 28, 2011 at 1:33 PM, Sami Boutros wrote: > > > >> At 06:43 AM 3/28/2011, hideki.endo.es@hitachi.com wrote: > >> > >>> Hi Eric, > >>> > >>> What I'd like to say was explaned by Rolf. > >>> My concern is whether the OAM packet is fate sharing with user packet= or > >>> NOT. > >>> If draft-on-demand-cv doesn't care anything for fate sharing > >>> in the case of per-interface MIP, > >>> the per-interface MIP can NOT be implemented by HW reasonably. > >>> > >> > >> Keep in mind that a node decrement TTL once, and this per-interface MIP > >> seems to require a node to decrement twice.. > >> > >> Thanks, > >> > >> Sami > >> > >> > >> BR, > >>> Hideki > >>> > >>> >Eric, > >>> > > >>> >I generally agree but I think there is one case actually which needs= a > >>> closer look in this regard (which I hinted at earlier), which are the > >>> per-interface MIPs. Your TTL expires (the=20 > actual addressing bit here), the > >>> identifier tells you it is not intended for=20 > the ingress MIP, so it needs to > >>> be forwarded to the egress MIP through the forwarding engine. Now if= you > >>> pull the packet out of the fast path and inject it back in, is the OAM > >>> packet still fate sharing? If you can do=20 > this in HW on the line card, then > >>> it will and it will just be forwarded as=20 > normal. I know this is a different > >>> draft, but this will be in particular=20 > important for performance monitoring. > >>> > > >>> >Best, > >>> > > >>> >Rolf > >>> > > >>> > > >>> > > >>> >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > >>> London W3 6BL | Registered in England 2832014 > >>> > > >>> > > >>> >> -----Original Message----- > >>> >> From: Eric Gray [mailto:eric.gray@ericsson.com] > >>> >> Sent: Montag, 28. M=E4rz 2011 14:45 > >>> >> To: hideki.endo.es@hitachi.com; Rolf Winter > >>> >> Cc: mpls@ietf.org > >>> >> Subject: RE: Re[2]: [mpls] Working Group=20 > Las Call ondraft-ietf-mpls-tp- > >>> >> on-demand-cv-03 > >>> >> > >>> >> Hideki, > >>> >> > >>> >> What you're saying is true, but not relevant in this > >>> >> case. The "addresses" in this discussion are not used to > >>> >> determine how to forward OAM packets. They are used only > >>> >> by the recipient MIP/MEP to verify that the OAM packet was > >>> >> properly delivered. > >>> >> > >>> >> By the way, this discussion is an indication of the > >>> >> confusing injected by calling these things addresses. My > >>> >> mistake and I bring it up now to help to stem the tide of > >>> >> further comments resulting from that confusion. > >>> >> > >>> >> In the version we post after last call is complete, > >>> >> we will be changing the source and destination "address" > >>> >> TLVs to source and destination "identifier" TLVs. > >>> >> > >>> >> We will also be correcting the reference to DSMAP, > >>> >> and DDMAP, address TLVs (which is incorrect, because the > >>> >> format for DSMAP/DDMAP doesn't include a "length" field). > >>> >> > >>> >> The format of the Downstream Mapping (DSMAP) TLV is > >>> >> defined in RFC 4379, and we are not changing the format > >>> >> of that TLV. > >>> >> > >>> >> These changes are driven by last call comments we > >>> >> have already received (see Joel Halpern's comments on the > >>> >> mailing list) and are - in part - to correct accidental > >>> >> use of the word "address" for source and destination > >>> >> identifier TLVs (which is what we had discussed before > >>> >> I generated the -03 version among the authors of several > >>> >> of the current set of MPLS-TP drafts). > >>> >> > >>> >> In the case of source and destination identifiers, > >>> >> these will be used exclusively to verify that an OAM PDU > >>> >> has been correctly received by its intended recipient. > >>> >> Because this is an on-demand connectivity verification > >>> >> protocol, that is expected to be used only on those > >>> >> occasions when there is a network problem that needs to > >>> >> be diagnosed, and the information is not seen (and not > >>> >> visible - without layer violations), optimizing these > >>> >> objects for software makes sense. > >>> >> > >>> >> In addition, since either may be included (which > >>> >> includes the possibility of including both), it is the > >>> >> case already that we would then need to decide which is > >>> >> to go first - assuming we wanted to do this (which we > >>> >> do not). > >>> >> > >>> >> -- > >>> >> Eric > >>> >> > >>> >> -----Original Message----- > >>> >> From: hideki.endo.es@hitachi.com= [mailto:hideki.endo.es@hitachi.com] > >>> >> Sent: Monday, March 28, 2011 8:11 AM > >>> >> To: Eric Gray; Rolf.Winter@neclab.eu > >>> >> Cc: mpls@ietf.org > >>> >> Subject: Re[2]: [mpls] Working Group Las Call= ondraft-ietf-mpls-tp-on- > >>> >> demand-cv-03 > >>> >> Importance: High > >>> >> > >>> >> Hi Eric and Rolf, > >>> >> > >>> >> I'm sorry for interrupting. > >>> >> > >>> >> I agree with Rolf regarding the per-interface MIP discussion. > >>> >> We have to consider the HW implementation aspect, > >>> >> because trapping of an OAM packet is HW rule/functionality even in > >>> >> routers. > >>> >> > >>> >> If every OAM packet is trapped to CPU > >>> >> and the OAM packets which should NOT be processed in the Interface > >>> >> are returned to Data-plane, > >>> >> it is different forwarding path from user packets, > >>> >> which is NOT the Connectivity Verification of the user path. > >>> >> > >>> >> Therefore, we should take the HW aspect and flexibilty into account > >>> >> concurrently. > >>> >> If an address TLV MUST be the first in TLVs, > >>> >> it is enough to make HW implementation easy. > >>> >> > >>> >> BR, > >>> >> Hideki > >>> >> > >>> >> > >>> >> > >>> >> >Rolf, > >>> >> > > >>> >> > The words you propose are okay with me. > >>> >> > > >>> >> > I thought the MIP/interface and address location issues > >>> >> >were separate. > >>> >> > > >>> >> > I've personally had problems with protocol specifications > >>> >> >that require ordering of TLVs. In particular, this is not very > >>> >> >robust in terms of "future-proofing." What happens if new TLVs > >>> >> >are added later on; for instance, suppose at some point we have > >>> >> >multiple "address" TLVs? > >>> >> > > >>> >> > Also, the fact that implementations are allowed to attach > >>> >> >TLVs in any arbitrary order allows considerable flexibilty in > >>> >> >implementation. Messages can be built in arbitrarily many ways. > >>> >> >This too can be a future-proofing issue. > >>> >> > > >>> >> > I would prefer not to start down the road of requiring a > >>> >> >subset of TLVs to appear in a certain order, and saying we have > >>> >> >one TLV that needs to be first is doing just that. > >>> >> > > >>> >> >-- > >>> >> >Eric > >>> >> > > >>> >> >-----Original Message----- > >>> >> >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > >>> >> >Sent: Monday, March 28, 2011 6:19 AM > >>> >> >To: Eric Gray > >>> >> >Cc: mpls@ietf.org > >>> >> >Subject: RE: [mpls] Working Group Las Call on= draft-ietf-mpls-tp-on- > >>> >> demand-cv-03 > >>> >> >Importance: High > >>> >> > > >>> >> >Hi, > >>> >> > > >>> >> >I still think there is a logical error. Let me explain. In case= there > >>> >> is no IP you simply cannot use it. You=20 > say you could enable IP but then > >>> >> that is not a case where there is no IP. In order to be= constructive > >>> >> here is a text change suggestion: > >>> >> > > >>> >> >"In certain MPLS-TP deployment scenarios IP addressing might not= be > >>> >> available. In those cases On-demand CV=20 > and/or route tracing MUST be run > >>> >> without IP addressing, using the ACH channel type specified in= Section > >>> >> 3. In other cases it might be available, however, it may be= preferred > >>> >> to use some form of non-IP encapsulation. In those cases, the > >>> >> procedures as outlined in section 3 SHOULD also be used." > >>> >> > > >>> >> >Regarding the per-interface MIP discussion. The HW aspect also= popped > >>> >> up in the PWE3 session and I think this is an important= consideration, > >>> >> in particular for OAM. Even if we talk about TLVs, we could make it= a > >>> >> MUST that an Address TLV is always the first one to appear. If you= can > >>> >> facilitate an easy implementation in hardware, I see no reason to > >>> >> deliberately not do it. > >>> >> > > >>> >> >Best, > >>> >> > > >>> >> >Rolf > >>> >> > > >>> >> > > >>> >> >NEC Europe Limited | Registered Office: NEC House, 1 Victoria= Road, > >>> >> London W3 6BL | Registered in England 2832014 > >>> >> > > >>> >> > > >>> >> >> -----Original Message----- > >>> >> >> From: Eric Gray [mailto:eric.gray@ericsson.com] > >>> >> >> Sent: Montag, 28. M=E4rz 2011 11:43 > >>> >> >> To: Rolf Winter > >>> >> >> Cc: loa@pi.nu; mpls@ietf.org > >>> >> >> Subject: RE: [mpls] Working Group Las=20 > Call on draft-ietf-mpls-tp-on- > >>> >> >> demand-cv-03 > >>> >> >> > >>> >> >> Rolf, > >>> >> >> > >>> >> >> With regard to the use of SHOULD (verses MUST) - the intent > >>> >> >> (according to RFC 2119 - see the quote below) is consistent with > >>> >> >> this case. If - for some reason - one had a really good reason= to > >>> >> >> use IP addressing in some specific case, one could take steps to > >>> >> >> make IP addressing available. > >>> >> >> > >>> >> >> This could be said to introduce a logical disconnect, but we > >>> >> >> are saved from going down that path by the fact that the= statement > >>> >> >> also includes the case where (for some reason) there is a case= in > >>> >> >> which some other addressing scheme might be preferred. In many= of > >>> >> >> the cases where another addressing scheme may be preferred, it= is > >>> >> >> still possible (in fact likely) that IP addressing is available. > >>> >> >> > >>> >> >> Otherwise, it would not have been necessary to distinguish > >>> >> >> this case from the one in which IP addressing is not available. > >>> >> >> > >>> >> >> For the case where IP addressing is not the preferred mode, > >>> >> >> we are recommending a mode in which it is not necessary. > >>> >> >> > >>> >> >> With regard to having addresses located in the same place, > >>> >> >> this protocol is meant for connectivity testing on an on-demand > >>> >> >> basis and is therefore not optimized for processing in hardware. > >>> >> >> > >>> >> >> Whether addresses or identifiers, if we are talking about > >>> >> >> TLV contents, there are issues with trying to guarantee location > >>> >> >> of specific content, because of the fact that the TLV in= question > >>> >> >> will probably follow other TLVs - thus making locations= difficult > >>> >> >> to predict in any case. > >>> >> >> > >>> >> >> With regard to needing more text on per-interface MIPs, do > >>> >> >> you have specific suggestions as to what text we might add? > >>> >> >> > >>> >> >> I understand (from discussion with WG chairs) that we are > >>> >> >> not allowed to explicitly address last call comments during the > >>> >> >> IETF meeting in Prague, because the last call is still ongoing > >>> >> >> at that time. > >>> >> >> > >>> >> >> -- > >>> >> >> Eric > >>> >> >> > >>> >> >> PS - > >>> >> >> From RFC 2119 - > >>> >> >> 'SHOULD This word, or the adjective=20 > "RECOMMENDED", mean that there > >>> >> >> may exist valid reasons in particular circumstances to > >>> >> >> ignore a particular item, but the full implications= must > >>> >> >> be understood and carefully weighed before choosing a > >>> >> >> different course.' > >>> >> >> > >>> >> >> -----Original Message----- > >>> >> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >>> Behalf > >>> >> Of > >>> >> >> Rolf Winter > >>> >> >> Sent: Tuesday, March 22, 2011 4:57 AM > >>> >> >> To: loa@pi.nu; mpls@ietf.org > >>> >> >> Subject: Re: [mpls] Working Group Las=20 > Call on draft-ietf-mpls-tp-on- > >>> >> >> demand-cv-03 > >>> >> >> > >>> >> >> Hi, > >>> >> >> > >>> >> >> some comments below: > >>> >> >> > >>> >> >> Section 1.3 says: " In certain MPLS-TP deployment scenarios IP > >>> >> >> addressing might not be > >>> >> >> available or it may be preferred to use some form of non-IP > >>> >> >> encapsulation for On-demand CV, route tracing and BFD= packets. > >>> >> In > >>> >> >> such scenarios, On-demand CV and/or route tracing SHOULD be= run > >>> >> >> without IP addressing..." > >>> >> >> > >>> >> >> I am not sure the "SHOULD" is right here. If no IP addressing is > >>> >> >> available, this thing MUST be run=20 > without IP addressing, mustn't it? > >>> >> >> > >>> >> >> I think some additional text regarding per-interface MIP= addressing > >>> >> >> would be nice. As far as I understand=20 > the document, all TLVs will be > >>> >> >> inside the LSP ping packet (rather than as ACH TLVs). > >>> >> >> > >>> >> >> Some people had concerns earlier,=20 > that addressing information should > >>> >> be > >>> >> >> in a fixed location for easier processing. Is this the case here= I > >>> >> >> wonder? > >>> >> >> > >>> >> >> It would be nice if you could address this in your presentation= in > >>> >> >> Prague. > >>> >> >> > >>> >> >> Thanks, > >>> >> >> > >>> >> >> Rolf > >>> >> >> > >>> >> >> > >>> >> >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria= Road, > >>> >> >> London W3 6BL | Registered in England 2832014 > >>> >> >> > >>> >> >> > >>> >> >> > -----Original Message----- > >>> >> >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >>> >> Behalf > >>> >> >> Of > >>> >> >> > loa@pi.nu > >>> >> >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26 > >>> >> >> > To: mpls@ietf.org > >>> >> >> > Cc: MPLS-TP ad hoc team > >>> >> >> > Subject: [mpls] Working Group Las Call on= draft-ietf-mpls-tp-on- > >>> >> >> demand- > >>> >> >> > cv-03 > >>> >> >> > > >>> >> >> > Working Group, > >>> >> >> > > >>> >> >> > this is to start a 3 week working group last call on > >>> >> >> > > >>> >> >> > draft-ietf-mpls-tp-on-demand-cv-03 > >>> >> >> > > >>> >> >> > Please send comments to the working group mailing list > >>> >> >> > mpls@ietf.org > >>> >> >> > > >>> >> >> > The working group last call ends on April 8, 2011. > >>> >> >> > > >>> >> >> > /Loa > >>> >> >> > > >>> >> >> > > >>> >> >> > > >>> >> >> > > >>> >> >> > _______________________________________________ > >>> >> >> > mpls mailing list > >>> >> >> > mpls@ietf.org > >>> >> >> > https://www.ietf.org/mailman/listinfo/mpls > >>> >> >> _______________________________________________ > >>> >> >> mpls mailing list > >>> >> >> mpls@ietf.org > >>> >> >> https://www.ietf.org/mailman/listinfo/mpls > >>> >> >_______________________________________________ > >>> >> >mpls mailing list > >>> >> >mpls@ietf.org > >>> >> >https://www.ietf.org/mailman/listinfo/mpls > >>> >> > > >>> > > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > >>> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >> > > From eric.gray@ericsson.com Tue Mar 29 00:54:45 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B585F3A68E1 for ; Tue, 29 Mar 2011 00:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.272 X-Spam-Level: X-Spam-Status: No, score=-5.272 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 XDeww7Wg1Kk5 for ; Tue, 29 Mar 2011 00:54:44 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id C68293A683F for ; Tue, 29 Mar 2011 00:54:43 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p2T7uFCZ019890 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Mar 2011 02:56:16 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 29 Mar 2011 03:56:15 -0400 From: Eric Gray To: "hideki.endo.es@hitachi.com" , "gregimirsky@gmail.com" , "sboutros@cisco.com" Date: Tue, 29 Mar 2011 03:56:13 -0400 Thread-Topic: Re[2]: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-demand-cv-03 Thread-Index: Acvt46Mkcr5+f1G9QtuiIazof+NdKgAAxBdg Message-ID: References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> In-Reply-To: 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@ietf.org" , "Rolf.Winter@neclab.eu" Subject: Re: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:54:45 -0000 Which meeting are you referring to? -----Original Message----- From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] Sent: Tuesday, March 29, 2011 3:33 AM To: gregimirsky@gmail.com; sboutros@cisco.com Cc: Eric Gray; Rolf.Winter@neclab.eu; mpls@ietf.org Subject: Re[2]: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-deman= d-cv-03 Hi Sami, I don't think that the per-interface MIP requires a node to decrement TTL t= wice. I have proposed draft-mip-mep-map to avoid twice decrement of TTL. However, we, authers, don't push specific solution for per-interface MIP at= this point, which presented by Rolf at previous meeting at Beijing. We have several options to identify per-interface MIP without twice decreme= nt of TTL; (1)MIP ID in ACH-TLV (2)MIP ID in Ping address TLV (3)OML (4)GAL TTL(I proposed before, but now removed from our draft) We can discuss the best solution in this meeting. BR, Hideki >Hi Sami, >alternative to decrementing TTL for out-MIP approach, to use reserved >Outgoing MIP Label (OML), presented in draft-farrel-mpls-tp-mip-mep-map-03= . >Considering that few proposed MPLS-TP OAM mechanisms use ACH TLV Header pe= r >RFC 5586 OML might be the better solution to address out-MIP. > >Regards, >Greg > >On Mon, Mar 28, 2011 at 1:33 PM, Sami Boutros wrote: > >> At 06:43 AM 3/28/2011, hideki.endo.es@hitachi.com wrote: >> >>> Hi Eric, >>> >>> What I'd like to say was explaned by Rolf. >>> My concern is whether the OAM packet is fate sharing with user packet o= r >>> NOT. >>> If draft-on-demand-cv doesn't care anything for fate sharing >>> in the case of per-interface MIP, >>> the per-interface MIP can NOT be implemented by HW reasonably. >>> >> >> Keep in mind that a node decrement TTL once, and this per-interface MIP >> seems to require a node to decrement twice.. >> >> Thanks, >> >> Sami >> >> >> BR, >>> Hideki >>> >>> >Eric, >>> > >>> >I generally agree but I think there is one case actually which needs a >>> closer look in this regard (which I hinted at earlier), which are the >>> per-interface MIPs. Your TTL expires (the actual addressing bit here), = the >>> identifier tells you it is not intended for the ingress MIP, so it need= s to >>> be forwarded to the egress MIP through the forwarding engine. Now if yo= u >>> pull the packet out of the fast path and inject it back in, is the OAM >>> packet still fate sharing? If you can do this in HW on the line card, t= hen >>> it will and it will just be forwarded as normal. I know this is a diffe= rent >>> draft, but this will be in particular important for performance monitor= ing. >>> > >>> >Best, >>> > >>> >Rolf >>> > >>> > >>> > >>> >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>> London W3 6BL | Registered in England 2832014 >>> > >>> > >>> >> -----Original Message----- >>> >> From: Eric Gray [mailto:eric.gray@ericsson.com] >>> >> Sent: Montag, 28. M=E4rz 2011 14:45 >>> >> To: hideki.endo.es@hitachi.com; Rolf Winter >>> >> Cc: mpls@ietf.org >>> >> Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-= tp- >>> >> on-demand-cv-03 >>> >> >>> >> Hideki, >>> >> >>> >> What you're saying is true, but not relevant in this >>> >> case. The "addresses" in this discussion are not used to >>> >> determine how to forward OAM packets. They are used only >>> >> by the recipient MIP/MEP to verify that the OAM packet was >>> >> properly delivered. >>> >> >>> >> By the way, this discussion is an indication of the >>> >> confusing injected by calling these things addresses. My >>> >> mistake and I bring it up now to help to stem the tide of >>> >> further comments resulting from that confusion. >>> >> >>> >> In the version we post after last call is complete, >>> >> we will be changing the source and destination "address" >>> >> TLVs to source and destination "identifier" TLVs. >>> >> >>> >> We will also be correcting the reference to DSMAP, >>> >> and DDMAP, address TLVs (which is incorrect, because the >>> >> format for DSMAP/DDMAP doesn't include a "length" field). >>> >> >>> >> The format of the Downstream Mapping (DSMAP) TLV is >>> >> defined in RFC 4379, and we are not changing the format >>> >> of that TLV. >>> >> >>> >> These changes are driven by last call comments we >>> >> have already received (see Joel Halpern's comments on the >>> >> mailing list) and are - in part - to correct accidental >>> >> use of the word "address" for source and destination >>> >> identifier TLVs (which is what we had discussed before >>> >> I generated the -03 version among the authors of several >>> >> of the current set of MPLS-TP drafts). >>> >> >>> >> In the case of source and destination identifiers, >>> >> these will be used exclusively to verify that an OAM PDU >>> >> has been correctly received by its intended recipient. >>> >> Because this is an on-demand connectivity verification >>> >> protocol, that is expected to be used only on those >>> >> occasions when there is a network problem that needs to >>> >> be diagnosed, and the information is not seen (and not >>> >> visible - without layer violations), optimizing these >>> >> objects for software makes sense. >>> >> >>> >> In addition, since either may be included (which >>> >> includes the possibility of including both), it is the >>> >> case already that we would then need to decide which is >>> >> to go first - assuming we wanted to do this (which we >>> >> do not). >>> >> >>> >> -- >>> >> Eric >>> >> >>> >> -----Original Message----- >>> >> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >>> >> Sent: Monday, March 28, 2011 8:11 AM >>> >> To: Eric Gray; Rolf.Winter@neclab.eu >>> >> Cc: mpls@ietf.org >>> >> Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-o= n- >>> >> demand-cv-03 >>> >> Importance: High >>> >> >>> >> Hi Eric and Rolf, >>> >> >>> >> I'm sorry for interrupting. >>> >> >>> >> I agree with Rolf regarding the per-interface MIP discussion. >>> >> We have to consider the HW implementation aspect, >>> >> because trapping of an OAM packet is HW rule/functionality even in >>> >> routers. >>> >> >>> >> If every OAM packet is trapped to CPU >>> >> and the OAM packets which should NOT be processed in the Interface >>> >> are returned to Data-plane, >>> >> it is different forwarding path from user packets, >>> >> which is NOT the Connectivity Verification of the user path. >>> >> >>> >> Therefore, we should take the HW aspect and flexibilty into account >>> >> concurrently. >>> >> If an address TLV MUST be the first in TLVs, >>> >> it is enough to make HW implementation easy. >>> >> >>> >> BR, >>> >> Hideki >>> >> >>> >> >>> >> >>> >> >Rolf, >>> >> > >>> >> > The words you propose are okay with me. >>> >> > >>> >> > I thought the MIP/interface and address location issues >>> >> >were separate. >>> >> > >>> >> > I've personally had problems with protocol specifications >>> >> >that require ordering of TLVs. In particular, this is not very >>> >> >robust in terms of "future-proofing." What happens if new TLVs >>> >> >are added later on; for instance, suppose at some point we have >>> >> >multiple "address" TLVs? >>> >> > >>> >> > Also, the fact that implementations are allowed to attach >>> >> >TLVs in any arbitrary order allows considerable flexibilty in >>> >> >implementation. Messages can be built in arbitrarily many ways. >>> >> >This too can be a future-proofing issue. >>> >> > >>> >> > I would prefer not to start down the road of requiring a >>> >> >subset of TLVs to appear in a certain order, and saying we have >>> >> >one TLV that needs to be first is doing just that. >>> >> > >>> >> >-- >>> >> >Eric >>> >> > >>> >> >-----Original Message----- >>> >> >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >>> >> >Sent: Monday, March 28, 2011 6:19 AM >>> >> >To: Eric Gray >>> >> >Cc: mpls@ietf.org >>> >> >Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on= - >>> >> demand-cv-03 >>> >> >Importance: High >>> >> > >>> >> >Hi, >>> >> > >>> >> >I still think there is a logical error. Let me explain. In case the= re >>> >> is no IP you simply cannot use it. You say you could enable IP but t= hen >>> >> that is not a case where there is no IP. In order to be constructive >>> >> here is a text change suggestion: >>> >> > >>> >> >"In certain MPLS-TP deployment scenarios IP addressing might not be >>> >> available. In those cases On-demand CV and/or route tracing MUST be = run >>> >> without IP addressing, using the ACH channel type specified in Secti= on >>> >> 3. In other cases it might be available, however, it may be preferre= d >>> >> to use some form of non-IP encapsulation. In those cases, the >>> >> procedures as outlined in section 3 SHOULD also be used." >>> >> > >>> >> >Regarding the per-interface MIP discussion. The HW aspect also popp= ed >>> >> up in the PWE3 session and I think this is an important consideratio= n, >>> >> in particular for OAM. Even if we talk about TLVs, we could make it = a >>> >> MUST that an Address TLV is always the first one to appear. If you c= an >>> >> facilitate an easy implementation in hardware, I see no reason to >>> >> deliberately not do it. >>> >> > >>> >> >Best, >>> >> > >>> >> >Rolf >>> >> > >>> >> > >>> >> >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>> >> London W3 6BL | Registered in England 2832014 >>> >> > >>> >> > >>> >> >> -----Original Message----- >>> >> >> From: Eric Gray [mailto:eric.gray@ericsson.com] >>> >> >> Sent: Montag, 28. M=E4rz 2011 11:43 >>> >> >> To: Rolf Winter >>> >> >> Cc: loa@pi.nu; mpls@ietf.org >>> >> >> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-= on- >>> >> >> demand-cv-03 >>> >> >> >>> >> >> Rolf, >>> >> >> >>> >> >> With regard to the use of SHOULD (verses MUST) - the intent >>> >> >> (according to RFC 2119 - see the quote below) is consistent with >>> >> >> this case. If - for some reason - one had a really good reason t= o >>> >> >> use IP addressing in some specific case, one could take steps to >>> >> >> make IP addressing available. >>> >> >> >>> >> >> This could be said to introduce a logical disconnect, but we >>> >> >> are saved from going down that path by the fact that the statemen= t >>> >> >> also includes the case where (for some reason) there is a case in >>> >> >> which some other addressing scheme might be preferred. In many o= f >>> >> >> the cases where another addressing scheme may be preferred, it is >>> >> >> still possible (in fact likely) that IP addressing is available. >>> >> >> >>> >> >> Otherwise, it would not have been necessary to distinguish >>> >> >> this case from the one in which IP addressing is not available. >>> >> >> >>> >> >> For the case where IP addressing is not the preferred mode, >>> >> >> we are recommending a mode in which it is not necessary. >>> >> >> >>> >> >> With regard to having addresses located in the same place, >>> >> >> this protocol is meant for connectivity testing on an on-demand >>> >> >> basis and is therefore not optimized for processing in hardware. >>> >> >> >>> >> >> Whether addresses or identifiers, if we are talking about >>> >> >> TLV contents, there are issues with trying to guarantee location >>> >> >> of specific content, because of the fact that the TLV in question >>> >> >> will probably follow other TLVs - thus making locations difficult >>> >> >> to predict in any case. >>> >> >> >>> >> >> With regard to needing more text on per-interface MIPs, do >>> >> >> you have specific suggestions as to what text we might add? >>> >> >> >>> >> >> I understand (from discussion with WG chairs) that we are >>> >> >> not allowed to explicitly address last call comments during the >>> >> >> IETF meeting in Prague, because the last call is still ongoing >>> >> >> at that time. >>> >> >> >>> >> >> -- >>> >> >> Eric >>> >> >> >>> >> >> PS - >>> >> >> From RFC 2119 - >>> >> >> 'SHOULD This word, or the adjective "RECOMMENDED", mean that th= ere >>> >> >> may exist valid reasons in particular circumstances to >>> >> >> ignore a particular item, but the full implications mus= t >>> >> >> be understood and carefully weighed before choosing a >>> >> >> different course.' >>> >> >> >>> >> >> -----Original Message----- >>> >> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>> Behalf >>> >> Of >>> >> >> Rolf Winter >>> >> >> Sent: Tuesday, March 22, 2011 4:57 AM >>> >> >> To: loa@pi.nu; mpls@ietf.org >>> >> >> Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-= on- >>> >> >> demand-cv-03 >>> >> >> >>> >> >> Hi, >>> >> >> >>> >> >> some comments below: >>> >> >> >>> >> >> Section 1.3 says: " In certain MPLS-TP deployment scenarios IP >>> >> >> addressing might not be >>> >> >> available or it may be preferred to use some form of non-IP >>> >> >> encapsulation for On-demand CV, route tracing and BFD packets. >>> >> In >>> >> >> such scenarios, On-demand CV and/or route tracing SHOULD be ru= n >>> >> >> without IP addressing..." >>> >> >> >>> >> >> I am not sure the "SHOULD" is right here. If no IP addressing is >>> >> >> available, this thing MUST be run without IP addressing, mustn't = it? >>> >> >> >>> >> >> I think some additional text regarding per-interface MIP addressi= ng >>> >> >> would be nice. As far as I understand the document, all TLVs will= be >>> >> >> inside the LSP ping packet (rather than as ACH TLVs). >>> >> >> >>> >> >> Some people had concerns earlier, that addressing information sho= uld >>> >> be >>> >> >> in a fixed location for easier processing. Is this the case here = I >>> >> >> wonder? >>> >> >> >>> >> >> It would be nice if you could address this in your presentation i= n >>> >> >> Prague. >>> >> >> >>> >> >> Thanks, >>> >> >> >>> >> >> Rolf >>> >> >> >>> >> >> >>> >> >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Roa= d, >>> >> >> London W3 6BL | Registered in England 2832014 >>> >> >> >>> >> >> >>> >> >> > -----Original Message----- >>> >> >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>> >> Behalf >>> >> >> Of >>> >> >> > loa@pi.nu >>> >> >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26 >>> >> >> > To: mpls@ietf.org >>> >> >> > Cc: MPLS-TP ad hoc team >>> >> >> > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on= - >>> >> >> demand- >>> >> >> > cv-03 >>> >> >> > >>> >> >> > Working Group, >>> >> >> > >>> >> >> > this is to start a 3 week working group last call on >>> >> >> > >>> >> >> > draft-ietf-mpls-tp-on-demand-cv-03 >>> >> >> > >>> >> >> > Please send comments to the working group mailing list >>> >> >> > mpls@ietf.org >>> >> >> > >>> >> >> > The working group last call ends on April 8, 2011. >>> >> >> > >>> >> >> > /Loa >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > _______________________________________________ >>> >> >> > mpls mailing list >>> >> >> > mpls@ietf.org >>> >> >> > https://www.ietf.org/mailman/listinfo/mpls >>> >> >> _______________________________________________ >>> >> >> mpls mailing list >>> >> >> mpls@ietf.org >>> >> >> https://www.ietf.org/mailman/listinfo/mpls >>> >> >_______________________________________________ >>> >> >mpls mailing list >>> >> >mpls@ietf.org >>> >> >https://www.ietf.org/mailman/listinfo/mpls >>> >> > >>> > >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > From eric.gray@ericsson.com Tue Mar 29 01:02:18 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2BE53A6ACF for ; Tue, 29 Mar 2011 01:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.632 X-Spam-Level: X-Spam-Status: No, score=-5.632 tagged_above=-999 required=5 tests=[AWL=0.967, 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 KpMHJHnyIlXJ for ; Tue, 29 Mar 2011 01:02:17 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 14F2A3A69FC for ; Tue, 29 Mar 2011 01:02:17 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2T83pc0027134; Tue, 29 Mar 2011 03:03:52 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 29 Mar 2011 04:03:45 -0400 From: Eric Gray To: Rolf Winter , Sami Boutros , "hideki.endo.es@hitachi.com" Date: Tue, 29 Mar 2011 04:03:44 -0400 Thread-Topic: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-demand-cv-03 Thread-Index: AQHL7YdjG4j++77GG0yKCjb8Qx0mppRD6CgQgAAKXYA= Message-ID: References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E177AF@Polydeuces.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05E177AF@Polydeuces.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 08:02:18 -0000 Rolf, There is no case here to support your argument that TTL is always only decremented by one. We should discuss this (as has=20 been proposed), however - if you read the Routing Requirements=20 RFC (RFC 1812) - you will find that the actual requirement is for=20 a "forwarder" to decrement TTL "by at least one." I can think of several scenarios where a single forwarder might be configured to decrement TTL by more than one for some set of packets. -- Eric -----Original Message----- From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 Sent: Tuesday, March 29, 2011 3:25 AM To: Sami Boutros; hideki.endo.es@hitachi.com; Eric Gray Cc: mpls@ietf.org Subject: RE: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-demand-c= v-03 Importance: High Hi Sami, see inline. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 >=20 > Keep in mind that a node decrement TTL once, and > this per-interface MIP seems to require a node to decrement twice.. >=20 > Thanks, >=20 I don't think this is a good idea. This is not how the TTL works today. I t= hink this is very unwise and touching a pretty fundamental principle here. = FWIW, we have proposed an alternative and presented it the last IETF. Unfor= tunately, we have received little feedback on it. But I think the discussio= n we have right now is good and not too late. The OAM framework document in= cludes per-interface MIPs and I think the group needs to start thinking har= d now to make sure this is thought about before we finish off all these OAM= tools. This way we do not need to come back later and change things. I don= 't think it will be overly hard, we just need to agree on something. Best, Rolf From Rolf.Winter@neclab.eu Tue Mar 29 01:04:04 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD01C3A6A83 for ; Tue, 29 Mar 2011 01:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.111 X-Spam-Level: X-Spam-Status: No, score=-102.111 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 IbaDKeSvFPgx for ; Tue, 29 Mar 2011 01:04:03 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 521E73A6A73 for ; Tue, 29 Mar 2011 01:04:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1E3C32C0002E9; Tue, 29 Mar 2011 10:08:18 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDy8twTcBi90; Tue, 29 Mar 2011 10:08:18 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id EBA932C0002E7; Tue, 29 Mar 2011 10:07:52 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.246]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Tue, 29 Mar 2011 10:01:46 +0200 From: Rolf Winter To: Sami Boutros , "hideki.endo.es@hitachi.com" , "gregimirsky@gmail.com" Thread-Topic: Re[2]: [mpls] Working Group Las Cal londraft-ietf-mpls-tp- on-demand-cv-03 Thread-Index: AQHL7eYz2/0WNVUweE+rqKbfCiYpNJRD8PVw Date: Tue, 29 Mar 2011 08:01:45 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05E178CE@Polydeuces.office.hd> References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.198] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Working Group Las Cal londraft-ietf-mpls-tp- on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 08:04:04 -0000 Sami, yes and no. So far you define an ID inside the OAM message. The draft we re= fer to does something else. So if things evolve strictly separately, in the= best case we have the same ID twice in a packet. In the worst case, we wil= l run into something that will at some point resemble the VCCV type discuss= ion earlier this week. Again, I don't think it is hard, we just need to agr= ee on something. I'd also like to point out that the underlying issue is wi= der than the on-demand-cv draft really. Any OAM that need to interact with = MIPs needs to address the same issue. So if we could get a wider set of peo= ple into this discussion an move forward, that would be really helpful.=20 Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Sami Boutros [mailto:sboutros@cisco.com] > Sent: Dienstag, 29. M=E4rz 2011 09:52 > To: hideki.endo.es@hitachi.com; gregimirsky@gmail.com > Cc: eric.gray@ericsson.com; Rolf Winter; mpls@ietf.org > Subject: Re[2]: [mpls] Working Group Las Cal londraft-ietf-mpls-tp- on- > demand-cv-03 >=20 > Agreed folks, >=20 > The solution options you propose on the draft > would work and will be transparent to the > on-demand-cv draft. >=20 > Thanks, >=20 > Sami > At 12:33 AM 3/29/2011, hideki.endo.es@hitachi.com wrote: > >Hi Sami, > > > >I don't think that the per-interface MIP > >requires a node to decrement TTL twice. > >I have proposed draft-mip-mep-map to avoid twice decrement of TTL. > >However, we, authers, don't push specific > >solution for per-interface MIP at this point, > >which presented by Rolf at previous meeting at Beijing. > > > >We have several options to identify > >per-interface MIP without twice decrement of TTL; > >(1)MIP ID in ACH-TLV > >(2)MIP ID in Ping address TLV > >(3)OML > >(4)GAL TTL(I proposed before, but now removed from our draft) > > > >We can discuss the best solution in this meeting. > > > >BR, > >Hideki > > > > > > >Hi Sami, > > >alternative to decrementing TTL for out-MIP approach, to use > reserved > > >Outgoing MIP Label (OML), presented in draft-farrel-mpls-tp-mip-mep- > map-03. > > >Considering that few proposed MPLS-TP OAM mechanisms use ACH TLV > Header per > > >RFC 5586 OML might be the better solution to address out-MIP. > > > > > >Regards, > > >Greg > > > > > >On Mon, Mar 28, 2011 at 1:33 PM, Sami Boutros > wrote: > > > > > >> At 06:43 AM 3/28/2011, hideki.endo.es@hitachi.com wrote: > > >> > > >>> Hi Eric, > > >>> > > >>> What I'd like to say was explaned by Rolf. > > >>> My concern is whether the OAM packet is fate sharing with user > packet or > > >>> NOT. > > >>> If draft-on-demand-cv doesn't care anything for fate sharing > > >>> in the case of per-interface MIP, > > >>> the per-interface MIP can NOT be implemented by HW reasonably. > > >>> > > >> > > >> Keep in mind that a node decrement TTL once, and this per- > interface MIP > > >> seems to require a node to decrement twice.. > > >> > > >> Thanks, > > >> > > >> Sami > > >> > > >> > > >> BR, > > >>> Hideki > > >>> > > >>> >Eric, > > >>> > > > >>> >I generally agree but I think there is one case actually which > needs a > > >>> closer look in this regard (which I hinted at earlier), which are > the > > >>> per-interface MIPs. Your TTL expires (the > > actual addressing bit here), the > > >>> identifier tells you it is not intended for > > the ingress MIP, so it needs to > > >>> be forwarded to the egress MIP through the forwarding engine. Now > if you > > >>> pull the packet out of the fast path and inject it back in, is > the OAM > > >>> packet still fate sharing? If you can do > > this in HW on the line card, then > > >>> it will and it will just be forwarded as > > normal. I know this is a different > > >>> draft, but this will be in particular > > important for performance monitoring. > > >>> > > > >>> >Best, > > >>> > > > >>> >Rolf > > >>> > > > >>> > > > >>> > > > >>> >NEC Europe Limited | Registered Office: NEC House, 1 Victoria > Road, > > >>> London W3 6BL | Registered in England 2832014 > > >>> > > > >>> > > > >>> >> -----Original Message----- > > >>> >> From: Eric Gray [mailto:eric.gray@ericsson.com] > > >>> >> Sent: Montag, 28. M=E4rz 2011 14:45 > > >>> >> To: hideki.endo.es@hitachi.com; Rolf Winter > > >>> >> Cc: mpls@ietf.org > > >>> >> Subject: RE: Re[2]: [mpls] Working Group > > Las Call ondraft-ietf-mpls-tp- > > >>> >> on-demand-cv-03 > > >>> >> > > >>> >> Hideki, > > >>> >> > > >>> >> What you're saying is true, but not relevant in this > > >>> >> case. The "addresses" in this discussion are not used to > > >>> >> determine how to forward OAM packets. They are used only > > >>> >> by the recipient MIP/MEP to verify that the OAM packet was > > >>> >> properly delivered. > > >>> >> > > >>> >> By the way, this discussion is an indication of the > > >>> >> confusing injected by calling these things addresses. My > > >>> >> mistake and I bring it up now to help to stem the tide of > > >>> >> further comments resulting from that confusion. > > >>> >> > > >>> >> In the version we post after last call is complete, > > >>> >> we will be changing the source and destination "address" > > >>> >> TLVs to source and destination "identifier" TLVs. > > >>> >> > > >>> >> We will also be correcting the reference to DSMAP, > > >>> >> and DDMAP, address TLVs (which is incorrect, because the > > >>> >> format for DSMAP/DDMAP doesn't include a "length" field). > > >>> >> > > >>> >> The format of the Downstream Mapping (DSMAP) TLV is > > >>> >> defined in RFC 4379, and we are not changing the format > > >>> >> of that TLV. > > >>> >> > > >>> >> These changes are driven by last call comments we > > >>> >> have already received (see Joel Halpern's comments on the > > >>> >> mailing list) and are - in part - to correct accidental > > >>> >> use of the word "address" for source and destination > > >>> >> identifier TLVs (which is what we had discussed before > > >>> >> I generated the -03 version among the authors of several > > >>> >> of the current set of MPLS-TP drafts). > > >>> >> > > >>> >> In the case of source and destination identifiers, > > >>> >> these will be used exclusively to verify that an OAM PDU > > >>> >> has been correctly received by its intended recipient. > > >>> >> Because this is an on-demand connectivity verification > > >>> >> protocol, that is expected to be used only on those > > >>> >> occasions when there is a network problem that needs to > > >>> >> be diagnosed, and the information is not seen (and not > > >>> >> visible - without layer violations), optimizing these > > >>> >> objects for software makes sense. > > >>> >> > > >>> >> In addition, since either may be included (which > > >>> >> includes the possibility of including both), it is the > > >>> >> case already that we would then need to decide which is > > >>> >> to go first - assuming we wanted to do this (which we > > >>> >> do not). > > >>> >> > > >>> >> -- > > >>> >> Eric > > >>> >> > > >>> >> -----Original Message----- > > >>> >> From: hideki.endo.es@hitachi.com > [mailto:hideki.endo.es@hitachi.com] > > >>> >> Sent: Monday, March 28, 2011 8:11 AM > > >>> >> To: Eric Gray; Rolf.Winter@neclab.eu > > >>> >> Cc: mpls@ietf.org > > >>> >> Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf- > mpls-tp-on- > > >>> >> demand-cv-03 > > >>> >> Importance: High > > >>> >> > > >>> >> Hi Eric and Rolf, > > >>> >> > > >>> >> I'm sorry for interrupting. > > >>> >> > > >>> >> I agree with Rolf regarding the per-interface MIP discussion. > > >>> >> We have to consider the HW implementation aspect, > > >>> >> because trapping of an OAM packet is HW rule/functionality > even in > > >>> >> routers. > > >>> >> > > >>> >> If every OAM packet is trapped to CPU > > >>> >> and the OAM packets which should NOT be processed in the > Interface > > >>> >> are returned to Data-plane, > > >>> >> it is different forwarding path from user packets, > > >>> >> which is NOT the Connectivity Verification of the user path. > > >>> >> > > >>> >> Therefore, we should take the HW aspect and flexibilty into > account > > >>> >> concurrently. > > >>> >> If an address TLV MUST be the first in TLVs, > > >>> >> it is enough to make HW implementation easy. > > >>> >> > > >>> >> BR, > > >>> >> Hideki > > >>> >> > > >>> >> > > >>> >> > > >>> >> >Rolf, > > >>> >> > > > >>> >> > The words you propose are okay with me. > > >>> >> > > > >>> >> > I thought the MIP/interface and address location issues > > >>> >> >were separate. > > >>> >> > > > >>> >> > I've personally had problems with protocol specifications > > >>> >> >that require ordering of TLVs. In particular, this is not > very > > >>> >> >robust in terms of "future-proofing." What happens if new > TLVs > > >>> >> >are added later on; for instance, suppose at some point we > have > > >>> >> >multiple "address" TLVs? > > >>> >> > > > >>> >> > Also, the fact that implementations are allowed to attach > > >>> >> >TLVs in any arbitrary order allows considerable flexibilty in > > >>> >> >implementation. Messages can be built in arbitrarily many > ways. > > >>> >> >This too can be a future-proofing issue. > > >>> >> > > > >>> >> > I would prefer not to start down the road of requiring a > > >>> >> >subset of TLVs to appear in a certain order, and saying we > have > > >>> >> >one TLV that needs to be first is doing just that. > > >>> >> > > > >>> >> >-- > > >>> >> >Eric > > >>> >> > > > >>> >> >-----Original Message----- > > >>> >> >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > > >>> >> >Sent: Monday, March 28, 2011 6:19 AM > > >>> >> >To: Eric Gray > > >>> >> >Cc: mpls@ietf.org > > >>> >> >Subject: RE: [mpls] Working Group Las Call on draft-ietf- > mpls-tp-on- > > >>> >> demand-cv-03 > > >>> >> >Importance: High > > >>> >> > > > >>> >> >Hi, > > >>> >> > > > >>> >> >I still think there is a logical error. Let me explain. In > case there > > >>> >> is no IP you simply cannot use it. You > > say you could enable IP but then > > >>> >> that is not a case where there is no IP. In order to be > constructive > > >>> >> here is a text change suggestion: > > >>> >> > > > >>> >> >"In certain MPLS-TP deployment scenarios IP addressing might > not be > > >>> >> available. In those cases On-demand CV > > and/or route tracing MUST be run > > >>> >> without IP addressing, using the ACH channel type specified in > Section > > >>> >> 3. In other cases it might be available, however, it may be > preferred > > >>> >> to use some form of non-IP encapsulation. In those cases, the > > >>> >> procedures as outlined in section 3 SHOULD also be used." > > >>> >> > > > >>> >> >Regarding the per-interface MIP discussion. The HW aspect > also popped > > >>> >> up in the PWE3 session and I think this is an important > consideration, > > >>> >> in particular for OAM. Even if we talk about TLVs, we could > make it a > > >>> >> MUST that an Address TLV is always the first one to appear. If > you can > > >>> >> facilitate an easy implementation in hardware, I see no reason > to > > >>> >> deliberately not do it. > > >>> >> > > > >>> >> >Best, > > >>> >> > > > >>> >> >Rolf > > >>> >> > > > >>> >> > > > >>> >> >NEC Europe Limited | Registered Office: NEC House, 1 Victoria > Road, > > >>> >> London W3 6BL | Registered in England 2832014 > > >>> >> > > > >>> >> > > > >>> >> >> -----Original Message----- > > >>> >> >> From: Eric Gray [mailto:eric.gray@ericsson.com] > > >>> >> >> Sent: Montag, 28. M=E4rz 2011 11:43 > > >>> >> >> To: Rolf Winter > > >>> >> >> Cc: loa@pi.nu; mpls@ietf.org > > >>> >> >> Subject: RE: [mpls] Working Group Las > > Call on draft-ietf-mpls-tp-on- > > >>> >> >> demand-cv-03 > > >>> >> >> > > >>> >> >> Rolf, > > >>> >> >> > > >>> >> >> With regard to the use of SHOULD (verses MUST) - the > intent > > >>> >> >> (according to RFC 2119 - see the quote below) is consistent > with > > >>> >> >> this case. If - for some reason - one had a really good > reason to > > >>> >> >> use IP addressing in some specific case, one could take > steps to > > >>> >> >> make IP addressing available. > > >>> >> >> > > >>> >> >> This could be said to introduce a logical disconnect, but > we > > >>> >> >> are saved from going down that path by the fact that the > statement > > >>> >> >> also includes the case where (for some reason) there is a > case in > > >>> >> >> which some other addressing scheme might be preferred. In > many of > > >>> >> >> the cases where another addressing scheme may be preferred, > it is > > >>> >> >> still possible (in fact likely) that IP addressing is > available. > > >>> >> >> > > >>> >> >> Otherwise, it would not have been necessary to > distinguish > > >>> >> >> this case from the one in which IP addressing is not > available. > > >>> >> >> > > >>> >> >> For the case where IP addressing is not the preferred > mode, > > >>> >> >> we are recommending a mode in which it is not necessary. > > >>> >> >> > > >>> >> >> With regard to having addresses located in the same place, > > >>> >> >> this protocol is meant for connectivity testing on an on- > demand > > >>> >> >> basis and is therefore not optimized for processing in > hardware. > > >>> >> >> > > >>> >> >> Whether addresses or identifiers, if we are talking about > > >>> >> >> TLV contents, there are issues with trying to guarantee > location > > >>> >> >> of specific content, because of the fact that the TLV in > question > > >>> >> >> will probably follow other TLVs - thus making locations > difficult > > >>> >> >> to predict in any case. > > >>> >> >> > > >>> >> >> With regard to needing more text on per-interface MIPs, > do > > >>> >> >> you have specific suggestions as to what text we might add? > > >>> >> >> > > >>> >> >> I understand (from discussion with WG chairs) that we are > > >>> >> >> not allowed to explicitly address last call comments during > the > > >>> >> >> IETF meeting in Prague, because the last call is still > ongoing > > >>> >> >> at that time. > > >>> >> >> > > >>> >> >> -- > > >>> >> >> Eric > > >>> >> >> > > >>> >> >> PS - > > >>> >> >> From RFC 2119 - > > >>> >> >> 'SHOULD This word, or the adjective > > "RECOMMENDED", mean that there > > >>> >> >> may exist valid reasons in particular > circumstances to > > >>> >> >> ignore a particular item, but the full > implications must > > >>> >> >> be understood and carefully weighed before > choosing a > > >>> >> >> different course.' > > >>> >> >> > > >>> >> >> -----Original Message----- > > >>> >> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On > > >>> Behalf > > >>> >> Of > > >>> >> >> Rolf Winter > > >>> >> >> Sent: Tuesday, March 22, 2011 4:57 AM > > >>> >> >> To: loa@pi.nu; mpls@ietf.org > > >>> >> >> Subject: Re: [mpls] Working Group Las > > Call on draft-ietf-mpls-tp-on- > > >>> >> >> demand-cv-03 > > >>> >> >> > > >>> >> >> Hi, > > >>> >> >> > > >>> >> >> some comments below: > > >>> >> >> > > >>> >> >> Section 1.3 says: " In certain MPLS-TP deployment scenarios > IP > > >>> >> >> addressing might not be > > >>> >> >> available or it may be preferred to use some form of > non-IP > > >>> >> >> encapsulation for On-demand CV, route tracing and BFD > packets. > > >>> >> In > > >>> >> >> such scenarios, On-demand CV and/or route tracing SHOULD > be run > > >>> >> >> without IP addressing..." > > >>> >> >> > > >>> >> >> I am not sure the "SHOULD" is right here. If no IP > addressing is > > >>> >> >> available, this thing MUST be run > > without IP addressing, mustn't it? > > >>> >> >> > > >>> >> >> I think some additional text regarding per-interface MIP > addressing > > >>> >> >> would be nice. As far as I understand > > the document, all TLVs will be > > >>> >> >> inside the LSP ping packet (rather than as ACH TLVs). > > >>> >> >> > > >>> >> >> Some people had concerns earlier, > > that addressing information should > > >>> >> be > > >>> >> >> in a fixed location for easier processing. Is this the case > here I > > >>> >> >> wonder? > > >>> >> >> > > >>> >> >> It would be nice if you could address this in your > presentation in > > >>> >> >> Prague. > > >>> >> >> > > >>> >> >> Thanks, > > >>> >> >> > > >>> >> >> Rolf > > >>> >> >> > > >>> >> >> > > >>> >> >> NEC Europe Limited | Registered Office: NEC House, 1 > Victoria Road, > > >>> >> >> London W3 6BL | Registered in England 2832014 > > >>> >> >> > > >>> >> >> > > >>> >> >> > -----Original Message----- > > >>> >> >> > From: mpls-bounces@ietf.org [mailto:mpls- > bounces@ietf.org] On > > >>> >> Behalf > > >>> >> >> Of > > >>> >> >> > loa@pi.nu > > >>> >> >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26 > > >>> >> >> > To: mpls@ietf.org > > >>> >> >> > Cc: MPLS-TP ad hoc team > > >>> >> >> > Subject: [mpls] Working Group Las Call on draft-ietf- > mpls-tp-on- > > >>> >> >> demand- > > >>> >> >> > cv-03 > > >>> >> >> > > > >>> >> >> > Working Group, > > >>> >> >> > > > >>> >> >> > this is to start a 3 week working group last call on > > >>> >> >> > > > >>> >> >> > draft-ietf-mpls-tp-on-demand-cv-03 > > >>> >> >> > > > >>> >> >> > Please send comments to the working group mailing list > > >>> >> >> > mpls@ietf.org > > >>> >> >> > > > >>> >> >> > The working group last call ends on April 8, 2011. > > >>> >> >> > > > >>> >> >> > /Loa > > >>> >> >> > > > >>> >> >> > > > >>> >> >> > > > >>> >> >> > > > >>> >> >> > _______________________________________________ > > >>> >> >> > mpls mailing list > > >>> >> >> > mpls@ietf.org > > >>> >> >> > https://www.ietf.org/mailman/listinfo/mpls > > >>> >> >> _______________________________________________ > > >>> >> >> mpls mailing list > > >>> >> >> mpls@ietf.org > > >>> >> >> https://www.ietf.org/mailman/listinfo/mpls > > >>> >> >_______________________________________________ > > >>> >> >mpls mailing list > > >>> >> >mpls@ietf.org > > >>> >> >https://www.ietf.org/mailman/listinfo/mpls > > >>> >> > > > >>> > > > >>> _______________________________________________ > > >>> mpls mailing list > > >>> mpls@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mpls > > >>> > > >> > > >> > > >> _______________________________________________ > > >> mpls mailing list > > >> mpls@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mpls > > >> > > > >=20 From hideki.endo.es@hitachi.com Tue Mar 29 01:10:50 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A5FE3A68C1 for ; Tue, 29 Mar 2011 01:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.837 X-Spam-Level: **** X-Spam-Status: No, score=4.837 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_31=0.6, MIME_BASE64_TEXT=1.753, SUBJ_RE_NUM=2.799] 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 NqZ+Yc4qVg-9 for ; Tue, 29 Mar 2011 01:10:48 -0700 (PDT) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by core3.amsl.com (Postfix) with ESMTP id B44763A697A for ; Tue, 29 Mar 2011 01:10:47 -0700 (PDT) Received: from mlsv5.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 96E3037AC6; Tue, 29 Mar 2011 17:12:25 +0900 (JST) Received: from mfilter1.hitachi.co.jp by mlsv5.hitachi.co.jp (8.13.1/8.13.1) id p2T8CP6u007246; Tue, 29 Mar 2011 17:12:25 +0900 Received: from hitachi.com (localhost.localdomain [127.0.0.1]) by mfilter1.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id p2T8C93r000302; Tue, 29 Mar 2011 17:12:25 +0900 Received: from vshuts2.hitachi.co.jp ([vshuts2.hitachi.co.jp [10.201.6.71]]) by mfilter1.hitachi.co.jp with RELAY id p2T8COuI000532 ; Tue, 29 Mar 2011 17:12:25 +0900 X-AuditID: b753bd60-a274aba0000001d0-d9-4d91946865a1 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id 17B1F8B02E4; Tue, 29 Mar 2011 17:12:24 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p2T8COq11579406; Tue, 29 Mar 2011 17:12:24 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: multipart/mixed; boundary="GMAILSMTPBOUND01110329171220" To: From: Date: Tue, 29 Mar 2011 17:12:10 +0900 References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> Priority: normal Importance: normal X400-Content-Identifier: X4D91944100000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28110329171145UX2] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Rolf.Winter@neclab.eu, sboutros@cisco.com, mpls@ietf.org Subject: Re: [mpls] =?iso-8859-1?q?Working_Group_Las_Callondraft-ietf-mpls-tp-?= =?iso-8859-1?q?on-demand-cv-03?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 08:10:50 -0000 --GMAILSMTPBOUND01110329171220 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 RXJpYywNCg0KSSdtIHNvcnJ5LCB3ZSBkb24ndCByZWZlciB0byBzcGVjaWZpYyBtZWV0aW5n IGF0IHRoaXMgcG9pbnQuDQpDb3JyZWN0bHksDQppZiB3ZSBoYXZlIGEgbWVldGluZyBpbiB0 aGlzIHdlZWssDQp3ZSBjYW4gZGlzY3VzcyB3aGF0IHRoZSBiZXN0IHNvbHV0aW9uIGlzLg0K DQpMZXQncyBzY2hlZHVsZSB0aGUgbWVldGluZy4NCg0KQlIsDQpIaWRla2kNCg0KPldoaWNo IG1lZXRpbmcgYXJlIHlvdSByZWZlcnJpbmcgdG8/DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj5Gcm9tOiBoaWRla2kuZW5kby5lc0BoaXRhY2hpLmNvbSBbbWFpbHRvOmhp ZGVraS5lbmRvLmVzQGhpdGFjaGkuY29tXQ0KPlNlbnQ6IFR1ZXNkYXksIE1hcmNoIDI5LCAy MDExIDM6MzMgQU0NCj5UbzogZ3JlZ2ltaXJza3lAZ21haWwuY29tOyBzYm91dHJvc0BjaXNj by5jb20NCj5DYzogRXJpYyBHcmF5OyBSb2xmLldpbnRlckBuZWNsYWIuZXU7IG1wbHNAaWV0 Zi5vcmcNCj5TdWJqZWN0OiBSZVsyXTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENhbGxv bmRyYWZ0LWlldGYtbXBscy10cC0gb24tZGVtYW5kLWN2LTAzDQo+DQo+SGkgU2FtaSwNCj4N Cj5JIGRvbid0IHRoaW5rIHRoYXQgdGhlIHBlci1pbnRlcmZhY2UgTUlQIHJlcXVpcmVzIGEg bm9kZSB0byBkZWNyZW1lbnQgVFRMIHR3aWNlLg0KPkkgaGF2ZSBwcm9wb3NlZCBkcmFmdC1t aXAtbWVwLW1hcCB0byBhdm9pZCB0d2ljZSBkZWNyZW1lbnQgb2YgVFRMLg0KPkhvd2V2ZXIs IHdlLCBhdXRoZXJzLCBkb24ndCBwdXNoIHNwZWNpZmljIHNvbHV0aW9uIGZvciBwZXItaW50 ZXJmYWNlIE1JUCBhdCB0aGlzIHBvaW50LA0KPndoaWNoIHByZXNlbnRlZCBieSBSb2xmIGF0 IHByZXZpb3VzIG1lZXRpbmcgYXQgQmVpamluZy4NCj4NCj5XZSBoYXZlIHNldmVyYWwgb3B0 aW9ucyB0byBpZGVudGlmeSBwZXItaW50ZXJmYWNlIE1JUCB3aXRob3V0IHR3aWNlIGRlY3Jl bWVudCBvZiBUVEw7DQo+KDEpTUlQIElEIGluIEFDSC1UTFYNCj4oMilNSVAgSUQgaW4gUGlu ZyBhZGRyZXNzIFRMVg0KPigzKU9NTA0KPig0KUdBTCBUVEwoSSBwcm9wb3NlZCBiZWZvcmUs IGJ1dCBub3cgcmVtb3ZlZCBmcm9tIG91ciBkcmFmdCkNCj4NCj5XZSBjYW4gZGlzY3VzcyB0 aGUgYmVzdCBzb2x1dGlvbiBpbiB0aGlzIG1lZXRpbmcuDQo+DQo+QlIsDQo+SGlkZWtpDQo+ DQo+DQo+PkhpIFNhbWksDQo+PmFsdGVybmF0aXZlIHRvIGRlY3JlbWVudGluZyBUVEwgZm9y IG91dC1NSVAgYXBwcm9hY2gsIHRvIHVzZSByZXNlcnZlZA0KPj5PdXRnb2luZyBNSVAgTGFi ZWwgKE9NTCksIHByZXNlbnRlZCBpbiBkcmFmdC1mYXJyZWwtbXBscy10cC1taXAtbWVwLW1h cC0wMy4NCj4+Q29uc2lkZXJpbmcgdGhhdCBmZXcgcHJvcG9zZWQgTVBMUy1UUCBPQU0gbWVj aGFuaXNtcyB1c2UgQUNIIFRMViBIZWFkZXIgcGVyDQo+PlJGQyA1NTg2IE9NTCBtaWdodCBi ZSB0aGUgYmV0dGVyIHNvbHV0aW9uIHRvIGFkZHJlc3Mgb3V0LU1JUC4NCj4+DQo+PlJlZ2Fy ZHMsDQo+PkdyZWcNCj4+DQo+Pk9uIE1vbiwgTWFyIDI4LCAyMDExIGF0IDE6MzMgUE0sIFNh bWkgQm91dHJvcyA8c2JvdXRyb3NAY2lzY28uY29tPiB3cm90ZToNCj4+DQo+Pj4gQXQgMDY6 NDMgQU0gMy8yOC8yMDExLCBoaWRla2kuZW5kby5lc0BoaXRhY2hpLmNvbSB3cm90ZToNCj4+ Pg0KPj4+PiBIaSBFcmljLA0KPj4+Pg0KPj4+PiBXaGF0IEknZCBsaWtlIHRvIHNheSB3YXMg ZXhwbGFuZWQgYnkgUm9sZi4NCj4+Pj4gTXkgY29uY2VybiBpcyB3aGV0aGVyIHRoZSBPQU0g cGFja2V0IGlzIGZhdGUgc2hhcmluZyB3aXRoIHVzZXIgcGFja2V0IG9yDQo+Pj4+IE5PVC4N Cj4+Pj4gSWYgZHJhZnQtb24tZGVtYW5kLWN2IGRvZXNuJ3QgY2FyZSBhbnl0aGluZyBmb3Ig ZmF0ZSBzaGFyaW5nDQo+Pj4+IGluIHRoZSBjYXNlIG9mIHBlci1pbnRlcmZhY2UgTUlQLA0K Pj4+PiB0aGUgcGVyLWludGVyZmFjZSBNSVAgY2FuIE5PVCBiZSBpbXBsZW1lbnRlZCBieSBI VyByZWFzb25hYmx5Lg0KPj4+Pg0KPj4+DQo+Pj4gS2VlcCBpbiBtaW5kIHRoYXQgYSBub2Rl IGRlY3JlbWVudCBUVEwgb25jZSwgYW5kIHRoaXMgcGVyLWludGVyZmFjZSBNSVANCj4+PiBz ZWVtcyB0byByZXF1aXJlIGEgbm9kZSB0byBkZWNyZW1lbnQgdHdpY2UuLg0KPj4+DQo+Pj4g VGhhbmtzLA0KPj4+DQo+Pj4gU2FtaQ0KPj4+DQo+Pj4NCj4+PiAgQlIsDQo+Pj4+IEhpZGVr aQ0KPj4+Pg0KPj4+PiA+RXJpYywNCj4+Pj4gPg0KPj4+PiA+SSBnZW5lcmFsbHkgYWdyZWUg YnV0IEkgdGhpbmsgdGhlcmUgaXMgb25lIGNhc2UgYWN0dWFsbHkgd2hpY2ggbmVlZHMgYQ0K Pj4+PiBjbG9zZXIgbG9vayBpbiB0aGlzIHJlZ2FyZCAod2hpY2ggSSBoaW50ZWQgYXQgZWFy bGllciksIHdoaWNoIGFyZSB0aGUNCj4+Pj4gcGVyLWludGVyZmFjZSBNSVBzLiBZb3VyIFRU TCBleHBpcmVzICh0aGUgYWN0dWFsIGFkZHJlc3NpbmcgYml0IGhlcmUpLCB0aGUNCj4+Pj4g aWRlbnRpZmllciB0ZWxscyB5b3UgaXQgaXMgbm90IGludGVuZGVkIGZvciB0aGUgaW5ncmVz cyBNSVAsIHNvIGl0IG5lZWRzIHRvDQo+Pj4+IGJlIGZvcndhcmRlZCB0byB0aGUgZWdyZXNz IE1JUCB0aHJvdWdoIHRoZSBmb3J3YXJkaW5nIGVuZ2luZS4gTm93IGlmIHlvdQ0KPj4+PiBw dWxsIHRoZSBwYWNrZXQgb3V0IG9mIHRoZSBmYXN0IHBhdGggYW5kIGluamVjdCBpdCBiYWNr IGluLCBpcyB0aGUgT0FNDQo+Pj4+IHBhY2tldCBzdGlsbCBmYXRlIHNoYXJpbmc/IElmIHlv dSBjYW4gZG8gdGhpcyBpbiBIVyBvbiB0aGUgbGluZSBjYXJkLCB0aGVuDQo+Pj4+IGl0IHdp bGwgYW5kIGl0IHdpbGwganVzdCBiZSBmb3J3YXJkZWQgYXMgbm9ybWFsLiBJIGtub3cgdGhp cyBpcyBhIGRpZmZlcmVudA0KPj4+PiBkcmFmdCwgYnV0IHRoaXMgd2lsbCBiZSBpbiBwYXJ0 aWN1bGFyIGltcG9ydGFudCBmb3IgcGVyZm9ybWFuY2UgbW9uaXRvcmluZy4NCj4+Pj4gPg0K Pj4+PiA+QmVzdCwNCj4+Pj4gPg0KPj4+PiA+Um9sZg0KPj4+PiA+DQo+Pj4+ID4NCj4+Pj4g Pg0KPj4+PiA+TkVDIEV1cm9wZSBMaW1pdGVkIHwgUmVnaXN0ZXJlZCBPZmZpY2U6IE5FQyBI b3VzZSwgMSBWaWN0b3JpYSBSb2FkLA0KPj4+PiBMb25kb24gVzMgNkJMIHwgUmVnaXN0ZXJl ZCBpbiBFbmdsYW5kIDI4MzIwMTQNCj4+Pj4gPg0KPj4+PiA+DQo+Pj4+ID4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+ID4+IEZyb206IEVyaWMgR3JheSBbbWFpbHRvOmVy aWMuZ3JheUBlcmljc3Nvbi5jb21dDQo+Pj4+ID4+IFNlbnQ6IE1vbnRhZywgMjguIE3kcnog MjAxMSAxNDo0NQ0KPj4+PiA+PiBUbzogaGlkZWtpLmVuZG8uZXNAaGl0YWNoaS5jb207IFJv bGYgV2ludGVyDQo+Pj4+ID4+IENjOiBtcGxzQGlldGYub3JnDQo+Pj4+ID4+IFN1YmplY3Q6 IFJFOiBSZVsyXTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENhbGwgb25kcmFmdC1pZXRm LW1wbHMtdHAtDQo+Pj4+ID4+IG9uLWRlbWFuZC1jdi0wMw0KPj4+PiA+Pg0KPj4+PiA+PiBI aWRla2ksDQo+Pj4+ID4+DQo+Pj4+ID4+ICAgICAgV2hhdCB5b3UncmUgc2F5aW5nIGlzIHRy dWUsIGJ1dCBub3QgcmVsZXZhbnQgaW4gdGhpcw0KPj4+PiA+PiBjYXNlLiAgVGhlICJhZGRy ZXNzZXMiIGluIHRoaXMgZGlzY3Vzc2lvbiBhcmUgbm90IHVzZWQgdG8NCj4+Pj4gPj4gZGV0 ZXJtaW5lIGhvdyB0byBmb3J3YXJkIE9BTSBwYWNrZXRzLiAgVGhleSBhcmUgdXNlZCBvbmx5 DQo+Pj4+ID4+IGJ5IHRoZSByZWNpcGllbnQgTUlQL01FUCB0byB2ZXJpZnkgdGhhdCB0aGUg T0FNIHBhY2tldCB3YXMNCj4+Pj4gPj4gcHJvcGVybHkgZGVsaXZlcmVkLg0KPj4+PiA+Pg0K Pj4+PiA+PiAgICAgIEJ5IHRoZSB3YXksIHRoaXMgZGlzY3Vzc2lvbiBpcyBhbiBpbmRpY2F0 aW9uIG9mIHRoZQ0KPj4+PiA+PiBjb25mdXNpbmcgaW5qZWN0ZWQgYnkgY2FsbGluZyB0aGVz ZSB0aGluZ3MgYWRkcmVzc2VzLiAgTXkNCj4+Pj4gPj4gbWlzdGFrZSBhbmQgSSBicmluZyBp dCB1cCBub3cgdG8gaGVscCB0byBzdGVtIHRoZSB0aWRlIG9mDQo+Pj4+ID4+IGZ1cnRoZXIg Y29tbWVudHMgcmVzdWx0aW5nIGZyb20gdGhhdCBjb25mdXNpb24uDQo+Pj4+ID4+DQo+Pj4+ ID4+ICAgICAgSW4gdGhlIHZlcnNpb24gd2UgcG9zdCBhZnRlciBsYXN0IGNhbGwgaXMgY29t cGxldGUsDQo+Pj4+ID4+IHdlIHdpbGwgYmUgY2hhbmdpbmcgdGhlIHNvdXJjZSBhbmQgZGVz dGluYXRpb24gImFkZHJlc3MiDQo+Pj4+ID4+IFRMVnMgdG8gc291cmNlIGFuZCBkZXN0aW5h dGlvbiAiaWRlbnRpZmllciIgVExWcy4NCj4+Pj4gPj4NCj4+Pj4gPj4gICAgICBXZSB3aWxs IGFsc28gYmUgY29ycmVjdGluZyB0aGUgcmVmZXJlbmNlIHRvIERTTUFQLA0KPj4+PiA+PiBh bmQgRERNQVAsIGFkZHJlc3MgVExWcyAod2hpY2ggaXMgaW5jb3JyZWN0LCBiZWNhdXNlIHRo ZQ0KPj4+PiA+PiBmb3JtYXQgZm9yIERTTUFQL0RETUFQIGRvZXNuJ3QgaW5jbHVkZSBhICJs ZW5ndGgiIGZpZWxkKS4NCj4+Pj4gPj4NCj4+Pj4gPj4gICAgICBUaGUgZm9ybWF0IG9mIHRo ZSBEb3duc3RyZWFtIE1hcHBpbmcgKERTTUFQKSBUTFYgaXMNCj4+Pj4gPj4gZGVmaW5lZCBp biBSRkMgNDM3OSwgYW5kIHdlIGFyZSBub3QgY2hhbmdpbmcgdGhlIGZvcm1hdA0KPj4+PiA+ PiBvZiB0aGF0IFRMVi4NCj4+Pj4gPj4NCj4+Pj4gPj4gICAgICBUaGVzZSBjaGFuZ2VzIGFy ZSBkcml2ZW4gYnkgbGFzdCBjYWxsIGNvbW1lbnRzIHdlDQo+Pj4+ID4+IGhhdmUgYWxyZWFk eSByZWNlaXZlZCAoc2VlIEpvZWwgSGFscGVybidzIGNvbW1lbnRzIG9uIHRoZQ0KPj4+PiA+ PiBtYWlsaW5nIGxpc3QpIGFuZCBhcmUgLSBpbiBwYXJ0IC0gdG8gY29ycmVjdCBhY2NpZGVu dGFsDQo+Pj4+ID4+IHVzZSBvZiB0aGUgd29yZCAiYWRkcmVzcyIgZm9yIHNvdXJjZSBhbmQg ZGVzdGluYXRpb24NCj4+Pj4gPj4gaWRlbnRpZmllciBUTFZzICh3aGljaCBpcyB3aGF0IHdl IGhhZCBkaXNjdXNzZWQgYmVmb3JlDQo+Pj4+ID4+IEkgZ2VuZXJhdGVkIHRoZSAtMDMgdmVy c2lvbiBhbW9uZyB0aGUgYXV0aG9ycyBvZiBzZXZlcmFsDQo+Pj4+ID4+IG9mIHRoZSBjdXJy ZW50IHNldCBvZiBNUExTLVRQIGRyYWZ0cykuDQo+Pj4+ID4+DQo+Pj4+ID4+ICAgICAgSW4g dGhlIGNhc2Ugb2Ygc291cmNlIGFuZCBkZXN0aW5hdGlvbiBpZGVudGlmaWVycywNCj4+Pj4g Pj4gdGhlc2Ugd2lsbCBiZSB1c2VkIGV4Y2x1c2l2ZWx5IHRvIHZlcmlmeSB0aGF0IGFuIE9B TSBQRFUNCj4+Pj4gPj4gaGFzIGJlZW4gY29ycmVjdGx5IHJlY2VpdmVkIGJ5IGl0cyBpbnRl bmRlZCByZWNpcGllbnQuDQo+Pj4+ID4+IEJlY2F1c2UgdGhpcyBpcyBhbiBvbi1kZW1hbmQg Y29ubmVjdGl2aXR5IHZlcmlmaWNhdGlvbg0KPj4+PiA+PiBwcm90b2NvbCwgdGhhdCBpcyBl eHBlY3RlZCB0byBiZSB1c2VkIG9ubHkgb24gdGhvc2UNCj4+Pj4gPj4gb2NjYXNpb25zIHdo ZW4gdGhlcmUgaXMgYSBuZXR3b3JrIHByb2JsZW0gdGhhdCBuZWVkcyB0bw0KPj4+PiA+PiBi ZSBkaWFnbm9zZWQsIGFuZCB0aGUgaW5mb3JtYXRpb24gaXMgbm90IHNlZW4gKGFuZCBub3QN Cj4+Pj4gPj4gdmlzaWJsZSAtIHdpdGhvdXQgbGF5ZXIgdmlvbGF0aW9ucyksIG9wdGltaXpp bmcgdGhlc2UNCj4+Pj4gPj4gb2JqZWN0cyBmb3Igc29mdHdhcmUgbWFrZXMgc2Vuc2UuDQo+ Pj4+ID4+DQo+Pj4+ID4+ICAgICAgSW4gYWRkaXRpb24sIHNpbmNlIGVpdGhlciBtYXkgYmUg aW5jbHVkZWQgKHdoaWNoDQo+Pj4+ID4+IGluY2x1ZGVzIHRoZSBwb3NzaWJpbGl0eSBvZiBp bmNsdWRpbmcgYm90aCksIGl0IGlzIHRoZQ0KPj4+PiA+PiBjYXNlIGFscmVhZHkgdGhhdCB3 ZSB3b3VsZCB0aGVuIG5lZWQgdG8gZGVjaWRlIHdoaWNoIGlzDQo+Pj4+ID4+IHRvIGdvIGZp cnN0IC0gYXNzdW1pbmcgd2Ugd2FudGVkIHRvIGRvIHRoaXMgKHdoaWNoIHdlDQo+Pj4+ID4+ IGRvIG5vdCkuDQo+Pj4+ID4+DQo+Pj4+ID4+IC0tDQo+Pj4+ID4+IEVyaWMNCj4+Pj4gPj4N Cj4+Pj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gPj4gRnJvbTogaGlk ZWtpLmVuZG8uZXNAaGl0YWNoaS5jb20gW21haWx0bzpoaWRla2kuZW5kby5lc0BoaXRhY2hp LmNvbV0NCj4+Pj4gPj4gU2VudDogTW9uZGF5LCBNYXJjaCAyOCwgMjAxMSA4OjExIEFNDQo+ Pj4+ID4+IFRvOiBFcmljIEdyYXk7IFJvbGYuV2ludGVyQG5lY2xhYi5ldQ0KPj4+PiA+PiBD YzogbXBsc0BpZXRmLm9yZw0KPj4+PiA+PiBTdWJqZWN0OiBSZVsyXTogW21wbHNdIFdvcmtp bmcgR3JvdXAgTGFzIENhbGwgb25kcmFmdC1pZXRmLW1wbHMtdHAtb24tDQo+Pj4+ID4+IGRl bWFuZC1jdi0wMw0KPj4+PiA+PiBJbXBvcnRhbmNlOiBIaWdoDQo+Pj4+ID4+DQo+Pj4+ID4+ IEhpIEVyaWMgYW5kIFJvbGYsDQo+Pj4+ID4+DQo+Pj4+ID4+IEknbSBzb3JyeSBmb3IgaW50 ZXJydXB0aW5nLg0KPj4+PiA+Pg0KPj4+PiA+PiBJIGFncmVlIHdpdGggUm9sZiByZWdhcmRp bmcgdGhlIHBlci1pbnRlcmZhY2UgTUlQIGRpc2N1c3Npb24uDQo+Pj4+ID4+IFdlIGhhdmUg dG8gY29uc2lkZXIgdGhlIEhXIGltcGxlbWVudGF0aW9uIGFzcGVjdCwNCj4+Pj4gPj4gYmVj YXVzZSB0cmFwcGluZyBvZiBhbiBPQU0gcGFja2V0IGlzIEhXIHJ1bGUvZnVuY3Rpb25hbGl0 eSBldmVuIGluDQo+Pj4+ID4+IHJvdXRlcnMuDQo+Pj4+ID4+DQo+Pj4+ID4+IElmIGV2ZXJ5 IE9BTSBwYWNrZXQgaXMgdHJhcHBlZCB0byBDUFUNCj4+Pj4gPj4gYW5kIHRoZSBPQU0gcGFj a2V0cyB3aGljaCBzaG91bGQgTk9UIGJlIHByb2Nlc3NlZCBpbiB0aGUgSW50ZXJmYWNlDQo+ Pj4+ID4+IGFyZSByZXR1cm5lZCB0byBEYXRhLXBsYW5lLA0KPj4+PiA+PiBpdCBpcyBkaWZm ZXJlbnQgZm9yd2FyZGluZyBwYXRoIGZyb20gdXNlciBwYWNrZXRzLA0KPj4+PiA+PiB3aGlj aCBpcyBOT1QgdGhlIENvbm5lY3Rpdml0eSBWZXJpZmljYXRpb24gb2YgdGhlIHVzZXIgcGF0 aC4NCj4+Pj4gPj4NCj4+Pj4gPj4gVGhlcmVmb3JlLCB3ZSBzaG91bGQgdGFrZSB0aGUgSFcg YXNwZWN0IGFuZCBmbGV4aWJpbHR5IGludG8gYWNjb3VudA0KPj4+PiA+PiBjb25jdXJyZW50 bHkuDQo+Pj4+ID4+IElmIGFuIGFkZHJlc3MgVExWIE1VU1QgYmUgdGhlIGZpcnN0IGluIFRM VnMsDQo+Pj4+ID4+IGl0IGlzIGVub3VnaCB0byBtYWtlIEhXIGltcGxlbWVudGF0aW9uIGVh c3kuDQo+Pj4+ID4+DQo+Pj4+ID4+IEJSLA0KPj4+PiA+PiBIaWRla2kNCj4+Pj4gPj4NCj4+ Pj4gPj4NCj4+Pj4gPj4NCj4+Pj4gPj4gPlJvbGYsDQo+Pj4+ID4+ID4NCj4+Pj4gPj4gPiAg ICBUaGUgd29yZHMgeW91IHByb3Bvc2UgYXJlIG9rYXkgd2l0aCBtZS4NCj4+Pj4gPj4gPg0K Pj4+PiA+PiA+ICAgIEkgdGhvdWdodCB0aGUgTUlQL2ludGVyZmFjZSBhbmQgYWRkcmVzcyBs b2NhdGlvbiBpc3N1ZXMNCj4+Pj4gPj4gPndlcmUgc2VwYXJhdGUuDQo+Pj4+ID4+ID4NCj4+ Pj4gPj4gPiAgICBJJ3ZlIHBlcnNvbmFsbHkgaGFkIHByb2JsZW1zIHdpdGggcHJvdG9jb2wg c3BlY2lmaWNhdGlvbnMNCj4+Pj4gPj4gPnRoYXQgcmVxdWlyZSBvcmRlcmluZyBvZiBUTFZz LiAgSW4gcGFydGljdWxhciwgdGhpcyBpcyBub3QgdmVyeQ0KPj4+PiA+PiA+cm9idXN0IGlu IHRlcm1zIG9mICJmdXR1cmUtcHJvb2ZpbmcuIiAgV2hhdCBoYXBwZW5zIGlmIG5ldyBUTFZz DQo+Pj4+ID4+ID5hcmUgYWRkZWQgbGF0ZXIgb247IGZvciBpbnN0YW5jZSwgc3VwcG9zZSBh dCBzb21lIHBvaW50IHdlIGhhdmUNCj4+Pj4gPj4gPm11bHRpcGxlICJhZGRyZXNzIiBUTFZz Pw0KPj4+PiA+PiA+DQo+Pj4+ID4+ID4gICAgQWxzbywgdGhlIGZhY3QgdGhhdCBpbXBsZW1l bnRhdGlvbnMgYXJlIGFsbG93ZWQgdG8gYXR0YWNoDQo+Pj4+ID4+ID5UTFZzIGluIGFueSBh cmJpdHJhcnkgb3JkZXIgYWxsb3dzIGNvbnNpZGVyYWJsZSBmbGV4aWJpbHR5IGluDQo+Pj4+ ID4+ID5pbXBsZW1lbnRhdGlvbi4gIE1lc3NhZ2VzIGNhbiBiZSBidWlsdCBpbiBhcmJpdHJh cmlseSBtYW55IHdheXMuDQo+Pj4+ID4+ID5UaGlzIHRvbyBjYW4gYmUgYSBmdXR1cmUtcHJv b2ZpbmcgaXNzdWUuDQo+Pj4+ID4+ID4NCj4+Pj4gPj4gPiAgICBJIHdvdWxkIHByZWZlciBu b3QgdG8gc3RhcnQgZG93biB0aGUgcm9hZCBvZiByZXF1aXJpbmcgYQ0KPj4+PiA+PiA+c3Vi c2V0IG9mIFRMVnMgdG8gYXBwZWFyIGluIGEgY2VydGFpbiBvcmRlciwgYW5kIHNheWluZyB3 ZSBoYXZlDQo+Pj4+ID4+ID5vbmUgVExWIHRoYXQgbmVlZHMgdG8gYmUgZmlyc3QgaXMgZG9p bmcganVzdCB0aGF0Lg0KPj4+PiA+PiA+DQo+Pj4+ID4+ID4tLQ0KPj4+PiA+PiA+RXJpYw0K Pj4+PiA+PiA+DQo+Pj4+ID4+ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiA+ PiA+RnJvbTogUm9sZiBXaW50ZXIgW21haWx0bzpSb2xmLldpbnRlckBuZWNsYWIuZXVdDQo+ Pj4+ID4+ID5TZW50OiBNb25kYXksIE1hcmNoIDI4LCAyMDExIDY6MTkgQU0NCj4+Pj4gPj4g PlRvOiBFcmljIEdyYXkNCj4+Pj4gPj4gPkNjOiBtcGxzQGlldGYub3JnDQo+Pj4+ID4+ID5T dWJqZWN0OiBSRTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENhbGwgb24gZHJhZnQtaWV0 Zi1tcGxzLXRwLW9uLQ0KPj4+PiA+PiBkZW1hbmQtY3YtMDMNCj4+Pj4gPj4gPkltcG9ydGFu Y2U6IEhpZ2gNCj4+Pj4gPj4gPg0KPj4+PiA+PiA+SGksDQo+Pj4+ID4+ID4NCj4+Pj4gPj4g Pkkgc3RpbGwgdGhpbmsgdGhlcmUgaXMgYSBsb2dpY2FsIGVycm9yLiBMZXQgbWUgZXhwbGFp bi4gSW4gY2FzZSB0aGVyZQ0KPj4+PiA+PiBpcyBubyBJUCB5b3Ugc2ltcGx5IGNhbm5vdCB1 c2UgaXQuIFlvdSBzYXkgeW91IGNvdWxkIGVuYWJsZSBJUCBidXQgdGhlbg0KPj4+PiA+PiB0 aGF0IGlzIG5vdCBhIGNhc2Ugd2hlcmUgdGhlcmUgaXMgbm8gSVAuIEluIG9yZGVyIHRvIGJl IGNvbnN0cnVjdGl2ZQ0KPj4+PiA+PiBoZXJlIGlzIGEgdGV4dCBjaGFuZ2Ugc3VnZ2VzdGlv bjoNCj4+Pj4gPj4gPg0KPj4+PiA+PiA+IkluIGNlcnRhaW4gTVBMUy1UUCBkZXBsb3ltZW50 IHNjZW5hcmlvcyBJUCBhZGRyZXNzaW5nIG1pZ2h0IG5vdCBiZQ0KPj4+PiA+PiBhdmFpbGFi bGUuIEluIHRob3NlIGNhc2VzIE9uLWRlbWFuZCBDViBhbmQvb3Igcm91dGUgdHJhY2luZyBN VVNUIGJlIHJ1bg0KPj4+PiA+PiB3aXRob3V0IElQIGFkZHJlc3NpbmcsIHVzaW5nIHRoZSBB Q0ggY2hhbm5lbCB0eXBlIHNwZWNpZmllZCBpbiBTZWN0aW9uDQo+Pj4+ID4+IDMuIEluIG90 aGVyIGNhc2VzIGl0IG1pZ2h0IGJlIGF2YWlsYWJsZSwgaG93ZXZlciwgaXQgbWF5IGJlIHBy ZWZlcnJlZA0KPj4+PiA+PiB0byB1c2Ugc29tZSBmb3JtIG9mIG5vbi1JUCBlbmNhcHN1bGF0 aW9uLiBJbiB0aG9zZSBjYXNlcywgdGhlDQo+Pj4+ID4+IHByb2NlZHVyZXMgYXMgb3V0bGlu ZWQgaW4gc2VjdGlvbiAzIFNIT1VMRCBhbHNvIGJlIHVzZWQuIg0KPj4+PiA+PiA+DQo+Pj4+ ID4+ID5SZWdhcmRpbmcgdGhlIHBlci1pbnRlcmZhY2UgTUlQIGRpc2N1c3Npb24uIFRoZSBI VyBhc3BlY3QgYWxzbyBwb3BwZWQNCj4+Pj4gPj4gdXAgaW4gdGhlIFBXRTMgc2Vzc2lvbiBh bmQgSSB0aGluayB0aGlzIGlzIGFuIGltcG9ydGFudCBjb25zaWRlcmF0aW9uLA0KPj4+PiA+ PiBpbiBwYXJ0aWN1bGFyIGZvciBPQU0uIEV2ZW4gaWYgd2UgdGFsayBhYm91dCBUTFZzLCB3 ZSBjb3VsZCBtYWtlIGl0IGENCj4+Pj4gPj4gTVVTVCB0aGF0IGFuIEFkZHJlc3MgVExWIGlz IGFsd2F5cyB0aGUgZmlyc3Qgb25lIHRvIGFwcGVhci4gSWYgeW91IGNhbg0KPj4+PiA+PiBm YWNpbGl0YXRlIGFuIGVhc3kgaW1wbGVtZW50YXRpb24gaW4gaGFyZHdhcmUsIEkgc2VlIG5v IHJlYXNvbiB0bw0KPj4+PiA+PiBkZWxpYmVyYXRlbHkgbm90IGRvIGl0Lg0KPj4+PiA+PiA+ DQo+Pj4+ID4+ID5CZXN0LA0KPj4+PiA+PiA+DQo+Pj4+ID4+ID5Sb2xmDQo+Pj4+ID4+ID4N Cj4+Pj4gPj4gPg0KPj4+PiA+PiA+TkVDIEV1cm9wZSBMaW1pdGVkIHwgUmVnaXN0ZXJlZCBP ZmZpY2U6IE5FQyBIb3VzZSwgMSBWaWN0b3JpYSBSb2FkLA0KPj4+PiA+PiBMb25kb24gVzMg NkJMIHwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIDI4MzIwMTQNCj4+Pj4gPj4gPg0KPj4+PiA+ PiA+DQo+Pj4+ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+ID4+ID4+ IEZyb206IEVyaWMgR3JheSBbbWFpbHRvOmVyaWMuZ3JheUBlcmljc3Nvbi5jb21dDQo+Pj4+ ID4+ID4+IFNlbnQ6IE1vbnRhZywgMjguIE3kcnogMjAxMSAxMTo0Mw0KPj4+PiA+PiA+PiBU bzogUm9sZiBXaW50ZXINCj4+Pj4gPj4gPj4gQ2M6IGxvYUBwaS5udTsgbXBsc0BpZXRmLm9y Zw0KPj4+PiA+PiA+PiBTdWJqZWN0OiBSRTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENh bGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLQ0KPj4+PiA+PiA+PiBkZW1hbmQtY3YtMDMN Cj4+Pj4gPj4gPj4NCj4+Pj4gPj4gPj4gUm9sZiwNCj4+Pj4gPj4gPj4NCj4+Pj4gPj4gPj4g ICBXaXRoIHJlZ2FyZCB0byB0aGUgdXNlIG9mIFNIT1VMRCAodmVyc2VzIE1VU1QpIC0gdGhl IGludGVudA0KPj4+PiA+PiA+PiAoYWNjb3JkaW5nIHRvIFJGQyAyMTE5IC0gc2VlIHRoZSBx dW90ZSBiZWxvdykgaXMgY29uc2lzdGVudCB3aXRoDQo+Pj4+ID4+ID4+IHRoaXMgY2FzZS4g IElmIC0gZm9yIHNvbWUgcmVhc29uIC0gb25lIGhhZCBhIHJlYWxseSBnb29kIHJlYXNvbiB0 bw0KPj4+PiA+PiA+PiB1c2UgSVAgYWRkcmVzc2luZyBpbiBzb21lIHNwZWNpZmljIGNhc2Us IG9uZSBjb3VsZCB0YWtlIHN0ZXBzIHRvDQo+Pj4+ID4+ID4+IG1ha2UgSVAgYWRkcmVzc2lu ZyBhdmFpbGFibGUuDQo+Pj4+ID4+ID4+DQo+Pj4+ID4+ID4+ICAgVGhpcyBjb3VsZCBiZSBz YWlkIHRvIGludHJvZHVjZSBhIGxvZ2ljYWwgZGlzY29ubmVjdCwgYnV0IHdlDQo+Pj4+ID4+ ID4+IGFyZSBzYXZlZCBmcm9tIGdvaW5nIGRvd24gdGhhdCBwYXRoIGJ5IHRoZSBmYWN0IHRo YXQgdGhlIHN0YXRlbWVudA0KPj4+PiA+PiA+PiBhbHNvIGluY2x1ZGVzIHRoZSBjYXNlIHdo ZXJlIChmb3Igc29tZSByZWFzb24pIHRoZXJlIGlzIGEgY2FzZSBpbg0KPj4+PiA+PiA+PiB3 aGljaCBzb21lIG90aGVyIGFkZHJlc3Npbmcgc2NoZW1lIG1pZ2h0IGJlIHByZWZlcnJlZC4g IEluIG1hbnkgb2YNCj4+Pj4gPj4gPj4gdGhlIGNhc2VzIHdoZXJlIGFub3RoZXIgYWRkcmVz c2luZyBzY2hlbWUgbWF5IGJlIHByZWZlcnJlZCwgaXQgaXMNCj4+Pj4gPj4gPj4gc3RpbGwg cG9zc2libGUgKGluIGZhY3QgbGlrZWx5KSB0aGF0IElQIGFkZHJlc3NpbmcgaXMgYXZhaWxh YmxlLg0KPj4+PiA+PiA+Pg0KPj4+PiA+PiA+PiAgIE90aGVyd2lzZSwgaXQgd291bGQgbm90 IGhhdmUgYmVlbiBuZWNlc3NhcnkgdG8gZGlzdGluZ3Vpc2gNCj4+Pj4gPj4gPj4gdGhpcyBj YXNlIGZyb20gdGhlIG9uZSBpbiB3aGljaCBJUCBhZGRyZXNzaW5nIGlzIG5vdCBhdmFpbGFi bGUuDQo+Pj4+ID4+ID4+DQo+Pj4+ID4+ID4+ICAgRm9yIHRoZSBjYXNlIHdoZXJlIElQIGFk ZHJlc3NpbmcgaXMgbm90IHRoZSBwcmVmZXJyZWQgbW9kZSwNCj4+Pj4gPj4gPj4gd2UgYXJl IHJlY29tbWVuZGluZyBhIG1vZGUgaW4gd2hpY2ggaXQgaXMgbm90IG5lY2Vzc2FyeS4NCj4+ Pj4gPj4gPj4NCj4+Pj4gPj4gPj4gICBXaXRoIHJlZ2FyZCB0byBoYXZpbmcgYWRkcmVzc2Vz IGxvY2F0ZWQgaW4gdGhlIHNhbWUgcGxhY2UsDQo+Pj4+ID4+ID4+IHRoaXMgcHJvdG9jb2wg aXMgbWVhbnQgZm9yIGNvbm5lY3Rpdml0eSB0ZXN0aW5nIG9uIGFuIG9uLWRlbWFuZA0KPj4+ PiA+PiA+PiBiYXNpcyBhbmQgaXMgdGhlcmVmb3JlIG5vdCBvcHRpbWl6ZWQgZm9yIHByb2Nl c3NpbmcgaW4gaGFyZHdhcmUuDQo+Pj4+ID4+ID4+DQo+Pj4+ID4+ID4+ICAgV2hldGhlciBh ZGRyZXNzZXMgb3IgaWRlbnRpZmllcnMsIGlmIHdlIGFyZSB0YWxraW5nIGFib3V0DQo+Pj4+ ID4+ID4+IFRMViBjb250ZW50cywgdGhlcmUgYXJlIGlzc3VlcyB3aXRoIHRyeWluZyB0byBn dWFyYW50ZWUgbG9jYXRpb24NCj4+Pj4gPj4gPj4gb2Ygc3BlY2lmaWMgY29udGVudCwgYmVj YXVzZSBvZiB0aGUgZmFjdCB0aGF0IHRoZSBUTFYgaW4gcXVlc3Rpb24NCj4+Pj4gPj4gPj4g d2lsbCBwcm9iYWJseSBmb2xsb3cgb3RoZXIgVExWcyAtIHRodXMgbWFraW5nIGxvY2F0aW9u cyBkaWZmaWN1bHQNCj4+Pj4gPj4gPj4gdG8gcHJlZGljdCBpbiBhbnkgY2FzZS4NCj4+Pj4g Pj4gPj4NCj4+Pj4gPj4gPj4gICBXaXRoIHJlZ2FyZCB0byBuZWVkaW5nIG1vcmUgdGV4dCBv biBwZXItaW50ZXJmYWNlIE1JUHMsIGRvDQo+Pj4+ID4+ID4+IHlvdSBoYXZlIHNwZWNpZmlj IHN1Z2dlc3Rpb25zIGFzIHRvIHdoYXQgdGV4dCB3ZSBtaWdodCBhZGQ/DQo+Pj4+ID4+ID4+ DQo+Pj4+ID4+ID4+ICAgSSB1bmRlcnN0YW5kIChmcm9tIGRpc2N1c3Npb24gd2l0aCBXRyBj aGFpcnMpIHRoYXQgd2UgYXJlDQo+Pj4+ID4+ID4+IG5vdCBhbGxvd2VkIHRvIGV4cGxpY2l0 bHkgYWRkcmVzcyBsYXN0IGNhbGwgY29tbWVudHMgZHVyaW5nIHRoZQ0KPj4+PiA+PiA+PiBJ RVRGIG1lZXRpbmcgaW4gUHJhZ3VlLCBiZWNhdXNlIHRoZSBsYXN0IGNhbGwgaXMgc3RpbGwg b25nb2luZw0KPj4+PiA+PiA+PiBhdCB0aGF0IHRpbWUuDQo+Pj4+ID4+ID4+DQo+Pj4+ID4+ ID4+IC0tDQo+Pj4+ID4+ID4+IEVyaWMNCj4+Pj4gPj4gPj4NCj4+Pj4gPj4gPj4gUFMgLQ0K Pj4+PiA+PiA+PiBGcm9tIFJGQyAyMTE5IC0NCj4+Pj4gPj4gPj4gJ1NIT1VMRCAgIFRoaXMg d29yZCwgb3IgdGhlIGFkamVjdGl2ZSAiUkVDT01NRU5ERUQiLCBtZWFuIHRoYXQgdGhlcmUN Cj4+Pj4gPj4gPj4gICAgICAgICAgIG1heSBleGlzdCB2YWxpZCByZWFzb25zIGluIHBhcnRp Y3VsYXIgY2lyY3Vtc3RhbmNlcyB0bw0KPj4+PiA+PiA+PiAgICAgICAgICAgaWdub3JlIGEg cGFydGljdWxhciBpdGVtLCBidXQgdGhlIGZ1bGwgaW1wbGljYXRpb25zIG11c3QNCj4+Pj4g Pj4gPj4gICAgICAgICAgIGJlIHVuZGVyc3Rvb2QgYW5kIGNhcmVmdWxseSB3ZWlnaGVkIGJl Zm9yZSBjaG9vc2luZyBhDQo+Pj4+ID4+ID4+ICAgICAgICAgICBkaWZmZXJlbnQgY291cnNl LicNCj4+Pj4gPj4gPj4NCj4+Pj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+Pj4gPj4gPj4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1i b3VuY2VzQGlldGYub3JnXSBPbg0KPj4+PiBCZWhhbGYNCj4+Pj4gPj4gT2YNCj4+Pj4gPj4g Pj4gUm9sZiBXaW50ZXINCj4+Pj4gPj4gPj4gU2VudDogVHVlc2RheSwgTWFyY2ggMjIsIDIw MTEgNDo1NyBBTQ0KPj4+PiA+PiA+PiBUbzogbG9hQHBpLm51OyBtcGxzQGlldGYub3JnDQo+ Pj4+ID4+ID4+IFN1YmplY3Q6IFJlOiBbbXBsc10gV29ya2luZyBHcm91cCBMYXMgQ2FsbCBv biBkcmFmdC1pZXRmLW1wbHMtdHAtb24tDQo+Pj4+ID4+ID4+IGRlbWFuZC1jdi0wMw0KPj4+ PiA+PiA+Pg0KPj4+PiA+PiA+PiBIaSwNCj4+Pj4gPj4gPj4NCj4+Pj4gPj4gPj4gc29tZSBj b21tZW50cyBiZWxvdzoNCj4+Pj4gPj4gPj4NCj4+Pj4gPj4gPj4gU2VjdGlvbiAxLjMgc2F5 czogIiBJbiBjZXJ0YWluIE1QTFMtVFAgZGVwbG95bWVudCBzY2VuYXJpb3MgSVANCj4+Pj4g Pj4gPj4gYWRkcmVzc2luZyBtaWdodCBub3QgYmUNCj4+Pj4gPj4gPj4gICAgYXZhaWxhYmxl IG9yIGl0IG1heSBiZSBwcmVmZXJyZWQgdG8gdXNlIHNvbWUgZm9ybSBvZiBub24tSVANCj4+ Pj4gPj4gPj4gICAgZW5jYXBzdWxhdGlvbiBmb3IgT24tZGVtYW5kIENWLCByb3V0ZSB0cmFj aW5nIGFuZCBCRkQgcGFja2V0cy4NCj4+Pj4gPj4gSW4NCj4+Pj4gPj4gPj4gICAgc3VjaCBz Y2VuYXJpb3MsIE9uLWRlbWFuZCBDViBhbmQvb3Igcm91dGUgdHJhY2luZyBTSE9VTEQgYmUg cnVuDQo+Pj4+ID4+ID4+ICAgIHdpdGhvdXQgSVAgYWRkcmVzc2luZy4uLiINCj4+Pj4gPj4g Pj4NCj4+Pj4gPj4gPj4gSSBhbSBub3Qgc3VyZSB0aGUgIlNIT1VMRCIgaXMgcmlnaHQgaGVy ZS4gSWYgbm8gSVAgYWRkcmVzc2luZyBpcw0KPj4+PiA+PiA+PiBhdmFpbGFibGUsIHRoaXMg dGhpbmcgTVVTVCBiZSBydW4gd2l0aG91dCBJUCBhZGRyZXNzaW5nLCBtdXN0bid0IGl0Pw0K Pj4+PiA+PiA+Pg0KPj4+PiA+PiA+PiBJIHRoaW5rIHNvbWUgYWRkaXRpb25hbCB0ZXh0IHJl Z2FyZGluZyBwZXItaW50ZXJmYWNlIE1JUCBhZGRyZXNzaW5nDQo+Pj4+ID4+ID4+IHdvdWxk IGJlIG5pY2UuIEFzIGZhciBhcyBJIHVuZGVyc3RhbmQgdGhlIGRvY3VtZW50LCBhbGwgVExW cyB3aWxsIGJlDQo+Pj4+ID4+ID4+IGluc2lkZSB0aGUgTFNQIHBpbmcgcGFja2V0IChyYXRo ZXIgdGhhbiBhcyBBQ0ggVExWcykuDQo+Pj4+ID4+ID4+DQo+Pj4+ID4+ID4+IFNvbWUgcGVv cGxlIGhhZCBjb25jZXJucyBlYXJsaWVyLCB0aGF0IGFkZHJlc3NpbmcgaW5mb3JtYXRpb24g c2hvdWxkDQo+Pj4+ID4+IGJlDQo+Pj4+ID4+ID4+IGluIGEgZml4ZWQgbG9jYXRpb24gZm9y IGVhc2llciBwcm9jZXNzaW5nLiBJcyB0aGlzIHRoZSBjYXNlIGhlcmUgSQ0KPj4+PiA+PiA+ PiB3b25kZXI/DQo+Pj4+ID4+ID4+DQo+Pj4+ID4+ID4+IEl0IHdvdWxkIGJlIG5pY2UgaWYg eW91IGNvdWxkIGFkZHJlc3MgdGhpcyBpbiB5b3VyIHByZXNlbnRhdGlvbiBpbg0KPj4+PiA+ PiA+PiBQcmFndWUuDQo+Pj4+ID4+ID4+DQo+Pj4+ID4+ID4+IFRoYW5rcywNCj4+Pj4gPj4g Pj4NCj4+Pj4gPj4gPj4gUm9sZg0KPj4+PiA+PiA+Pg0KPj4+PiA+PiA+Pg0KPj4+PiA+PiA+ PiBORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVkIE9mZmljZTogTkVDIEhvdXNlLCAx IFZpY3RvcmlhIFJvYWQsDQo+Pj4+ID4+ID4+IExvbmRvbiBXMyA2QkwgfCBSZWdpc3RlcmVk IGluIEVuZ2xhbmQgMjgzMjAxNA0KPj4+PiA+PiA+Pg0KPj4+PiA+PiA+Pg0KPj4+PiA+PiA+ PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+ID4+ID4+ID4gRnJvbTogbXBs cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbg0K Pj4+PiA+PiBCZWhhbGYNCj4+Pj4gPj4gPj4gT2YNCj4+Pj4gPj4gPj4gPiBsb2FAcGkubnUN Cj4+Pj4gPj4gPj4gPiBTZW50OiBNaXR0d29jaCwgMTYuIE3kcnogMjAxMSAwMDoyNg0KPj4+ PiA+PiA+PiA+IFRvOiBtcGxzQGlldGYub3JnDQo+Pj4+ID4+ID4+ID4gQ2M6IE1QTFMtVFAg YWQgaG9jIHRlYW0NCj4+Pj4gPj4gPj4gPiBTdWJqZWN0OiBbbXBsc10gV29ya2luZyBHcm91 cCBMYXMgQ2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtb24tDQo+Pj4+ID4+ID4+IGRlbWFu ZC0NCj4+Pj4gPj4gPj4gPiBjdi0wMw0KPj4+PiA+PiA+PiA+DQo+Pj4+ID4+ID4+ID4gV29y a2luZyBHcm91cCwNCj4+Pj4gPj4gPj4gPg0KPj4+PiA+PiA+PiA+IHRoaXMgaXMgdG8gc3Rh cnQgYSAzIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24NCj4+Pj4gPj4gPj4gPg0K Pj4+PiA+PiA+PiA+IGRyYWZ0LWlldGYtbXBscy10cC1vbi1kZW1hbmQtY3YtMDMNCj4+Pj4g Pj4gPj4gPg0KPj4+PiA+PiA+PiA+IFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRoZSB3b3Jr aW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPj4+PiA+PiA+PiA+IG1wbHNAaWV0Zi5vcmcNCj4+ Pj4gPj4gPj4gPg0KPj4+PiA+PiA+PiA+IFRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBl bmRzIG9uIEFwcmlsIDgsIDIwMTEuDQo+Pj4+ID4+ID4+ID4NCj4+Pj4gPj4gPj4gPiAvTG9h DQo+Pj4+ID4+ID4+ID4NCj4+Pj4gPj4gPj4gPg0KPj4+PiA+PiA+PiA+DQo+Pj4+ID4+ID4+ ID4NCj4+Pj4gPj4gPj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+PiA+PiA+PiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4+ID4+ID4+ ID4gbXBsc0BpZXRmLm9yZw0KPj4+PiA+PiA+PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscw0KPj4+PiA+PiA+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiA+PiA+PiBtcGxzIG1haWxpbmcgbGlz dA0KPj4+PiA+PiA+PiBtcGxzQGlldGYub3JnDQo+Pj4+ID4+ID4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4+PiA+PiA+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gPj4gPm1wbHMgbWFpbGlu ZyBsaXN0DQo+Pj4+ID4+ID5tcGxzQGlldGYub3JnDQo+Pj4+ID4+ID5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+Pj4gPj4gPg0KPj4+PiA+DQo+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+ IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4+IG1wbHNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+Pj4+DQo+Pj4NCj4+Pg0KPj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4g bXBscyBtYWlsaW5nIGxpc3QNCj4+PiBtcGxzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+Pj4NCj4+DQo+DQo= --GMAILSMTPBOUND01110329171220-- From Alexander.Vainshtein@ecitele.com Tue Mar 29 01:15:51 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7A513A697A for ; Tue, 29 Mar 2011 01:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] 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 O0TmlNYFQAnu for ; Tue, 29 Mar 2011 01:15:50 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id 08B293A68C7 for ; Tue, 29 Mar 2011 01:15:49 -0700 (PDT) X-AuditID: 93eaf2e8-b7bb7ae000004cb7-2a-4d91952f8cc8 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Brightmail Gateway) with SMTP id FD.A8.19639.F25919D4; Tue, 29 Mar 2011 10:15:43 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 29 Mar 2011 10:16:49 +0200 From: Alexander Vainshtein To: Eric Gray Date: Tue, 29 Mar 2011 10:16:41 +0200 Thread-Topic: [mpls] Working Group Las Call on draft-ietf-mpls-tp- on-demand-cv-03 Thread-Index: AQHL7YdjG4j++77GG0yKCjb8Qx0mppRD6CgQgAAKXYCAAAOWYA== Message-ID: References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E177AF@Polydeuces.office.hd> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , Sami, Rolf Winter , Boutros Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp- on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 08:15:51 -0000 Eric, and all, I suggest that we should look at the diagrams in RFC 3443. They explicitly show that TTL is decremented by 1 by each LSR that the MPLS= packet crosses...=20 Regards, Sasha > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Eric Gray > Sent: Tuesday, March 29, 2011 10:04 AM > To: Rolf Winter; Sami Boutros; hideki.endo.es@hitachi.com > Cc: mpls@ietf.org > Subject: Re: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on- > demand-cv-03 >=20 > Rolf, >=20 > There is no case here to support your argument that TTL is > always only decremented by one. We should discuss this (as has > been proposed), however - if you read the Routing Requirements > RFC (RFC 1812) - you will find that the actual requirement is for > a "forwarder" to decrement TTL "by at least one." >=20 > I can think of several scenarios where a single forwarder > might be configured to decrement TTL by more than one for some > set of packets. >=20 > -- > Eric >=20 > -----Original Message----- > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > Sent: Tuesday, March 29, 2011 3:25 AM > To: Sami Boutros; hideki.endo.es@hitachi.com; Eric Gray > Cc: mpls@ietf.org > Subject: RE: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on- > demand-cv-03 > Importance: High >=20 > Hi Sami, >=20 > see inline. >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 > > > > Keep in mind that a node decrement TTL once, and > > this per-interface MIP seems to require a node to decrement twice.. > > > > Thanks, > > >=20 > I don't think this is a good idea. This is not how the TTL works today. > I think this is very unwise and touching a pretty fundamental principle > here. FWIW, we have proposed an alternative and presented it the last > IETF. Unfortunately, we have received little feedback on it. But I > think the discussion we have right now is good and not too late. The > OAM framework document includes per-interface MIPs and I think the > group needs to start thinking hard now to make sure this is thought > about before we finish off all these OAM tools. This way we do not need > to come back later and change things. I don't think it will be overly > hard, we just need to agree on something. >=20 > Best, >=20 > Rolf >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Tue Mar 29 01:26:39 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB0D73A6A9D for ; Tue, 29 Mar 2011 01:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[AWL=0.892, 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 Wx8xV5K9r1to for ; Tue, 29 Mar 2011 01:26:37 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 509ED3A697A for ; Tue, 29 Mar 2011 01:26:37 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2T8RwfL027525; Tue, 29 Mar 2011 03:28:13 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 29 Mar 2011 04:28:04 -0400 From: Eric Gray To: Sami Boutros , "hideki.endo.es@hitachi.com" , "Rolf.Winter@neclab.eu" Date: Tue, 29 Mar 2011 04:28:03 -0400 Thread-Topic: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-demand-cv-03 Thread-Index: Acvth3iQ8/dKl7oyTui9sdjTGJ3O6gAYpiIg Message-ID: References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> In-Reply-To: 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@ietf.org" Subject: Re: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 08:26:39 -0000 Sami, I could see a case for decrementing TTL twice in order to achieve this approach, but this would only be workable in practice if the device _always_ decrements PDUs in the LSP affected by this once at ingress port and again at egress port. Otherwise, there is an obvious case in which treatment of OAM packets on this LSP is conspicuously different from treatment of data packets (i.e. OAM packets are decremented twice in the same node where data packets are decremented only once in the same LSP). I don't see decrementing TTL twice as a requirement, but - then - I am not at all sure why we would be doing a trace-route that attempts to discern not only what nodes a specific LSP traverses, but also what ports on each node. That seems to be going well beyond the usual use of trace-route. Perhaps I missed an MPLS-TP requirement that explicitly compels us to do this? -- Eric -----Original Message----- From: Sami Boutros [mailto:sboutros@cisco.com] Sent: Monday, March 28, 2011 4:33 PM To: hideki.endo.es@hitachi.com; Eric Gray; Rolf.Winter@neclab.eu Cc: mpls@ietf.org Subject: Re: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-demand-c= v-03 Importance: High At 06:43 AM 3/28/2011, hideki.endo.es@hitachi.com wrote: >Hi Eric, > >What I'd like to say was explaned by Rolf. >My concern is whether the OAM packet is fate sharing with user packet or N= OT. >If draft-on-demand-cv doesn't care anything for fate sharing >in the case of per-interface MIP, >the per-interface MIP can NOT be implemented by HW reasonably. Keep in mind that a node decrement TTL once, and this per-interface MIP seems to require a node to decrement twice.. Thanks, Sami >BR, >Hideki > > >Eric, > > > >I generally agree but I think there is one > case actually which needs a closer look in this > regard (which I hinted at earlier), which are > the per-interface MIPs. Your TTL expires (the > actual addressing bit here), the identifier > tells you it is not intended for the ingress > MIP, so it needs to be forwarded to the egress > MIP through the forwarding engine. Now if you > pull the packet out of the fast path and inject > it back in, is the OAM packet still fate > sharing? If you can do this in HW on the line > card, then it will and it will just be > forwarded as normal. I know this is a different > draft, but this will be in particular important for performance monitorin= g. > > > >Best, > > > >Rolf > > > > > > > >NEC Europe Limited | Registered Office: NEC > House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > > > > >> -----Original Message----- > >> From: Eric Gray [mailto:eric.gray@ericsson.com] > >> Sent: Montag, 28. M=E4rz 2011 14:45 > >> To: hideki.endo.es@hitachi.com; Rolf Winter > >> Cc: mpls@ietf.org > >> Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp= - > >> on-demand-cv-03 > >> > >> Hideki, > >> > >> What you're saying is true, but not relevant in this > >> case. The "addresses" in this discussion are not used to > >> determine how to forward OAM packets. They are used only > >> by the recipient MIP/MEP to verify that the OAM packet was > >> properly delivered. > >> > >> By the way, this discussion is an indication of the > >> confusing injected by calling these things addresses. My > >> mistake and I bring it up now to help to stem the tide of > >> further comments resulting from that confusion. > >> > >> In the version we post after last call is complete, > >> we will be changing the source and destination "address" > >> TLVs to source and destination "identifier" TLVs. > >> > >> We will also be correcting the reference to DSMAP, > >> and DDMAP, address TLVs (which is incorrect, because the > >> format for DSMAP/DDMAP doesn't include a "length" field). > >> > >> The format of the Downstream Mapping (DSMAP) TLV is > >> defined in RFC 4379, and we are not changing the format > >> of that TLV. > >> > >> These changes are driven by last call comments we > >> have already received (see Joel Halpern's comments on the > >> mailing list) and are - in part - to correct accidental > >> use of the word "address" for source and destination > >> identifier TLVs (which is what we had discussed before > >> I generated the -03 version among the authors of several > >> of the current set of MPLS-TP drafts). > >> > >> In the case of source and destination identifiers, > >> these will be used exclusively to verify that an OAM PDU > >> has been correctly received by its intended recipient. > >> Because this is an on-demand connectivity verification > >> protocol, that is expected to be used only on those > >> occasions when there is a network problem that needs to > >> be diagnosed, and the information is not seen (and not > >> visible - without layer violations), optimizing these > >> objects for software makes sense. > >> > >> In addition, since either may be included (which > >> includes the possibility of including both), it is the > >> case already that we would then need to decide which is > >> to go first - assuming we wanted to do this (which we > >> do not). > >> > >> -- > >> Eric > >> > >> -----Original Message----- > >> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] > >> Sent: Monday, March 28, 2011 8:11 AM > >> To: Eric Gray; Rolf.Winter@neclab.eu > >> Cc: mpls@ietf.org > >> Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on- > >> demand-cv-03 > >> Importance: High > >> > >> Hi Eric and Rolf, > >> > >> I'm sorry for interrupting. > >> > >> I agree with Rolf regarding the per-interface MIP discussion. > >> We have to consider the HW implementation aspect, > >> because trapping of an OAM packet is HW rule/functionality even in > >> routers. > >> > >> If every OAM packet is trapped to CPU > >> and the OAM packets which should NOT be processed in the Interface > >> are returned to Data-plane, > >> it is different forwarding path from user packets, > >> which is NOT the Connectivity Verification of the user path. > >> > >> Therefore, we should take the HW aspect and flexibilty into account > >> concurrently. > >> If an address TLV MUST be the first in TLVs, > >> it is enough to make HW implementation easy. > >> > >> BR, > >> Hideki > >> > >> > >> > >> >Rolf, > >> > > >> > The words you propose are okay with me. > >> > > >> > I thought the MIP/interface and address location issues > >> >were separate. > >> > > >> > I've personally had problems with protocol specifications > >> >that require ordering of TLVs. In particular, this is not very > >> >robust in terms of "future-proofing." What happens if new TLVs > >> >are added later on; for instance, suppose at some point we have > >> >multiple "address" TLVs? > >> > > >> > Also, the fact that implementations are allowed to attach > >> >TLVs in any arbitrary order allows considerable flexibilty in > >> >implementation. Messages can be built in arbitrarily many ways. > >> >This too can be a future-proofing issue. > >> > > >> > I would prefer not to start down the road of requiring a > >> >subset of TLVs to appear in a certain order, and saying we have > >> >one TLV that needs to be first is doing just that. > >> > > >> >-- > >> >Eric > >> > > >> >-----Original Message----- > >> >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > >> >Sent: Monday, March 28, 2011 6:19 AM > >> >To: Eric Gray > >> >Cc: mpls@ietf.org > >> >Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > >> demand-cv-03 > >> >Importance: High > >> > > >> >Hi, > >> > > >> >I still think there is a logical error. Let me explain. In case there > >> is no IP you simply cannot use it. You say you could enable IP but the= n > >> that is not a case where there is no IP. In order to be constructive > >> here is a text change suggestion: > >> > > >> >"In certain MPLS-TP deployment scenarios IP addressing might not be > >> available. In those cases On-demand CV and/or route tracing MUST be ru= n > >> without IP addressing, using the ACH channel type specified in Section > >> 3. In other cases it might be available, however, it may be preferred > >> to use some form of non-IP encapsulation. In those cases, the > >> procedures as outlined in section 3 SHOULD also be used." > >> > > >> >Regarding the per-interface MIP discussion. The HW aspect also popped > >> up in the PWE3 session and I think this is an important consideration, > >> in particular for OAM. Even if we talk about TLVs, we could make it a > >> MUST that an Address TLV is always the first one to appear. If you can > >> facilitate an easy implementation in hardware, I see no reason to > >> deliberately not do it. > >> > > >> >Best, > >> > > >> >Rolf > >> > > >> > > >> >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > >> London W3 6BL | Registered in England 2832014 > >> > > >> > > >> >> -----Original Message----- > >> >> From: Eric Gray [mailto:eric.gray@ericsson.com] > >> >> Sent: Montag, 28. M=E4rz 2011 11:43 > >> >> To: Rolf Winter > >> >> Cc: loa@pi.nu; mpls@ietf.org > >> >> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on= - > >> >> demand-cv-03 > >> >> > >> >> Rolf, > >> >> > >> >> With regard to the use of SHOULD (verses MUST) - the intent > >> >> (according to RFC 2119 - see the quote below) is consistent with > >> >> this case. If - for some reason - one had a really good reason to > >> >> use IP addressing in some specific case, one could take steps to > >> >> make IP addressing available. > >> >> > >> >> This could be said to introduce a logical disconnect, but we > >> >> are saved from going down that path by the fact that the statement > >> >> also includes the case where (for some reason) there is a case in > >> >> which some other addressing scheme might be preferred. In many of > >> >> the cases where another addressing scheme may be preferred, it is > >> >> still possible (in fact likely) that IP addressing is available. > >> >> > >> >> Otherwise, it would not have been necessary to distinguish > >> >> this case from the one in which IP addressing is not available. > >> >> > >> >> For the case where IP addressing is not the preferred mode, > >> >> we are recommending a mode in which it is not necessary. > >> >> > >> >> With regard to having addresses located in the same place, > >> >> this protocol is meant for connectivity testing on an on-demand > >> >> basis and is therefore not optimized for processing in hardware. > >> >> > >> >> Whether addresses or identifiers, if we are talking about > >> >> TLV contents, there are issues with trying to guarantee location > >> >> of specific content, because of the fact that the TLV in question > >> >> will probably follow other TLVs - thus making locations difficult > >> >> to predict in any case. > >> >> > >> >> With regard to needing more text on per-interface MIPs, do > >> >> you have specific suggestions as to what text we might add? > >> >> > >> >> I understand (from discussion with WG chairs) that we are > >> >> not allowed to explicitly address last call comments during the > >> >> IETF meeting in Prague, because the last call is still ongoing > >> >> at that time. > >> >> > >> >> -- > >> >> Eric > >> >> > >> >> PS - > >> >> From RFC 2119 - > >> >> 'SHOULD This word, or the adjective "RECOMMENDED", mean that ther= e > >> >> may exist valid reasons in particular circumstances to > >> >> ignore a particular item, but the full implications must > >> >> be understood and carefully weighed before choosing a > >> >> different course.' > >> >> > >> >> -----Original Message----- > >> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behal= f > >> Of > >> >> Rolf Winter > >> >> Sent: Tuesday, March 22, 2011 4:57 AM > >> >> To: loa@pi.nu; mpls@ietf.org > >> >> Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on= - > >> >> demand-cv-03 > >> >> > >> >> Hi, > >> >> > >> >> some comments below: > >> >> > >> >> Section 1.3 says: " In certain MPLS-TP deployment scenarios IP > >> >> addressing might not be > >> >> available or it may be preferred to use some form of non-IP > >> >> encapsulation for On-demand CV, route tracing and BFD packets. > >> In > >> >> such scenarios, On-demand CV and/or route tracing SHOULD be run > >> >> without IP addressing..." > >> >> > >> >> I am not sure the "SHOULD" is right here. If no IP addressing is > >> >> available, this thing MUST be run without IP addressing, mustn't it= ? > >> >> > >> >> I think some additional text regarding per-interface MIP addressing > >> >> would be nice. As far as I understand the document, all TLVs will b= e > >> >> inside the LSP ping packet (rather than as ACH TLVs). > >> >> > >> >> Some people had concerns earlier, that addressing information shoul= d > >> be > >> >> in a fixed location for easier processing. Is this the case here I > >> >> wonder? > >> >> > >> >> It would be nice if you could address this in your presentation in > >> >> Prague. > >> >> > >> >> Thanks, > >> >> > >> >> Rolf > >> >> > >> >> > >> >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > >> >> London W3 6BL | Registered in England 2832014 > >> >> > >> >> > >> >> > -----Original Message----- > >> >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >> Behalf > >> >> Of > >> >> > loa@pi.nu > >> >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26 > >> >> > To: mpls@ietf.org > >> >> > Cc: MPLS-TP ad hoc team > >> >> > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > >> >> demand- > >> >> > cv-03 > >> >> > > >> >> > Working Group, > >> >> > > >> >> > this is to start a 3 week working group last call on > >> >> > > >> >> > draft-ietf-mpls-tp-on-demand-cv-03 > >> >> > > >> >> > Please send comments to the working group mailing list > >> >> > mpls@ietf.org > >> >> > > >> >> > The working group last call ends on April 8, 2011. > >> >> > > >> >> > /Loa > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > mpls mailing list > >> >> > mpls@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/mpls > >> >> _______________________________________________ > >> >> mpls mailing list > >> >> mpls@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/mpls > >> >_______________________________________________ > >> >mpls mailing list > >> >mpls@ietf.org > >> >https://www.ietf.org/mailman/listinfo/mpls > >> > > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Tue Mar 29 02:09:50 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3FB28C13E for ; Tue, 29 Mar 2011 02:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.77 X-Spam-Level: X-Spam-Status: No, score=-5.77 tagged_above=-999 required=5 tests=[AWL=0.829, 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 Lw3yHNTNeriX for ; Tue, 29 Mar 2011 02:09:44 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 3FF9328C126 for ; Tue, 29 Mar 2011 02:09:33 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2T9B5VT028200; Tue, 29 Mar 2011 04:11:07 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 29 Mar 2011 05:11:06 -0400 From: Eric Gray To: Alexander Vainshtein Date: Tue, 29 Mar 2011 05:11:04 -0400 Thread-Topic: Off-Topic (was RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp- on-demand-cv-03) Thread-Index: AQHL7YdjG4j++77GG0yKCjb8Qx0mppRD6CgQgAAKXYCAAAOWYIAACN3g Message-ID: References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E177AF@Polydeuces.office.hd> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , Sami, Rolf Winter , Boutros Subject: [mpls] Off-Topic (was RE: Working Group Las Call on draft-ietf-mpls-tp- on-demand-cv-03) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 09:09:50 -0000 Sasha, This is definitely starting to wander off-topic. I'm pretty sure that particular aspect of the diagrams=20 is intended as an example. It is clearly possible that TTL may be decremented by more than one by something that otherwise looks like one forwarding device.=20 One of the continuing issues with using ASCII art in figures is that it is relatively painful to represent the symbol for "greater-than-or-equal-to", so people frequently use the path of least resistance and use "=3D" instead... =20 I am also pretty sure that it is a generic abuse of TTL=20 to use it to try to infer the number of devices on a path. This could be a problem if you have a sender that uses their "knowledge" of the network topology to set a starting TTL value. I think this would be a mistake, but it should=20 be a correctable mistake and it would certainly be an easily detectable problem. One (really old, so I may be dating myself) example of a very reasonable case for decrementing by more than one at a forwarder is if that forwarder is using a low-speed link to forward. In this case, a relatively small number of PDUS can completely consune the available bandwidth on that link if allowed to re-traverse the link a significant number of=20 times. I have certainly run trace-route in the past and seen the same node show up more than once in the path (which is an indication that the node decrements TTL by more than one. Originally (really dating myself now), it was also an explicit requirement that a device would decrement TTL by=20 the larger of "1", or the number of seconds that packet was queued while being processed by the device. At today's line rates, this is not a realistic consideration unless a device has an outrageously huge set of packet buffers, however. But it might not be unreasonable for a device to use a higher value than one to decrement TTL in cases where a set=20 of packets are experiencing unusually long processing delays, as this might have something to do with congestion and a larger decrement for queues experiencing congestion would "punish" looping traffic more severely than other traffic. -- Eric -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Tuesday, March 29, 2011 4:17 AM To: Eric Gray Cc: mpls@ietf.org; Rolf Winter; Sami Boutros; hideki.endo.es@hitachi.com Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp- on-demand= -cv-03 Importance: High Eric, and all, I suggest that we should look at the diagrams in RFC 3443. They explicitly show that TTL is decremented by 1 by each LSR that the MPLS= packet crosses...=20 Regards, Sasha > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Eric Gray > Sent: Tuesday, March 29, 2011 10:04 AM > To: Rolf Winter; Sami Boutros; hideki.endo.es@hitachi.com > Cc: mpls@ietf.org > Subject: Re: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on- > demand-cv-03 >=20 > Rolf, >=20 > There is no case here to support your argument that TTL is > always only decremented by one. We should discuss this (as has > been proposed), however - if you read the Routing Requirements > RFC (RFC 1812) - you will find that the actual requirement is for > a "forwarder" to decrement TTL "by at least one." >=20 > I can think of several scenarios where a single forwarder > might be configured to decrement TTL by more than one for some > set of packets. >=20 > -- > Eric >=20 > -----Original Message----- > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > Sent: Tuesday, March 29, 2011 3:25 AM > To: Sami Boutros; hideki.endo.es@hitachi.com; Eric Gray > Cc: mpls@ietf.org > Subject: RE: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on- > demand-cv-03 > Importance: High >=20 > Hi Sami, >=20 > see inline. >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 > > > > Keep in mind that a node decrement TTL once, and > > this per-interface MIP seems to require a node to decrement twice.. > > > > Thanks, > > >=20 > I don't think this is a good idea. This is not how the TTL works today. > I think this is very unwise and touching a pretty fundamental principle > here. FWIW, we have proposed an alternative and presented it the last > IETF. Unfortunately, we have received little feedback on it. But I > think the discussion we have right now is good and not too late. The > OAM framework document includes per-interface MIPs and I think the > group needs to start thinking hard now to make sure this is thought > about before we finish off all these OAM tools. This way we do not need > to come back later and change things. I don't think it will be overly > hard, we just need to agree on something. >=20 > Best, >=20 > Rolf >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Adrian.Farrel@huawei.com Tue Mar 29 06:51:08 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3679E3A6A2D for ; Tue, 29 Mar 2011 06:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.368 X-Spam-Level: X-Spam-Status: No, score=-105.368 tagged_above=-999 required=5 tests=[AWL=1.231, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 RVyHzfIVlzP4 for ; Tue, 29 Mar 2011 06:51:07 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 6D6363A6A26 for ; Tue, 29 Mar 2011 06:51:07 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIT004KTNVXC8@usaga03-in.huawei.com> for mpls@ietf.org; Tue, 29 Mar 2011 08:52:45 -0500 (CDT) Received: from 950129200 ([130.129.21.165]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIT009WONVUWT@usaga03-in.huawei.com> for mpls@ietf.org; Tue, 29 Mar 2011 08:52:45 -0500 (CDT) Date: Tue, 29 Mar 2011 15:52:07 +0200 From: Adrian Farrel To: mpls@ietf.org Message-id: <08e101cbee18$950a5820$bf1f0860$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AcvuF87GNPlcIWRRS0G56AYGbHHCqQ== Subject: [mpls] Working Group chairs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 13:51:08 -0000 Hi, At the end of last year I appointed Ross Callon and as a temporary third WG chair to help with the considerable management and technical load in the MPLS working group. Ross has been a great benefit to the WG and is working well with the other chairs. The work load continues to be incredibly high. I have appointed Ross to continue as WG chair as a full third chair. Thanks for Ross for agreeing to help with the work. Adrian From kishoret@juniper.net Tue Mar 29 06:55:52 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DC243A68FC for ; Tue, 29 Mar 2011 06:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LRKKaT-ISu2T for ; Tue, 29 Mar 2011 06:55:45 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id AD27E3A6A26 for ; Tue, 29 Mar 2011 06:55:43 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTZHlNFjd3TFmc30gOuNsKkogqVhzYfDK@postini.com; Tue, 29 Mar 2011 06:57:23 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 29 Mar 2011 06:54:06 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 29 Mar 2011 09:55:35 -0400 From: Kishore Tiruveedhula To: "lesnix@gmail.com" , "mpls@ietf.org" , "EXT - ofeoktistov@amt.ru" , "dginsburg@gmail.com" , "ext-amolodkin@amt.ru" , "mlasserre@alcatel-lucent.com" , "kompella@alcatel-lucent.com" , "rhthomas@cisco.com" Date: Tue, 29 Mar 2011 09:55:34 -0400 Thread-Topic: [mpls] AddressList TLV in MAC Address Withdraw message Thread-Index: AcvoobuHxBhTckUiTfq1WI+TVtUKdQAABqiw Message-ID: References: <877910.55339.qm@web111902.mail.gq1.yahoo.com> In-Reply-To: <877910.55339.qm@web111902.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A0F87AA600EF73468BA3741CFF49DE4F03605A83A0CEEMBX01WFjnp_" MIME-Version: 1.0 Subject: Re: [mpls] AddressList TLV in MAC Address Withdraw message X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 13:55:52 -0000 --_000_A0F87AA600EF73468BA3741CFF49DE4F03605A83A0CEEMBX01WFjnp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Egor, Regarding including the empty AddressList TLV while withdrawing the MAC add= resses, I think It doesn't make sense to add empty address List TLV as it d= oesn't convey any information. It is not mentioned about including the emp= ty AddressList TLV in addition to MACList TLV in this RFC 4762. Can author= s of RFC 4762 clarify this? And the empty address TLV is not defined in the RFC 5036, So, this would be= treated as Malformed TLV due to short TLV length as there are no addresses= present in the TLV. I think this is valid for any other TLVs also. For ex= ample, if you receive the FEC TLV with no fecs, do you accept empty FEC TLV= ? Do you think accepting empty TLVs valid? Thanks, Kishore ----- Forwarded Message ---- From: Egor Zimin > To: Ina Minei >; Bob Thomas > Cc: mpls@ietf.org; ofeoktistov@amt.ru; dginsburg@gmail.com; amolodkin@amt= .ru Sent: Sun, February 27, 2011 4:23:15 AM Subject: [mpls] AddressList TLV in MAC Address Withdraw message Hi Ina, Few days ago we had a deal with an interesting case of LDP interoperability= . The root cause of our problem was the presence of empty "AddressList" TLV= in LDP MacWithdraw message. Vendor "C" inserts this TLV in every MAC Withdraw message even if there are= no addresses to withdraw. Their explanation: --- "RFC 4762 introduces the MAC List TLV as an optional TLV to the Address Wit= hdraw message, used to withdraw MAC addresses. The addition of this option= al TLV to the Address Withdraw message does not replace the Address List TL= V. While it would be perfectly acceptable to withdraw both IPV4 addresses = as well as MAC addresses in the same Address Withdraw message, it's not alw= ays the case that there is a need to withdraw IPV4 addresses at the same ti= me that there is a need to withdraw MAC addresses. Also, given that the Ad= dress List TLV can not be omitted when sending an Address Message that with= draws MAC Addresses, the logical conclusion is to send an empty Address Lis= t TLV in the Address Withdraw message, along with the MAC List TLV. The emp= ty address list TLV, while not explicitly specified, is not explicitly proh= ibited either. It would have been better had the RFCs been explicit on this= subject, but the above logic is the best solution given the way that the R= FCs are written." --- Vendor "J" implies, that "AddressList" TLV is not mandatory in MACWithdraw = message. They omit this TLV in their messages. However, in addition, they p= erform a strange check for minimal TLV length in all incoming messages. Bec= ause of this check empty AddressList TLV (with length=3D2) considered as "= Malformed TLV" and the session goes down. I haven't found any mention about checking for "too short TLV" in RFC 5036.= However, point #11 in chapter "7. Changes from RFC 3036" states: --- 11. Added case for TLV length too short in the specification for hand= ling malformed TLVs. --- It would be great to know your opinion about these questions: 1. The presence of empty AddressList TLV in MACWithdraw message. Is it mand= atory or optional? 2. Checking incoming TLVs for minimal length. Is it correct behavior ? IMH= O, it should be remembered about Jon Postel's law: "Be liberal in what you = accept, and conservative in what you send" -- Best regards, Egor Zimin _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_A0F87AA600EF73468BA3741CFF49DE4F03605A83A0CEEMBX01WFjnp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Egor,

    Regarding including the empty AddressList TLV while withdrawing= the MAC addresses, I think It doesn’t make sense to add empty addres= s List TLV as it doesn’t convey any information.  It is not ment= ioned about including the empty AddressList TLV in addition to MACList TLV = in this RFC 4762.  Can authors of RFC 4762 clarify this?

     

    And the empty = address TLV is not defined in the RFC 5036, So, this would be treated a= s Malformed TLV due to short TLV length as there are no addresses present i= n the TLV.  I think this is valid for any other TLVs also. For example= , if you receive the FEC TLV with no fecs, do you accept empty FEC TLV?<= /b> Do you think accepting empty TLVs valid?

     

    Thanks,

    Kishore

     

    =

     

    -= ---- Forwarded Message ----
    From: Egor Zimin <lesnix@gmail.com>
    To: Ina Minei <ina@juniper.net>; Bob Thomas <rhthomas@cisco.com>
    Cc: mpls@ietf.org; ofeoktistov@amt.ru; dginsburg@gmail.com; amolodkin= @amt.ru
    Sent: Sun, February 27, 2011 4:23:15 AM
    Subject= : [mpls] AddressList TLV in MAC Address Withdraw message

    Hi Ina,
    Few days ago we had a deal with an interesting case of LDP interopera= bility. The root cause of our problem was the presence of empty "Addre= ssList" TLV in LDP MacWithdraw message.
    Vendor "C" insert= s this TLV in every MAC Withdraw message even if there are no addresses to = withdraw.
    Their explanation:
    ---
    "RFC 4762 introduces the MAC= List TLV as an optional TLV to the Address Withdraw message, used to withd= raw MAC addresses.  The addition of this optional TLV to the Address W= ithdraw message does not replace the Address List TLV.  While it would= be perfectly acceptable to withdraw both IPV4 addresses as well as MAC add= resses in the same Address Withdraw message, it's not always the case that = there is a need to withdraw IPV4 addresses at the same time that there is a= need to withdraw MAC addresses.  Also, given that the Address List TL= V can not be omitted when sending an Address Message that withdraws MAC Add= resses, the logical conclusion is to send an empty Address List TLV in the = Address Withdraw message, along with the MAC List TLV. The empty address li= st TLV, while not explicitly specified, is not explicitly prohibited either= . It would have been better had the RFCs been explicit on this subject, but= the above logic is the best solution given the way that the RFCs are writt= en."
    ---

    Vendor "J" implies, that "AddressLis= t" TLV is not mandatory in MACWithdraw message. They omit this TLV in = their messages. However, in addition, they perform a strange check for mini= mal TLV length in all incoming messages. Because of this check empty Addres= sList TLV  (with length=3D2) considered as "Malformed TLV" a= nd the session goes down.

    I haven't found any mention about checking= for "too short TLV" in RFC 5036. However, point #11 in chapter &= quot;7. Changes from RFC 3036" states:
    ---
          = 11. Added case for TLV length too short in the specification for handling m= alformed TLVs.
    ---
    It would be great to know your opinion about these= questions:
    1. The presence of empty AddressList TLV in MACWithdraw mess= age. Is it mandatory or optional?
    2. Checking incoming TLVs for minimal = length. Is it correct behavior ?  IMHO, it should be remembered about = Jon Postel's law: "Be liberal in what you accept, and conservative in = what you send"

    -- Best regards,
    Egor Zimin

    __________= _____________________________________
    mpls mailing list
    mpls@ietf.org
    https://www.ietf.org/mailman/listinf= o/mpls

     

    = --_000_A0F87AA600EF73468BA3741CFF49DE4F03605A83A0CEEMBX01WFjnp_-- From ping@pingpan.org Tue Mar 29 07:53:51 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6363A68B8 for ; Tue, 29 Mar 2011 07:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 fQ1AmkKaC1Ke for ; Tue, 29 Mar 2011 07:53:50 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with SMTP id 0D1C63A682B for ; Tue, 29 Mar 2011 07:53:49 -0700 (PDT) Received: from source ([209.85.214.174]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTZHy32pykB/LD8vBixH1aU11uZx6kjH8@postini.com; Tue, 29 Mar 2011 07:55:28 PDT Received: by mail-iw0-f174.google.com with SMTP id 34so254946iwn.19 for ; Tue, 29 Mar 2011 07:55:27 -0700 (PDT) Received: by 10.42.238.140 with SMTP id ks12mr9495932icb.414.1301410527102; Tue, 29 Mar 2011 07:55:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.195.202 with HTTP; Tue, 29 Mar 2011 07:54:47 -0700 (PDT) In-Reply-To: <20110314143001.5553.3953.idtracker@localhost> References: <20110314143001.5553.3953.idtracker@localhost> From: Ping Pan Date: Tue, 29 Mar 2011 16:54:47 +0200 Message-ID: To: hejia@huawei.com, lihan@chinamobile.com, elisa.bellagamba@ericsson.com Content-Type: multipart/alternative; boundary=20cf306846392cc835049fa040cf Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-ietf-mpls-tp-csf-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 14:53:51 -0000 --20cf306846392cc835049fa040cf Content-Type: text/plain; charset=ISO-8859-1 Hi, As we have asked during the presentation, this draft is to notify client failures. In the BFD base protocol (Section 4.1, RFC5880), a range of diag code has been defined and can be further extended for reporting the similar failures as indicated here. In practical deployment, it's likely that we would have BFD sessions between MIP's/MEP's, and can be readily used for client failure notification. Just curious, is this draft duplicating the work? Many thanks! - Ping On Mon, Mar 14, 2011 at 3:30 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiprotocol Label Switching Working > Group of the IETF. > > > Title : Indication of Client Failure in MPLS-TP > Author(s) : H. Jia, et al. > Filename : draft-ietf-mpls-tp-csf-01.txt > Pages : 12 > Date : 2011-03-14 > > This document describes a Multi-Protocol Label Switching Transport > Profile (MPLS-TP) Operations, Administration and Maintenance (OAM) > protocol to propagate a client failure indication across an MPLS-TP > network in the case that propagation of failure status in the client > layer is not supported as required in [RFC5860]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-csf-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > --20cf306846392cc835049fa040cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

    As we have asked during the presentation, this draft= is to notify client failures. In the BFD base protocol (Section 4.1, RFC58= 80), a range of diag code has been defined and can be further extended for = reporting the similar failures as indicated here.

    In=A0practical=A0deployment, it's likely that we wo= uld have BFD sessions between MIP's/MEP's, and can be readily used = for client failure notification.

    Just curious, is = this draft duplicating the work?

    Many thanks!

    - Ping


    On Mon, Mar 14, 2011 at 3:30 PM, <Internet-Drafts= @ietf.org> wrote:
    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
    This draft is a work item of the Multiprotocol Label Switching Working Grou= p of the IETF.


    =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Indication of Client Failure in= MPLS-TP
    =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : H. Jia, et al.
    =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-mpls-tp-csf-01.txt
    =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12
    =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-14

    This document describes a Multi-Protocol Label Switching Transport
    Profile (MPLS-TP) Operations, Administration and Maintenance (OAM)
    protocol to propagate a client failure indication across an MPLS-TP
    network in the case that propagation of failure status in the client
    layer is not supported as required in [RFC5860].

    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp= -csf-01.txt

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp= .ietf.org/internet-drafts/

    Below is the data which will enable a MIME compliant mail reader
    implementation to automatically retrieve the ASCII version of the
    Internet-Draft.


    _______________________________________________
    I-D-Announce mailing list
    I-D-Announce@ietf.org
    https://www.ietf.org/mailman/listinfo/i-d= -announce
    Internet-Draft     directories: http://www.ietf.org/shadow.html
    or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


    --20cf306846392cc835049fa040cf-- From yaakov_s@rad.com Tue Mar 29 08:42:51 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68AD23A6981 for ; Tue, 29 Mar 2011 08:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.246 X-Spam-Level: X-Spam-Status: No, score=-102.246 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Xw-qQ92pSTXa for ; Tue, 29 Mar 2011 08:42:50 -0700 (PDT) Received: from antivir1.rad.co.il (antivir1.rad.co.il [62.0.23.193]) by core3.amsl.com (Postfix) with ESMTP id A8A0C3A6A4A for ; Tue, 29 Mar 2011 08:42:48 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir1.rad.co.il with ESMTP; 29 Mar 2011 17:44:25 +0200 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 29 Mar 2011 17:44:25 +0200 Received: from EXRAD5.ad.rad.co.il ([fe80::ec3e:feb5:8bef:e3ba]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Tue, 29 Mar 2011 17:44:25 +0200 From: Yaakov Stein To: "mpls@ietf.org" Thread-Topic: seamless MPLS Thread-Index: AcvuH8gC1BPbKnOiSXS6qnyu9KaPAQ== Date: Tue, 29 Mar 2011 15:44:24 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903D20AE7@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.232.33.112] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC903D20AE7EXRAD5adradcoil_" MIME-Version: 1.0 Subject: [mpls] seamless MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 15:42:51 -0000 --_000_07F7D7DED63154409F13298786A2ADC903D20AE7EXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Before draft-leymann-mpls-seamless-mpls-03 is moved to become a WG draft, I would like to clarify the security implications. The security section of this draft starts very well : In a typical MPLS deployment the use of MPLS is limited to relatively small network consisting of core and edge nodes. Those nodes are under full control of the services provider and placed at locations where only authorized personal has access (this also includes physical access to the nodes). With the extensions of MPLS towards access and aggregation nodes not all nodes will be "locked away" in secure locations. Small access nodes like DSLAMs will be located in street cabinets, potentially offering access to the "interested researcher". I couldn't have stated this any better myself. However it then goes on to say : Nevertheless the unauthorized access to such in device SHOULD NOT impose any security risks to the MPLS infrastructure itself. I would love to hear the reasoning behind this statement. Y(J)S --_000_07F7D7DED63154409F13298786A2ADC903D20AE7EXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Before draft-leymann-mpls-seamless-mpls-03 is moved = to become a WG draft,

    I would like to clarify  the security implicati= ons.

     

    The security section of this draft starts very well = :

     

      = ; In a typical MPLS deployment the use of MPLS is limited to relatively

      = ; small network consisting of core and edge nodes.  Those nodes are

      = ; under full control of the services provider and placed at locations<= /o:p>

      = ; where only authorized personal has access (this also includes<= /span>

      = ; physical access to the nodes).  With the extensions of MPLS towards<= o:p>

      = ; access and aggregation nodes not all nodes will be "locked away"= ; in

      = ; secure locations.  Small access nodes like DSLAMs will be located in=

      = ; street cabinets, potentially offering access to the "interested=

      = ; researcher". 

     =

    I couldn't have stated this any be= tter myself.

    However it then goes on to say :

     

      = ;             &= nbsp; Nevertheless the unauthorized access to such in device

      = ; SHOULD NOT impose any security risks to the MPLS infrastructure

      = ; itself. 

     =

    I would love to hear the reasoning behind this statement.

     

    Y(J)S

     

    --_000_07F7D7DED63154409F13298786A2ADC903D20AE7EXRAD5adradcoil_-- From prvs=1069bc45e1=edwin.mallette@bhnis.com Tue Mar 29 08:51:44 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0D3B3A690E for ; Tue, 29 Mar 2011 08:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 CagpdpO2vHZx for ; Tue, 29 Mar 2011 08:51:43 -0700 (PDT) Received: from mx2.mybrighthouse.com (MX3.mybrighthouse.com [209.16.122.105]) by core3.amsl.com (Postfix) with ESMTP id 5DB1E3A67E4 for ; Tue, 29 Mar 2011 08:51:43 -0700 (PDT) Received: from pps.filterd (mx3 [127.0.0.1]) by mx3.mybrighthouse.com (8.14.3/8.14.3) with SMTP id p2TFnejZ003217; Tue, 29 Mar 2011 11:53:20 -0400 Received: from cntpacas1.corp.local ([10.225.1.123]) by mx3.mybrighthouse.com with ESMTP id vbgrq0h3s-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 29 Mar 2011 11:53:20 -0400 Received: from CNEMAIL.corp.local ([10.225.1.130]) by cntpacas1.corp.local ([10.225.1.123]) with mapi; Tue, 29 Mar 2011 11:53:20 -0400 From: "Mallette, Edwin" To: Yaakov Stein , "mpls@ietf.org" Date: Tue, 29 Mar 2011 11:53:17 -0400 Thread-Topic: [mpls] seamless MPLS Thread-Index: AcvuKW0el0gi8dVsQMWW33OTP5bGBQ== Message-ID: In-Reply-To: <07F7D7DED63154409F13298786A2ADC903D20AE7@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9B7CC09A04Cedwinmallettebhniscom_" MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1103290071 Subject: Re: [mpls] seamless MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 15:51:44 -0000 --_000_C9B7CC09A04Cedwinmallettebhniscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This made me laugh, but I'm going to go out on a limb here and say the type= of access meant was physical access. For instance, if I take out my mons= ter truck and physically access said DSLAM by running over the street cabin= et that wouldn't have any real risk to the MPLS infrastructure =96 just to = the DSLAM. But a slightly modified wording might help. Ed From: Yaakov Stein > Date: Tue, 29 Mar 2011 11:44:24 -0400 To: "mpls@ietf.org" > Subject: [mpls] seamless MPLS Before draft-leymann-mpls-seamless-mpls-03 is moved to become a WG draft, I would like to clarify the security implications. The security section of this draft starts very well : In a typical MPLS deployment the use of MPLS is limited to relatively small network consisting of core and edge nodes. Those nodes are under full control of the services provider and placed at locations where only authorized personal has access (this also includes physical access to the nodes). With the extensions of MPLS towards access and aggregation nodes not all nodes will be "locked away" in secure locations. Small access nodes like DSLAMs will be located in street cabinets, potentially offering access to the "interested researcher". I couldn't have stated this any better myself. However it then goes on to say : Nevertheless the unauthorized access to such in device SHOULD NOT impose any security risks to the MPLS infrastructure itself. I would love to hear the reasoning behind this statement. Y(J)S ________________________________ CONFIDENTIALITY NOTICE: This e-mail may contain information that is privile= ged, confidential or otherwise protected from disclosure. If you are not th= e intended recipient of this e-mail, please notify the sender immediately b= y return e-mail, purge it and do not disseminate or copy it. --_000_C9B7CC09A04Cedwinmallettebhniscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    This made me laugh, but I'm going to go out on a limb here and say the= type of access meant was physical access.   For instance, if I take o= ut my monster truck and physically access said DSLAM by running over the st= reet cabinet that wouldn't have any real risk to the MPLS infrastructure =96 just to the DSLAM.  But a slightl= y modified wording might help.

    Ed

    From: Yaakov Stein <yaakov_s@rad.com>
    Date: Tue, 29 Mar 2011 11:44:24 -04= 00
    To: "mpls@ietf.org" <mpls@i= etf.org>
    Subject: [mpls] seamless MPLS

    Before draft-leymann-mpls-seamless-mpls-03 is moved = to become a WG draft,

    I would like to clarify  the security implicati= ons.

     

    The security section of this draft starts very well = :

     

       In a = typical MPLS deployment the use of MPLS is limited to relatively=

       small= network consisting of core and edge nodes.  Those nodes are

       under= full control of the services provider and placed at locations

       where= only authorized personal has access (this also includes<= /p>

       physi= cal access to the nodes).  With the extensions of MPLS towards

       acces= s and aggregation nodes not all nodes will be "locked away" in

       secur= e locations.  Small access nodes like DSLAMs will be located in

       stree= t cabinets, potentially offering access to the "interested<= /span>

       resea= rcher". 

     <= /span>

    I couldn't have stated this any be= tter myself.

    However it then goes on to say :

     

       =              &n= bsp;Nevertheless the unauthorized access to such in device

       SHOUL= D NOT impose any security risks to the MPLS infrastructure

       itsel= f. 

     <= /span>

    I would love to hear the reasoning behind this statement.

     

    Y(J)S

     


    CONFIDENTIALITY NOTICE: This= e-mail may contain information that is privileged, confidential or otherwi= se protected from disclosure. If you are not the intended recipient of this= e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.
     --_000_C9B7CC09A04Cedwinmallettebhniscom_-- From yaakov_s@rad.com Tue Mar 29 09:07:54 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88E2128C0DE for ; Tue, 29 Mar 2011 09:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.275 X-Spam-Level: X-Spam-Status: No, score=-102.275 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jEa-GvsE3sIN for ; Tue, 29 Mar 2011 09:07:49 -0700 (PDT) Received: from antivir1.rad.co.il (antivir1.rad.co.il [62.0.23.193]) by core3.amsl.com (Postfix) with ESMTP id E35143A6812 for ; Tue, 29 Mar 2011 09:07:46 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir1.rad.co.il with ESMTP; 29 Mar 2011 18:09:23 +0200 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 29 Mar 2011 18:09:23 +0200 Received: from EXRAD5.ad.rad.co.il ([fe80::ec3e:feb5:8bef:e3ba]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Tue, 29 Mar 2011 18:09:22 +0200 From: Yaakov Stein To: "Mallette, Edwin" , "mpls@ietf.org" Thread-Topic: [mpls] seamless MPLS Thread-Index: AcvuH8gC1BPbKnOiSXS6qnyu9KaPAf//8b+A///rY8A= Date: Tue, 29 Mar 2011 16:09:22 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903D20B53@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC903D20AE7@EXRAD5.ad.rad.co.il> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.232.33.112] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC903D20B53EXRAD5adradcoil_" MIME-Version: 1.0 Subject: Re: [mpls] seamless MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 16:07:54 -0000 --_000_07F7D7DED63154409F13298786A2ADC903D20B53EXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That is not quite the kind of attack I was worried about. Someone able to inject packets into an MPLS network can wreak more havoc than a monster truck. Y(J)S From: Mallette, Edwin [mailto:Edwin.Mallette@bhnis.com] Sent: Tuesday, March 29, 2011 18:53 To: Yaakov Stein; mpls@ietf.org Subject: Re: [mpls] seamless MPLS This made me laugh, but I'm going to go out on a limb here and say the type= of access meant was physical access. For instance, if I take out my mons= ter truck and physically access said DSLAM by running over the street cabin= et that wouldn't have any real risk to the MPLS infrastructure - just to th= e DSLAM. But a slightly modified wording might help. Ed From: Yaakov Stein > Date: Tue, 29 Mar 2011 11:44:24 -0400 To: "mpls@ietf.org" > Subject: [mpls] seamless MPLS Before draft-leymann-mpls-seamless-mpls-03 is moved to become a WG draft, I would like to clarify the security implications. The security section of this draft starts very well : In a typical MPLS deployment the use of MPLS is limited to relatively small network consisting of core and edge nodes. Those nodes are under full control of the services provider and placed at locations where only authorized personal has access (this also includes physical access to the nodes). With the extensions of MPLS towards access and aggregation nodes not all nodes will be "locked away" in secure locations. Small access nodes like DSLAMs will be located in street cabinets, potentially offering access to the "interested researcher". I couldn't have stated this any better myself. However it then goes on to say : Nevertheless the unauthorized access to such in device SHOULD NOT impose any security risks to the MPLS infrastructure itself. I would love to hear the reasoning behind this statement. Y(J)S ________________________________ CONFIDENTIALITY NOTICE: This e-mail may contain information that is privile= ged, confidential or otherwise protected from disclosure. If you are not th= e intended recipient of this e-mail, please notify the sender immediately b= y return e-mail, purge it and do not disseminate or copy it. --_000_07F7D7DED63154409F13298786A2ADC903D20B53EXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    That is not quite the = kind of attack I was worried about.

     

    Someone able to inject= packets into an MPLS network

    can wreak more havoc t= han a monster truck.

     

    Y(J)S

     

    From: Mallette= , Edwin [mailto:Edwin.Mallette@bhnis.com]
    Sent: Tuesday, March 29, 2011 18:53
    To: Yaakov Stein; mpls@ietf.org
    Subject: Re: [mpls] seamless MPLS

     

    This ma= de me laugh, but I'm going to go out on a limb here and say the type of acc= ess meant was physical access.   For instance, if I take out my monste= r truck and physically access said DSLAM by running over the street cabinet that wouldn't have any real risk to the= MPLS infrastructure – just to the DSLAM.  But a slightly modifi= ed wording might help.

    &n= bsp;

    Ed=

    &n= bsp;

    From: Yaakov Stein <yaakov_s@rad.com>
    Date: Tue, 29 Mar 2011 11:44:24 -0400
    To: "mpls@ietf.org" &= lt;mpls@ietf.org>
    Subject: [mpls] seamless MPLS

    &n= bsp;

    Before draft-leymann-mpl= s-seamless-mpls-03 is moved to become a WG draft,

    I would like to clarify =  the security implications.

     =

    The security section of = this draft starts very well :

     =

       In a typical MPLS deployment the use of MPLS is limited to re= latively

       small network consisting of core and edge nodes.  Those = nodes are

       under full control of the services provider and placed at loc= ations

       where only authorized personal has access (this also includes=

       physical access to the nodes).  With the extensions of M= PLS towards

       access and aggregation nodes not all nodes will be "lock= ed away" in

       secure locations.  Small access nodes like DSLAMs will b= e located in

       street cabinets, potentially offering access to the "int= erested

       researcher". 

     

    I couldn't h= ave stated this any better myself.<= /o:p>

    However it t= hen goes on to say :

     

                 &= nbsp;   Nevertheless the unauthorized access to such in devi= ce

       SHOULD NOT impose any security risks to the MPLS infrastructu= re

       itself. 

     

    I would love to hear the reasoning behind this state= ment.

     =

    Y(J)S<= /span>

     =

    &n= bsp;

    CONFIDENTIALITY NOTICE: This e-mail may contain information tha= t is privileged, confidential or otherwise protected from disclosure. If yo= u are not the intended recipient of this e-mail, please notify the sender immediately by return e= -mail, purge it and do not disseminate or copy it.

    --_000_07F7D7DED63154409F13298786A2ADC903D20B53EXRAD5adradcoil_-- From lesnix@gmail.com Tue Mar 29 12:22:28 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357C53A6A2E for ; Tue, 29 Mar 2011 12:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 l1B8GP0R8Fp2 for ; Tue, 29 Mar 2011 12:22:19 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B4EF23A693C for ; Tue, 29 Mar 2011 12:22:18 -0700 (PDT) Received: by bwz13 with SMTP id 13so481990bwz.31 for ; Tue, 29 Mar 2011 12:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=w0RT4aYHYIoRVZbrPwff76Hwj/zq+fsbaA+x/k+QuSo=; b=ik6uQZIzpuGeqwQK2NSGsqeE8HQm/dYGSCMIr13QUBzscWB8eUf62Rh5bKxdL2vbo/ IRwRG/jxKxVHBHJ9tpy3XMe1qFRGTf2l+n6OLFty185d4HqcTwJdaO9frxd8IWd0X503 M0zevquSA0VlG4U/JZJeods/hUqGZLKozZURg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=GifitELSxMKk6YMD0Mo6iPwkaX3ms53SnfIWn4XXYwZi+JspmSRMnnA6eKEyZhoyXa 6SbowBudPLH4yS8GT38JvHQohX9CRtiNTdFPGpm8hAGQU5aOiT4q+ZohTg+2DTPzaPLv dSoz3/8pNDMDfdHw1qr9yL1E0rxxq1ELzl8yY= Received: by 10.204.127.29 with SMTP id e29mr233733bks.52.1301426636436; Tue, 29 Mar 2011 12:23:56 -0700 (PDT) Received: from [192.168.88.144] (home.lesnix.ru [80.251.120.67]) by mx.google.com with ESMTPS id z18sm3641067bkf.20.2011.03.29.12.23.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2011 12:23:52 -0700 (PDT) Message-ID: <4D9231C4.6020800@gmail.com> Date: Tue, 29 Mar 2011 23:23:48 +0400 From: Egor Zimin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Kishore Tiruveedhula References: <877910.55339.qm@web111902.mail.gq1.yahoo.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060106030609060000060807" Cc: "mpls@ietf.org" , "ext-amolodkin@amt.ru" , "rhthomas@cisco.com" , "EXT - ofeoktistov@amt.ru" , "dginsburg@gmail.com" , "kompella@alcatel-lucent.com" , "mlasserre@alcatel-lucent.com" Subject: Re: [mpls] AddressList TLV in MAC Address Withdraw message X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 19:22:28 -0000 This is a multi-part message in MIME format. --------------060106030609060000060807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kishore, Probably yes. Probably it doesn't make sense to add empty address List TLV. And - yes, it would be great if authors of 4762 clarified this. However, what we have right now: 1. MAC Address Withdraw Message and Address Withdraw Message use the same message type (0x0301) 2. Address List TLV is mandatory in Address Withdraw message (http://tools.ietf.org/html/rfc5036#section-3.5.6) 3. However, we have no ipv4 addresses to withdraw So, in this case the only way to meet all three conditions mentioned is to include empty AddressList TLV in MAC Address Withdraw Message. Next. Why you decide, that empty AddressList TLV is Malformed ? Are there any mentions about "too short TLV length" checking in 5036 ? If no, is it liberal behavior ? So: yes, I think, accepting empty TLV is valid in this case. Regarding your question about FEC TLV: FEC TLV is also mandatory in Label Mapping Message. If we have no FECs to advertise, we shouldn't send Label Mapping Message iirc. However, if there is any _other_ reason why we must send Label Mapping Message, than YES, we should include empty FEC TLV in this message. And this Message must be accepted. Because there is no any mention about "too short TLV length" check in 5036. And we should be liberal in what we accept. P.S. By the way, this question was already asked by Vivienne(wanglixing at huawei.com): http://www.ietf.org/mail-archive/web/mpls/current/msg01708.html And there is still no answer. And what is the most terrible thing: Two leading vendors break absolutely legitimate design - pseudowire redundancy, where pseudowire has "C" as the first PE and "J" as the primary_second_PE and backup_second_PE. Just because of this "room for interpretation". 29.03.2011 17:55, Kishore Tiruveedhula ?????: > > Egor, > > Regarding including the empty AddressList TLV while withdrawing the > MAC addresses, I think It doesn't make sense to add empty address List > TLV as it doesn't convey any information. It is not mentioned about > including the empty AddressList TLV in addition to MACList TLV in this > RFC 4762. Can authors of RFC 4762 clarify this? > > And the *empty address TLV* is not defined in the RFC 5036, So, this > would be treated as Malformed TLV due to short TLV length as there are > no addresses present in the TLV. I think this is valid for any other > TLVs also. For example, if you receive the FEC TLV with no fecs, do > you accept *empty FEC TLV?* Do you think accepting empty TLVs valid? > > Thanks, > > Kishore > > ----- Forwarded Message ---- > *From:* Egor Zimin > > *To:* Ina Minei >; Bob Thomas > > > *Cc:* mpls@ietf.org ; ofeoktistov@amt.ru > ; dginsburg@gmail.com > ; amolodkin@amt.ru > *Sent:* Sun, February 27, 2011 4:23:15 AM > *Subject:* [mpls] AddressList TLV in MAC Address Withdraw message > > Hi Ina, > > Few days ago we had a deal with an interesting case of LDP > interoperability. The root cause of our problem was the presence of > empty "AddressList" TLV in LDP MacWithdraw message. > Vendor "C" inserts this TLV in every MAC Withdraw message even if > there are no addresses to withdraw. > Their explanation: > --- > "RFC 4762 introduces the MAC List TLV as an optional TLV to the > Address Withdraw message, used to withdraw MAC addresses. The > addition of this optional TLV to the Address Withdraw message does not > replace the Address List TLV. While it would be perfectly acceptable > to withdraw both IPV4 addresses as well as MAC addresses in the same > Address Withdraw message, it's not always the case that there is a > need to withdraw IPV4 addresses at the same time that there is a need > to withdraw MAC addresses. Also, given that the Address List TLV can > not be omitted when sending an Address Message that withdraws MAC > Addresses, the logical conclusion is to send an empty Address List TLV > in the Address Withdraw message, along with the MAC List TLV. The > empty address list TLV, while not explicitly specified, is not > explicitly prohibited either. It would have been better had the RFCs > been explicit on this subject, but the above logic is the best > solution given the way that the RFCs are written." > --- > > Vendor "J" implies, that "AddressList" TLV is not mandatory in > MACWithdraw message. They omit this TLV in their messages. However, in > addition, they perform a strange check for minimal TLV length in all > incoming messages. Because of this check empty AddressList TLV (with > length=2) considered as "Malformed TLV" and the session goes down. > > I haven't found any mention about checking for "too short TLV" in RFC > 5036. However, point #11 in chapter "7. Changes from RFC 3036" states: > --- > 11. Added case for TLV length too short in the specification for > handling malformed TLVs. > --- > It would be great to know your opinion about these questions: > 1. The presence of empty AddressList TLV in MACWithdraw message. Is it > mandatory or optional? > 2. Checking incoming TLVs for minimal length. Is it correct behavior > ? IMHO, it should be remembered about Jon Postel's law: "Be liberal > in what you accept, and conservative in what you send" > > -- Best regards, > Egor Zimin > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Best regards, Egor Zimin --------------060106030609060000060807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Kishore,

    Probably yes. Probably it doesn't make sense to add empty address List TLV.
    And - yes, it would be great if authors of 4762 clarified this.

    However, what we have right now:
    1. MAC Address Withdraw Message and Address Withdraw Message use the same message type (0x0301)
    2. Address List TLV is mandatory in Address Withdraw message (http://tools.ietf.org/html/rfc5036#section-3.5.6)
    3. However, we have no ipv4 addresses to withdraw
    So, in this case the only way to meet all three conditions mentioned is to include empty AddressList TLV in MAC Address Withdraw Message.

    Next.
    Why you decide, that empty AddressList TLV is Malformed ? Are there any mentions about "too short TLV length" checking in 5036 ?
    If no, is it liberal behavior ?
    So: yes, I think, accepting empty TLV is valid in this case.

    Regarding your question about FEC TLV:
    FEC TLV is also mandatory in Label Mapping Message. If we have no FECs to advertise, we shouldn't send Label Mapping Message iirc. However, if there is any _other_ reason why we must send Label Mapping Message, than YES, we should include empty FEC TLV in this message. And this Message must be accepted. Because there is no any mention about "too short TLV length" check in 5036. And we should be liberal in what we accept.


    P.S. By the way, this question was already asked by Vivienne(wanglixing at huawei.com):
    http://www.ietf.org/mail-archive/web/mpls/current/msg01708.html
    And there is still no answer.

    And what is the most terrible thing:
    Two leading vendors break absolutely legitimate design - pseudowire redundancy, where pseudowire has "C" as the first PE and "J" as the primary_second_PE and backup_second_PE. Just because of this "room for interpretation".

    29.03.2011 17:55, Kishore Tiruveedhula пишет:

    Egor,

    Regarding including the empty AddressList TLV while withdrawing the MAC addresses, I think It doesn’t make sense to add empty address List TLV as it doesn’t convey any information.  It is not mentioned about including the empty AddressList TLV in addition to MACList TLV in this RFC 4762.  Can authors of RFC 4762 clarify this?

     

    And the empty address TLV is not defined in the RFC 5036, So, this would be treated as Malformed TLV due to short TLV length as there are no addresses present in the TLV.  I think this is valid for any other TLVs also. For example, if you receive the FEC TLV with no fecs, do you accept empty FEC TLV? Do you think accepting empty TLVs valid?

     

    Thanks,

    Kishore

     

     

    ----- Forwarded Message ----
    From: Egor Zimin <lesnix@gmail.com>
    To: Ina Minei <ina@juniper.net>; Bob Thomas <rhthomas@cisco.com>
    Cc: mpls@ietf.org; ofeoktistov@amt.ru; dginsburg@gmail.com; amolodkin@amt.ru
    Sent: Sun, February 27, 2011 4:23:15 AM
    Subject: [mpls] AddressList TLV in MAC Address Withdraw message

    Hi Ina,

    Few days ago we had a deal with an interesting case of LDP interoperability. The root cause of our problem was the presence of empty "AddressList" TLV in LDP MacWithdraw message.
    Vendor "C" inserts this TLV in every MAC Withdraw message even if there are no addresses to withdraw.
    Their explanation:
    ---
    "RFC 4762 introduces the MAC List TLV as an optional TLV to the Address Withdraw message, used to withdraw MAC addresses.  The addition of this optional TLV to the Address Withdraw message does not replace the Address List TLV.  While it would be perfectly acceptable to withdraw both IPV4 addresses as well as MAC addresses in the same Address Withdraw message, it's not always the case that there is a need to withdraw IPV4 addresses at the same time that there is a need to withdraw MAC addresses.  Also, given that the Address List TLV can not be omitted when sending an Address Message that withdraws MAC Addresses, the logical conclusion is to send an empty Address List TLV in the Address Withdraw message, along with the MAC List TLV. The empty address list TLV, while not explicitly specified, is not explicitly prohibited either. It would have been better had the RFCs been explicit on this subject, but the above logic is the best solution given the way that the RFCs are written."
    ---

    Vendor "J" implies, that "AddressList" TLV is not mandatory in MACWithdraw message. They omit this TLV in their messages. However, in addition, they perform a strange check for minimal TLV length in all incoming messages. Because of this check empty AddressList TLV  (with length=2) considered as "Malformed TLV" and the session goes down.

    I haven't found any mention about checking for "too short TLV" in RFC 5036. However, point #11 in chapter "7. Changes from RFC 3036" states:
    ---
          11. Added case for TLV length too short in the specification for handling malformed TLVs.
    ---
    It would be great to know your opinion about these questions:
    1. The presence of empty AddressList TLV in MACWithdraw message. Is it mandatory or optional?
    2. Checking incoming TLVs for minimal length. Is it correct behavior ?  IMHO, it should be remembered about Jon Postel's law: "Be liberal in what you accept, and conservative in what you send"

    -- Best regards,
    Egor Zimin

    _______________________________________________
    mpls mailing list
    mpls@ietf.org
    https://www.ietf.org/mailman/listinfo/mpls

     


    -- 
Best regards, 
 Egor Zimin
    --------------060106030609060000060807-- From cdl@asgaard.org Tue Mar 29 13:43:38 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEBB83A6A2E for ; Tue, 29 Mar 2011 13:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 xTV6bBn9Ss2C for ; Tue, 29 Mar 2011 13:43:37 -0700 (PDT) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by core3.amsl.com (Postfix) with ESMTP id 6AA5D3A6981 for ; Tue, 29 Mar 2011 13:43:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id DE8291E260E; Tue, 29 Mar 2011 20:45:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gh3eZkrPe0ma; Tue, 29 Mar 2011 20:45:15 +0000 (UTC) Received: from fenrir.asgaard.org (fenrir.asgaard.org [204.29.152.154]) by asgaard.org (Postfix) with ESMTPSA id B32B01E25F9; Tue, 29 Mar 2011 20:45:13 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-93-1001753582" From: Christopher LILJENSTOLPE In-Reply-To: <07F7D7DED63154409F13298786A2ADC903D20B53@EXRAD5.ad.rad.co.il> Date: Wed, 30 Mar 2011 07:45:00 +1100 Message-Id: References: <07F7D7DED63154409F13298786A2ADC903D20AE7@EXRAD5.ad.rad.co.il> <07F7D7DED63154409F13298786A2ADC903D20B53@EXRAD5.ad.rad.co.il> To: Yaakov Stein Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1082) Cc: "mpls@ietf.org" , "Mallette, Edwin" Subject: Re: [mpls] seamless MPLS X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 20:43:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-93-1001753582 Content-Type: multipart/alternative; boundary=Apple-Mail-92-1001753516 --Apple-Mail-92-1001753516 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, Let me second this set of concerns. In an SP network, I can elect not = to extend my IGP into uncontrolled spaces, and, instead use control = plane protocols that I can apply policy to (BGP comes to mind). The = document does talk about hierarchy, and using BGP to distribute labels = (anyone care to think about the number of non-aggregateable labels in a = large network that BGP would have to distribute, btw?). However, there = is no mention of the security implications of defining the correct (or = incorrect) aggregation/protocol boundary. =20 In the not too distant future, some lazy operator decides that statics = are too hard, and extends the IGP down to the access nodes (which are = not physically controlled - may even be on customer prem) - Customer = does some "research" and injects routes into said IGP after = circumventing default passwords - sit back and watch the fun and = fireworks. Anyone who says that the service provider won't be lazy = and/or won't deploy with default or well-known passwords - I have MANY = cases to prove otherwise.... If we think this work is valid, then we REALLY need to cover this in = detail in the architecture and security sections. I am not, however, = indicating that I do think it is a good idea.... Chris On 30Mar2011, at 03.09, Yaakov Stein wrote: > That is not quite the kind of attack I was worried about. >=20 > Someone able to inject packets into an MPLS network > can wreak more havoc than a monster truck. >=20 > Y(J)S >=20 > From: Mallette, Edwin [mailto:Edwin.Mallette@bhnis.com] > Sent: Tuesday, March 29, 2011 18:53 > To: Yaakov Stein; mpls@ietf.org > Subject: Re: [mpls] seamless MPLS >=20 > This made me laugh, but I'm going to go out on a limb here and say the = type of access meant was physical access. For instance, if I take out = my monster truck and physically access said DSLAM by running over the = street cabinet that wouldn't have any real risk to the MPLS = infrastructure - just to the DSLAM. But a slightly modified wording = might help. >=20 > Ed >=20 > From: Yaakov Stein > > Date: Tue, 29 Mar 2011 11:44:24 -0400 > To: "mpls@ietf.org" = > > Subject: [mpls] seamless MPLS >=20 > Before draft-leymann-mpls-seamless-mpls-03 is moved to become a WG = draft, > I would like to clarify the security implications. >=20 > The security section of this draft starts very well : >=20 > In a typical MPLS deployment the use of MPLS is limited to = relatively > small network consisting of core and edge nodes. Those nodes are > under full control of the services provider and placed at locations > where only authorized personal has access (this also includes > physical access to the nodes). With the extensions of MPLS towards > access and aggregation nodes not all nodes will be "locked away" in > secure locations. Small access nodes like DSLAMs will be located in > street cabinets, potentially offering access to the "interested > researcher". >=20 > I couldn't have stated this any better myself. > However it then goes on to say : >=20 > Nevertheless the unauthorized access to such in device > SHOULD NOT impose any security risks to the MPLS infrastructure > itself. >=20 > I would love to hear the reasoning behind this statement. >=20 > Y(J)S >=20 >=20 > ________________________________ > CONFIDENTIALITY NOTICE: This e-mail may contain information that is = privileged, confidential or otherwise protected from disclosure. If you = are not the intended recipient of this e-mail, please notify the sender = immediately by return e-mail, purge it and do not disseminate or copy = it. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --- =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc --Apple-Mail-92-1001753516 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

    If we think this work is valid, = then we REALLY need to cover this in detail in the architecture and = security sections.  I am not, however, indicating that I do think = it is a good = idea....

    Chris

    On 30Mar2011, at 03.09, Yaakov Stein wrote:

    That = is not quite the kind of attack I was worried about.

    Someone able = to inject packets into an MPLS network
    can wreak more havoc than a = monster truck.

    Y(J)S

    From: Mallette, Edwin = [mailto:Edwin.Mallette@bhnis.com]
    Sent: Tuesday, March 29, 2011 = 18:53
    To: Yaakov Stein; mpls@ietf.org
    Subject: Re: [mpls] = seamless MPLS

    This made me laugh, but I'm going to go out on a = limb here and say the type of access meant was physical access. =   For instance, if I take out my monster truck and physically = access said DSLAM by running over the street cabinet that wouldn't have = any real risk to the MPLS infrastructure - just to the DSLAM.  But = a slightly modified wording might help.

    Ed

    From: Yaakov = Stein <yaakov_s@rad.com<mailto:yaakov_s@rad.com>>
    Da= te: Tue, 29 Mar 2011 11:44:24 -0400
    To: "mpls@ietf.org<mailto:mpls@ietf.org>" = <mpls@ietf.org<mailto:mpls@ietf.org>>
    Subject:= [mpls] seamless MPLS

    Before draft-leymann-mpls-seamless-mpls-03 = is moved to become a WG draft,
    I would like to clarify  the = security implications.

    The security section of this draft starts = very well :

      In a typical MPLS deployment the use of = MPLS is limited to relatively
      small network consisting = of core and edge nodes.  Those nodes are
      under full = control of the services provider and placed at locations
    =   where only authorized personal has access (this also = includes
      physical access to the nodes).  With the = extensions of MPLS towards
      access and aggregation nodes = not all nodes will be "locked away" in
      secure locations. =  Small access nodes like DSLAMs will be located in
    =   street cabinets, potentially offering access to the = "interested
      researcher".

    I couldn't have stated = this any better myself.
    However it then goes on to say :

    =             &n= bsp;   Nevertheless the unauthorized access to such in = device
      SHOULD NOT impose any security risks to the MPLS = infrastructure
      itself.

    I would love to hear the = reasoning behind this = statement.

    Y(J)S


    ________________________________
    CON= FIDENTIALITY NOTICE: This e-mail may contain information that is = privileged, confidential or otherwise protected from disclosure. If you = are not the intended recipient of this e-mail, please notify the sender = immediately by return e-mail, purge it and do not disseminate or copy = it.
    _______________________________________________
    mpls mailing = list
    mpls@ietf.org
    https://www.ietf.org/m= ailman/listinfo/mpls


= --Apple-Mail-92-1001753516-- --Apple-Mail-93-1001753582 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJNkkTXAAoJEGmx2Mt/+Iw/MNIH/1Ss/xADH90HhxyYR3hWDlna CYGPXabYv0tJRSZCh9jcG5DT+LApCoP82/oUuqOqmzmhtfQ+DGu1bxhp4W9JDGHP bS25SW17UdRPvHNYhgm7UkFhgj22ABvR3EtvYtMpF87zwJeou+C/DgQ3OOkMCeRk HG3u8+N+RFeL/dl8VstpfJh3W+yYBpH7MrZZ8ZPAkw6eoCPzJrg8Wy+xpZ6BPnPH fMzzG8N2jXInzT2wq2sQoQePCZhtMd2I0oDW5JaMIUYZ5WtmW3ATp6SWn1flxmzv LOKihkcVjbwROeHHZfL07KCEzQo9JjSVP8JR51wLnvq1Sc7MEl93eodfjWEKUSo= =oZa4 -----END PGP SIGNATURE----- --Apple-Mail-93-1001753582-- From loa@pi.nu Tue Mar 29 21:10:26 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620093A6A37 for ; Tue, 29 Mar 2011 21:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 i685p63I0VxQ for ; Tue, 29 Mar 2011 21:10:25 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 4E9893A6999 for ; Tue, 29 Mar 2011 21:10:25 -0700 (PDT) Received: from [130.129.22.69] (dhcp-1645.meeting.ietf.org [130.129.22.69]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 594E52A8001 for ; Wed, 30 Mar 2011 06:12:02 +0200 (CEST) Message-ID: <4D92AD8F.9090808@pi.nu> Date: Wed, 30 Mar 2011 06:11:59 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] the mpls wg meeting on Thursday March 31 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 04:10:26 -0000 Working group, it has been pointed out that I had an error in my wg status slides yesterday. The working group meeting on Thursday will be *1740-1940 in Congress III* /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From rcallon@juniper.net Wed Mar 30 00:40:43 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342843A6A1F for ; Wed, 30 Mar 2011 00:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 gNuK+mT7LqGq for ; Wed, 30 Mar 2011 00:40:39 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id AD6753A676A for ; Wed, 30 Mar 2011 00:40:38 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTZLe2WdRZLsYugBvzSCO4wan1q7/FEzP@postini.com; Wed, 30 Mar 2011 00:42:17 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 30 Mar 2011 00:36:54 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 30 Mar 2011 03:38:24 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Wed, 30 Mar 2011 03:38:21 -0400 Thread-Topic: [80all] Wednesday 3-30-2011 Agenda Change Thread-Index: AcvuqD3PQGLOKt07QTydzWC1hyvyGQABOugw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_DF7F294AF4153D498141CBEFADB17704C1F70EB4D8EMBX01WFjnprn_" MIME-Version: 1.0 Subject: [mpls] FW: [80all] Wednesday 3-30-2011 Agenda Change X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 07:40:43 -0000 --_004_DF7F294AF4153D498141CBEFADB17704C1F70EB4D8EMBX01WFjnprn_ Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C1F70EB4D8EMBX01WFjnprn_" --_000_DF7F294AF4153D498141CBEFADB17704C1F70EB4D8EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please note the room change for today's Routing Area Open Meeting. This pro= vides a larger room, which is good since this meeting should be of interest= to many, including participants in the MPLS WG. Thanks, Ross From: 80all-bounces@ietf.org [mailto:80all-bounces@ietf.org] On Behalf Of W= anda Lo Sent: Wednesday, March 30, 2011 3:01 AM To: 80all@ietf.org Subject: [80all] Wednesday 3-30-2011 Agenda Change Hi Everyone, There's a room change in today's afternoon session I (13:00-15:00). RTGAREA has moved to Congress Hall II. CLUE has moved to Congress Hall I. Please note it in on your pocket agenda to reflect the change. Of course, = the agenda on the IETF website (https://datatracker.ietf.org/meeting/80/age= nda.html) always has the most up-to-date information. Thanks, Wanda =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Wanda Lo Internet Engineering Task Force (IETF) 48377 Fremont Blvd., Ste. 117 Fremont, California 94538 / USA +1-510-492-4082 +1-510-492-4001 (fax) www.ietf.org -- Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com --_000_DF7F294AF4153D498141CBEFADB17704C1F70EB4D8EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please note the room change for today’s Routing Area Open = Meeting. This provides a larger room, which is good since this meeting shou= ld be of interest to many, including participants in the MPLS WG.

 

Thanks, Ross

 

= From:= 80all-bounces@ietf.org [mailto:80all-bounces@ietf.org] On Behalf Of Wanda Lo
Sent: Wednesday, March 30, 2011 3:01 AM
To: 8= 0all@ietf.org
Subject: [80all] Wednesday 3-30-2011 Agenda Change<= o:p>

 

=

Hi Everyone,

<= o:p> 

There's a room change i= n today's afternoon session I (13:00-15:00).

 

RTGARE= A has moved to Congress Hall II.

 

CLUE has moved to = Congress Hall I.

 <= /o:p>

Please note it in on your pocket a= genda to reflect the change.  Of course, the agenda on the IETF websit= e (https://= datatracker.ietf.org/meeting/80/agenda.html) always has the most up-to-= date information.

 =

 

<= p class=3DMsoNormal>Thanks,

W= anda 

 <= /p>

 <= /o:p>

 

 

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black= '>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Wanda Lo<= /o:p>

Internet Engineering Tas= k Force (IETF)

48377 Fremont Blvd., Ste. 117 
Fremo= nt, California 94538 / USA 
+1-510-492-4082&nbs= p;
+1-510-492-4001 (fax) 
www.ietf.org

 =

--<= span style=3D'color:black'>

Managed by Association Management Solutions (AMS)

Forum Management, Meeting and Event Planning

 



 

= --_000_DF7F294AF4153D498141CBEFADB17704C1F70EB4D8EMBX01WFjnprn_-- --_004_DF7F294AF4153D498141CBEFADB17704C1F70EB4D8EMBX01WFjnprn_ Content-Type: text/plain; name="ATT00001..txt" Content-Description: ATT00001..txt Content-Disposition: attachment; filename="ATT00001..txt"; size=130; creation-date="Wed, 30 Mar 2011 03:01:06 GMT"; modification-date="Wed, 30 Mar 2011 03:01:06 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCjgwYWxsIG1h aWxpbmcgbGlzdA0KODBhbGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vODBhbGwNCg== --_004_DF7F294AF4153D498141CBEFADB17704C1F70EB4D8EMBX01WFjnprn_-- From swallow@cisco.com Wed Mar 30 01:06:25 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C0A3A6B23 for ; Wed, 30 Mar 2011 01:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.726 X-Spam-Level: X-Spam-Status: No, score=-109.726 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, 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 U82Aj1bgiid6 for ; Wed, 30 Mar 2011 01:06:24 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 26C493A6AF5 for ; Wed, 30 Mar 2011 01:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swallow@cisco.com; l=10113; q=dns/txt; s=iport; t=1301472483; x=1302682083; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=UoCsYQNg2gh3bUOmM0YQhvlC6P+P/mVeIio7RCtvOW0=; b=h9EfEj1M+JMiV7t6UDNq+4EsL7AypnqKGw3tnmUu9+/HUYlwz5hG1X49 VFe8SWMKvCHuHDNGowQnOc3mb9BE/4VKUhcUbycUn2be1WvC5TdBj3+/s /Eu7cb5+SBX6u6BWn0n7TGzKmrj2ae6yOang5AdbfVDhycmk/bbobTA7n c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0HALbkkk2tJV2d/2dsb2JhbACCXpVyjCFbd6BsnEyDFoJUBIU/h0eDWw X-IronPort-AV: E=Sophos;i="4.63,267,1299456000"; d="scan'208,217";a="228050542" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 30 Mar 2011 08:07:51 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2U87pQa002714 for ; Wed, 30 Mar 2011 08:07:51 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 03:07:52 -0500 Received: from 10.55.83.169 ([10.55.83.169]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 Mar 2011 08:07:51 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 30 Mar 2011 04:07:50 -0500 From: George Swallow To: Message-ID: Thread-Topic: Routing Area Open Meeting room change Thread-Index: AcvurOL/MaRaJ7S1RLOW7PExS1FFqQABKzUN In-Reply-To: <0bb501cbeeac$e6a72390$b3f56ab0$@huawei.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3384302870_218499155" X-OriginalArrivalTime: 30 Mar 2011 08:07:52.0140 (UTC) FILETIME=[911CD8C0:01CBEEB1] Subject: [mpls] FW: Routing Area Open Meeting room change X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:06:25 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3384302870_218499155 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit FYI - ...George ------ Forwarded Message From: Adrian Farrel Reply-To: Adrian Farrel Date: Wed, 30 Mar 2011 09:34:25 +0200 To: Cc: Subject: Routing Area Open Meeting room change Fortunately, this is only a change to the next-door room. Chairs: Notifying your WGs might be good. From: 80all-bounces@ietf.org [mailto:80all-bounces@ietf.org] On Behalf Of Wanda Lo Sent: 30 March 2011 09:01 To: 80all@ietf.org Subject: [80all] Wednesday 3-30-2011 Agenda Change Hi Everyone, There's a room change in today's afternoon session I (13:00-15:00). RTGAREA has moved to Congress Hall II. CLUE has moved to Congress Hall I. Please note it in on your pocket agenda to reflect the change. Of course, the agenda on the IETF website (https://datatracker.ietf.org/meeting/80/agenda.html) always has the most up-to-date information. Thanks, Wanda =========================== Wanda Lo Internet Engi neering span style='mso-fareast-font-family:"Times New Roman";color:black'> 48377 Fremont Blvd., Ste. 117 Fremont, California 94538 / USA +1-510-492-4082 +1-510-492-4001 (fax) www.ietf.org -- Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com ------ End of Forwarded Message --B_3384302870_218499155 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable FW: Routing Area Open Meeting room change FYI -

...George


------ Forwarded Message
From: Adrian Farrel <Adrian.Fa= rrel@huawei.com>
Reply-To: Adrian Farrel <Adria= n.Farrel@huawei.com>
Date: Wed, 30 Mar 2011 09:34:25 +0200
To: <routing-discussion@iet= f.org>
Cc: <rtg-chairs@ietf.org> Subject: Routing Area Open Meeting room change

Fo= rtunately, this is only a change to the next-door room.
 
Chairs: Notifying your WGs might be good.
 
 

From: 80all-bounces@i= etf.org [mailto:80all-bounces@ie= tf.org] On Behalf Of Wanda Lo
Sent: 30 March 2011 09:01
To: 80all@ietf.org
Subject: [80all] Wednesday 3-30-2011 Agenda Change
Hi Everyone,

There's a room change in today's afternoon session I (13:00-15:0= 0).

RTGAREA has moved to Congress Hall II.

CLUE has moved to Congress Hall I.

Please note it in on your pocket agenda to reflect the change.  Of cou= rse, the agenda on the IETF website (https://datatracker.ietf.org/meeting/80/agenda.html) always has the most up-to-date information.



Thanks,

Wanda









=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Wanda Lo

Internet Engi neering span style=3D'mso-fareast-fon= t-family:"Times New Roman";color:black'>

48377 Fremont Blvd., Ste. 117
Fremont, California 94538 / USA
+1-510-492-4082
+1-510-492-4001 (fax)
www.ietf.org <ht= tp://www.ietf.org/>



--

Managed by Association Management Solutions (AMS)

Forum Management, Meeting and Event Planning

www.amsl.com <http://www.amsl.com/>

 


------ End of Forwarded Message
 --B_3384302870_218499155-- From Manuel.Paul@telekom.de Wed Mar 30 07:30:15 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66EAD3A687D for ; Wed, 30 Mar 2011 07:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 z4wM-YB23hW9 for ; Wed, 30 Mar 2011 07:30:13 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 2AC303A67EF for ; Wed, 30 Mar 2011 07:30:11 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail31.telekom.de with ESMTP; 30 Mar 2011 16:31:47 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 16:31:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 30 Mar 2011 16:31:30 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-cv-03 Thread-Index: AQHL7UEzNDkNsNSfrUy2+prVZl2z35RCj7sAgAAj/7CAAzkQQA== References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu><791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd><791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> From: To: , , X-OriginalArrivalTime: 30 Mar 2011 14:31:46.0677 (UTC) FILETIME=[32C44250:01CBEEE7] Cc: mpls@ietf.org Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 14:30:15 -0000 DQpEZWFyIEFsbCwNCg0KSSByZWFsbHkgYXBwcmVjaWF0ZSB0aGUgY29uc2lkZXJhdGlvbiBvbiB0 aGUgcGVyLWludGVyZmFjZSBNSVAgc3VwcG9ydCBhbmQgdGhlIGRpc2N1c3Npb24gbW92aW5nIGZv cndhcmQuDQoNCg0KRnJvbSBhbiBvcGVyYXRvcidzIHBlcnNwZWN0aXZlLCBpdCBpcyB2ZXJ5IGlt cG9ydGFudCB0aGF0IHRoZSBzdXBwb3J0IGZvciBwZXItaW50ZXJmYWNlIE1JUHMgaXMgY292ZXJl ZCBieSB0aGUgZGVmaW5pdGlvbnMuDQoNCkxvb2tpbmcgYXQgZWFybGllciB2ZXJzaW9ucyBvZiBk cmFmdC1mYXJyZWwtbXBscy10cC1taXAtbWVwLW1hcCwgdGhlcmUgd2FzIGFscmVhZHkgYSBzb2x1 dGlvbiBwcm9wb3NhbCwgdXNpbmcgdGhlIFRUTC4gRW5oYW5jZWQgc29sdXRpb25zIGhhdmUgYmVl biB0aG9yb3VnbHkgZGlzY3Vzc2VkIGR1cmluZyB0aGlzIElFVEYgbWVldGluZy4gSXQgaXQgdG8g YmUgZXhwZWN0ZWQgdGhhdCB0aGVyZSB3aWxsIGJlIHdheXMgdG8gc29sdmUgYm90aCB0aGUgZmFz dCBwYXRoIGFuZCBmYXRlLXNoYXJpbmcgcmVxdWlyZW1lbnQuDQoNCg0KSSBzZWNvbmQgdGhlIHBy b3Bvc2FsIGluaXRpYWxseSBtYWRlIGJ5IFJvbGYsIHRvIGluY2x1ZGUgYWRkaXRpb25hbCB0ZXh0 IHRvIGRvY3VtZW50IHRoZSBwZXItaW50ZXJmYWNlIE1JUCBhZGRyZXNzaW5nIGZvciB0aGUgb24t ZGVtYW5kLWN2IGFuZCBmb3Igb3RoZXIgT0FNIHRvb2xzLiANCg0KDQpCZXN0IHJlZ2FyZHMsDQpN YW51ZWwgDQoNCg0KRGV1dHNjaGUgVGVsZWtvbSBBRw0KR3JvdXAgVGVjaG5vbG9neQ0KTWFudWVs IFBhdWwNClNBMy0xMQ0KR29zbGFyZXIgVWZlciAzNS0zNywgMTA1ODkgQmVybGluDQorNDkgMzAg MzQ5NyAtIDQzOTQgKFRlbC4pDQorNDkgMzAgMzQ5NyAtIDQ5NTYgKEZheCkNCis0OSAxNzEgIDg2 MzQwMzIgKE1vYmlsKQ0KRS1NYWlsOiBtYWlsdG86bWFudWVsLnBhdWxAdGVsZWtvbS5kZQ0KaHR0 cDovL3d3dy50ZWxla29tLmNvbSAgICANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZg0KPiBSb2xmIFdpbnRlcg0KPiBTZW50OiBNb25kYXksIE1hcmNoIDI4 LCAyMDExIDM6MDMgUE0NCj4gVG86IEVyaWMgR3JheTsgaGlkZWtpLmVuZG8uZXNAaGl0YWNoaS5j b20NCj4gQ2M6IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttcGxzXSBXb3JraW5nIEdy b3VwIExhcyBDYWxsIG9uZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLWRlbWFuZC0NCj4gY3YtMDMNCj4g DQo+IEVyaWMsDQo+IA0KPiBJIGdlbmVyYWxseSBhZ3JlZSBidXQgSSB0aGluayB0aGVyZSBpcyBv bmUgY2FzZSBhY3R1YWxseSB3aGljaCBuZWVkcyBhDQo+IGNsb3NlciBsb29rIGluIHRoaXMgcmVn YXJkICh3aGljaCBJIGhpbnRlZCBhdCBlYXJsaWVyKSwgd2hpY2ggYXJlIHRoZSBwZXItDQo+IGlu dGVyZmFjZSBNSVBzLiBZb3VyIFRUTCBleHBpcmVzICh0aGUgYWN0dWFsIGFkZHJlc3NpbmcgYml0 IGhlcmUpLCB0aGUNCj4gaWRlbnRpZmllciB0ZWxscyB5b3UgaXQgaXMgbm90IGludGVuZGVkIGZv ciB0aGUgaW5ncmVzcyBNSVAsIHNvIGl0IG5lZWRzDQo+IHRvIGJlIGZvcndhcmRlZCB0byB0aGUg ZWdyZXNzIE1JUCB0aHJvdWdoIHRoZSBmb3J3YXJkaW5nIGVuZ2luZS4gTm93IGlmDQo+IHlvdSBw dWxsIHRoZSBwYWNrZXQgb3V0IG9mIHRoZSBmYXN0IHBhdGggYW5kIGluamVjdCBpdCBiYWNrIGlu LCBpcyB0aGUgT0FNDQo+IHBhY2tldCBzdGlsbCBmYXRlIHNoYXJpbmc/IElmIHlvdSBjYW4gZG8g dGhpcyBpbiBIVyBvbiB0aGUgbGluZSBjYXJkLCB0aGVuDQo+IGl0IHdpbGwgYW5kIGl0IHdpbGwg anVzdCBiZSBmb3J3YXJkZWQgYXMgbm9ybWFsLiBJIGtub3cgdGhpcyBpcyBhDQo+IGRpZmZlcmVu dCBkcmFmdCwgYnV0IHRoaXMgd2lsbCBiZSBpbiBwYXJ0aWN1bGFyIGltcG9ydGFudCBmb3IgcGVy Zm9ybWFuY2UNCj4gbW9uaXRvcmluZy4NCj4gDQo+IEJlc3QsDQo+IA0KPiBSb2xmDQo+IA0KPiAN Cj4gDQo+IE5FQyBFdXJvcGUgTGltaXRlZCB8IFJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2Us IDEgVmljdG9yaWEgUm9hZCwgTG9uZG9uDQo+IFczIDZCTCB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFu ZCAyODMyMDE0DQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZy b206IEVyaWMgR3JheSBbbWFpbHRvOmVyaWMuZ3JheUBlcmljc3Nvbi5jb21dDQo+ID4gU2VudDog TW9udGFnLCAyOC4gTcOkcnogMjAxMSAxNDo0NQ0KPiA+IFRvOiBoaWRla2kuZW5kby5lc0BoaXRh Y2hpLmNvbTsgUm9sZiBXaW50ZXINCj4gPiBDYzogbXBsc0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6 IFJFOiBSZVsyXTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENhbGwgb25kcmFmdC1pZXRmLW1w bHMtdHAtDQo+ID4gb24tZGVtYW5kLWN2LTAzDQo+ID4NCj4gPiBIaWRla2ksDQo+ID4NCj4gPiAJ V2hhdCB5b3UncmUgc2F5aW5nIGlzIHRydWUsIGJ1dCBub3QgcmVsZXZhbnQgaW4gdGhpcw0KPiA+ IGNhc2UuICBUaGUgImFkZHJlc3NlcyIgaW4gdGhpcyBkaXNjdXNzaW9uIGFyZSBub3QgdXNlZCB0 bw0KPiA+IGRldGVybWluZSBob3cgdG8gZm9yd2FyZCBPQU0gcGFja2V0cy4gIFRoZXkgYXJlIHVz ZWQgb25seQ0KPiA+IGJ5IHRoZSByZWNpcGllbnQgTUlQL01FUCB0byB2ZXJpZnkgdGhhdCB0aGUg T0FNIHBhY2tldCB3YXMNCj4gPiBwcm9wZXJseSBkZWxpdmVyZWQuDQo+ID4NCj4gPiAJQnkgdGhl IHdheSwgdGhpcyBkaXNjdXNzaW9uIGlzIGFuIGluZGljYXRpb24gb2YgdGhlDQo+ID4gY29uZnVz aW5nIGluamVjdGVkIGJ5IGNhbGxpbmcgdGhlc2UgdGhpbmdzIGFkZHJlc3Nlcy4gIE15DQo+ID4g bWlzdGFrZSBhbmQgSSBicmluZyBpdCB1cCBub3cgdG8gaGVscCB0byBzdGVtIHRoZSB0aWRlIG9m DQo+ID4gZnVydGhlciBjb21tZW50cyByZXN1bHRpbmcgZnJvbSB0aGF0IGNvbmZ1c2lvbi4NCj4g Pg0KPiA+IAlJbiB0aGUgdmVyc2lvbiB3ZSBwb3N0IGFmdGVyIGxhc3QgY2FsbCBpcyBjb21wbGV0 ZSwNCj4gPiB3ZSB3aWxsIGJlIGNoYW5naW5nIHRoZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uICJh ZGRyZXNzIg0KPiA+IFRMVnMgdG8gc291cmNlIGFuZCBkZXN0aW5hdGlvbiAiaWRlbnRpZmllciIg VExWcy4NCj4gPg0KPiA+IAlXZSB3aWxsIGFsc28gYmUgY29ycmVjdGluZyB0aGUgcmVmZXJlbmNl IHRvIERTTUFQLA0KPiA+IGFuZCBERE1BUCwgYWRkcmVzcyBUTFZzICh3aGljaCBpcyBpbmNvcnJl Y3QsIGJlY2F1c2UgdGhlDQo+ID4gZm9ybWF0IGZvciBEU01BUC9ERE1BUCBkb2Vzbid0IGluY2x1 ZGUgYSAibGVuZ3RoIiBmaWVsZCkuDQo+ID4NCj4gPiAJVGhlIGZvcm1hdCBvZiB0aGUgRG93bnN0 cmVhbSBNYXBwaW5nIChEU01BUCkgVExWIGlzDQo+ID4gZGVmaW5lZCBpbiBSRkMgNDM3OSwgYW5k IHdlIGFyZSBub3QgY2hhbmdpbmcgdGhlIGZvcm1hdA0KPiA+IG9mIHRoYXQgVExWLg0KPiA+DQo+ ID4gCVRoZXNlIGNoYW5nZXMgYXJlIGRyaXZlbiBieSBsYXN0IGNhbGwgY29tbWVudHMgd2UNCj4g PiBoYXZlIGFscmVhZHkgcmVjZWl2ZWQgKHNlZSBKb2VsIEhhbHBlcm4ncyBjb21tZW50cyBvbiB0 aGUNCj4gPiBtYWlsaW5nIGxpc3QpIGFuZCBhcmUgLSBpbiBwYXJ0IC0gdG8gY29ycmVjdCBhY2Np ZGVudGFsDQo+ID4gdXNlIG9mIHRoZSB3b3JkICJhZGRyZXNzIiBmb3Igc291cmNlIGFuZCBkZXN0 aW5hdGlvbg0KPiA+IGlkZW50aWZpZXIgVExWcyAod2hpY2ggaXMgd2hhdCB3ZSBoYWQgZGlzY3Vz c2VkIGJlZm9yZQ0KPiA+IEkgZ2VuZXJhdGVkIHRoZSAtMDMgdmVyc2lvbiBhbW9uZyB0aGUgYXV0 aG9ycyBvZiBzZXZlcmFsDQo+ID4gb2YgdGhlIGN1cnJlbnQgc2V0IG9mIE1QTFMtVFAgZHJhZnRz KS4NCj4gPg0KPiA+IAlJbiB0aGUgY2FzZSBvZiBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIGlkZW50 aWZpZXJzLA0KPiA+IHRoZXNlIHdpbGwgYmUgdXNlZCBleGNsdXNpdmVseSB0byB2ZXJpZnkgdGhh dCBhbiBPQU0gUERVDQo+ID4gaGFzIGJlZW4gY29ycmVjdGx5IHJlY2VpdmVkIGJ5IGl0cyBpbnRl bmRlZCByZWNpcGllbnQuDQo+ID4gQmVjYXVzZSB0aGlzIGlzIGFuIG9uLWRlbWFuZCBjb25uZWN0 aXZpdHkgdmVyaWZpY2F0aW9uDQo+ID4gcHJvdG9jb2wsIHRoYXQgaXMgZXhwZWN0ZWQgdG8gYmUg dXNlZCBvbmx5IG9uIHRob3NlDQo+ID4gb2NjYXNpb25zIHdoZW4gdGhlcmUgaXMgYSBuZXR3b3Jr IHByb2JsZW0gdGhhdCBuZWVkcyB0bw0KPiA+IGJlIGRpYWdub3NlZCwgYW5kIHRoZSBpbmZvcm1h dGlvbiBpcyBub3Qgc2VlbiAoYW5kIG5vdA0KPiA+IHZpc2libGUgLSB3aXRob3V0IGxheWVyIHZp b2xhdGlvbnMpLCBvcHRpbWl6aW5nIHRoZXNlDQo+ID4gb2JqZWN0cyBmb3Igc29mdHdhcmUgbWFr ZXMgc2Vuc2UuDQo+ID4NCj4gPiAJSW4gYWRkaXRpb24sIHNpbmNlIGVpdGhlciBtYXkgYmUgaW5j bHVkZWQgKHdoaWNoDQo+ID4gaW5jbHVkZXMgdGhlIHBvc3NpYmlsaXR5IG9mIGluY2x1ZGluZyBi b3RoKSwgaXQgaXMgdGhlDQo+ID4gY2FzZSBhbHJlYWR5IHRoYXQgd2Ugd291bGQgdGhlbiBuZWVk IHRvIGRlY2lkZSB3aGljaCBpcw0KPiA+IHRvIGdvIGZpcnN0IC0gYXNzdW1pbmcgd2Ugd2FudGVk IHRvIGRvIHRoaXMgKHdoaWNoIHdlDQo+ID4gZG8gbm90KS4NCj4gPg0KPiA+IC0tDQo+ID4gRXJp Yw0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBoaWRla2ku ZW5kby5lc0BoaXRhY2hpLmNvbSBbbWFpbHRvOmhpZGVraS5lbmRvLmVzQGhpdGFjaGkuY29tXQ0K PiA+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMjgsIDIwMTEgODoxMSBBTQ0KPiA+IFRvOiBFcmljIEdy YXk7IFJvbGYuV2ludGVyQG5lY2xhYi5ldQ0KPiA+IENjOiBtcGxzQGlldGYub3JnDQo+ID4gU3Vi amVjdDogUmVbMl06IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9uZHJhZnQtaWV0Zi1t cGxzLXRwLW9uLQ0KPiA+IGRlbWFuZC1jdi0wMw0KPiA+IEltcG9ydGFuY2U6IEhpZ2gNCj4gPg0K PiA+IEhpIEVyaWMgYW5kIFJvbGYsDQo+ID4NCj4gPiBJJ20gc29ycnkgZm9yIGludGVycnVwdGlu Zy4NCj4gPg0KPiA+IEkgYWdyZWUgd2l0aCBSb2xmIHJlZ2FyZGluZyB0aGUgcGVyLWludGVyZmFj ZSBNSVAgZGlzY3Vzc2lvbi4NCj4gPiBXZSBoYXZlIHRvIGNvbnNpZGVyIHRoZSBIVyBpbXBsZW1l bnRhdGlvbiBhc3BlY3QsDQo+ID4gYmVjYXVzZSB0cmFwcGluZyBvZiBhbiBPQU0gcGFja2V0IGlz IEhXIHJ1bGUvZnVuY3Rpb25hbGl0eSBldmVuIGluDQo+ID4gcm91dGVycy4NCj4gPg0KPiA+IElm IGV2ZXJ5IE9BTSBwYWNrZXQgaXMgdHJhcHBlZCB0byBDUFUNCj4gPiBhbmQgdGhlIE9BTSBwYWNr ZXRzIHdoaWNoIHNob3VsZCBOT1QgYmUgcHJvY2Vzc2VkIGluIHRoZSBJbnRlcmZhY2UNCj4gPiBh cmUgcmV0dXJuZWQgdG8gRGF0YS1wbGFuZSwNCj4gPiBpdCBpcyBkaWZmZXJlbnQgZm9yd2FyZGlu ZyBwYXRoIGZyb20gdXNlciBwYWNrZXRzLA0KPiA+IHdoaWNoIGlzIE5PVCB0aGUgQ29ubmVjdGl2 aXR5IFZlcmlmaWNhdGlvbiBvZiB0aGUgdXNlciBwYXRoLg0KPiA+DQo+ID4gVGhlcmVmb3JlLCB3 ZSBzaG91bGQgdGFrZSB0aGUgSFcgYXNwZWN0IGFuZCBmbGV4aWJpbHR5IGludG8gYWNjb3VudA0K PiA+IGNvbmN1cnJlbnRseS4NCj4gPiBJZiBhbiBhZGRyZXNzIFRMViBNVVNUIGJlIHRoZSBmaXJz dCBpbiBUTFZzLA0KPiA+IGl0IGlzIGVub3VnaCB0byBtYWtlIEhXIGltcGxlbWVudGF0aW9uIGVh c3kuDQo+ID4NCj4gPiBCUiwNCj4gPiBIaWRla2kNCj4gPg0KPiA+DQo+ID4NCj4gPiA+Um9sZiwN Cj4gPiA+DQo+ID4gPglUaGUgd29yZHMgeW91IHByb3Bvc2UgYXJlIG9rYXkgd2l0aCBtZS4NCj4g PiA+DQo+ID4gPglJIHRob3VnaHQgdGhlIE1JUC9pbnRlcmZhY2UgYW5kIGFkZHJlc3MgbG9jYXRp b24gaXNzdWVzDQo+ID4gPndlcmUgc2VwYXJhdGUuDQo+ID4gPg0KPiA+ID4JSSd2ZSBwZXJzb25h bGx5IGhhZCBwcm9ibGVtcyB3aXRoIHByb3RvY29sIHNwZWNpZmljYXRpb25zDQo+ID4gPnRoYXQg cmVxdWlyZSBvcmRlcmluZyBvZiBUTFZzLiAgSW4gcGFydGljdWxhciwgdGhpcyBpcyBub3QgdmVy eQ0KPiA+ID5yb2J1c3QgaW4gdGVybXMgb2YgImZ1dHVyZS1wcm9vZmluZy4iICBXaGF0IGhhcHBl bnMgaWYgbmV3IFRMVnMNCj4gPiA+YXJlIGFkZGVkIGxhdGVyIG9uOyBmb3IgaW5zdGFuY2UsIHN1 cHBvc2UgYXQgc29tZSBwb2ludCB3ZSBoYXZlDQo+ID4gPm11bHRpcGxlICJhZGRyZXNzIiBUTFZz Pw0KPiA+ID4NCj4gPiA+CUFsc28sIHRoZSBmYWN0IHRoYXQgaW1wbGVtZW50YXRpb25zIGFyZSBh bGxvd2VkIHRvIGF0dGFjaA0KPiA+ID5UTFZzIGluIGFueSBhcmJpdHJhcnkgb3JkZXIgYWxsb3dz IGNvbnNpZGVyYWJsZSBmbGV4aWJpbHR5IGluDQo+ID4gPmltcGxlbWVudGF0aW9uLiAgTWVzc2Fn ZXMgY2FuIGJlIGJ1aWx0IGluIGFyYml0cmFyaWx5IG1hbnkgd2F5cy4NCj4gPiA+VGhpcyB0b28g Y2FuIGJlIGEgZnV0dXJlLXByb29maW5nIGlzc3VlLg0KPiA+ID4NCj4gPiA+CUkgd291bGQgcHJl ZmVyIG5vdCB0byBzdGFydCBkb3duIHRoZSByb2FkIG9mIHJlcXVpcmluZyBhDQo+ID4gPnN1YnNl dCBvZiBUTFZzIHRvIGFwcGVhciBpbiBhIGNlcnRhaW4gb3JkZXIsIGFuZCBzYXlpbmcgd2UgaGF2 ZQ0KPiA+ID5vbmUgVExWIHRoYXQgbmVlZHMgdG8gYmUgZmlyc3QgaXMgZG9pbmcganVzdCB0aGF0 Lg0KPiA+ID4NCj4gPiA+LS0NCj4gPiA+RXJpYw0KPiA+ID4NCj4gPiA+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiA+RnJvbTogUm9sZiBXaW50ZXIgW21haWx0bzpSb2xmLldpbnRlckBu ZWNsYWIuZXVdDQo+ID4gPlNlbnQ6IE1vbmRheSwgTWFyY2ggMjgsIDIwMTEgNjoxOSBBTQ0KPiA+ ID5UbzogRXJpYyBHcmF5DQo+ID4gPkNjOiBtcGxzQGlldGYub3JnDQo+ID4gPlN1YmplY3Q6IFJF OiBbbXBsc10gV29ya2luZyBHcm91cCBMYXMgQ2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtb24t DQo+ID4gZGVtYW5kLWN2LTAzDQo+ID4gPkltcG9ydGFuY2U6IEhpZ2gNCj4gPiA+DQo+ID4gPkhp LA0KPiA+ID4NCj4gPiA+SSBzdGlsbCB0aGluayB0aGVyZSBpcyBhIGxvZ2ljYWwgZXJyb3IuIExl dCBtZSBleHBsYWluLiBJbiBjYXNlIHRoZXJlDQo+ID4gaXMgbm8gSVAgeW91IHNpbXBseSBjYW5u b3QgdXNlIGl0LiBZb3Ugc2F5IHlvdSBjb3VsZCBlbmFibGUgSVAgYnV0IHRoZW4NCj4gPiB0aGF0 IGlzIG5vdCBhIGNhc2Ugd2hlcmUgdGhlcmUgaXMgbm8gSVAuIEluIG9yZGVyIHRvIGJlIGNvbnN0 cnVjdGl2ZQ0KPiA+IGhlcmUgaXMgYSB0ZXh0IGNoYW5nZSBzdWdnZXN0aW9uOg0KPiA+ID4NCj4g PiA+IkluIGNlcnRhaW4gTVBMUy1UUCBkZXBsb3ltZW50IHNjZW5hcmlvcyBJUCBhZGRyZXNzaW5n IG1pZ2h0IG5vdCBiZQ0KPiA+IGF2YWlsYWJsZS4gSW4gdGhvc2UgY2FzZXMgT24tZGVtYW5kIENW IGFuZC9vciByb3V0ZSB0cmFjaW5nIE1VU1QgYmUgcnVuDQo+ID4gd2l0aG91dCBJUCBhZGRyZXNz aW5nLCB1c2luZyB0aGUgQUNIIGNoYW5uZWwgdHlwZSBzcGVjaWZpZWQgaW4gU2VjdGlvbg0KPiA+ IDMuIEluIG90aGVyIGNhc2VzIGl0IG1pZ2h0IGJlIGF2YWlsYWJsZSwgaG93ZXZlciwgaXQgbWF5 IGJlIHByZWZlcnJlZA0KPiA+IHRvIHVzZSBzb21lIGZvcm0gb2Ygbm9uLUlQIGVuY2Fwc3VsYXRp b24uIEluIHRob3NlIGNhc2VzLCB0aGUNCj4gPiBwcm9jZWR1cmVzIGFzIG91dGxpbmVkIGluIHNl Y3Rpb24gMyBTSE9VTEQgYWxzbyBiZSB1c2VkLiINCj4gPiA+DQo+ID4gPlJlZ2FyZGluZyB0aGUg cGVyLWludGVyZmFjZSBNSVAgZGlzY3Vzc2lvbi4gVGhlIEhXIGFzcGVjdCBhbHNvIHBvcHBlZA0K PiA+IHVwIGluIHRoZSBQV0UzIHNlc3Npb24gYW5kIEkgdGhpbmsgdGhpcyBpcyBhbiBpbXBvcnRh bnQgY29uc2lkZXJhdGlvbiwNCj4gPiBpbiBwYXJ0aWN1bGFyIGZvciBPQU0uIEV2ZW4gaWYgd2Ug dGFsayBhYm91dCBUTFZzLCB3ZSBjb3VsZCBtYWtlIGl0IGENCj4gPiBNVVNUIHRoYXQgYW4gQWRk cmVzcyBUTFYgaXMgYWx3YXlzIHRoZSBmaXJzdCBvbmUgdG8gYXBwZWFyLiBJZiB5b3UgY2FuDQo+ ID4gZmFjaWxpdGF0ZSBhbiBlYXN5IGltcGxlbWVudGF0aW9uIGluIGhhcmR3YXJlLCBJIHNlZSBu byByZWFzb24gdG8NCj4gPiBkZWxpYmVyYXRlbHkgbm90IGRvIGl0Lg0KPiA+ID4NCj4gPiA+QmVz dCwNCj4gPiA+DQo+ID4gPlJvbGYNCj4gPiA+DQo+ID4gPg0KPiA+ID5ORUMgRXVyb3BlIExpbWl0 ZWQgfCBSZWdpc3RlcmVkIE9mZmljZTogTkVDIEhvdXNlLCAxIFZpY3RvcmlhIFJvYWQsDQo+ID4g TG9uZG9uIFczIDZCTCB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODMyMDE0DQo+ID4gPg0KPiA+ ID4NCj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+IEZyb206IEVyaWMg R3JheSBbbWFpbHRvOmVyaWMuZ3JheUBlcmljc3Nvbi5jb21dDQo+ID4gPj4gU2VudDogTW9udGFn LCAyOC4gTcOkcnogMjAxMSAxMTo0Mw0KPiA+ID4+IFRvOiBSb2xmIFdpbnRlcg0KPiA+ID4+IENj OiBsb2FAcGkubnU7IG1wbHNAaWV0Zi5vcmcNCj4gPiA+PiBTdWJqZWN0OiBSRTogW21wbHNdIFdv cmtpbmcgR3JvdXAgTGFzIENhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLQ0KPiA+ID4+IGRl bWFuZC1jdi0wMw0KPiA+ID4+DQo+ID4gPj4gUm9sZiwNCj4gPiA+Pg0KPiA+ID4+IAlXaXRoIHJl Z2FyZCB0byB0aGUgdXNlIG9mIFNIT1VMRCAodmVyc2VzIE1VU1QpIC0gdGhlIGludGVudA0KPiA+ ID4+IChhY2NvcmRpbmcgdG8gUkZDIDIxMTkgLSBzZWUgdGhlIHF1b3RlIGJlbG93KSBpcyBjb25z aXN0ZW50IHdpdGgNCj4gPiA+PiB0aGlzIGNhc2UuICBJZiAtIGZvciBzb21lIHJlYXNvbiAtIG9u ZSBoYWQgYSByZWFsbHkgZ29vZCByZWFzb24gdG8NCj4gPiA+PiB1c2UgSVAgYWRkcmVzc2luZyBp biBzb21lIHNwZWNpZmljIGNhc2UsIG9uZSBjb3VsZCB0YWtlIHN0ZXBzIHRvDQo+ID4gPj4gbWFr ZSBJUCBhZGRyZXNzaW5nIGF2YWlsYWJsZS4NCj4gPiA+Pg0KPiA+ID4+IAlUaGlzIGNvdWxkIGJl IHNhaWQgdG8gaW50cm9kdWNlIGEgbG9naWNhbCBkaXNjb25uZWN0LCBidXQgd2UNCj4gPiA+PiBh cmUgc2F2ZWQgZnJvbSBnb2luZyBkb3duIHRoYXQgcGF0aCBieSB0aGUgZmFjdCB0aGF0IHRoZSBz dGF0ZW1lbnQNCj4gPiA+PiBhbHNvIGluY2x1ZGVzIHRoZSBjYXNlIHdoZXJlIChmb3Igc29tZSBy ZWFzb24pIHRoZXJlIGlzIGEgY2FzZSBpbg0KPiA+ID4+IHdoaWNoIHNvbWUgb3RoZXIgYWRkcmVz c2luZyBzY2hlbWUgbWlnaHQgYmUgcHJlZmVycmVkLiAgSW4gbWFueSBvZg0KPiA+ID4+IHRoZSBj YXNlcyB3aGVyZSBhbm90aGVyIGFkZHJlc3Npbmcgc2NoZW1lIG1heSBiZSBwcmVmZXJyZWQsIGl0 IGlzDQo+ID4gPj4gc3RpbGwgcG9zc2libGUgKGluIGZhY3QgbGlrZWx5KSB0aGF0IElQIGFkZHJl c3NpbmcgaXMgYXZhaWxhYmxlLg0KPiA+ID4+DQo+ID4gPj4gCU90aGVyd2lzZSwgaXQgd291bGQg bm90IGhhdmUgYmVlbiBuZWNlc3NhcnkgdG8gZGlzdGluZ3Vpc2gNCj4gPiA+PiB0aGlzIGNhc2Ug ZnJvbSB0aGUgb25lIGluIHdoaWNoIElQIGFkZHJlc3NpbmcgaXMgbm90IGF2YWlsYWJsZS4NCj4g PiA+Pg0KPiA+ID4+IAlGb3IgdGhlIGNhc2Ugd2hlcmUgSVAgYWRkcmVzc2luZyBpcyBub3QgdGhl IHByZWZlcnJlZCBtb2RlLA0KPiA+ID4+IHdlIGFyZSByZWNvbW1lbmRpbmcgYSBtb2RlIGluIHdo aWNoIGl0IGlzIG5vdCBuZWNlc3NhcnkuDQo+ID4gPj4NCj4gPiA+PiAJV2l0aCByZWdhcmQgdG8g aGF2aW5nIGFkZHJlc3NlcyBsb2NhdGVkIGluIHRoZSBzYW1lIHBsYWNlLA0KPiA+ID4+IHRoaXMg cHJvdG9jb2wgaXMgbWVhbnQgZm9yIGNvbm5lY3Rpdml0eSB0ZXN0aW5nIG9uIGFuIG9uLWRlbWFu ZA0KPiA+ID4+IGJhc2lzIGFuZCBpcyB0aGVyZWZvcmUgbm90IG9wdGltaXplZCBmb3IgcHJvY2Vz c2luZyBpbiBoYXJkd2FyZS4NCj4gPiA+Pg0KPiA+ID4+IAlXaGV0aGVyIGFkZHJlc3NlcyBvciBp ZGVudGlmaWVycywgaWYgd2UgYXJlIHRhbGtpbmcgYWJvdXQNCj4gPiA+PiBUTFYgY29udGVudHMs IHRoZXJlIGFyZSBpc3N1ZXMgd2l0aCB0cnlpbmcgdG8gZ3VhcmFudGVlIGxvY2F0aW9uDQo+ID4g Pj4gb2Ygc3BlY2lmaWMgY29udGVudCwgYmVjYXVzZSBvZiB0aGUgZmFjdCB0aGF0IHRoZSBUTFYg aW4gcXVlc3Rpb24NCj4gPiA+PiB3aWxsIHByb2JhYmx5IGZvbGxvdyBvdGhlciBUTFZzIC0gdGh1 cyBtYWtpbmcgbG9jYXRpb25zIGRpZmZpY3VsdA0KPiA+ID4+IHRvIHByZWRpY3QgaW4gYW55IGNh c2UuDQo+ID4gPj4NCj4gPiA+PiAJV2l0aCByZWdhcmQgdG8gbmVlZGluZyBtb3JlIHRleHQgb24g cGVyLWludGVyZmFjZSBNSVBzLCBkbw0KPiA+ID4+IHlvdSBoYXZlIHNwZWNpZmljIHN1Z2dlc3Rp b25zIGFzIHRvIHdoYXQgdGV4dCB3ZSBtaWdodCBhZGQ/DQo+ID4gPj4NCj4gPiA+PiAJSSB1bmRl cnN0YW5kIChmcm9tIGRpc2N1c3Npb24gd2l0aCBXRyBjaGFpcnMpIHRoYXQgd2UgYXJlDQo+ID4g Pj4gbm90IGFsbG93ZWQgdG8gZXhwbGljaXRseSBhZGRyZXNzIGxhc3QgY2FsbCBjb21tZW50cyBk dXJpbmcgdGhlDQo+ID4gPj4gSUVURiBtZWV0aW5nIGluIFByYWd1ZSwgYmVjYXVzZSB0aGUgbGFz dCBjYWxsIGlzIHN0aWxsIG9uZ29pbmcNCj4gPiA+PiBhdCB0aGF0IHRpbWUuDQo+ID4gPj4NCj4g PiA+PiAtLQ0KPiA+ID4+IEVyaWMNCj4gPiA+Pg0KPiA+ID4+IFBTIC0NCj4gPiA+PiBGcm9tIFJG QyAyMTE5IC0NCj4gPiA+PiAnU0hPVUxEICAgVGhpcyB3b3JkLCBvciB0aGUgYWRqZWN0aXZlICJS RUNPTU1FTkRFRCIsIG1lYW4gdGhhdCB0aGVyZQ0KPiA+ID4+ICAgICAgICAgICBtYXkgZXhpc3Qg dmFsaWQgcmVhc29ucyBpbiBwYXJ0aWN1bGFyIGNpcmN1bXN0YW5jZXMgdG8NCj4gPiA+PiAgICAg ICAgICAgaWdub3JlIGEgcGFydGljdWxhciBpdGVtLCBidXQgdGhlIGZ1bGwgaW1wbGljYXRpb25z IG11c3QNCj4gPiA+PiAgICAgICAgICAgYmUgdW5kZXJzdG9vZCBhbmQgY2FyZWZ1bGx5IHdlaWdo ZWQgYmVmb3JlIGNob29zaW5nIGENCj4gPiA+PiAgICAgICAgICAgZGlmZmVyZW50IGNvdXJzZS4n DQo+ID4gPj4NCj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+IEZyb206 IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmDQo+ID4gT2YNCj4gPiA+PiBSb2xmIFdpbnRlcg0KPiA+ID4+IFNlbnQ6IFR1ZXNkYXks IE1hcmNoIDIyLCAyMDExIDQ6NTcgQU0NCj4gPiA+PiBUbzogbG9hQHBpLm51OyBtcGxzQGlldGYu b3JnDQo+ID4gPj4gU3ViamVjdDogUmU6IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9u IGRyYWZ0LWlldGYtbXBscy10cC1vbi0NCj4gPiA+PiBkZW1hbmQtY3YtMDMNCj4gPiA+Pg0KPiA+ ID4+IEhpLA0KPiA+ID4+DQo+ID4gPj4gc29tZSBjb21tZW50cyBiZWxvdzoNCj4gPiA+Pg0KPiA+ ID4+IFNlY3Rpb24gMS4zIHNheXM6ICIgSW4gY2VydGFpbiBNUExTLVRQIGRlcGxveW1lbnQgc2Nl bmFyaW9zIElQDQo+ID4gPj4gYWRkcmVzc2luZyBtaWdodCBub3QgYmUNCj4gPiA+PiAgICBhdmFp bGFibGUgb3IgaXQgbWF5IGJlIHByZWZlcnJlZCB0byB1c2Ugc29tZSBmb3JtIG9mIG5vbi1JUA0K PiA+ID4+ICAgIGVuY2Fwc3VsYXRpb24gZm9yIE9uLWRlbWFuZCBDViwgcm91dGUgdHJhY2luZyBh bmQgQkZEIHBhY2tldHMuDQo+ID4gSW4NCj4gPiA+PiAgICBzdWNoIHNjZW5hcmlvcywgT24tZGVt YW5kIENWIGFuZC9vciByb3V0ZSB0cmFjaW5nIFNIT1VMRCBiZSBydW4NCj4gPiA+PiAgICB3aXRo b3V0IElQIGFkZHJlc3NpbmcuLi4iDQo+ID4gPj4NCj4gPiA+PiBJIGFtIG5vdCBzdXJlIHRoZSAi U0hPVUxEIiBpcyByaWdodCBoZXJlLiBJZiBubyBJUCBhZGRyZXNzaW5nIGlzDQo+ID4gPj4gYXZh aWxhYmxlLCB0aGlzIHRoaW5nIE1VU1QgYmUgcnVuIHdpdGhvdXQgSVAgYWRkcmVzc2luZywgbXVz dG4ndCBpdD8NCj4gPiA+Pg0KPiA+ID4+IEkgdGhpbmsgc29tZSBhZGRpdGlvbmFsIHRleHQgcmVn YXJkaW5nIHBlci1pbnRlcmZhY2UgTUlQIGFkZHJlc3NpbmcNCj4gPiA+PiB3b3VsZCBiZSBuaWNl LiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kIHRoZSBkb2N1bWVudCwgYWxsIFRMVnMgd2lsbCBiZQ0K PiA+ID4+IGluc2lkZSB0aGUgTFNQIHBpbmcgcGFja2V0IChyYXRoZXIgdGhhbiBhcyBBQ0ggVExW cykuDQo+ID4gPj4NCj4gPiA+PiBTb21lIHBlb3BsZSBoYWQgY29uY2VybnMgZWFybGllciwgdGhh dCBhZGRyZXNzaW5nIGluZm9ybWF0aW9uIHNob3VsZA0KPiA+IGJlDQo+ID4gPj4gaW4gYSBmaXhl ZCBsb2NhdGlvbiBmb3IgZWFzaWVyIHByb2Nlc3NpbmcuIElzIHRoaXMgdGhlIGNhc2UgaGVyZSBJ DQo+ID4gPj4gd29uZGVyPw0KPiA+ID4+DQo+ID4gPj4gSXQgd291bGQgYmUgbmljZSBpZiB5b3Ug Y291bGQgYWRkcmVzcyB0aGlzIGluIHlvdXIgcHJlc2VudGF0aW9uIGluDQo+ID4gPj4gUHJhZ3Vl Lg0KPiA+ID4+DQo+ID4gPj4gVGhhbmtzLA0KPiA+ID4+DQo+ID4gPj4gUm9sZg0KPiA+ID4+DQo+ ID4gPj4NCj4gPiA+PiBORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVkIE9mZmljZTogTkVD IEhvdXNlLCAxIFZpY3RvcmlhIFJvYWQsDQo+ID4gPj4gTG9uZG9uIFczIDZCTCB8IFJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCAyODMyMDE0DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+PiA+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gPiBCZWhhbGYNCj4gPiA+PiBPZg0K PiA+ID4+ID4gbG9hQHBpLm51DQo+ID4gPj4gPiBTZW50OiBNaXR0d29jaCwgMTYuIE3DpHJ6IDIw MTEgMDA6MjYNCj4gPiA+PiA+IFRvOiBtcGxzQGlldGYub3JnDQo+ID4gPj4gPiBDYzogTVBMUy1U UCBhZCBob2MgdGVhbQ0KPiA+ID4+ID4gU3ViamVjdDogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFz IENhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLQ0KPiA+ID4+IGRlbWFuZC0NCj4gPiA+PiA+ IGN2LTAzDQo+ID4gPj4gPg0KPiA+ID4+ID4gV29ya2luZyBHcm91cCwNCj4gPiA+PiA+DQo+ID4g Pj4gPiB0aGlzIGlzIHRvIHN0YXJ0IGEgMyB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9u DQo+ID4gPj4gPg0KPiA+ID4+ID4gZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLWRlbWFuZC1jdi0wMw0K PiA+ID4+ID4NCj4gPiA+PiA+IFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRoZSB3b3JraW5nIGdy b3VwIG1haWxpbmcgbGlzdA0KPiA+ID4+ID4gbXBsc0BpZXRmLm9yZw0KPiA+ID4+ID4NCj4gPiA+ PiA+IFRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIEFwcmlsIDgsIDIwMTEuDQo+ ID4gPj4gPg0KPiA+ID4+ID4gL0xvYQ0KPiA+ID4+ID4NCj4gPiA+PiA+DQo+ID4gPj4gPg0KPiA+ ID4+ID4NCj4gPiA+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4gPj4gPiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+ID4+ID4gbXBsc0BpZXRmLm9y Zw0KPiA+ID4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiA+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+ID4+IG1wbHNAaWV0Zi5vcmcNCj4gPiA+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPiA+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+bXBscyBtYWlsaW5nIGxp c3QNCj4gPiA+bXBsc0BpZXRmLm9yZw0KPiA+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHMNCj4gPiA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From hideki.endo.es@hitachi.com Wed Mar 30 08:31:36 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8BB3A6B64 for ; Wed, 30 Mar 2011 08:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.781 X-Spam-Level: *** X-Spam-Status: No, score=3.781 tagged_above=-999 required=5 tests=[AWL=0.920, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SARE_SUB_ENC_UTF8=0.152, SUBJ_RE_NUM=2.799] 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 L10OP5T+bA-O for ; Wed, 30 Mar 2011 08:31:34 -0700 (PDT) Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by core3.amsl.com (Postfix) with ESMTP id 190523A6A20 for ; Wed, 30 Mar 2011 08:31:33 -0700 (PDT) Received: from mlsv6.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id B8BE237C82; Thu, 31 Mar 2011 00:33:10 +0900 (JST) Received: from mfilter4.hitachi.co.jp by mlsv6.hitachi.co.jp (8.13.1/8.13.1) id p2UFXAgq005372; Thu, 31 Mar 2011 00:33:10 +0900 Received: from vshuts4.hitachi.co.jp (vshuts4.hitachi.co.jp [10.201.6.80]) by mfilter4.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id p2UFX9Du002114; Thu, 31 Mar 2011 00:33:10 +0900 X-AuditID: b753bd60-a1eb6ba000004916-cd-4d934d352e29 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts4.hitachi.co.jp (Symantec Mail Security) with ESMTP id 812E3204333; Thu, 31 Mar 2011 00:33:09 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p2UFX9h15212566; Thu, 31 Mar 2011 00:33:09 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: multipart/mixed; boundary="GMAILSMTPBOUND01110331003300" To: , , , From: Date: Thu, 31 Mar 2011 00:32:50 +0900 References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.d> Priority: normal Importance: normal X400-Content-Identifier: X4D934D1000000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28110331003232PQH] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [mpls] =?utf-8?q?Working_Group_Las_Call_ondraft-ietf-mpls-tp-on-d?= =?utf-8?q?emand-cv-03?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 15:31:36 -0000 --GMAILSMTPBOUND01110331003300 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSBvbmUgY29tbWVudCBvbiBJRHMgaW4gZHJhZnQtb24tZGVtYW5kLWN2 Lg0KVGhlIGludGVyZmFjZS1EIGlzIG1pc3NpbmcgaW4gdGhlIGN1cnJlbnQgZHJhZnQsIHRo ZXJlIGlzIG9ubHkgTm9kZS1JRC4NCllvdSBuZWVkIGF0IGxlYXN0IHRoZSBpbnRlcmZhY2Ug SUQgdG8gc3VwcG9ydCBwZXItaW50ZXJmYWNlIE1JUC4NCg0KQlIsDQpIaWRla2kNCg0KPg0K PkRlYXIgQWxsLA0KPg0KPkkgcmVhbGx5IGFwcHJlY2lhdGUgdGhlIGNvbnNpZGVyYXRpb24g b24gdGhlIHBlci1pbnRlcmZhY2UgTUlQIHN1cHBvcnQgYW5kIHRoZSBkaXNjdXNzaW9uIG1v dmluZyBmb3J3YXJkLg0KPg0KPg0KPkZyb20gYW4gb3BlcmF0b3IncyBwZXJzcGVjdGl2ZSwg aXQgaXMgdmVyeSBpbXBvcnRhbnQgdGhhdCB0aGUgc3VwcG9ydCBmb3IgcGVyLWludGVyZmFj ZSBNSVBzIGlzIGNvdmVyZWQgYnkgdGhlIGRlZmluaXRpb25zLg0KPg0KPkxvb2tpbmcgYXQg ZWFybGllciB2ZXJzaW9ucyBvZiBkcmFmdC1mYXJyZWwtbXBscy10cC1taXAtbWVwLW1hcCwg dGhlcmUgd2FzIGFscmVhZHkgYSBzb2x1dGlvbiBwcm9wb3NhbCwgdXNpbmcgdGhlIFRUTC4g RW5oYW5jZWQgc29sdXRpb25zIGhhdmUgYmVlbiB0aG9yb3VnbHkgZGlzY3Vzc2VkIGR1cmlu ZyB0aGlzIElFVEYgbWVldGluZy4gSXQgaXQgdG8gYmUgZXhwZWN0ZWQgdGhhdCB0aGVyZSB3 aWxsIGJlIHdheXMgdG8gc29sdmUgYm90aCB0aGUgZmFzdCBwYXRoIGFuZCBmYXRlLXNoYXJp bmcgcmVxdWlyZW1lbnQuDQo+DQo+DQo+SSBzZWNvbmQgdGhlIHByb3Bvc2FsIGluaXRpYWxs eSBtYWRlIGJ5IFJvbGYsIHRvIGluY2x1ZGUgYWRkaXRpb25hbCB0ZXh0IHRvIGRvY3VtZW50 IHRoZSBwZXItaW50ZXJmYWNlIE1JUCBhZGRyZXNzaW5nIGZvciB0aGUgb24tZGVtYW5kLWN2 IGFuZCBmb3Igb3RoZXIgT0FNIHRvb2xzLiANCj4NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+TWFu dWVsIA0KPg0KPg0KPkRldXRzY2hlIFRlbGVrb20gQUcNCj5Hcm91cCBUZWNobm9sb2d5DQo+ TWFudWVsIFBhdWwNCj5TQTMtMTENCj5Hb3NsYXJlciBVZmVyIDM1LTM3LCAxMDU4OSBCZXJs aW4NCj4rNDkgMzAgMzQ5NyAtIDQzOTQgKFRlbC4pDQo+KzQ5IDMwIDM0OTcgLSA0OTU2IChG YXgpDQo+KzQ5IDE3MSAgODYzNDAzMiAoTW9iaWwpDQo+RS1NYWlsOiBtYWlsdG86bWFudWVs LnBhdWxAdGVsZWtvbS5kZQ0KPmh0dHA6Ly93d3cudGVsZWtvbS5jb20gICAgDQo+DQo+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4+IFJv bGYgV2ludGVyDQo+PiBTZW50OiBNb25kYXksIE1hcmNoIDI4LCAyMDExIDM6MDMgUE0NCj4+ IFRvOiBFcmljIEdyYXk7IGhpZGVraS5lbmRvLmVzQGhpdGFjaGkuY29tDQo+PiBDYzogbXBs c0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBD YWxsIG9uZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLWRlbWFuZC0NCj4+IGN2LTAzDQo+PiANCj4+ IEVyaWMsDQo+PiANCj4+IEkgZ2VuZXJhbGx5IGFncmVlIGJ1dCBJIHRoaW5rIHRoZXJlIGlz IG9uZSBjYXNlIGFjdHVhbGx5IHdoaWNoIG5lZWRzIGENCj4+IGNsb3NlciBsb29rIGluIHRo aXMgcmVnYXJkICh3aGljaCBJIGhpbnRlZCBhdCBlYXJsaWVyKSwgd2hpY2ggYXJlIHRoZSBw ZXItDQo+PiBpbnRlcmZhY2UgTUlQcy4gWW91ciBUVEwgZXhwaXJlcyAodGhlIGFjdHVhbCBh ZGRyZXNzaW5nIGJpdCBoZXJlKSwgdGhlDQo+PiBpZGVudGlmaWVyIHRlbGxzIHlvdSBpdCBp cyBub3QgaW50ZW5kZWQgZm9yIHRoZSBpbmdyZXNzIE1JUCwgc28gaXQgbmVlZHMNCj4+IHRv IGJlIGZvcndhcmRlZCB0byB0aGUgZWdyZXNzIE1JUCB0aHJvdWdoIHRoZSBmb3J3YXJkaW5n IGVuZ2luZS4gTm93IGlmDQo+PiB5b3UgcHVsbCB0aGUgcGFja2V0IG91dCBvZiB0aGUgZmFz dCBwYXRoIGFuZCBpbmplY3QgaXQgYmFjayBpbiwgaXMgdGhlIE9BTQ0KPj4gcGFja2V0IHN0 aWxsIGZhdGUgc2hhcmluZz8gSWYgeW91IGNhbiBkbyB0aGlzIGluIEhXIG9uIHRoZSBsaW5l IGNhcmQsIHRoZW4NCj4+IGl0IHdpbGwgYW5kIGl0IHdpbGwganVzdCBiZSBmb3J3YXJkZWQg YXMgbm9ybWFsLiBJIGtub3cgdGhpcyBpcyBhDQo+PiBkaWZmZXJlbnQgZHJhZnQsIGJ1dCB0 aGlzIHdpbGwgYmUgaW4gcGFydGljdWxhciBpbXBvcnRhbnQgZm9yIHBlcmZvcm1hbmNlDQo+ PiBtb25pdG9yaW5nLg0KPj4gDQo+PiBCZXN0LA0KPj4gDQo+PiBSb2xmDQo+PiANCj4+IA0K Pj4gDQo+PiBORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVkIE9mZmljZTogTkVDIEhv dXNlLCAxIFZpY3RvcmlhIFJvYWQsIExvbmRvbg0KPj4gVzMgNkJMIHwgUmVnaXN0ZXJlZCBp biBFbmdsYW5kIDI4MzIwMTQNCj4+IA0KPj4gDQo+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+PiA+IEZyb206IEVyaWMgR3JheSBbbWFpbHRvOmVyaWMuZ3JheUBlcmljc3Nv bi5jb21dDQo+PiA+IFNlbnQ6IE1vbnRhZywgMjguIE3DpHJ6IDIwMTEgMTQ6NDUNCj4+ID4g VG86IGhpZGVraS5lbmRvLmVzQGhpdGFjaGkuY29tOyBSb2xmIFdpbnRlcg0KPj4gPiBDYzog bXBsc0BpZXRmLm9yZw0KPj4gPiBTdWJqZWN0OiBSRTogUmVbMl06IFttcGxzXSBXb3JraW5n IEdyb3VwIExhcyBDYWxsIG9uZHJhZnQtaWV0Zi1tcGxzLXRwLQ0KPj4gPiBvbi1kZW1hbmQt Y3YtMDMNCj4+ID4NCj4+ID4gSGlkZWtpLA0KPj4gPg0KPj4gPiAJV2hhdCB5b3UncmUgc2F5 aW5nIGlzIHRydWUsIGJ1dCBub3QgcmVsZXZhbnQgaW4gdGhpcw0KPj4gPiBjYXNlLiAgVGhl ICJhZGRyZXNzZXMiIGluIHRoaXMgZGlzY3Vzc2lvbiBhcmUgbm90IHVzZWQgdG8NCj4+ID4g ZGV0ZXJtaW5lIGhvdyB0byBmb3J3YXJkIE9BTSBwYWNrZXRzLiAgVGhleSBhcmUgdXNlZCBv bmx5DQo+PiA+IGJ5IHRoZSByZWNpcGllbnQgTUlQL01FUCB0byB2ZXJpZnkgdGhhdCB0aGUg T0FNIHBhY2tldCB3YXMNCj4+ID4gcHJvcGVybHkgZGVsaXZlcmVkLg0KPj4gPg0KPj4gPiAJ QnkgdGhlIHdheSwgdGhpcyBkaXNjdXNzaW9uIGlzIGFuIGluZGljYXRpb24gb2YgdGhlDQo+ PiA+IGNvbmZ1c2luZyBpbmplY3RlZCBieSBjYWxsaW5nIHRoZXNlIHRoaW5ncyBhZGRyZXNz ZXMuICBNeQ0KPj4gPiBtaXN0YWtlIGFuZCBJIGJyaW5nIGl0IHVwIG5vdyB0byBoZWxwIHRv IHN0ZW0gdGhlIHRpZGUgb2YNCj4+ID4gZnVydGhlciBjb21tZW50cyByZXN1bHRpbmcgZnJv bSB0aGF0IGNvbmZ1c2lvbi4NCj4+ID4NCj4+ID4gCUluIHRoZSB2ZXJzaW9uIHdlIHBvc3Qg YWZ0ZXIgbGFzdCBjYWxsIGlzIGNvbXBsZXRlLA0KPj4gPiB3ZSB3aWxsIGJlIGNoYW5naW5n IHRoZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uICJhZGRyZXNzIg0KPj4gPiBUTFZzIHRvIHNv dXJjZSBhbmQgZGVzdGluYXRpb24gImlkZW50aWZpZXIiIFRMVnMuDQo+PiA+DQo+PiA+IAlX ZSB3aWxsIGFsc28gYmUgY29ycmVjdGluZyB0aGUgcmVmZXJlbmNlIHRvIERTTUFQLA0KPj4g PiBhbmQgRERNQVAsIGFkZHJlc3MgVExWcyAod2hpY2ggaXMgaW5jb3JyZWN0LCBiZWNhdXNl IHRoZQ0KPj4gPiBmb3JtYXQgZm9yIERTTUFQL0RETUFQIGRvZXNuJ3QgaW5jbHVkZSBhICJs ZW5ndGgiIGZpZWxkKS4NCj4+ID4NCj4+ID4gCVRoZSBmb3JtYXQgb2YgdGhlIERvd25zdHJl YW0gTWFwcGluZyAoRFNNQVApIFRMViBpcw0KPj4gPiBkZWZpbmVkIGluIFJGQyA0Mzc5LCBh bmQgd2UgYXJlIG5vdCBjaGFuZ2luZyB0aGUgZm9ybWF0DQo+PiA+IG9mIHRoYXQgVExWLg0K Pj4gPg0KPj4gPiAJVGhlc2UgY2hhbmdlcyBhcmUgZHJpdmVuIGJ5IGxhc3QgY2FsbCBjb21t ZW50cyB3ZQ0KPj4gPiBoYXZlIGFscmVhZHkgcmVjZWl2ZWQgKHNlZSBKb2VsIEhhbHBlcm4n cyBjb21tZW50cyBvbiB0aGUNCj4+ID4gbWFpbGluZyBsaXN0KSBhbmQgYXJlIC0gaW4gcGFy dCAtIHRvIGNvcnJlY3QgYWNjaWRlbnRhbA0KPj4gPiB1c2Ugb2YgdGhlIHdvcmQgImFkZHJl c3MiIGZvciBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uDQo+PiA+IGlkZW50aWZpZXIgVExWcyAo d2hpY2ggaXMgd2hhdCB3ZSBoYWQgZGlzY3Vzc2VkIGJlZm9yZQ0KPj4gPiBJIGdlbmVyYXRl ZCB0aGUgLTAzIHZlcnNpb24gYW1vbmcgdGhlIGF1dGhvcnMgb2Ygc2V2ZXJhbA0KPj4gPiBv ZiB0aGUgY3VycmVudCBzZXQgb2YgTVBMUy1UUCBkcmFmdHMpLg0KPj4gPg0KPj4gPiAJSW4g dGhlIGNhc2Ugb2Ygc291cmNlIGFuZCBkZXN0aW5hdGlvbiBpZGVudGlmaWVycywNCj4+ID4g dGhlc2Ugd2lsbCBiZSB1c2VkIGV4Y2x1c2l2ZWx5IHRvIHZlcmlmeSB0aGF0IGFuIE9BTSBQ RFUNCj4+ID4gaGFzIGJlZW4gY29ycmVjdGx5IHJlY2VpdmVkIGJ5IGl0cyBpbnRlbmRlZCBy ZWNpcGllbnQuDQo+PiA+IEJlY2F1c2UgdGhpcyBpcyBhbiBvbi1kZW1hbmQgY29ubmVjdGl2 aXR5IHZlcmlmaWNhdGlvbg0KPj4gPiBwcm90b2NvbCwgdGhhdCBpcyBleHBlY3RlZCB0byBi ZSB1c2VkIG9ubHkgb24gdGhvc2UNCj4+ID4gb2NjYXNpb25zIHdoZW4gdGhlcmUgaXMgYSBu ZXR3b3JrIHByb2JsZW0gdGhhdCBuZWVkcyB0bw0KPj4gPiBiZSBkaWFnbm9zZWQsIGFuZCB0 aGUgaW5mb3JtYXRpb24gaXMgbm90IHNlZW4gKGFuZCBub3QNCj4+ID4gdmlzaWJsZSAtIHdp dGhvdXQgbGF5ZXIgdmlvbGF0aW9ucyksIG9wdGltaXppbmcgdGhlc2UNCj4+ID4gb2JqZWN0 cyBmb3Igc29mdHdhcmUgbWFrZXMgc2Vuc2UuDQo+PiA+DQo+PiA+IAlJbiBhZGRpdGlvbiwg c2luY2UgZWl0aGVyIG1heSBiZSBpbmNsdWRlZCAod2hpY2gNCj4+ID4gaW5jbHVkZXMgdGhl IHBvc3NpYmlsaXR5IG9mIGluY2x1ZGluZyBib3RoKSwgaXQgaXMgdGhlDQo+PiA+IGNhc2Ug YWxyZWFkeSB0aGF0IHdlIHdvdWxkIHRoZW4gbmVlZCB0byBkZWNpZGUgd2hpY2ggaXMNCj4+ ID4gdG8gZ28gZmlyc3QgLSBhc3N1bWluZyB3ZSB3YW50ZWQgdG8gZG8gdGhpcyAod2hpY2gg d2UNCj4+ID4gZG8gbm90KS4NCj4+ID4NCj4+ID4gLS0NCj4+ID4gRXJpYw0KPj4gPg0KPj4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPiBGcm9tOiBoaWRla2kuZW5kby5l c0BoaXRhY2hpLmNvbSBbbWFpbHRvOmhpZGVraS5lbmRvLmVzQGhpdGFjaGkuY29tXQ0KPj4g PiBTZW50OiBNb25kYXksIE1hcmNoIDI4LCAyMDExIDg6MTEgQU0NCj4+ID4gVG86IEVyaWMg R3JheTsgUm9sZi5XaW50ZXJAbmVjbGFiLmV1DQo+PiA+IENjOiBtcGxzQGlldGYub3JnDQo+ PiA+IFN1YmplY3Q6IFJlWzJdOiBbbXBsc10gV29ya2luZyBHcm91cCBMYXMgQ2FsbCBvbmRy YWZ0LWlldGYtbXBscy10cC1vbi0NCj4+ID4gZGVtYW5kLWN2LTAzDQo+PiA+IEltcG9ydGFu Y2U6IEhpZ2gNCj4+ID4NCj4+ID4gSGkgRXJpYyBhbmQgUm9sZiwNCj4+ID4NCj4+ID4gSSdt IHNvcnJ5IGZvciBpbnRlcnJ1cHRpbmcuDQo+PiA+DQo+PiA+IEkgYWdyZWUgd2l0aCBSb2xm IHJlZ2FyZGluZyB0aGUgcGVyLWludGVyZmFjZSBNSVAgZGlzY3Vzc2lvbi4NCj4+ID4gV2Ug aGF2ZSB0byBjb25zaWRlciB0aGUgSFcgaW1wbGVtZW50YXRpb24gYXNwZWN0LA0KPj4gPiBi ZWNhdXNlIHRyYXBwaW5nIG9mIGFuIE9BTSBwYWNrZXQgaXMgSFcgcnVsZS9mdW5jdGlvbmFs aXR5IGV2ZW4gaW4NCj4+ID4gcm91dGVycy4NCj4+ID4NCj4+ID4gSWYgZXZlcnkgT0FNIHBh Y2tldCBpcyB0cmFwcGVkIHRvIENQVQ0KPj4gPiBhbmQgdGhlIE9BTSBwYWNrZXRzIHdoaWNo IHNob3VsZCBOT1QgYmUgcHJvY2Vzc2VkIGluIHRoZSBJbnRlcmZhY2UNCj4+ID4gYXJlIHJl dHVybmVkIHRvIERhdGEtcGxhbmUsDQo+PiA+IGl0IGlzIGRpZmZlcmVudCBmb3J3YXJkaW5n IHBhdGggZnJvbSB1c2VyIHBhY2tldHMsDQo+PiA+IHdoaWNoIGlzIE5PVCB0aGUgQ29ubmVj dGl2aXR5IFZlcmlmaWNhdGlvbiBvZiB0aGUgdXNlciBwYXRoLg0KPj4gPg0KPj4gPiBUaGVy ZWZvcmUsIHdlIHNob3VsZCB0YWtlIHRoZSBIVyBhc3BlY3QgYW5kIGZsZXhpYmlsdHkgaW50 byBhY2NvdW50DQo+PiA+IGNvbmN1cnJlbnRseS4NCj4+ID4gSWYgYW4gYWRkcmVzcyBUTFYg TVVTVCBiZSB0aGUgZmlyc3QgaW4gVExWcywNCj4+ID4gaXQgaXMgZW5vdWdoIHRvIG1ha2Ug SFcgaW1wbGVtZW50YXRpb24gZWFzeS4NCj4+ID4NCj4+ID4gQlIsDQo+PiA+IEhpZGVraQ0K Pj4gPg0KPj4gPg0KPj4gPg0KPj4gPiA+Um9sZiwNCj4+ID4gPg0KPj4gPiA+CVRoZSB3b3Jk cyB5b3UgcHJvcG9zZSBhcmUgb2theSB3aXRoIG1lLg0KPj4gPiA+DQo+PiA+ID4JSSB0aG91 Z2h0IHRoZSBNSVAvaW50ZXJmYWNlIGFuZCBhZGRyZXNzIGxvY2F0aW9uIGlzc3Vlcw0KPj4g PiA+d2VyZSBzZXBhcmF0ZS4NCj4+ID4gPg0KPj4gPiA+CUkndmUgcGVyc29uYWxseSBoYWQg cHJvYmxlbXMgd2l0aCBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucw0KPj4gPiA+dGhhdCByZXF1 aXJlIG9yZGVyaW5nIG9mIFRMVnMuICBJbiBwYXJ0aWN1bGFyLCB0aGlzIGlzIG5vdCB2ZXJ5 DQo+PiA+ID5yb2J1c3QgaW4gdGVybXMgb2YgImZ1dHVyZS1wcm9vZmluZy4iICBXaGF0IGhh cHBlbnMgaWYgbmV3IFRMVnMNCj4+ID4gPmFyZSBhZGRlZCBsYXRlciBvbjsgZm9yIGluc3Rh bmNlLCBzdXBwb3NlIGF0IHNvbWUgcG9pbnQgd2UgaGF2ZQ0KPj4gPiA+bXVsdGlwbGUgImFk ZHJlc3MiIFRMVnM/DQo+PiA+ID4NCj4+ID4gPglBbHNvLCB0aGUgZmFjdCB0aGF0IGltcGxl bWVudGF0aW9ucyBhcmUgYWxsb3dlZCB0byBhdHRhY2gNCj4+ID4gPlRMVnMgaW4gYW55IGFy Yml0cmFyeSBvcmRlciBhbGxvd3MgY29uc2lkZXJhYmxlIGZsZXhpYmlsdHkgaW4NCj4+ID4g PmltcGxlbWVudGF0aW9uLiAgTWVzc2FnZXMgY2FuIGJlIGJ1aWx0IGluIGFyYml0cmFyaWx5 IG1hbnkgd2F5cy4NCj4+ID4gPlRoaXMgdG9vIGNhbiBiZSBhIGZ1dHVyZS1wcm9vZmluZyBp c3N1ZS4NCj4+ID4gPg0KPj4gPiA+CUkgd291bGQgcHJlZmVyIG5vdCB0byBzdGFydCBkb3du IHRoZSByb2FkIG9mIHJlcXVpcmluZyBhDQo+PiA+ID5zdWJzZXQgb2YgVExWcyB0byBhcHBl YXIgaW4gYSBjZXJ0YWluIG9yZGVyLCBhbmQgc2F5aW5nIHdlIGhhdmUNCj4+ID4gPm9uZSBU TFYgdGhhdCBuZWVkcyB0byBiZSBmaXJzdCBpcyBkb2luZyBqdXN0IHRoYXQuDQo+PiA+ID4N Cj4+ID4gPi0tDQo+PiA+ID5FcmljDQo+PiA+ID4NCj4+ID4gPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PiA+ID5Gcm9tOiBSb2xmIFdpbnRlciBbbWFpbHRvOlJvbGYuV2ludGVy QG5lY2xhYi5ldV0NCj4+ID4gPlNlbnQ6IE1vbmRheSwgTWFyY2ggMjgsIDIwMTEgNjoxOSBB TQ0KPj4gPiA+VG86IEVyaWMgR3JheQ0KPj4gPiA+Q2M6IG1wbHNAaWV0Zi5vcmcNCj4+ID4g PlN1YmplY3Q6IFJFOiBbbXBsc10gV29ya2luZyBHcm91cCBMYXMgQ2FsbCBvbiBkcmFmdC1p ZXRmLW1wbHMtdHAtb24tDQo+PiA+IGRlbWFuZC1jdi0wMw0KPj4gPiA+SW1wb3J0YW5jZTog SGlnaA0KPj4gPiA+DQo+PiA+ID5IaSwNCj4+ID4gPg0KPj4gPiA+SSBzdGlsbCB0aGluayB0 aGVyZSBpcyBhIGxvZ2ljYWwgZXJyb3IuIExldCBtZSBleHBsYWluLiBJbiBjYXNlIHRoZXJl DQo+PiA+IGlzIG5vIElQIHlvdSBzaW1wbHkgY2Fubm90IHVzZSBpdC4gWW91IHNheSB5b3Ug Y291bGQgZW5hYmxlIElQIGJ1dCB0aGVuDQo+PiA+IHRoYXQgaXMgbm90IGEgY2FzZSB3aGVy ZSB0aGVyZSBpcyBubyBJUC4gSW4gb3JkZXIgdG8gYmUgY29uc3RydWN0aXZlDQo+PiA+IGhl cmUgaXMgYSB0ZXh0IGNoYW5nZSBzdWdnZXN0aW9uOg0KPj4gPiA+DQo+PiA+ID4iSW4gY2Vy dGFpbiBNUExTLVRQIGRlcGxveW1lbnQgc2NlbmFyaW9zIElQIGFkZHJlc3NpbmcgbWlnaHQg bm90IGJlDQo+PiA+IGF2YWlsYWJsZS4gSW4gdGhvc2UgY2FzZXMgT24tZGVtYW5kIENWIGFu ZC9vciByb3V0ZSB0cmFjaW5nIE1VU1QgYmUgcnVuDQo+PiA+IHdpdGhvdXQgSVAgYWRkcmVz c2luZywgdXNpbmcgdGhlIEFDSCBjaGFubmVsIHR5cGUgc3BlY2lmaWVkIGluIFNlY3Rpb24N Cj4+ID4gMy4gSW4gb3RoZXIgY2FzZXMgaXQgbWlnaHQgYmUgYXZhaWxhYmxlLCBob3dldmVy LCBpdCBtYXkgYmUgcHJlZmVycmVkDQo+PiA+IHRvIHVzZSBzb21lIGZvcm0gb2Ygbm9uLUlQ IGVuY2Fwc3VsYXRpb24uIEluIHRob3NlIGNhc2VzLCB0aGUNCj4+ID4gcHJvY2VkdXJlcyBh cyBvdXRsaW5lZCBpbiBzZWN0aW9uIDMgU0hPVUxEIGFsc28gYmUgdXNlZC4iDQo+PiA+ID4N Cj4+ID4gPlJlZ2FyZGluZyB0aGUgcGVyLWludGVyZmFjZSBNSVAgZGlzY3Vzc2lvbi4gVGhl IEhXIGFzcGVjdCBhbHNvIHBvcHBlZA0KPj4gPiB1cCBpbiB0aGUgUFdFMyBzZXNzaW9uIGFu ZCBJIHRoaW5rIHRoaXMgaXMgYW4gaW1wb3J0YW50IGNvbnNpZGVyYXRpb24sDQo+PiA+IGlu IHBhcnRpY3VsYXIgZm9yIE9BTS4gRXZlbiBpZiB3ZSB0YWxrIGFib3V0IFRMVnMsIHdlIGNv dWxkIG1ha2UgaXQgYQ0KPj4gPiBNVVNUIHRoYXQgYW4gQWRkcmVzcyBUTFYgaXMgYWx3YXlz IHRoZSBmaXJzdCBvbmUgdG8gYXBwZWFyLiBJZiB5b3UgY2FuDQo+PiA+IGZhY2lsaXRhdGUg YW4gZWFzeSBpbXBsZW1lbnRhdGlvbiBpbiBoYXJkd2FyZSwgSSBzZWUgbm8gcmVhc29uIHRv DQo+PiA+IGRlbGliZXJhdGVseSBub3QgZG8gaXQuDQo+PiA+ID4NCj4+ID4gPkJlc3QsDQo+ PiA+ID4NCj4+ID4gPlJvbGYNCj4+ID4gPg0KPj4gPiA+DQo+PiA+ID5ORUMgRXVyb3BlIExp bWl0ZWQgfCBSZWdpc3RlcmVkIE9mZmljZTogTkVDIEhvdXNlLCAxIFZpY3RvcmlhIFJvYWQs DQo+PiA+IExvbmRvbiBXMyA2QkwgfCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgMjgzMjAxNA0K Pj4gPiA+DQo+PiA+ID4NCj4+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ ID4gPj4gRnJvbTogRXJpYyBHcmF5IFttYWlsdG86ZXJpYy5ncmF5QGVyaWNzc29uLmNvbV0N Cj4+ID4gPj4gU2VudDogTW9udGFnLCAyOC4gTcOkcnogMjAxMSAxMTo0Mw0KPj4gPiA+PiBU bzogUm9sZiBXaW50ZXINCj4+ID4gPj4gQ2M6IGxvYUBwaS5udTsgbXBsc0BpZXRmLm9yZw0K Pj4gPiA+PiBTdWJqZWN0OiBSRTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENhbGwgb24g ZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLQ0KPj4gPiA+PiBkZW1hbmQtY3YtMDMNCj4+ID4gPj4N Cj4+ID4gPj4gUm9sZiwNCj4+ID4gPj4NCj4+ID4gPj4gCVdpdGggcmVnYXJkIHRvIHRoZSB1 c2Ugb2YgU0hPVUxEICh2ZXJzZXMgTVVTVCkgLSB0aGUgaW50ZW50DQo+PiA+ID4+IChhY2Nv cmRpbmcgdG8gUkZDIDIxMTkgLSBzZWUgdGhlIHF1b3RlIGJlbG93KSBpcyBjb25zaXN0ZW50 IHdpdGgNCj4+ID4gPj4gdGhpcyBjYXNlLiAgSWYgLSBmb3Igc29tZSByZWFzb24gLSBvbmUg aGFkIGEgcmVhbGx5IGdvb2QgcmVhc29uIHRvDQo+PiA+ID4+IHVzZSBJUCBhZGRyZXNzaW5n IGluIHNvbWUgc3BlY2lmaWMgY2FzZSwgb25lIGNvdWxkIHRha2Ugc3RlcHMgdG8NCj4+ID4g Pj4gbWFrZSBJUCBhZGRyZXNzaW5nIGF2YWlsYWJsZS4NCj4+ID4gPj4NCj4+ID4gPj4gCVRo aXMgY291bGQgYmUgc2FpZCB0byBpbnRyb2R1Y2UgYSBsb2dpY2FsIGRpc2Nvbm5lY3QsIGJ1 dCB3ZQ0KPj4gPiA+PiBhcmUgc2F2ZWQgZnJvbSBnb2luZyBkb3duIHRoYXQgcGF0aCBieSB0 aGUgZmFjdCB0aGF0IHRoZSBzdGF0ZW1lbnQNCj4+ID4gPj4gYWxzbyBpbmNsdWRlcyB0aGUg Y2FzZSB3aGVyZSAoZm9yIHNvbWUgcmVhc29uKSB0aGVyZSBpcyBhIGNhc2UgaW4NCj4+ID4g Pj4gd2hpY2ggc29tZSBvdGhlciBhZGRyZXNzaW5nIHNjaGVtZSBtaWdodCBiZSBwcmVmZXJy ZWQuICBJbiBtYW55IG9mDQo+PiA+ID4+IHRoZSBjYXNlcyB3aGVyZSBhbm90aGVyIGFkZHJl c3Npbmcgc2NoZW1lIG1heSBiZSBwcmVmZXJyZWQsIGl0IGlzDQo+PiA+ID4+IHN0aWxsIHBv c3NpYmxlIChpbiBmYWN0IGxpa2VseSkgdGhhdCBJUCBhZGRyZXNzaW5nIGlzIGF2YWlsYWJs ZS4NCj4+ID4gPj4NCj4+ID4gPj4gCU90aGVyd2lzZSwgaXQgd291bGQgbm90IGhhdmUgYmVl biBuZWNlc3NhcnkgdG8gZGlzdGluZ3Vpc2gNCj4+ID4gPj4gdGhpcyBjYXNlIGZyb20gdGhl IG9uZSBpbiB3aGljaCBJUCBhZGRyZXNzaW5nIGlzIG5vdCBhdmFpbGFibGUuDQo+PiA+ID4+ DQo+PiA+ID4+IAlGb3IgdGhlIGNhc2Ugd2hlcmUgSVAgYWRkcmVzc2luZyBpcyBub3QgdGhl IHByZWZlcnJlZCBtb2RlLA0KPj4gPiA+PiB3ZSBhcmUgcmVjb21tZW5kaW5nIGEgbW9kZSBp biB3aGljaCBpdCBpcyBub3QgbmVjZXNzYXJ5Lg0KPj4gPiA+Pg0KPj4gPiA+PiAJV2l0aCBy ZWdhcmQgdG8gaGF2aW5nIGFkZHJlc3NlcyBsb2NhdGVkIGluIHRoZSBzYW1lIHBsYWNlLA0K Pj4gPiA+PiB0aGlzIHByb3RvY29sIGlzIG1lYW50IGZvciBjb25uZWN0aXZpdHkgdGVzdGlu ZyBvbiBhbiBvbi1kZW1hbmQNCj4+ID4gPj4gYmFzaXMgYW5kIGlzIHRoZXJlZm9yZSBub3Qg b3B0aW1pemVkIGZvciBwcm9jZXNzaW5nIGluIGhhcmR3YXJlLg0KPj4gPiA+Pg0KPj4gPiA+ PiAJV2hldGhlciBhZGRyZXNzZXMgb3IgaWRlbnRpZmllcnMsIGlmIHdlIGFyZSB0YWxraW5n IGFib3V0DQo+PiA+ID4+IFRMViBjb250ZW50cywgdGhlcmUgYXJlIGlzc3VlcyB3aXRoIHRy eWluZyB0byBndWFyYW50ZWUgbG9jYXRpb24NCj4+ID4gPj4gb2Ygc3BlY2lmaWMgY29udGVu dCwgYmVjYXVzZSBvZiB0aGUgZmFjdCB0aGF0IHRoZSBUTFYgaW4gcXVlc3Rpb24NCj4+ID4g Pj4gd2lsbCBwcm9iYWJseSBmb2xsb3cgb3RoZXIgVExWcyAtIHRodXMgbWFraW5nIGxvY2F0 aW9ucyBkaWZmaWN1bHQNCj4+ID4gPj4gdG8gcHJlZGljdCBpbiBhbnkgY2FzZS4NCj4+ID4g Pj4NCj4+ID4gPj4gCVdpdGggcmVnYXJkIHRvIG5lZWRpbmcgbW9yZSB0ZXh0IG9uIHBlci1p bnRlcmZhY2UgTUlQcywgZG8NCj4+ID4gPj4geW91IGhhdmUgc3BlY2lmaWMgc3VnZ2VzdGlv bnMgYXMgdG8gd2hhdCB0ZXh0IHdlIG1pZ2h0IGFkZD8NCj4+ID4gPj4NCj4+ID4gPj4gCUkg dW5kZXJzdGFuZCAoZnJvbSBkaXNjdXNzaW9uIHdpdGggV0cgY2hhaXJzKSB0aGF0IHdlIGFy ZQ0KPj4gPiA+PiBub3QgYWxsb3dlZCB0byBleHBsaWNpdGx5IGFkZHJlc3MgbGFzdCBjYWxs IGNvbW1lbnRzIGR1cmluZyB0aGUNCj4+ID4gPj4gSUVURiBtZWV0aW5nIGluIFByYWd1ZSwg YmVjYXVzZSB0aGUgbGFzdCBjYWxsIGlzIHN0aWxsIG9uZ29pbmcNCj4+ID4gPj4gYXQgdGhh dCB0aW1lLg0KPj4gPiA+Pg0KPj4gPiA+PiAtLQ0KPj4gPiA+PiBFcmljDQo+PiA+ID4+DQo+ PiA+ID4+IFBTIC0NCj4+ID4gPj4gRnJvbSBSRkMgMjExOSAtDQo+PiA+ID4+ICdTSE9VTEQg ICBUaGlzIHdvcmQsIG9yIHRoZSBhZGplY3RpdmUgIlJFQ09NTUVOREVEIiwgbWVhbiB0aGF0 IHRoZXJlDQo+PiA+ID4+ICAgICAgICAgICBtYXkgZXhpc3QgdmFsaWQgcmVhc29ucyBpbiBw YXJ0aWN1bGFyIGNpcmN1bXN0YW5jZXMgdG8NCj4+ID4gPj4gICAgICAgICAgIGlnbm9yZSBh IHBhcnRpY3VsYXIgaXRlbSwgYnV0IHRoZSBmdWxsIGltcGxpY2F0aW9ucyBtdXN0DQo+PiA+ ID4+ICAgICAgICAgICBiZSB1bmRlcnN0b29kIGFuZCBjYXJlZnVsbHkgd2VpZ2hlZCBiZWZv cmUgY2hvb3NpbmcgYQ0KPj4gPiA+PiAgICAgICAgICAgZGlmZmVyZW50IGNvdXJzZS4nDQo+ PiA+ID4+DQo+PiA+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+ID4+IEZy b206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmDQo+PiA+IE9mDQo+PiA+ID4+IFJvbGYgV2ludGVyDQo+PiA+ID4+IFNl bnQ6IFR1ZXNkYXksIE1hcmNoIDIyLCAyMDExIDQ6NTcgQU0NCj4+ID4gPj4gVG86IGxvYUBw aS5udTsgbXBsc0BpZXRmLm9yZw0KPj4gPiA+PiBTdWJqZWN0OiBSZTogW21wbHNdIFdvcmtp bmcgR3JvdXAgTGFzIENhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLQ0KPj4gPiA+PiBk ZW1hbmQtY3YtMDMNCj4+ID4gPj4NCj4+ID4gPj4gSGksDQo+PiA+ID4+DQo+PiA+ID4+IHNv bWUgY29tbWVudHMgYmVsb3c6DQo+PiA+ID4+DQo+PiA+ID4+IFNlY3Rpb24gMS4zIHNheXM6 ICIgSW4gY2VydGFpbiBNUExTLVRQIGRlcGxveW1lbnQgc2NlbmFyaW9zIElQDQo+PiA+ID4+ IGFkZHJlc3NpbmcgbWlnaHQgbm90IGJlDQo+PiA+ID4+ICAgIGF2YWlsYWJsZSBvciBpdCBt YXkgYmUgcHJlZmVycmVkIHRvIHVzZSBzb21lIGZvcm0gb2Ygbm9uLUlQDQo+PiA+ID4+ICAg IGVuY2Fwc3VsYXRpb24gZm9yIE9uLWRlbWFuZCBDViwgcm91dGUgdHJhY2luZyBhbmQgQkZE IHBhY2tldHMuDQo+PiA+IEluDQo+PiA+ID4+ICAgIHN1Y2ggc2NlbmFyaW9zLCBPbi1kZW1h bmQgQ1YgYW5kL29yIHJvdXRlIHRyYWNpbmcgU0hPVUxEIGJlIHJ1bg0KPj4gPiA+PiAgICB3 aXRob3V0IElQIGFkZHJlc3NpbmcuLi4iDQo+PiA+ID4+DQo+PiA+ID4+IEkgYW0gbm90IHN1 cmUgdGhlICJTSE9VTEQiIGlzIHJpZ2h0IGhlcmUuIElmIG5vIElQIGFkZHJlc3NpbmcgaXMN Cj4+ID4gPj4gYXZhaWxhYmxlLCB0aGlzIHRoaW5nIE1VU1QgYmUgcnVuIHdpdGhvdXQgSVAg YWRkcmVzc2luZywgbXVzdG4ndCBpdD8NCj4+ID4gPj4NCj4+ID4gPj4gSSB0aGluayBzb21l IGFkZGl0aW9uYWwgdGV4dCByZWdhcmRpbmcgcGVyLWludGVyZmFjZSBNSVAgYWRkcmVzc2lu Zw0KPj4gPiA+PiB3b3VsZCBiZSBuaWNlLiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kIHRoZSBk b2N1bWVudCwgYWxsIFRMVnMgd2lsbCBiZQ0KPj4gPiA+PiBpbnNpZGUgdGhlIExTUCBwaW5n IHBhY2tldCAocmF0aGVyIHRoYW4gYXMgQUNIIFRMVnMpLg0KPj4gPiA+Pg0KPj4gPiA+PiBT b21lIHBlb3BsZSBoYWQgY29uY2VybnMgZWFybGllciwgdGhhdCBhZGRyZXNzaW5nIGluZm9y bWF0aW9uIHNob3VsZA0KPj4gPiBiZQ0KPj4gPiA+PiBpbiBhIGZpeGVkIGxvY2F0aW9uIGZv ciBlYXNpZXIgcHJvY2Vzc2luZy4gSXMgdGhpcyB0aGUgY2FzZSBoZXJlIEkNCj4+ID4gPj4g d29uZGVyPw0KPj4gPiA+Pg0KPj4gPiA+PiBJdCB3b3VsZCBiZSBuaWNlIGlmIHlvdSBjb3Vs ZCBhZGRyZXNzIHRoaXMgaW4geW91ciBwcmVzZW50YXRpb24gaW4NCj4+ID4gPj4gUHJhZ3Vl Lg0KPj4gPiA+Pg0KPj4gPiA+PiBUaGFua3MsDQo+PiA+ID4+DQo+PiA+ID4+IFJvbGYNCj4+ ID4gPj4NCj4+ID4gPj4NCj4+ID4gPj4gTkVDIEV1cm9wZSBMaW1pdGVkIHwgUmVnaXN0ZXJl ZCBPZmZpY2U6IE5FQyBIb3VzZSwgMSBWaWN0b3JpYSBSb2FkLA0KPj4gPiA+PiBMb25kb24g VzMgNkJMIHwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIDI4MzIwMTQNCj4+ID4gPj4NCj4+ID4g Pj4NCj4+ID4gPj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPiA+PiA+IEZy b206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9y Z10gT24NCj4+ID4gQmVoYWxmDQo+PiA+ID4+IE9mDQo+PiA+ID4+ID4gbG9hQHBpLm51DQo+ PiA+ID4+ID4gU2VudDogTWl0dHdvY2gsIDE2LiBNw6RyeiAyMDExIDAwOjI2DQo+PiA+ID4+ ID4gVG86IG1wbHNAaWV0Zi5vcmcNCj4+ID4gPj4gPiBDYzogTVBMUy1UUCBhZCBob2MgdGVh bQ0KPj4gPiA+PiA+IFN1YmplY3Q6IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9u IGRyYWZ0LWlldGYtbXBscy10cC1vbi0NCj4+ID4gPj4gZGVtYW5kLQ0KPj4gPiA+PiA+IGN2 LTAzDQo+PiA+ID4+ID4NCj4+ID4gPj4gPiBXb3JraW5nIEdyb3VwLA0KPj4gPiA+PiA+DQo+ PiA+ID4+ID4gdGhpcyBpcyB0byBzdGFydCBhIDMgd2VlayB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCBvbg0KPj4gPiA+PiA+DQo+PiA+ID4+ID4gZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLWRl bWFuZC1jdi0wMw0KPj4gPiA+PiA+DQo+PiA+ID4+ID4gUGxlYXNlIHNlbmQgY29tbWVudHMg dG8gdGhlIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+PiA+ID4+ID4gbXBsc0BpZXRm Lm9yZw0KPj4gPiA+PiA+DQo+PiA+ID4+ID4gVGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxs IGVuZHMgb24gQXByaWwgOCwgMjAxMS4NCj4+ID4gPj4gPg0KPj4gPiA+PiA+IC9Mb2ENCj4+ ID4gPj4gPg0KPj4gPiA+PiA+DQo+PiA+ID4+ID4NCj4+ID4gPj4gPg0KPj4gPiA+PiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+ID4+ ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4+ID4gPj4gPiBtcGxzQGlldGYub3JnDQo+PiA+ID4+ ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+PiA+ID4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+ ID4+IG1wbHMgbWFpbGluZyBsaXN0DQo+PiA+ID4+IG1wbHNAaWV0Zi5vcmcNCj4+ID4gPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+PiA+ID5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPiA+bXBs cyBtYWlsaW5nIGxpc3QNCj4+ID4gPm1wbHNAaWV0Zi5vcmcNCj4+ID4gPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4gPiA+DQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbXBscyBtYWlsaW5n IGxpc3QNCj4+IG1wbHNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBscw0KPg0K --GMAILSMTPBOUND01110331003300-- From koike.yoshinori@lab.ntt.co.jp Wed Mar 30 08:49:23 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 154C03A6B71 for ; Wed, 30 Mar 2011 08:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 Hv+b0hHgt7iG for ; Wed, 30 Mar 2011 08:49:21 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id 1A01D3A6A48 for ; Wed, 30 Mar 2011 08:49:20 -0700 (PDT) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.14.4/8.14.4) with ESMTP id p2UFop4b010105; Thu, 31 Mar 2011 00:50:51 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id AFAFC7038; Thu, 31 Mar 2011 00:50:51 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3-mgr.m.ecl.ntt.co.jp [129.60.144.43]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id A36496E32; Thu, 31 Mar 2011 00:50:51 +0900 (JST) Received: from [127.0.0.1] (nesoku-96-1-1.nslab.ecl.ntt.co.jp [129.60.11.43]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id p2UFol66021228; Thu, 31 Mar 2011 00:50:51 +0900 Message-ID: <4D9350E3.7000206@lab.ntt.co.jp> Date: Thu, 31 Mar 2011 00:48:51 +0900 From: Yoshinori KOIKE User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: mpls@ietf.org References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu><791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd><791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Manuel.Paul@telekom.de, Rolf.Winter@neclab.eu Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 15:49:23 -0000 Dear all, I agree with Manuel. It is important to agree with the solution which achieves per-interface model as soon as possible. I think that enhancing the draft-farrel-mpls-tp-mip-mep-map is the best way at the moment. Best regards, Yoshinori (2011/03/30 23:31), Manuel.Paul@telekom.de wrote: > > Dear All, > > I really appreciate the consideration on the per-interface MIP support and the discussion moving forward. > > >> From an operator's perspective, it is very important that the support for per-interface MIPs is covered by the definitions. > > Looking at earlier versions of draft-farrel-mpls-tp-mip-mep-map, there was already a solution proposal, using the TTL. Enhanced solutions have been thorougly discussed during this IETF meeting. It it to be expected that there will be ways to solve both the fast path and fate-sharing requirement. > > > I second the proposal initially made by Rolf, to include additional text to document the per-interface MIP addressing for the on-demand-cv and for other OAM tools. > > > Best regards, > Manuel > > > Deutsche Telekom AG > Group Technology > Manuel Paul > SA3-11 > Goslarer Ufer 35-37, 10589 Berlin > +49 30 3497 - 4394 (Tel.) > +49 30 3497 - 4956 (Fax) > +49 171 8634032 (Mobil) > E-Mail: mailto:manuel.paul@telekom.de > http://www.telekom.com > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Rolf Winter >> Sent: Monday, March 28, 2011 3:03 PM >> To: Eric Gray; hideki.endo.es@hitachi.com >> Cc: mpls@ietf.org >> Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand- >> cv-03 >> >> Eric, >> >> I generally agree but I think there is one case actually which needs a >> closer look in this regard (which I hinted at earlier), which are the per- >> interface MIPs. Your TTL expires (the actual addressing bit here), the >> identifier tells you it is not intended for the ingress MIP, so it needs >> to be forwarded to the egress MIP through the forwarding engine. Now if >> you pull the packet out of the fast path and inject it back in, is the OAM >> packet still fate sharing? If you can do this in HW on the line card, then >> it will and it will just be forwarded as normal. I know this is a >> different draft, but this will be in particular important for performance >> monitoring. >> >> Best, >> >> Rolf >> >> >> >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London >> W3 6BL | Registered in England 2832014 >> >> >>> -----Original Message----- >>> From: Eric Gray [mailto:eric.gray@ericsson.com] >>> Sent: Montag, 28. März 2011 14:45 >>> To: hideki.endo.es@hitachi.com; Rolf Winter >>> Cc: mpls@ietf.org >>> Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp- >>> on-demand-cv-03 >>> >>> Hideki, >>> >>> What you're saying is true, but not relevant in this >>> case. The "addresses" in this discussion are not used to >>> determine how to forward OAM packets. They are used only >>> by the recipient MIP/MEP to verify that the OAM packet was >>> properly delivered. >>> >>> By the way, this discussion is an indication of the >>> confusing injected by calling these things addresses. My >>> mistake and I bring it up now to help to stem the tide of >>> further comments resulting from that confusion. >>> >>> In the version we post after last call is complete, >>> we will be changing the source and destination "address" >>> TLVs to source and destination "identifier" TLVs. >>> >>> We will also be correcting the reference to DSMAP, >>> and DDMAP, address TLVs (which is incorrect, because the >>> format for DSMAP/DDMAP doesn't include a "length" field). >>> >>> The format of the Downstream Mapping (DSMAP) TLV is >>> defined in RFC 4379, and we are not changing the format >>> of that TLV. >>> >>> These changes are driven by last call comments we >>> have already received (see Joel Halpern's comments on the >>> mailing list) and are - in part - to correct accidental >>> use of the word "address" for source and destination >>> identifier TLVs (which is what we had discussed before >>> I generated the -03 version among the authors of several >>> of the current set of MPLS-TP drafts). >>> >>> In the case of source and destination identifiers, >>> these will be used exclusively to verify that an OAM PDU >>> has been correctly received by its intended recipient. >>> Because this is an on-demand connectivity verification >>> protocol, that is expected to be used only on those >>> occasions when there is a network problem that needs to >>> be diagnosed, and the information is not seen (and not >>> visible - without layer violations), optimizing these >>> objects for software makes sense. >>> >>> In addition, since either may be included (which >>> includes the possibility of including both), it is the >>> case already that we would then need to decide which is >>> to go first - assuming we wanted to do this (which we >>> do not). >>> >>> -- >>> Eric >>> >>> -----Original Message----- >>> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >>> Sent: Monday, March 28, 2011 8:11 AM >>> To: Eric Gray; Rolf.Winter@neclab.eu >>> Cc: mpls@ietf.org >>> Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on- >>> demand-cv-03 >>> Importance: High >>> >>> Hi Eric and Rolf, >>> >>> I'm sorry for interrupting. >>> >>> I agree with Rolf regarding the per-interface MIP discussion. >>> We have to consider the HW implementation aspect, >>> because trapping of an OAM packet is HW rule/functionality even in >>> routers. >>> >>> If every OAM packet is trapped to CPU >>> and the OAM packets which should NOT be processed in the Interface >>> are returned to Data-plane, >>> it is different forwarding path from user packets, >>> which is NOT the Connectivity Verification of the user path. >>> >>> Therefore, we should take the HW aspect and flexibilty into account >>> concurrently. >>> If an address TLV MUST be the first in TLVs, >>> it is enough to make HW implementation easy. >>> >>> BR, >>> Hideki >>> >>> >>> >>>> Rolf, >>>> >>>> The words you propose are okay with me. >>>> >>>> I thought the MIP/interface and address location issues >>>> were separate. >>>> >>>> I've personally had problems with protocol specifications >>>> that require ordering of TLVs. In particular, this is not very >>>> robust in terms of "future-proofing." What happens if new TLVs >>>> are added later on; for instance, suppose at some point we have >>>> multiple "address" TLVs? >>>> >>>> Also, the fact that implementations are allowed to attach >>>> TLVs in any arbitrary order allows considerable flexibilty in >>>> implementation. Messages can be built in arbitrarily many ways. >>>> This too can be a future-proofing issue. >>>> >>>> I would prefer not to start down the road of requiring a >>>> subset of TLVs to appear in a certain order, and saying we have >>>> one TLV that needs to be first is doing just that. >>>> >>>> -- >>>> Eric >>>> >>>> -----Original Message----- >>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >>>> Sent: Monday, March 28, 2011 6:19 AM >>>> To: Eric Gray >>>> Cc: mpls@ietf.org >>>> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >>> demand-cv-03 >>>> Importance: High >>>> >>>> Hi, >>>> >>>> I still think there is a logical error. Let me explain. In case there >>> is no IP you simply cannot use it. You say you could enable IP but then >>> that is not a case where there is no IP. In order to be constructive >>> here is a text change suggestion: >>>> >>>> "In certain MPLS-TP deployment scenarios IP addressing might not be >>> available. In those cases On-demand CV and/or route tracing MUST be run >>> without IP addressing, using the ACH channel type specified in Section >>> 3. In other cases it might be available, however, it may be preferred >>> to use some form of non-IP encapsulation. In those cases, the >>> procedures as outlined in section 3 SHOULD also be used." >>>> >>>> Regarding the per-interface MIP discussion. The HW aspect also popped >>> up in the PWE3 session and I think this is an important consideration, >>> in particular for OAM. Even if we talk about TLVs, we could make it a >>> MUST that an Address TLV is always the first one to appear. If you can >>> facilitate an easy implementation in hardware, I see no reason to >>> deliberately not do it. >>>> >>>> Best, >>>> >>>> Rolf >>>> >>>> >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>> London W3 6BL | Registered in England 2832014 >>>> >>>> >>>>> -----Original Message----- >>>>> From: Eric Gray [mailto:eric.gray@ericsson.com] >>>>> Sent: Montag, 28. März 2011 11:43 >>>>> To: Rolf Winter >>>>> Cc: loa@pi.nu; mpls@ietf.org >>>>> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >>>>> demand-cv-03 >>>>> >>>>> Rolf, >>>>> >>>>> With regard to the use of SHOULD (verses MUST) - the intent >>>>> (according to RFC 2119 - see the quote below) is consistent with >>>>> this case. If - for some reason - one had a really good reason to >>>>> use IP addressing in some specific case, one could take steps to >>>>> make IP addressing available. >>>>> >>>>> This could be said to introduce a logical disconnect, but we >>>>> are saved from going down that path by the fact that the statement >>>>> also includes the case where (for some reason) there is a case in >>>>> which some other addressing scheme might be preferred. In many of >>>>> the cases where another addressing scheme may be preferred, it is >>>>> still possible (in fact likely) that IP addressing is available. >>>>> >>>>> Otherwise, it would not have been necessary to distinguish >>>>> this case from the one in which IP addressing is not available. >>>>> >>>>> For the case where IP addressing is not the preferred mode, >>>>> we are recommending a mode in which it is not necessary. >>>>> >>>>> With regard to having addresses located in the same place, >>>>> this protocol is meant for connectivity testing on an on-demand >>>>> basis and is therefore not optimized for processing in hardware. >>>>> >>>>> Whether addresses or identifiers, if we are talking about >>>>> TLV contents, there are issues with trying to guarantee location >>>>> of specific content, because of the fact that the TLV in question >>>>> will probably follow other TLVs - thus making locations difficult >>>>> to predict in any case. >>>>> >>>>> With regard to needing more text on per-interface MIPs, do >>>>> you have specific suggestions as to what text we might add? >>>>> >>>>> I understand (from discussion with WG chairs) that we are >>>>> not allowed to explicitly address last call comments during the >>>>> IETF meeting in Prague, because the last call is still ongoing >>>>> at that time. >>>>> >>>>> -- >>>>> Eric >>>>> >>>>> PS - >>>>> From RFC 2119 - >>>>> 'SHOULD This word, or the adjective "RECOMMENDED", mean that there >>>>> may exist valid reasons in particular circumstances to >>>>> ignore a particular item, but the full implications must >>>>> be understood and carefully weighed before choosing a >>>>> different course.' >>>>> >>>>> -----Original Message----- >>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>> Of >>>>> Rolf Winter >>>>> Sent: Tuesday, March 22, 2011 4:57 AM >>>>> To: loa@pi.nu; mpls@ietf.org >>>>> Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >>>>> demand-cv-03 >>>>> >>>>> Hi, >>>>> >>>>> some comments below: >>>>> >>>>> Section 1.3 says: " In certain MPLS-TP deployment scenarios IP >>>>> addressing might not be >>>>> available or it may be preferred to use some form of non-IP >>>>> encapsulation for On-demand CV, route tracing and BFD packets. >>> In >>>>> such scenarios, On-demand CV and/or route tracing SHOULD be run >>>>> without IP addressing..." >>>>> >>>>> I am not sure the "SHOULD" is right here. If no IP addressing is >>>>> available, this thing MUST be run without IP addressing, mustn't it? >>>>> >>>>> I think some additional text regarding per-interface MIP addressing >>>>> would be nice. As far as I understand the document, all TLVs will be >>>>> inside the LSP ping packet (rather than as ACH TLVs). >>>>> >>>>> Some people had concerns earlier, that addressing information should >>> be >>>>> in a fixed location for easier processing. Is this the case here I >>>>> wonder? >>>>> >>>>> It would be nice if you could address this in your presentation in >>>>> Prague. >>>>> >>>>> Thanks, >>>>> >>>>> Rolf >>>>> >>>>> >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>>>> London W3 6BL | Registered in England 2832014 >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>> Behalf >>>>> Of >>>>>> loa@pi.nu >>>>>> Sent: Mittwoch, 16. März 2011 00:26 >>>>>> To: mpls@ietf.org >>>>>> Cc: MPLS-TP ad hoc team >>>>>> Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >>>>> demand- >>>>>> cv-03 >>>>>> >>>>>> Working Group, >>>>>> >>>>>> this is to start a 3 week working group last call on >>>>>> >>>>>> draft-ietf-mpls-tp-on-demand-cv-03 >>>>>> >>>>>> Please send comments to the working group mailing list >>>>>> mpls@ietf.org >>>>>> >>>>>> The working group last call ends on April 8, 2011. >>>>>> >>>>>> /Loa >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- ************************************** Yoshinori Koike Optical Transmission Systems Development Project First Promotion Project NTT Network Service Systems Laboratories NIPPON TELEGRAPH AND TELEPHONE CORPORATION Telephone: +81 422 59 6723 Facsimile: +81 422 59 3494 Email: koike.yoshinori@lab.ntt.co.jp ************************************** From nurit.sprecher@nsn.com Wed Mar 30 09:00:18 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24CB128C190 for ; Wed, 30 Mar 2011 09:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 CyGLJ03Srx3V for ; Wed, 30 Mar 2011 09:00:16 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 9F4713A6B6C for ; Wed, 30 Mar 2011 09:00:13 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p2UG1pHf023988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Mar 2011 18:01:51 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p2UG1pPK005205; Wed, 30 Mar 2011 18:01:51 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 18:01:51 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Wed, 30 Mar 2011 18:01:47 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A532640397A5F7@DEMUEXC014.nsn-intra.net> In-Reply-To: <4D9350E3.7000206@lab.ntt.co.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Working Group LasCall ondraft-ietf-mpls-tp-on-demand-cv-03 Thread-Index: Acvu8lKPELKMY3rpSru+Fl4CEnMXZQAAW/sA References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu><791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd><791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd><40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.de> <4D9350E3.7000206@lab.ntt.co.jp> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Yoshinori KOIKE" , X-OriginalArrivalTime: 30 Mar 2011 16:01:51.0539 (UTC) FILETIME=[C850C030:01CBEEF3] Cc: Manuel.Paul@telekom.de, Rolf.Winter@neclab.eu Subject: Re: [mpls] Working Group LasCall ondraft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 16:00:18 -0000 KzENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1wbHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBZb3No aW5vcmkgS09JS0UNClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMzAsIDIwMTEgNjo0OSBQTQ0KVG86 IG1wbHNAaWV0Zi5vcmcNCkNjOiBNYW51ZWwuUGF1bEB0ZWxla29tLmRlOyBSb2xmLldpbnRlckBu ZWNsYWIuZXUNClN1YmplY3Q6IFJlOiBbbXBsc10gV29ya2luZyBHcm91cCBMYXNDYWxsIG9uZHJh ZnQtaWV0Zi1tcGxzLXRwLW9uLWRlbWFuZC1jdi0wMw0KDQpEZWFyIGFsbCwNCg0KSSBhZ3JlZSB3 aXRoIE1hbnVlbC4gSXQgaXMgaW1wb3J0YW50IHRvIGFncmVlIHdpdGggdGhlDQpzb2x1dGlvbiB3 aGljaCBhY2hpZXZlcyBwZXItaW50ZXJmYWNlIG1vZGVsIGFzIHNvb24gYXMNCnBvc3NpYmxlLg0K DQpJIHRoaW5rIHRoYXQgZW5oYW5jaW5nIHRoZSBkcmFmdC1mYXJyZWwtbXBscy10cC1taXAtbWVw LW1hcA0KaXMgdGhlIGJlc3Qgd2F5IGF0IHRoZSBtb21lbnQuDQoNCkJlc3QgcmVnYXJkcywNCg0K WW9zaGlub3JpDQoNCigyMDExLzAzLzMwIDIzOjMxKSwgTWFudWVsLlBhdWxAdGVsZWtvbS5kZSB3 cm90ZToNCj4NCj4gRGVhciBBbGwsDQo+DQo+IEkgcmVhbGx5IGFwcHJlY2lhdGUgdGhlIGNvbnNp ZGVyYXRpb24gb24gdGhlIHBlci1pbnRlcmZhY2UgTUlQIHN1cHBvcnQgYW5kIHRoZSBkaXNjdXNz aW9uIG1vdmluZyBmb3J3YXJkLg0KPg0KPg0KPj4gRnJvbSBhbiBvcGVyYXRvcidzIHBlcnNwZWN0 aXZlLCBpdCBpcyB2ZXJ5IGltcG9ydGFudCB0aGF0IHRoZSBzdXBwb3J0IGZvciBwZXItaW50ZXJm YWNlIE1JUHMgaXMgY292ZXJlZCBieSB0aGUgZGVmaW5pdGlvbnMuDQo+DQo+IExvb2tpbmcgYXQg ZWFybGllciB2ZXJzaW9ucyBvZiBkcmFmdC1mYXJyZWwtbXBscy10cC1taXAtbWVwLW1hcCwgdGhl cmUgd2FzIGFscmVhZHkgYSBzb2x1dGlvbiBwcm9wb3NhbCwgdXNpbmcgdGhlIFRUTC4gRW5oYW5j ZWQgc29sdXRpb25zIGhhdmUgYmVlbiB0aG9yb3VnbHkgZGlzY3Vzc2VkIGR1cmluZyB0aGlzIElF VEYgbWVldGluZy4gSXQgaXQgdG8gYmUgZXhwZWN0ZWQgdGhhdCB0aGVyZSB3aWxsIGJlIHdheXMg dG8gc29sdmUgYm90aCB0aGUgZmFzdCBwYXRoIGFuZCBmYXRlLXNoYXJpbmcgcmVxdWlyZW1lbnQu DQo+DQo+DQo+IEkgc2Vjb25kIHRoZSBwcm9wb3NhbCBpbml0aWFsbHkgbWFkZSBieSBSb2xmLCB0 byBpbmNsdWRlIGFkZGl0aW9uYWwgdGV4dCB0byBkb2N1bWVudCB0aGUgcGVyLWludGVyZmFjZSBN SVAgYWRkcmVzc2luZyBmb3IgdGhlIG9uLWRlbWFuZC1jdiBhbmQgZm9yIG90aGVyIE9BTSB0b29s cy4NCj4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPiBNYW51ZWwNCj4NCj4NCj4gRGV1dHNjaGUgVGVs ZWtvbSBBRw0KPiBHcm91cCBUZWNobm9sb2d5DQo+IE1hbnVlbCBQYXVsDQo+IFNBMy0xMQ0KPiBH b3NsYXJlciBVZmVyIDM1LTM3LCAxMDU4OSBCZXJsaW4NCj4gKzQ5IDMwIDM0OTcgLSA0Mzk0IChU ZWwuKQ0KPiArNDkgMzAgMzQ5NyAtIDQ5NTYgKEZheCkNCj4gKzQ5IDE3MSAgODYzNDAzMiAoTW9i aWwpDQo+IEUtTWFpbDogbWFpbHRvOm1hbnVlbC5wYXVsQHRlbGVrb20uZGUNCj4gaHR0cDovL3d3 dy50ZWxla29tLmNvbQ0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206 IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mDQo+PiBSb2xmIFdpbnRlcg0KPj4gU2VudDogTW9uZGF5LCBNYXJjaCAyOCwgMjAx MSAzOjAzIFBNDQo+PiBUbzogRXJpYyBHcmF5OyBoaWRla2kuZW5kby5lc0BoaXRhY2hpLmNvbQ0K Pj4gQ2M6IG1wbHNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbbXBsc10gV29ya2luZyBHcm91 cCBMYXMgQ2FsbCBvbmRyYWZ0LWlldGYtbXBscy10cC1vbi1kZW1hbmQtDQo+PiBjdi0wMw0KPj4N Cj4+IEVyaWMsDQo+Pg0KPj4gSSBnZW5lcmFsbHkgYWdyZWUgYnV0IEkgdGhpbmsgdGhlcmUgaXMg b25lIGNhc2UgYWN0dWFsbHkgd2hpY2ggbmVlZHMgYQ0KPj4gY2xvc2VyIGxvb2sgaW4gdGhpcyBy ZWdhcmQgKHdoaWNoIEkgaGludGVkIGF0IGVhcmxpZXIpLCB3aGljaCBhcmUgdGhlIHBlci0NCj4+ IGludGVyZmFjZSBNSVBzLiBZb3VyIFRUTCBleHBpcmVzICh0aGUgYWN0dWFsIGFkZHJlc3Npbmcg Yml0IGhlcmUpLCB0aGUNCj4+IGlkZW50aWZpZXIgdGVsbHMgeW91IGl0IGlzIG5vdCBpbnRlbmRl ZCBmb3IgdGhlIGluZ3Jlc3MgTUlQLCBzbyBpdCBuZWVkcw0KPj4gdG8gYmUgZm9yd2FyZGVkIHRv IHRoZSBlZ3Jlc3MgTUlQIHRocm91Z2ggdGhlIGZvcndhcmRpbmcgZW5naW5lLiBOb3cgaWYNCj4+ IHlvdSBwdWxsIHRoZSBwYWNrZXQgb3V0IG9mIHRoZSBmYXN0IHBhdGggYW5kIGluamVjdCBpdCBi YWNrIGluLCBpcyB0aGUgT0FNDQo+PiBwYWNrZXQgc3RpbGwgZmF0ZSBzaGFyaW5nPyBJZiB5b3Ug Y2FuIGRvIHRoaXMgaW4gSFcgb24gdGhlIGxpbmUgY2FyZCwgdGhlbg0KPj4gaXQgd2lsbCBhbmQg aXQgd2lsbCBqdXN0IGJlIGZvcndhcmRlZCBhcyBub3JtYWwuIEkga25vdyB0aGlzIGlzIGENCj4+ IGRpZmZlcmVudCBkcmFmdCwgYnV0IHRoaXMgd2lsbCBiZSBpbiBwYXJ0aWN1bGFyIGltcG9ydGFu dCBmb3IgcGVyZm9ybWFuY2UNCj4+IG1vbml0b3JpbmcuDQo+Pg0KPj4gQmVzdCwNCj4+DQo+PiBS b2xmDQo+Pg0KPj4NCj4+DQo+PiBORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVkIE9mZmlj ZTogTkVDIEhvdXNlLCAxIFZpY3RvcmlhIFJvYWQsIExvbmRvbg0KPj4gVzMgNkJMIHwgUmVnaXN0 ZXJlZCBpbiBFbmdsYW5kIDI4MzIwMTQNCj4+DQo+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4gRnJvbTogRXJpYyBHcmF5IFttYWlsdG86ZXJpYy5ncmF5QGVyaWNzc29uLmNv bV0NCj4+PiBTZW50OiBNb250YWcsIDI4LiBNw6RyeiAyMDExIDE0OjQ1DQo+Pj4gVG86IGhpZGVr aS5lbmRvLmVzQGhpdGFjaGkuY29tOyBSb2xmIFdpbnRlcg0KPj4+IENjOiBtcGxzQGlldGYub3Jn DQo+Pj4gU3ViamVjdDogUkU6IFJlWzJdOiBbbXBsc10gV29ya2luZyBHcm91cCBMYXMgQ2FsbCBv bmRyYWZ0LWlldGYtbXBscy10cC0NCj4+PiBvbi1kZW1hbmQtY3YtMDMNCj4+Pg0KPj4+IEhpZGVr aSwNCj4+Pg0KPj4+IAlXaGF0IHlvdSdyZSBzYXlpbmcgaXMgdHJ1ZSwgYnV0IG5vdCByZWxldmFu dCBpbiB0aGlzDQo+Pj4gY2FzZS4gIFRoZSAiYWRkcmVzc2VzIiBpbiB0aGlzIGRpc2N1c3Npb24g YXJlIG5vdCB1c2VkIHRvDQo+Pj4gZGV0ZXJtaW5lIGhvdyB0byBmb3J3YXJkIE9BTSBwYWNrZXRz LiAgVGhleSBhcmUgdXNlZCBvbmx5DQo+Pj4gYnkgdGhlIHJlY2lwaWVudCBNSVAvTUVQIHRvIHZl cmlmeSB0aGF0IHRoZSBPQU0gcGFja2V0IHdhcw0KPj4+IHByb3Blcmx5IGRlbGl2ZXJlZC4NCj4+ Pg0KPj4+IAlCeSB0aGUgd2F5LCB0aGlzIGRpc2N1c3Npb24gaXMgYW4gaW5kaWNhdGlvbiBvZiB0 aGUNCj4+PiBjb25mdXNpbmcgaW5qZWN0ZWQgYnkgY2FsbGluZyB0aGVzZSB0aGluZ3MgYWRkcmVz c2VzLiAgTXkNCj4+PiBtaXN0YWtlIGFuZCBJIGJyaW5nIGl0IHVwIG5vdyB0byBoZWxwIHRvIHN0 ZW0gdGhlIHRpZGUgb2YNCj4+PiBmdXJ0aGVyIGNvbW1lbnRzIHJlc3VsdGluZyBmcm9tIHRoYXQg Y29uZnVzaW9uLg0KPj4+DQo+Pj4gCUluIHRoZSB2ZXJzaW9uIHdlIHBvc3QgYWZ0ZXIgbGFzdCBj YWxsIGlzIGNvbXBsZXRlLA0KPj4+IHdlIHdpbGwgYmUgY2hhbmdpbmcgdGhlIHNvdXJjZSBhbmQg ZGVzdGluYXRpb24gImFkZHJlc3MiDQo+Pj4gVExWcyB0byBzb3VyY2UgYW5kIGRlc3RpbmF0aW9u ICJpZGVudGlmaWVyIiBUTFZzLg0KPj4+DQo+Pj4gCVdlIHdpbGwgYWxzbyBiZSBjb3JyZWN0aW5n IHRoZSByZWZlcmVuY2UgdG8gRFNNQVAsDQo+Pj4gYW5kIERETUFQLCBhZGRyZXNzIFRMVnMgKHdo aWNoIGlzIGluY29ycmVjdCwgYmVjYXVzZSB0aGUNCj4+PiBmb3JtYXQgZm9yIERTTUFQL0RETUFQ IGRvZXNuJ3QgaW5jbHVkZSBhICJsZW5ndGgiIGZpZWxkKS4NCj4+Pg0KPj4+IAlUaGUgZm9ybWF0 IG9mIHRoZSBEb3duc3RyZWFtIE1hcHBpbmcgKERTTUFQKSBUTFYgaXMNCj4+PiBkZWZpbmVkIGlu IFJGQyA0Mzc5LCBhbmQgd2UgYXJlIG5vdCBjaGFuZ2luZyB0aGUgZm9ybWF0DQo+Pj4gb2YgdGhh dCBUTFYuDQo+Pj4NCj4+PiAJVGhlc2UgY2hhbmdlcyBhcmUgZHJpdmVuIGJ5IGxhc3QgY2FsbCBj b21tZW50cyB3ZQ0KPj4+IGhhdmUgYWxyZWFkeSByZWNlaXZlZCAoc2VlIEpvZWwgSGFscGVybidz IGNvbW1lbnRzIG9uIHRoZQ0KPj4+IG1haWxpbmcgbGlzdCkgYW5kIGFyZSAtIGluIHBhcnQgLSB0 byBjb3JyZWN0IGFjY2lkZW50YWwNCj4+PiB1c2Ugb2YgdGhlIHdvcmQgImFkZHJlc3MiIGZvciBz b3VyY2UgYW5kIGRlc3RpbmF0aW9uDQo+Pj4gaWRlbnRpZmllciBUTFZzICh3aGljaCBpcyB3aGF0 IHdlIGhhZCBkaXNjdXNzZWQgYmVmb3JlDQo+Pj4gSSBnZW5lcmF0ZWQgdGhlIC0wMyB2ZXJzaW9u IGFtb25nIHRoZSBhdXRob3JzIG9mIHNldmVyYWwNCj4+PiBvZiB0aGUgY3VycmVudCBzZXQgb2Yg TVBMUy1UUCBkcmFmdHMpLg0KPj4+DQo+Pj4gCUluIHRoZSBjYXNlIG9mIHNvdXJjZSBhbmQgZGVz dGluYXRpb24gaWRlbnRpZmllcnMsDQo+Pj4gdGhlc2Ugd2lsbCBiZSB1c2VkIGV4Y2x1c2l2ZWx5 IHRvIHZlcmlmeSB0aGF0IGFuIE9BTSBQRFUNCj4+PiBoYXMgYmVlbiBjb3JyZWN0bHkgcmVjZWl2 ZWQgYnkgaXRzIGludGVuZGVkIHJlY2lwaWVudC4NCj4+PiBCZWNhdXNlIHRoaXMgaXMgYW4gb24t ZGVtYW5kIGNvbm5lY3Rpdml0eSB2ZXJpZmljYXRpb24NCj4+PiBwcm90b2NvbCwgdGhhdCBpcyBl eHBlY3RlZCB0byBiZSB1c2VkIG9ubHkgb24gdGhvc2UNCj4+PiBvY2Nhc2lvbnMgd2hlbiB0aGVy ZSBpcyBhIG5ldHdvcmsgcHJvYmxlbSB0aGF0IG5lZWRzIHRvDQo+Pj4gYmUgZGlhZ25vc2VkLCBh bmQgdGhlIGluZm9ybWF0aW9uIGlzIG5vdCBzZWVuIChhbmQgbm90DQo+Pj4gdmlzaWJsZSAtIHdp dGhvdXQgbGF5ZXIgdmlvbGF0aW9ucyksIG9wdGltaXppbmcgdGhlc2UNCj4+PiBvYmplY3RzIGZv ciBzb2Z0d2FyZSBtYWtlcyBzZW5zZS4NCj4+Pg0KPj4+IAlJbiBhZGRpdGlvbiwgc2luY2UgZWl0 aGVyIG1heSBiZSBpbmNsdWRlZCAod2hpY2gNCj4+PiBpbmNsdWRlcyB0aGUgcG9zc2liaWxpdHkg b2YgaW5jbHVkaW5nIGJvdGgpLCBpdCBpcyB0aGUNCj4+PiBjYXNlIGFscmVhZHkgdGhhdCB3ZSB3 b3VsZCB0aGVuIG5lZWQgdG8gZGVjaWRlIHdoaWNoIGlzDQo+Pj4gdG8gZ28gZmlyc3QgLSBhc3N1 bWluZyB3ZSB3YW50ZWQgdG8gZG8gdGhpcyAod2hpY2ggd2UNCj4+PiBkbyBub3QpLg0KPj4+DQo+ Pj4gLS0NCj4+PiBFcmljDQo+Pj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ IEZyb206IGhpZGVraS5lbmRvLmVzQGhpdGFjaGkuY29tIFttYWlsdG86aGlkZWtpLmVuZG8uZXNA aGl0YWNoaS5jb21dDQo+Pj4gU2VudDogTW9uZGF5LCBNYXJjaCAyOCwgMjAxMSA4OjExIEFNDQo+ Pj4gVG86IEVyaWMgR3JheTsgUm9sZi5XaW50ZXJAbmVjbGFiLmV1DQo+Pj4gQ2M6IG1wbHNAaWV0 Zi5vcmcNCj4+PiBTdWJqZWN0OiBSZVsyXTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENhbGwg b25kcmFmdC1pZXRmLW1wbHMtdHAtb24tDQo+Pj4gZGVtYW5kLWN2LTAzDQo+Pj4gSW1wb3J0YW5j ZTogSGlnaA0KPj4+DQo+Pj4gSGkgRXJpYyBhbmQgUm9sZiwNCj4+Pg0KPj4+IEknbSBzb3JyeSBm b3IgaW50ZXJydXB0aW5nLg0KPj4+DQo+Pj4gSSBhZ3JlZSB3aXRoIFJvbGYgcmVnYXJkaW5nIHRo ZSBwZXItaW50ZXJmYWNlIE1JUCBkaXNjdXNzaW9uLg0KPj4+IFdlIGhhdmUgdG8gY29uc2lkZXIg dGhlIEhXIGltcGxlbWVudGF0aW9uIGFzcGVjdCwNCj4+PiBiZWNhdXNlIHRyYXBwaW5nIG9mIGFu IE9BTSBwYWNrZXQgaXMgSFcgcnVsZS9mdW5jdGlvbmFsaXR5IGV2ZW4gaW4NCj4+PiByb3V0ZXJz Lg0KPj4+DQo+Pj4gSWYgZXZlcnkgT0FNIHBhY2tldCBpcyB0cmFwcGVkIHRvIENQVQ0KPj4+IGFu ZCB0aGUgT0FNIHBhY2tldHMgd2hpY2ggc2hvdWxkIE5PVCBiZSBwcm9jZXNzZWQgaW4gdGhlIElu dGVyZmFjZQ0KPj4+IGFyZSByZXR1cm5lZCB0byBEYXRhLXBsYW5lLA0KPj4+IGl0IGlzIGRpZmZl cmVudCBmb3J3YXJkaW5nIHBhdGggZnJvbSB1c2VyIHBhY2tldHMsDQo+Pj4gd2hpY2ggaXMgTk9U IHRoZSBDb25uZWN0aXZpdHkgVmVyaWZpY2F0aW9uIG9mIHRoZSB1c2VyIHBhdGguDQo+Pj4NCj4+ PiBUaGVyZWZvcmUsIHdlIHNob3VsZCB0YWtlIHRoZSBIVyBhc3BlY3QgYW5kIGZsZXhpYmlsdHkg aW50byBhY2NvdW50DQo+Pj4gY29uY3VycmVudGx5Lg0KPj4+IElmIGFuIGFkZHJlc3MgVExWIE1V U1QgYmUgdGhlIGZpcnN0IGluIFRMVnMsDQo+Pj4gaXQgaXMgZW5vdWdoIHRvIG1ha2UgSFcgaW1w bGVtZW50YXRpb24gZWFzeS4NCj4+Pg0KPj4+IEJSLA0KPj4+IEhpZGVraQ0KPj4+DQo+Pj4NCj4+ Pg0KPj4+PiBSb2xmLA0KPj4+Pg0KPj4+PiAJVGhlIHdvcmRzIHlvdSBwcm9wb3NlIGFyZSBva2F5 IHdpdGggbWUuDQo+Pj4+DQo+Pj4+IAlJIHRob3VnaHQgdGhlIE1JUC9pbnRlcmZhY2UgYW5kIGFk ZHJlc3MgbG9jYXRpb24gaXNzdWVzDQo+Pj4+IHdlcmUgc2VwYXJhdGUuDQo+Pj4+DQo+Pj4+IAlJ J3ZlIHBlcnNvbmFsbHkgaGFkIHByb2JsZW1zIHdpdGggcHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMN Cj4+Pj4gdGhhdCByZXF1aXJlIG9yZGVyaW5nIG9mIFRMVnMuICBJbiBwYXJ0aWN1bGFyLCB0aGlz IGlzIG5vdCB2ZXJ5DQo+Pj4+IHJvYnVzdCBpbiB0ZXJtcyBvZiAiZnV0dXJlLXByb29maW5nLiIg IFdoYXQgaGFwcGVucyBpZiBuZXcgVExWcw0KPj4+PiBhcmUgYWRkZWQgbGF0ZXIgb247IGZvciBp bnN0YW5jZSwgc3VwcG9zZSBhdCBzb21lIHBvaW50IHdlIGhhdmUNCj4+Pj4gbXVsdGlwbGUgImFk ZHJlc3MiIFRMVnM/DQo+Pj4+DQo+Pj4+IAlBbHNvLCB0aGUgZmFjdCB0aGF0IGltcGxlbWVudGF0 aW9ucyBhcmUgYWxsb3dlZCB0byBhdHRhY2gNCj4+Pj4gVExWcyBpbiBhbnkgYXJiaXRyYXJ5IG9y ZGVyIGFsbG93cyBjb25zaWRlcmFibGUgZmxleGliaWx0eSBpbg0KPj4+PiBpbXBsZW1lbnRhdGlv bi4gIE1lc3NhZ2VzIGNhbiBiZSBidWlsdCBpbiBhcmJpdHJhcmlseSBtYW55IHdheXMuDQo+Pj4+ IFRoaXMgdG9vIGNhbiBiZSBhIGZ1dHVyZS1wcm9vZmluZyBpc3N1ZS4NCj4+Pj4NCj4+Pj4gCUkg d291bGQgcHJlZmVyIG5vdCB0byBzdGFydCBkb3duIHRoZSByb2FkIG9mIHJlcXVpcmluZyBhDQo+ Pj4+IHN1YnNldCBvZiBUTFZzIHRvIGFwcGVhciBpbiBhIGNlcnRhaW4gb3JkZXIsIGFuZCBzYXlp bmcgd2UgaGF2ZQ0KPj4+PiBvbmUgVExWIHRoYXQgbmVlZHMgdG8gYmUgZmlyc3QgaXMgZG9pbmcg anVzdCB0aGF0Lg0KPj4+Pg0KPj4+PiAtLQ0KPj4+PiBFcmljDQo+Pj4+DQo+Pj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IFJvbGYgV2ludGVyIFttYWlsdG86Um9sZi5X aW50ZXJAbmVjbGFiLmV1XQ0KPj4+PiBTZW50OiBNb25kYXksIE1hcmNoIDI4LCAyMDExIDY6MTkg QU0NCj4+Pj4gVG86IEVyaWMgR3JheQ0KPj4+PiBDYzogbXBsc0BpZXRmLm9yZw0KPj4+PiBTdWJq ZWN0OiBSRTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENhbGwgb24gZHJhZnQtaWV0Zi1tcGxz LXRwLW9uLQ0KPj4+IGRlbWFuZC1jdi0wMw0KPj4+PiBJbXBvcnRhbmNlOiBIaWdoDQo+Pj4+DQo+ Pj4+IEhpLA0KPj4+Pg0KPj4+PiBJIHN0aWxsIHRoaW5rIHRoZXJlIGlzIGEgbG9naWNhbCBlcnJv ci4gTGV0IG1lIGV4cGxhaW4uIEluIGNhc2UgdGhlcmUNCj4+PiBpcyBubyBJUCB5b3Ugc2ltcGx5 IGNhbm5vdCB1c2UgaXQuIFlvdSBzYXkgeW91IGNvdWxkIGVuYWJsZSBJUCBidXQgdGhlbg0KPj4+ IHRoYXQgaXMgbm90IGEgY2FzZSB3aGVyZSB0aGVyZSBpcyBubyBJUC4gSW4gb3JkZXIgdG8gYmUg Y29uc3RydWN0aXZlDQo+Pj4gaGVyZSBpcyBhIHRleHQgY2hhbmdlIHN1Z2dlc3Rpb246DQo+Pj4+ DQo+Pj4+ICJJbiBjZXJ0YWluIE1QTFMtVFAgZGVwbG95bWVudCBzY2VuYXJpb3MgSVAgYWRkcmVz c2luZyBtaWdodCBub3QgYmUNCj4+PiBhdmFpbGFibGUuIEluIHRob3NlIGNhc2VzIE9uLWRlbWFu ZCBDViBhbmQvb3Igcm91dGUgdHJhY2luZyBNVVNUIGJlIHJ1bg0KPj4+IHdpdGhvdXQgSVAgYWRk cmVzc2luZywgdXNpbmcgdGhlIEFDSCBjaGFubmVsIHR5cGUgc3BlY2lmaWVkIGluIFNlY3Rpb24N Cj4+PiAzLiBJbiBvdGhlciBjYXNlcyBpdCBtaWdodCBiZSBhdmFpbGFibGUsIGhvd2V2ZXIsIGl0 IG1heSBiZSBwcmVmZXJyZWQNCj4+PiB0byB1c2Ugc29tZSBmb3JtIG9mIG5vbi1JUCBlbmNhcHN1 bGF0aW9uLiBJbiB0aG9zZSBjYXNlcywgdGhlDQo+Pj4gcHJvY2VkdXJlcyBhcyBvdXRsaW5lZCBp biBzZWN0aW9uIDMgU0hPVUxEIGFsc28gYmUgdXNlZC4iDQo+Pj4+DQo+Pj4+IFJlZ2FyZGluZyB0 aGUgcGVyLWludGVyZmFjZSBNSVAgZGlzY3Vzc2lvbi4gVGhlIEhXIGFzcGVjdCBhbHNvIHBvcHBl ZA0KPj4+IHVwIGluIHRoZSBQV0UzIHNlc3Npb24gYW5kIEkgdGhpbmsgdGhpcyBpcyBhbiBpbXBv cnRhbnQgY29uc2lkZXJhdGlvbiwNCj4+PiBpbiBwYXJ0aWN1bGFyIGZvciBPQU0uIEV2ZW4gaWYg d2UgdGFsayBhYm91dCBUTFZzLCB3ZSBjb3VsZCBtYWtlIGl0IGENCj4+PiBNVVNUIHRoYXQgYW4g QWRkcmVzcyBUTFYgaXMgYWx3YXlzIHRoZSBmaXJzdCBvbmUgdG8gYXBwZWFyLiBJZiB5b3UgY2Fu DQo+Pj4gZmFjaWxpdGF0ZSBhbiBlYXN5IGltcGxlbWVudGF0aW9uIGluIGhhcmR3YXJlLCBJIHNl ZSBubyByZWFzb24gdG8NCj4+PiBkZWxpYmVyYXRlbHkgbm90IGRvIGl0Lg0KPj4+Pg0KPj4+PiBC ZXN0LA0KPj4+Pg0KPj4+PiBSb2xmDQo+Pj4+DQo+Pj4+DQo+Pj4+IE5FQyBFdXJvcGUgTGltaXRl ZCB8IFJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2UsIDEgVmljdG9yaWEgUm9hZCwNCj4+PiBM b25kb24gVzMgNkJMIHwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIDI4MzIwMTQNCj4+Pj4NCj4+Pj4N Cj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBFcmljIEdyYXkg W21haWx0bzplcmljLmdyYXlAZXJpY3Nzb24uY29tXQ0KPj4+Pj4gU2VudDogTW9udGFnLCAyOC4g TcOkcnogMjAxMSAxMTo0Mw0KPj4+Pj4gVG86IFJvbGYgV2ludGVyDQo+Pj4+PiBDYzogbG9hQHBp Lm51OyBtcGxzQGlldGYub3JnDQo+Pj4+PiBTdWJqZWN0OiBSRTogW21wbHNdIFdvcmtpbmcgR3Jv dXAgTGFzIENhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLQ0KPj4+Pj4gZGVtYW5kLWN2LTAz DQo+Pj4+Pg0KPj4+Pj4gUm9sZiwNCj4+Pj4+DQo+Pj4+PiAJV2l0aCByZWdhcmQgdG8gdGhlIHVz ZSBvZiBTSE9VTEQgKHZlcnNlcyBNVVNUKSAtIHRoZSBpbnRlbnQNCj4+Pj4+IChhY2NvcmRpbmcg dG8gUkZDIDIxMTkgLSBzZWUgdGhlIHF1b3RlIGJlbG93KSBpcyBjb25zaXN0ZW50IHdpdGgNCj4+ Pj4+IHRoaXMgY2FzZS4gIElmIC0gZm9yIHNvbWUgcmVhc29uIC0gb25lIGhhZCBhIHJlYWxseSBn b29kIHJlYXNvbiB0bw0KPj4+Pj4gdXNlIElQIGFkZHJlc3NpbmcgaW4gc29tZSBzcGVjaWZpYyBj YXNlLCBvbmUgY291bGQgdGFrZSBzdGVwcyB0bw0KPj4+Pj4gbWFrZSBJUCBhZGRyZXNzaW5nIGF2 YWlsYWJsZS4NCj4+Pj4+DQo+Pj4+PiAJVGhpcyBjb3VsZCBiZSBzYWlkIHRvIGludHJvZHVjZSBh IGxvZ2ljYWwgZGlzY29ubmVjdCwgYnV0IHdlDQo+Pj4+PiBhcmUgc2F2ZWQgZnJvbSBnb2luZyBk b3duIHRoYXQgcGF0aCBieSB0aGUgZmFjdCB0aGF0IHRoZSBzdGF0ZW1lbnQNCj4+Pj4+IGFsc28g aW5jbHVkZXMgdGhlIGNhc2Ugd2hlcmUgKGZvciBzb21lIHJlYXNvbikgdGhlcmUgaXMgYSBjYXNl IGluDQo+Pj4+PiB3aGljaCBzb21lIG90aGVyIGFkZHJlc3Npbmcgc2NoZW1lIG1pZ2h0IGJlIHBy ZWZlcnJlZC4gIEluIG1hbnkgb2YNCj4+Pj4+IHRoZSBjYXNlcyB3aGVyZSBhbm90aGVyIGFkZHJl c3Npbmcgc2NoZW1lIG1heSBiZSBwcmVmZXJyZWQsIGl0IGlzDQo+Pj4+PiBzdGlsbCBwb3NzaWJs ZSAoaW4gZmFjdCBsaWtlbHkpIHRoYXQgSVAgYWRkcmVzc2luZyBpcyBhdmFpbGFibGUuDQo+Pj4+ Pg0KPj4+Pj4gCU90aGVyd2lzZSwgaXQgd291bGQgbm90IGhhdmUgYmVlbiBuZWNlc3NhcnkgdG8g ZGlzdGluZ3Vpc2gNCj4+Pj4+IHRoaXMgY2FzZSBmcm9tIHRoZSBvbmUgaW4gd2hpY2ggSVAgYWRk cmVzc2luZyBpcyBub3QgYXZhaWxhYmxlLg0KPj4+Pj4NCj4+Pj4+IAlGb3IgdGhlIGNhc2Ugd2hl cmUgSVAgYWRkcmVzc2luZyBpcyBub3QgdGhlIHByZWZlcnJlZCBtb2RlLA0KPj4+Pj4gd2UgYXJl IHJlY29tbWVuZGluZyBhIG1vZGUgaW4gd2hpY2ggaXQgaXMgbm90IG5lY2Vzc2FyeS4NCj4+Pj4+ DQo+Pj4+PiAJV2l0aCByZWdhcmQgdG8gaGF2aW5nIGFkZHJlc3NlcyBsb2NhdGVkIGluIHRoZSBz YW1lIHBsYWNlLA0KPj4+Pj4gdGhpcyBwcm90b2NvbCBpcyBtZWFudCBmb3IgY29ubmVjdGl2aXR5 IHRlc3Rpbmcgb24gYW4gb24tZGVtYW5kDQo+Pj4+PiBiYXNpcyBhbmQgaXMgdGhlcmVmb3JlIG5v dCBvcHRpbWl6ZWQgZm9yIHByb2Nlc3NpbmcgaW4gaGFyZHdhcmUuDQo+Pj4+Pg0KPj4+Pj4gCVdo ZXRoZXIgYWRkcmVzc2VzIG9yIGlkZW50aWZpZXJzLCBpZiB3ZSBhcmUgdGFsa2luZyBhYm91dA0K Pj4+Pj4gVExWIGNvbnRlbnRzLCB0aGVyZSBhcmUgaXNzdWVzIHdpdGggdHJ5aW5nIHRvIGd1YXJh bnRlZSBsb2NhdGlvbg0KPj4+Pj4gb2Ygc3BlY2lmaWMgY29udGVudCwgYmVjYXVzZSBvZiB0aGUg ZmFjdCB0aGF0IHRoZSBUTFYgaW4gcXVlc3Rpb24NCj4+Pj4+IHdpbGwgcHJvYmFibHkgZm9sbG93 IG90aGVyIFRMVnMgLSB0aHVzIG1ha2luZyBsb2NhdGlvbnMgZGlmZmljdWx0DQo+Pj4+PiB0byBw cmVkaWN0IGluIGFueSBjYXNlLg0KPj4+Pj4NCj4+Pj4+IAlXaXRoIHJlZ2FyZCB0byBuZWVkaW5n IG1vcmUgdGV4dCBvbiBwZXItaW50ZXJmYWNlIE1JUHMsIGRvDQo+Pj4+PiB5b3UgaGF2ZSBzcGVj aWZpYyBzdWdnZXN0aW9ucyBhcyB0byB3aGF0IHRleHQgd2UgbWlnaHQgYWRkPw0KPj4+Pj4NCj4+ Pj4+IAlJIHVuZGVyc3RhbmQgKGZyb20gZGlzY3Vzc2lvbiB3aXRoIFdHIGNoYWlycykgdGhhdCB3 ZSBhcmUNCj4+Pj4+IG5vdCBhbGxvd2VkIHRvIGV4cGxpY2l0bHkgYWRkcmVzcyBsYXN0IGNhbGwg Y29tbWVudHMgZHVyaW5nIHRoZQ0KPj4+Pj4gSUVURiBtZWV0aW5nIGluIFByYWd1ZSwgYmVjYXVz ZSB0aGUgbGFzdCBjYWxsIGlzIHN0aWxsIG9uZ29pbmcNCj4+Pj4+IGF0IHRoYXQgdGltZS4NCj4+ Pj4+DQo+Pj4+PiAtLQ0KPj4+Pj4gRXJpYw0KPj4+Pj4NCj4+Pj4+IFBTIC0NCj4+Pj4+ICBGcm9t IFJGQyAyMTE5IC0NCj4+Pj4+ICdTSE9VTEQgICBUaGlzIHdvcmQsIG9yIHRoZSBhZGplY3RpdmUg IlJFQ09NTUVOREVEIiwgbWVhbiB0aGF0IHRoZXJlDQo+Pj4+PiAgICAgICAgICAgIG1heSBleGlz dCB2YWxpZCByZWFzb25zIGluIHBhcnRpY3VsYXIgY2lyY3Vtc3RhbmNlcyB0bw0KPj4+Pj4gICAg ICAgICAgICBpZ25vcmUgYSBwYXJ0aWN1bGFyIGl0ZW0sIGJ1dCB0aGUgZnVsbCBpbXBsaWNhdGlv bnMgbXVzdA0KPj4+Pj4gICAgICAgICAgICBiZSB1bmRlcnN0b29kIGFuZCBjYXJlZnVsbHkgd2Vp Z2hlZCBiZWZvcmUgY2hvb3NpbmcgYQ0KPj4+Pj4gICAgICAgICAgICBkaWZmZXJlbnQgY291cnNl LicNCj4+Pj4+DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTog bXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYNCj4+PiBPZg0KPj4+Pj4gUm9sZiBXaW50ZXINCj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIE1h cmNoIDIyLCAyMDExIDQ6NTcgQU0NCj4+Pj4+IFRvOiBsb2FAcGkubnU7IG1wbHNAaWV0Zi5vcmcN Cj4+Pj4+IFN1YmplY3Q6IFJlOiBbbXBsc10gV29ya2luZyBHcm91cCBMYXMgQ2FsbCBvbiBkcmFm dC1pZXRmLW1wbHMtdHAtb24tDQo+Pj4+PiBkZW1hbmQtY3YtMDMNCj4+Pj4+DQo+Pj4+PiBIaSwN Cj4+Pj4+DQo+Pj4+PiBzb21lIGNvbW1lbnRzIGJlbG93Og0KPj4+Pj4NCj4+Pj4+IFNlY3Rpb24g MS4zIHNheXM6ICIgSW4gY2VydGFpbiBNUExTLVRQIGRlcGxveW1lbnQgc2NlbmFyaW9zIElQDQo+ Pj4+PiBhZGRyZXNzaW5nIG1pZ2h0IG5vdCBiZQ0KPj4+Pj4gICAgIGF2YWlsYWJsZSBvciBpdCBt YXkgYmUgcHJlZmVycmVkIHRvIHVzZSBzb21lIGZvcm0gb2Ygbm9uLUlQDQo+Pj4+PiAgICAgZW5j YXBzdWxhdGlvbiBmb3IgT24tZGVtYW5kIENWLCByb3V0ZSB0cmFjaW5nIGFuZCBCRkQgcGFja2V0 cy4NCj4+PiBJbg0KPj4+Pj4gICAgIHN1Y2ggc2NlbmFyaW9zLCBPbi1kZW1hbmQgQ1YgYW5kL29y IHJvdXRlIHRyYWNpbmcgU0hPVUxEIGJlIHJ1bg0KPj4+Pj4gICAgIHdpdGhvdXQgSVAgYWRkcmVz c2luZy4uLiINCj4+Pj4+DQo+Pj4+PiBJIGFtIG5vdCBzdXJlIHRoZSAiU0hPVUxEIiBpcyByaWdo dCBoZXJlLiBJZiBubyBJUCBhZGRyZXNzaW5nIGlzDQo+Pj4+PiBhdmFpbGFibGUsIHRoaXMgdGhp bmcgTVVTVCBiZSBydW4gd2l0aG91dCBJUCBhZGRyZXNzaW5nLCBtdXN0bid0IGl0Pw0KPj4+Pj4N Cj4+Pj4+IEkgdGhpbmsgc29tZSBhZGRpdGlvbmFsIHRleHQgcmVnYXJkaW5nIHBlci1pbnRlcmZh Y2UgTUlQIGFkZHJlc3NpbmcNCj4+Pj4+IHdvdWxkIGJlIG5pY2UuIEFzIGZhciBhcyBJIHVuZGVy c3RhbmQgdGhlIGRvY3VtZW50LCBhbGwgVExWcyB3aWxsIGJlDQo+Pj4+PiBpbnNpZGUgdGhlIExT UCBwaW5nIHBhY2tldCAocmF0aGVyIHRoYW4gYXMgQUNIIFRMVnMpLg0KPj4+Pj4NCj4+Pj4+IFNv bWUgcGVvcGxlIGhhZCBjb25jZXJucyBlYXJsaWVyLCB0aGF0IGFkZHJlc3NpbmcgaW5mb3JtYXRp b24gc2hvdWxkDQo+Pj4gYmUNCj4+Pj4+IGluIGEgZml4ZWQgbG9jYXRpb24gZm9yIGVhc2llciBw cm9jZXNzaW5nLiBJcyB0aGlzIHRoZSBjYXNlIGhlcmUgSQ0KPj4+Pj4gd29uZGVyPw0KPj4+Pj4N Cj4+Pj4+IEl0IHdvdWxkIGJlIG5pY2UgaWYgeW91IGNvdWxkIGFkZHJlc3MgdGhpcyBpbiB5b3Vy IHByZXNlbnRhdGlvbiBpbg0KPj4+Pj4gUHJhZ3VlLg0KPj4+Pj4NCj4+Pj4+IFRoYW5rcywNCj4+ Pj4+DQo+Pj4+PiBSb2xmDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE5FQyBFdXJvcGUgTGltaXRlZCB8 IFJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2UsIDEgVmljdG9yaWEgUm9hZCwNCj4+Pj4+IExv bmRvbiBXMyA2QkwgfCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgMjgzMjAxNA0KPj4+Pj4NCj4+Pj4+ DQo+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+PiBGcm9tOiBtcGxzLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+Pj4gQmVo YWxmDQo+Pj4+PiBPZg0KPj4+Pj4+IGxvYUBwaS5udQ0KPj4+Pj4+IFNlbnQ6IE1pdHR3b2NoLCAx Ni4gTcOkcnogMjAxMSAwMDoyNg0KPj4+Pj4+IFRvOiBtcGxzQGlldGYub3JnDQo+Pj4+Pj4gQ2M6 IE1QTFMtVFAgYWQgaG9jIHRlYW0NCj4+Pj4+PiBTdWJqZWN0OiBbbXBsc10gV29ya2luZyBHcm91 cCBMYXMgQ2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtb24tDQo+Pj4+PiBkZW1hbmQtDQo+Pj4+ Pj4gY3YtMDMNCj4+Pj4+Pg0KPj4+Pj4+IFdvcmtpbmcgR3JvdXAsDQo+Pj4+Pj4NCj4+Pj4+PiB0 aGlzIGlzIHRvIHN0YXJ0IGEgMyB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQo+Pj4+ Pj4NCj4+Pj4+PiBkcmFmdC1pZXRmLW1wbHMtdHAtb24tZGVtYW5kLWN2LTAzDQo+Pj4+Pj4NCj4+ Pj4+PiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0byB0aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxp c3QNCj4+Pj4+PiBtcGxzQGlldGYub3JnDQo+Pj4+Pj4NCj4+Pj4+PiBUaGUgd29ya2luZyBncm91 cCBsYXN0IGNhbGwgZW5kcyBvbiBBcHJpbCA4LCAyMDExLg0KPj4+Pj4+DQo+Pj4+Pj4gL0xvYQ0K Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0K Pj4+Pj4+IG1wbHNAaWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHMNCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+Pj4gbXBsc0BpZXRmLm9y Zw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IG1w bHMgbWFpbGluZyBsaXN0DQo+Pj4+IG1wbHNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+Pj4+DQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+IG1w bHNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBt cGxzIG1haWxpbmcgbGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscw0KPg0KDQoNCi0tIA0KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioNCllvc2hpbm9yaSBLb2lrZQ0KT3B0aWNhbCBUcmFuc21pc3Npb24g U3lzdGVtcyBEZXZlbG9wbWVudCBQcm9qZWN0DQpGaXJzdCBQcm9tb3Rpb24gUHJvamVjdA0KTlRU IE5ldHdvcmsgU2VydmljZSBTeXN0ZW1zIExhYm9yYXRvcmllcw0KTklQUE9OIFRFTEVHUkFQSCBB TkQgVEVMRVBIT05FIENPUlBPUkFUSU9ODQpUZWxlcGhvbmU6ICs4MSA0MjIgNTkgNjcyMw0KRmFj c2ltaWxlOiArODEgNDIyIDU5IDM0OTQNCkVtYWlsOiBrb2lrZS55b3NoaW5vcmlAbGFiLm50dC5j by5qcA0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0K bXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz DQo= From eric.gray@ericsson.com Wed Mar 30 09:13:17 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE0E63A6AB4 for ; Wed, 30 Mar 2011 09:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.826 X-Spam-Level: X-Spam-Status: No, score=-5.826 tagged_above=-999 required=5 tests=[AWL=0.773, 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 wt6rtoD5-j3R for ; Wed, 30 Mar 2011 09:13:15 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 84BF83A6A48 for ; Wed, 30 Mar 2011 09:13:15 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2UGEnL1021192; Wed, 30 Mar 2011 11:14:52 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 30 Mar 2011 12:14:49 -0400 From: Eric Gray To: "Manuel.Paul@telekom.de" , "Rolf.Winter@neclab.eu" , "hideki.endo.es@hitachi.com" Date: Wed, 30 Mar 2011 12:14:47 -0400 Thread-Topic: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-cv-03 Thread-Index: AQHL7UEzNDkNsNSfrUy2+prVZl2z35RCj7sAgAAj/7CAAzkQQIAADGEw Message-ID: References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu><791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd><791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.de> 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@ietf.org" Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 16:13:17 -0000 Manuel, Several of us had an off-line discussion, in which we concluded that there are no changes required - or even any that could reasonably be expected to be made - to the draft "draft-ietf-mpls-tp-on-demand-cv-03" based on per interface MIP support. Whatever technique may be developed to support the details of per-interface MIP support was something that could be documented in a follow-on RFC. In fact, there is a draft that has been written that appears to be explicitly for that purpose. That draft is one you refer to (i.e. - draft-farrel-mpls-tp-mip-mep-map). The details of why this is true, as well as what was discussed, are below. It appears that there are multiple options in how to proceed (including the one you mention that relies on use of TTL) and that authors of the draft that will eventually detail the desired approach have not yet confirmed with the WG which of all possible approaches might be acceptable to the WG. In our draft, we define information that may be used to identify a destination interface. This would allow for connectivity verification to be done to either the ingress or egress interface. As stated earlier on the list, the intent in using this information is simply to verify that it has been received by the intended maintenance entity. The information in on-demand cv TLVs is not - and has never been - intended to be used in forwarding. The issue raised in discussion was that - if we were to subsequently decide to try to use these on-demand TLVs (specifically, the destination identifier TLV) to try to determine which interface an OAM packet is intended for, it would not - for certain implementations and approaches that might be chosen - necessarily result in "shared-fate" for data and OAM packets, i.e. - IFF the OAM packet were shunted to a slow-path processor and TLVs had to be checked to decide that the OAM PDU was actually intended to go to the egress interface (since it would now have to be sent to the egress interface). We view this as attempting to use the TLVs to decide how to forward an OAM packet. We suggested that it would be more appropriate to put the information the mechanism (that may be proposed) needs in a more appropriate field of the message(s) that mechanism would use. The objection was raised that this would mean that potentially the exact same information could be present in this message twice (if - for example - it was in the field proposed and also in a TLV). It is not clear how this might be considered an issue given that there is typically not a lot of content in OAM messages, and - even if there were - source and destination identifier TLVs are optional. Also, in the course of the discussion, it was not clear that not all possible approaches have been given due consideration, and it was clear that not all (or possibly any) of the considered solutions would be guaranteed to be compatible with every implementation. For example, one suggestion that had apparently not been considered was the use of different channel types to indicate whether a specific OAM message is intended to be intercepted by a maintenance entity associated with the ingress or egress interface. This suggestion had not been considered. For another example, we pointed out to the authors that the entire premise - on which the suggested behavior relies is an assumption that a given device checks for TTL expiry at the ingress interface. While this is a common implementation assumption, it is in no way guaranteed. As a result of all of these points, we agreed that we cannot justify imposing a specific ordering requirement on the TLVs in the on demand CV messages - hence there is no change required specifically to address this issue. -- Eric -----Original Message----- From: Manuel.Paul@telekom.de [mailto:Manuel.Paul@telekom.de] Sent: Wednesday, March 30, 2011 10:32 AM To: Rolf.Winter@neclab.eu; Eric Gray; hideki.endo.es@hitachi.com Cc: mpls@ietf.org Subject: RE: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-c= v-03 Importance: High Dear All, I really appreciate the consideration on the per-interface MIP support and = the discussion moving forward. >From an operator's perspective, it is very important that the support for p= er-interface MIPs is covered by the definitions. Looking at earlier versions of draft-farrel-mpls-tp-mip-mep-map, there was = already a solution proposal, using the TTL. Enhanced solutions have been th= orougly discussed during this IETF meeting. It it to be expected that there= will be ways to solve both the fast path and fate-sharing requirement. I second the proposal initially made by Rolf, to include additional text to= document the per-interface MIP addressing for the on-demand-cv and for oth= er OAM tools. Best regards, Manuel Deutsche Telekom AG Group Technology Manuel Paul SA3-11 Goslarer Ufer 35-37, 10589 Berlin +49 30 3497 - 4394 (Tel.) +49 30 3497 - 4956 (Fax) +49 171 8634032 (Mobil) E-Mail: mailto:manuel.paul@telekom.de http://www.telekom.com > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rolf Winter > Sent: Monday, March 28, 2011 3:03 PM > To: Eric Gray; hideki.endo.es@hitachi.com > Cc: mpls@ietf.org > Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand= - > cv-03 > > Eric, > > I generally agree but I think there is one case actually which needs a > closer look in this regard (which I hinted at earlier), which are the per= - > interface MIPs. Your TTL expires (the actual addressing bit here), the > identifier tells you it is not intended for the ingress MIP, so it needs > to be forwarded to the egress MIP through the forwarding engine. Now if > you pull the packet out of the fast path and inject it back in, is the OA= M > packet still fate sharing? If you can do this in HW on the line card, the= n > it will and it will just be forwarded as normal. I know this is a > different draft, but this will be in particular important for performance > monitoring. > > Best, > > Rolf > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Londo= n > W3 6BL | Registered in England 2832014 > > > > -----Original Message----- > > From: Eric Gray [mailto:eric.gray@ericsson.com] > > Sent: Montag, 28. M=E4rz 2011 14:45 > > To: hideki.endo.es@hitachi.com; Rolf Winter > > Cc: mpls@ietf.org > > Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp- > > on-demand-cv-03 > > > > Hideki, > > > > What you're saying is true, but not relevant in this > > case. The "addresses" in this discussion are not used to > > determine how to forward OAM packets. They are used only > > by the recipient MIP/MEP to verify that the OAM packet was > > properly delivered. > > > > By the way, this discussion is an indication of the > > confusing injected by calling these things addresses. My > > mistake and I bring it up now to help to stem the tide of > > further comments resulting from that confusion. > > > > In the version we post after last call is complete, > > we will be changing the source and destination "address" > > TLVs to source and destination "identifier" TLVs. > > > > We will also be correcting the reference to DSMAP, > > and DDMAP, address TLVs (which is incorrect, because the > > format for DSMAP/DDMAP doesn't include a "length" field). > > > > The format of the Downstream Mapping (DSMAP) TLV is > > defined in RFC 4379, and we are not changing the format > > of that TLV. > > > > These changes are driven by last call comments we > > have already received (see Joel Halpern's comments on the > > mailing list) and are - in part - to correct accidental > > use of the word "address" for source and destination > > identifier TLVs (which is what we had discussed before > > I generated the -03 version among the authors of several > > of the current set of MPLS-TP drafts). > > > > In the case of source and destination identifiers, > > these will be used exclusively to verify that an OAM PDU > > has been correctly received by its intended recipient. > > Because this is an on-demand connectivity verification > > protocol, that is expected to be used only on those > > occasions when there is a network problem that needs to > > be diagnosed, and the information is not seen (and not > > visible - without layer violations), optimizing these > > objects for software makes sense. > > > > In addition, since either may be included (which > > includes the possibility of including both), it is the > > case already that we would then need to decide which is > > to go first - assuming we wanted to do this (which we > > do not). > > > > -- > > Eric > > > > -----Original Message----- > > From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] > > Sent: Monday, March 28, 2011 8:11 AM > > To: Eric Gray; Rolf.Winter@neclab.eu > > Cc: mpls@ietf.org > > Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on- > > demand-cv-03 > > Importance: High > > > > Hi Eric and Rolf, > > > > I'm sorry for interrupting. > > > > I agree with Rolf regarding the per-interface MIP discussion. > > We have to consider the HW implementation aspect, > > because trapping of an OAM packet is HW rule/functionality even in > > routers. > > > > If every OAM packet is trapped to CPU > > and the OAM packets which should NOT be processed in the Interface > > are returned to Data-plane, > > it is different forwarding path from user packets, > > which is NOT the Connectivity Verification of the user path. > > > > Therefore, we should take the HW aspect and flexibilty into account > > concurrently. > > If an address TLV MUST be the first in TLVs, > > it is enough to make HW implementation easy. > > > > BR, > > Hideki > > > > > > > > >Rolf, > > > > > > The words you propose are okay with me. > > > > > > I thought the MIP/interface and address location issues > > >were separate. > > > > > > I've personally had problems with protocol specifications > > >that require ordering of TLVs. In particular, this is not very > > >robust in terms of "future-proofing." What happens if new TLVs > > >are added later on; for instance, suppose at some point we have > > >multiple "address" TLVs? > > > > > > Also, the fact that implementations are allowed to attach > > >TLVs in any arbitrary order allows considerable flexibilty in > > >implementation. Messages can be built in arbitrarily many ways. > > >This too can be a future-proofing issue. > > > > > > I would prefer not to start down the road of requiring a > > >subset of TLVs to appear in a certain order, and saying we have > > >one TLV that needs to be first is doing just that. > > > > > >-- > > >Eric > > > > > >-----Original Message----- > > >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > > >Sent: Monday, March 28, 2011 6:19 AM > > >To: Eric Gray > > >Cc: mpls@ietf.org > > >Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > > demand-cv-03 > > >Importance: High > > > > > >Hi, > > > > > >I still think there is a logical error. Let me explain. In case there > > is no IP you simply cannot use it. You say you could enable IP but then > > that is not a case where there is no IP. In order to be constructive > > here is a text change suggestion: > > > > > >"In certain MPLS-TP deployment scenarios IP addressing might not be > > available. In those cases On-demand CV and/or route tracing MUST be run > > without IP addressing, using the ACH channel type specified in Section > > 3. In other cases it might be available, however, it may be preferred > > to use some form of non-IP encapsulation. In those cases, the > > procedures as outlined in section 3 SHOULD also be used." > > > > > >Regarding the per-interface MIP discussion. The HW aspect also popped > > up in the PWE3 session and I think this is an important consideration, > > in particular for OAM. Even if we talk about TLVs, we could make it a > > MUST that an Address TLV is always the first one to appear. If you can > > facilitate an easy implementation in hardware, I see no reason to > > deliberately not do it. > > > > > >Best, > > > > > >Rolf > > > > > > > > >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > > > > >> -----Original Message----- > > >> From: Eric Gray [mailto:eric.gray@ericsson.com] > > >> Sent: Montag, 28. M=E4rz 2011 11:43 > > >> To: Rolf Winter > > >> Cc: loa@pi.nu; mpls@ietf.org > > >> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > > >> demand-cv-03 > > >> > > >> Rolf, > > >> > > >> With regard to the use of SHOULD (verses MUST) - the intent > > >> (according to RFC 2119 - see the quote below) is consistent with > > >> this case. If - for some reason - one had a really good reason to > > >> use IP addressing in some specific case, one could take steps to > > >> make IP addressing available. > > >> > > >> This could be said to introduce a logical disconnect, but we > > >> are saved from going down that path by the fact that the statement > > >> also includes the case where (for some reason) there is a case in > > >> which some other addressing scheme might be preferred. In many of > > >> the cases where another addressing scheme may be preferred, it is > > >> still possible (in fact likely) that IP addressing is available. > > >> > > >> Otherwise, it would not have been necessary to distinguish > > >> this case from the one in which IP addressing is not available. > > >> > > >> For the case where IP addressing is not the preferred mode, > > >> we are recommending a mode in which it is not necessary. > > >> > > >> With regard to having addresses located in the same place, > > >> this protocol is meant for connectivity testing on an on-demand > > >> basis and is therefore not optimized for processing in hardware. > > >> > > >> Whether addresses or identifiers, if we are talking about > > >> TLV contents, there are issues with trying to guarantee location > > >> of specific content, because of the fact that the TLV in question > > >> will probably follow other TLVs - thus making locations difficult > > >> to predict in any case. > > >> > > >> With regard to needing more text on per-interface MIPs, do > > >> you have specific suggestions as to what text we might add? > > >> > > >> I understand (from discussion with WG chairs) that we are > > >> not allowed to explicitly address last call comments during the > > >> IETF meeting in Prague, because the last call is still ongoing > > >> at that time. > > >> > > >> -- > > >> Eric > > >> > > >> PS - > > >> From RFC 2119 - > > >> 'SHOULD This word, or the adjective "RECOMMENDED", mean that there > > >> may exist valid reasons in particular circumstances to > > >> ignore a particular item, but the full implications must > > >> be understood and carefully weighed before choosing a > > >> different course.' > > >> > > >> -----Original Message----- > > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > >> Rolf Winter > > >> Sent: Tuesday, March 22, 2011 4:57 AM > > >> To: loa@pi.nu; mpls@ietf.org > > >> Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > > >> demand-cv-03 > > >> > > >> Hi, > > >> > > >> some comments below: > > >> > > >> Section 1.3 says: " In certain MPLS-TP deployment scenarios IP > > >> addressing might not be > > >> available or it may be preferred to use some form of non-IP > > >> encapsulation for On-demand CV, route tracing and BFD packets. > > In > > >> such scenarios, On-demand CV and/or route tracing SHOULD be run > > >> without IP addressing..." > > >> > > >> I am not sure the "SHOULD" is right here. If no IP addressing is > > >> available, this thing MUST be run without IP addressing, mustn't it? > > >> > > >> I think some additional text regarding per-interface MIP addressing > > >> would be nice. As far as I understand the document, all TLVs will be > > >> inside the LSP ping packet (rather than as ACH TLVs). > > >> > > >> Some people had concerns earlier, that addressing information should > > be > > >> in a fixed location for easier processing. Is this the case here I > > >> wonder? > > >> > > >> It would be nice if you could address this in your presentation in > > >> Prague. > > >> > > >> Thanks, > > >> > > >> Rolf > > >> > > >> > > >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > >> London W3 6BL | Registered in England 2832014 > > >> > > >> > > >> > -----Original Message----- > > >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf > > >> Of > > >> > loa@pi.nu > > >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26 > > >> > To: mpls@ietf.org > > >> > Cc: MPLS-TP ad hoc team > > >> > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > > >> demand- > > >> > cv-03 > > >> > > > >> > Working Group, > > >> > > > >> > this is to start a 3 week working group last call on > > >> > > > >> > draft-ietf-mpls-tp-on-demand-cv-03 > > >> > > > >> > Please send comments to the working group mailing list > > >> > mpls@ietf.org > > >> > > > >> > The working group last call ends on April 8, 2011. > > >> > > > >> > /Loa > > >> > > > >> > > > >> > > > >> > > > >> > _______________________________________________ > > >> > mpls mailing list > > >> > mpls@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/mpls > > >> _______________________________________________ > > >> mpls mailing list > > >> mpls@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mpls > > >_______________________________________________ > > >mpls mailing list > > >mpls@ietf.org > > >https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Wed Mar 30 09:20:33 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40D53A6B91 for ; Wed, 30 Mar 2011 09:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.725, 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 V4M-SaVqTotU for ; Wed, 30 Mar 2011 09:20:31 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id DEF4C3A6A48 for ; Wed, 30 Mar 2011 09:20:30 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p2UGLsmS012566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Mar 2011 11:22:07 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 30 Mar 2011 12:21:50 -0400 From: Eric Gray To: "hideki.endo.es@hitachi.com" , "Rolf.Winter@neclab.eu" , "mpls@ietf.org" , "Manuel.Paul@telekom.de" Date: Wed, 30 Mar 2011 12:21:48 -0400 Thread-Topic: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-cv-03 Thread-Index: Acvu79PAMUmGllCDQIewfFYsRAZrTwABd21w Message-ID: References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.d> In-Reply-To: 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 Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 16:20:33 -0000 Hideki, If you want to include specific interface information, you can include a DSMAP (or DDMAP) TLV as defined by RFC 4379, and extended by this draft (in combination with the draft "draft-ietf-mpls-lsp-ping-enhanced-dsmap" for DDMAP). Would this not do what you're looking for? -- Eric -----Original Message----- From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] Sent: Wednesday, March 30, 2011 11:33 AM To: Rolf.Winter@neclab.eu; Eric Gray; mpls@ietf.org; Manuel.Paul@telekom.de Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-deman= d-cv-03 Importance: High Hi, I have one comment on IDs in draft-on-demand-cv. The interface-D is missing in the current draft, there is only Node-ID. You need at least the interface ID to support per-interface MIP. BR, Hideki > >Dear All, > >I really appreciate the consideration on the per-interface MIP support and= the discussion moving forward. > > >From an operator's perspective, it is very important that the support for = per-interface MIPs is covered by the definitions. > >Looking at earlier versions of draft-farrel-mpls-tp-mip-mep-map, there was= already a solution proposal, using the TTL. Enhanced solutions have been t= horougly discussed during this IETF meeting. It it to be expected that ther= e will be ways to solve both the fast path and fate-sharing requirement. > > >I second the proposal initially made by Rolf, to include additional text t= o document the per-interface MIP addressing for the on-demand-cv and for ot= her OAM tools. > > >Best regards, >Manuel > > >Deutsche Telekom AG >Group Technology >Manuel Paul >SA3-11 >Goslarer Ufer 35-37, 10589 Berlin >+49 30 3497 - 4394 (Tel.) >+49 30 3497 - 4956 (Fax) >+49 171 8634032 (Mobil) >E-Mail: mailto:manuel.paul@telekom.de >http://www.telekom.com > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Rolf Winter >> Sent: Monday, March 28, 2011 3:03 PM >> To: Eric Gray; hideki.endo.es@hitachi.com >> Cc: mpls@ietf.org >> Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-deman= d- >> cv-03 >> >> Eric, >> >> I generally agree but I think there is one case actually which needs a >> closer look in this regard (which I hinted at earlier), which are the pe= r- >> interface MIPs. Your TTL expires (the actual addressing bit here), the >> identifier tells you it is not intended for the ingress MIP, so it needs >> to be forwarded to the egress MIP through the forwarding engine. Now if >> you pull the packet out of the fast path and inject it back in, is the O= AM >> packet still fate sharing? If you can do this in HW on the line card, th= en >> it will and it will just be forwarded as normal. I know this is a >> different draft, but this will be in particular important for performanc= e >> monitoring. >> >> Best, >> >> Rolf >> >> >> >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lond= on >> W3 6BL | Registered in England 2832014 >> >> >> > -----Original Message----- >> > From: Eric Gray [mailto:eric.gray@ericsson.com] >> > Sent: Montag, 28. M=E4rz 2011 14:45 >> > To: hideki.endo.es@hitachi.com; Rolf Winter >> > Cc: mpls@ietf.org >> > Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp= - >> > on-demand-cv-03 >> > >> > Hideki, >> > >> > What you're saying is true, but not relevant in this >> > case. The "addresses" in this discussion are not used to >> > determine how to forward OAM packets. They are used only >> > by the recipient MIP/MEP to verify that the OAM packet was >> > properly delivered. >> > >> > By the way, this discussion is an indication of the >> > confusing injected by calling these things addresses. My >> > mistake and I bring it up now to help to stem the tide of >> > further comments resulting from that confusion. >> > >> > In the version we post after last call is complete, >> > we will be changing the source and destination "address" >> > TLVs to source and destination "identifier" TLVs. >> > >> > We will also be correcting the reference to DSMAP, >> > and DDMAP, address TLVs (which is incorrect, because the >> > format for DSMAP/DDMAP doesn't include a "length" field). >> > >> > The format of the Downstream Mapping (DSMAP) TLV is >> > defined in RFC 4379, and we are not changing the format >> > of that TLV. >> > >> > These changes are driven by last call comments we >> > have already received (see Joel Halpern's comments on the >> > mailing list) and are - in part - to correct accidental >> > use of the word "address" for source and destination >> > identifier TLVs (which is what we had discussed before >> > I generated the -03 version among the authors of several >> > of the current set of MPLS-TP drafts). >> > >> > In the case of source and destination identifiers, >> > these will be used exclusively to verify that an OAM PDU >> > has been correctly received by its intended recipient. >> > Because this is an on-demand connectivity verification >> > protocol, that is expected to be used only on those >> > occasions when there is a network problem that needs to >> > be diagnosed, and the information is not seen (and not >> > visible - without layer violations), optimizing these >> > objects for software makes sense. >> > >> > In addition, since either may be included (which >> > includes the possibility of including both), it is the >> > case already that we would then need to decide which is >> > to go first - assuming we wanted to do this (which we >> > do not). >> > >> > -- >> > Eric >> > >> > -----Original Message----- >> > From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >> > Sent: Monday, March 28, 2011 8:11 AM >> > To: Eric Gray; Rolf.Winter@neclab.eu >> > Cc: mpls@ietf.org >> > Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on- >> > demand-cv-03 >> > Importance: High >> > >> > Hi Eric and Rolf, >> > >> > I'm sorry for interrupting. >> > >> > I agree with Rolf regarding the per-interface MIP discussion. >> > We have to consider the HW implementation aspect, >> > because trapping of an OAM packet is HW rule/functionality even in >> > routers. >> > >> > If every OAM packet is trapped to CPU >> > and the OAM packets which should NOT be processed in the Interface >> > are returned to Data-plane, >> > it is different forwarding path from user packets, >> > which is NOT the Connectivity Verification of the user path. >> > >> > Therefore, we should take the HW aspect and flexibilty into account >> > concurrently. >> > If an address TLV MUST be the first in TLVs, >> > it is enough to make HW implementation easy. >> > >> > BR, >> > Hideki >> > >> > >> > >> > >Rolf, >> > > >> > > The words you propose are okay with me. >> > > >> > > I thought the MIP/interface and address location issues >> > >were separate. >> > > >> > > I've personally had problems with protocol specifications >> > >that require ordering of TLVs. In particular, this is not very >> > >robust in terms of "future-proofing." What happens if new TLVs >> > >are added later on; for instance, suppose at some point we have >> > >multiple "address" TLVs? >> > > >> > > Also, the fact that implementations are allowed to attach >> > >TLVs in any arbitrary order allows considerable flexibilty in >> > >implementation. Messages can be built in arbitrarily many ways. >> > >This too can be a future-proofing issue. >> > > >> > > I would prefer not to start down the road of requiring a >> > >subset of TLVs to appear in a certain order, and saying we have >> > >one TLV that needs to be first is doing just that. >> > > >> > >-- >> > >Eric >> > > >> > >-----Original Message----- >> > >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >> > >Sent: Monday, March 28, 2011 6:19 AM >> > >To: Eric Gray >> > >Cc: mpls@ietf.org >> > >Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >> > demand-cv-03 >> > >Importance: High >> > > >> > >Hi, >> > > >> > >I still think there is a logical error. Let me explain. In case there >> > is no IP you simply cannot use it. You say you could enable IP but the= n >> > that is not a case where there is no IP. In order to be constructive >> > here is a text change suggestion: >> > > >> > >"In certain MPLS-TP deployment scenarios IP addressing might not be >> > available. In those cases On-demand CV and/or route tracing MUST be ru= n >> > without IP addressing, using the ACH channel type specified in Section >> > 3. In other cases it might be available, however, it may be preferred >> > to use some form of non-IP encapsulation. In those cases, the >> > procedures as outlined in section 3 SHOULD also be used." >> > > >> > >Regarding the per-interface MIP discussion. The HW aspect also popped >> > up in the PWE3 session and I think this is an important consideration, >> > in particular for OAM. Even if we talk about TLVs, we could make it a >> > MUST that an Address TLV is always the first one to appear. If you can >> > facilitate an easy implementation in hardware, I see no reason to >> > deliberately not do it. >> > > >> > >Best, >> > > >> > >Rolf >> > > >> > > >> > >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >> > London W3 6BL | Registered in England 2832014 >> > > >> > > >> > >> -----Original Message----- >> > >> From: Eric Gray [mailto:eric.gray@ericsson.com] >> > >> Sent: Montag, 28. M=E4rz 2011 11:43 >> > >> To: Rolf Winter >> > >> Cc: loa@pi.nu; mpls@ietf.org >> > >> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on= - >> > >> demand-cv-03 >> > >> >> > >> Rolf, >> > >> >> > >> With regard to the use of SHOULD (verses MUST) - the intent >> > >> (according to RFC 2119 - see the quote below) is consistent with >> > >> this case. If - for some reason - one had a really good reason to >> > >> use IP addressing in some specific case, one could take steps to >> > >> make IP addressing available. >> > >> >> > >> This could be said to introduce a logical disconnect, but w= e >> > >> are saved from going down that path by the fact that the statement >> > >> also includes the case where (for some reason) there is a case in >> > >> which some other addressing scheme might be preferred. In many of >> > >> the cases where another addressing scheme may be preferred, it is >> > >> still possible (in fact likely) that IP addressing is available. >> > >> >> > >> Otherwise, it would not have been necessary to distinguish >> > >> this case from the one in which IP addressing is not available. >> > >> >> > >> For the case where IP addressing is not the preferred mode, >> > >> we are recommending a mode in which it is not necessary. >> > >> >> > >> With regard to having addresses located in the same place, >> > >> this protocol is meant for connectivity testing on an on-demand >> > >> basis and is therefore not optimized for processing in hardware. >> > >> >> > >> Whether addresses or identifiers, if we are talking about >> > >> TLV contents, there are issues with trying to guarantee location >> > >> of specific content, because of the fact that the TLV in question >> > >> will probably follow other TLVs - thus making locations difficult >> > >> to predict in any case. >> > >> >> > >> With regard to needing more text on per-interface MIPs, do >> > >> you have specific suggestions as to what text we might add? >> > >> >> > >> I understand (from discussion with WG chairs) that we are >> > >> not allowed to explicitly address last call comments during the >> > >> IETF meeting in Prague, because the last call is still ongoing >> > >> at that time. >> > >> >> > >> -- >> > >> Eric >> > >> >> > >> PS - >> > >> From RFC 2119 - >> > >> 'SHOULD This word, or the adjective "RECOMMENDED", mean that ther= e >> > >> may exist valid reasons in particular circumstances to >> > >> ignore a particular item, but the full implications must >> > >> be understood and carefully weighed before choosing a >> > >> different course.' >> > >> >> > >> -----Original Message----- >> > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behal= f >> > Of >> > >> Rolf Winter >> > >> Sent: Tuesday, March 22, 2011 4:57 AM >> > >> To: loa@pi.nu; mpls@ietf.org >> > >> Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on= - >> > >> demand-cv-03 >> > >> >> > >> Hi, >> > >> >> > >> some comments below: >> > >> >> > >> Section 1.3 says: " In certain MPLS-TP deployment scenarios IP >> > >> addressing might not be >> > >> available or it may be preferred to use some form of non-IP >> > >> encapsulation for On-demand CV, route tracing and BFD packets. >> > In >> > >> such scenarios, On-demand CV and/or route tracing SHOULD be run >> > >> without IP addressing..." >> > >> >> > >> I am not sure the "SHOULD" is right here. If no IP addressing is >> > >> available, this thing MUST be run without IP addressing, mustn't it= ? >> > >> >> > >> I think some additional text regarding per-interface MIP addressing >> > >> would be nice. As far as I understand the document, all TLVs will b= e >> > >> inside the LSP ping packet (rather than as ACH TLVs). >> > >> >> > >> Some people had concerns earlier, that addressing information shoul= d >> > be >> > >> in a fixed location for easier processing. Is this the case here I >> > >> wonder? >> > >> >> > >> It would be nice if you could address this in your presentation in >> > >> Prague. >> > >> >> > >> Thanks, >> > >> >> > >> Rolf >> > >> >> > >> >> > >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >> > >> London W3 6BL | Registered in England 2832014 >> > >> >> > >> >> > >> > -----Original Message----- >> > >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> > Behalf >> > >> Of >> > >> > loa@pi.nu >> > >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26 >> > >> > To: mpls@ietf.org >> > >> > Cc: MPLS-TP ad hoc team >> > >> > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >> > >> demand- >> > >> > cv-03 >> > >> > >> > >> > Working Group, >> > >> > >> > >> > this is to start a 3 week working group last call on >> > >> > >> > >> > draft-ietf-mpls-tp-on-demand-cv-03 >> > >> > >> > >> > Please send comments to the working group mailing list >> > >> > mpls@ietf.org >> > >> > >> > >> > The working group last call ends on April 8, 2011. >> > >> > >> > >> > /Loa >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > >> > mpls mailing list >> > >> > mpls@ietf.org >> > >> > https://www.ietf.org/mailman/listinfo/mpls >> > >> _______________________________________________ >> > >> mpls mailing list >> > >> mpls@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/mpls >> > >_______________________________________________ >> > >mpls mailing list >> > >mpls@ietf.org >> > >https://www.ietf.org/mailman/listinfo/mpls >> > > >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > From venkatflex@gmail.com Wed Mar 30 09:39:07 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E0D3A6B85 for ; Wed, 30 Mar 2011 09:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 0RnnyyYG5jWo for ; Wed, 30 Mar 2011 09:39:06 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 203DA3A6B7C for ; Wed, 30 Mar 2011 09:39:06 -0700 (PDT) Received: by vws12 with SMTP id 12so1348124vws.31 for ; Wed, 30 Mar 2011 09:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=iuT1A/HPwcafMNJcPk3lP765tWEBzjc/DEvTuLLDuBU=; b=exruNpMwxaiTeVH13TmAbWRKQ2fzutWL9b+SEoABs+i1sMycwxUN38R49cGq2RJ5tQ qOqvDvGd3MdsDiCIT+DRyB3rPiz6CgwqOBLcdgEj3H2ii04S/uxzAlDUnxP0/8J6981k Vgvw7lFQA9ZcO6laGrhKBuMpaERVned+VoF1c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rZoxsC2ScYS9jr6AU9pp3VJUxgGTda+pitkZXhs95hX1FNXHGawk73YeABuTeoz7oB UCnxUSpUQjVSfCKgXbmYwA1RSrHUVPHVZirl9beuQvXSCBbFpFJd4AkPKdZDa7W3mUCW 5L2vper0JbZhq1k88wvoaqER3Zmz6k2FRx1/k= MIME-Version: 1.0 Received: by 10.52.70.116 with SMTP id l20mr2090495vdu.13.1301503244798; Wed, 30 Mar 2011 09:40:44 -0700 (PDT) Received: by 10.52.164.230 with HTTP; Wed, 30 Mar 2011 09:40:44 -0700 (PDT) Date: Wed, 30 Mar 2011 12:40:44 -0400 Message-ID: From: venkatesan mahalingam To: mpls Content-Type: multipart/alternative; boundary=20cf307abcff94898f049fb5d631 Subject: [mpls] Regd. MPLS-TP asymmetric bandwidth requirements clarification X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 16:39:07 -0000 --20cf307abcff94898f049fb5d631 Content-Type: text/plain; charset=ISO-8859-1 Hello Authors and all, Per RFC-5654 section 2.1. General Requirements 14 MPLS-TP MUST support bidirectional transport paths with asymmetric bandwidth requirements, i.e., the amount of reserved bandwidth differs between the forward and backward directions. VM>> Is this requirement applicable for both MPLS-TP co-routed and associated bidirectional tunnels? Regards, Venkat. --20cf307abcff94898f049fb5d631 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Authors and all,

Per RFC-5654 section= =A02.1. General Requir= ements
<= pre style=3D"white-space:pre-wrap;font-size:1em;margin-top:0px;margin-botto= m:0px"> 14 MPLS-TP MUST support bidirectional transport paths with asymmetric bandwidth requirements, i.e., the amount of reserved bandwidth differs between the forward and backward directions.=

VM>> Is this requirement applicable for bo= th MPLS-TP co-routed and associated bidirectional tunnels?

Regards,
Venkat.
 --20cf307abcff94898f049fb5d631-- From hideki.endo.es@hitachi.com Wed Mar 30 14:41:53 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A26728C15A for ; Wed, 30 Mar 2011 14:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.429 X-Spam-Level: **** X-Spam-Status: No, score=4.429 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_BASE64_TEXT=1.753, SUBJ_RE_NUM=2.799] 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 6ohyWz00Ec9l for ; Wed, 30 Mar 2011 14:41:51 -0700 (PDT) Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by core3.amsl.com (Postfix) with ESMTP id 524FF3A6BD6 for ; Wed, 30 Mar 2011 14:41:51 -0700 (PDT) Received: from mlsv8.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id 90FE037C82; Thu, 31 Mar 2011 06:43:29 +0900 (JST) Received: from mfilter2.hitachi.co.jp by mlsv8.hitachi.co.jp (8.13.1/8.13.1) id p2ULhTLj001770; Thu, 31 Mar 2011 06:43:29 +0900 Received: from vshuts3.hitachi.co.jp (vshuts3.hitachi.co.jp [10.201.6.72]) by mfilter2.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id p2ULhSkF018569; Thu, 31 Mar 2011 06:43:29 +0900 X-AuditID: b753bd60-9c553ba000007e19-85-4d93a40058f5 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id 546877741ED; Thu, 31 Mar 2011 06:43:28 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p2ULhSx5640254; Thu, 31 Mar 2011 06:43:28 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: multipart/mixed; boundary="GMAILSMTPBOUND01110331064321" To: , From: Date: Thu, 31 Mar 2011 06:43:10 +0900 References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.d> Priority: normal Importance: normal X400-Content-Identifier: X4D93A3DE00000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28110331064254P49] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Manuel.Paul@telekom.de, Rolf.Winter@neclab.eu Subject: Re: [mpls] =?iso-8859-1?q?Working_Group_Las_Callondraft-ietf-mpls-tp-?= =?iso-8859-1?q?on-demand-cv-03?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 21:41:53 -0000 --GMAILSMTPBOUND01110331064321 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 RXJpYywNCg0KSW4gbXkgdW5kZXJzdGFuZGluZywgRFNNQVAgVExWIGlzIG9ubHkgZm9yIHRy YWNlIHJvdXRlLCBpc24ndCBpdD8NCldlIG5lZWQgc3BlY2lmaWMgaW50ZXJmYWNlIGluZm9y bWF0aW9uIGZvciBwaW5nIG1vZGUgb2Ygb24tZGVtYW5kIENWLg0KDQpCUiwNCkhpZGVraQ0K DQo+SGlkZWtpLA0KPg0KPiAgICAgICAgSWYgeW91IHdhbnQgdG8gaW5jbHVkZSBzcGVjaWZp YyBpbnRlcmZhY2UgaW5mb3JtYXRpb24sDQo+eW91IGNhbiBpbmNsdWRlIGEgRFNNQVAgKG9y IERETUFQKSBUTFYgYXMgZGVmaW5lZCBieSBSRkMNCj40Mzc5LCBhbmQgZXh0ZW5kZWQgYnkg dGhpcyBkcmFmdCAoaW4gY29tYmluYXRpb24gd2l0aCB0aGUNCj5kcmFmdCAiZHJhZnQtaWV0 Zi1tcGxzLWxzcC1waW5nLWVuaGFuY2VkLWRzbWFwIiBmb3IgRERNQVApLg0KPg0KPiAgICAg ICAgV291bGQgdGhpcyBub3QgZG8gd2hhdCB5b3UncmUgbG9va2luZyBmb3I/DQo+DQo+LS0N Cj5FcmljDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBoaWRla2ku ZW5kby5lc0BoaXRhY2hpLmNvbSBbbWFpbHRvOmhpZGVraS5lbmRvLmVzQGhpdGFjaGkuY29t XQ0KPlNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMzAsIDIwMTEgMTE6MzMgQU0NCj5UbzogUm9s Zi5XaW50ZXJAbmVjbGFiLmV1OyBFcmljIEdyYXk7IG1wbHNAaWV0Zi5vcmc7IE1hbnVlbC5Q YXVsQHRlbGVrb20uZGUNCj5TdWJqZWN0OiBSZVsyXTogW21wbHNdIFdvcmtpbmcgR3JvdXAg TGFzIENhbGwgb25kcmFmdC1pZXRmLW1wbHMtdHAtb24tZGVtYW5kLWN2LTAzDQo+SW1wb3J0 YW5jZTogSGlnaA0KPg0KPkhpLA0KPg0KPkkgaGF2ZSBvbmUgY29tbWVudCBvbiBJRHMgaW4g ZHJhZnQtb24tZGVtYW5kLWN2Lg0KPlRoZSBpbnRlcmZhY2UtRCBpcyBtaXNzaW5nIGluIHRo ZSBjdXJyZW50IGRyYWZ0LCB0aGVyZSBpcyBvbmx5IE5vZGUtSUQuDQo+WW91IG5lZWQgYXQg bGVhc3QgdGhlIGludGVyZmFjZSBJRCB0byBzdXBwb3J0IHBlci1pbnRlcmZhY2UgTUlQLg0K Pg0KPkJSLA0KPkhpZGVraQ0KPg0KPj4NCj4+RGVhciBBbGwsDQo+Pg0KPj5JIHJlYWxseSBh cHByZWNpYXRlIHRoZSBjb25zaWRlcmF0aW9uIG9uIHRoZSBwZXItaW50ZXJmYWNlIE1JUCBz dXBwb3J0IGFuZCB0aGUgZGlzY3Vzc2lvbiBtb3ZpbmcgZm9yd2FyZC4NCj4+DQo+Pg0KPj5G cm9tIGFuIG9wZXJhdG9yJ3MgcGVyc3BlY3RpdmUsIGl0IGlzIHZlcnkgaW1wb3J0YW50IHRo YXQgdGhlIHN1cHBvcnQgZm9yIHBlci1pbnRlcmZhY2UgTUlQcyBpcyBjb3ZlcmVkIGJ5IHRo ZSBkZWZpbml0aW9ucy4NCj4+DQo+Pkxvb2tpbmcgYXQgZWFybGllciB2ZXJzaW9ucyBvZiBk cmFmdC1mYXJyZWwtbXBscy10cC1taXAtbWVwLW1hcCwgdGhlcmUgd2FzIGFscmVhZHkgYSBz b2x1dGlvbiBwcm9wb3NhbCwgdXNpbmcgdGhlIFRUTC4gRW5oYW5jZWQgc29sdXRpb25zIGhh dmUgYmVlbiB0aG9yb3VnbHkgZGlzY3Vzc2VkIGR1cmluZyB0aGlzIElFVEYgbWVldGluZy4g SXQgaXQgdG8gYmUgZXhwZWN0ZWQgdGhhdCB0aGVyZSB3aWxsIGJlIHdheXMgdG8gc29sdmUg Ym90aCB0aGUgZmFzdCBwYXRoIGFuZCBmYXRlLXNoYXJpbmcgcmVxdWlyZW1lbnQuDQo+Pg0K Pj4NCj4+SSBzZWNvbmQgdGhlIHByb3Bvc2FsIGluaXRpYWxseSBtYWRlIGJ5IFJvbGYsIHRv IGluY2x1ZGUgYWRkaXRpb25hbCB0ZXh0IHRvIGRvY3VtZW50IHRoZSBwZXItaW50ZXJmYWNl IE1JUCBhZGRyZXNzaW5nIGZvciB0aGUgb24tZGVtYW5kLWN2IGFuZCBmb3Igb3RoZXIgT0FN IHRvb2xzLg0KPj4NCj4+DQo+PkJlc3QgcmVnYXJkcywNCj4+TWFudWVsDQo+Pg0KPj4NCj4+ RGV1dHNjaGUgVGVsZWtvbSBBRw0KPj5Hcm91cCBUZWNobm9sb2d5DQo+Pk1hbnVlbCBQYXVs DQo+PlNBMy0xMQ0KPj5Hb3NsYXJlciBVZmVyIDM1LTM3LCAxMDU4OSBCZXJsaW4NCj4+KzQ5 IDMwIDM0OTcgLSA0Mzk0IChUZWwuKQ0KPj4rNDkgMzAgMzQ5NyAtIDQ5NTYgKEZheCkNCj4+ KzQ5IDE3MSAgODYzNDAzMiAoTW9iaWwpDQo+PkUtTWFpbDogbWFpbHRvOm1hbnVlbC5wYXVs QHRlbGVrb20uZGUNCj4+aHR0cDovL3d3dy50ZWxla29tLmNvbQ0KPj4NCj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+Pj4gUm9sZiBX aW50ZXINCj4+PiBTZW50OiBNb25kYXksIE1hcmNoIDI4LCAyMDExIDM6MDMgUE0NCj4+PiBU bzogRXJpYyBHcmF5OyBoaWRla2kuZW5kby5lc0BoaXRhY2hpLmNvbQ0KPj4+IENjOiBtcGxz QGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBD YWxsIG9uZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLWRlbWFuZC0NCj4+PiBjdi0wMw0KPj4+DQo+ Pj4gRXJpYywNCj4+Pg0KPj4+IEkgZ2VuZXJhbGx5IGFncmVlIGJ1dCBJIHRoaW5rIHRoZXJl IGlzIG9uZSBjYXNlIGFjdHVhbGx5IHdoaWNoIG5lZWRzIGENCj4+PiBjbG9zZXIgbG9vayBp biB0aGlzIHJlZ2FyZCAod2hpY2ggSSBoaW50ZWQgYXQgZWFybGllciksIHdoaWNoIGFyZSB0 aGUgcGVyLQ0KPj4+IGludGVyZmFjZSBNSVBzLiBZb3VyIFRUTCBleHBpcmVzICh0aGUgYWN0 dWFsIGFkZHJlc3NpbmcgYml0IGhlcmUpLCB0aGUNCj4+PiBpZGVudGlmaWVyIHRlbGxzIHlv dSBpdCBpcyBub3QgaW50ZW5kZWQgZm9yIHRoZSBpbmdyZXNzIE1JUCwgc28gaXQgbmVlZHMN Cj4+PiB0byBiZSBmb3J3YXJkZWQgdG8gdGhlIGVncmVzcyBNSVAgdGhyb3VnaCB0aGUgZm9y d2FyZGluZyBlbmdpbmUuIE5vdyBpZg0KPj4+IHlvdSBwdWxsIHRoZSBwYWNrZXQgb3V0IG9m IHRoZSBmYXN0IHBhdGggYW5kIGluamVjdCBpdCBiYWNrIGluLCBpcyB0aGUgT0FNDQo+Pj4g cGFja2V0IHN0aWxsIGZhdGUgc2hhcmluZz8gSWYgeW91IGNhbiBkbyB0aGlzIGluIEhXIG9u IHRoZSBsaW5lIGNhcmQsIHRoZW4NCj4+PiBpdCB3aWxsIGFuZCBpdCB3aWxsIGp1c3QgYmUg Zm9yd2FyZGVkIGFzIG5vcm1hbC4gSSBrbm93IHRoaXMgaXMgYQ0KPj4+IGRpZmZlcmVudCBk cmFmdCwgYnV0IHRoaXMgd2lsbCBiZSBpbiBwYXJ0aWN1bGFyIGltcG9ydGFudCBmb3IgcGVy Zm9ybWFuY2UNCj4+PiBtb25pdG9yaW5nLg0KPj4+DQo+Pj4gQmVzdCwNCj4+Pg0KPj4+IFJv bGYNCj4+Pg0KPj4+DQo+Pj4NCj4+PiBORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVk IE9mZmljZTogTkVDIEhvdXNlLCAxIFZpY3RvcmlhIFJvYWQsIExvbmRvbg0KPj4+IFczIDZC TCB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODMyMDE0DQo+Pj4NCj4+Pg0KPj4+ID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiA+IEZyb206IEVyaWMgR3JheSBbbWFpbHRv OmVyaWMuZ3JheUBlcmljc3Nvbi5jb21dDQo+Pj4gPiBTZW50OiBNb250YWcsIDI4LiBN5HJ6 IDIwMTEgMTQ6NDUNCj4+PiA+IFRvOiBoaWRla2kuZW5kby5lc0BoaXRhY2hpLmNvbTsgUm9s ZiBXaW50ZXINCj4+PiA+IENjOiBtcGxzQGlldGYub3JnDQo+Pj4gPiBTdWJqZWN0OiBSRTog UmVbMl06IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9uZHJhZnQtaWV0Zi1tcGxz LXRwLQ0KPj4+ID4gb24tZGVtYW5kLWN2LTAzDQo+Pj4gPg0KPj4+ID4gSGlkZWtpLA0KPj4+ ID4NCj4+PiA+ICAgIFdoYXQgeW91J3JlIHNheWluZyBpcyB0cnVlLCBidXQgbm90IHJlbGV2 YW50IGluIHRoaXMNCj4+PiA+IGNhc2UuICBUaGUgImFkZHJlc3NlcyIgaW4gdGhpcyBkaXNj dXNzaW9uIGFyZSBub3QgdXNlZCB0bw0KPj4+ID4gZGV0ZXJtaW5lIGhvdyB0byBmb3J3YXJk IE9BTSBwYWNrZXRzLiAgVGhleSBhcmUgdXNlZCBvbmx5DQo+Pj4gPiBieSB0aGUgcmVjaXBp ZW50IE1JUC9NRVAgdG8gdmVyaWZ5IHRoYXQgdGhlIE9BTSBwYWNrZXQgd2FzDQo+Pj4gPiBw cm9wZXJseSBkZWxpdmVyZWQuDQo+Pj4gPg0KPj4+ID4gICAgQnkgdGhlIHdheSwgdGhpcyBk aXNjdXNzaW9uIGlzIGFuIGluZGljYXRpb24gb2YgdGhlDQo+Pj4gPiBjb25mdXNpbmcgaW5q ZWN0ZWQgYnkgY2FsbGluZyB0aGVzZSB0aGluZ3MgYWRkcmVzc2VzLiAgTXkNCj4+PiA+IG1p c3Rha2UgYW5kIEkgYnJpbmcgaXQgdXAgbm93IHRvIGhlbHAgdG8gc3RlbSB0aGUgdGlkZSBv Zg0KPj4+ID4gZnVydGhlciBjb21tZW50cyByZXN1bHRpbmcgZnJvbSB0aGF0IGNvbmZ1c2lv bi4NCj4+PiA+DQo+Pj4gPiAgICBJbiB0aGUgdmVyc2lvbiB3ZSBwb3N0IGFmdGVyIGxhc3Qg Y2FsbCBpcyBjb21wbGV0ZSwNCj4+PiA+IHdlIHdpbGwgYmUgY2hhbmdpbmcgdGhlIHNvdXJj ZSBhbmQgZGVzdGluYXRpb24gImFkZHJlc3MiDQo+Pj4gPiBUTFZzIHRvIHNvdXJjZSBhbmQg ZGVzdGluYXRpb24gImlkZW50aWZpZXIiIFRMVnMuDQo+Pj4gPg0KPj4+ID4gICAgV2Ugd2ls bCBhbHNvIGJlIGNvcnJlY3RpbmcgdGhlIHJlZmVyZW5jZSB0byBEU01BUCwNCj4+PiA+IGFu ZCBERE1BUCwgYWRkcmVzcyBUTFZzICh3aGljaCBpcyBpbmNvcnJlY3QsIGJlY2F1c2UgdGhl DQo+Pj4gPiBmb3JtYXQgZm9yIERTTUFQL0RETUFQIGRvZXNuJ3QgaW5jbHVkZSBhICJsZW5n dGgiIGZpZWxkKS4NCj4+PiA+DQo+Pj4gPiAgICBUaGUgZm9ybWF0IG9mIHRoZSBEb3duc3Ry ZWFtIE1hcHBpbmcgKERTTUFQKSBUTFYgaXMNCj4+PiA+IGRlZmluZWQgaW4gUkZDIDQzNzks IGFuZCB3ZSBhcmUgbm90IGNoYW5naW5nIHRoZSBmb3JtYXQNCj4+PiA+IG9mIHRoYXQgVExW Lg0KPj4+ID4NCj4+PiA+ICAgIFRoZXNlIGNoYW5nZXMgYXJlIGRyaXZlbiBieSBsYXN0IGNh bGwgY29tbWVudHMgd2UNCj4+PiA+IGhhdmUgYWxyZWFkeSByZWNlaXZlZCAoc2VlIEpvZWwg SGFscGVybidzIGNvbW1lbnRzIG9uIHRoZQ0KPj4+ID4gbWFpbGluZyBsaXN0KSBhbmQgYXJl IC0gaW4gcGFydCAtIHRvIGNvcnJlY3QgYWNjaWRlbnRhbA0KPj4+ID4gdXNlIG9mIHRoZSB3 b3JkICJhZGRyZXNzIiBmb3Igc291cmNlIGFuZCBkZXN0aW5hdGlvbg0KPj4+ID4gaWRlbnRp ZmllciBUTFZzICh3aGljaCBpcyB3aGF0IHdlIGhhZCBkaXNjdXNzZWQgYmVmb3JlDQo+Pj4g PiBJIGdlbmVyYXRlZCB0aGUgLTAzIHZlcnNpb24gYW1vbmcgdGhlIGF1dGhvcnMgb2Ygc2V2 ZXJhbA0KPj4+ID4gb2YgdGhlIGN1cnJlbnQgc2V0IG9mIE1QTFMtVFAgZHJhZnRzKS4NCj4+ PiA+DQo+Pj4gPiAgICBJbiB0aGUgY2FzZSBvZiBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIGlk ZW50aWZpZXJzLA0KPj4+ID4gdGhlc2Ugd2lsbCBiZSB1c2VkIGV4Y2x1c2l2ZWx5IHRvIHZl cmlmeSB0aGF0IGFuIE9BTSBQRFUNCj4+PiA+IGhhcyBiZWVuIGNvcnJlY3RseSByZWNlaXZl ZCBieSBpdHMgaW50ZW5kZWQgcmVjaXBpZW50Lg0KPj4+ID4gQmVjYXVzZSB0aGlzIGlzIGFu IG9uLWRlbWFuZCBjb25uZWN0aXZpdHkgdmVyaWZpY2F0aW9uDQo+Pj4gPiBwcm90b2NvbCwg dGhhdCBpcyBleHBlY3RlZCB0byBiZSB1c2VkIG9ubHkgb24gdGhvc2UNCj4+PiA+IG9jY2Fz aW9ucyB3aGVuIHRoZXJlIGlzIGEgbmV0d29yayBwcm9ibGVtIHRoYXQgbmVlZHMgdG8NCj4+ PiA+IGJlIGRpYWdub3NlZCwgYW5kIHRoZSBpbmZvcm1hdGlvbiBpcyBub3Qgc2VlbiAoYW5k IG5vdA0KPj4+ID4gdmlzaWJsZSAtIHdpdGhvdXQgbGF5ZXIgdmlvbGF0aW9ucyksIG9wdGlt aXppbmcgdGhlc2UNCj4+PiA+IG9iamVjdHMgZm9yIHNvZnR3YXJlIG1ha2VzIHNlbnNlLg0K Pj4+ID4NCj4+PiA+ICAgIEluIGFkZGl0aW9uLCBzaW5jZSBlaXRoZXIgbWF5IGJlIGluY2x1 ZGVkICh3aGljaA0KPj4+ID4gaW5jbHVkZXMgdGhlIHBvc3NpYmlsaXR5IG9mIGluY2x1ZGlu ZyBib3RoKSwgaXQgaXMgdGhlDQo+Pj4gPiBjYXNlIGFscmVhZHkgdGhhdCB3ZSB3b3VsZCB0 aGVuIG5lZWQgdG8gZGVjaWRlIHdoaWNoIGlzDQo+Pj4gPiB0byBnbyBmaXJzdCAtIGFzc3Vt aW5nIHdlIHdhbnRlZCB0byBkbyB0aGlzICh3aGljaCB3ZQ0KPj4+ID4gZG8gbm90KS4NCj4+ PiA+DQo+Pj4gPiAtLQ0KPj4+ID4gRXJpYw0KPj4+ID4NCj4+PiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj4gPiBGcm9tOiBoaWRla2kuZW5kby5lc0BoaXRhY2hpLmNvbSBb bWFpbHRvOmhpZGVraS5lbmRvLmVzQGhpdGFjaGkuY29tXQ0KPj4+ID4gU2VudDogTW9uZGF5 LCBNYXJjaCAyOCwgMjAxMSA4OjExIEFNDQo+Pj4gPiBUbzogRXJpYyBHcmF5OyBSb2xmLldp bnRlckBuZWNsYWIuZXUNCj4+PiA+IENjOiBtcGxzQGlldGYub3JnDQo+Pj4gPiBTdWJqZWN0 OiBSZVsyXTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENhbGwgb25kcmFmdC1pZXRmLW1w bHMtdHAtb24tDQo+Pj4gPiBkZW1hbmQtY3YtMDMNCj4+PiA+IEltcG9ydGFuY2U6IEhpZ2gN Cj4+PiA+DQo+Pj4gPiBIaSBFcmljIGFuZCBSb2xmLA0KPj4+ID4NCj4+PiA+IEknbSBzb3Jy eSBmb3IgaW50ZXJydXB0aW5nLg0KPj4+ID4NCj4+PiA+IEkgYWdyZWUgd2l0aCBSb2xmIHJl Z2FyZGluZyB0aGUgcGVyLWludGVyZmFjZSBNSVAgZGlzY3Vzc2lvbi4NCj4+PiA+IFdlIGhh dmUgdG8gY29uc2lkZXIgdGhlIEhXIGltcGxlbWVudGF0aW9uIGFzcGVjdCwNCj4+PiA+IGJl Y2F1c2UgdHJhcHBpbmcgb2YgYW4gT0FNIHBhY2tldCBpcyBIVyBydWxlL2Z1bmN0aW9uYWxp dHkgZXZlbiBpbg0KPj4+ID4gcm91dGVycy4NCj4+PiA+DQo+Pj4gPiBJZiBldmVyeSBPQU0g cGFja2V0IGlzIHRyYXBwZWQgdG8gQ1BVDQo+Pj4gPiBhbmQgdGhlIE9BTSBwYWNrZXRzIHdo aWNoIHNob3VsZCBOT1QgYmUgcHJvY2Vzc2VkIGluIHRoZSBJbnRlcmZhY2UNCj4+PiA+IGFy ZSByZXR1cm5lZCB0byBEYXRhLXBsYW5lLA0KPj4+ID4gaXQgaXMgZGlmZmVyZW50IGZvcndh cmRpbmcgcGF0aCBmcm9tIHVzZXIgcGFja2V0cywNCj4+PiA+IHdoaWNoIGlzIE5PVCB0aGUg Q29ubmVjdGl2aXR5IFZlcmlmaWNhdGlvbiBvZiB0aGUgdXNlciBwYXRoLg0KPj4+ID4NCj4+ PiA+IFRoZXJlZm9yZSwgd2Ugc2hvdWxkIHRha2UgdGhlIEhXIGFzcGVjdCBhbmQgZmxleGli aWx0eSBpbnRvIGFjY291bnQNCj4+PiA+IGNvbmN1cnJlbnRseS4NCj4+PiA+IElmIGFuIGFk ZHJlc3MgVExWIE1VU1QgYmUgdGhlIGZpcnN0IGluIFRMVnMsDQo+Pj4gPiBpdCBpcyBlbm91 Z2ggdG8gbWFrZSBIVyBpbXBsZW1lbnRhdGlvbiBlYXN5Lg0KPj4+ID4NCj4+PiA+IEJSLA0K Pj4+ID4gSGlkZWtpDQo+Pj4gPg0KPj4+ID4NCj4+PiA+DQo+Pj4gPiA+Um9sZiwNCj4+PiA+ ID4NCj4+PiA+ID4gIFRoZSB3b3JkcyB5b3UgcHJvcG9zZSBhcmUgb2theSB3aXRoIG1lLg0K Pj4+ID4gPg0KPj4+ID4gPiAgSSB0aG91Z2h0IHRoZSBNSVAvaW50ZXJmYWNlIGFuZCBhZGRy ZXNzIGxvY2F0aW9uIGlzc3Vlcw0KPj4+ID4gPndlcmUgc2VwYXJhdGUuDQo+Pj4gPiA+DQo+ Pj4gPiA+ICBJJ3ZlIHBlcnNvbmFsbHkgaGFkIHByb2JsZW1zIHdpdGggcHJvdG9jb2wgc3Bl Y2lmaWNhdGlvbnMNCj4+PiA+ID50aGF0IHJlcXVpcmUgb3JkZXJpbmcgb2YgVExWcy4gIElu IHBhcnRpY3VsYXIsIHRoaXMgaXMgbm90IHZlcnkNCj4+PiA+ID5yb2J1c3QgaW4gdGVybXMg b2YgImZ1dHVyZS1wcm9vZmluZy4iICBXaGF0IGhhcHBlbnMgaWYgbmV3IFRMVnMNCj4+PiA+ ID5hcmUgYWRkZWQgbGF0ZXIgb247IGZvciBpbnN0YW5jZSwgc3VwcG9zZSBhdCBzb21lIHBv aW50IHdlIGhhdmUNCj4+PiA+ID5tdWx0aXBsZSAiYWRkcmVzcyIgVExWcz8NCj4+PiA+ID4N Cj4+PiA+ID4gIEFsc28sIHRoZSBmYWN0IHRoYXQgaW1wbGVtZW50YXRpb25zIGFyZSBhbGxv d2VkIHRvIGF0dGFjaA0KPj4+ID4gPlRMVnMgaW4gYW55IGFyYml0cmFyeSBvcmRlciBhbGxv d3MgY29uc2lkZXJhYmxlIGZsZXhpYmlsdHkgaW4NCj4+PiA+ID5pbXBsZW1lbnRhdGlvbi4g IE1lc3NhZ2VzIGNhbiBiZSBidWlsdCBpbiBhcmJpdHJhcmlseSBtYW55IHdheXMuDQo+Pj4g PiA+VGhpcyB0b28gY2FuIGJlIGEgZnV0dXJlLXByb29maW5nIGlzc3VlLg0KPj4+ID4gPg0K Pj4+ID4gPiAgSSB3b3VsZCBwcmVmZXIgbm90IHRvIHN0YXJ0IGRvd24gdGhlIHJvYWQgb2Yg cmVxdWlyaW5nIGENCj4+PiA+ID5zdWJzZXQgb2YgVExWcyB0byBhcHBlYXIgaW4gYSBjZXJ0 YWluIG9yZGVyLCBhbmQgc2F5aW5nIHdlIGhhdmUNCj4+PiA+ID5vbmUgVExWIHRoYXQgbmVl ZHMgdG8gYmUgZmlyc3QgaXMgZG9pbmcganVzdCB0aGF0Lg0KPj4+ID4gPg0KPj4+ID4gPi0t DQo+Pj4gPiA+RXJpYw0KPj4+ID4gPg0KPj4+ID4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4gPiA+RnJvbTogUm9sZiBXaW50ZXIgW21haWx0bzpSb2xmLldpbnRlckBuZWNs YWIuZXVdDQo+Pj4gPiA+U2VudDogTW9uZGF5LCBNYXJjaCAyOCwgMjAxMSA2OjE5IEFNDQo+ Pj4gPiA+VG86IEVyaWMgR3JheQ0KPj4+ID4gPkNjOiBtcGxzQGlldGYub3JnDQo+Pj4gPiA+ U3ViamVjdDogUkU6IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9uIGRyYWZ0LWll dGYtbXBscy10cC1vbi0NCj4+PiA+IGRlbWFuZC1jdi0wMw0KPj4+ID4gPkltcG9ydGFuY2U6 IEhpZ2gNCj4+PiA+ID4NCj4+PiA+ID5IaSwNCj4+PiA+ID4NCj4+PiA+ID5JIHN0aWxsIHRo aW5rIHRoZXJlIGlzIGEgbG9naWNhbCBlcnJvci4gTGV0IG1lIGV4cGxhaW4uIEluIGNhc2Ug dGhlcmUNCj4+PiA+IGlzIG5vIElQIHlvdSBzaW1wbHkgY2Fubm90IHVzZSBpdC4gWW91IHNh eSB5b3UgY291bGQgZW5hYmxlIElQIGJ1dCB0aGVuDQo+Pj4gPiB0aGF0IGlzIG5vdCBhIGNh c2Ugd2hlcmUgdGhlcmUgaXMgbm8gSVAuIEluIG9yZGVyIHRvIGJlIGNvbnN0cnVjdGl2ZQ0K Pj4+ID4gaGVyZSBpcyBhIHRleHQgY2hhbmdlIHN1Z2dlc3Rpb246DQo+Pj4gPiA+DQo+Pj4g PiA+IkluIGNlcnRhaW4gTVBMUy1UUCBkZXBsb3ltZW50IHNjZW5hcmlvcyBJUCBhZGRyZXNz aW5nIG1pZ2h0IG5vdCBiZQ0KPj4+ID4gYXZhaWxhYmxlLiBJbiB0aG9zZSBjYXNlcyBPbi1k ZW1hbmQgQ1YgYW5kL29yIHJvdXRlIHRyYWNpbmcgTVVTVCBiZSBydW4NCj4+PiA+IHdpdGhv dXQgSVAgYWRkcmVzc2luZywgdXNpbmcgdGhlIEFDSCBjaGFubmVsIHR5cGUgc3BlY2lmaWVk IGluIFNlY3Rpb24NCj4+PiA+IDMuIEluIG90aGVyIGNhc2VzIGl0IG1pZ2h0IGJlIGF2YWls YWJsZSwgaG93ZXZlciwgaXQgbWF5IGJlIHByZWZlcnJlZA0KPj4+ID4gdG8gdXNlIHNvbWUg Zm9ybSBvZiBub24tSVAgZW5jYXBzdWxhdGlvbi4gSW4gdGhvc2UgY2FzZXMsIHRoZQ0KPj4+ ID4gcHJvY2VkdXJlcyBhcyBvdXRsaW5lZCBpbiBzZWN0aW9uIDMgU0hPVUxEIGFsc28gYmUg dXNlZC4iDQo+Pj4gPiA+DQo+Pj4gPiA+UmVnYXJkaW5nIHRoZSBwZXItaW50ZXJmYWNlIE1J UCBkaXNjdXNzaW9uLiBUaGUgSFcgYXNwZWN0IGFsc28gcG9wcGVkDQo+Pj4gPiB1cCBpbiB0 aGUgUFdFMyBzZXNzaW9uIGFuZCBJIHRoaW5rIHRoaXMgaXMgYW4gaW1wb3J0YW50IGNvbnNp ZGVyYXRpb24sDQo+Pj4gPiBpbiBwYXJ0aWN1bGFyIGZvciBPQU0uIEV2ZW4gaWYgd2UgdGFs ayBhYm91dCBUTFZzLCB3ZSBjb3VsZCBtYWtlIGl0IGENCj4+PiA+IE1VU1QgdGhhdCBhbiBB ZGRyZXNzIFRMViBpcyBhbHdheXMgdGhlIGZpcnN0IG9uZSB0byBhcHBlYXIuIElmIHlvdSBj YW4NCj4+PiA+IGZhY2lsaXRhdGUgYW4gZWFzeSBpbXBsZW1lbnRhdGlvbiBpbiBoYXJkd2Fy ZSwgSSBzZWUgbm8gcmVhc29uIHRvDQo+Pj4gPiBkZWxpYmVyYXRlbHkgbm90IGRvIGl0Lg0K Pj4+ID4gPg0KPj4+ID4gPkJlc3QsDQo+Pj4gPiA+DQo+Pj4gPiA+Um9sZg0KPj4+ID4gPg0K Pj4+ID4gPg0KPj4+ID4gPk5FQyBFdXJvcGUgTGltaXRlZCB8IFJlZ2lzdGVyZWQgT2ZmaWNl OiBORUMgSG91c2UsIDEgVmljdG9yaWEgUm9hZCwNCj4+PiA+IExvbmRvbiBXMyA2QkwgfCBS ZWdpc3RlcmVkIGluIEVuZ2xhbmQgMjgzMjAxNA0KPj4+ID4gPg0KPj4+ID4gPg0KPj4+ID4g Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiA+ID4+IEZyb206IEVyaWMgR3Jh eSBbbWFpbHRvOmVyaWMuZ3JheUBlcmljc3Nvbi5jb21dDQo+Pj4gPiA+PiBTZW50OiBNb250 YWcsIDI4LiBN5HJ6IDIwMTEgMTE6NDMNCj4+PiA+ID4+IFRvOiBSb2xmIFdpbnRlcg0KPj4+ ID4gPj4gQ2M6IGxvYUBwaS5udTsgbXBsc0BpZXRmLm9yZw0KPj4+ID4gPj4gU3ViamVjdDog UkU6IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10 cC1vbi0NCj4+PiA+ID4+IGRlbWFuZC1jdi0wMw0KPj4+ID4gPj4NCj4+PiA+ID4+IFJvbGYs DQo+Pj4gPiA+Pg0KPj4+ID4gPj4gICAgICAgICBXaXRoIHJlZ2FyZCB0byB0aGUgdXNlIG9m IFNIT1VMRCAodmVyc2VzIE1VU1QpIC0gdGhlIGludGVudA0KPj4+ID4gPj4gKGFjY29yZGlu ZyB0byBSRkMgMjExOSAtIHNlZSB0aGUgcXVvdGUgYmVsb3cpIGlzIGNvbnNpc3RlbnQgd2l0 aA0KPj4+ID4gPj4gdGhpcyBjYXNlLiAgSWYgLSBmb3Igc29tZSByZWFzb24gLSBvbmUgaGFk IGEgcmVhbGx5IGdvb2QgcmVhc29uIHRvDQo+Pj4gPiA+PiB1c2UgSVAgYWRkcmVzc2luZyBp biBzb21lIHNwZWNpZmljIGNhc2UsIG9uZSBjb3VsZCB0YWtlIHN0ZXBzIHRvDQo+Pj4gPiA+ PiBtYWtlIElQIGFkZHJlc3NpbmcgYXZhaWxhYmxlLg0KPj4+ID4gPj4NCj4+PiA+ID4+ICAg ICAgICAgVGhpcyBjb3VsZCBiZSBzYWlkIHRvIGludHJvZHVjZSBhIGxvZ2ljYWwgZGlzY29u bmVjdCwgYnV0IHdlDQo+Pj4gPiA+PiBhcmUgc2F2ZWQgZnJvbSBnb2luZyBkb3duIHRoYXQg cGF0aCBieSB0aGUgZmFjdCB0aGF0IHRoZSBzdGF0ZW1lbnQNCj4+PiA+ID4+IGFsc28gaW5j bHVkZXMgdGhlIGNhc2Ugd2hlcmUgKGZvciBzb21lIHJlYXNvbikgdGhlcmUgaXMgYSBjYXNl IGluDQo+Pj4gPiA+PiB3aGljaCBzb21lIG90aGVyIGFkZHJlc3Npbmcgc2NoZW1lIG1pZ2h0 IGJlIHByZWZlcnJlZC4gIEluIG1hbnkgb2YNCj4+PiA+ID4+IHRoZSBjYXNlcyB3aGVyZSBh bm90aGVyIGFkZHJlc3Npbmcgc2NoZW1lIG1heSBiZSBwcmVmZXJyZWQsIGl0IGlzDQo+Pj4g PiA+PiBzdGlsbCBwb3NzaWJsZSAoaW4gZmFjdCBsaWtlbHkpIHRoYXQgSVAgYWRkcmVzc2lu ZyBpcyBhdmFpbGFibGUuDQo+Pj4gPiA+Pg0KPj4+ID4gPj4gICAgICAgICBPdGhlcndpc2Us IGl0IHdvdWxkIG5vdCBoYXZlIGJlZW4gbmVjZXNzYXJ5IHRvIGRpc3Rpbmd1aXNoDQo+Pj4g PiA+PiB0aGlzIGNhc2UgZnJvbSB0aGUgb25lIGluIHdoaWNoIElQIGFkZHJlc3NpbmcgaXMg bm90IGF2YWlsYWJsZS4NCj4+PiA+ID4+DQo+Pj4gPiA+PiAgICAgICAgIEZvciB0aGUgY2Fz ZSB3aGVyZSBJUCBhZGRyZXNzaW5nIGlzIG5vdCB0aGUgcHJlZmVycmVkIG1vZGUsDQo+Pj4g PiA+PiB3ZSBhcmUgcmVjb21tZW5kaW5nIGEgbW9kZSBpbiB3aGljaCBpdCBpcyBub3QgbmVj ZXNzYXJ5Lg0KPj4+ID4gPj4NCj4+PiA+ID4+ICAgICAgICAgV2l0aCByZWdhcmQgdG8gaGF2 aW5nIGFkZHJlc3NlcyBsb2NhdGVkIGluIHRoZSBzYW1lIHBsYWNlLA0KPj4+ID4gPj4gdGhp cyBwcm90b2NvbCBpcyBtZWFudCBmb3IgY29ubmVjdGl2aXR5IHRlc3Rpbmcgb24gYW4gb24t ZGVtYW5kDQo+Pj4gPiA+PiBiYXNpcyBhbmQgaXMgdGhlcmVmb3JlIG5vdCBvcHRpbWl6ZWQg Zm9yIHByb2Nlc3NpbmcgaW4gaGFyZHdhcmUuDQo+Pj4gPiA+Pg0KPj4+ID4gPj4gICAgICAg ICBXaGV0aGVyIGFkZHJlc3NlcyBvciBpZGVudGlmaWVycywgaWYgd2UgYXJlIHRhbGtpbmcg YWJvdXQNCj4+PiA+ID4+IFRMViBjb250ZW50cywgdGhlcmUgYXJlIGlzc3VlcyB3aXRoIHRy eWluZyB0byBndWFyYW50ZWUgbG9jYXRpb24NCj4+PiA+ID4+IG9mIHNwZWNpZmljIGNvbnRl bnQsIGJlY2F1c2Ugb2YgdGhlIGZhY3QgdGhhdCB0aGUgVExWIGluIHF1ZXN0aW9uDQo+Pj4g PiA+PiB3aWxsIHByb2JhYmx5IGZvbGxvdyBvdGhlciBUTFZzIC0gdGh1cyBtYWtpbmcgbG9j YXRpb25zIGRpZmZpY3VsdA0KPj4+ID4gPj4gdG8gcHJlZGljdCBpbiBhbnkgY2FzZS4NCj4+ PiA+ID4+DQo+Pj4gPiA+PiAgICAgICAgIFdpdGggcmVnYXJkIHRvIG5lZWRpbmcgbW9yZSB0 ZXh0IG9uIHBlci1pbnRlcmZhY2UgTUlQcywgZG8NCj4+PiA+ID4+IHlvdSBoYXZlIHNwZWNp ZmljIHN1Z2dlc3Rpb25zIGFzIHRvIHdoYXQgdGV4dCB3ZSBtaWdodCBhZGQ/DQo+Pj4gPiA+ Pg0KPj4+ID4gPj4gICAgICAgICBJIHVuZGVyc3RhbmQgKGZyb20gZGlzY3Vzc2lvbiB3aXRo IFdHIGNoYWlycykgdGhhdCB3ZSBhcmUNCj4+PiA+ID4+IG5vdCBhbGxvd2VkIHRvIGV4cGxp Y2l0bHkgYWRkcmVzcyBsYXN0IGNhbGwgY29tbWVudHMgZHVyaW5nIHRoZQ0KPj4+ID4gPj4g SUVURiBtZWV0aW5nIGluIFByYWd1ZSwgYmVjYXVzZSB0aGUgbGFzdCBjYWxsIGlzIHN0aWxs IG9uZ29pbmcNCj4+PiA+ID4+IGF0IHRoYXQgdGltZS4NCj4+PiA+ID4+DQo+Pj4gPiA+PiAt LQ0KPj4+ID4gPj4gRXJpYw0KPj4+ID4gPj4NCj4+PiA+ID4+IFBTIC0NCj4+PiA+ID4+IEZy b20gUkZDIDIxMTkgLQ0KPj4+ID4gPj4gJ1NIT1VMRCAgIFRoaXMgd29yZCwgb3IgdGhlIGFk amVjdGl2ZSAiUkVDT01NRU5ERUQiLCBtZWFuIHRoYXQgdGhlcmUNCj4+PiA+ID4+ICAgICAg ICAgICBtYXkgZXhpc3QgdmFsaWQgcmVhc29ucyBpbiBwYXJ0aWN1bGFyIGNpcmN1bXN0YW5j ZXMgdG8NCj4+PiA+ID4+ICAgICAgICAgICBpZ25vcmUgYSBwYXJ0aWN1bGFyIGl0ZW0sIGJ1 dCB0aGUgZnVsbCBpbXBsaWNhdGlvbnMgbXVzdA0KPj4+ID4gPj4gICAgICAgICAgIGJlIHVu ZGVyc3Rvb2QgYW5kIGNhcmVmdWxseSB3ZWlnaGVkIGJlZm9yZSBjaG9vc2luZyBhDQo+Pj4g PiA+PiAgICAgICAgICAgZGlmZmVyZW50IGNvdXJzZS4nDQo+Pj4gPiA+Pg0KPj4+ID4gPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiA+ID4+IEZyb206IG1wbHMtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+ Pj4gPiBPZg0KPj4+ID4gPj4gUm9sZiBXaW50ZXINCj4+PiA+ID4+IFNlbnQ6IFR1ZXNkYXks IE1hcmNoIDIyLCAyMDExIDQ6NTcgQU0NCj4+PiA+ID4+IFRvOiBsb2FAcGkubnU7IG1wbHNA aWV0Zi5vcmcNCj4+PiA+ID4+IFN1YmplY3Q6IFJlOiBbbXBsc10gV29ya2luZyBHcm91cCBM YXMgQ2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtb24tDQo+Pj4gPiA+PiBkZW1hbmQtY3Yt MDMNCj4+PiA+ID4+DQo+Pj4gPiA+PiBIaSwNCj4+PiA+ID4+DQo+Pj4gPiA+PiBzb21lIGNv bW1lbnRzIGJlbG93Og0KPj4+ID4gPj4NCj4+PiA+ID4+IFNlY3Rpb24gMS4zIHNheXM6ICIg SW4gY2VydGFpbiBNUExTLVRQIGRlcGxveW1lbnQgc2NlbmFyaW9zIElQDQo+Pj4gPiA+PiBh ZGRyZXNzaW5nIG1pZ2h0IG5vdCBiZQ0KPj4+ID4gPj4gICAgYXZhaWxhYmxlIG9yIGl0IG1h eSBiZSBwcmVmZXJyZWQgdG8gdXNlIHNvbWUgZm9ybSBvZiBub24tSVANCj4+PiA+ID4+ICAg IGVuY2Fwc3VsYXRpb24gZm9yIE9uLWRlbWFuZCBDViwgcm91dGUgdHJhY2luZyBhbmQgQkZE IHBhY2tldHMuDQo+Pj4gPiBJbg0KPj4+ID4gPj4gICAgc3VjaCBzY2VuYXJpb3MsIE9uLWRl bWFuZCBDViBhbmQvb3Igcm91dGUgdHJhY2luZyBTSE9VTEQgYmUgcnVuDQo+Pj4gPiA+PiAg ICB3aXRob3V0IElQIGFkZHJlc3NpbmcuLi4iDQo+Pj4gPiA+Pg0KPj4+ID4gPj4gSSBhbSBu b3Qgc3VyZSB0aGUgIlNIT1VMRCIgaXMgcmlnaHQgaGVyZS4gSWYgbm8gSVAgYWRkcmVzc2lu ZyBpcw0KPj4+ID4gPj4gYXZhaWxhYmxlLCB0aGlzIHRoaW5nIE1VU1QgYmUgcnVuIHdpdGhv dXQgSVAgYWRkcmVzc2luZywgbXVzdG4ndCBpdD8NCj4+PiA+ID4+DQo+Pj4gPiA+PiBJIHRo aW5rIHNvbWUgYWRkaXRpb25hbCB0ZXh0IHJlZ2FyZGluZyBwZXItaW50ZXJmYWNlIE1JUCBh ZGRyZXNzaW5nDQo+Pj4gPiA+PiB3b3VsZCBiZSBuaWNlLiBBcyBmYXIgYXMgSSB1bmRlcnN0 YW5kIHRoZSBkb2N1bWVudCwgYWxsIFRMVnMgd2lsbCBiZQ0KPj4+ID4gPj4gaW5zaWRlIHRo ZSBMU1AgcGluZyBwYWNrZXQgKHJhdGhlciB0aGFuIGFzIEFDSCBUTFZzKS4NCj4+PiA+ID4+ DQo+Pj4gPiA+PiBTb21lIHBlb3BsZSBoYWQgY29uY2VybnMgZWFybGllciwgdGhhdCBhZGRy ZXNzaW5nIGluZm9ybWF0aW9uIHNob3VsZA0KPj4+ID4gYmUNCj4+PiA+ID4+IGluIGEgZml4 ZWQgbG9jYXRpb24gZm9yIGVhc2llciBwcm9jZXNzaW5nLiBJcyB0aGlzIHRoZSBjYXNlIGhl cmUgSQ0KPj4+ID4gPj4gd29uZGVyPw0KPj4+ID4gPj4NCj4+PiA+ID4+IEl0IHdvdWxkIGJl IG5pY2UgaWYgeW91IGNvdWxkIGFkZHJlc3MgdGhpcyBpbiB5b3VyIHByZXNlbnRhdGlvbiBp bg0KPj4+ID4gPj4gUHJhZ3VlLg0KPj4+ID4gPj4NCj4+PiA+ID4+IFRoYW5rcywNCj4+PiA+ ID4+DQo+Pj4gPiA+PiBSb2xmDQo+Pj4gPiA+Pg0KPj4+ID4gPj4NCj4+PiA+ID4+IE5FQyBF dXJvcGUgTGltaXRlZCB8IFJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2UsIDEgVmljdG9y aWEgUm9hZCwNCj4+PiA+ID4+IExvbmRvbiBXMyA2QkwgfCBSZWdpc3RlcmVkIGluIEVuZ2xh bmQgMjgzMjAxNA0KPj4+ID4gPj4NCj4+PiA+ID4+DQo+Pj4gPiA+PiA+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj4gPiA+PiA+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+PiA+IEJlaGFsZg0KPj4+ ID4gPj4gT2YNCj4+PiA+ID4+ID4gbG9hQHBpLm51DQo+Pj4gPiA+PiA+IFNlbnQ6IE1pdHR3 b2NoLCAxNi4gTeRyeiAyMDExIDAwOjI2DQo+Pj4gPiA+PiA+IFRvOiBtcGxzQGlldGYub3Jn DQo+Pj4gPiA+PiA+IENjOiBNUExTLVRQIGFkIGhvYyB0ZWFtDQo+Pj4gPiA+PiA+IFN1Ympl Y3Q6IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10 cC1vbi0NCj4+PiA+ID4+IGRlbWFuZC0NCj4+PiA+ID4+ID4gY3YtMDMNCj4+PiA+ID4+ID4N Cj4+PiA+ID4+ID4gV29ya2luZyBHcm91cCwNCj4+PiA+ID4+ID4NCj4+PiA+ID4+ID4gdGhp cyBpcyB0byBzdGFydCBhIDMgd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbg0KPj4+ ID4gPj4gPg0KPj4+ID4gPj4gPiBkcmFmdC1pZXRmLW1wbHMtdHAtb24tZGVtYW5kLWN2LTAz DQo+Pj4gPiA+PiA+DQo+Pj4gPiA+PiA+IFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRoZSB3 b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPj4+ID4gPj4gPiBtcGxzQGlldGYub3JnDQo+ Pj4gPiA+PiA+DQo+Pj4gPiA+PiA+IFRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRz IG9uIEFwcmlsIDgsIDIwMTEuDQo+Pj4gPiA+PiA+DQo+Pj4gPiA+PiA+IC9Mb2ENCj4+PiA+ ID4+ID4NCj4+PiA+ID4+ID4NCj4+PiA+ID4+ID4NCj4+PiA+ID4+ID4NCj4+PiA+ID4+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiA+ ID4+ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4+PiA+ID4+ID4gbXBsc0BpZXRmLm9yZw0KPj4+ ID4gPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+ PiA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4gPiA+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+ID4gPj4gbXBsc0BpZXRmLm9yZw0K Pj4+ID4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ Pj4gPiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+PiA+ID5tcGxzIG1haWxpbmcgbGlzdA0KPj4+ID4gPm1wbHNAaWV0Zi5vcmcNCj4+PiA+ ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+PiA+ID4N Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4gbXBsc0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4NCj4NCg== --GMAILSMTPBOUND01110331064321-- From aldrin.ietf@gmail.com Wed Mar 30 16:07:30 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C21CF3A6BD7 for ; Wed, 30 Mar 2011 16:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 vcgt1Cdf+iSf for ; Wed, 30 Mar 2011 16:07:28 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 1192828C144 for ; Wed, 30 Mar 2011 16:07:27 -0700 (PDT) Received: by bwz13 with SMTP id 13so1451641bwz.31 for ; Wed, 30 Mar 2011 16:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=pbFZ0kAtwo1Gkrl2STEvXGPLXAYGuYco0bEolXMuBEs=; b=lJOdGWx+midRYprOGNQ9bz0J7vI7gOZYnPIQFWjeUUW9FYbKjafbqvgqHAwi1L41n/ bxQMOk/kDTyh+V+UIITBZ/zR78juXApTyorBhIJC/6qyhLycKSOe7slG8z0QIKtJCh1o mVw8AJAlj6OyO7jpN7niZK5reCP+oI+QkA55Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=AxyaaLbf2/Nbiuot51fhhR2rARnqa18fELKvZUQkacxYdsluUvYUFVbfEpQyXQZ2x+ I9c6vHgmzRBKwUxRv3K5Uwzos4goZb/KhttVC+YXZWpFqqtNnJkEGss4S5CIKZRcnCef lKiLwRH7Ocn3fP0y9dATbhSlwGraIYhZFdwF0= Received: by 10.204.136.210 with SMTP id s18mr1652884bkt.56.1301526546544; Wed, 30 Mar 2011 16:09:06 -0700 (PDT) Received: from [130.129.66.202] (dhcp-42ca.meeting.ietf.org [130.129.66.202]) by mx.google.com with ESMTPS id q24sm356412bks.21.2011.03.30.16.08.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 16:09:05 -0700 (PDT) References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.d> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8G4) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPad Mail (8G4) From: Sam Aldrin Date: Wed, 30 Mar 2011 16:08:45 -0700 To: "" Cc: "" , "Manuel.Paul@telekom.de" , "Rolf.Winter@neclab.eu" Subject: Re: [mpls] Working Group Las Callondraft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 23:07:30 -0000 DSMAP or DDMAP could be used for both ping and trace. Nothing restricts usin= g the tlv for ping. -sam Sent from my iPad On Mar 30, 2011, at 2:43 PM, wrote: > Eric, >=20 > In my understanding, DSMAP TLV is only for trace route, isn't it? > We need specific interface information for ping mode of on-demand CV. >=20 > BR, > Hideki >=20 >> Hideki, >>=20 >> If you want to include specific interface information, >> you can include a DSMAP (or DDMAP) TLV as defined by RFC >> 4379, and extended by this draft (in combination with the >> draft "draft-ietf-mpls-lsp-ping-enhanced-dsmap" for DDMAP). >>=20 >> Would this not do what you're looking for? >>=20 >> -- >> Eric >>=20 >> -----Original Message----- >> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >> Sent: Wednesday, March 30, 2011 11:33 AM >> To: Rolf.Winter@neclab.eu; Eric Gray; mpls@ietf.org; Manuel.Paul@telekom.= de >> Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-dem= and-cv-03 >> Importance: High >>=20 >> Hi, >>=20 >> I have one comment on IDs in draft-on-demand-cv. >> The interface-D is missing in the current draft, there is only Node-ID. >> You need at least the interface ID to support per-interface MIP. >>=20 >> BR, >> Hideki >>=20 >>>=20 >>> Dear All, >>>=20 >>> I really appreciate the consideration on the per-interface MIP support a= nd the discussion moving forward. >>>=20 >>>=20 >>> =46rom an operator's perspective, it is very important that the support f= or per-interface MIPs is covered by the definitions. >>>=20 >>> Looking at earlier versions of draft-farrel-mpls-tp-mip-mep-map, there w= as already a solution proposal, using the TTL. Enhanced solutions have been t= horougly discussed during this IETF meeting. It it to be expected that there= will be ways to solve both the fast path and fate-sharing requirement. >>>=20 >>>=20 >>> I second the proposal initially made by Rolf, to include additional text= to document the per-interface MIP addressing for the on-demand-cv and for o= ther OAM tools. >>>=20 >>>=20 >>> Best regards, >>> Manuel >>>=20 >>>=20 >>> Deutsche Telekom AG >>> Group Technology >>> Manuel Paul >>> SA3-11 >>> Goslarer Ufer 35-37, 10589 Berlin >>> +49 30 3497 - 4394 (Tel.) >>> +49 30 3497 - 4956 (Fax) >>> +49 171 8634032 (Mobil) >>> E-Mail: mailto:manuel.paul@telekom.de >>> http://www.telekom.com >>>=20 >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of= >>>> Rolf Winter >>>> Sent: Monday, March 28, 2011 3:03 PM >>>> To: Eric Gray; hideki.endo.es@hitachi.com >>>> Cc: mpls@ietf.org >>>> Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-dema= nd- >>>> cv-03 >>>>=20 >>>> Eric, >>>>=20 >>>> I generally agree but I think there is one case actually which needs a >>>> closer look in this regard (which I hinted at earlier), which are the p= er- >>>> interface MIPs. Your TTL expires (the actual addressing bit here), the >>>> identifier tells you it is not intended for the ingress MIP, so it need= s >>>> to be forwarded to the egress MIP through the forwarding engine. Now if= >>>> you pull the packet out of the fast path and inject it back in, is the O= AM >>>> packet still fate sharing? If you can do this in HW on the line card, t= hen >>>> it will and it will just be forwarded as normal. I know this is a >>>> different draft, but this will be in particular important for performan= ce >>>> monitoring. >>>>=20 >>>> Best, >>>>=20 >>>> Rolf >>>>=20 >>>>=20 >>>>=20 >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lon= don >>>> W3 6BL | Registered in England 2832014 >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Eric Gray [mailto:eric.gray@ericsson.com] >>>>> Sent: Montag, 28. M=C3=A4rz 2011 14:45 >>>>> To: hideki.endo.es@hitachi.com; Rolf Winter >>>>> Cc: mpls@ietf.org >>>>> Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp= - >>>>> on-demand-cv-03 >>>>>=20 >>>>> Hideki, >>>>>=20 >>>>> What you're saying is true, but not relevant in this >>>>> case. The "addresses" in this discussion are not used to >>>>> determine how to forward OAM packets. They are used only >>>>> by the recipient MIP/MEP to verify that the OAM packet was >>>>> properly delivered. >>>>>=20 >>>>> By the way, this discussion is an indication of the >>>>> confusing injected by calling these things addresses. My >>>>> mistake and I bring it up now to help to stem the tide of >>>>> further comments resulting from that confusion. >>>>>=20 >>>>> In the version we post after last call is complete, >>>>> we will be changing the source and destination "address" >>>>> TLVs to source and destination "identifier" TLVs. >>>>>=20 >>>>> We will also be correcting the reference to DSMAP, >>>>> and DDMAP, address TLVs (which is incorrect, because the >>>>> format for DSMAP/DDMAP doesn't include a "length" field). >>>>>=20 >>>>> The format of the Downstream Mapping (DSMAP) TLV is >>>>> defined in RFC 4379, and we are not changing the format >>>>> of that TLV. >>>>>=20 >>>>> These changes are driven by last call comments we >>>>> have already received (see Joel Halpern's comments on the >>>>> mailing list) and are - in part - to correct accidental >>>>> use of the word "address" for source and destination >>>>> identifier TLVs (which is what we had discussed before >>>>> I generated the -03 version among the authors of several >>>>> of the current set of MPLS-TP drafts). >>>>>=20 >>>>> In the case of source and destination identifiers, >>>>> these will be used exclusively to verify that an OAM PDU >>>>> has been correctly received by its intended recipient. >>>>> Because this is an on-demand connectivity verification >>>>> protocol, that is expected to be used only on those >>>>> occasions when there is a network problem that needs to >>>>> be diagnosed, and the information is not seen (and not >>>>> visible - without layer violations), optimizing these >>>>> objects for software makes sense. >>>>>=20 >>>>> In addition, since either may be included (which >>>>> includes the possibility of including both), it is the >>>>> case already that we would then need to decide which is >>>>> to go first - assuming we wanted to do this (which we >>>>> do not). >>>>>=20 >>>>> -- >>>>> Eric >>>>>=20 >>>>> -----Original Message----- >>>>> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >>>>> Sent: Monday, March 28, 2011 8:11 AM >>>>> To: Eric Gray; Rolf.Winter@neclab.eu >>>>> Cc: mpls@ietf.org >>>>> Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-= >>>>> demand-cv-03 >>>>> Importance: High >>>>>=20 >>>>> Hi Eric and Rolf, >>>>>=20 >>>>> I'm sorry for interrupting. >>>>>=20 >>>>> I agree with Rolf regarding the per-interface MIP discussion. >>>>> We have to consider the HW implementation aspect, >>>>> because trapping of an OAM packet is HW rule/functionality even in >>>>> routers. >>>>>=20 >>>>> If every OAM packet is trapped to CPU >>>>> and the OAM packets which should NOT be processed in the Interface >>>>> are returned to Data-plane, >>>>> it is different forwarding path from user packets, >>>>> which is NOT the Connectivity Verification of the user path. >>>>>=20 >>>>> Therefore, we should take the HW aspect and flexibilty into account >>>>> concurrently. >>>>> If an address TLV MUST be the first in TLVs, >>>>> it is enough to make HW implementation easy. >>>>>=20 >>>>> BR, >>>>> Hideki >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Rolf, >>>>>>=20 >>>>>> The words you propose are okay with me. >>>>>>=20 >>>>>> I thought the MIP/interface and address location issues >>>>>> were separate. >>>>>>=20 >>>>>> I've personally had problems with protocol specifications >>>>>> that require ordering of TLVs. In particular, this is not very >>>>>> robust in terms of "future-proofing." What happens if new TLVs >>>>>> are added later on; for instance, suppose at some point we have >>>>>> multiple "address" TLVs? >>>>>>=20 >>>>>> Also, the fact that implementations are allowed to attach >>>>>> TLVs in any arbitrary order allows considerable flexibilty in >>>>>> implementation. Messages can be built in arbitrarily many ways. >>>>>> This too can be a future-proofing issue. >>>>>>=20 >>>>>> I would prefer not to start down the road of requiring a >>>>>> subset of TLVs to appear in a certain order, and saying we have >>>>>> one TLV that needs to be first is doing just that. >>>>>>=20 >>>>>> -- >>>>>> Eric >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >>>>>> Sent: Monday, March 28, 2011 6:19 AM >>>>>> To: Eric Gray >>>>>> Cc: mpls@ietf.org >>>>>> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >>>>> demand-cv-03 >>>>>> Importance: High >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> I still think there is a logical error. Let me explain. In case there= >>>>> is no IP you simply cannot use it. You say you could enable IP but the= n >>>>> that is not a case where there is no IP. In order to be constructive >>>>> here is a text change suggestion: >>>>>>=20 >>>>>> "In certain MPLS-TP deployment scenarios IP addressing might not be >>>>> available. In those cases On-demand CV and/or route tracing MUST be ru= n >>>>> without IP addressing, using the ACH channel type specified in Section= >>>>> 3. In other cases it might be available, however, it may be preferred >>>>> to use some form of non-IP encapsulation. In those cases, the >>>>> procedures as outlined in section 3 SHOULD also be used." >>>>>>=20 >>>>>> Regarding the per-interface MIP discussion. The HW aspect also popped= >>>>> up in the PWE3 session and I think this is an important consideration,= >>>>> in particular for OAM. Even if we talk about TLVs, we could make it a >>>>> MUST that an Address TLV is always the first one to appear. If you can= >>>>> facilitate an easy implementation in hardware, I see no reason to >>>>> deliberately not do it. >>>>>>=20 >>>>>> Best, >>>>>>=20 >>>>>> Rolf >>>>>>=20 >>>>>>=20 >>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>>>> London W3 6BL | Registered in England 2832014 >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Eric Gray [mailto:eric.gray@ericsson.com] >>>>>>> Sent: Montag, 28. M=C3=A4rz 2011 11:43 >>>>>>> To: Rolf Winter >>>>>>> Cc: loa@pi.nu; mpls@ietf.org >>>>>>> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-= >>>>>>> demand-cv-03 >>>>>>>=20 >>>>>>> Rolf, >>>>>>>=20 >>>>>>> With regard to the use of SHOULD (verses MUST) - the intent >>>>>>> (according to RFC 2119 - see the quote below) is consistent with >>>>>>> this case. If - for some reason - one had a really good reason to >>>>>>> use IP addressing in some specific case, one could take steps to >>>>>>> make IP addressing available. >>>>>>>=20 >>>>>>> This could be said to introduce a logical disconnect, but we >>>>>>> are saved from going down that path by the fact that the statement >>>>>>> also includes the case where (for some reason) there is a case in >>>>>>> which some other addressing scheme might be preferred. In many of >>>>>>> the cases where another addressing scheme may be preferred, it is >>>>>>> still possible (in fact likely) that IP addressing is available. >>>>>>>=20 >>>>>>> Otherwise, it would not have been necessary to distinguish >>>>>>> this case from the one in which IP addressing is not available. >>>>>>>=20 >>>>>>> For the case where IP addressing is not the preferred mode, >>>>>>> we are recommending a mode in which it is not necessary. >>>>>>>=20 >>>>>>> With regard to having addresses located in the same place, >>>>>>> this protocol is meant for connectivity testing on an on-demand >>>>>>> basis and is therefore not optimized for processing in hardware. >>>>>>>=20 >>>>>>> Whether addresses or identifiers, if we are talking about >>>>>>> TLV contents, there are issues with trying to guarantee location >>>>>>> of specific content, because of the fact that the TLV in question >>>>>>> will probably follow other TLVs - thus making locations difficult >>>>>>> to predict in any case. >>>>>>>=20 >>>>>>> With regard to needing more text on per-interface MIPs, do >>>>>>> you have specific suggestions as to what text we might add? >>>>>>>=20 >>>>>>> I understand (from discussion with WG chairs) that we are >>>>>>> not allowed to explicitly address last call comments during the >>>>>>> IETF meeting in Prague, because the last call is still ongoing >>>>>>> at that time. >>>>>>>=20 >>>>>>> -- >>>>>>> Eric >>>>>>>=20 >>>>>>> PS - >>>>>>> =46rom RFC 2119 - >>>>>>> 'SHOULD This word, or the adjective "RECOMMENDED", mean that there= >>>>>>> may exist valid reasons in particular circumstances to >>>>>>> ignore a particular item, but the full implications must >>>>>>> be understood and carefully weighed before choosing a >>>>>>> different course.' >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf= >>>>> Of >>>>>>> Rolf Winter >>>>>>> Sent: Tuesday, March 22, 2011 4:57 AM >>>>>>> To: loa@pi.nu; mpls@ietf.org >>>>>>> Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on-= >>>>>>> demand-cv-03 >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> some comments below: >>>>>>>=20 >>>>>>> Section 1.3 says: " In certain MPLS-TP deployment scenarios IP >>>>>>> addressing might not be >>>>>>> available or it may be preferred to use some form of non-IP >>>>>>> encapsulation for On-demand CV, route tracing and BFD packets. >>>>> In >>>>>>> such scenarios, On-demand CV and/or route tracing SHOULD be run >>>>>>> without IP addressing..." >>>>>>>=20 >>>>>>> I am not sure the "SHOULD" is right here. If no IP addressing is >>>>>>> available, this thing MUST be run without IP addressing, mustn't it?= >>>>>>>=20 >>>>>>> I think some additional text regarding per-interface MIP addressing >>>>>>> would be nice. As far as I understand the document, all TLVs will be= >>>>>>> inside the LSP ping packet (rather than as ACH TLVs). >>>>>>>=20 >>>>>>> Some people had concerns earlier, that addressing information should= >>>>> be >>>>>>> in a fixed location for easier processing. Is this the case here I >>>>>>> wonder? >>>>>>>=20 >>>>>>> It would be nice if you could address this in your presentation in >>>>>>> Prague. >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> Rolf >>>>>>>=20 >>>>>>>=20 >>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>>>>>> London W3 6BL | Registered in England 2832014 >>>>>>>=20 >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>>>> Behalf >>>>>>> Of >>>>>>>> loa@pi.nu >>>>>>>> Sent: Mittwoch, 16. M=C3=A4rz 2011 00:26 >>>>>>>> To: mpls@ietf.org >>>>>>>> Cc: MPLS-TP ad hoc team >>>>>>>> Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >>>>>>> demand- >>>>>>>> cv-03 >>>>>>>>=20 >>>>>>>> Working Group, >>>>>>>>=20 >>>>>>>> this is to start a 3 week working group last call on >>>>>>>>=20 >>>>>>>> draft-ietf-mpls-tp-on-demand-cv-03 >>>>>>>>=20 >>>>>>>> Please send comments to the working group mailing list >>>>>>>> mpls@ietf.org >>>>>>>>=20 >>>>>>>> The working group last call ends on April 8, 2011. >>>>>>>>=20 >>>>>>>> /Loa >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> mpls mailing list >>>>>>>> mpls@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>> _______________________________________________ >>>>>>> mpls mailing list >>>>>>> mpls@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>=20 >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >>=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From velantechie@gmail.com Wed Mar 30 21:23:18 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5613A69C6 for ; Wed, 30 Mar 2011 21:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 pI7Em021vkjk for ; Wed, 30 Mar 2011 21:23:17 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id E5DD03A69B3 for ; Wed, 30 Mar 2011 21:23:16 -0700 (PDT) Received: by vxg33 with SMTP id 33so1836251vxg.31 for ; Wed, 30 Mar 2011 21:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JhPnWGY5ejXPDDW5kWtvaeE3CqKvTpLcnJUGsd0ocDw=; b=uIXjRCZ1TeEPxLo3FP8nhjgUsQn4u3lmuc2Oeuqjazx4rRDs/Wjw9OJi1Gp06CPbMK gCnepehWNjFJ4XVgFvtkdMozbrVvkE0avjXh8uZWrN1QumS6UJmXz1I0xBifYuDjPi// ex+Wjl2puPITaFRXBaLXyiEkuzbFFzQBgOJ4Q= 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=GW2uJvCefA5/WmpEbxmlA9Ez+fpp0W5xnjIcRknEYYHybKwvtByKYft0PCNQcDyVLJ Cs5rgIp2504jJqCQAB1ZWIzuJmyUgPEs5pRpq1x71WDjX3IcMH51/BToDW/tCKo526/c t864miv6NR7LT2/fm02YW2CZfqtqJOsrJcRfQ= MIME-Version: 1.0 Received: by 10.52.74.66 with SMTP id r2mr2773344vdv.263.1301545495942; Wed, 30 Mar 2011 21:24:55 -0700 (PDT) Received: by 10.52.166.233 with HTTP; Wed, 30 Mar 2011 21:24:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Mar 2011 21:24:55 -0700 Message-ID: From: Velan S To: venkatesan mahalingam Content-Type: multipart/alternative; boundary=bcaec5016627f1d5e3049fbfac5f Cc: mpls Subject: Re: [mpls] Regd. MPLS-TP asymmetric bandwidth requirements clarification X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 04:23:18 -0000 --bcaec5016627f1d5e3049fbfac5f Content-Type: text/plain; charset=ISO-8859-1 Hi Venkat, The co-routed or non-co-routed cases are only path layout. The LSPs in the two directions regardless if they are co-routed or separately routed, should allow Users to setup with differing B/W on each side. That means the LSPs in two directions not necessarily have to have equal B/W, and user should be able to Setup equal B/W if LSP wants or non-equal B/W if LSP wants. Regards S.Velan On Wed, Mar 30, 2011 at 9:40 AM, venkatesan mahalingam wrote: > Hello Authors and all, > > Per RFC-5654 section 2.1. General Requirements > > 14 MPLS-TP MUST support bidirectional transport paths with > asymmetric bandwidth requirements, i.e., the amount of reserved > bandwidth differs between the forward and backward directions. > > > VM>> Is this requirement applicable for both MPLS-TP co-routed and > associated bidirectional tunnels? > > Regards, > Venkat. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --bcaec5016627f1d5e3049fbfac5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Venkat,=
=A0=
The co-routed or non-co-= routed cases are only path layout.

=A0

The LSPs in the two direct= ions regardless if they are co-routed or separately routed, should allow Us= ers

to setup with differing B/= W on each side.

=A0

That means the LSPs in two= directions not necessarily have to have equal B/W, and user should be able= to

Setup equal B/W if LSP wan= ts or non-equal B/W if=A0LSP wants.

=A0
Regards
S.Velan

On Wed, Mar 30, 2011 at 9:40 AM, venkatesan maha= lingam <venkat= flex@gmail.com> wrote:
Hello Authors an= d all,=20

Per RFC-5654 section=A02.1. General Requirements
14 = MPLS-TP MUST support bidirectional transport paths with asymmetric bandwidth requirements, i.e., the amount of reserved bandwidth differs between the forward and backward directions.=

VM>> Is this requirement applicable for both MPLS-TP co-routed a= nd associated bidirectional tunnels?

Regards,
Venkat.

______________________________________________= _
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


--bcaec5016627f1d5e3049fbfac5f-- From velantechie@gmail.com Wed Mar 30 21:24:04 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94123A69B3; Wed, 30 Mar 2011 21:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ORxPm+hk7b1o; Wed, 30 Mar 2011 21:24:04 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 9E0FB3A6990; Wed, 30 Mar 2011 21:24:03 -0700 (PDT) Received: by vws12 with SMTP id 12so1819956vws.31 for ; Wed, 30 Mar 2011 21:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ogUzp0Rc4y82iGqlkMrGQtaAeRE0xtXJvDOKBtWySA8=; b=fzJ5T7PYU2O6Kpbs6cDCsRjVml8akQzOCvtlcH1alG7Ak9gVFf/pYYT/LMCssAFNae f1pPHgnuQB0YvGeL0vEGsu0KfZOfCvE/19omwInDL2IGWwJx2fQ7h7OOUlxPVpfA7UCH AWo3750PECeMtlgqyzTcb5Uy7bldSw4keSiNY= 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=b80XDSu2U7eZ6IZj61cGjMYFj9A9r8dUF+xEjonU4SDjY8/MrSACLRnXqbNfZaHpjk QFp36491JFYVrFmusKQoVn/r6apxLUER9YfgC1QizQETTLL1gAfQ6VcE97B0aGNvrhLH wYgHR5Eyh2g7ph335zG+tYZQLzDkmBph9yH7M= MIME-Version: 1.0 Received: by 10.52.0.169 with SMTP id 9mr2746854vdf.303.1301545542506; Wed, 30 Mar 2011 21:25:42 -0700 (PDT) Received: by 10.52.166.233 with HTTP; Wed, 30 Mar 2011 21:25:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Mar 2011 21:25:42 -0700 Message-ID: From: Velan S To: venkatesan mahalingam Content-Type: multipart/alternative; boundary=20cf304346d6b8598f049fbfaf4d Cc: mpls , mpls-tp@ietf.org Subject: Re: [mpls] Regd. MPLS-TP asymmetric bandwidth requirements clarification X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 04:24:05 -0000 --20cf304346d6b8598f049fbfaf4d Content-Type: text/plain; charset=ISO-8859-1 CC: mpls-tp also. On Wed, Mar 30, 2011 at 9:24 PM, Velan S wrote: > Hi Venkat, > > The co-routed or non-co-routed cases are only path layout. > > > > The LSPs in the two directions regardless if they are co-routed or > separately routed, should allow Users > > to setup with differing B/W on each side. > > > > That means the LSPs in two directions not necessarily have to have equal > B/W, and user should be able to > > Setup equal B/W if LSP wants or non-equal B/W if LSP wants. > > Regards > S.Velan > > On Wed, Mar 30, 2011 at 9:40 AM, venkatesan mahalingam < > venkatflex@gmail.com> wrote: > >> Hello Authors and all, >> >> Per RFC-5654 section 2.1. General Requirements >> >> 14 MPLS-TP MUST support bidirectional transport paths with >> asymmetric bandwidth requirements, i.e., the amount of reserved >> bandwidth differs between the forward and backward directions. >> >> >> VM>> Is this requirement applicable for both MPLS-TP co-routed and >> associated bidirectional tunnels? >> >> Regards, >> Venkat. >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> > --20cf304346d6b8598f049fbfaf4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable CC: mpls-tp also.

On Wed, Mar 30, 2011 at 9:24 PM, Velan S <velantechie@gmail.c= om> wrote:
Hi Venkat,=
=A0=
The co-routed or non-co-= routed cases are only path layout.

=A0

The LSPs in the two direct= ions regardless if they are co-routed or separately routed, should allow Us= ers

to setup with differing B/= W on each side.

=A0

That means the LSPs in two= directions not necessarily have to have equal B/W, and user should be able= to

Setup equal B/W if LSP wan= ts or non-equal B/W if=A0LSP wants.

=A0
Regards
S.Velan

On Wed, Mar 30, 2011 at 9:40 AM, venkatesan mahalingam <venkatflex@gmail.com> wrote:
Hello Authors and all,=20

Per RFC-5654 section=A02.1. General Requirements
14 = MPLS-TP MUST support bidirectional transport paths with asymmetric bandwidth requirements, i.e., the amount of reserved bandwidth differs between the forward and backward directions.=

VM>> Is this requirement applicable for both MPLS-TP co-routed a= nd associated bidirectional tunnels?

Regards,
Venkat.

__________________________________= _____________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls=



--20cf304346d6b8598f049fbfaf4d-- From Sidd.Aanand@ecitele.com Wed Mar 30 21:27:57 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08F013A6BFA for ; Wed, 30 Mar 2011 21:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 ChFfuIrke0zI for ; Wed, 30 Mar 2011 21:27:50 -0700 (PDT) Received: from uspitbmg01.ecitele.com (uspitbmg01-out.ecitele.com [63.94.127.136]) by core3.amsl.com (Postfix) with ESMTP id 452A928C104 for ; Wed, 30 Mar 2011 21:27:48 -0700 (PDT) X-AuditID: 3f5e7f87-b7b0bae000006999-3a-4d942a6f2e7e Received: from uspitexch01.ecitele.com ( [10.0.0.71]) by uspitbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 98.E0.27033.F6A249D4; Thu, 31 Mar 2011 03:17:04 -0400 (EDT) Received: from USPITMAIL01.ecitele.com ([10.0.0.81]) by uspitexch01.ecitele.com ([10.0.0.71]) with mapi; Thu, 31 Mar 2011 00:29:24 -0400 From: Sidd Aanand To: Velan S , venkatesan mahalingam Date: Thu, 31 Mar 2011 00:29:10 -0400 Thread-Topic: [mpls] Regd. MPLS-TP asymmetric bandwidth requirements clarification Thread-Index: AcvvW5+QlSHWUweHRgmzoqWMfNRPVAAAHWmw Message-ID: <047B8373FDE6CE4BBAC116646F35479213739D8A5A@USPITMAIL01.ecitele.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_047B8373FDE6CE4BBAC116646F35479213739D8A5AUSPITMAIL01ec_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: mpls Subject: Re: [mpls] Regd. MPLS-TP asymmetric bandwidth requirements clarification X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 04:27:58 -0000 --_000_047B8373FDE6CE4BBAC116646F35479213739D8A5AUSPITMAIL01ec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Velan on this one. The way the path is laid out is independent= of the BW requirement in each direction. Sidd From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Vel= an S Sent: Thursday, March 31, 2011 9:55 AM To: venkatesan mahalingam Cc: mpls Subject: Re: [mpls] Regd. MPLS-TP asymmetric bandwidth requirements clarifi= cation Hi Venkat, The co-routed or non-co-routed cases are only path layout. The LSPs in the two directions regardless if they are co-routed or separate= ly routed, should allow Users to setup with differing B/W on each side. That means the LSPs in two directions not necessarily have to have equal B/= W, and user should be able to Setup equal B/W if LSP wants or non-equal B/W if LSP wants. Regards S.Velan On Wed, Mar 30, 2011 at 9:40 AM, venkatesan mahalingam > wrote: Hello Authors and all, Per RFC-5654 section 2.1. General Requirements 14 MPLS-TP MUST support bidirectional transport paths with asymmetric bandwidth requirements, i.e., the amount of reserved bandwidth differs between the forward and backward directions. VM>> Is this requirement applicable for both MPLS-TP co-routed and associat= ed bidirectional tunnels? Regards, Venkat. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_047B8373FDE6CE4BBAC116646F35479213739D8A5AUSPITMAIL01ec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree w= ith Velan on this one. The way the path is laid out is independent of the B= W requirement in each direction.

=
Sidd

 = ;

From: mpls-bounces@ietf.org [= mailto:mpls-bounces@ietf.org] On Behalf Of Velan S
Sent: T= hursday, March 31, 2011 9:55 AM
To: venkatesan mahalingam
C= c: mpls
Subject: Re: [mpls] Regd. MPLS-TP asymmetric bandwidt= h requirements clarification

 

Hi Venkat,

 

The = co-routed or non-co-routed cases are only path layout.

 

The LSPs in the tw= o directions regardless if they are co-routed or separately routed, should = allow Users

to setup with differing B/W on = each side.

 

That means the LSPs in two directions not necessarily have to have e= qual B/W, and user should be able to

Setup = equal B/W if LSP wants or non-equal B/W if LSP wants.

 

Regards

S.Velan

On= Wed, Mar 30, 2011 at 9:40 AM, venkatesan mahalingam <venkatflex@gmail.com> wrote:

Hello Authors and all,

 

Per RFC-5654 section 2.1. General Requirements

   14  MP=
LS-TP MUST support bidirectional transport paths with
      =
; asymmetric bandwidth requirements, i.e., the amount of reserved
    =
;   bandwidth differs between the forward and backward directions=
.
 
VM>> Is this requirement applicable for both MPLS-T=
P co-routed and associated bidirectional tunnels?
 
Regards,
Venkat.

____=
___________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/l=
istinfo/mpls
 =
= --_000_047B8373FDE6CE4BBAC116646F35479213739D8A5AUSPITMAIL01ec_-- From eric.gray@ericsson.com Wed Mar 30 22:24:06 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8793A6C05 for ; Wed, 30 Mar 2011 22:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.917 X-Spam-Level: X-Spam-Status: No, score=-5.917 tagged_above=-999 required=5 tests=[AWL=0.682, 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 ye7rNeaI3DyZ for ; Wed, 30 Mar 2011 22:24:04 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id E8B3E3A6C03 for ; Wed, 30 Mar 2011 22:24:03 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2V5PdLw013205; Thu, 31 Mar 2011 00:25:40 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 31 Mar 2011 01:25:34 -0400 From: Eric Gray To: "hideki.endo.es@hitachi.com" , "mpls@ietf.org" Date: Thu, 31 Mar 2011 01:25:31 -0400 Thread-Topic: Re[2]: Re[2]: [mpls] Working Group Las Callondraft-ietf-mpls-tp-on-demand-cv-03 Thread-Index: AcvvI5EiXksDnG/9S/SD5Cf0J/truAAP5a4A Message-ID: References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.d> In-Reply-To: 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: "Manuel.Paul@telekom.de" , "Rolf.Winter@neclab.eu" Subject: Re: [mpls] Working Group Las Callondraft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 05:24:06 -0000 Hideki, Ping mode would be strictly MEP-to-MEP. At least, that is the way it is intended to work in our draft. Why would you need per-interface MIP information in this case? If someone wanted to do LSP-Ping to a specific interface, I am uncertain why it would be incorrect to use the DSMAP TLV. -- Eric -----Original Message----- From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] Sent: Wednesday, March 30, 2011 5:43 PM To: Eric Gray; mpls@ietf.org Cc: Rolf.Winter@neclab.eu; Manuel.Paul@telekom.de Subject: Re[2]: Re[2]: [mpls] Working Group Las Callondraft-ietf-mpls-tp-on= -demand-cv-03 Importance: High Eric, In my understanding, DSMAP TLV is only for trace route, isn't it? We need specific interface information for ping mode of on-demand CV. BR, Hideki >Hideki, > > If you want to include specific interface information, >you can include a DSMAP (or DDMAP) TLV as defined by RFC >4379, and extended by this draft (in combination with the >draft "draft-ietf-mpls-lsp-ping-enhanced-dsmap" for DDMAP). > > Would this not do what you're looking for? > >-- >Eric > >-----Original Message----- >From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >Sent: Wednesday, March 30, 2011 11:33 AM >To: Rolf.Winter@neclab.eu; Eric Gray; mpls@ietf.org; Manuel.Paul@telekom.d= e >Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-dema= nd-cv-03 >Importance: High > >Hi, > >I have one comment on IDs in draft-on-demand-cv. >The interface-D is missing in the current draft, there is only Node-ID. >You need at least the interface ID to support per-interface MIP. > >BR, >Hideki > >> >>Dear All, >> >>I really appreciate the consideration on the per-interface MIP support an= d the discussion moving forward. >> >> >>From an operator's perspective, it is very important that the support for= per-interface MIPs is covered by the definitions. >> >>Looking at earlier versions of draft-farrel-mpls-tp-mip-mep-map, there wa= s already a solution proposal, using the TTL. Enhanced solutions have been = thorougly discussed during this IETF meeting. It it to be expected that the= re will be ways to solve both the fast path and fate-sharing requirement. >> >> >>I second the proposal initially made by Rolf, to include additional text = to document the per-interface MIP addressing for the on-demand-cv and for o= ther OAM tools. >> >> >>Best regards, >>Manuel >> >> >>Deutsche Telekom AG >>Group Technology >>Manuel Paul >>SA3-11 >>Goslarer Ufer 35-37, 10589 Berlin >>+49 30 3497 - 4394 (Tel.) >>+49 30 3497 - 4956 (Fax) >>+49 171 8634032 (Mobil) >>E-Mail: mailto:manuel.paul@telekom.de >>http://www.telekom.com >> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>> Rolf Winter >>> Sent: Monday, March 28, 2011 3:03 PM >>> To: Eric Gray; hideki.endo.es@hitachi.com >>> Cc: mpls@ietf.org >>> Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-dema= nd- >>> cv-03 >>> >>> Eric, >>> >>> I generally agree but I think there is one case actually which needs a >>> closer look in this regard (which I hinted at earlier), which are the p= er- >>> interface MIPs. Your TTL expires (the actual addressing bit here), the >>> identifier tells you it is not intended for the ingress MIP, so it need= s >>> to be forwarded to the egress MIP through the forwarding engine. Now if >>> you pull the packet out of the fast path and inject it back in, is the = OAM >>> packet still fate sharing? If you can do this in HW on the line card, t= hen >>> it will and it will just be forwarded as normal. I know this is a >>> different draft, but this will be in particular important for performan= ce >>> monitoring. >>> >>> Best, >>> >>> Rolf >>> >>> >>> >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lon= don >>> W3 6BL | Registered in England 2832014 >>> >>> >>> > -----Original Message----- >>> > From: Eric Gray [mailto:eric.gray@ericsson.com] >>> > Sent: Montag, 28. M=E4rz 2011 14:45 >>> > To: hideki.endo.es@hitachi.com; Rolf Winter >>> > Cc: mpls@ietf.org >>> > Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-t= p- >>> > on-demand-cv-03 >>> > >>> > Hideki, >>> > >>> > What you're saying is true, but not relevant in this >>> > case. The "addresses" in this discussion are not used to >>> > determine how to forward OAM packets. They are used only >>> > by the recipient MIP/MEP to verify that the OAM packet was >>> > properly delivered. >>> > >>> > By the way, this discussion is an indication of the >>> > confusing injected by calling these things addresses. My >>> > mistake and I bring it up now to help to stem the tide of >>> > further comments resulting from that confusion. >>> > >>> > In the version we post after last call is complete, >>> > we will be changing the source and destination "address" >>> > TLVs to source and destination "identifier" TLVs. >>> > >>> > We will also be correcting the reference to DSMAP, >>> > and DDMAP, address TLVs (which is incorrect, because the >>> > format for DSMAP/DDMAP doesn't include a "length" field). >>> > >>> > The format of the Downstream Mapping (DSMAP) TLV is >>> > defined in RFC 4379, and we are not changing the format >>> > of that TLV. >>> > >>> > These changes are driven by last call comments we >>> > have already received (see Joel Halpern's comments on the >>> > mailing list) and are - in part - to correct accidental >>> > use of the word "address" for source and destination >>> > identifier TLVs (which is what we had discussed before >>> > I generated the -03 version among the authors of several >>> > of the current set of MPLS-TP drafts). >>> > >>> > In the case of source and destination identifiers, >>> > these will be used exclusively to verify that an OAM PDU >>> > has been correctly received by its intended recipient. >>> > Because this is an on-demand connectivity verification >>> > protocol, that is expected to be used only on those >>> > occasions when there is a network problem that needs to >>> > be diagnosed, and the information is not seen (and not >>> > visible - without layer violations), optimizing these >>> > objects for software makes sense. >>> > >>> > In addition, since either may be included (which >>> > includes the possibility of including both), it is the >>> > case already that we would then need to decide which is >>> > to go first - assuming we wanted to do this (which we >>> > do not). >>> > >>> > -- >>> > Eric >>> > >>> > -----Original Message----- >>> > From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >>> > Sent: Monday, March 28, 2011 8:11 AM >>> > To: Eric Gray; Rolf.Winter@neclab.eu >>> > Cc: mpls@ietf.org >>> > Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on= - >>> > demand-cv-03 >>> > Importance: High >>> > >>> > Hi Eric and Rolf, >>> > >>> > I'm sorry for interrupting. >>> > >>> > I agree with Rolf regarding the per-interface MIP discussion. >>> > We have to consider the HW implementation aspect, >>> > because trapping of an OAM packet is HW rule/functionality even in >>> > routers. >>> > >>> > If every OAM packet is trapped to CPU >>> > and the OAM packets which should NOT be processed in the Interface >>> > are returned to Data-plane, >>> > it is different forwarding path from user packets, >>> > which is NOT the Connectivity Verification of the user path. >>> > >>> > Therefore, we should take the HW aspect and flexibilty into account >>> > concurrently. >>> > If an address TLV MUST be the first in TLVs, >>> > it is enough to make HW implementation easy. >>> > >>> > BR, >>> > Hideki >>> > >>> > >>> > >>> > >Rolf, >>> > > >>> > > The words you propose are okay with me. >>> > > >>> > > I thought the MIP/interface and address location issues >>> > >were separate. >>> > > >>> > > I've personally had problems with protocol specifications >>> > >that require ordering of TLVs. In particular, this is not very >>> > >robust in terms of "future-proofing." What happens if new TLVs >>> > >are added later on; for instance, suppose at some point we have >>> > >multiple "address" TLVs? >>> > > >>> > > Also, the fact that implementations are allowed to attach >>> > >TLVs in any arbitrary order allows considerable flexibilty in >>> > >implementation. Messages can be built in arbitrarily many ways. >>> > >This too can be a future-proofing issue. >>> > > >>> > > I would prefer not to start down the road of requiring a >>> > >subset of TLVs to appear in a certain order, and saying we have >>> > >one TLV that needs to be first is doing just that. >>> > > >>> > >-- >>> > >Eric >>> > > >>> > >-----Original Message----- >>> > >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >>> > >Sent: Monday, March 28, 2011 6:19 AM >>> > >To: Eric Gray >>> > >Cc: mpls@ietf.org >>> > >Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >>> > demand-cv-03 >>> > >Importance: High >>> > > >>> > >Hi, >>> > > >>> > >I still think there is a logical error. Let me explain. In case ther= e >>> > is no IP you simply cannot use it. You say you could enable IP but th= en >>> > that is not a case where there is no IP. In order to be constructive >>> > here is a text change suggestion: >>> > > >>> > >"In certain MPLS-TP deployment scenarios IP addressing might not be >>> > available. In those cases On-demand CV and/or route tracing MUST be r= un >>> > without IP addressing, using the ACH channel type specified in Sectio= n >>> > 3. In other cases it might be available, however, it may be preferred >>> > to use some form of non-IP encapsulation. In those cases, the >>> > procedures as outlined in section 3 SHOULD also be used." >>> > > >>> > >Regarding the per-interface MIP discussion. The HW aspect also poppe= d >>> > up in the PWE3 session and I think this is an important consideration= , >>> > in particular for OAM. Even if we talk about TLVs, we could make it a >>> > MUST that an Address TLV is always the first one to appear. If you ca= n >>> > facilitate an easy implementation in hardware, I see no reason to >>> > deliberately not do it. >>> > > >>> > >Best, >>> > > >>> > >Rolf >>> > > >>> > > >>> > >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>> > London W3 6BL | Registered in England 2832014 >>> > > >>> > > >>> > >> -----Original Message----- >>> > >> From: Eric Gray [mailto:eric.gray@ericsson.com] >>> > >> Sent: Montag, 28. M=E4rz 2011 11:43 >>> > >> To: Rolf Winter >>> > >> Cc: loa@pi.nu; mpls@ietf.org >>> > >> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-o= n- >>> > >> demand-cv-03 >>> > >> >>> > >> Rolf, >>> > >> >>> > >> With regard to the use of SHOULD (verses MUST) - the inten= t >>> > >> (according to RFC 2119 - see the quote below) is consistent with >>> > >> this case. If - for some reason - one had a really good reason to >>> > >> use IP addressing in some specific case, one could take steps to >>> > >> make IP addressing available. >>> > >> >>> > >> This could be said to introduce a logical disconnect, but = we >>> > >> are saved from going down that path by the fact that the statement >>> > >> also includes the case where (for some reason) there is a case in >>> > >> which some other addressing scheme might be preferred. In many of >>> > >> the cases where another addressing scheme may be preferred, it is >>> > >> still possible (in fact likely) that IP addressing is available. >>> > >> >>> > >> Otherwise, it would not have been necessary to distinguish >>> > >> this case from the one in which IP addressing is not available. >>> > >> >>> > >> For the case where IP addressing is not the preferred mode= , >>> > >> we are recommending a mode in which it is not necessary. >>> > >> >>> > >> With regard to having addresses located in the same place, >>> > >> this protocol is meant for connectivity testing on an on-demand >>> > >> basis and is therefore not optimized for processing in hardware. >>> > >> >>> > >> Whether addresses or identifiers, if we are talking about >>> > >> TLV contents, there are issues with trying to guarantee location >>> > >> of specific content, because of the fact that the TLV in question >>> > >> will probably follow other TLVs - thus making locations difficult >>> > >> to predict in any case. >>> > >> >>> > >> With regard to needing more text on per-interface MIPs, do >>> > >> you have specific suggestions as to what text we might add? >>> > >> >>> > >> I understand (from discussion with WG chairs) that we are >>> > >> not allowed to explicitly address last call comments during the >>> > >> IETF meeting in Prague, because the last call is still ongoing >>> > >> at that time. >>> > >> >>> > >> -- >>> > >> Eric >>> > >> >>> > >> PS - >>> > >> From RFC 2119 - >>> > >> 'SHOULD This word, or the adjective "RECOMMENDED", mean that the= re >>> > >> may exist valid reasons in particular circumstances to >>> > >> ignore a particular item, but the full implications must >>> > >> be understood and carefully weighed before choosing a >>> > >> different course.' >>> > >> >>> > >> -----Original Message----- >>> > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beha= lf >>> > Of >>> > >> Rolf Winter >>> > >> Sent: Tuesday, March 22, 2011 4:57 AM >>> > >> To: loa@pi.nu; mpls@ietf.org >>> > >> Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-o= n- >>> > >> demand-cv-03 >>> > >> >>> > >> Hi, >>> > >> >>> > >> some comments below: >>> > >> >>> > >> Section 1.3 says: " In certain MPLS-TP deployment scenarios IP >>> > >> addressing might not be >>> > >> available or it may be preferred to use some form of non-IP >>> > >> encapsulation for On-demand CV, route tracing and BFD packets. >>> > In >>> > >> such scenarios, On-demand CV and/or route tracing SHOULD be run >>> > >> without IP addressing..." >>> > >> >>> > >> I am not sure the "SHOULD" is right here. If no IP addressing is >>> > >> available, this thing MUST be run without IP addressing, mustn't i= t? >>> > >> >>> > >> I think some additional text regarding per-interface MIP addressin= g >>> > >> would be nice. As far as I understand the document, all TLVs will = be >>> > >> inside the LSP ping packet (rather than as ACH TLVs). >>> > >> >>> > >> Some people had concerns earlier, that addressing information shou= ld >>> > be >>> > >> in a fixed location for easier processing. Is this the case here I >>> > >> wonder? >>> > >> >>> > >> It would be nice if you could address this in your presentation in >>> > >> Prague. >>> > >> >>> > >> Thanks, >>> > >> >>> > >> Rolf >>> > >> >>> > >> >>> > >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road= , >>> > >> London W3 6BL | Registered in England 2832014 >>> > >> >>> > >> >>> > >> > -----Original Message----- >>> > >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>> > Behalf >>> > >> Of >>> > >> > loa@pi.nu >>> > >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26 >>> > >> > To: mpls@ietf.org >>> > >> > Cc: MPLS-TP ad hoc team >>> > >> > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >>> > >> demand- >>> > >> > cv-03 >>> > >> > >>> > >> > Working Group, >>> > >> > >>> > >> > this is to start a 3 week working group last call on >>> > >> > >>> > >> > draft-ietf-mpls-tp-on-demand-cv-03 >>> > >> > >>> > >> > Please send comments to the working group mailing list >>> > >> > mpls@ietf.org >>> > >> > >>> > >> > The working group last call ends on April 8, 2011. >>> > >> > >>> > >> > /Loa >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> > _______________________________________________ >>> > >> > mpls mailing list >>> > >> > mpls@ietf.org >>> > >> > https://www.ietf.org/mailman/listinfo/mpls >>> > >> _______________________________________________ >>> > >> mpls mailing list >>> > >> mpls@ietf.org >>> > >> https://www.ietf.org/mailman/listinfo/mpls >>> > >_______________________________________________ >>> > >mpls mailing list >>> > >mpls@ietf.org >>> > >https://www.ietf.org/mailman/listinfo/mpls >>> > > >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> > From hideki.endo.es@hitachi.com Wed Mar 30 23:22:42 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B9B28C217 for ; Wed, 30 Mar 2011 23:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.433 X-Spam-Level: **** X-Spam-Status: No, score=4.433 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_BASE64_TEXT=1.753, SUBJ_RE_NUM=2.799] 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 h+7x7VoBj5aM for ; Wed, 30 Mar 2011 23:22:38 -0700 (PDT) Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by core3.amsl.com (Postfix) with ESMTP id CCD2228C1FE for ; Wed, 30 Mar 2011 23:22:37 -0700 (PDT) Received: from mlsv2.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 3912433CC8; Thu, 31 Mar 2011 15:24:16 +0900 (JST) Received: from mfilter1.hitachi.co.jp by mlsv2.hitachi.co.jp (8.13.1/8.13.1) id p2V6OGgx019370; Thu, 31 Mar 2011 15:24:16 +0900 Received: from hitachi.com (localhost.localdomain [127.0.0.1]) by mfilter1.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id p2V6Nxlx010661; Thu, 31 Mar 2011 15:24:16 +0900 Received: from vshuts2.hitachi.co.jp ([vshuts2.hitachi.co.jp [10.201.6.71]]) by mfilter1.hitachi.co.jp with RELAY id p2V6OEMM010774 ; Thu, 31 Mar 2011 15:24:16 +0900 X-AuditID: b753bd60-a314bba0000001d0-bc-4d941e0e17fe Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id B4F1F8B02CF; Thu, 31 Mar 2011 15:24:14 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p2V6OEi22155362; Thu, 31 Mar 2011 15:24:14 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: multipart/mixed; boundary="GMAILSMTPBOUND01110331152407" To: , , From: Date: Thu, 31 Mar 2011 15:23:46 +0900 References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.d> Priority: normal Importance: normal X400-Content-Identifier: X4D941DCC00000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28110331152308AAM] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Manuel.Paul@telekom.de, Rolf.Winter@neclab.eu Subject: Re: [mpls] =?iso-8859-1?q?Working_Group_LasCallondraft-ietf-mpls-tp-o?= =?iso-8859-1?q?n-demand-cv-?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 06:22:42 -0000 --GMAILSMTPBOUND01110331152407 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 SGkgRXJpYyBhbmQgU2FtLA0KDQpJJ20gc29ycnkgZm9yIG15IGluY29ycmVjdCB1bmRlcnN0 YW5kaW5nIG9uIERTTUFQIFRMVi4NCkFjY29yZGluZyB0byBTYW0sIFdlIGNhbiB1c2UgRFNN QVAgaW4gYm90aCBvZiBwaW5nIGFuZCB0cmFjZSByb3V0ZS4NCg0KSG93ZXZlciwgSSBoYXZl IGEgY29uY2Vybi4NCkVyaWMsIHlvdSBzYWlkOw0KPiAgICAgICAgUGluZyBtb2RlIHdvdWxk IGJlIHN0cmljdGx5IE1FUC10by1NRVAuICBBdCBsZWFzdCwgdGhhdA0KPmlzIHRoZSB3YXkg aXQgaXMgaW50ZW5kZWQgdG8gd29yayBpbiBvdXIgZHJhZnQuDQoNCk9uIHRoZSBvdGhlciBo YW5kLCBSRkM1ODYwLCBNUExTLVRQIE9BTSByZXFzLCBzYXlzOw0KMi4yLjMuICBDb25uZWN0 aXZpdHkgVmVyaWZpY2F0aW9ucw0KICAgPHNuaXBwZWQ+DQogICBUaGlzIGZ1bmN0aW9uIFNI T1VMRCBiZSBwZXJmb3JtZWQgb24tZGVtYW5kIGJldHdlZW4gRW5kIFBvaW50cyBhbmQNCiAg IEludGVybWVkaWF0ZSBQb2ludHMgb2YgUFdzIGFuZCBMU1BzLCBhbmQgYmV0d2VlbiBFbmQg UG9pbnRzIG9mIFBXcywNCiAgIExTUHMsIGFuZCBTZWN0aW9ucy4NCg0KYW5kOw0KDQoyLjIu NC4gIFJvdXRlIFRyYWNpbmcNCiAgIDxzbmlwcGVkPg0KICAgVGhpcyBmdW5jdGlvbiBTSE9V TEQgYmUgcGVyZm9ybWVkIG9uLWRlbWFuZC4NCg0KICAgVGhpcyBmdW5jdGlvbiBTSE9VTEQg YmUgcGVyZm9ybWVkIGJldHdlZW4gRW5kIFBvaW50cyBhbmQgSW50ZXJtZWRpYXRlDQogICBQ b2ludHMgb2YgUFdzIGFuZCBMU1BzLCBhbmQgYmV0d2VlbiBFbmQgUG9pbnRzIG9mIFBXcywg TFNQcywgYW5kDQogICBTZWN0aW9ucy4NCg0KV2h5IGRvIHlvdSByZXN0cmljdCBwaW5nIG1v ZGUgdG8gb25seSBmb3IgYmV0d2VlbiBNRVBzPw0KRG8geW91IG1lYW4gdGhhdCBPbi1kZW1h bmQgQ1YgZG9lc24ndCBzYXRpc2Z5IGFsbCBvZiBPQU0gcmVxcz8NCg0KQlIsDQpIaWRla2kN Cg0KPkhpZGVraSwNCj4NCj4gICAgICAgIFBpbmcgbW9kZSB3b3VsZCBiZSBzdHJpY3RseSBN RVAtdG8tTUVQLiAgQXQgbGVhc3QsIHRoYXQNCj5pcyB0aGUgd2F5IGl0IGlzIGludGVuZGVk IHRvIHdvcmsgaW4gb3VyIGRyYWZ0Lg0KPg0KPiAgICAgICAgV2h5IHdvdWxkIHlvdSBuZWVk IHBlci1pbnRlcmZhY2UgTUlQIGluZm9ybWF0aW9uIGluIHRoaXMNCj5jYXNlPw0KPg0KPiAg ICAgICAgSWYgc29tZW9uZSB3YW50ZWQgdG8gZG8gTFNQLVBpbmcgdG8gYSBzcGVjaWZpYyBp bnRlcmZhY2UsDQo+SSBhbSB1bmNlcnRhaW4gd2h5IGl0IHdvdWxkIGJlIGluY29ycmVjdCB0 byB1c2UgdGhlIERTTUFQIFRMVi4NCj4NCj4tLQ0KPkVyaWMNCj4NCj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPkZyb206IGhpZGVraS5lbmRvLmVzQGhpdGFjaGkuY29tIFttYWls dG86aGlkZWtpLmVuZG8uZXNAaGl0YWNoaS5jb21dDQo+U2VudDogV2VkbmVzZGF5LCBNYXJj aCAzMCwgMjAxMSA1OjQzIFBNDQo+VG86IEVyaWMgR3JheTsgbXBsc0BpZXRmLm9yZw0KPkNj OiBSb2xmLldpbnRlckBuZWNsYWIuZXU7IE1hbnVlbC5QYXVsQHRlbGVrb20uZGUNCj5TdWJq ZWN0OiBSZVsyXTogUmVbMl06IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsb25kcmFm dC1pZXRmLW1wbHMtdHAtb24tZGVtYW5kLWN2LTAzDQo+SW1wb3J0YW5jZTogSGlnaA0KPg0K PkVyaWMsDQo+DQo+SW4gbXkgdW5kZXJzdGFuZGluZywgRFNNQVAgVExWIGlzIG9ubHkgZm9y IHRyYWNlIHJvdXRlLCBpc24ndCBpdD8NCj5XZSBuZWVkIHNwZWNpZmljIGludGVyZmFjZSBp bmZvcm1hdGlvbiBmb3IgcGluZyBtb2RlIG9mIG9uLWRlbWFuZCBDVi4NCj4NCj5CUiwNCj5I aWRla2kNCj4NCj4+SGlkZWtpLA0KPj4NCj4+ICAgICAgICBJZiB5b3Ugd2FudCB0byBpbmNs dWRlIHNwZWNpZmljIGludGVyZmFjZSBpbmZvcm1hdGlvbiwNCj4+eW91IGNhbiBpbmNsdWRl IGEgRFNNQVAgKG9yIERETUFQKSBUTFYgYXMgZGVmaW5lZCBieSBSRkMNCj4+NDM3OSwgYW5k IGV4dGVuZGVkIGJ5IHRoaXMgZHJhZnQgKGluIGNvbWJpbmF0aW9uIHdpdGggdGhlDQo+PmRy YWZ0ICJkcmFmdC1pZXRmLW1wbHMtbHNwLXBpbmctZW5oYW5jZWQtZHNtYXAiIGZvciBERE1B UCkuDQo+Pg0KPj4gICAgICAgIFdvdWxkIHRoaXMgbm90IGRvIHdoYXQgeW91J3JlIGxvb2tp bmcgZm9yPw0KPj4NCj4+LS0NCj4+RXJpYw0KPj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+RnJvbTogaGlkZWtpLmVuZG8uZXNAaGl0YWNoaS5jb20gW21haWx0bzpoaWRl a2kuZW5kby5lc0BoaXRhY2hpLmNvbV0NCj4+U2VudDogV2VkbmVzZGF5LCBNYXJjaCAzMCwg MjAxMSAxMTozMyBBTQ0KPj5UbzogUm9sZi5XaW50ZXJAbmVjbGFiLmV1OyBFcmljIEdyYXk7 IG1wbHNAaWV0Zi5vcmc7IE1hbnVlbC5QYXVsQHRlbGVrb20uZGUNCj4+U3ViamVjdDogUmVb Ml06IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9uZHJhZnQtaWV0Zi1tcGxzLXRw LW9uLWRlbWFuZC1jdi0wMw0KPj5JbXBvcnRhbmNlOiBIaWdoDQo+Pg0KPj5IaSwNCj4+DQo+ PkkgaGF2ZSBvbmUgY29tbWVudCBvbiBJRHMgaW4gZHJhZnQtb24tZGVtYW5kLWN2Lg0KPj5U aGUgaW50ZXJmYWNlLUQgaXMgbWlzc2luZyBpbiB0aGUgY3VycmVudCBkcmFmdCwgdGhlcmUg aXMgb25seSBOb2RlLUlELg0KPj5Zb3UgbmVlZCBhdCBsZWFzdCB0aGUgaW50ZXJmYWNlIElE IHRvIHN1cHBvcnQgcGVyLWludGVyZmFjZSBNSVAuDQo+Pg0KPj5CUiwNCj4+SGlkZWtpDQo+ Pg0KPj4+DQo+Pj5EZWFyIEFsbCwNCj4+Pg0KPj4+SSByZWFsbHkgYXBwcmVjaWF0ZSB0aGUg Y29uc2lkZXJhdGlvbiBvbiB0aGUgcGVyLWludGVyZmFjZSBNSVAgc3VwcG9ydCBhbmQgdGhl IGRpc2N1c3Npb24gbW92aW5nIGZvcndhcmQuDQo+Pj4NCj4+Pg0KPj4+RnJvbSBhbiBvcGVy YXRvcidzIHBlcnNwZWN0aXZlLCBpdCBpcyB2ZXJ5IGltcG9ydGFudCB0aGF0IHRoZSBzdXBw b3J0IGZvciBwZXItaW50ZXJmYWNlIE1JUHMgaXMgY292ZXJlZCBieSB0aGUgZGVmaW5pdGlv bnMuDQo+Pj4NCj4+Pkxvb2tpbmcgYXQgZWFybGllciB2ZXJzaW9ucyBvZiBkcmFmdC1mYXJy ZWwtbXBscy10cC1taXAtbWVwLW1hcCwgdGhlcmUgd2FzIGFscmVhZHkgYSBzb2x1dGlvbiBw cm9wb3NhbCwgdXNpbmcgdGhlIFRUTC4gRW5oYW5jZWQgc29sdXRpb25zIGhhdmUgYmVlbiB0 aG9yb3VnbHkgZGlzY3Vzc2VkIGR1cmluZyB0aGlzIElFVEYgbWVldGluZy4gSXQgaXQgdG8g YmUgZXhwZWN0ZWQgdGhhdCB0aGVyZSB3aWxsIGJlIHdheXMgdG8gc29sdmUgYm90aCB0aGUg ZmFzdCBwYXRoIGFuZCBmYXRlLXNoYXJpbmcgcmVxdWlyZW1lbnQuDQo+Pj4NCj4+Pg0KPj4+ SSBzZWNvbmQgdGhlIHByb3Bvc2FsIGluaXRpYWxseSBtYWRlIGJ5IFJvbGYsIHRvIGluY2x1 ZGUgYWRkaXRpb25hbCB0ZXh0IHRvIGRvY3VtZW50IHRoZSBwZXItaW50ZXJmYWNlIE1JUCBh ZGRyZXNzaW5nIGZvciB0aGUgb24tZGVtYW5kLWN2IGFuZCBmb3Igb3RoZXIgT0FNIHRvb2xz Lg0KPj4+DQo+Pj4NCj4+PkJlc3QgcmVnYXJkcywNCj4+Pk1hbnVlbA0KPj4+DQo+Pj4NCj4+ PkRldXRzY2hlIFRlbGVrb20gQUcNCj4+Pkdyb3VwIFRlY2hub2xvZ3kNCj4+Pk1hbnVlbCBQ YXVsDQo+Pj5TQTMtMTENCj4+Pkdvc2xhcmVyIFVmZXIgMzUtMzcsIDEwNTg5IEJlcmxpbg0K Pj4+KzQ5IDMwIDM0OTcgLSA0Mzk0IChUZWwuKQ0KPj4+KzQ5IDMwIDM0OTcgLSA0OTU2IChG YXgpDQo+Pj4rNDkgMTcxICA4NjM0MDMyIChNb2JpbCkNCj4+PkUtTWFpbDogbWFpbHRvOm1h bnVlbC5wYXVsQHRlbGVrb20uZGUNCj4+Pmh0dHA6Ly93d3cudGVsZWtvbS5jb20NCj4+Pg0K Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBtcGxzLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP Zg0KPj4+PiBSb2xmIFdpbnRlcg0KPj4+PiBTZW50OiBNb25kYXksIE1hcmNoIDI4LCAyMDEx IDM6MDMgUE0NCj4+Pj4gVG86IEVyaWMgR3JheTsgaGlkZWtpLmVuZG8uZXNAaGl0YWNoaS5j b20NCj4+Pj4gQ2M6IG1wbHNAaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogUmU6IFttcGxzXSBX b3JraW5nIEdyb3VwIExhcyBDYWxsIG9uZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLWRlbWFuZC0N Cj4+Pj4gY3YtMDMNCj4+Pj4NCj4+Pj4gRXJpYywNCj4+Pj4NCj4+Pj4gSSBnZW5lcmFsbHkg YWdyZWUgYnV0IEkgdGhpbmsgdGhlcmUgaXMgb25lIGNhc2UgYWN0dWFsbHkgd2hpY2ggbmVl ZHMgYQ0KPj4+PiBjbG9zZXIgbG9vayBpbiB0aGlzIHJlZ2FyZCAod2hpY2ggSSBoaW50ZWQg YXQgZWFybGllciksIHdoaWNoIGFyZSB0aGUgcGVyLQ0KPj4+PiBpbnRlcmZhY2UgTUlQcy4g WW91ciBUVEwgZXhwaXJlcyAodGhlIGFjdHVhbCBhZGRyZXNzaW5nIGJpdCBoZXJlKSwgdGhl DQo+Pj4+IGlkZW50aWZpZXIgdGVsbHMgeW91IGl0IGlzIG5vdCBpbnRlbmRlZCBmb3IgdGhl IGluZ3Jlc3MgTUlQLCBzbyBpdCBuZWVkcw0KPj4+PiB0byBiZSBmb3J3YXJkZWQgdG8gdGhl IGVncmVzcyBNSVAgdGhyb3VnaCB0aGUgZm9yd2FyZGluZyBlbmdpbmUuIE5vdyBpZg0KPj4+ PiB5b3UgcHVsbCB0aGUgcGFja2V0IG91dCBvZiB0aGUgZmFzdCBwYXRoIGFuZCBpbmplY3Qg aXQgYmFjayBpbiwgaXMgdGhlIE9BTQ0KPj4+PiBwYWNrZXQgc3RpbGwgZmF0ZSBzaGFyaW5n PyBJZiB5b3UgY2FuIGRvIHRoaXMgaW4gSFcgb24gdGhlIGxpbmUgY2FyZCwgdGhlbg0KPj4+ PiBpdCB3aWxsIGFuZCBpdCB3aWxsIGp1c3QgYmUgZm9yd2FyZGVkIGFzIG5vcm1hbC4gSSBr bm93IHRoaXMgaXMgYQ0KPj4+PiBkaWZmZXJlbnQgZHJhZnQsIGJ1dCB0aGlzIHdpbGwgYmUg aW4gcGFydGljdWxhciBpbXBvcnRhbnQgZm9yIHBlcmZvcm1hbmNlDQo+Pj4+IG1vbml0b3Jp bmcuDQo+Pj4+DQo+Pj4+IEJlc3QsDQo+Pj4+DQo+Pj4+IFJvbGYNCj4+Pj4NCj4+Pj4NCj4+ Pj4NCj4+Pj4gTkVDIEV1cm9wZSBMaW1pdGVkIHwgUmVnaXN0ZXJlZCBPZmZpY2U6IE5FQyBI b3VzZSwgMSBWaWN0b3JpYSBSb2FkLCBMb25kb24NCj4+Pj4gVzMgNkJMIHwgUmVnaXN0ZXJl ZCBpbiBFbmdsYW5kIDI4MzIwMTQNCj4+Pj4NCj4+Pj4NCj4+Pj4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+PiA+IEZyb206IEVyaWMgR3JheSBbbWFpbHRvOmVyaWMuZ3Jh eUBlcmljc3Nvbi5jb21dDQo+Pj4+ID4gU2VudDogTW9udGFnLCAyOC4gTeRyeiAyMDExIDE0 OjQ1DQo+Pj4+ID4gVG86IGhpZGVraS5lbmRvLmVzQGhpdGFjaGkuY29tOyBSb2xmIFdpbnRl cg0KPj4+PiA+IENjOiBtcGxzQGlldGYub3JnDQo+Pj4+ID4gU3ViamVjdDogUkU6IFJlWzJd OiBbbXBsc10gV29ya2luZyBHcm91cCBMYXMgQ2FsbCBvbmRyYWZ0LWlldGYtbXBscy10cC0N Cj4+Pj4gPiBvbi1kZW1hbmQtY3YtMDMNCj4+Pj4gPg0KPj4+PiA+IEhpZGVraSwNCj4+Pj4g Pg0KPj4+PiA+ICAgIFdoYXQgeW91J3JlIHNheWluZyBpcyB0cnVlLCBidXQgbm90IHJlbGV2 YW50IGluIHRoaXMNCj4+Pj4gPiBjYXNlLiAgVGhlICJhZGRyZXNzZXMiIGluIHRoaXMgZGlz Y3Vzc2lvbiBhcmUgbm90IHVzZWQgdG8NCj4+Pj4gPiBkZXRlcm1pbmUgaG93IHRvIGZvcndh cmQgT0FNIHBhY2tldHMuICBUaGV5IGFyZSB1c2VkIG9ubHkNCj4+Pj4gPiBieSB0aGUgcmVj aXBpZW50IE1JUC9NRVAgdG8gdmVyaWZ5IHRoYXQgdGhlIE9BTSBwYWNrZXQgd2FzDQo+Pj4+ ID4gcHJvcGVybHkgZGVsaXZlcmVkLg0KPj4+PiA+DQo+Pj4+ID4gICAgQnkgdGhlIHdheSwg dGhpcyBkaXNjdXNzaW9uIGlzIGFuIGluZGljYXRpb24gb2YgdGhlDQo+Pj4+ID4gY29uZnVz aW5nIGluamVjdGVkIGJ5IGNhbGxpbmcgdGhlc2UgdGhpbmdzIGFkZHJlc3Nlcy4gIE15DQo+ Pj4+ID4gbWlzdGFrZSBhbmQgSSBicmluZyBpdCB1cCBub3cgdG8gaGVscCB0byBzdGVtIHRo ZSB0aWRlIG9mDQo+Pj4+ID4gZnVydGhlciBjb21tZW50cyByZXN1bHRpbmcgZnJvbSB0aGF0 IGNvbmZ1c2lvbi4NCj4+Pj4gPg0KPj4+PiA+ICAgIEluIHRoZSB2ZXJzaW9uIHdlIHBvc3Qg YWZ0ZXIgbGFzdCBjYWxsIGlzIGNvbXBsZXRlLA0KPj4+PiA+IHdlIHdpbGwgYmUgY2hhbmdp bmcgdGhlIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gImFkZHJlc3MiDQo+Pj4+ID4gVExWcyB0 byBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uICJpZGVudGlmaWVyIiBUTFZzLg0KPj4+PiA+DQo+ Pj4+ID4gICAgV2Ugd2lsbCBhbHNvIGJlIGNvcnJlY3RpbmcgdGhlIHJlZmVyZW5jZSB0byBE U01BUCwNCj4+Pj4gPiBhbmQgRERNQVAsIGFkZHJlc3MgVExWcyAod2hpY2ggaXMgaW5jb3Jy ZWN0LCBiZWNhdXNlIHRoZQ0KPj4+PiA+IGZvcm1hdCBmb3IgRFNNQVAvRERNQVAgZG9lc24n dCBpbmNsdWRlIGEgImxlbmd0aCIgZmllbGQpLg0KPj4+PiA+DQo+Pj4+ID4gICAgVGhlIGZv cm1hdCBvZiB0aGUgRG93bnN0cmVhbSBNYXBwaW5nIChEU01BUCkgVExWIGlzDQo+Pj4+ID4g ZGVmaW5lZCBpbiBSRkMgNDM3OSwgYW5kIHdlIGFyZSBub3QgY2hhbmdpbmcgdGhlIGZvcm1h dA0KPj4+PiA+IG9mIHRoYXQgVExWLg0KPj4+PiA+DQo+Pj4+ID4gICAgVGhlc2UgY2hhbmdl cyBhcmUgZHJpdmVuIGJ5IGxhc3QgY2FsbCBjb21tZW50cyB3ZQ0KPj4+PiA+IGhhdmUgYWxy ZWFkeSByZWNlaXZlZCAoc2VlIEpvZWwgSGFscGVybidzIGNvbW1lbnRzIG9uIHRoZQ0KPj4+ PiA+IG1haWxpbmcgbGlzdCkgYW5kIGFyZSAtIGluIHBhcnQgLSB0byBjb3JyZWN0IGFjY2lk ZW50YWwNCj4+Pj4gPiB1c2Ugb2YgdGhlIHdvcmQgImFkZHJlc3MiIGZvciBzb3VyY2UgYW5k IGRlc3RpbmF0aW9uDQo+Pj4+ID4gaWRlbnRpZmllciBUTFZzICh3aGljaCBpcyB3aGF0IHdl IGhhZCBkaXNjdXNzZWQgYmVmb3JlDQo+Pj4+ID4gSSBnZW5lcmF0ZWQgdGhlIC0wMyB2ZXJz aW9uIGFtb25nIHRoZSBhdXRob3JzIG9mIHNldmVyYWwNCj4+Pj4gPiBvZiB0aGUgY3VycmVu dCBzZXQgb2YgTVBMUy1UUCBkcmFmdHMpLg0KPj4+PiA+DQo+Pj4+ID4gICAgSW4gdGhlIGNh c2Ugb2Ygc291cmNlIGFuZCBkZXN0aW5hdGlvbiBpZGVudGlmaWVycywNCj4+Pj4gPiB0aGVz ZSB3aWxsIGJlIHVzZWQgZXhjbHVzaXZlbHkgdG8gdmVyaWZ5IHRoYXQgYW4gT0FNIFBEVQ0K Pj4+PiA+IGhhcyBiZWVuIGNvcnJlY3RseSByZWNlaXZlZCBieSBpdHMgaW50ZW5kZWQgcmVj aXBpZW50Lg0KPj4+PiA+IEJlY2F1c2UgdGhpcyBpcyBhbiBvbi1kZW1hbmQgY29ubmVjdGl2 aXR5IHZlcmlmaWNhdGlvbg0KPj4+PiA+IHByb3RvY29sLCB0aGF0IGlzIGV4cGVjdGVkIHRv IGJlIHVzZWQgb25seSBvbiB0aG9zZQ0KPj4+PiA+IG9jY2FzaW9ucyB3aGVuIHRoZXJlIGlz IGEgbmV0d29yayBwcm9ibGVtIHRoYXQgbmVlZHMgdG8NCj4+Pj4gPiBiZSBkaWFnbm9zZWQs IGFuZCB0aGUgaW5mb3JtYXRpb24gaXMgbm90IHNlZW4gKGFuZCBub3QNCj4+Pj4gPiB2aXNp YmxlIC0gd2l0aG91dCBsYXllciB2aW9sYXRpb25zKSwgb3B0aW1pemluZyB0aGVzZQ0KPj4+ PiA+IG9iamVjdHMgZm9yIHNvZnR3YXJlIG1ha2VzIHNlbnNlLg0KPj4+PiA+DQo+Pj4+ID4g ICAgSW4gYWRkaXRpb24sIHNpbmNlIGVpdGhlciBtYXkgYmUgaW5jbHVkZWQgKHdoaWNoDQo+ Pj4+ID4gaW5jbHVkZXMgdGhlIHBvc3NpYmlsaXR5IG9mIGluY2x1ZGluZyBib3RoKSwgaXQg aXMgdGhlDQo+Pj4+ID4gY2FzZSBhbHJlYWR5IHRoYXQgd2Ugd291bGQgdGhlbiBuZWVkIHRv IGRlY2lkZSB3aGljaCBpcw0KPj4+PiA+IHRvIGdvIGZpcnN0IC0gYXNzdW1pbmcgd2Ugd2Fu dGVkIHRvIGRvIHRoaXMgKHdoaWNoIHdlDQo+Pj4+ID4gZG8gbm90KS4NCj4+Pj4gPg0KPj4+ PiA+IC0tDQo+Pj4+ID4gRXJpYw0KPj4+PiA+DQo+Pj4+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+Pj4gPiBGcm9tOiBoaWRla2kuZW5kby5lc0BoaXRhY2hpLmNvbSBbbWFp bHRvOmhpZGVraS5lbmRvLmVzQGhpdGFjaGkuY29tXQ0KPj4+PiA+IFNlbnQ6IE1vbmRheSwg TWFyY2ggMjgsIDIwMTEgODoxMSBBTQ0KPj4+PiA+IFRvOiBFcmljIEdyYXk7IFJvbGYuV2lu dGVyQG5lY2xhYi5ldQ0KPj4+PiA+IENjOiBtcGxzQGlldGYub3JnDQo+Pj4+ID4gU3ViamVj dDogUmVbMl06IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9uZHJhZnQtaWV0Zi1t cGxzLXRwLW9uLQ0KPj4+PiA+IGRlbWFuZC1jdi0wMw0KPj4+PiA+IEltcG9ydGFuY2U6IEhp Z2gNCj4+Pj4gPg0KPj4+PiA+IEhpIEVyaWMgYW5kIFJvbGYsDQo+Pj4+ID4NCj4+Pj4gPiBJ J20gc29ycnkgZm9yIGludGVycnVwdGluZy4NCj4+Pj4gPg0KPj4+PiA+IEkgYWdyZWUgd2l0 aCBSb2xmIHJlZ2FyZGluZyB0aGUgcGVyLWludGVyZmFjZSBNSVAgZGlzY3Vzc2lvbi4NCj4+ Pj4gPiBXZSBoYXZlIHRvIGNvbnNpZGVyIHRoZSBIVyBpbXBsZW1lbnRhdGlvbiBhc3BlY3Qs DQo+Pj4+ID4gYmVjYXVzZSB0cmFwcGluZyBvZiBhbiBPQU0gcGFja2V0IGlzIEhXIHJ1bGUv ZnVuY3Rpb25hbGl0eSBldmVuIGluDQo+Pj4+ID4gcm91dGVycy4NCj4+Pj4gPg0KPj4+PiA+ IElmIGV2ZXJ5IE9BTSBwYWNrZXQgaXMgdHJhcHBlZCB0byBDUFUNCj4+Pj4gPiBhbmQgdGhl IE9BTSBwYWNrZXRzIHdoaWNoIHNob3VsZCBOT1QgYmUgcHJvY2Vzc2VkIGluIHRoZSBJbnRl cmZhY2UNCj4+Pj4gPiBhcmUgcmV0dXJuZWQgdG8gRGF0YS1wbGFuZSwNCj4+Pj4gPiBpdCBp cyBkaWZmZXJlbnQgZm9yd2FyZGluZyBwYXRoIGZyb20gdXNlciBwYWNrZXRzLA0KPj4+PiA+ IHdoaWNoIGlzIE5PVCB0aGUgQ29ubmVjdGl2aXR5IFZlcmlmaWNhdGlvbiBvZiB0aGUgdXNl ciBwYXRoLg0KPj4+PiA+DQo+Pj4+ID4gVGhlcmVmb3JlLCB3ZSBzaG91bGQgdGFrZSB0aGUg SFcgYXNwZWN0IGFuZCBmbGV4aWJpbHR5IGludG8gYWNjb3VudA0KPj4+PiA+IGNvbmN1cnJl bnRseS4NCj4+Pj4gPiBJZiBhbiBhZGRyZXNzIFRMViBNVVNUIGJlIHRoZSBmaXJzdCBpbiBU TFZzLA0KPj4+PiA+IGl0IGlzIGVub3VnaCB0byBtYWtlIEhXIGltcGxlbWVudGF0aW9uIGVh c3kuDQo+Pj4+ID4NCj4+Pj4gPiBCUiwNCj4+Pj4gPiBIaWRla2kNCj4+Pj4gPg0KPj4+PiA+ DQo+Pj4+ID4NCj4+Pj4gPiA+Um9sZiwNCj4+Pj4gPiA+DQo+Pj4+ID4gPiAgVGhlIHdvcmRz IHlvdSBwcm9wb3NlIGFyZSBva2F5IHdpdGggbWUuDQo+Pj4+ID4gPg0KPj4+PiA+ID4gIEkg dGhvdWdodCB0aGUgTUlQL2ludGVyZmFjZSBhbmQgYWRkcmVzcyBsb2NhdGlvbiBpc3N1ZXMN Cj4+Pj4gPiA+d2VyZSBzZXBhcmF0ZS4NCj4+Pj4gPiA+DQo+Pj4+ID4gPiAgSSd2ZSBwZXJz b25hbGx5IGhhZCBwcm9ibGVtcyB3aXRoIHByb3RvY29sIHNwZWNpZmljYXRpb25zDQo+Pj4+ ID4gPnRoYXQgcmVxdWlyZSBvcmRlcmluZyBvZiBUTFZzLiAgSW4gcGFydGljdWxhciwgdGhp cyBpcyBub3QgdmVyeQ0KPj4+PiA+ID5yb2J1c3QgaW4gdGVybXMgb2YgImZ1dHVyZS1wcm9v ZmluZy4iICBXaGF0IGhhcHBlbnMgaWYgbmV3IFRMVnMNCj4+Pj4gPiA+YXJlIGFkZGVkIGxh dGVyIG9uOyBmb3IgaW5zdGFuY2UsIHN1cHBvc2UgYXQgc29tZSBwb2ludCB3ZSBoYXZlDQo+ Pj4+ID4gPm11bHRpcGxlICJhZGRyZXNzIiBUTFZzPw0KPj4+PiA+ID4NCj4+Pj4gPiA+ICBB bHNvLCB0aGUgZmFjdCB0aGF0IGltcGxlbWVudGF0aW9ucyBhcmUgYWxsb3dlZCB0byBhdHRh Y2gNCj4+Pj4gPiA+VExWcyBpbiBhbnkgYXJiaXRyYXJ5IG9yZGVyIGFsbG93cyBjb25zaWRl cmFibGUgZmxleGliaWx0eSBpbg0KPj4+PiA+ID5pbXBsZW1lbnRhdGlvbi4gIE1lc3NhZ2Vz IGNhbiBiZSBidWlsdCBpbiBhcmJpdHJhcmlseSBtYW55IHdheXMuDQo+Pj4+ID4gPlRoaXMg dG9vIGNhbiBiZSBhIGZ1dHVyZS1wcm9vZmluZyBpc3N1ZS4NCj4+Pj4gPiA+DQo+Pj4+ID4g PiAgSSB3b3VsZCBwcmVmZXIgbm90IHRvIHN0YXJ0IGRvd24gdGhlIHJvYWQgb2YgcmVxdWly aW5nIGENCj4+Pj4gPiA+c3Vic2V0IG9mIFRMVnMgdG8gYXBwZWFyIGluIGEgY2VydGFpbiBv cmRlciwgYW5kIHNheWluZyB3ZSBoYXZlDQo+Pj4+ID4gPm9uZSBUTFYgdGhhdCBuZWVkcyB0 byBiZSBmaXJzdCBpcyBkb2luZyBqdXN0IHRoYXQuDQo+Pj4+ID4gPg0KPj4+PiA+ID4tLQ0K Pj4+PiA+ID5FcmljDQo+Pj4+ID4gPg0KPj4+PiA+ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj4+PiA+ID5Gcm9tOiBSb2xmIFdpbnRlciBbbWFpbHRvOlJvbGYuV2ludGVyQG5l Y2xhYi5ldV0NCj4+Pj4gPiA+U2VudDogTW9uZGF5LCBNYXJjaCAyOCwgMjAxMSA2OjE5IEFN DQo+Pj4+ID4gPlRvOiBFcmljIEdyYXkNCj4+Pj4gPiA+Q2M6IG1wbHNAaWV0Zi5vcmcNCj4+ Pj4gPiA+U3ViamVjdDogUkU6IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9uIGRy YWZ0LWlldGYtbXBscy10cC1vbi0NCj4+Pj4gPiBkZW1hbmQtY3YtMDMNCj4+Pj4gPiA+SW1w b3J0YW5jZTogSGlnaA0KPj4+PiA+ID4NCj4+Pj4gPiA+SGksDQo+Pj4+ID4gPg0KPj4+PiA+ ID5JIHN0aWxsIHRoaW5rIHRoZXJlIGlzIGEgbG9naWNhbCBlcnJvci4gTGV0IG1lIGV4cGxh aW4uIEluIGNhc2UgdGhlcmUNCj4+Pj4gPiBpcyBubyBJUCB5b3Ugc2ltcGx5IGNhbm5vdCB1 c2UgaXQuIFlvdSBzYXkgeW91IGNvdWxkIGVuYWJsZSBJUCBidXQgdGhlbg0KPj4+PiA+IHRo YXQgaXMgbm90IGEgY2FzZSB3aGVyZSB0aGVyZSBpcyBubyBJUC4gSW4gb3JkZXIgdG8gYmUg Y29uc3RydWN0aXZlDQo+Pj4+ID4gaGVyZSBpcyBhIHRleHQgY2hhbmdlIHN1Z2dlc3Rpb246 DQo+Pj4+ID4gPg0KPj4+PiA+ID4iSW4gY2VydGFpbiBNUExTLVRQIGRlcGxveW1lbnQgc2Nl bmFyaW9zIElQIGFkZHJlc3NpbmcgbWlnaHQgbm90IGJlDQo+Pj4+ID4gYXZhaWxhYmxlLiBJ biB0aG9zZSBjYXNlcyBPbi1kZW1hbmQgQ1YgYW5kL29yIHJvdXRlIHRyYWNpbmcgTVVTVCBi ZSBydW4NCj4+Pj4gPiB3aXRob3V0IElQIGFkZHJlc3NpbmcsIHVzaW5nIHRoZSBBQ0ggY2hh bm5lbCB0eXBlIHNwZWNpZmllZCBpbiBTZWN0aW9uDQo+Pj4+ID4gMy4gSW4gb3RoZXIgY2Fz ZXMgaXQgbWlnaHQgYmUgYXZhaWxhYmxlLCBob3dldmVyLCBpdCBtYXkgYmUgcHJlZmVycmVk DQo+Pj4+ID4gdG8gdXNlIHNvbWUgZm9ybSBvZiBub24tSVAgZW5jYXBzdWxhdGlvbi4gSW4g dGhvc2UgY2FzZXMsIHRoZQ0KPj4+PiA+IHByb2NlZHVyZXMgYXMgb3V0bGluZWQgaW4gc2Vj dGlvbiAzIFNIT1VMRCBhbHNvIGJlIHVzZWQuIg0KPj4+PiA+ID4NCj4+Pj4gPiA+UmVnYXJk aW5nIHRoZSBwZXItaW50ZXJmYWNlIE1JUCBkaXNjdXNzaW9uLiBUaGUgSFcgYXNwZWN0IGFs c28gcG9wcGVkDQo+Pj4+ID4gdXAgaW4gdGhlIFBXRTMgc2Vzc2lvbiBhbmQgSSB0aGluayB0 aGlzIGlzIGFuIGltcG9ydGFudCBjb25zaWRlcmF0aW9uLA0KPj4+PiA+IGluIHBhcnRpY3Vs YXIgZm9yIE9BTS4gRXZlbiBpZiB3ZSB0YWxrIGFib3V0IFRMVnMsIHdlIGNvdWxkIG1ha2Ug aXQgYQ0KPj4+PiA+IE1VU1QgdGhhdCBhbiBBZGRyZXNzIFRMViBpcyBhbHdheXMgdGhlIGZp cnN0IG9uZSB0byBhcHBlYXIuIElmIHlvdSBjYW4NCj4+Pj4gPiBmYWNpbGl0YXRlIGFuIGVh c3kgaW1wbGVtZW50YXRpb24gaW4gaGFyZHdhcmUsIEkgc2VlIG5vIHJlYXNvbiB0bw0KPj4+ PiA+IGRlbGliZXJhdGVseSBub3QgZG8gaXQuDQo+Pj4+ID4gPg0KPj4+PiA+ID5CZXN0LA0K Pj4+PiA+ID4NCj4+Pj4gPiA+Um9sZg0KPj4+PiA+ID4NCj4+Pj4gPiA+DQo+Pj4+ID4gPk5F QyBFdXJvcGUgTGltaXRlZCB8IFJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2UsIDEgVmlj dG9yaWEgUm9hZCwNCj4+Pj4gPiBMb25kb24gVzMgNkJMIHwgUmVnaXN0ZXJlZCBpbiBFbmds YW5kIDI4MzIwMTQNCj4+Pj4gPiA+DQo+Pj4+ID4gPg0KPj4+PiA+ID4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj4+ID4gPj4gRnJvbTogRXJpYyBHcmF5IFttYWlsdG86ZXJp Yy5ncmF5QGVyaWNzc29uLmNvbV0NCj4+Pj4gPiA+PiBTZW50OiBNb250YWcsIDI4LiBN5HJ6 IDIwMTEgMTE6NDMNCj4+Pj4gPiA+PiBUbzogUm9sZiBXaW50ZXINCj4+Pj4gPiA+PiBDYzog bG9hQHBpLm51OyBtcGxzQGlldGYub3JnDQo+Pj4+ID4gPj4gU3ViamVjdDogUkU6IFttcGxz XSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1vbi0NCj4+ Pj4gPiA+PiBkZW1hbmQtY3YtMDMNCj4+Pj4gPiA+Pg0KPj4+PiA+ID4+IFJvbGYsDQo+Pj4+ ID4gPj4NCj4+Pj4gPiA+PiAgICAgICAgIFdpdGggcmVnYXJkIHRvIHRoZSB1c2Ugb2YgU0hP VUxEICh2ZXJzZXMgTVVTVCkgLSB0aGUgaW50ZW50DQo+Pj4+ID4gPj4gKGFjY29yZGluZyB0 byBSRkMgMjExOSAtIHNlZSB0aGUgcXVvdGUgYmVsb3cpIGlzIGNvbnNpc3RlbnQgd2l0aA0K Pj4+PiA+ID4+IHRoaXMgY2FzZS4gIElmIC0gZm9yIHNvbWUgcmVhc29uIC0gb25lIGhhZCBh IHJlYWxseSBnb29kIHJlYXNvbiB0bw0KPj4+PiA+ID4+IHVzZSBJUCBhZGRyZXNzaW5nIGlu IHNvbWUgc3BlY2lmaWMgY2FzZSwgb25lIGNvdWxkIHRha2Ugc3RlcHMgdG8NCj4+Pj4gPiA+ PiBtYWtlIElQIGFkZHJlc3NpbmcgYXZhaWxhYmxlLg0KPj4+PiA+ID4+DQo+Pj4+ID4gPj4g ICAgICAgICBUaGlzIGNvdWxkIGJlIHNhaWQgdG8gaW50cm9kdWNlIGEgbG9naWNhbCBkaXNj b25uZWN0LCBidXQgd2UNCj4+Pj4gPiA+PiBhcmUgc2F2ZWQgZnJvbSBnb2luZyBkb3duIHRo YXQgcGF0aCBieSB0aGUgZmFjdCB0aGF0IHRoZSBzdGF0ZW1lbnQNCj4+Pj4gPiA+PiBhbHNv IGluY2x1ZGVzIHRoZSBjYXNlIHdoZXJlIChmb3Igc29tZSByZWFzb24pIHRoZXJlIGlzIGEg Y2FzZSBpbg0KPj4+PiA+ID4+IHdoaWNoIHNvbWUgb3RoZXIgYWRkcmVzc2luZyBzY2hlbWUg bWlnaHQgYmUgcHJlZmVycmVkLiAgSW4gbWFueSBvZg0KPj4+PiA+ID4+IHRoZSBjYXNlcyB3 aGVyZSBhbm90aGVyIGFkZHJlc3Npbmcgc2NoZW1lIG1heSBiZSBwcmVmZXJyZWQsIGl0IGlz DQo+Pj4+ID4gPj4gc3RpbGwgcG9zc2libGUgKGluIGZhY3QgbGlrZWx5KSB0aGF0IElQIGFk ZHJlc3NpbmcgaXMgYXZhaWxhYmxlLg0KPj4+PiA+ID4+DQo+Pj4+ID4gPj4gICAgICAgICBP dGhlcndpc2UsIGl0IHdvdWxkIG5vdCBoYXZlIGJlZW4gbmVjZXNzYXJ5IHRvIGRpc3Rpbmd1 aXNoDQo+Pj4+ID4gPj4gdGhpcyBjYXNlIGZyb20gdGhlIG9uZSBpbiB3aGljaCBJUCBhZGRy ZXNzaW5nIGlzIG5vdCBhdmFpbGFibGUuDQo+Pj4+ID4gPj4NCj4+Pj4gPiA+PiAgICAgICAg IEZvciB0aGUgY2FzZSB3aGVyZSBJUCBhZGRyZXNzaW5nIGlzIG5vdCB0aGUgcHJlZmVycmVk IG1vZGUsDQo+Pj4+ID4gPj4gd2UgYXJlIHJlY29tbWVuZGluZyBhIG1vZGUgaW4gd2hpY2gg aXQgaXMgbm90IG5lY2Vzc2FyeS4NCj4+Pj4gPiA+Pg0KPj4+PiA+ID4+ICAgICAgICAgV2l0 aCByZWdhcmQgdG8gaGF2aW5nIGFkZHJlc3NlcyBsb2NhdGVkIGluIHRoZSBzYW1lIHBsYWNl LA0KPj4+PiA+ID4+IHRoaXMgcHJvdG9jb2wgaXMgbWVhbnQgZm9yIGNvbm5lY3Rpdml0eSB0 ZXN0aW5nIG9uIGFuIG9uLWRlbWFuZA0KPj4+PiA+ID4+IGJhc2lzIGFuZCBpcyB0aGVyZWZv cmUgbm90IG9wdGltaXplZCBmb3IgcHJvY2Vzc2luZyBpbiBoYXJkd2FyZS4NCj4+Pj4gPiA+ Pg0KPj4+PiA+ID4+ICAgICAgICAgV2hldGhlciBhZGRyZXNzZXMgb3IgaWRlbnRpZmllcnMs IGlmIHdlIGFyZSB0YWxraW5nIGFib3V0DQo+Pj4+ID4gPj4gVExWIGNvbnRlbnRzLCB0aGVy ZSBhcmUgaXNzdWVzIHdpdGggdHJ5aW5nIHRvIGd1YXJhbnRlZSBsb2NhdGlvbg0KPj4+PiA+ ID4+IG9mIHNwZWNpZmljIGNvbnRlbnQsIGJlY2F1c2Ugb2YgdGhlIGZhY3QgdGhhdCB0aGUg VExWIGluIHF1ZXN0aW9uDQo+Pj4+ID4gPj4gd2lsbCBwcm9iYWJseSBmb2xsb3cgb3RoZXIg VExWcyAtIHRodXMgbWFraW5nIGxvY2F0aW9ucyBkaWZmaWN1bHQNCj4+Pj4gPiA+PiB0byBw cmVkaWN0IGluIGFueSBjYXNlLg0KPj4+PiA+ID4+DQo+Pj4+ID4gPj4gICAgICAgICBXaXRo IHJlZ2FyZCB0byBuZWVkaW5nIG1vcmUgdGV4dCBvbiBwZXItaW50ZXJmYWNlIE1JUHMsIGRv DQo+Pj4+ID4gPj4geW91IGhhdmUgc3BlY2lmaWMgc3VnZ2VzdGlvbnMgYXMgdG8gd2hhdCB0 ZXh0IHdlIG1pZ2h0IGFkZD8NCj4+Pj4gPiA+Pg0KPj4+PiA+ID4+ICAgICAgICAgSSB1bmRl cnN0YW5kIChmcm9tIGRpc2N1c3Npb24gd2l0aCBXRyBjaGFpcnMpIHRoYXQgd2UgYXJlDQo+ Pj4+ID4gPj4gbm90IGFsbG93ZWQgdG8gZXhwbGljaXRseSBhZGRyZXNzIGxhc3QgY2FsbCBj b21tZW50cyBkdXJpbmcgdGhlDQo+Pj4+ID4gPj4gSUVURiBtZWV0aW5nIGluIFByYWd1ZSwg YmVjYXVzZSB0aGUgbGFzdCBjYWxsIGlzIHN0aWxsIG9uZ29pbmcNCj4+Pj4gPiA+PiBhdCB0 aGF0IHRpbWUuDQo+Pj4+ID4gPj4NCj4+Pj4gPiA+PiAtLQ0KPj4+PiA+ID4+IEVyaWMNCj4+ Pj4gPiA+Pg0KPj4+PiA+ID4+IFBTIC0NCj4+Pj4gPiA+PiBGcm9tIFJGQyAyMTE5IC0NCj4+ Pj4gPiA+PiAnU0hPVUxEICAgVGhpcyB3b3JkLCBvciB0aGUgYWRqZWN0aXZlICJSRUNPTU1F TkRFRCIsIG1lYW4gdGhhdCB0aGVyZQ0KPj4+PiA+ID4+ICAgICAgICAgICBtYXkgZXhpc3Qg dmFsaWQgcmVhc29ucyBpbiBwYXJ0aWN1bGFyIGNpcmN1bXN0YW5jZXMgdG8NCj4+Pj4gPiA+ PiAgICAgICAgICAgaWdub3JlIGEgcGFydGljdWxhciBpdGVtLCBidXQgdGhlIGZ1bGwgaW1w bGljYXRpb25zIG11c3QNCj4+Pj4gPiA+PiAgICAgICAgICAgYmUgdW5kZXJzdG9vZCBhbmQg Y2FyZWZ1bGx5IHdlaWdoZWQgYmVmb3JlIGNob29zaW5nIGENCj4+Pj4gPiA+PiAgICAgICAg ICAgZGlmZmVyZW50IGNvdXJzZS4nDQo+Pj4+ID4gPj4NCj4+Pj4gPiA+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiA+ID4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+Pj4+ID4gT2YN Cj4+Pj4gPiA+PiBSb2xmIFdpbnRlcg0KPj4+PiA+ID4+IFNlbnQ6IFR1ZXNkYXksIE1hcmNo IDIyLCAyMDExIDQ6NTcgQU0NCj4+Pj4gPiA+PiBUbzogbG9hQHBpLm51OyBtcGxzQGlldGYu b3JnDQo+Pj4+ID4gPj4gU3ViamVjdDogUmU6IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBD YWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1vbi0NCj4+Pj4gPiA+PiBkZW1hbmQtY3YtMDMN Cj4+Pj4gPiA+Pg0KPj4+PiA+ID4+IEhpLA0KPj4+PiA+ID4+DQo+Pj4+ID4gPj4gc29tZSBj b21tZW50cyBiZWxvdzoNCj4+Pj4gPiA+Pg0KPj4+PiA+ID4+IFNlY3Rpb24gMS4zIHNheXM6 ICIgSW4gY2VydGFpbiBNUExTLVRQIGRlcGxveW1lbnQgc2NlbmFyaW9zIElQDQo+Pj4+ID4g Pj4gYWRkcmVzc2luZyBtaWdodCBub3QgYmUNCj4+Pj4gPiA+PiAgICBhdmFpbGFibGUgb3Ig aXQgbWF5IGJlIHByZWZlcnJlZCB0byB1c2Ugc29tZSBmb3JtIG9mIG5vbi1JUA0KPj4+PiA+ ID4+ICAgIGVuY2Fwc3VsYXRpb24gZm9yIE9uLWRlbWFuZCBDViwgcm91dGUgdHJhY2luZyBh bmQgQkZEIHBhY2tldHMuDQo+Pj4+ID4gSW4NCj4+Pj4gPiA+PiAgICBzdWNoIHNjZW5hcmlv cywgT24tZGVtYW5kIENWIGFuZC9vciByb3V0ZSB0cmFjaW5nIFNIT1VMRCBiZSBydW4NCj4+ Pj4gPiA+PiAgICB3aXRob3V0IElQIGFkZHJlc3NpbmcuLi4iDQo+Pj4+ID4gPj4NCj4+Pj4g PiA+PiBJIGFtIG5vdCBzdXJlIHRoZSAiU0hPVUxEIiBpcyByaWdodCBoZXJlLiBJZiBubyBJ UCBhZGRyZXNzaW5nIGlzDQo+Pj4+ID4gPj4gYXZhaWxhYmxlLCB0aGlzIHRoaW5nIE1VU1Qg YmUgcnVuIHdpdGhvdXQgSVAgYWRkcmVzc2luZywgbXVzdG4ndCBpdD8NCj4+Pj4gPiA+Pg0K Pj4+PiA+ID4+IEkgdGhpbmsgc29tZSBhZGRpdGlvbmFsIHRleHQgcmVnYXJkaW5nIHBlci1p bnRlcmZhY2UgTUlQIGFkZHJlc3NpbmcNCj4+Pj4gPiA+PiB3b3VsZCBiZSBuaWNlLiBBcyBm YXIgYXMgSSB1bmRlcnN0YW5kIHRoZSBkb2N1bWVudCwgYWxsIFRMVnMgd2lsbCBiZQ0KPj4+ PiA+ID4+IGluc2lkZSB0aGUgTFNQIHBpbmcgcGFja2V0IChyYXRoZXIgdGhhbiBhcyBBQ0gg VExWcykuDQo+Pj4+ID4gPj4NCj4+Pj4gPiA+PiBTb21lIHBlb3BsZSBoYWQgY29uY2VybnMg ZWFybGllciwgdGhhdCBhZGRyZXNzaW5nIGluZm9ybWF0aW9uIHNob3VsZA0KPj4+PiA+IGJl DQo+Pj4+ID4gPj4gaW4gYSBmaXhlZCBsb2NhdGlvbiBmb3IgZWFzaWVyIHByb2Nlc3Npbmcu IElzIHRoaXMgdGhlIGNhc2UgaGVyZSBJDQo+Pj4+ID4gPj4gd29uZGVyPw0KPj4+PiA+ID4+ DQo+Pj4+ID4gPj4gSXQgd291bGQgYmUgbmljZSBpZiB5b3UgY291bGQgYWRkcmVzcyB0aGlz IGluIHlvdXIgcHJlc2VudGF0aW9uIGluDQo+Pj4+ID4gPj4gUHJhZ3VlLg0KPj4+PiA+ID4+ DQo+Pj4+ID4gPj4gVGhhbmtzLA0KPj4+PiA+ID4+DQo+Pj4+ID4gPj4gUm9sZg0KPj4+PiA+ ID4+DQo+Pj4+ID4gPj4NCj4+Pj4gPiA+PiBORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3Rl cmVkIE9mZmljZTogTkVDIEhvdXNlLCAxIFZpY3RvcmlhIFJvYWQsDQo+Pj4+ID4gPj4gTG9u ZG9uIFczIDZCTCB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODMyMDE0DQo+Pj4+ID4gPj4N Cj4+Pj4gPiA+Pg0KPj4+PiA+ID4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ Pj4gPiA+PiA+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91 bmNlc0BpZXRmLm9yZ10gT24NCj4+Pj4gPiBCZWhhbGYNCj4+Pj4gPiA+PiBPZg0KPj4+PiA+ ID4+ID4gbG9hQHBpLm51DQo+Pj4+ID4gPj4gPiBTZW50OiBNaXR0d29jaCwgMTYuIE3kcnog MjAxMSAwMDoyNg0KPj4+PiA+ID4+ID4gVG86IG1wbHNAaWV0Zi5vcmcNCj4+Pj4gPiA+PiA+ IENjOiBNUExTLVRQIGFkIGhvYyB0ZWFtDQo+Pj4+ID4gPj4gPiBTdWJqZWN0OiBbbXBsc10g V29ya2luZyBHcm91cCBMYXMgQ2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtb24tDQo+Pj4+ ID4gPj4gZGVtYW5kLQ0KPj4+PiA+ID4+ID4gY3YtMDMNCj4+Pj4gPiA+PiA+DQo+Pj4+ID4g Pj4gPiBXb3JraW5nIEdyb3VwLA0KPj4+PiA+ID4+ID4NCj4+Pj4gPiA+PiA+IHRoaXMgaXMg dG8gc3RhcnQgYSAzIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24NCj4+Pj4gPiA+ PiA+DQo+Pj4+ID4gPj4gPiBkcmFmdC1pZXRmLW1wbHMtdHAtb24tZGVtYW5kLWN2LTAzDQo+ Pj4+ID4gPj4gPg0KPj4+PiA+ID4+ID4gUGxlYXNlIHNlbmQgY29tbWVudHMgdG8gdGhlIHdv cmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+Pj4+ID4gPj4gPiBtcGxzQGlldGYub3JnDQo+ Pj4+ID4gPj4gPg0KPj4+PiA+ID4+ID4gVGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVu ZHMgb24gQXByaWwgOCwgMjAxMS4NCj4+Pj4gPiA+PiA+DQo+Pj4+ID4gPj4gPiAvTG9hDQo+ Pj4+ID4gPj4gPg0KPj4+PiA+ID4+ID4NCj4+Pj4gPiA+PiA+DQo+Pj4+ID4gPj4gPg0KPj4+ PiA+ID4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4gPiA+PiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4+ID4gPj4gPiBtcGxzQGll dGYub3JnDQo+Pj4+ID4gPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMNCj4+Pj4gPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+PiA+ID4+IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4+ID4gPj4g bXBsc0BpZXRmLm9yZw0KPj4+PiA+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscw0KPj4+PiA+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+PiA+ID5tcGxzIG1haWxpbmcgbGlzdA0KPj4+PiA+ID5t cGxzQGlldGYub3JnDQo+Pj4+ID4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0KPj4+PiA+ID4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+Pj4gbXBs c0BpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMNCj4+Pg0KPj4NCj4NCg== --GMAILSMTPBOUND01110331152407-- From Alexander.Vainshtein@ecitele.com Wed Mar 30 23:42:34 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E315228C236 for ; Wed, 30 Mar 2011 23:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] 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 9k2yTb3UIRhh for ; Wed, 30 Mar 2011 23:42:32 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id 6773528C23B for ; Wed, 30 Mar 2011 23:42:28 -0700 (PDT) X-AuditID: 93eaf2e8-b7bb7ae000004cb7-3c-4d942250ac47 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Brightmail Gateway) with SMTP id 47.6C.19639.052249D4; Thu, 31 Mar 2011 08:42:24 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 31 Mar 2011 08:44:06 +0200 From: Alexander Vainshtein To: "hideki.endo.es@hitachi.com" , "eric.gray@ericsson.com" Date: Thu, 31 Mar 2011 08:43:53 +0200 Thread-Topic: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-demand-cv- Thread-Index: AcvvbFBklaphTwH6Qry5dNZ1fakPwwAAnb0Q Message-ID: References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.d> In-Reply-To: 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 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "Manuel.Paul@telekom.de" , "Rolf.Winter@neclab.eu" Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-demand-cv- X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 06:42:35 -0000 Hideki, Eric, and all, I believe that ability to do ping MEP-to-MIP should not be precluded (at le= ast for co-routed bidirectional LSPs). Regards, Sasha > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > hideki.endo.es@hitachi.com > Sent: Thursday, March 31, 2011 8:24 AM > To: mpls@ietf.org; eric.gray@ericsson.com; aldrin.ietf@gmail.com > Cc: Manuel.Paul@telekom.de; Rolf.Winter@neclab.eu > Subject: Re: [mpls] Working Group LasCallondraft-ietf-mpls-tp-on- > demand-cv- > > Hi Eric and Sam, > > I'm sorry for my incorrect understanding on DSMAP TLV. > According to Sam, We can use DSMAP in both of ping and trace route. > > However, I have a concern. > Eric, you said; > > Ping mode would be strictly MEP-to-MEP. At least, that > >is the way it is intended to work in our draft. > > On the other hand, RFC5860, MPLS-TP OAM reqs, says; > 2.2.3. Connectivity Verifications > > This function SHOULD be performed on-demand between End Points and > Intermediate Points of PWs and LSPs, and between End Points of PWs, > LSPs, and Sections. > > and; > > 2.2.4. Route Tracing > > This function SHOULD be performed on-demand. > > This function SHOULD be performed between End Points and > Intermediate > Points of PWs and LSPs, and between End Points of PWs, LSPs, and > Sections. > > Why do you restrict ping mode to only for between MEPs? > Do you mean that On-demand CV doesn't satisfy all of OAM reqs? > > BR, > Hideki > > >Hideki, > > > > Ping mode would be strictly MEP-to-MEP. At least, that > >is the way it is intended to work in our draft. > > > > Why would you need per-interface MIP information in this > >case? > > > > If someone wanted to do LSP-Ping to a specific interface, > >I am uncertain why it would be incorrect to use the DSMAP TLV. > > > >-- > >Eric > > > >-----Original Message----- > >From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] > >Sent: Wednesday, March 30, 2011 5:43 PM > >To: Eric Gray; mpls@ietf.org > >Cc: Rolf.Winter@neclab.eu; Manuel.Paul@telekom.de > >Subject: Re[2]: Re[2]: [mpls] Working Group Las Callondraft-ietf-mpls- > tp-on-demand-cv-03 > >Importance: High > > > >Eric, > > > >In my understanding, DSMAP TLV is only for trace route, isn't it? > >We need specific interface information for ping mode of on-demand CV. > > > >BR, > >Hideki > > > >>Hideki, > >> > >> If you want to include specific interface information, > >>you can include a DSMAP (or DDMAP) TLV as defined by RFC > >>4379, and extended by this draft (in combination with the > >>draft "draft-ietf-mpls-lsp-ping-enhanced-dsmap" for DDMAP). > >> > >> Would this not do what you're looking for? > >> > >>-- > >>Eric > >> > >>-----Original Message----- > >>From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] > >>Sent: Wednesday, March 30, 2011 11:33 AM > >>To: Rolf.Winter@neclab.eu; Eric Gray; mpls@ietf.org; > Manuel.Paul@telekom.de > >>Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp- > on-demand-cv-03 > >>Importance: High > >> > >>Hi, > >> > >>I have one comment on IDs in draft-on-demand-cv. > >>The interface-D is missing in the current draft, there is only Node- > ID. > >>You need at least the interface ID to support per-interface MIP. > >> > >>BR, > >>Hideki > >> > >>> > >>>Dear All, > >>> > >>>I really appreciate the consideration on the per-interface MIP > support and the discussion moving forward. > >>> > >>> > >>>From an operator's perspective, it is very important that the > support for per-interface MIPs is covered by the definitions. > >>> > >>>Looking at earlier versions of draft-farrel-mpls-tp-mip-mep-map, > there was already a solution proposal, using the TTL. Enhanced > solutions have been thorougly discussed during this IETF meeting. It it > to be expected that there will be ways to solve both the fast path and > fate-sharing requirement. > >>> > >>> > >>>I second the proposal initially made by Rolf, to include additional > text to document the per-interface MIP addressing for the on-demand-cv > and for other OAM tools. > >>> > >>> > >>>Best regards, > >>>Manuel > >>> > >>> > >>>Deutsche Telekom AG > >>>Group Technology > >>>Manuel Paul > >>>SA3-11 > >>>Goslarer Ufer 35-37, 10589 Berlin > >>>+49 30 3497 - 4394 (Tel.) > >>>+49 30 3497 - 4956 (Fax) > >>>+49 171 8634032 (Mobil) > >>>E-Mail: mailto:manuel.paul@telekom.de > >>>http://www.telekom.com > >>> > >>>> -----Original Message----- > >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of > >>>> Rolf Winter > >>>> Sent: Monday, March 28, 2011 3:03 PM > >>>> To: Eric Gray; hideki.endo.es@hitachi.com > >>>> Cc: mpls@ietf.org > >>>> Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp- > on-demand- > >>>> cv-03 > >>>> > >>>> Eric, > >>>> > >>>> I generally agree but I think there is one case actually which > needs a > >>>> closer look in this regard (which I hinted at earlier), which are > the per- > >>>> interface MIPs. Your TTL expires (the actual addressing bit here), > the > >>>> identifier tells you it is not intended for the ingress MIP, so it > needs > >>>> to be forwarded to the egress MIP through the forwarding engine. > Now if > >>>> you pull the packet out of the fast path and inject it back in, is > the OAM > >>>> packet still fate sharing? If you can do this in HW on the line > card, then > >>>> it will and it will just be forwarded as normal. I know this is a > >>>> different draft, but this will be in particular important for > performance > >>>> monitoring. > >>>> > >>>> Best, > >>>> > >>>> Rolf > >>>> > >>>> > >>>> > >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria > Road, London > >>>> W3 6BL | Registered in England 2832014 > >>>> > >>>> > >>>> > -----Original Message----- > >>>> > From: Eric Gray [mailto:eric.gray@ericsson.com] > >>>> > Sent: Montag, 28. M=E4rz 2011 14:45 > >>>> > To: hideki.endo.es@hitachi.com; Rolf Winter > >>>> > Cc: mpls@ietf.org > >>>> > Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf- > mpls-tp- > >>>> > on-demand-cv-03 > >>>> > > >>>> > Hideki, > >>>> > > >>>> > What you're saying is true, but not relevant in this > >>>> > case. The "addresses" in this discussion are not used to > >>>> > determine how to forward OAM packets. They are used only > >>>> > by the recipient MIP/MEP to verify that the OAM packet was > >>>> > properly delivered. > >>>> > > >>>> > By the way, this discussion is an indication of the > >>>> > confusing injected by calling these things addresses. My > >>>> > mistake and I bring it up now to help to stem the tide of > >>>> > further comments resulting from that confusion. > >>>> > > >>>> > In the version we post after last call is complete, > >>>> > we will be changing the source and destination "address" > >>>> > TLVs to source and destination "identifier" TLVs. > >>>> > > >>>> > We will also be correcting the reference to DSMAP, > >>>> > and DDMAP, address TLVs (which is incorrect, because the > >>>> > format for DSMAP/DDMAP doesn't include a "length" field). > >>>> > > >>>> > The format of the Downstream Mapping (DSMAP) TLV is > >>>> > defined in RFC 4379, and we are not changing the format > >>>> > of that TLV. > >>>> > > >>>> > These changes are driven by last call comments we > >>>> > have already received (see Joel Halpern's comments on the > >>>> > mailing list) and are - in part - to correct accidental > >>>> > use of the word "address" for source and destination > >>>> > identifier TLVs (which is what we had discussed before > >>>> > I generated the -03 version among the authors of several > >>>> > of the current set of MPLS-TP drafts). > >>>> > > >>>> > In the case of source and destination identifiers, > >>>> > these will be used exclusively to verify that an OAM PDU > >>>> > has been correctly received by its intended recipient. > >>>> > Because this is an on-demand connectivity verification > >>>> > protocol, that is expected to be used only on those > >>>> > occasions when there is a network problem that needs to > >>>> > be diagnosed, and the information is not seen (and not > >>>> > visible - without layer violations), optimizing these > >>>> > objects for software makes sense. > >>>> > > >>>> > In addition, since either may be included (which > >>>> > includes the possibility of including both), it is the > >>>> > case already that we would then need to decide which is > >>>> > to go first - assuming we wanted to do this (which we > >>>> > do not). > >>>> > > >>>> > -- > >>>> > Eric > >>>> > > >>>> > -----Original Message----- > >>>> > From: hideki.endo.es@hitachi.com > [mailto:hideki.endo.es@hitachi.com] > >>>> > Sent: Monday, March 28, 2011 8:11 AM > >>>> > To: Eric Gray; Rolf.Winter@neclab.eu > >>>> > Cc: mpls@ietf.org > >>>> > Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls- > tp-on- > >>>> > demand-cv-03 > >>>> > Importance: High > >>>> > > >>>> > Hi Eric and Rolf, > >>>> > > >>>> > I'm sorry for interrupting. > >>>> > > >>>> > I agree with Rolf regarding the per-interface MIP discussion. > >>>> > We have to consider the HW implementation aspect, > >>>> > because trapping of an OAM packet is HW rule/functionality even > in > >>>> > routers. > >>>> > > >>>> > If every OAM packet is trapped to CPU > >>>> > and the OAM packets which should NOT be processed in the > Interface > >>>> > are returned to Data-plane, > >>>> > it is different forwarding path from user packets, > >>>> > which is NOT the Connectivity Verification of the user path. > >>>> > > >>>> > Therefore, we should take the HW aspect and flexibilty into > account > >>>> > concurrently. > >>>> > If an address TLV MUST be the first in TLVs, > >>>> > it is enough to make HW implementation easy. > >>>> > > >>>> > BR, > >>>> > Hideki > >>>> > > >>>> > > >>>> > > >>>> > >Rolf, > >>>> > > > >>>> > > The words you propose are okay with me. > >>>> > > > >>>> > > I thought the MIP/interface and address location issues > >>>> > >were separate. > >>>> > > > >>>> > > I've personally had problems with protocol specifications > >>>> > >that require ordering of TLVs. In particular, this is not very > >>>> > >robust in terms of "future-proofing." What happens if new TLVs > >>>> > >are added later on; for instance, suppose at some point we have > >>>> > >multiple "address" TLVs? > >>>> > > > >>>> > > Also, the fact that implementations are allowed to attach > >>>> > >TLVs in any arbitrary order allows considerable flexibilty in > >>>> > >implementation. Messages can be built in arbitrarily many > ways. > >>>> > >This too can be a future-proofing issue. > >>>> > > > >>>> > > I would prefer not to start down the road of requiring a > >>>> > >subset of TLVs to appear in a certain order, and saying we have > >>>> > >one TLV that needs to be first is doing just that. > >>>> > > > >>>> > >-- > >>>> > >Eric > >>>> > > > >>>> > >-----Original Message----- > >>>> > >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > >>>> > >Sent: Monday, March 28, 2011 6:19 AM > >>>> > >To: Eric Gray > >>>> > >Cc: mpls@ietf.org > >>>> > >Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls- > tp-on- > >>>> > demand-cv-03 > >>>> > >Importance: High > >>>> > > > >>>> > >Hi, > >>>> > > > >>>> > >I still think there is a logical error. Let me explain. In case > there > >>>> > is no IP you simply cannot use it. You say you could enable IP > but then > >>>> > that is not a case where there is no IP. In order to be > constructive > >>>> > here is a text change suggestion: > >>>> > > > >>>> > >"In certain MPLS-TP deployment scenarios IP addressing might > not be > >>>> > available. In those cases On-demand CV and/or route tracing MUST > be run > >>>> > without IP addressing, using the ACH channel type specified in > Section > >>>> > 3. In other cases it might be available, however, it may be > preferred > >>>> > to use some form of non-IP encapsulation. In those cases, the > >>>> > procedures as outlined in section 3 SHOULD also be used." > >>>> > > > >>>> > >Regarding the per-interface MIP discussion. The HW aspect also > popped > >>>> > up in the PWE3 session and I think this is an important > consideration, > >>>> > in particular for OAM. Even if we talk about TLVs, we could make > it a > >>>> > MUST that an Address TLV is always the first one to appear. If > you can > >>>> > facilitate an easy implementation in hardware, I see no reason > to > >>>> > deliberately not do it. > >>>> > > > >>>> > >Best, > >>>> > > > >>>> > >Rolf > >>>> > > > >>>> > > > >>>> > >NEC Europe Limited | Registered Office: NEC House, 1 Victoria > Road, > >>>> > London W3 6BL | Registered in England 2832014 > >>>> > > > >>>> > > > >>>> > >> -----Original Message----- > >>>> > >> From: Eric Gray [mailto:eric.gray@ericsson.com] > >>>> > >> Sent: Montag, 28. M=E4rz 2011 11:43 > >>>> > >> To: Rolf Winter > >>>> > >> Cc: loa@pi.nu; mpls@ietf.org > >>>> > >> Subject: RE: [mpls] Working Group Las Call on draft-ietf- > mpls-tp-on- > >>>> > >> demand-cv-03 > >>>> > >> > >>>> > >> Rolf, > >>>> > >> > >>>> > >> With regard to the use of SHOULD (verses MUST) - the > intent > >>>> > >> (according to RFC 2119 - see the quote below) is consistent > with > >>>> > >> this case. If - for some reason - one had a really good > reason to > >>>> > >> use IP addressing in some specific case, one could take steps > to > >>>> > >> make IP addressing available. > >>>> > >> > >>>> > >> This could be said to introduce a logical disconnect, > but we > >>>> > >> are saved from going down that path by the fact that the > statement > >>>> > >> also includes the case where (for some reason) there is a > case in > >>>> > >> which some other addressing scheme might be preferred. In > many of > >>>> > >> the cases where another addressing scheme may be preferred, > it is > >>>> > >> still possible (in fact likely) that IP addressing is > available. > >>>> > >> > >>>> > >> Otherwise, it would not have been necessary to > distinguish > >>>> > >> this case from the one in which IP addressing is not > available. > >>>> > >> > >>>> > >> For the case where IP addressing is not the preferred > mode, > >>>> > >> we are recommending a mode in which it is not necessary. > >>>> > >> > >>>> > >> With regard to having addresses located in the same > place, > >>>> > >> this protocol is meant for connectivity testing on an on- > demand > >>>> > >> basis and is therefore not optimized for processing in > hardware. > >>>> > >> > >>>> > >> Whether addresses or identifiers, if we are talking > about > >>>> > >> TLV contents, there are issues with trying to guarantee > location > >>>> > >> of specific content, because of the fact that the TLV in > question > >>>> > >> will probably follow other TLVs - thus making locations > difficult > >>>> > >> to predict in any case. > >>>> > >> > >>>> > >> With regard to needing more text on per-interface > MIPs, do > >>>> > >> you have specific suggestions as to what text we might add? > >>>> > >> > >>>> > >> I understand (from discussion with WG chairs) that we > are > >>>> > >> not allowed to explicitly address last call comments during > the > >>>> > >> IETF meeting in Prague, because the last call is still > ongoing > >>>> > >> at that time. > >>>> > >> > >>>> > >> -- > >>>> > >> Eric > >>>> > >> > >>>> > >> PS - > >>>> > >> From RFC 2119 - > >>>> > >> 'SHOULD This word, or the adjective "RECOMMENDED", mean > that there > >>>> > >> may exist valid reasons in particular circumstances > to > >>>> > >> ignore a particular item, but the full implications > must > >>>> > >> be understood and carefully weighed before choosing > a > >>>> > >> different course.' > >>>> > >> > >>>> > >> -----Original Message----- > >>>> > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > >>>> > Of > >>>> > >> Rolf Winter > >>>> > >> Sent: Tuesday, March 22, 2011 4:57 AM > >>>> > >> To: loa@pi.nu; mpls@ietf.org > >>>> > >> Subject: Re: [mpls] Working Group Las Call on draft-ietf- > mpls-tp-on- > >>>> > >> demand-cv-03 > >>>> > >> > >>>> > >> Hi, > >>>> > >> > >>>> > >> some comments below: > >>>> > >> > >>>> > >> Section 1.3 says: " In certain MPLS-TP deployment scenarios > IP > >>>> > >> addressing might not be > >>>> > >> available or it may be preferred to use some form of non- > IP > >>>> > >> encapsulation for On-demand CV, route tracing and BFD > packets. > >>>> > In > >>>> > >> such scenarios, On-demand CV and/or route tracing SHOULD > be run > >>>> > >> without IP addressing..." > >>>> > >> > >>>> > >> I am not sure the "SHOULD" is right here. If no IP addressing > is > >>>> > >> available, this thing MUST be run without IP addressing, > mustn't it? > >>>> > >> > >>>> > >> I think some additional text regarding per-interface MIP > addressing > >>>> > >> would be nice. As far as I understand the document, all TLVs > will be > >>>> > >> inside the LSP ping packet (rather than as ACH TLVs). > >>>> > >> > >>>> > >> Some people had concerns earlier, that addressing information > should > >>>> > be > >>>> > >> in a fixed location for easier processing. Is this the case > here I > >>>> > >> wonder? > >>>> > >> > >>>> > >> It would be nice if you could address this in your > presentation in > >>>> > >> Prague. > >>>> > >> > >>>> > >> Thanks, > >>>> > >> > >>>> > >> Rolf > >>>> > >> > >>>> > >> > >>>> > >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria > Road, > >>>> > >> London W3 6BL | Registered in England 2832014 > >>>> > >> > >>>> > >> > >>>> > >> > -----Original Message----- > >>>> > >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On > >>>> > Behalf > >>>> > >> Of > >>>> > >> > loa@pi.nu > >>>> > >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26 > >>>> > >> > To: mpls@ietf.org > >>>> > >> > Cc: MPLS-TP ad hoc team > >>>> > >> > Subject: [mpls] Working Group Las Call on draft-ietf-mpls- > tp-on- > >>>> > >> demand- > >>>> > >> > cv-03 > >>>> > >> > > >>>> > >> > Working Group, > >>>> > >> > > >>>> > >> > this is to start a 3 week working group last call on > >>>> > >> > > >>>> > >> > draft-ietf-mpls-tp-on-demand-cv-03 > >>>> > >> > > >>>> > >> > Please send comments to the working group mailing list > >>>> > >> > mpls@ietf.org > >>>> > >> > > >>>> > >> > The working group last call ends on April 8, 2011. > >>>> > >> > > >>>> > >> > /Loa > >>>> > >> > > >>>> > >> > > >>>> > >> > > >>>> > >> > > >>>> > >> > _______________________________________________ > >>>> > >> > mpls mailing list > >>>> > >> > mpls@ietf.org > >>>> > >> > https://www.ietf.org/mailman/listinfo/mpls > >>>> > >> _______________________________________________ > >>>> > >> mpls mailing list > >>>> > >> mpls@ietf.org > >>>> > >> https://www.ietf.org/mailman/listinfo/mpls > >>>> > >_______________________________________________ > >>>> > >mpls mailing list > >>>> > >mpls@ietf.org > >>>> > >https://www.ietf.org/mailman/listinfo/mpls > >>>> > > > >>>> _______________________________________________ > >>>> mpls mailing list > >>>> mpls@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mpls > >>> > >> > > From eric.gray@ericsson.com Thu Mar 31 00:46:35 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C580B28C0D0 for ; Thu, 31 Mar 2011 00:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.955 X-Spam-Level: X-Spam-Status: No, score=-5.955 tagged_above=-999 required=5 tests=[AWL=0.644, 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 KNK0sBNygIoB for ; Thu, 31 Mar 2011 00:46:33 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 5F0513A6AD5 for ; Thu, 31 Mar 2011 00:46:33 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p2V7m73w025290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Mar 2011 02:48:07 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 31 Mar 2011 03:48:06 -0400 From: Eric Gray To: "hideki.endo.es@hitachi.com" , "mpls@ietf.org" , "aldrin.ietf@gmail.com" Date: Thu, 31 Mar 2011 03:48:04 -0400 Thread-Topic: Re[2]: Re[2]: Re[2]: [mpls] Working Group LasCallondraft-ietf-mpls-tp-on-demand-cv- Thread-Index: AcvvbEXZsXQLUV4JRMe1AoUnWtuEEAACN7zw Message-ID: References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.d> In-Reply-To: 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: "Manuel.Paul@telekom.de" , "Rolf.Winter@neclab.eu" Subject: Re: [mpls] Working Group LasCallondraft-ietf-mpls-tp-on-demand-cv- X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 07:46:35 -0000 Hideki, This is mostly a semantics issue. In this context, if you're doing MEP-to-MIP Ping using the specification in this draft, you're effectively doing a single-message traceroute. This is because traceroute uses deliberately TTL-limited Ping, one message at a time. This is also the only way you can "Ping" an intermediate maintenance entity - i.e. - by using TTL-limited LSP Ping. This is (I think) the disconnect; there should be no limit imposed on use of DSMAP/DDMAP TLVs in on-demand CV/Traceroute, because the same messages is used for both CV and Traceroute. Hopefully, this clears up any confusion... -- Eric -----Original Message----- From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] Sent: Thursday, March 31, 2011 2:24 AM To: mpls@ietf.org; Eric Gray; aldrin.ietf@gmail.com Cc: Rolf.Winter@neclab.eu; Manuel.Paul@telekom.de Subject: Re[2]: Re[2]: Re[2]: [mpls] Working Group LasCallondraft-ietf-mpls= -tp-on-demand-cv- Importance: High Hi Eric and Sam, I'm sorry for my incorrect understanding on DSMAP TLV. According to Sam, We can use DSMAP in both of ping and trace route. However, I have a concern. Eric, you said; > Ping mode would be strictly MEP-to-MEP. At least, that >is the way it is intended to work in our draft. On the other hand, RFC5860, MPLS-TP OAM reqs, says; 2.2.3. Connectivity Verifications This function SHOULD be performed on-demand between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs, and Sections. and; 2.2.4. Route Tracing This function SHOULD be performed on-demand. This function SHOULD be performed between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs, and Sections. Why do you restrict ping mode to only for between MEPs? Do you mean that On-demand CV doesn't satisfy all of OAM reqs? BR, Hideki >Hideki, > > Ping mode would be strictly MEP-to-MEP. At least, that >is the way it is intended to work in our draft. > > Why would you need per-interface MIP information in this >case? > > If someone wanted to do LSP-Ping to a specific interface, >I am uncertain why it would be incorrect to use the DSMAP TLV. > >-- >Eric > >-----Original Message----- >From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >Sent: Wednesday, March 30, 2011 5:43 PM >To: Eric Gray; mpls@ietf.org >Cc: Rolf.Winter@neclab.eu; Manuel.Paul@telekom.de >Subject: Re[2]: Re[2]: [mpls] Working Group Las Callondraft-ietf-mpls-tp-o= n-demand-cv-03 >Importance: High > >Eric, > >In my understanding, DSMAP TLV is only for trace route, isn't it? >We need specific interface information for ping mode of on-demand CV. > >BR, >Hideki > >>Hideki, >> >> If you want to include specific interface information, >>you can include a DSMAP (or DDMAP) TLV as defined by RFC >>4379, and extended by this draft (in combination with the >>draft "draft-ietf-mpls-lsp-ping-enhanced-dsmap" for DDMAP). >> >> Would this not do what you're looking for? >> >>-- >>Eric >> >>-----Original Message----- >>From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >>Sent: Wednesday, March 30, 2011 11:33 AM >>To: Rolf.Winter@neclab.eu; Eric Gray; mpls@ietf.org; Manuel.Paul@telekom.= de >>Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-dem= and-cv-03 >>Importance: High >> >>Hi, >> >>I have one comment on IDs in draft-on-demand-cv. >>The interface-D is missing in the current draft, there is only Node-ID. >>You need at least the interface ID to support per-interface MIP. >> >>BR, >>Hideki >> >>> >>>Dear All, >>> >>>I really appreciate the consideration on the per-interface MIP support a= nd the discussion moving forward. >>> >>> >>>From an operator's perspective, it is very important that the support fo= r per-interface MIPs is covered by the definitions. >>> >>>Looking at earlier versions of draft-farrel-mpls-tp-mip-mep-map, there w= as already a solution proposal, using the TTL. Enhanced solutions have been= thorougly discussed during this IETF meeting. It it to be expected that th= ere will be ways to solve both the fast path and fate-sharing requirement. >>> >>> >>>I second the proposal initially made by Rolf, to include additional text= to document the per-interface MIP addressing for the on-demand-cv and for = other OAM tools. >>> >>> >>>Best regards, >>>Manuel >>> >>> >>>Deutsche Telekom AG >>>Group Technology >>>Manuel Paul >>>SA3-11 >>>Goslarer Ufer 35-37, 10589 Berlin >>>+49 30 3497 - 4394 (Tel.) >>>+49 30 3497 - 4956 (Fax) >>>+49 171 8634032 (Mobil) >>>E-Mail: mailto:manuel.paul@telekom.de >>>http://www.telekom.com >>> >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf O= f >>>> Rolf Winter >>>> Sent: Monday, March 28, 2011 3:03 PM >>>> To: Eric Gray; hideki.endo.es@hitachi.com >>>> Cc: mpls@ietf.org >>>> Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-dem= and- >>>> cv-03 >>>> >>>> Eric, >>>> >>>> I generally agree but I think there is one case actually which needs a >>>> closer look in this regard (which I hinted at earlier), which are the = per- >>>> interface MIPs. Your TTL expires (the actual addressing bit here), the >>>> identifier tells you it is not intended for the ingress MIP, so it nee= ds >>>> to be forwarded to the egress MIP through the forwarding engine. Now i= f >>>> you pull the packet out of the fast path and inject it back in, is the= OAM >>>> packet still fate sharing? If you can do this in HW on the line card, = then >>>> it will and it will just be forwarded as normal. I know this is a >>>> different draft, but this will be in particular important for performa= nce >>>> monitoring. >>>> >>>> Best, >>>> >>>> Rolf >>>> >>>> >>>> >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lo= ndon >>>> W3 6BL | Registered in England 2832014 >>>> >>>> >>>> > -----Original Message----- >>>> > From: Eric Gray [mailto:eric.gray@ericsson.com] >>>> > Sent: Montag, 28. M=E4rz 2011 14:45 >>>> > To: hideki.endo.es@hitachi.com; Rolf Winter >>>> > Cc: mpls@ietf.org >>>> > Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-= tp- >>>> > on-demand-cv-03 >>>> > >>>> > Hideki, >>>> > >>>> > What you're saying is true, but not relevant in this >>>> > case. The "addresses" in this discussion are not used to >>>> > determine how to forward OAM packets. They are used only >>>> > by the recipient MIP/MEP to verify that the OAM packet was >>>> > properly delivered. >>>> > >>>> > By the way, this discussion is an indication of the >>>> > confusing injected by calling these things addresses. My >>>> > mistake and I bring it up now to help to stem the tide of >>>> > further comments resulting from that confusion. >>>> > >>>> > In the version we post after last call is complete, >>>> > we will be changing the source and destination "address" >>>> > TLVs to source and destination "identifier" TLVs. >>>> > >>>> > We will also be correcting the reference to DSMAP, >>>> > and DDMAP, address TLVs (which is incorrect, because the >>>> > format for DSMAP/DDMAP doesn't include a "length" field). >>>> > >>>> > The format of the Downstream Mapping (DSMAP) TLV is >>>> > defined in RFC 4379, and we are not changing the format >>>> > of that TLV. >>>> > >>>> > These changes are driven by last call comments we >>>> > have already received (see Joel Halpern's comments on the >>>> > mailing list) and are - in part - to correct accidental >>>> > use of the word "address" for source and destination >>>> > identifier TLVs (which is what we had discussed before >>>> > I generated the -03 version among the authors of several >>>> > of the current set of MPLS-TP drafts). >>>> > >>>> > In the case of source and destination identifiers, >>>> > these will be used exclusively to verify that an OAM PDU >>>> > has been correctly received by its intended recipient. >>>> > Because this is an on-demand connectivity verification >>>> > protocol, that is expected to be used only on those >>>> > occasions when there is a network problem that needs to >>>> > be diagnosed, and the information is not seen (and not >>>> > visible - without layer violations), optimizing these >>>> > objects for software makes sense. >>>> > >>>> > In addition, since either may be included (which >>>> > includes the possibility of including both), it is the >>>> > case already that we would then need to decide which is >>>> > to go first - assuming we wanted to do this (which we >>>> > do not). >>>> > >>>> > -- >>>> > Eric >>>> > >>>> > -----Original Message----- >>>> > From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >>>> > Sent: Monday, March 28, 2011 8:11 AM >>>> > To: Eric Gray; Rolf.Winter@neclab.eu >>>> > Cc: mpls@ietf.org >>>> > Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-o= n- >>>> > demand-cv-03 >>>> > Importance: High >>>> > >>>> > Hi Eric and Rolf, >>>> > >>>> > I'm sorry for interrupting. >>>> > >>>> > I agree with Rolf regarding the per-interface MIP discussion. >>>> > We have to consider the HW implementation aspect, >>>> > because trapping of an OAM packet is HW rule/functionality even in >>>> > routers. >>>> > >>>> > If every OAM packet is trapped to CPU >>>> > and the OAM packets which should NOT be processed in the Interface >>>> > are returned to Data-plane, >>>> > it is different forwarding path from user packets, >>>> > which is NOT the Connectivity Verification of the user path. >>>> > >>>> > Therefore, we should take the HW aspect and flexibilty into account >>>> > concurrently. >>>> > If an address TLV MUST be the first in TLVs, >>>> > it is enough to make HW implementation easy. >>>> > >>>> > BR, >>>> > Hideki >>>> > >>>> > >>>> > >>>> > >Rolf, >>>> > > >>>> > > The words you propose are okay with me. >>>> > > >>>> > > I thought the MIP/interface and address location issues >>>> > >were separate. >>>> > > >>>> > > I've personally had problems with protocol specifications >>>> > >that require ordering of TLVs. In particular, this is not very >>>> > >robust in terms of "future-proofing." What happens if new TLVs >>>> > >are added later on; for instance, suppose at some point we have >>>> > >multiple "address" TLVs? >>>> > > >>>> > > Also, the fact that implementations are allowed to attach >>>> > >TLVs in any arbitrary order allows considerable flexibilty in >>>> > >implementation. Messages can be built in arbitrarily many ways. >>>> > >This too can be a future-proofing issue. >>>> > > >>>> > > I would prefer not to start down the road of requiring a >>>> > >subset of TLVs to appear in a certain order, and saying we have >>>> > >one TLV that needs to be first is doing just that. >>>> > > >>>> > >-- >>>> > >Eric >>>> > > >>>> > >-----Original Message----- >>>> > >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >>>> > >Sent: Monday, March 28, 2011 6:19 AM >>>> > >To: Eric Gray >>>> > >Cc: mpls@ietf.org >>>> > >Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on= - >>>> > demand-cv-03 >>>> > >Importance: High >>>> > > >>>> > >Hi, >>>> > > >>>> > >I still think there is a logical error. Let me explain. In case the= re >>>> > is no IP you simply cannot use it. You say you could enable IP but t= hen >>>> > that is not a case where there is no IP. In order to be constructive >>>> > here is a text change suggestion: >>>> > > >>>> > >"In certain MPLS-TP deployment scenarios IP addressing might not be >>>> > available. In those cases On-demand CV and/or route tracing MUST be = run >>>> > without IP addressing, using the ACH channel type specified in Secti= on >>>> > 3. In other cases it might be available, however, it may be preferre= d >>>> > to use some form of non-IP encapsulation. In those cases, the >>>> > procedures as outlined in section 3 SHOULD also be used." >>>> > > >>>> > >Regarding the per-interface MIP discussion. The HW aspect also popp= ed >>>> > up in the PWE3 session and I think this is an important consideratio= n, >>>> > in particular for OAM. Even if we talk about TLVs, we could make it = a >>>> > MUST that an Address TLV is always the first one to appear. If you c= an >>>> > facilitate an easy implementation in hardware, I see no reason to >>>> > deliberately not do it. >>>> > > >>>> > >Best, >>>> > > >>>> > >Rolf >>>> > > >>>> > > >>>> > >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>>> > London W3 6BL | Registered in England 2832014 >>>> > > >>>> > > >>>> > >> -----Original Message----- >>>> > >> From: Eric Gray [mailto:eric.gray@ericsson.com] >>>> > >> Sent: Montag, 28. M=E4rz 2011 11:43 >>>> > >> To: Rolf Winter >>>> > >> Cc: loa@pi.nu; mpls@ietf.org >>>> > >> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-= on- >>>> > >> demand-cv-03 >>>> > >> >>>> > >> Rolf, >>>> > >> >>>> > >> With regard to the use of SHOULD (verses MUST) - the inte= nt >>>> > >> (according to RFC 2119 - see the quote below) is consistent with >>>> > >> this case. If - for some reason - one had a really good reason t= o >>>> > >> use IP addressing in some specific case, one could take steps to >>>> > >> make IP addressing available. >>>> > >> >>>> > >> This could be said to introduce a logical disconnect, but= we >>>> > >> are saved from going down that path by the fact that the statemen= t >>>> > >> also includes the case where (for some reason) there is a case in >>>> > >> which some other addressing scheme might be preferred. In many o= f >>>> > >> the cases where another addressing scheme may be preferred, it is >>>> > >> still possible (in fact likely) that IP addressing is available. >>>> > >> >>>> > >> Otherwise, it would not have been necessary to distinguis= h >>>> > >> this case from the one in which IP addressing is not available. >>>> > >> >>>> > >> For the case where IP addressing is not the preferred mod= e, >>>> > >> we are recommending a mode in which it is not necessary. >>>> > >> >>>> > >> With regard to having addresses located in the same place= , >>>> > >> this protocol is meant for connectivity testing on an on-demand >>>> > >> basis and is therefore not optimized for processing in hardware. >>>> > >> >>>> > >> Whether addresses or identifiers, if we are talking about >>>> > >> TLV contents, there are issues with trying to guarantee location >>>> > >> of specific content, because of the fact that the TLV in question >>>> > >> will probably follow other TLVs - thus making locations difficult >>>> > >> to predict in any case. >>>> > >> >>>> > >> With regard to needing more text on per-interface MIPs, d= o >>>> > >> you have specific suggestions as to what text we might add? >>>> > >> >>>> > >> I understand (from discussion with WG chairs) that we are >>>> > >> not allowed to explicitly address last call comments during the >>>> > >> IETF meeting in Prague, because the last call is still ongoing >>>> > >> at that time. >>>> > >> >>>> > >> -- >>>> > >> Eric >>>> > >> >>>> > >> PS - >>>> > >> From RFC 2119 - >>>> > >> 'SHOULD This word, or the adjective "RECOMMENDED", mean that th= ere >>>> > >> may exist valid reasons in particular circumstances to >>>> > >> ignore a particular item, but the full implications mus= t >>>> > >> be understood and carefully weighed before choosing a >>>> > >> different course.' >>>> > >> >>>> > >> -----Original Message----- >>>> > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beh= alf >>>> > Of >>>> > >> Rolf Winter >>>> > >> Sent: Tuesday, March 22, 2011 4:57 AM >>>> > >> To: loa@pi.nu; mpls@ietf.org >>>> > >> Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-= on- >>>> > >> demand-cv-03 >>>> > >> >>>> > >> Hi, >>>> > >> >>>> > >> some comments below: >>>> > >> >>>> > >> Section 1.3 says: " In certain MPLS-TP deployment scenarios IP >>>> > >> addressing might not be >>>> > >> available or it may be preferred to use some form of non-IP >>>> > >> encapsulation for On-demand CV, route tracing and BFD packets. >>>> > In >>>> > >> such scenarios, On-demand CV and/or route tracing SHOULD be ru= n >>>> > >> without IP addressing..." >>>> > >> >>>> > >> I am not sure the "SHOULD" is right here. If no IP addressing is >>>> > >> available, this thing MUST be run without IP addressing, mustn't = it? >>>> > >> >>>> > >> I think some additional text regarding per-interface MIP addressi= ng >>>> > >> would be nice. As far as I understand the document, all TLVs will= be >>>> > >> inside the LSP ping packet (rather than as ACH TLVs). >>>> > >> >>>> > >> Some people had concerns earlier, that addressing information sho= uld >>>> > be >>>> > >> in a fixed location for easier processing. Is this the case here = I >>>> > >> wonder? >>>> > >> >>>> > >> It would be nice if you could address this in your presentation i= n >>>> > >> Prague. >>>> > >> >>>> > >> Thanks, >>>> > >> >>>> > >> Rolf >>>> > >> >>>> > >> >>>> > >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Roa= d, >>>> > >> London W3 6BL | Registered in England 2832014 >>>> > >> >>>> > >> >>>> > >> > -----Original Message----- >>>> > >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>>> > Behalf >>>> > >> Of >>>> > >> > loa@pi.nu >>>> > >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26 >>>> > >> > To: mpls@ietf.org >>>> > >> > Cc: MPLS-TP ad hoc team >>>> > >> > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on= - >>>> > >> demand- >>>> > >> > cv-03 >>>> > >> > >>>> > >> > Working Group, >>>> > >> > >>>> > >> > this is to start a 3 week working group last call on >>>> > >> > >>>> > >> > draft-ietf-mpls-tp-on-demand-cv-03 >>>> > >> > >>>> > >> > Please send comments to the working group mailing list >>>> > >> > mpls@ietf.org >>>> > >> > >>>> > >> > The working group last call ends on April 8, 2011. >>>> > >> > >>>> > >> > /Loa >>>> > >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> > >> > _______________________________________________ >>>> > >> > mpls mailing list >>>> > >> > mpls@ietf.org >>>> > >> > https://www.ietf.org/mailman/listinfo/mpls >>>> > >> _______________________________________________ >>>> > >> mpls mailing list >>>> > >> mpls@ietf.org >>>> > >> https://www.ietf.org/mailman/listinfo/mpls >>>> > >_______________________________________________ >>>> > >mpls mailing list >>>> > >mpls@ietf.org >>>> > >https://www.ietf.org/mailman/listinfo/mpls >>>> > > >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> >> > From eric.gray@ericsson.com Thu Mar 31 00:59:05 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8350C28C10A for ; Thu, 31 Mar 2011 00:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.988 X-Spam-Level: X-Spam-Status: No, score=-5.988 tagged_above=-999 required=5 tests=[AWL=0.611, 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 70Xx5R+6ZERI for ; Thu, 31 Mar 2011 00:59:03 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id EF84E28C0FC for ; Thu, 31 Mar 2011 00:59:02 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2V80WdU015849; Thu, 31 Mar 2011 03:00:33 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 31 Mar 2011 04:00:31 -0400 From: Eric Gray To: Alexander Vainshtein , "hideki.endo.es@hitachi.com" Date: Thu, 31 Mar 2011 04:00:29 -0400 Thread-Topic: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-demand-cv- Thread-Index: AcvvbFBklaphTwH6Qry5dNZ1fakPwwAAnb0QAAJX26A= Message-ID: References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.d> In-Reply-To: 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@ietf.org" , "Manuel.Paul@telekom.de" , "Rolf.Winter@neclab.eu" Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-demand-cv- X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 07:59:05 -0000 Sasha, It is not precluded. As Hideki correctly points out, ingress to mid-point connectivity verification is a requirement in RFC 5860. Since the same message is used in both Traceroute and CV, in the case where you want to do a continuity check from LSP ingress to some device between the ingress and egress for the LSP (i.e. - a MIP), implementations would do it in the same way that you do Traceroute - with the exception that you would do it only with the intended TTL (as opposed to starting with 1 and incrementing it until you get a ("Ping") response from the intended LSP egress. As I explained to Hideki, it is largely a matter of personal preference whether you think of this as a Traceroute or TTL-limited CV message. Note that CV is explicitly not included in requirements for the case where one might want to test MIP-to-MEP. -- Eric -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, March 31, 2011 2:44 AM To: hideki.endo.es@hitachi.com; Eric Gray Cc: Manuel.Paul@telekom.de; Rolf.Winter@neclab.eu; mpls@ietf.org; aldrin.ie= tf@gmail.com Subject: RE: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-demand= -cv- Importance: High Hideki, Eric, and all, I believe that ability to do ping MEP-to-MIP should not be precluded (at le= ast for co-routed bidirectional LSPs). Regards, Sasha > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > hideki.endo.es@hitachi.com > Sent: Thursday, March 31, 2011 8:24 AM > To: mpls@ietf.org; eric.gray@ericsson.com; aldrin.ietf@gmail.com > Cc: Manuel.Paul@telekom.de; Rolf.Winter@neclab.eu > Subject: Re: [mpls] Working Group LasCallondraft-ietf-mpls-tp-on- > demand-cv- > > Hi Eric and Sam, > > I'm sorry for my incorrect understanding on DSMAP TLV. > According to Sam, We can use DSMAP in both of ping and trace route. > > However, I have a concern. > Eric, you said; > > Ping mode would be strictly MEP-to-MEP. At least, that > >is the way it is intended to work in our draft. > > On the other hand, RFC5860, MPLS-TP OAM reqs, says; > 2.2.3. Connectivity Verifications > > This function SHOULD be performed on-demand between End Points and > Intermediate Points of PWs and LSPs, and between End Points of PWs, > LSPs, and Sections. > > and; > > 2.2.4. Route Tracing > > This function SHOULD be performed on-demand. > > This function SHOULD be performed between End Points and > Intermediate > Points of PWs and LSPs, and between End Points of PWs, LSPs, and > Sections. > > Why do you restrict ping mode to only for between MEPs? > Do you mean that On-demand CV doesn't satisfy all of OAM reqs? > > BR, > Hideki > > >Hideki, > > > > Ping mode would be strictly MEP-to-MEP. At least, that > >is the way it is intended to work in our draft. > > > > Why would you need per-interface MIP information in this > >case? > > > > If someone wanted to do LSP-Ping to a specific interface, > >I am uncertain why it would be incorrect to use the DSMAP TLV. > > > >-- > >Eric > > > >-----Original Message----- > >From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] > >Sent: Wednesday, March 30, 2011 5:43 PM > >To: Eric Gray; mpls@ietf.org > >Cc: Rolf.Winter@neclab.eu; Manuel.Paul@telekom.de > >Subject: Re[2]: Re[2]: [mpls] Working Group Las Callondraft-ietf-mpls- > tp-on-demand-cv-03 > >Importance: High > > > >Eric, > > > >In my understanding, DSMAP TLV is only for trace route, isn't it? > >We need specific interface information for ping mode of on-demand CV. > > > >BR, > >Hideki > > > >>Hideki, > >> > >> If you want to include specific interface information, > >>you can include a DSMAP (or DDMAP) TLV as defined by RFC > >>4379, and extended by this draft (in combination with the > >>draft "draft-ietf-mpls-lsp-ping-enhanced-dsmap" for DDMAP). > >> > >> Would this not do what you're looking for? > >> > >>-- > >>Eric > >> > >>-----Original Message----- > >>From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] > >>Sent: Wednesday, March 30, 2011 11:33 AM > >>To: Rolf.Winter@neclab.eu; Eric Gray; mpls@ietf.org; > Manuel.Paul@telekom.de > >>Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp- > on-demand-cv-03 > >>Importance: High > >> > >>Hi, > >> > >>I have one comment on IDs in draft-on-demand-cv. > >>The interface-D is missing in the current draft, there is only Node- > ID. > >>You need at least the interface ID to support per-interface MIP. > >> > >>BR, > >>Hideki > >> > >>> > >>>Dear All, > >>> > >>>I really appreciate the consideration on the per-interface MIP > support and the discussion moving forward. > >>> > >>> > >>>From an operator's perspective, it is very important that the > support for per-interface MIPs is covered by the definitions. > >>> > >>>Looking at earlier versions of draft-farrel-mpls-tp-mip-mep-map, > there was already a solution proposal, using the TTL. Enhanced > solutions have been thorougly discussed during this IETF meeting. It it > to be expected that there will be ways to solve both the fast path and > fate-sharing requirement. > >>> > >>> > >>>I second the proposal initially made by Rolf, to include additional > text to document the per-interface MIP addressing for the on-demand-cv > and for other OAM tools. > >>> > >>> > >>>Best regards, > >>>Manuel > >>> > >>> > >>>Deutsche Telekom AG > >>>Group Technology > >>>Manuel Paul > >>>SA3-11 > >>>Goslarer Ufer 35-37, 10589 Berlin > >>>+49 30 3497 - 4394 (Tel.) > >>>+49 30 3497 - 4956 (Fax) > >>>+49 171 8634032 (Mobil) > >>>E-Mail: mailto:manuel.paul@telekom.de > >>>http://www.telekom.com > >>> > >>>> -----Original Message----- > >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of > >>>> Rolf Winter > >>>> Sent: Monday, March 28, 2011 3:03 PM > >>>> To: Eric Gray; hideki.endo.es@hitachi.com > >>>> Cc: mpls@ietf.org > >>>> Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp- > on-demand- > >>>> cv-03 > >>>> > >>>> Eric, > >>>> > >>>> I generally agree but I think there is one case actually which > needs a > >>>> closer look in this regard (which I hinted at earlier), which are > the per- > >>>> interface MIPs. Your TTL expires (the actual addressing bit here), > the > >>>> identifier tells you it is not intended for the ingress MIP, so it > needs > >>>> to be forwarded to the egress MIP through the forwarding engine. > Now if > >>>> you pull the packet out of the fast path and inject it back in, is > the OAM > >>>> packet still fate sharing? If you can do this in HW on the line > card, then > >>>> it will and it will just be forwarded as normal. I know this is a > >>>> different draft, but this will be in particular important for > performance > >>>> monitoring. > >>>> > >>>> Best, > >>>> > >>>> Rolf > >>>> > >>>> > >>>> > >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria > Road, London > >>>> W3 6BL | Registered in England 2832014 > >>>> > >>>> > >>>> > -----Original Message----- > >>>> > From: Eric Gray [mailto:eric.gray@ericsson.com] > >>>> > Sent: Montag, 28. M=E4rz 2011 14:45 > >>>> > To: hideki.endo.es@hitachi.com; Rolf Winter > >>>> > Cc: mpls@ietf.org > >>>> > Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf- > mpls-tp- > >>>> > on-demand-cv-03 > >>>> > > >>>> > Hideki, > >>>> > > >>>> > What you're saying is true, but not relevant in this > >>>> > case. The "addresses" in this discussion are not used to > >>>> > determine how to forward OAM packets. They are used only > >>>> > by the recipient MIP/MEP to verify that the OAM packet was > >>>> > properly delivered. > >>>> > > >>>> > By the way, this discussion is an indication of the > >>>> > confusing injected by calling these things addresses. My > >>>> > mistake and I bring it up now to help to stem the tide of > >>>> > further comments resulting from that confusion. > >>>> > > >>>> > In the version we post after last call is complete, > >>>> > we will be changing the source and destination "address" > >>>> > TLVs to source and destination "identifier" TLVs. > >>>> > > >>>> > We will also be correcting the reference to DSMAP, > >>>> > and DDMAP, address TLVs (which is incorrect, because the > >>>> > format for DSMAP/DDMAP doesn't include a "length" field). > >>>> > > >>>> > The format of the Downstream Mapping (DSMAP) TLV is > >>>> > defined in RFC 4379, and we are not changing the format > >>>> > of that TLV. > >>>> > > >>>> > These changes are driven by last call comments we > >>>> > have already received (see Joel Halpern's comments on the > >>>> > mailing list) and are - in part - to correct accidental > >>>> > use of the word "address" for source and destination > >>>> > identifier TLVs (which is what we had discussed before > >>>> > I generated the -03 version among the authors of several > >>>> > of the current set of MPLS-TP drafts). > >>>> > > >>>> > In the case of source and destination identifiers, > >>>> > these will be used exclusively to verify that an OAM PDU > >>>> > has been correctly received by its intended recipient. > >>>> > Because this is an on-demand connectivity verification > >>>> > protocol, that is expected to be used only on those > >>>> > occasions when there is a network problem that needs to > >>>> > be diagnosed, and the information is not seen (and not > >>>> > visible - without layer violations), optimizing these > >>>> > objects for software makes sense. > >>>> > > >>>> > In addition, since either may be included (which > >>>> > includes the possibility of including both), it is the > >>>> > case already that we would then need to decide which is > >>>> > to go first - assuming we wanted to do this (which we > >>>> > do not). > >>>> > > >>>> > -- > >>>> > Eric > >>>> > > >>>> > -----Original Message----- > >>>> > From: hideki.endo.es@hitachi.com > [mailto:hideki.endo.es@hitachi.com] > >>>> > Sent: Monday, March 28, 2011 8:11 AM > >>>> > To: Eric Gray; Rolf.Winter@neclab.eu > >>>> > Cc: mpls@ietf.org > >>>> > Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls- > tp-on- > >>>> > demand-cv-03 > >>>> > Importance: High > >>>> > > >>>> > Hi Eric and Rolf, > >>>> > > >>>> > I'm sorry for interrupting. > >>>> > > >>>> > I agree with Rolf regarding the per-interface MIP discussion. > >>>> > We have to consider the HW implementation aspect, > >>>> > because trapping of an OAM packet is HW rule/functionality even > in > >>>> > routers. > >>>> > > >>>> > If every OAM packet is trapped to CPU > >>>> > and the OAM packets which should NOT be processed in the > Interface > >>>> > are returned to Data-plane, > >>>> > it is different forwarding path from user packets, > >>>> > which is NOT the Connectivity Verification of the user path. > >>>> > > >>>> > Therefore, we should take the HW aspect and flexibilty into > account > >>>> > concurrently. > >>>> > If an address TLV MUST be the first in TLVs, > >>>> > it is enough to make HW implementation easy. > >>>> > > >>>> > BR, > >>>> > Hideki > >>>> > > >>>> > > >>>> > > >>>> > >Rolf, > >>>> > > > >>>> > > The words you propose are okay with me. > >>>> > > > >>>> > > I thought the MIP/interface and address location issues > >>>> > >were separate. > >>>> > > > >>>> > > I've personally had problems with protocol specifications > >>>> > >that require ordering of TLVs. In particular, this is not very > >>>> > >robust in terms of "future-proofing." What happens if new TLVs > >>>> > >are added later on; for instance, suppose at some point we have > >>>> > >multiple "address" TLVs? > >>>> > > > >>>> > > Also, the fact that implementations are allowed to attach > >>>> > >TLVs in any arbitrary order allows considerable flexibilty in > >>>> > >implementation. Messages can be built in arbitrarily many > ways. > >>>> > >This too can be a future-proofing issue. > >>>> > > > >>>> > > I would prefer not to start down the road of requiring a > >>>> > >subset of TLVs to appear in a certain order, and saying we have > >>>> > >one TLV that needs to be first is doing just that. > >>>> > > > >>>> > >-- > >>>> > >Eric > >>>> > > > >>>> > >-----Original Message----- > >>>> > >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > >>>> > >Sent: Monday, March 28, 2011 6:19 AM > >>>> > >To: Eric Gray > >>>> > >Cc: mpls@ietf.org > >>>> > >Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls- > tp-on- > >>>> > demand-cv-03 > >>>> > >Importance: High > >>>> > > > >>>> > >Hi, > >>>> > > > >>>> > >I still think there is a logical error. Let me explain. In case > there > >>>> > is no IP you simply cannot use it. You say you could enable IP > but then > >>>> > that is not a case where there is no IP. In order to be > constructive > >>>> > here is a text change suggestion: > >>>> > > > >>>> > >"In certain MPLS-TP deployment scenarios IP addressing might > not be > >>>> > available. In those cases On-demand CV and/or route tracing MUST > be run > >>>> > without IP addressing, using the ACH channel type specified in > Section > >>>> > 3. In other cases it might be available, however, it may be > preferred > >>>> > to use some form of non-IP encapsulation. In those cases, the > >>>> > procedures as outlined in section 3 SHOULD also be used." > >>>> > > > >>>> > >Regarding the per-interface MIP discussion. The HW aspect also > popped > >>>> > up in the PWE3 session and I think this is an important > consideration, > >>>> > in particular for OAM. Even if we talk about TLVs, we could make > it a > >>>> > MUST that an Address TLV is always the first one to appear. If > you can > >>>> > facilitate an easy implementation in hardware, I see no reason > to > >>>> > deliberately not do it. > >>>> > > > >>>> > >Best, > >>>> > > > >>>> > >Rolf > >>>> > > > >>>> > > > >>>> > >NEC Europe Limited | Registered Office: NEC House, 1 Victoria > Road, > >>>> > London W3 6BL | Registered in England 2832014 > >>>> > > > >>>> > > > >>>> > >> -----Original Message----- > >>>> > >> From: Eric Gray [mailto:eric.gray@ericsson.com] > >>>> > >> Sent: Montag, 28. M=E4rz 2011 11:43 > >>>> > >> To: Rolf Winter > >>>> > >> Cc: loa@pi.nu; mpls@ietf.org > >>>> > >> Subject: RE: [mpls] Working Group Las Call on draft-ietf- > mpls-tp-on- > >>>> > >> demand-cv-03 > >>>> > >> > >>>> > >> Rolf, > >>>> > >> > >>>> > >> With regard to the use of SHOULD (verses MUST) - the > intent > >>>> > >> (according to RFC 2119 - see the quote below) is consistent > with > >>>> > >> this case. If - for some reason - one had a really good > reason to > >>>> > >> use IP addressing in some specific case, one could take steps > to > >>>> > >> make IP addressing available. > >>>> > >> > >>>> > >> This could be said to introduce a logical disconnect, > but we > >>>> > >> are saved from going down that path by the fact that the > statement > >>>> > >> also includes the case where (for some reason) there is a > case in > >>>> > >> which some other addressing scheme might be preferred. In > many of > >>>> > >> the cases where another addressing scheme may be preferred, > it is > >>>> > >> still possible (in fact likely) that IP addressing is > available. > >>>> > >> > >>>> > >> Otherwise, it would not have been necessary to > distinguish > >>>> > >> this case from the one in which IP addressing is not > available. > >>>> > >> > >>>> > >> For the case where IP addressing is not the preferred > mode, > >>>> > >> we are recommending a mode in which it is not necessary. > >>>> > >> > >>>> > >> With regard to having addresses located in the same > place, > >>>> > >> this protocol is meant for connectivity testing on an on- > demand > >>>> > >> basis and is therefore not optimized for processing in > hardware. > >>>> > >> > >>>> > >> Whether addresses or identifiers, if we are talking > about > >>>> > >> TLV contents, there are issues with trying to guarantee > location > >>>> > >> of specific content, because of the fact that the TLV in > question > >>>> > >> will probably follow other TLVs - thus making locations > difficult > >>>> > >> to predict in any case. > >>>> > >> > >>>> > >> With regard to needing more text on per-interface > MIPs, do > >>>> > >> you have specific suggestions as to what text we might add? > >>>> > >> > >>>> > >> I understand (from discussion with WG chairs) that we > are > >>>> > >> not allowed to explicitly address last call comments during > the > >>>> > >> IETF meeting in Prague, because the last call is still > ongoing > >>>> > >> at that time. > >>>> > >> > >>>> > >> -- > >>>> > >> Eric > >>>> > >> > >>>> > >> PS - > >>>> > >> From RFC 2119 - > >>>> > >> 'SHOULD This word, or the adjective "RECOMMENDED", mean > that there > >>>> > >> may exist valid reasons in particular circumstances > to > >>>> > >> ignore a particular item, but the full implications > must > >>>> > >> be understood and carefully weighed before choosing > a > >>>> > >> different course.' > >>>> > >> > >>>> > >> -----Original Message----- > >>>> > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > >>>> > Of > >>>> > >> Rolf Winter > >>>> > >> Sent: Tuesday, March 22, 2011 4:57 AM > >>>> > >> To: loa@pi.nu; mpls@ietf.org > >>>> > >> Subject: Re: [mpls] Working Group Las Call on draft-ietf- > mpls-tp-on- > >>>> > >> demand-cv-03 > >>>> > >> > >>>> > >> Hi, > >>>> > >> > >>>> > >> some comments below: > >>>> > >> > >>>> > >> Section 1.3 says: " In certain MPLS-TP deployment scenarios > IP > >>>> > >> addressing might not be > >>>> > >> available or it may be preferred to use some form of non- > IP > >>>> > >> encapsulation for On-demand CV, route tracing and BFD > packets. > >>>> > In > >>>> > >> such scenarios, On-demand CV and/or route tracing SHOULD > be run > >>>> > >> without IP addressing..." > >>>> > >> > >>>> > >> I am not sure the "SHOULD" is right here. If no IP addressing > is > >>>> > >> available, this thing MUST be run without IP addressing, > mustn't it? > >>>> > >> > >>>> > >> I think some additional text regarding per-interface MIP > addressing > >>>> > >> would be nice. As far as I understand the document, all TLVs > will be > >>>> > >> inside the LSP ping packet (rather than as ACH TLVs). > >>>> > >> > >>>> > >> Some people had concerns earlier, that addressing information > should > >>>> > be > >>>> > >> in a fixed location for easier processing. Is this the case > here I > >>>> > >> wonder? > >>>> > >> > >>>> > >> It would be nice if you could address this in your > presentation in > >>>> > >> Prague. > >>>> > >> > >>>> > >> Thanks, > >>>> > >> > >>>> > >> Rolf > >>>> > >> > >>>> > >> > >>>> > >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria > Road, > >>>> > >> London W3 6BL | Registered in England 2832014 > >>>> > >> > >>>> > >> > >>>> > >> > -----Original Message----- > >>>> > >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On > >>>> > Behalf > >>>> > >> Of > >>>> > >> > loa@pi.nu > >>>> > >> > Sent: Mittwoch, 16. M=E4rz 2011 00:26 > >>>> > >> > To: mpls@ietf.org > >>>> > >> > Cc: MPLS-TP ad hoc team > >>>> > >> > Subject: [mpls] Working Group Las Call on draft-ietf-mpls- > tp-on- > >>>> > >> demand- > >>>> > >> > cv-03 > >>>> > >> > > >>>> > >> > Working Group, > >>>> > >> > > >>>> > >> > this is to start a 3 week working group last call on > >>>> > >> > > >>>> > >> > draft-ietf-mpls-tp-on-demand-cv-03 > >>>> > >> > > >>>> > >> > Please send comments to the working group mailing list > >>>> > >> > mpls@ietf.org > >>>> > >> > > >>>> > >> > The working group last call ends on April 8, 2011. > >>>> > >> > > >>>> > >> > /Loa > >>>> > >> > > >>>> > >> > > >>>> > >> > > >>>> > >> > > >>>> > >> > _______________________________________________ > >>>> > >> > mpls mailing list > >>>> > >> > mpls@ietf.org > >>>> > >> > https://www.ietf.org/mailman/listinfo/mpls > >>>> > >> _______________________________________________ > >>>> > >> mpls mailing list > >>>> > >> mpls@ietf.org > >>>> > >> https://www.ietf.org/mailman/listinfo/mpls > >>>> > >_______________________________________________ > >>>> > >mpls mailing list > >>>> > >mpls@ietf.org > >>>> > >https://www.ietf.org/mailman/listinfo/mpls > >>>> > > > >>>> _______________________________________________ > >>>> mpls mailing list > >>>> mpls@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mpls > >>> > >> > > From hideki.endo.es@hitachi.com Thu Mar 31 01:12:33 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9429E28C209 for ; Thu, 31 Mar 2011 01:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.437 X-Spam-Level: **** X-Spam-Status: No, score=4.437 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_BASE64_TEXT=1.753, SUBJ_RE_NUM=2.799] 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 AHZzsLX2Wjd1 for ; Thu, 31 Mar 2011 01:12:31 -0700 (PDT) Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by core3.amsl.com (Postfix) with ESMTP id DF89E28C105 for ; Thu, 31 Mar 2011 01:12:30 -0700 (PDT) Received: from mlsv6.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id C554437C84; Thu, 31 Mar 2011 17:14:09 +0900 (JST) Received: from mfilter2.hitachi.co.jp by mlsv6.hitachi.co.jp (8.13.1/8.13.1) id p2V8E9f3023714; Thu, 31 Mar 2011 17:14:09 +0900 Received: from hitachi.com (localhost.localdomain [127.0.0.1]) by mfilter2.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id p2V8CshO003704; Thu, 31 Mar 2011 17:14:09 +0900 Received: from vshuts2.hitachi.co.jp ([vshuts2.hitachi.co.jp [10.201.6.71]]) by mfilter2.hitachi.co.jp with RELAY id p2V8E8te004433 ; Thu, 31 Mar 2011 17:14:09 +0900 X-AuditID: b753bd60-a48faba000000ee4-cb-4d9437d002bb Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id 386888B02A5; Thu, 31 Mar 2011 17:14:08 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p2V8E8E25133080; Thu, 31 Mar 2011 17:14:08 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: multipart/mixed; boundary="GMAILSMTPBOUND01110331171357" To: From: Date: Thu, 31 Mar 2011 17:13:39 +0900 References: <161a6e509fbc46c600274060d4da5da6.squirrel@pi.nu> <791AD3077F94194BB2BDD13565B6295D05DECC11@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05E170ED@Polydeuces.office.hd> <791AD3077F94194BB2BDD13565B6295D05E172E9@Polydeuces.office.hd> <40FB0FFB97588246A1BEFB05759DC8A0055E9B99@S4DE9JSAANI.ost.t-com.d> Priority: normal Importance: normal X400-Content-Identifier: X4D94379D00000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28110331171317N8G] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mpls@ietf.org, Manuel.Paul@telekom.de, Rolf.Winter@neclab.eu Subject: Re: [mpls] =?iso-8859-1?q?Working_GroupLasCallondraft-ietf-mpls-tp-on?= =?iso-8859-1?q?-dema?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 08:12:33 -0000 --GMAILSMTPBOUND01110331171357 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 RXJpYywNCg0KVGhhbmsgeW91IGZvciBjbGFyaWZpY2F0aW9ucy4NCkkgdW5kZXJzdGFuZCBv bi1kZW1hbmQgQ1YgY2FuIGJlIGFwcGxpZWQgdG8gYm90aCBNRVAtdG8tTUVQIGFuZCBNRVAt dG8tTUlQLg0KDQpXZSwgZXNwZWNpYWxseSBteXNlbGYsIGhhdmUgdG8gZGlzY2FyZCB0aGUg dGVybWlub2xvZ3kgcmVsYXRlZCB0byBMU1AgcGluZw0Kc3VjaCBhcyBwaW5nIG1vZGUgb3Ig VHJhY2Vyb3V0ZSBtb2RlLA0KYmVjYXVzZSBpdCdzIHZlcnkgY29uZnVzaW5nIGluIE1QTFMt VFAuDQpXZSBuZWVkIHRoZSB0ZXJtaW5vbG9neSBhY2NvcmRpbmcgdG8gUkZDcyBvZiBNUExT LVRQLCBhdCBsZWFzdCB0byBSRkM1ODYwLg0KDQpCUiwNCkhpZGVraQ0KDQo+SGlkZWtpLA0K Pg0KPiAgICAgICAgVGhpcyBpcyBtb3N0bHkgYSBzZW1hbnRpY3MgaXNzdWUuDQo+DQo+ICAg ICAgICBJbiB0aGlzIGNvbnRleHQsIGlmIHlvdSdyZSBkb2luZyBNRVAtdG8tTUlQIFBpbmcg dXNpbmcNCj50aGUgc3BlY2lmaWNhdGlvbiBpbiB0aGlzIGRyYWZ0LCB5b3UncmUgZWZmZWN0 aXZlbHkgZG9pbmcgYQ0KPnNpbmdsZS1tZXNzYWdlIHRyYWNlcm91dGUuDQo+DQo+ICAgICAg ICBUaGlzIGlzIGJlY2F1c2UgdHJhY2Vyb3V0ZSB1c2VzIGRlbGliZXJhdGVseSBUVEwtbGlt aXRlZA0KPlBpbmcsIG9uZSBtZXNzYWdlIGF0IGEgdGltZS4gIFRoaXMgaXMgYWxzbyB0aGUg b25seSB3YXkgeW91DQo+Y2FuICJQaW5nIiBhbiBpbnRlcm1lZGlhdGUgbWFpbnRlbmFuY2Ug ZW50aXR5IC0gaS5lLiAtIGJ5IHVzaW5nDQo+VFRMLWxpbWl0ZWQgTFNQIFBpbmcuDQo+DQo+ ICAgICAgICBUaGlzIGlzIChJIHRoaW5rKSB0aGUgZGlzY29ubmVjdDsgdGhlcmUgc2hvdWxk IGJlIG5vIGxpbWl0DQo+aW1wb3NlZCBvbiB1c2Ugb2YgRFNNQVAvRERNQVAgVExWcyBpbiBv bi1kZW1hbmQgQ1YvVHJhY2Vyb3V0ZSwNCj5iZWNhdXNlIHRoZSBzYW1lIG1lc3NhZ2VzIGlz IHVzZWQgZm9yIGJvdGggQ1YgYW5kIFRyYWNlcm91dGUuDQo+DQo+ICAgICAgICBIb3BlZnVs bHksIHRoaXMgY2xlYXJzIHVwIGFueSBjb25mdXNpb24uLi4NCj4NCj4tLQ0KPkVyaWMNCj4N Cj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGhpZGVraS5lbmRvLmVzQGhp dGFjaGkuY29tIFttYWlsdG86aGlkZWtpLmVuZG8uZXNAaGl0YWNoaS5jb21dDQo+U2VudDog VGh1cnNkYXksIE1hcmNoIDMxLCAyMDExIDI6MjQgQU0NCj5UbzogbXBsc0BpZXRmLm9yZzsg RXJpYyBHcmF5OyBhbGRyaW4uaWV0ZkBnbWFpbC5jb20NCj5DYzogUm9sZi5XaW50ZXJAbmVj bGFiLmV1OyBNYW51ZWwuUGF1bEB0ZWxla29tLmRlDQo+U3ViamVjdDogUmVbMl06IFJlWzJd OiBSZVsyXTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzQ2FsbG9uZHJhZnQtaWV0Zi1tcGxz LXRwLW9uLWRlbWFuZC1jdi0NCj5JbXBvcnRhbmNlOiBIaWdoDQo+DQo+SGkgRXJpYyBhbmQg U2FtLA0KPg0KPkknbSBzb3JyeSBmb3IgbXkgaW5jb3JyZWN0IHVuZGVyc3RhbmRpbmcgb24g RFNNQVAgVExWLg0KPkFjY29yZGluZyB0byBTYW0sIFdlIGNhbiB1c2UgRFNNQVAgaW4gYm90 aCBvZiBwaW5nIGFuZCB0cmFjZSByb3V0ZS4NCj4NCj5Ib3dldmVyLCBJIGhhdmUgYSBjb25j ZXJuLg0KPkVyaWMsIHlvdSBzYWlkOw0KPj4gICAgICAgIFBpbmcgbW9kZSB3b3VsZCBiZSBz dHJpY3RseSBNRVAtdG8tTUVQLiAgQXQgbGVhc3QsIHRoYXQNCj4+aXMgdGhlIHdheSBpdCBp cyBpbnRlbmRlZCB0byB3b3JrIGluIG91ciBkcmFmdC4NCj4NCj5PbiB0aGUgb3RoZXIgaGFu ZCwgUkZDNTg2MCwgTVBMUy1UUCBPQU0gcmVxcywgc2F5czsNCj4yLjIuMy4gIENvbm5lY3Rp dml0eSBWZXJpZmljYXRpb25zDQo+ICAgPHNuaXBwZWQ+DQo+ICAgVGhpcyBmdW5jdGlvbiBT SE9VTEQgYmUgcGVyZm9ybWVkIG9uLWRlbWFuZCBiZXR3ZWVuIEVuZCBQb2ludHMgYW5kDQo+ ICAgSW50ZXJtZWRpYXRlIFBvaW50cyBvZiBQV3MgYW5kIExTUHMsIGFuZCBiZXR3ZWVuIEVu ZCBQb2ludHMgb2YgUFdzLA0KPiAgIExTUHMsIGFuZCBTZWN0aW9ucy4NCj4NCj5hbmQ7DQo+ DQo+Mi4yLjQuICBSb3V0ZSBUcmFjaW5nDQo+ICAgPHNuaXBwZWQ+DQo+ICAgVGhpcyBmdW5j dGlvbiBTSE9VTEQgYmUgcGVyZm9ybWVkIG9uLWRlbWFuZC4NCj4NCj4gICBUaGlzIGZ1bmN0 aW9uIFNIT1VMRCBiZSBwZXJmb3JtZWQgYmV0d2VlbiBFbmQgUG9pbnRzIGFuZCBJbnRlcm1l ZGlhdGUNCj4gICBQb2ludHMgb2YgUFdzIGFuZCBMU1BzLCBhbmQgYmV0d2VlbiBFbmQgUG9p bnRzIG9mIFBXcywgTFNQcywgYW5kDQo+ICAgU2VjdGlvbnMuDQo+DQo+V2h5IGRvIHlvdSBy ZXN0cmljdCBwaW5nIG1vZGUgdG8gb25seSBmb3IgYmV0d2VlbiBNRVBzPw0KPkRvIHlvdSBt ZWFuIHRoYXQgT24tZGVtYW5kIENWIGRvZXNuJ3Qgc2F0aXNmeSBhbGwgb2YgT0FNIHJlcXM/ DQo+DQo+QlIsDQo+SGlkZWtpDQo+DQo+PkhpZGVraSwNCj4+DQo+PiAgICAgICAgUGluZyBt b2RlIHdvdWxkIGJlIHN0cmljdGx5IE1FUC10by1NRVAuICBBdCBsZWFzdCwgdGhhdA0KPj5p cyB0aGUgd2F5IGl0IGlzIGludGVuZGVkIHRvIHdvcmsgaW4gb3VyIGRyYWZ0Lg0KPj4NCj4+ ICAgICAgICBXaHkgd291bGQgeW91IG5lZWQgcGVyLWludGVyZmFjZSBNSVAgaW5mb3JtYXRp b24gaW4gdGhpcw0KPj5jYXNlPw0KPj4NCj4+ICAgICAgICBJZiBzb21lb25lIHdhbnRlZCB0 byBkbyBMU1AtUGluZyB0byBhIHNwZWNpZmljIGludGVyZmFjZSwNCj4+SSBhbSB1bmNlcnRh aW4gd2h5IGl0IHdvdWxkIGJlIGluY29ycmVjdCB0byB1c2UgdGhlIERTTUFQIFRMVi4NCj4+ DQo+Pi0tDQo+PkVyaWMNCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZy b206IGhpZGVraS5lbmRvLmVzQGhpdGFjaGkuY29tIFttYWlsdG86aGlkZWtpLmVuZG8uZXNA aGl0YWNoaS5jb21dDQo+PlNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMzAsIDIwMTEgNTo0MyBQ TQ0KPj5UbzogRXJpYyBHcmF5OyBtcGxzQGlldGYub3JnDQo+PkNjOiBSb2xmLldpbnRlckBu ZWNsYWIuZXU7IE1hbnVlbC5QYXVsQHRlbGVrb20uZGUNCj4+U3ViamVjdDogUmVbMl06IFJl WzJdOiBbbXBsc10gV29ya2luZyBHcm91cCBMYXMgQ2FsbG9uZHJhZnQtaWV0Zi1tcGxzLXRw LW9uLWRlbWFuZC1jdi0wMw0KPj5JbXBvcnRhbmNlOiBIaWdoDQo+Pg0KPj5FcmljLA0KPj4N Cj4+SW4gbXkgdW5kZXJzdGFuZGluZywgRFNNQVAgVExWIGlzIG9ubHkgZm9yIHRyYWNlIHJv dXRlLCBpc24ndCBpdD8NCj4+V2UgbmVlZCBzcGVjaWZpYyBpbnRlcmZhY2UgaW5mb3JtYXRp b24gZm9yIHBpbmcgbW9kZSBvZiBvbi1kZW1hbmQgQ1YuDQo+Pg0KPj5CUiwNCj4+SGlkZWtp DQo+Pg0KPj4+SGlkZWtpLA0KPj4+DQo+Pj4gICAgICAgIElmIHlvdSB3YW50IHRvIGluY2x1 ZGUgc3BlY2lmaWMgaW50ZXJmYWNlIGluZm9ybWF0aW9uLA0KPj4+eW91IGNhbiBpbmNsdWRl IGEgRFNNQVAgKG9yIERETUFQKSBUTFYgYXMgZGVmaW5lZCBieSBSRkMNCj4+PjQzNzksIGFu ZCBleHRlbmRlZCBieSB0aGlzIGRyYWZ0IChpbiBjb21iaW5hdGlvbiB3aXRoIHRoZQ0KPj4+ ZHJhZnQgImRyYWZ0LWlldGYtbXBscy1sc3AtcGluZy1lbmhhbmNlZC1kc21hcCIgZm9yIERE TUFQKS4NCj4+Pg0KPj4+ICAgICAgICBXb3VsZCB0aGlzIG5vdCBkbyB3aGF0IHlvdSdyZSBs b29raW5nIGZvcj8NCj4+Pg0KPj4+LS0NCj4+PkVyaWMNCj4+Pg0KPj4+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IGhpZGVraS5lbmRvLmVzQGhpdGFjaGkuY29tIFtt YWlsdG86aGlkZWtpLmVuZG8uZXNAaGl0YWNoaS5jb21dDQo+Pj5TZW50OiBXZWRuZXNkYXks IE1hcmNoIDMwLCAyMDExIDExOjMzIEFNDQo+Pj5UbzogUm9sZi5XaW50ZXJAbmVjbGFiLmV1 OyBFcmljIEdyYXk7IG1wbHNAaWV0Zi5vcmc7IE1hbnVlbC5QYXVsQHRlbGVrb20uZGUNCj4+ PlN1YmplY3Q6IFJlWzJdOiBbbXBsc10gV29ya2luZyBHcm91cCBMYXMgQ2FsbCBvbmRyYWZ0 LWlldGYtbXBscy10cC1vbi1kZW1hbmQtY3YtMDMNCj4+PkltcG9ydGFuY2U6IEhpZ2gNCj4+ Pg0KPj4+SGksDQo+Pj4NCj4+PkkgaGF2ZSBvbmUgY29tbWVudCBvbiBJRHMgaW4gZHJhZnQt b24tZGVtYW5kLWN2Lg0KPj4+VGhlIGludGVyZmFjZS1EIGlzIG1pc3NpbmcgaW4gdGhlIGN1 cnJlbnQgZHJhZnQsIHRoZXJlIGlzIG9ubHkgTm9kZS1JRC4NCj4+PllvdSBuZWVkIGF0IGxl YXN0IHRoZSBpbnRlcmZhY2UgSUQgdG8gc3VwcG9ydCBwZXItaW50ZXJmYWNlIE1JUC4NCj4+ Pg0KPj4+QlIsDQo+Pj5IaWRla2kNCj4+Pg0KPj4+Pg0KPj4+PkRlYXIgQWxsLA0KPj4+Pg0K Pj4+PkkgcmVhbGx5IGFwcHJlY2lhdGUgdGhlIGNvbnNpZGVyYXRpb24gb24gdGhlIHBlci1p bnRlcmZhY2UgTUlQIHN1cHBvcnQgYW5kIHRoZSBkaXNjdXNzaW9uIG1vdmluZyBmb3J3YXJk Lg0KPj4+Pg0KPj4+Pg0KPj4+PkZyb20gYW4gb3BlcmF0b3IncyBwZXJzcGVjdGl2ZSwgaXQg aXMgdmVyeSBpbXBvcnRhbnQgdGhhdCB0aGUgc3VwcG9ydCBmb3IgcGVyLWludGVyZmFjZSBN SVBzIGlzIGNvdmVyZWQgYnkgdGhlIGRlZmluaXRpb25zLg0KPj4+Pg0KPj4+Pkxvb2tpbmcg YXQgZWFybGllciB2ZXJzaW9ucyBvZiBkcmFmdC1mYXJyZWwtbXBscy10cC1taXAtbWVwLW1h cCwgdGhlcmUgd2FzIGFscmVhZHkgYSBzb2x1dGlvbiBwcm9wb3NhbCwgdXNpbmcgdGhlIFRU TC4gRW5oYW5jZWQgc29sdXRpb25zIGhhdmUgYmVlbiB0aG9yb3VnbHkgZGlzY3Vzc2VkIGR1 cmluZyB0aGlzIElFVEYgbWVldGluZy4gSXQgaXQgdG8gYmUgZXhwZWN0ZWQgdGhhdCB0aGVy ZSB3aWxsIGJlIHdheXMgdG8gc29sdmUgYm90aCB0aGUgZmFzdCBwYXRoIGFuZCBmYXRlLXNo YXJpbmcgcmVxdWlyZW1lbnQuDQo+Pj4+DQo+Pj4+DQo+Pj4+SSBzZWNvbmQgdGhlIHByb3Bv c2FsIGluaXRpYWxseSBtYWRlIGJ5IFJvbGYsIHRvIGluY2x1ZGUgYWRkaXRpb25hbCB0ZXh0 IHRvIGRvY3VtZW50IHRoZSBwZXItaW50ZXJmYWNlIE1JUCBhZGRyZXNzaW5nIGZvciB0aGUg b24tZGVtYW5kLWN2IGFuZCBmb3Igb3RoZXIgT0FNIHRvb2xzLg0KPj4+Pg0KPj4+Pg0KPj4+ PkJlc3QgcmVnYXJkcywNCj4+Pj5NYW51ZWwNCj4+Pj4NCj4+Pj4NCj4+Pj5EZXV0c2NoZSBU ZWxla29tIEFHDQo+Pj4+R3JvdXAgVGVjaG5vbG9neQ0KPj4+Pk1hbnVlbCBQYXVsDQo+Pj4+ U0EzLTExDQo+Pj4+R29zbGFyZXIgVWZlciAzNS0zNywgMTA1ODkgQmVybGluDQo+Pj4+KzQ5 IDMwIDM0OTcgLSA0Mzk0IChUZWwuKQ0KPj4+Pis0OSAzMCAzNDk3IC0gNDk1NiAoRmF4KQ0K Pj4+Pis0OSAxNzEgIDg2MzQwMzIgKE1vYmlsKQ0KPj4+PkUtTWFpbDogbWFpbHRvOm1hbnVl bC5wYXVsQHRlbGVrb20uZGUNCj4+Pj5odHRwOi8vd3d3LnRlbGVrb20uY29tDQo+Pj4+DQo+ Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogbXBscy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YNCj4+Pj4+IFJvbGYgV2ludGVyDQo+Pj4+PiBTZW50OiBNb25kYXksIE1hcmNoIDI4LCAy MDExIDM6MDMgUE0NCj4+Pj4+IFRvOiBFcmljIEdyYXk7IGhpZGVraS5lbmRvLmVzQGhpdGFj aGkuY29tDQo+Pj4+PiBDYzogbXBsc0BpZXRmLm9yZw0KPj4+Pj4gU3ViamVjdDogUmU6IFtt cGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9uZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLWRl bWFuZC0NCj4+Pj4+IGN2LTAzDQo+Pj4+Pg0KPj4+Pj4gRXJpYywNCj4+Pj4+DQo+Pj4+PiBJ IGdlbmVyYWxseSBhZ3JlZSBidXQgSSB0aGluayB0aGVyZSBpcyBvbmUgY2FzZSBhY3R1YWxs eSB3aGljaCBuZWVkcyBhDQo+Pj4+PiBjbG9zZXIgbG9vayBpbiB0aGlzIHJlZ2FyZCAod2hp Y2ggSSBoaW50ZWQgYXQgZWFybGllciksIHdoaWNoIGFyZSB0aGUgcGVyLQ0KPj4+Pj4gaW50 ZXJmYWNlIE1JUHMuIFlvdXIgVFRMIGV4cGlyZXMgKHRoZSBhY3R1YWwgYWRkcmVzc2luZyBi aXQgaGVyZSksIHRoZQ0KPj4+Pj4gaWRlbnRpZmllciB0ZWxscyB5b3UgaXQgaXMgbm90IGlu dGVuZGVkIGZvciB0aGUgaW5ncmVzcyBNSVAsIHNvIGl0IG5lZWRzDQo+Pj4+PiB0byBiZSBm b3J3YXJkZWQgdG8gdGhlIGVncmVzcyBNSVAgdGhyb3VnaCB0aGUgZm9yd2FyZGluZyBlbmdp bmUuIE5vdyBpZg0KPj4+Pj4geW91IHB1bGwgdGhlIHBhY2tldCBvdXQgb2YgdGhlIGZhc3Qg cGF0aCBhbmQgaW5qZWN0IGl0IGJhY2sgaW4sIGlzIHRoZSBPQU0NCj4+Pj4+IHBhY2tldCBz dGlsbCBmYXRlIHNoYXJpbmc/IElmIHlvdSBjYW4gZG8gdGhpcyBpbiBIVyBvbiB0aGUgbGlu ZSBjYXJkLCB0aGVuDQo+Pj4+PiBpdCB3aWxsIGFuZCBpdCB3aWxsIGp1c3QgYmUgZm9yd2Fy ZGVkIGFzIG5vcm1hbC4gSSBrbm93IHRoaXMgaXMgYQ0KPj4+Pj4gZGlmZmVyZW50IGRyYWZ0 LCBidXQgdGhpcyB3aWxsIGJlIGluIHBhcnRpY3VsYXIgaW1wb3J0YW50IGZvciBwZXJmb3Jt YW5jZQ0KPj4+Pj4gbW9uaXRvcmluZy4NCj4+Pj4+DQo+Pj4+PiBCZXN0LA0KPj4+Pj4NCj4+ Pj4+IFJvbGYNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE5FQyBFdXJvcGUgTGltaXRl ZCB8IFJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2UsIDEgVmljdG9yaWEgUm9hZCwgTG9u ZG9uDQo+Pj4+PiBXMyA2QkwgfCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgMjgzMjAxNA0KPj4+ Pj4NCj4+Pj4+DQo+Pj4+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiA+ IEZyb206IEVyaWMgR3JheSBbbWFpbHRvOmVyaWMuZ3JheUBlcmljc3Nvbi5jb21dDQo+Pj4+ PiA+IFNlbnQ6IE1vbnRhZywgMjguIE3kcnogMjAxMSAxNDo0NQ0KPj4+Pj4gPiBUbzogaGlk ZWtpLmVuZG8uZXNAaGl0YWNoaS5jb207IFJvbGYgV2ludGVyDQo+Pj4+PiA+IENjOiBtcGxz QGlldGYub3JnDQo+Pj4+PiA+IFN1YmplY3Q6IFJFOiBSZVsyXTogW21wbHNdIFdvcmtpbmcg R3JvdXAgTGFzIENhbGwgb25kcmFmdC1pZXRmLW1wbHMtdHAtDQo+Pj4+PiA+IG9uLWRlbWFu ZC1jdi0wMw0KPj4+Pj4gPg0KPj4+Pj4gPiBIaWRla2ksDQo+Pj4+PiA+DQo+Pj4+PiA+ICAg IFdoYXQgeW91J3JlIHNheWluZyBpcyB0cnVlLCBidXQgbm90IHJlbGV2YW50IGluIHRoaXMN Cj4+Pj4+ID4gY2FzZS4gIFRoZSAiYWRkcmVzc2VzIiBpbiB0aGlzIGRpc2N1c3Npb24gYXJl IG5vdCB1c2VkIHRvDQo+Pj4+PiA+IGRldGVybWluZSBob3cgdG8gZm9yd2FyZCBPQU0gcGFj a2V0cy4gIFRoZXkgYXJlIHVzZWQgb25seQ0KPj4+Pj4gPiBieSB0aGUgcmVjaXBpZW50IE1J UC9NRVAgdG8gdmVyaWZ5IHRoYXQgdGhlIE9BTSBwYWNrZXQgd2FzDQo+Pj4+PiA+IHByb3Bl cmx5IGRlbGl2ZXJlZC4NCj4+Pj4+ID4NCj4+Pj4+ID4gICAgQnkgdGhlIHdheSwgdGhpcyBk aXNjdXNzaW9uIGlzIGFuIGluZGljYXRpb24gb2YgdGhlDQo+Pj4+PiA+IGNvbmZ1c2luZyBp bmplY3RlZCBieSBjYWxsaW5nIHRoZXNlIHRoaW5ncyBhZGRyZXNzZXMuICBNeQ0KPj4+Pj4g PiBtaXN0YWtlIGFuZCBJIGJyaW5nIGl0IHVwIG5vdyB0byBoZWxwIHRvIHN0ZW0gdGhlIHRp ZGUgb2YNCj4+Pj4+ID4gZnVydGhlciBjb21tZW50cyByZXN1bHRpbmcgZnJvbSB0aGF0IGNv bmZ1c2lvbi4NCj4+Pj4+ID4NCj4+Pj4+ID4gICAgSW4gdGhlIHZlcnNpb24gd2UgcG9zdCBh ZnRlciBsYXN0IGNhbGwgaXMgY29tcGxldGUsDQo+Pj4+PiA+IHdlIHdpbGwgYmUgY2hhbmdp bmcgdGhlIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gImFkZHJlc3MiDQo+Pj4+PiA+IFRMVnMg dG8gc291cmNlIGFuZCBkZXN0aW5hdGlvbiAiaWRlbnRpZmllciIgVExWcy4NCj4+Pj4+ID4N Cj4+Pj4+ID4gICAgV2Ugd2lsbCBhbHNvIGJlIGNvcnJlY3RpbmcgdGhlIHJlZmVyZW5jZSB0 byBEU01BUCwNCj4+Pj4+ID4gYW5kIERETUFQLCBhZGRyZXNzIFRMVnMgKHdoaWNoIGlzIGlu Y29ycmVjdCwgYmVjYXVzZSB0aGUNCj4+Pj4+ID4gZm9ybWF0IGZvciBEU01BUC9ERE1BUCBk b2Vzbid0IGluY2x1ZGUgYSAibGVuZ3RoIiBmaWVsZCkuDQo+Pj4+PiA+DQo+Pj4+PiA+ICAg IFRoZSBmb3JtYXQgb2YgdGhlIERvd25zdHJlYW0gTWFwcGluZyAoRFNNQVApIFRMViBpcw0K Pj4+Pj4gPiBkZWZpbmVkIGluIFJGQyA0Mzc5LCBhbmQgd2UgYXJlIG5vdCBjaGFuZ2luZyB0 aGUgZm9ybWF0DQo+Pj4+PiA+IG9mIHRoYXQgVExWLg0KPj4+Pj4gPg0KPj4+Pj4gPiAgICBU aGVzZSBjaGFuZ2VzIGFyZSBkcml2ZW4gYnkgbGFzdCBjYWxsIGNvbW1lbnRzIHdlDQo+Pj4+ PiA+IGhhdmUgYWxyZWFkeSByZWNlaXZlZCAoc2VlIEpvZWwgSGFscGVybidzIGNvbW1lbnRz IG9uIHRoZQ0KPj4+Pj4gPiBtYWlsaW5nIGxpc3QpIGFuZCBhcmUgLSBpbiBwYXJ0IC0gdG8g Y29ycmVjdCBhY2NpZGVudGFsDQo+Pj4+PiA+IHVzZSBvZiB0aGUgd29yZCAiYWRkcmVzcyIg Zm9yIHNvdXJjZSBhbmQgZGVzdGluYXRpb24NCj4+Pj4+ID4gaWRlbnRpZmllciBUTFZzICh3 aGljaCBpcyB3aGF0IHdlIGhhZCBkaXNjdXNzZWQgYmVmb3JlDQo+Pj4+PiA+IEkgZ2VuZXJh dGVkIHRoZSAtMDMgdmVyc2lvbiBhbW9uZyB0aGUgYXV0aG9ycyBvZiBzZXZlcmFsDQo+Pj4+ PiA+IG9mIHRoZSBjdXJyZW50IHNldCBvZiBNUExTLVRQIGRyYWZ0cykuDQo+Pj4+PiA+DQo+ Pj4+PiA+ICAgIEluIHRoZSBjYXNlIG9mIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gaWRlbnRp ZmllcnMsDQo+Pj4+PiA+IHRoZXNlIHdpbGwgYmUgdXNlZCBleGNsdXNpdmVseSB0byB2ZXJp ZnkgdGhhdCBhbiBPQU0gUERVDQo+Pj4+PiA+IGhhcyBiZWVuIGNvcnJlY3RseSByZWNlaXZl ZCBieSBpdHMgaW50ZW5kZWQgcmVjaXBpZW50Lg0KPj4+Pj4gPiBCZWNhdXNlIHRoaXMgaXMg YW4gb24tZGVtYW5kIGNvbm5lY3Rpdml0eSB2ZXJpZmljYXRpb24NCj4+Pj4+ID4gcHJvdG9j b2wsIHRoYXQgaXMgZXhwZWN0ZWQgdG8gYmUgdXNlZCBvbmx5IG9uIHRob3NlDQo+Pj4+PiA+ IG9jY2FzaW9ucyB3aGVuIHRoZXJlIGlzIGEgbmV0d29yayBwcm9ibGVtIHRoYXQgbmVlZHMg dG8NCj4+Pj4+ID4gYmUgZGlhZ25vc2VkLCBhbmQgdGhlIGluZm9ybWF0aW9uIGlzIG5vdCBz ZWVuIChhbmQgbm90DQo+Pj4+PiA+IHZpc2libGUgLSB3aXRob3V0IGxheWVyIHZpb2xhdGlv bnMpLCBvcHRpbWl6aW5nIHRoZXNlDQo+Pj4+PiA+IG9iamVjdHMgZm9yIHNvZnR3YXJlIG1h a2VzIHNlbnNlLg0KPj4+Pj4gPg0KPj4+Pj4gPiAgICBJbiBhZGRpdGlvbiwgc2luY2UgZWl0 aGVyIG1heSBiZSBpbmNsdWRlZCAod2hpY2gNCj4+Pj4+ID4gaW5jbHVkZXMgdGhlIHBvc3Np YmlsaXR5IG9mIGluY2x1ZGluZyBib3RoKSwgaXQgaXMgdGhlDQo+Pj4+PiA+IGNhc2UgYWxy ZWFkeSB0aGF0IHdlIHdvdWxkIHRoZW4gbmVlZCB0byBkZWNpZGUgd2hpY2ggaXMNCj4+Pj4+ ID4gdG8gZ28gZmlyc3QgLSBhc3N1bWluZyB3ZSB3YW50ZWQgdG8gZG8gdGhpcyAod2hpY2gg d2UNCj4+Pj4+ID4gZG8gbm90KS4NCj4+Pj4+ID4NCj4+Pj4+ID4gLS0NCj4+Pj4+ID4gRXJp Yw0KPj4+Pj4gPg0KPj4+Pj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4g PiBGcm9tOiBoaWRla2kuZW5kby5lc0BoaXRhY2hpLmNvbSBbbWFpbHRvOmhpZGVraS5lbmRv LmVzQGhpdGFjaGkuY29tXQ0KPj4+Pj4gPiBTZW50OiBNb25kYXksIE1hcmNoIDI4LCAyMDEx IDg6MTEgQU0NCj4+Pj4+ID4gVG86IEVyaWMgR3JheTsgUm9sZi5XaW50ZXJAbmVjbGFiLmV1 DQo+Pj4+PiA+IENjOiBtcGxzQGlldGYub3JnDQo+Pj4+PiA+IFN1YmplY3Q6IFJlWzJdOiBb bXBsc10gV29ya2luZyBHcm91cCBMYXMgQ2FsbCBvbmRyYWZ0LWlldGYtbXBscy10cC1vbi0N Cj4+Pj4+ID4gZGVtYW5kLWN2LTAzDQo+Pj4+PiA+IEltcG9ydGFuY2U6IEhpZ2gNCj4+Pj4+ ID4NCj4+Pj4+ID4gSGkgRXJpYyBhbmQgUm9sZiwNCj4+Pj4+ID4NCj4+Pj4+ID4gSSdtIHNv cnJ5IGZvciBpbnRlcnJ1cHRpbmcuDQo+Pj4+PiA+DQo+Pj4+PiA+IEkgYWdyZWUgd2l0aCBS b2xmIHJlZ2FyZGluZyB0aGUgcGVyLWludGVyZmFjZSBNSVAgZGlzY3Vzc2lvbi4NCj4+Pj4+ ID4gV2UgaGF2ZSB0byBjb25zaWRlciB0aGUgSFcgaW1wbGVtZW50YXRpb24gYXNwZWN0LA0K Pj4+Pj4gPiBiZWNhdXNlIHRyYXBwaW5nIG9mIGFuIE9BTSBwYWNrZXQgaXMgSFcgcnVsZS9m dW5jdGlvbmFsaXR5IGV2ZW4gaW4NCj4+Pj4+ID4gcm91dGVycy4NCj4+Pj4+ID4NCj4+Pj4+ ID4gSWYgZXZlcnkgT0FNIHBhY2tldCBpcyB0cmFwcGVkIHRvIENQVQ0KPj4+Pj4gPiBhbmQg dGhlIE9BTSBwYWNrZXRzIHdoaWNoIHNob3VsZCBOT1QgYmUgcHJvY2Vzc2VkIGluIHRoZSBJ bnRlcmZhY2UNCj4+Pj4+ID4gYXJlIHJldHVybmVkIHRvIERhdGEtcGxhbmUsDQo+Pj4+PiA+ IGl0IGlzIGRpZmZlcmVudCBmb3J3YXJkaW5nIHBhdGggZnJvbSB1c2VyIHBhY2tldHMsDQo+ Pj4+PiA+IHdoaWNoIGlzIE5PVCB0aGUgQ29ubmVjdGl2aXR5IFZlcmlmaWNhdGlvbiBvZiB0 aGUgdXNlciBwYXRoLg0KPj4+Pj4gPg0KPj4+Pj4gPiBUaGVyZWZvcmUsIHdlIHNob3VsZCB0 YWtlIHRoZSBIVyBhc3BlY3QgYW5kIGZsZXhpYmlsdHkgaW50byBhY2NvdW50DQo+Pj4+PiA+ IGNvbmN1cnJlbnRseS4NCj4+Pj4+ID4gSWYgYW4gYWRkcmVzcyBUTFYgTVVTVCBiZSB0aGUg Zmlyc3QgaW4gVExWcywNCj4+Pj4+ID4gaXQgaXMgZW5vdWdoIHRvIG1ha2UgSFcgaW1wbGVt ZW50YXRpb24gZWFzeS4NCj4+Pj4+ID4NCj4+Pj4+ID4gQlIsDQo+Pj4+PiA+IEhpZGVraQ0K Pj4+Pj4gPg0KPj4+Pj4gPg0KPj4+Pj4gPg0KPj4+Pj4gPiA+Um9sZiwNCj4+Pj4+ID4gPg0K Pj4+Pj4gPiA+ICBUaGUgd29yZHMgeW91IHByb3Bvc2UgYXJlIG9rYXkgd2l0aCBtZS4NCj4+ Pj4+ID4gPg0KPj4+Pj4gPiA+ICBJIHRob3VnaHQgdGhlIE1JUC9pbnRlcmZhY2UgYW5kIGFk ZHJlc3MgbG9jYXRpb24gaXNzdWVzDQo+Pj4+PiA+ID53ZXJlIHNlcGFyYXRlLg0KPj4+Pj4g PiA+DQo+Pj4+PiA+ID4gIEkndmUgcGVyc29uYWxseSBoYWQgcHJvYmxlbXMgd2l0aCBwcm90 b2NvbCBzcGVjaWZpY2F0aW9ucw0KPj4+Pj4gPiA+dGhhdCByZXF1aXJlIG9yZGVyaW5nIG9m IFRMVnMuICBJbiBwYXJ0aWN1bGFyLCB0aGlzIGlzIG5vdCB2ZXJ5DQo+Pj4+PiA+ID5yb2J1 c3QgaW4gdGVybXMgb2YgImZ1dHVyZS1wcm9vZmluZy4iICBXaGF0IGhhcHBlbnMgaWYgbmV3 IFRMVnMNCj4+Pj4+ID4gPmFyZSBhZGRlZCBsYXRlciBvbjsgZm9yIGluc3RhbmNlLCBzdXBw b3NlIGF0IHNvbWUgcG9pbnQgd2UgaGF2ZQ0KPj4+Pj4gPiA+bXVsdGlwbGUgImFkZHJlc3Mi IFRMVnM/DQo+Pj4+PiA+ID4NCj4+Pj4+ID4gPiAgQWxzbywgdGhlIGZhY3QgdGhhdCBpbXBs ZW1lbnRhdGlvbnMgYXJlIGFsbG93ZWQgdG8gYXR0YWNoDQo+Pj4+PiA+ID5UTFZzIGluIGFu eSBhcmJpdHJhcnkgb3JkZXIgYWxsb3dzIGNvbnNpZGVyYWJsZSBmbGV4aWJpbHR5IGluDQo+ Pj4+PiA+ID5pbXBsZW1lbnRhdGlvbi4gIE1lc3NhZ2VzIGNhbiBiZSBidWlsdCBpbiBhcmJp dHJhcmlseSBtYW55IHdheXMuDQo+Pj4+PiA+ID5UaGlzIHRvbyBjYW4gYmUgYSBmdXR1cmUt cHJvb2ZpbmcgaXNzdWUuDQo+Pj4+PiA+ID4NCj4+Pj4+ID4gPiAgSSB3b3VsZCBwcmVmZXIg bm90IHRvIHN0YXJ0IGRvd24gdGhlIHJvYWQgb2YgcmVxdWlyaW5nIGENCj4+Pj4+ID4gPnN1 YnNldCBvZiBUTFZzIHRvIGFwcGVhciBpbiBhIGNlcnRhaW4gb3JkZXIsIGFuZCBzYXlpbmcg d2UgaGF2ZQ0KPj4+Pj4gPiA+b25lIFRMViB0aGF0IG5lZWRzIHRvIGJlIGZpcnN0IGlzIGRv aW5nIGp1c3QgdGhhdC4NCj4+Pj4+ID4gPg0KPj4+Pj4gPiA+LS0NCj4+Pj4+ID4gPkVyaWMN Cj4+Pj4+ID4gPg0KPj4+Pj4gPiA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+ ID4gPkZyb206IFJvbGYgV2ludGVyIFttYWlsdG86Um9sZi5XaW50ZXJAbmVjbGFiLmV1XQ0K Pj4+Pj4gPiA+U2VudDogTW9uZGF5LCBNYXJjaCAyOCwgMjAxMSA2OjE5IEFNDQo+Pj4+PiA+ ID5UbzogRXJpYyBHcmF5DQo+Pj4+PiA+ID5DYzogbXBsc0BpZXRmLm9yZw0KPj4+Pj4gPiA+ U3ViamVjdDogUkU6IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBDYWxsIG9uIGRyYWZ0LWll dGYtbXBscy10cC1vbi0NCj4+Pj4+ID4gZGVtYW5kLWN2LTAzDQo+Pj4+PiA+ID5JbXBvcnRh bmNlOiBIaWdoDQo+Pj4+PiA+ID4NCj4+Pj4+ID4gPkhpLA0KPj4+Pj4gPiA+DQo+Pj4+PiA+ ID5JIHN0aWxsIHRoaW5rIHRoZXJlIGlzIGEgbG9naWNhbCBlcnJvci4gTGV0IG1lIGV4cGxh aW4uIEluIGNhc2UgdGhlcmUNCj4+Pj4+ID4gaXMgbm8gSVAgeW91IHNpbXBseSBjYW5ub3Qg dXNlIGl0LiBZb3Ugc2F5IHlvdSBjb3VsZCBlbmFibGUgSVAgYnV0IHRoZW4NCj4+Pj4+ID4g dGhhdCBpcyBub3QgYSBjYXNlIHdoZXJlIHRoZXJlIGlzIG5vIElQLiBJbiBvcmRlciB0byBi ZSBjb25zdHJ1Y3RpdmUNCj4+Pj4+ID4gaGVyZSBpcyBhIHRleHQgY2hhbmdlIHN1Z2dlc3Rp b246DQo+Pj4+PiA+ID4NCj4+Pj4+ID4gPiJJbiBjZXJ0YWluIE1QTFMtVFAgZGVwbG95bWVu dCBzY2VuYXJpb3MgSVAgYWRkcmVzc2luZyBtaWdodCBub3QgYmUNCj4+Pj4+ID4gYXZhaWxh YmxlLiBJbiB0aG9zZSBjYXNlcyBPbi1kZW1hbmQgQ1YgYW5kL29yIHJvdXRlIHRyYWNpbmcg TVVTVCBiZSBydW4NCj4+Pj4+ID4gd2l0aG91dCBJUCBhZGRyZXNzaW5nLCB1c2luZyB0aGUg QUNIIGNoYW5uZWwgdHlwZSBzcGVjaWZpZWQgaW4gU2VjdGlvbg0KPj4+Pj4gPiAzLiBJbiBv dGhlciBjYXNlcyBpdCBtaWdodCBiZSBhdmFpbGFibGUsIGhvd2V2ZXIsIGl0IG1heSBiZSBw cmVmZXJyZWQNCj4+Pj4+ID4gdG8gdXNlIHNvbWUgZm9ybSBvZiBub24tSVAgZW5jYXBzdWxh dGlvbi4gSW4gdGhvc2UgY2FzZXMsIHRoZQ0KPj4+Pj4gPiBwcm9jZWR1cmVzIGFzIG91dGxp bmVkIGluIHNlY3Rpb24gMyBTSE9VTEQgYWxzbyBiZSB1c2VkLiINCj4+Pj4+ID4gPg0KPj4+ Pj4gPiA+UmVnYXJkaW5nIHRoZSBwZXItaW50ZXJmYWNlIE1JUCBkaXNjdXNzaW9uLiBUaGUg SFcgYXNwZWN0IGFsc28gcG9wcGVkDQo+Pj4+PiA+IHVwIGluIHRoZSBQV0UzIHNlc3Npb24g YW5kIEkgdGhpbmsgdGhpcyBpcyBhbiBpbXBvcnRhbnQgY29uc2lkZXJhdGlvbiwNCj4+Pj4+ ID4gaW4gcGFydGljdWxhciBmb3IgT0FNLiBFdmVuIGlmIHdlIHRhbGsgYWJvdXQgVExWcywg d2UgY291bGQgbWFrZSBpdCBhDQo+Pj4+PiA+IE1VU1QgdGhhdCBhbiBBZGRyZXNzIFRMViBp cyBhbHdheXMgdGhlIGZpcnN0IG9uZSB0byBhcHBlYXIuIElmIHlvdSBjYW4NCj4+Pj4+ID4g ZmFjaWxpdGF0ZSBhbiBlYXN5IGltcGxlbWVudGF0aW9uIGluIGhhcmR3YXJlLCBJIHNlZSBu byByZWFzb24gdG8NCj4+Pj4+ID4gZGVsaWJlcmF0ZWx5IG5vdCBkbyBpdC4NCj4+Pj4+ID4g Pg0KPj4+Pj4gPiA+QmVzdCwNCj4+Pj4+ID4gPg0KPj4+Pj4gPiA+Um9sZg0KPj4+Pj4gPiA+ DQo+Pj4+PiA+ID4NCj4+Pj4+ID4gPk5FQyBFdXJvcGUgTGltaXRlZCB8IFJlZ2lzdGVyZWQg T2ZmaWNlOiBORUMgSG91c2UsIDEgVmljdG9yaWEgUm9hZCwNCj4+Pj4+ID4gTG9uZG9uIFcz IDZCTCB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODMyMDE0DQo+Pj4+PiA+ID4NCj4+Pj4+ ID4gPg0KPj4+Pj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gPiA+ PiBGcm9tOiBFcmljIEdyYXkgW21haWx0bzplcmljLmdyYXlAZXJpY3Nzb24uY29tXQ0KPj4+ Pj4gPiA+PiBTZW50OiBNb250YWcsIDI4LiBN5HJ6IDIwMTEgMTE6NDMNCj4+Pj4+ID4gPj4g VG86IFJvbGYgV2ludGVyDQo+Pj4+PiA+ID4+IENjOiBsb2FAcGkubnU7IG1wbHNAaWV0Zi5v cmcNCj4+Pj4+ID4gPj4gU3ViamVjdDogUkU6IFttcGxzXSBXb3JraW5nIEdyb3VwIExhcyBD YWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1vbi0NCj4+Pj4+ID4gPj4gZGVtYW5kLWN2LTAz DQo+Pj4+PiA+ID4+DQo+Pj4+PiA+ID4+IFJvbGYsDQo+Pj4+PiA+ID4+DQo+Pj4+PiA+ID4+ ICAgICAgICAgV2l0aCByZWdhcmQgdG8gdGhlIHVzZSBvZiBTSE9VTEQgKHZlcnNlcyBNVVNU KSAtIHRoZSBpbnRlbnQNCj4+Pj4+ID4gPj4gKGFjY29yZGluZyB0byBSRkMgMjExOSAtIHNl ZSB0aGUgcXVvdGUgYmVsb3cpIGlzIGNvbnNpc3RlbnQgd2l0aA0KPj4+Pj4gPiA+PiB0aGlz IGNhc2UuICBJZiAtIGZvciBzb21lIHJlYXNvbiAtIG9uZSBoYWQgYSByZWFsbHkgZ29vZCBy ZWFzb24gdG8NCj4+Pj4+ID4gPj4gdXNlIElQIGFkZHJlc3NpbmcgaW4gc29tZSBzcGVjaWZp YyBjYXNlLCBvbmUgY291bGQgdGFrZSBzdGVwcyB0bw0KPj4+Pj4gPiA+PiBtYWtlIElQIGFk ZHJlc3NpbmcgYXZhaWxhYmxlLg0KPj4+Pj4gPiA+Pg0KPj4+Pj4gPiA+PiAgICAgICAgIFRo aXMgY291bGQgYmUgc2FpZCB0byBpbnRyb2R1Y2UgYSBsb2dpY2FsIGRpc2Nvbm5lY3QsIGJ1 dCB3ZQ0KPj4+Pj4gPiA+PiBhcmUgc2F2ZWQgZnJvbSBnb2luZyBkb3duIHRoYXQgcGF0aCBi eSB0aGUgZmFjdCB0aGF0IHRoZSBzdGF0ZW1lbnQNCj4+Pj4+ID4gPj4gYWxzbyBpbmNsdWRl cyB0aGUgY2FzZSB3aGVyZSAoZm9yIHNvbWUgcmVhc29uKSB0aGVyZSBpcyBhIGNhc2UgaW4N Cj4+Pj4+ID4gPj4gd2hpY2ggc29tZSBvdGhlciBhZGRyZXNzaW5nIHNjaGVtZSBtaWdodCBi ZSBwcmVmZXJyZWQuICBJbiBtYW55IG9mDQo+Pj4+PiA+ID4+IHRoZSBjYXNlcyB3aGVyZSBh bm90aGVyIGFkZHJlc3Npbmcgc2NoZW1lIG1heSBiZSBwcmVmZXJyZWQsIGl0IGlzDQo+Pj4+ PiA+ID4+IHN0aWxsIHBvc3NpYmxlIChpbiBmYWN0IGxpa2VseSkgdGhhdCBJUCBhZGRyZXNz aW5nIGlzIGF2YWlsYWJsZS4NCj4+Pj4+ID4gPj4NCj4+Pj4+ID4gPj4gICAgICAgICBPdGhl cndpc2UsIGl0IHdvdWxkIG5vdCBoYXZlIGJlZW4gbmVjZXNzYXJ5IHRvIGRpc3Rpbmd1aXNo DQo+Pj4+PiA+ID4+IHRoaXMgY2FzZSBmcm9tIHRoZSBvbmUgaW4gd2hpY2ggSVAgYWRkcmVz c2luZyBpcyBub3QgYXZhaWxhYmxlLg0KPj4+Pj4gPiA+Pg0KPj4+Pj4gPiA+PiAgICAgICAg IEZvciB0aGUgY2FzZSB3aGVyZSBJUCBhZGRyZXNzaW5nIGlzIG5vdCB0aGUgcHJlZmVycmVk IG1vZGUsDQo+Pj4+PiA+ID4+IHdlIGFyZSByZWNvbW1lbmRpbmcgYSBtb2RlIGluIHdoaWNo IGl0IGlzIG5vdCBuZWNlc3NhcnkuDQo+Pj4+PiA+ID4+DQo+Pj4+PiA+ID4+ICAgICAgICAg V2l0aCByZWdhcmQgdG8gaGF2aW5nIGFkZHJlc3NlcyBsb2NhdGVkIGluIHRoZSBzYW1lIHBs YWNlLA0KPj4+Pj4gPiA+PiB0aGlzIHByb3RvY29sIGlzIG1lYW50IGZvciBjb25uZWN0aXZp dHkgdGVzdGluZyBvbiBhbiBvbi1kZW1hbmQNCj4+Pj4+ID4gPj4gYmFzaXMgYW5kIGlzIHRo ZXJlZm9yZSBub3Qgb3B0aW1pemVkIGZvciBwcm9jZXNzaW5nIGluIGhhcmR3YXJlLg0KPj4+ Pj4gPiA+Pg0KPj4+Pj4gPiA+PiAgICAgICAgIFdoZXRoZXIgYWRkcmVzc2VzIG9yIGlkZW50 aWZpZXJzLCBpZiB3ZSBhcmUgdGFsa2luZyBhYm91dA0KPj4+Pj4gPiA+PiBUTFYgY29udGVu dHMsIHRoZXJlIGFyZSBpc3N1ZXMgd2l0aCB0cnlpbmcgdG8gZ3VhcmFudGVlIGxvY2F0aW9u DQo+Pj4+PiA+ID4+IG9mIHNwZWNpZmljIGNvbnRlbnQsIGJlY2F1c2Ugb2YgdGhlIGZhY3Qg dGhhdCB0aGUgVExWIGluIHF1ZXN0aW9uDQo+Pj4+PiA+ID4+IHdpbGwgcHJvYmFibHkgZm9s bG93IG90aGVyIFRMVnMgLSB0aHVzIG1ha2luZyBsb2NhdGlvbnMgZGlmZmljdWx0DQo+Pj4+ PiA+ID4+IHRvIHByZWRpY3QgaW4gYW55IGNhc2UuDQo+Pj4+PiA+ID4+DQo+Pj4+PiA+ID4+ ICAgICAgICAgV2l0aCByZWdhcmQgdG8gbmVlZGluZyBtb3JlIHRleHQgb24gcGVyLWludGVy ZmFjZSBNSVBzLCBkbw0KPj4+Pj4gPiA+PiB5b3UgaGF2ZSBzcGVjaWZpYyBzdWdnZXN0aW9u cyBhcyB0byB3aGF0IHRleHQgd2UgbWlnaHQgYWRkPw0KPj4+Pj4gPiA+Pg0KPj4+Pj4gPiA+ PiAgICAgICAgIEkgdW5kZXJzdGFuZCAoZnJvbSBkaXNjdXNzaW9uIHdpdGggV0cgY2hhaXJz KSB0aGF0IHdlIGFyZQ0KPj4+Pj4gPiA+PiBub3QgYWxsb3dlZCB0byBleHBsaWNpdGx5IGFk ZHJlc3MgbGFzdCBjYWxsIGNvbW1lbnRzIGR1cmluZyB0aGUNCj4+Pj4+ID4gPj4gSUVURiBt ZWV0aW5nIGluIFByYWd1ZSwgYmVjYXVzZSB0aGUgbGFzdCBjYWxsIGlzIHN0aWxsIG9uZ29p bmcNCj4+Pj4+ID4gPj4gYXQgdGhhdCB0aW1lLg0KPj4+Pj4gPiA+Pg0KPj4+Pj4gPiA+PiAt LQ0KPj4+Pj4gPiA+PiBFcmljDQo+Pj4+PiA+ID4+DQo+Pj4+PiA+ID4+IFBTIC0NCj4+Pj4+ ID4gPj4gRnJvbSBSRkMgMjExOSAtDQo+Pj4+PiA+ID4+ICdTSE9VTEQgICBUaGlzIHdvcmQs IG9yIHRoZSBhZGplY3RpdmUgIlJFQ09NTUVOREVEIiwgbWVhbiB0aGF0IHRoZXJlDQo+Pj4+ PiA+ID4+ICAgICAgICAgICBtYXkgZXhpc3QgdmFsaWQgcmVhc29ucyBpbiBwYXJ0aWN1bGFy IGNpcmN1bXN0YW5jZXMgdG8NCj4+Pj4+ID4gPj4gICAgICAgICAgIGlnbm9yZSBhIHBhcnRp Y3VsYXIgaXRlbSwgYnV0IHRoZSBmdWxsIGltcGxpY2F0aW9ucyBtdXN0DQo+Pj4+PiA+ID4+ ICAgICAgICAgICBiZSB1bmRlcnN0b29kIGFuZCBjYXJlZnVsbHkgd2VpZ2hlZCBiZWZvcmUg Y2hvb3NpbmcgYQ0KPj4+Pj4gPiA+PiAgICAgICAgICAgZGlmZmVyZW50IGNvdXJzZS4nDQo+ Pj4+PiA+ID4+DQo+Pj4+PiA+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+ PiA+ID4+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+Pj4+PiA+IE9mDQo+Pj4+PiA+ID4+IFJvbGYgV2lu dGVyDQo+Pj4+PiA+ID4+IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDIyLCAyMDExIDQ6NTcgQU0N Cj4+Pj4+ID4gPj4gVG86IGxvYUBwaS5udTsgbXBsc0BpZXRmLm9yZw0KPj4+Pj4gPiA+PiBT dWJqZWN0OiBSZTogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENhbGwgb24gZHJhZnQtaWV0 Zi1tcGxzLXRwLW9uLQ0KPj4+Pj4gPiA+PiBkZW1hbmQtY3YtMDMNCj4+Pj4+ID4gPj4NCj4+ Pj4+ID4gPj4gSGksDQo+Pj4+PiA+ID4+DQo+Pj4+PiA+ID4+IHNvbWUgY29tbWVudHMgYmVs b3c6DQo+Pj4+PiA+ID4+DQo+Pj4+PiA+ID4+IFNlY3Rpb24gMS4zIHNheXM6ICIgSW4gY2Vy dGFpbiBNUExTLVRQIGRlcGxveW1lbnQgc2NlbmFyaW9zIElQDQo+Pj4+PiA+ID4+IGFkZHJl c3NpbmcgbWlnaHQgbm90IGJlDQo+Pj4+PiA+ID4+ICAgIGF2YWlsYWJsZSBvciBpdCBtYXkg YmUgcHJlZmVycmVkIHRvIHVzZSBzb21lIGZvcm0gb2Ygbm9uLUlQDQo+Pj4+PiA+ID4+ICAg IGVuY2Fwc3VsYXRpb24gZm9yIE9uLWRlbWFuZCBDViwgcm91dGUgdHJhY2luZyBhbmQgQkZE IHBhY2tldHMuDQo+Pj4+PiA+IEluDQo+Pj4+PiA+ID4+ICAgIHN1Y2ggc2NlbmFyaW9zLCBP bi1kZW1hbmQgQ1YgYW5kL29yIHJvdXRlIHRyYWNpbmcgU0hPVUxEIGJlIHJ1bg0KPj4+Pj4g PiA+PiAgICB3aXRob3V0IElQIGFkZHJlc3NpbmcuLi4iDQo+Pj4+PiA+ID4+DQo+Pj4+PiA+ ID4+IEkgYW0gbm90IHN1cmUgdGhlICJTSE9VTEQiIGlzIHJpZ2h0IGhlcmUuIElmIG5vIElQ IGFkZHJlc3NpbmcgaXMNCj4+Pj4+ID4gPj4gYXZhaWxhYmxlLCB0aGlzIHRoaW5nIE1VU1Qg YmUgcnVuIHdpdGhvdXQgSVAgYWRkcmVzc2luZywgbXVzdG4ndCBpdD8NCj4+Pj4+ID4gPj4N Cj4+Pj4+ID4gPj4gSSB0aGluayBzb21lIGFkZGl0aW9uYWwgdGV4dCByZWdhcmRpbmcgcGVy LWludGVyZmFjZSBNSVAgYWRkcmVzc2luZw0KPj4+Pj4gPiA+PiB3b3VsZCBiZSBuaWNlLiBB cyBmYXIgYXMgSSB1bmRlcnN0YW5kIHRoZSBkb2N1bWVudCwgYWxsIFRMVnMgd2lsbCBiZQ0K Pj4+Pj4gPiA+PiBpbnNpZGUgdGhlIExTUCBwaW5nIHBhY2tldCAocmF0aGVyIHRoYW4gYXMg QUNIIFRMVnMpLg0KPj4+Pj4gPiA+Pg0KPj4+Pj4gPiA+PiBTb21lIHBlb3BsZSBoYWQgY29u Y2VybnMgZWFybGllciwgdGhhdCBhZGRyZXNzaW5nIGluZm9ybWF0aW9uIHNob3VsZA0KPj4+ Pj4gPiBiZQ0KPj4+Pj4gPiA+PiBpbiBhIGZpeGVkIGxvY2F0aW9uIGZvciBlYXNpZXIgcHJv Y2Vzc2luZy4gSXMgdGhpcyB0aGUgY2FzZSBoZXJlIEkNCj4+Pj4+ID4gPj4gd29uZGVyPw0K Pj4+Pj4gPiA+Pg0KPj4+Pj4gPiA+PiBJdCB3b3VsZCBiZSBuaWNlIGlmIHlvdSBjb3VsZCBh ZGRyZXNzIHRoaXMgaW4geW91ciBwcmVzZW50YXRpb24gaW4NCj4+Pj4+ID4gPj4gUHJhZ3Vl Lg0KPj4+Pj4gPiA+Pg0KPj4+Pj4gPiA+PiBUaGFua3MsDQo+Pj4+PiA+ID4+DQo+Pj4+PiA+ ID4+IFJvbGYNCj4+Pj4+ID4gPj4NCj4+Pj4+ID4gPj4NCj4+Pj4+ID4gPj4gTkVDIEV1cm9w ZSBMaW1pdGVkIHwgUmVnaXN0ZXJlZCBPZmZpY2U6IE5FQyBIb3VzZSwgMSBWaWN0b3JpYSBS b2FkLA0KPj4+Pj4gPiA+PiBMb25kb24gVzMgNkJMIHwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5k IDI4MzIwMTQNCj4+Pj4+ID4gPj4NCj4+Pj4+ID4gPj4NCj4+Pj4+ID4gPj4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gPiA+PiA+IEZyb206IG1wbHMtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+Pj4+ID4gQmVo YWxmDQo+Pj4+PiA+ID4+IE9mDQo+Pj4+PiA+ID4+ID4gbG9hQHBpLm51DQo+Pj4+PiA+ID4+ ID4gU2VudDogTWl0dHdvY2gsIDE2LiBN5HJ6IDIwMTEgMDA6MjYNCj4+Pj4+ID4gPj4gPiBU bzogbXBsc0BpZXRmLm9yZw0KPj4+Pj4gPiA+PiA+IENjOiBNUExTLVRQIGFkIGhvYyB0ZWFt DQo+Pj4+PiA+ID4+ID4gU3ViamVjdDogW21wbHNdIFdvcmtpbmcgR3JvdXAgTGFzIENhbGwg b24gZHJhZnQtaWV0Zi1tcGxzLXRwLW9uLQ0KPj4+Pj4gPiA+PiBkZW1hbmQtDQo+Pj4+PiA+ ID4+ID4gY3YtMDMNCj4+Pj4+ID4gPj4gPg0KPj4+Pj4gPiA+PiA+IFdvcmtpbmcgR3JvdXAs DQo+Pj4+PiA+ID4+ID4NCj4+Pj4+ID4gPj4gPiB0aGlzIGlzIHRvIHN0YXJ0IGEgMyB3ZWVr IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQo+Pj4+PiA+ID4+ID4NCj4+Pj4+ID4gPj4g PiBkcmFmdC1pZXRmLW1wbHMtdHAtb24tZGVtYW5kLWN2LTAzDQo+Pj4+PiA+ID4+ID4NCj4+ Pj4+ID4gPj4gPiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0byB0aGUgd29ya2luZyBncm91cCBt YWlsaW5nIGxpc3QNCj4+Pj4+ID4gPj4gPiBtcGxzQGlldGYub3JnDQo+Pj4+PiA+ID4+ID4N Cj4+Pj4+ID4gPj4gPiBUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBBcHJp bCA4LCAyMDExLg0KPj4+Pj4gPiA+PiA+DQo+Pj4+PiA+ID4+ID4gL0xvYQ0KPj4+Pj4gPiA+ PiA+DQo+Pj4+PiA+ID4+ID4NCj4+Pj4+ID4gPj4gPg0KPj4+Pj4gPiA+PiA+DQo+Pj4+PiA+ ID4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4+ID4gPj4gPiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+Pj4gPiA+PiA+IG1wbHNAaWV0 Zi5vcmcNCj4+Pj4+ID4gPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMNCj4+Pj4+ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+Pj4+ID4gPj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+Pj4+ID4g Pj4gbXBsc0BpZXRmLm9yZw0KPj4+Pj4gPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCj4+Pj4+ID4gPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiA+ID5tcGxzIG1haWxpbmcgbGlzdA0KPj4+ Pj4gPiA+bXBsc0BpZXRmLm9yZw0KPj4+Pj4gPiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzDQo+Pj4+PiA+ID4NCj4+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBtcGxzIG1haWxpbmcgbGlz dA0KPj4+Pj4gbXBsc0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzDQo+Pj4+DQo+Pj4NCj4+DQo+DQo= --GMAILSMTPBOUND01110331171357-- From curtis@occnc.com Thu Mar 31 01:33:06 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84CF528C0DF for ; Thu, 31 Mar 2011 01:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] 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 JibWrv+gh0rU for ; Thu, 31 Mar 2011 01:33:04 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 0F3E33A69AC for ; Thu, 31 Mar 2011 01:33:03 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p2V8Yfjk047606; Thu, 31 Mar 2011 04:34:42 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201103310834.p2V8Yfjk047606@harbor.orleans.occnc.com> To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" From: Curtis Villamizar In-reply-to: Your message of "Wed, 30 Mar 2011 18:01:47 +0200." <077E41CFFD002C4CAB7DFA4386A532640397A5F7@DEMUEXC014.nsn-intra.net> Date: Thu, 31 Mar 2011 04:34:41 -0400 Sender: curtis@occnc.com Cc: Manuel.Paul@telekom.de, Rolf.Winter@neclab.eu, mpls@ietf.org Subject: Re: [mpls] Working Group LasCall ondraft-ietf-mpls-tp-on-demand-cv-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 08:33:06 -0000 As long as there is an option to implement per-node model, then I agree. I would like to remind the strong advocates of per-interface model that the large ILM and counter set duplicated on ingress and egress doubles the size of an SRAM on-chip. What you will probably get from equipment vendors is an option to use all that ILM and counter SRAM on the ingress side or use half for ingress and half for egress and get half the ILM size. For some product, notably purpose built LSR only (no 4M IP routes) the ILM is perhaps the largest SRAM structure so doubling SRAM size reduces space/power density at least somewhat). That said, both per-node and per-interface model should be supported in the TP documents to allow this sort of tradeoff to be decided at deployment time by the provider. Curtis In message <077E41CFFD002C4CAB7DFA4386A532640397A5F7@DEMUEXC014.nsn-intra.net> "Sprecher, Nurit (NSN - IL/Hod HaSharon)" writes: +1 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Yoshinori KOIKE Sent: Wednesday, March 30, 2011 6:49 PM To: mpls@ietf.org Cc: Manuel.Paul@telekom.de; Rolf.Winter@neclab.eu Subject: Re: [mpls] Working Group LasCall ondraft-ietf-mpls-tp-on-demand-cv-03 Dear all, I agree with Manuel. It is important to agree with the solution which achieves per-interface model as soon as possible. I think that enhancing the draft-farrel-mpls-tp-mip-mep-map is the best way at the moment. Best regards, Yoshinori (2011/03/30 23:31), Manuel.Paul@telekom.de wrote: > > Dear All, > > I really appreciate the consideration on the per-interface MIP support and the discussion moving forward. > > >> From an operator's perspective, it is very important that the support for per-interface MIPs is covered by the definitions. > > Looking at earlier versions of draft-farrel-mpls-tp-mip-mep-map, there was already a solution proposal, using the TTL. Enhanced solutions have been thorougly discussed during this IETF meeting. It it to be expected that there will be ways to solve both the fast path and fate-sharing requirement. > > > I second the proposal initially made by Rolf, to include additional text to document the per-interface MIP addressing for the on-demand-cv and for other OAM tools. > > > Best regards, > Manuel > > > Deutsche Telekom AG > Group Technology > Manuel Paul > SA3-11 > Goslarer Ufer 35-37, 10589 Berlin > +49 30 3497 - 4394 (Tel.) > +49 30 3497 - 4956 (Fax) > +49 171 8634032 (Mobil) > E-Mail: mailto:manuel.paul@telekom.de > http://www.telekom.com > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Rolf Winter >> Sent: Monday, March 28, 2011 3:03 PM >> To: Eric Gray; hideki.endo.es@hitachi.com >> Cc: mpls@ietf.org >> Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on-demand- >> cv-03 >> >> Eric, >> >> I generally agree but I think there is one case actually which needs a >> closer look in this regard (which I hinted at earlier), which are the per- >> interface MIPs. Your TTL expires (the actual addressing bit here), the >> identifier tells you it is not intended for the ingress MIP, so it needs >> to be forwarded to the egress MIP through the forwarding engine. Now if >> you pull the packet out of the fast path and inject it back in, is the OAM >> packet still fate sharing? If you can do this in HW on the line card, then >> it will and it will just be forwarded as normal. I know this is a >> different draft, but this will be in particular important for performance >> monitoring. >> >> Best, >> >> Rolf >> >> >> >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London >> W3 6BL | Registered in England 2832014 >> >> >>> -----Original Message----- >>> From: Eric Gray [mailto:eric.gray@ericsson.com] >>> Sent: Montag, 28. März 2011 14:45 >>> To: hideki.endo.es@hitachi.com; Rolf Winter >>> Cc: mpls@ietf.org >>> Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp- >>> on-demand-cv-03 >>> >>> Hideki, >>> >>> What you're saying is true, but not relevant in this >>> case. The "addresses" in this discussion are not used to >>> determine how to forward OAM packets. They are used only >>> by the recipient MIP/MEP to verify that the OAM packet was >>> properly delivered. >>> >>> By the way, this discussion is an indication of the >>> confusing injected by calling these things addresses. My >>> mistake and I bring it up now to help to stem the tide of >>> further comments resulting from that confusion. >>> >>> In the version we post after last call is complete, >>> we will be changing the source and destination "address" >>> TLVs to source and destination "identifier" TLVs. >>> >>> We will also be correcting the reference to DSMAP, >>> and DDMAP, address TLVs (which is incorrect, because the >>> format for DSMAP/DDMAP doesn't include a "length" field). >>> >>> The format of the Downstream Mapping (DSMAP) TLV is >>> defined in RFC 4379, and we are not changing the format >>> of that TLV. >>> >>> These changes are driven by last call comments we >>> have already received (see Joel Halpern's comments on the >>> mailing list) and are - in part - to correct accidental >>> use of the word "address" for source and destination >>> identifier TLVs (which is what we had discussed before >>> I generated the -03 version among the authors of several >>> of the current set of MPLS-TP drafts). >>> >>> In the case of source and destination identifiers, >>> these will be used exclusively to verify that an OAM PDU >>> has been correctly received by its intended recipient. >>> Because this is an on-demand connectivity verification >>> protocol, that is expected to be used only on those >>> occasions when there is a network problem that needs to >>> be diagnosed, and the information is not seen (and not >>> visible - without layer violations), optimizing these >>> objects for software makes sense. >>> >>> In addition, since either may be included (which >>> includes the possibility of including both), it is the >>> case already that we would then need to decide which is >>> to go first - assuming we wanted to do this (which we >>> do not). >>> >>> -- >>> Eric >>> >>> -----Original Message----- >>> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >>> Sent: Monday, March 28, 2011 8:11 AM >>> To: Eric Gray; Rolf.Winter@neclab.eu >>> Cc: mpls@ietf.org >>> Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp-on- >>> demand-cv-03 >>> Importance: High >>> >>> Hi Eric and Rolf, >>> >>> I'm sorry for interrupting. >>> >>> I agree with Rolf regarding the per-interface MIP discussion. >>> We have to consider the HW implementation aspect, >>> because trapping of an OAM packet is HW rule/functionality even in >>> routers. >>> >>> If every OAM packet is trapped to CPU >>> and the OAM packets which should NOT be processed in the Interface >>> are returned to Data-plane, >>> it is different forwarding path from user packets, >>> which is NOT the Connectivity Verification of the user path. >>> >>> Therefore, we should take the HW aspect and flexibilty into account >>> concurrently. >>> If an address TLV MUST be the first in TLVs, >>> it is enough to make HW implementation easy. >>> >>> BR, >>> Hideki >>> >>> >>> >>>> Rolf, >>>> >>>> The words you propose are okay with me. >>>> >>>> I thought the MIP/interface and address location issues >>>> were separate. >>>> >>>> I've personally had problems with protocol specifications >>>> that require ordering of TLVs. In particular, this is not very >>>> robust in terms of "future-proofing." What happens if new TLVs >>>> are added later on; for instance, suppose at some point we have >>>> multiple "address" TLVs? >>>> >>>> Also, the fact that implementations are allowed to attach >>>> TLVs in any arbitrary order allows considerable flexibilty in >>>> implementation. Messages can be built in arbitrarily many ways. >>>> This too can be a future-proofing issue. >>>> >>>> I would prefer not to start down the road of requiring a >>>> subset of TLVs to appear in a certain order, and saying we have >>>> one TLV that needs to be first is doing just that. >>>> >>>> -- >>>> Eric >>>> >>>> -----Original Message----- >>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >>>> Sent: Monday, March 28, 2011 6:19 AM >>>> To: Eric Gray >>>> Cc: mpls@ietf.org >>>> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >>> demand-cv-03 >>>> Importance: High >>>> >>>> Hi, >>>> >>>> I still think there is a logical error. Let me explain. In case there >>> is no IP you simply cannot use it. You say you could enable IP but then >>> that is not a case where there is no IP. In order to be constructive >>> here is a text change suggestion: >>>> >>>> "In certain MPLS-TP deployment scenarios IP addressing might not be >>> available. In those cases On-demand CV and/or route tracing MUST be run >>> without IP addressing, using the ACH channel type specified in Section >>> 3. In other cases it might be available, however, it may be preferred >>> to use some form of non-IP encapsulation. In those cases, the >>> procedures as outlined in section 3 SHOULD also be used." >>>> >>>> Regarding the per-interface MIP discussion. The HW aspect also popped >>> up in the PWE3 session and I think this is an important consideration, >>> in particular for OAM. Even if we talk about TLVs, we could make it a >>> MUST that an Address TLV is always the first one to appear. If you can >>> facilitate an easy implementation in hardware, I see no reason to >>> deliberately not do it. >>>> >>>> Best, >>>> >>>> Rolf >>>> >>>> >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>> London W3 6BL | Registered in England 2832014 >>>> >>>> >>>>> -----Original Message----- >>>>> From: Eric Gray [mailto:eric.gray@ericsson.com] >>>>> Sent: Montag, 28. März 2011 11:43 >>>>> To: Rolf Winter >>>>> Cc: loa@pi.nu; mpls@ietf.org >>>>> Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >>>>> demand-cv-03 >>>>> >>>>> Rolf, >>>>> >>>>> With regard to the use of SHOULD (verses MUST) - the intent >>>>> (according to RFC 2119 - see the quote below) is consistent with >>>>> this case. If - for some reason - one had a really good reason to >>>>> use IP addressing in some specific case, one could take steps to >>>>> make IP addressing available. >>>>> >>>>> This could be said to introduce a logical disconnect, but we >>>>> are saved from going down that path by the fact that the statement >>>>> also includes the case where (for some reason) there is a case in >>>>> which some other addressing scheme might be preferred. In many of >>>>> the cases where another addressing scheme may be preferred, it is >>>>> still possible (in fact likely) that IP addressing is available. >>>>> >>>>> Otherwise, it would not have been necessary to distinguish >>>>> this case from the one in which IP addressing is not available. >>>>> >>>>> For the case where IP addressing is not the preferred mode, >>>>> we are recommending a mode in which it is not necessary. >>>>> >>>>> With regard to having addresses located in the same place, >>>>> this protocol is meant for connectivity testing on an on-demand >>>>> basis and is therefore not optimized for processing in hardware. >>>>> >>>>> Whether addresses or identifiers, if we are talking about >>>>> TLV contents, there are issues with trying to guarantee location >>>>> of specific content, because of the fact that the TLV in question >>>>> will probably follow other TLVs - thus making locations difficult >>>>> to predict in any case. >>>>> >>>>> With regard to needing more text on per-interface MIPs, do >>>>> you have specific suggestions as to what text we might add? >>>>> >>>>> I understand (from discussion with WG chairs) that we are >>>>> not allowed to explicitly address last call comments during the >>>>> IETF meeting in Prague, because the last call is still ongoing >>>>> at that time. >>>>> >>>>> -- >>>>> Eric >>>>> >>>>> PS - >>>>> From RFC 2119 - >>>>> 'SHOULD This word, or the adjective "RECOMMENDED", mean that there >>>>> may exist valid reasons in particular circumstances to >>>>> ignore a particular item, but the full implications must >>>>> be understood and carefully weighed before choosing a >>>>> different course.' >>>>> >>>>> -----Original Message----- >>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>> Of >>>>> Rolf Winter >>>>> Sent: Tuesday, March 22, 2011 4:57 AM >>>>> To: loa@pi.nu; mpls@ietf.org >>>>> Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >>>>> demand-cv-03 >>>>> >>>>> Hi, >>>>> >>>>> some comments below: >>>>> >>>>> Section 1.3 says: " In certain MPLS-TP deployment scenarios IP >>>>> addressing might not be >>>>> available or it may be preferred to use some form of non-IP >>>>> encapsulation for On-demand CV, route tracing and BFD packets. >>> In >>>>> such scenarios, On-demand CV and/or route tracing SHOULD be run >>>>> without IP addressing..." >>>>> >>>>> I am not sure the "SHOULD" is right here. If no IP addressing is >>>>> available, this thing MUST be run without IP addressing, mustn't it? >>>>> >>>>> I think some additional text regarding per-interface MIP addressing >>>>> would be nice. As far as I understand the document, all TLVs will be >>>>> inside the LSP ping packet (rather than as ACH TLVs). >>>>> >>>>> Some people had concerns earlier, that addressing information should >>> be >>>>> in a fixed location for easier processing. Is this the case here I >>>>> wonder? >>>>> >>>>> It would be nice if you could address this in your presentation in >>>>> Prague. >>>>> >>>>> Thanks, >>>>> >>>>> Rolf >>>>> >>>>> >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>>>> London W3 6BL | Registered in England 2832014 >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>> Behalf >>>>> Of >>>>>> loa@pi.nu >>>>>> Sent: Mittwoch, 16. März 2011 00:26 >>>>>> To: mpls@ietf.org >>>>>> Cc: MPLS-TP ad hoc team >>>>>> Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- >>>>> demand- >>>>>> cv-03 >>>>>> >>>>>> Working Group, >>>>>> >>>>>> this is to start a 3 week working group last call on >>>>>> >>>>>> draft-ietf-mpls-tp-on-demand-cv-03 >>>>>> >>>>>> Please send comments to the working group mailing list >>>>>> mpls@ietf.org >>>>>> >>>>>> The working group last call ends on April 8, 2011. >>>>>> >>>>>> /Loa >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- ************************************** Yoshinori Koike Optical Transmission Systems Development Project First Promotion Project NTT Network Service Systems Laboratories NIPPON TELEGRAPH AND TELEPHONE CORPORATION Telephone: +81 422 59 6723 Facsimile: +81 422 59 3494 Email: koike.yoshinori@lab.ntt.co.jp ************************************** _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From curtis@occnc.com Thu Mar 31 01:42:40 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D5C28C19A for ; Thu, 31 Mar 2011 01:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] 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 CLaR1+MwHgYD for ; Thu, 31 Mar 2011 01:42:38 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 1F07328C0E1 for ; Thu, 31 Mar 2011 01:42:38 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p2V8i8AW047762; Thu, 31 Mar 2011 04:44:08 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201103310844.p2V8i8AW047762@harbor.orleans.occnc.com> To: Alexander Vainshtein From: Curtis Villamizar In-reply-to: Your message of "Thu, 31 Mar 2011 08:43:53 +0200." Date: Thu, 31 Mar 2011 04:44:08 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , "Manuel.Paul@telekom.de" , "Rolf.Winter@neclab.eu" Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-tp-on-demand-cv- X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 08:42:40 -0000 In message Alexander Vainshtein writes: > > Hideki, Eric, and all, > > I believe that ability to do ping MEP-to-MIP should not be precluded (at least for co-routed bidirectional LSPs). > > Regards, > Sasha Sasha, Ping to a MIP is effectively traceroute. Think of it as addressing the Nth node (using TTL), where a common case is where the Nth node identifies itself, but where other OAM riding on ping encapsulation could also be carried. Curtis > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > hideki.endo.es@hitachi.com > > Sent: Thursday, March 31, 2011 8:24 AM > > To: mpls@ietf.org; eric.gray@ericsson.com; aldrin.ietf@gmail.com > > Cc: Manuel.Paul@telekom.de; Rolf.Winter@neclab.eu > > Subject: Re: [mpls] Working Group LasCallondraft-ietf-mpls-tp-on- > > demand-cv- > > > > Hi Eric and Sam, > > > > I'm sorry for my incorrect understanding on DSMAP TLV. > > According to Sam, We can use DSMAP in both of ping and trace route. > > > > However, I have a concern. > > Eric, you said; > > > Ping mode would be strictly MEP-to-MEP. At least, that > > >is the way it is intended to work in our draft. > > > > On the other hand, RFC5860, MPLS-TP OAM reqs, says; > > 2.2.3. Connectivity Verifications > > > > This function SHOULD be performed on-demand between End Points and > > Intermediate Points of PWs and LSPs, and between End Points of PWs, > > LSPs, and Sections. > > > > and; > > > > 2.2.4. Route Tracing > > > > This function SHOULD be performed on-demand. > > > > This function SHOULD be performed between End Points and > > Intermediate > > Points of PWs and LSPs, and between End Points of PWs, LSPs, and > > Sections. > > > > Why do you restrict ping mode to only for between MEPs? > > Do you mean that On-demand CV doesn't satisfy all of OAM reqs? > > > > BR, > > Hideki > > > > >Hideki, > > > > > > Ping mode would be strictly MEP-to-MEP. At least, that > > >is the way it is intended to work in our draft. > > > > > > Why would you need per-interface MIP information in this > > >case? > > > > > > If someone wanted to do LSP-Ping to a specific interface, > > >I am uncertain why it would be incorrect to use the DSMAP TLV. > > > > > >-- > > >Eric > > > > > >-----Original Message----- > > >From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] > > >Sent: Wednesday, March 30, 2011 5:43 PM > > >To: Eric Gray; mpls@ietf.org > > >Cc: Rolf.Winter@neclab.eu; Manuel.Paul@telekom.de > > >Subject: Re[2]: Re[2]: [mpls] Working Group Las Callondraft-ietf-mpls- > > tp-on-demand-cv-03 > > >Importance: High > > > > > >Eric, > > > > > >In my understanding, DSMAP TLV is only for trace route, isn't it? > > >We need specific interface information for ping mode of on-demand CV. > > > > > >BR, > > >Hideki > > > > > >>Hideki, > > >> > > >> If you want to include specific interface information, > > >>you can include a DSMAP (or DDMAP) TLV as defined by RFC > > >>4379, and extended by this draft (in combination with the > > >>draft "draft-ietf-mpls-lsp-ping-enhanced-dsmap" for DDMAP). > > >> > > >> Would this not do what you're looking for? > > >> > > >>-- > > >>Eric > > >> > > >>-----Original Message----- > > >>From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] > > >>Sent: Wednesday, March 30, 2011 11:33 AM > > >>To: Rolf.Winter@neclab.eu; Eric Gray; mpls@ietf.org; > > Manuel.Paul@telekom.de > > >>Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls-tp- > > on-demand-cv-03 > > >>Importance: High > > >> > > >>Hi, > > >> > > >>I have one comment on IDs in draft-on-demand-cv. > > >>The interface-D is missing in the current draft, there is only Node- > > ID. > > >>You need at least the interface ID to support per-interface MIP. > > >> > > >>BR, > > >>Hideki > > >> > > >>> > > >>>Dear All, > > >>> > > >>>I really appreciate the consideration on the per-interface MIP > > support and the discussion moving forward. > > >>> > > >>> > > >>>From an operator's perspective, it is very important that the > > support for per-interface MIPs is covered by the definitions. > > >>> > > >>>Looking at earlier versions of draft-farrel-mpls-tp-mip-mep-map, > > there was already a solution proposal, using the TTL. Enhanced > > solutions have been thorougly discussed during this IETF meeting. It it > > to be expected that there will be ways to solve both the fast path and > > fate-sharing requirement. > > >>> > > >>> > > >>>I second the proposal initially made by Rolf, to include additional > > text to document the per-interface MIP addressing for the on-demand-cv > > and for other OAM tools. > > >>> > > >>> > > >>>Best regards, > > >>>Manuel > > >>> > > >>> > > >>>Deutsche Telekom AG > > >>>Group Technology > > >>>Manuel Paul > > >>>SA3-11 > > >>>Goslarer Ufer 35-37, 10589 Berlin > > >>>+49 30 3497 - 4394 (Tel.) > > >>>+49 30 3497 - 4956 (Fax) > > >>>+49 171 8634032 (Mobil) > > >>>E-Mail: mailto:manuel.paul@telekom.de > > >>>http://www.telekom.com > > >>> > > >>>> -----Original Message----- > > >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf Of > > >>>> Rolf Winter > > >>>> Sent: Monday, March 28, 2011 3:03 PM > > >>>> To: Eric Gray; hideki.endo.es@hitachi.com > > >>>> Cc: mpls@ietf.org > > >>>> Subject: Re: [mpls] Working Group Las Call ondraft-ietf-mpls-tp- > > on-demand- > > >>>> cv-03 > > >>>> > > >>>> Eric, > > >>>> > > >>>> I generally agree but I think there is one case actually which > > needs a > > >>>> closer look in this regard (which I hinted at earlier), which are > > the per- > > >>>> interface MIPs. Your TTL expires (the actual addressing bit here), > > the > > >>>> identifier tells you it is not intended for the ingress MIP, so it > > needs > > >>>> to be forwarded to the egress MIP through the forwarding engine. > > Now if > > >>>> you pull the packet out of the fast path and inject it back in, is > > the OAM > > >>>> packet still fate sharing? If you can do this in HW on the line > > card, then > > >>>> it will and it will just be forwarded as normal. I know this is a > > >>>> different draft, but this will be in particular important for > > performance > > >>>> monitoring. > > >>>> > > >>>> Best, > > >>>> > > >>>> Rolf > > >>>> > > >>>> > > >>>> > > >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria > > Road, London > > >>>> W3 6BL | Registered in England 2832014 > > >>>> > > >>>> > > >>>> > -----Original Message----- > > >>>> > From: Eric Gray [mailto:eric.gray@ericsson.com] > > >>>> > Sent: Montag, 28. März 2011 14:45 > > >>>> > To: hideki.endo.es@hitachi.com; Rolf Winter > > >>>> > Cc: mpls@ietf.org > > >>>> > Subject: RE: Re[2]: [mpls] Working Group Las Call ondraft-ietf- > > mpls-tp- > > >>>> > on-demand-cv-03 > > >>>> > > > >>>> > Hideki, > > >>>> > > > >>>> > What you're saying is true, but not relevant in this > > >>>> > case. The "addresses" in this discussion are not used to > > >>>> > determine how to forward OAM packets. They are used only > > >>>> > by the recipient MIP/MEP to verify that the OAM packet was > > >>>> > properly delivered. > > >>>> > > > >>>> > By the way, this discussion is an indication of the > > >>>> > confusing injected by calling these things addresses. My > > >>>> > mistake and I bring it up now to help to stem the tide of > > >>>> > further comments resulting from that confusion. > > >>>> > > > >>>> > In the version we post after last call is complete, > > >>>> > we will be changing the source and destination "address" > > >>>> > TLVs to source and destination "identifier" TLVs. > > >>>> > > > >>>> > We will also be correcting the reference to DSMAP, > > >>>> > and DDMAP, address TLVs (which is incorrect, because the > > >>>> > format for DSMAP/DDMAP doesn't include a "length" field). > > >>>> > > > >>>> > The format of the Downstream Mapping (DSMAP) TLV is > > >>>> > defined in RFC 4379, and we are not changing the format > > >>>> > of that TLV. > > >>>> > > > >>>> > These changes are driven by last call comments we > > >>>> > have already received (see Joel Halpern's comments on the > > >>>> > mailing list) and are - in part - to correct accidental > > >>>> > use of the word "address" for source and destination > > >>>> > identifier TLVs (which is what we had discussed before > > >>>> > I generated the -03 version among the authors of several > > >>>> > of the current set of MPLS-TP drafts). > > >>>> > > > >>>> > In the case of source and destination identifiers, > > >>>> > these will be used exclusively to verify that an OAM PDU > > >>>> > has been correctly received by its intended recipient. > > >>>> > Because this is an on-demand connectivity verification > > >>>> > protocol, that is expected to be used only on those > > >>>> > occasions when there is a network problem that needs to > > >>>> > be diagnosed, and the information is not seen (and not > > >>>> > visible - without layer violations), optimizing these > > >>>> > objects for software makes sense. > > >>>> > > > >>>> > In addition, since either may be included (which > > >>>> > includes the possibility of including both), it is the > > >>>> > case already that we would then need to decide which is > > >>>> > to go first - assuming we wanted to do this (which we > > >>>> > do not). > > >>>> > > > >>>> > -- > > >>>> > Eric > > >>>> > > > >>>> > -----Original Message----- > > >>>> > From: hideki.endo.es@hitachi.com > > [mailto:hideki.endo.es@hitachi.com] > > >>>> > Sent: Monday, March 28, 2011 8:11 AM > > >>>> > To: Eric Gray; Rolf.Winter@neclab.eu > > >>>> > Cc: mpls@ietf.org > > >>>> > Subject: Re[2]: [mpls] Working Group Las Call ondraft-ietf-mpls- > > tp-on- > > >>>> > demand-cv-03 > > >>>> > Importance: High > > >>>> > > > >>>> > Hi Eric and Rolf, > > >>>> > > > >>>> > I'm sorry for interrupting. > > >>>> > > > >>>> > I agree with Rolf regarding the per-interface MIP discussion. > > >>>> > We have to consider the HW implementation aspect, > > >>>> > because trapping of an OAM packet is HW rule/functionality even > > in > > >>>> > routers. > > >>>> > > > >>>> > If every OAM packet is trapped to CPU > > >>>> > and the OAM packets which should NOT be processed in the > > Interface > > >>>> > are returned to Data-plane, > > >>>> > it is different forwarding path from user packets, > > >>>> > which is NOT the Connectivity Verification of the user path. > > >>>> > > > >>>> > Therefore, we should take the HW aspect and flexibilty into > > account > > >>>> > concurrently. > > >>>> > If an address TLV MUST be the first in TLVs, > > >>>> > it is enough to make HW implementation easy. > > >>>> > > > >>>> > BR, > > >>>> > Hideki > > >>>> > > > >>>> > > > >>>> > > > >>>> > >Rolf, > > >>>> > > > > >>>> > > The words you propose are okay with me. > > >>>> > > > > >>>> > > I thought the MIP/interface and address location issues > > >>>> > >were separate. > > >>>> > > > > >>>> > > I've personally had problems with protocol specifications > > >>>> > >that require ordering of TLVs. In particular, this is not very > > >>>> > >robust in terms of "future-proofing." What happens if new TLVs > > >>>> > >are added later on; for instance, suppose at some point we have > > >>>> > >multiple "address" TLVs? > > >>>> > > > > >>>> > > Also, the fact that implementations are allowed to attach > > >>>> > >TLVs in any arbitrary order allows considerable flexibilty in > > >>>> > >implementation. Messages can be built in arbitrarily many > > ways. > > >>>> > >This too can be a future-proofing issue. > > >>>> > > > > >>>> > > I would prefer not to start down the road of requiring a > > >>>> > >subset of TLVs to appear in a certain order, and saying we have > > >>>> > >one TLV that needs to be first is doing just that. > > >>>> > > > > >>>> > >-- > > >>>> > >Eric > > >>>> > > > > >>>> > >-----Original Message----- > > >>>> > >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > > >>>> > >Sent: Monday, March 28, 2011 6:19 AM > > >>>> > >To: Eric Gray > > >>>> > >Cc: mpls@ietf.org > > >>>> > >Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls- > > tp-on- > > >>>> > demand-cv-03 > > >>>> > >Importance: High > > >>>> > > > > >>>> > >Hi, > > >>>> > > > > >>>> > >I still think there is a logical error. Let me explain. In case > > there > > >>>> > is no IP you simply cannot use it. You say you could enable IP > > but then > > >>>> > that is not a case where there is no IP. In order to be > > constructive > > >>>> > here is a text change suggestion: > > >>>> > > > > >>>> > >"In certain MPLS-TP deployment scenarios IP addressing might > > not be > > >>>> > available. In those cases On-demand CV and/or route tracing MUST > > be run > > >>>> > without IP addressing, using the ACH channel type specified in > > Section > > >>>> > 3. In other cases it might be available, however, it may be > > preferred > > >>>> > to use some form of non-IP encapsulation. In those cases, the > > >>>> > procedures as outlined in section 3 SHOULD also be used." > > >>>> > > > > >>>> > >Regarding the per-interface MIP discussion. The HW aspect also > > popped > > >>>> > up in the PWE3 session and I think this is an important > > consideration, > > >>>> > in particular for OAM. Even if we talk about TLVs, we could make > > it a > > >>>> > MUST that an Address TLV is always the first one to appear. If > > you can > > >>>> > facilitate an easy implementation in hardware, I see no reason > > to > > >>>> > deliberately not do it. > > >>>> > > > > >>>> > >Best, > > >>>> > > > > >>>> > >Rolf > > >>>> > > > > >>>> > > > > >>>> > >NEC Europe Limited | Registered Office: NEC House, 1 Victoria > > Road, > > >>>> > London W3 6BL | Registered in England 2832014 > > >>>> > > > > >>>> > > > > >>>> > >> -----Original Message----- > > >>>> > >> From: Eric Gray [mailto:eric.gray@ericsson.com] > > >>>> > >> Sent: Montag, 28. März 2011 11:43 > > >>>> > >> To: Rolf Winter > > >>>> > >> Cc: loa@pi.nu; mpls@ietf.org > > >>>> > >> Subject: RE: [mpls] Working Group Las Call on draft-ietf- > > mpls-tp-on- > > >>>> > >> demand-cv-03 > > >>>> > >> > > >>>> > >> Rolf, > > >>>> > >> > > >>>> > >> With regard to the use of SHOULD (verses MUST) - the > > intent > > >>>> > >> (according to RFC 2119 - see the quote below) is consistent > > with > > >>>> > >> this case. If - for some reason - one had a really good > > reason to > > >>>> > >> use IP addressing in some specific case, one could take steps > > to > > >>>> > >> make IP addressing available. > > >>>> > >> > > >>>> > >> This could be said to introduce a logical disconnect, > > but we > > >>>> > >> are saved from going down that path by the fact that the > > statement > > >>>> > >> also includes the case where (for some reason) there is a > > case in > > >>>> > >> which some other addressing scheme might be preferred. In > > many of > > >>>> > >> the cases where another addressing scheme may be preferred, > > it is > > >>>> > >> still possible (in fact likely) that IP addressing is > > available. > > >>>> > >> > > >>>> > >> Otherwise, it would not have been necessary to > > distinguish > > >>>> > >> this case from the one in which IP addressing is not > > available. > > >>>> > >> > > >>>> > >> For the case where IP addressing is not the preferred > > mode, > > >>>> > >> we are recommending a mode in which it is not necessary. > > >>>> > >> > > >>>> > >> With regard to having addresses located in the same > > place, > > >>>> > >> this protocol is meant for connectivity testing on an on- > > demand > > >>>> > >> basis and is therefore not optimized for processing in > > hardware. > > >>>> > >> > > >>>> > >> Whether addresses or identifiers, if we are talking > > about > > >>>> > >> TLV contents, there are issues with trying to guarantee > > location > > >>>> > >> of specific content, because of the fact that the TLV in > > question > > >>>> > >> will probably follow other TLVs - thus making locations > > difficult > > >>>> > >> to predict in any case. > > >>>> > >> > > >>>> > >> With regard to needing more text on per-interface > > MIPs, do > > >>>> > >> you have specific suggestions as to what text we might add? > > >>>> > >> > > >>>> > >> I understand (from discussion with WG chairs) that we > > are > > >>>> > >> not allowed to explicitly address last call comments during > > the > > >>>> > >> IETF meeting in Prague, because the last call is still > > ongoing > > >>>> > >> at that time. > > >>>> > >> > > >>>> > >> -- > > >>>> > >> Eric > > >>>> > >> > > >>>> > >> PS - > > >>>> > >> From RFC 2119 - > > >>>> > >> 'SHOULD This word, or the adjective "RECOMMENDED", mean > > that there > > >>>> > >> may exist valid reasons in particular circumstances > > to > > >>>> > >> ignore a particular item, but the full implications > > must > > >>>> > >> be understood and carefully weighed before choosing > > a > > >>>> > >> different course.' > > >>>> > >> > > >>>> > >> -----Original Message----- > > >>>> > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf > > >>>> > Of > > >>>> > >> Rolf Winter > > >>>> > >> Sent: Tuesday, March 22, 2011 4:57 AM > > >>>> > >> To: loa@pi.nu; mpls@ietf.org > > >>>> > >> Subject: Re: [mpls] Working Group Las Call on draft-ietf- > > mpls-tp-on- > > >>>> > >> demand-cv-03 > > >>>> > >> > > >>>> > >> Hi, > > >>>> > >> > > >>>> > >> some comments below: > > >>>> > >> > > >>>> > >> Section 1.3 says: " In certain MPLS-TP deployment scenarios > > IP > > >>>> > >> addressing might not be > > >>>> > >> available or it may be preferred to use some form of non- > > IP > > >>>> > >> encapsulation for On-demand CV, route tracing and BFD > > packets. > > >>>> > In > > >>>> > >> such scenarios, On-demand CV and/or route tracing SHOULD > > be run > > >>>> > >> without IP addressing..." > > >>>> > >> > > >>>> > >> I am not sure the "SHOULD" is right here. If no IP addressing > > is > > >>>> > >> available, this thing MUST be run without IP addressing, > > mustn't it? > > >>>> > >> > > >>>> > >> I think some additional text regarding per-interface MIP > > addressing > > >>>> > >> would be nice. As far as I understand the document, all TLVs > > will be > > >>>> > >> inside the LSP ping packet (rather than as ACH TLVs). > > >>>> > >> > > >>>> > >> Some people had concerns earlier, that addressing information > > should > > >>>> > be > > >>>> > >> in a fixed location for easier processing. Is this the case > > here I > > >>>> > >> wonder? > > >>>> > >> > > >>>> > >> It would be nice if you could address this in your > > presentation in > > >>>> > >> Prague. > > >>>> > >> > > >>>> > >> Thanks, > > >>>> > >> > > >>>> > >> Rolf > > >>>> > >> > > >>>> > >> > > >>>> > >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria > > Road, > > >>>> > >> London W3 6BL | Registered in England 2832014 > > >>>> > >> > > >>>> > >> > > >>>> > >> > -----Original Message----- > > >>>> > >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > > On > > >>>> > Behalf > > >>>> > >> Of > > >>>> > >> > loa@pi.nu > > >>>> > >> > Sent: Mittwoch, 16. März 2011 00:26 > > >>>> > >> > To: mpls@ietf.org > > >>>> > >> > Cc: MPLS-TP ad hoc team > > >>>> > >> > Subject: [mpls] Working Group Las Call on draft-ietf-mpls- > > tp-on- > > >>>> > >> demand- > > >>>> > >> > cv-03 > > >>>> > >> > > > >>>> > >> > Working Group, > > >>>> > >> > > > >>>> > >> > this is to start a 3 week working group last call on > > >>>> > >> > > > >>>> > >> > draft-ietf-mpls-tp-on-demand-cv-03 > > >>>> > >> > > > >>>> > >> > Please send comments to the working group mailing list > > >>>> > >> > mpls@ietf.org > > >>>> > >> > > > >>>> > >> > The working group last call ends on April 8, 2011. > > >>>> > >> > > > >>>> > >> > /Loa > > >>>> > >> > > > >>>> > >> > > > >>>> > >> > > > >>>> > >> > > > >>>> > >> > _______________________________________________ > > >>>> > >> > mpls mailing list > > >>>> > >> > mpls@ietf.org > > >>>> > >> > https://www.ietf.org/mailman/listinfo/mpls > > >>>> > >> _______________________________________________ > > >>>> > >> mpls mailing list > > >>>> > >> mpls@ietf.org > > >>>> > >> https://www.ietf.org/mailman/listinfo/mpls > > >>>> > >_______________________________________________ > > >>>> > >mpls mailing list > > >>>> > >mpls@ietf.org > > >>>> > >https://www.ietf.org/mailman/listinfo/mpls > > >>>> > > > > >>>> _______________________________________________ > > >>>> mpls mailing list > > >>>> mpls@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/mpls > > >>> > > >> > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Robert.Rennison@ecitele.com Thu Mar 31 02:00:10 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4500A3A6AD5 for ; Thu, 31 Mar 2011 02:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 mGD4yrxWrP7l for ; Thu, 31 Mar 2011 02:00:08 -0700 (PDT) Received: from uspitbmg01.ecitele.com (uspitbmg01-out.ecitele.com [63.94.127.136]) by core3.amsl.com (Postfix) with ESMTP id 474D43A6969 for ; Thu, 31 Mar 2011 02:00:08 -0700 (PDT) X-AuditID: 3f5e7f87-b7cbcae000003bbc-a9-4d946a456890 Received: from uspitexch01.ecitele.com ( [10.0.0.71]) by uspitbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id B9.00.15292.54A649D4; Thu, 31 Mar 2011 07:49:26 -0400 (EDT) Received: from USPITMAIL01.ecitele.com ([10.0.0.81]) by uspitexch01.ecitele.com ([10.0.0.71]) with mapi; Thu, 31 Mar 2011 05:01:47 -0400 From: Robert Rennison To: Alexander Vainshtein , Shahram Davari Date: Thu, 31 Mar 2011 05:01:42 -0400 Thread-Topic: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03: Poll /Final Issues Thread-Index: AcvDrJpCvXJpavHRRhKBBXlDzw1/zAFFYIGQABGDQCAAAKcQEAACic4AAAbIaBADxnLswAAif0NABan8h6A= Message-ID: <786AD2EC3D80A1428B921CDC9BE9EE5466F24A5B28@USPITMAIL01.ecitele.com> References: <4D4AB81D.3080907@pi.nu> <06c901cbc8d4$d682a820$8387f860$@com> <60C093A41B5E45409A19D42CF7786DFD51CDF3F790@EUSAACMS0703.eamcs.ericsson.se> <2C2F1EBA8050E74EA81502D5740B4BD6956BBA178B@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03: Poll /Final Issues X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 09:00:10 -0000 Authors, The Poll/Final issue is still open with this document and I'd like to reit= erate one point but also understand a technicality/feasibility =20 1. An observation/ objection: It becomes yet another configuration subtly /= scope for error in needing to know" does the remote end of this PW support= P/F or not". Additionally we are now changing the BFD state machine and= complicating things to pander to the "perception" that P/F is _unnecessari= ly_ complex. Ok Off soapbox, now to my question. I'd like to understand how folks who wa= nt to run without the P/F mechanism envisage things working. If both ends can permanently "blast" at the preconfigured rate and set the = STA bits to say Init (what the Sta should be set to for this always fixed r= ate should be made clear) then I can see how both ends will transition to "= Up" and this is what I figured was how things would happen. However; in mor= e careful reading of the draft I see the following contradictory statement= s. 3.5. BFD Profile for MPLS-TP=20 BFD MUST operate in asynchronous mode. In this mode, the BFD Control=20 packets are periodically sent at configurable time rate. This rate is=20 typically a _fixed_ value for the lifetime of the session. In the rare=20 circumstance where an operator has a reason to change session=20 parameters, the session MUST be moved to the ADMIN DOWN state.=20 Poll/final discipline can only used for VCCV and UDP/IP encapsulated=20 BFD. Here we are saying things are sent at a fixed rate. ------------ 3.5.1. Session initiation=20 .... Otherwise once a transition from DOWN to INIT has occurred, the=20 session progresses as per [4]. In both the DOWN and INIT states=20 messages are transmitted at a rate of one per second and the defect=20 detection interval is fixed at 3.5 seconds. On transition to the UP=20 state, message periodicity _changes to_ the negotiated and/or=20 configured rate and the detect interval switches to detect multiplier=20 times the session peer's Tx Rate ------------ Here we are talking about the rate changing to the configured rate, and the= re is no distinguishing between whterh P/F is used or not; it's this chang= e of rate that I cannot see easily working without the P/F Paradoxically the so called "complex" poll/final is necessary not just to = change the rate due to some operational nicety but to allow us to coordina= te any rate changes, it's your friend once you understand it. Given the abo= ve statement of starting at some slow rate there will always need to be a r= ate change to get to any values other than a Tx interval of 1 second. Let's say I've made the transition from DOWN to INIT based on the reception= of a BFD control packet from the remote end. I now transition to the UP st= ate when receiving the next packet, I'm now expecting him to start sending = at the negotiated rate, however, in the absence of the remote end setting = the F bit to indicate he has programmed his HW to start sending at the prec= onfigured rate, I may unfairly/ prematurely declare the session down if he = has not jumped into UP state himself. Likewise the remote end may have this= problem with my transition too. In short, notwithstanding my objection to lack of P/F I'd like some further= clarification regarding how the rate change mechanism specified in the la= st para of 3.5.1 is expected to work without P/F. Or perhaps this para is = in error since it's inconsistent with the first para of 5.1 stating thing= s remain at a fixed rate. Cheers Rob Rennison -----Original Message----- From: Alexander Vainshtein=20 Sent: Wednesday, March 02, 2011 8:37 AM To: Shahram Davari Cc: mpls@ietf.org; mpls-tp@ietf.org; Robert Rennison; David Allan I Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv= -rdi-03 Shahram and all, Please see some comments inline below. Regards, Sasha > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Tuesday, March 01, 2011 9:55 PM > To: Alexander Vainshtein; David Allan I > Cc: mpls@ietf.org; mpls-tp@ietf.org; Robert Rennison > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03 >=20 > Hi, >=20 > I would like to support the disabling of Poll/Final for MPLS-TP LSP > BFDs. Transport networks don't need to change the rates and are mostly > static.=20 [[[Sasha]]] There are two different statements here IMO: 1. "Transport networks do not have to change the rates". Sounds very much like "transport networks are always single-vendor" to m= e. Because in a multi-vendor environment you have to deal with different ra= te ranges And have from time to time manipulate these rates... 2. "Transport networks are mostly static". I do not really understand how this is related to the subject. =20 Also Poll/Final will most likely require extra Software in > addition to HW, which can increase complexity and cost for MPLS-TP > operation. [[[Sasha]]] Extra SW (as opposed to extra HW) usually doesn't cost to the o= perators. And the vendors who have implemented Poll/Final will have to go into=20 new development and support two different BFD state machines... if this is = not expensive, what is? >=20 > Regards, > Shahram >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Alexander Vainshtein > Sent: Thursday, February 10, 2011 6:38 AM > To: David Allan I > Cc: mpls@ietf.org; mpls-tp@ietf.org; Robert Rennison > Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03 >=20 > Dave, and all, > To avoid any misinterpretation, please consider the original email as > my LC comment. >=20 > Regards, > Sasha >=20 >=20 > -----Original Message----- > From: Alexander Vainshtein > Sent: Thursday, February 10, 2011 1:36 PM > To: 'David Allan I' > Cc: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; Robert > Rennison > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03 >=20 > Dave and all, > I'd like to remind you that Rob and I have already questioned the > decision to change the BFD state machine by disabling in some case the > Poll/Final sequence. >=20 > The situation as presented in the draft seems to introduce even more > problems. > E.g., RFC 5885 allows to run BFD in VCCV without UDP/IP encapsulation > but follows the procedures specified in RFC 5880 and 5881 which, to the > best of my understanding, include usage of Poll/Final sequence. >=20 > It is my understanding that BFD for an MPLS-TP LSP would look exactly > as BFD in VCCV (including the same code point). > If this is correct, how should the implementation distinguish between > "PWE3 mode" (where poll/final are used) and "MPLS-TP mode where they > seem to be prohibited? >=20 > Regards, > Sasha >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > David Allan I > Sent: Thursday, February 10, 2011 1:09 PM > To: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; > ahmpls-tp@lists.itu.int > Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03 >=20 >=20 >=20 > Hi Mach: >=20 > Thanks for the review >=20 > >I read the draft, here are some comments, please consider: >=20 > >1.Section 3.5, last sentence of first paragraph >=20 > >"Poll/final discipline can only used for VCCV and UDP/IP encapsulated > BFD." > >There is a "be" lost between "can" and "only". >=20 > Good catch, will fix. >=20 > >2.Section 3.5.2 > >"1. BFD control packets are received with an unexpected encapsulation > (mis-connectivity defect), these include: > > - a PW receiving a packet with a GAL", Since GAL can be used > >for PW(http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw- > 00), this should not be a defect. Suggest to remove it. >=20 > We'll review and edit accordingly. >=20 > >3 Section 3.5.2 > >" 4. Receipt of an expected session discriminator with an unexpected > label (mis-connectivity defect).", For a receiver, how does it know > that the session >discriminator is valid but the label is invalid? > IMHO, this defect is just another description of defect 3 . Suggest to > remove it. >=20 > If the session discriminator exists in the BFD database, it is > superficially a valid descriminator but the label of arrival can be > incorrect. This may indicate an implementation problem at the source > MEP. What we were referring to in '3' was a session discriminator that > did not exist in the local database, BFD had never handed it out hence > it could not be found. >=20 > >4.Section 3.5.4.2 > >" Exit from a misconfiguration defect occurs when two consecutive CC > or > >CV frames have been received with the expected M bit setting." IMHO, > this sentence is little bit vague, and since this draft only defines > for P2P LSP, why not just say "...with M bit clear." >=20 > OK >=20 > >5. Section 3.5.4.3 > >"Exit from a mis-connectivity defect state occurs when no CV messages > >have been received with an incorrect source MEP-ID for a period of 3.5 > seconds.", since there are several defects listed in Section 3.5.2 and > this is only one condition for exiting from a mis-connectivity defect > state. How about "Exit >from a mis-connectivity defect state occurs > when no CV messages with mis-connectivity defects have been received > for a period of 3.5 seconds " >=20 > That seems to be more accurate, I'd replace "with...." with "indicating > an on-going mis-connectivity defect has been....". Simply wordsmithing. >=20 > >6. Section 3.5.5 >=20 > >In Figure 5, seems that it is lack of "AIS-LDI, LKR" inputs for DOWN > state. >=20 > Good catch. Will fix >=20 > Cheers > Dave >=20 >=20 >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > Behalf Of Loa Andersson > > Sent: Thursday, February 03, 2011 10:14 PM > > To: mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int > > Subject: [mpls-tp] mpls wg last call on > > draft-ietf-mpls-tp-cc-cv-rdi-03 > > > > Working Group, > > > > this is to start a four week working group last call on "Proactive > > Connectivity Verification, Continuity Check and Remote Defect > > indication for MPLS Transport Profile" > > (draft-ietf-mpls-tp-cc-cv-rdi-03.txt). > > > > Please send comments to the mpls-tp@ietf.org mailing list. > > > > This working group last call ends on February 28, 2011. > > > > > > Loa, George and Ross > > > > MPLS wg co-chairs > > -- > > > > > > Loa Andersson email: > > loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From david.i.allan@ericsson.com Thu Mar 31 02:08:34 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30A7A28C203 for ; Thu, 31 Mar 2011 02:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.379 X-Spam-Level: X-Spam-Status: No, score=-5.379 tagged_above=-999 required=5 tests=[AWL=1.220, 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 QgDh12dpVogV for ; Thu, 31 Mar 2011 02:08:32 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 3CE4C28C1FF for ; Thu, 31 Mar 2011 02:08:16 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p2V99pnW017054; Thu, 31 Mar 2011 04:09:52 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.203]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 31 Mar 2011 05:09:45 -0400 From: David Allan I To: Robert Rennison , Alexander Vainshtein , Shahram Davari Date: Thu, 31 Mar 2011 05:09:44 -0400 Thread-Topic: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03: Poll /Final Issues Thread-Index: AcvDrJpCvXJpavHRRhKBBXlDzw1/zAFFYIGQABGDQCAAAKcQEAACic4AAAbIaBADxnLswAAif0NABan8h6AAAbRRsA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD51D5311347@EUSAACMS0703.eamcs.ericsson.se> References: <4D4AB81D.3080907@pi.nu> <06c901cbc8d4$d682a820$8387f860$@com> <60C093A41B5E45409A19D42CF7786DFD51CDF3F790@EUSAACMS0703.eamcs.ericsson.se> <2C2F1EBA8050E74EA81502D5740B4BD6956BBA178B@SJEXCHCCR02.corp.ad.broadcom.com> <786AD2EC3D80A1428B921CDC9BE9EE5466F24A5B28@USPITMAIL01.ecitele.com> In-Reply-To: <786AD2EC3D80A1428B921CDC9BE9EE5466F24A5B28@USPITMAIL01.ecitele.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03: Poll /Final Issues X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 09:08:34 -0000 Hi Rob: The first paragraph of 3.5.1 describes the initialization. The intent is th= at an implementation that cannot support the requested periodicity in the I= NIT request will not transition from DOWN to INIT and returns a diagnostic = code accordingly. The premise is that the periodicity is a business require= ment hence the negotiation is binary. As for the contradictory statements, it is a fixed rate for the UP state fo= r the life of the session would be more precise wording.... Hope this helps Dave =20 -----Original Message----- From: Robert Rennison [mailto:Robert.Rennison@ecitele.com]=20 Sent: Thursday, March 31, 2011 11:02 AM To: Alexander Vainshtein; Shahram Davari Cc: mpls@ietf.org; David Allan I Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv= -rdi-03: Poll /Final Issues Authors, The Poll/Final issue is still open with this document and I'd like to reit= erate one point but also understand a technicality/feasibility =20 1. An observation/ objection: It becomes yet another configuration subtly /= scope for error in needing to know" does the remote end of this PW support= P/F or not". Additionally we are now changing the BFD state machine and= complicating things to pander to the "perception" that P/F is _unnecessari= ly_ complex. Ok Off soapbox, now to my question. I'd like to understand how folks who wa= nt to run without the P/F mechanism envisage things working. If both ends can permanently "blast" at the preconfigured rate and set the = STA bits to say Init (what the Sta should be set to for this always fixed r= ate should be made clear) then I can see how both ends will transition to "= Up" and this is what I figured was how things would happen. However; in mor= e careful reading of the draft I see the following contradictory statement= s. 3.5. BFD Profile for MPLS-TP=20 BFD MUST operate in asynchronous mode. In this mode, the BFD Control=20 packets are periodically sent at configurable time rate. This rate is=20 typically a _fixed_ value for the lifetime of the session. In the rare=20 circumstance where an operator has a reason to change session=20 parameters, the session MUST be moved to the ADMIN DOWN state.=20 Poll/final discipline can only used for VCCV and UDP/IP encapsulated=20 BFD. Here we are saying things are sent at a fixed rate. ------------ 3.5.1. Session initiation .... Otherwise once a transition from DOWN to INIT has occurred, the=20 session progresses as per [4]. In both the DOWN and INIT states=20 messages are transmitted at a rate of one per second and the defect=20 detection interval is fixed at 3.5 seconds. On transition to the UP=20 state, message periodicity _changes to_ the negotiated and/or=20 configured rate and the detect interval switches to detect multiplier=20 times the session peer's Tx Rate ------------ Here we are talking about the rate changing to the configured rate, and the= re is no distinguishing between whterh P/F is used or not; it's this chang= e of rate that I cannot see easily working without the P/F Paradoxically the so called "complex" poll/final is necessary not just to = change the rate due to some operational nicety but to allow us to coordina= te any rate changes, it's your friend once you understand it. Given the abo= ve statement of starting at some slow rate there will always need to be a r= ate change to get to any values other than a Tx interval of 1 second. Let's say I've made the transition from DOWN to INIT based on the reception= of a BFD control packet from the remote end. I now transition to the UP st= ate when receiving the next packet, I'm now expecting him to start sending = at the negotiated rate, however, in the absence of the remote end setting = the F bit to indicate he has programmed his HW to start sending at the prec= onfigured rate, I may unfairly/ prematurely declare the session down if he = has not jumped into UP state himself. Likewise the remote end may have this= problem with my transition too. In short, notwithstanding my objection to lack of P/F I'd like some further= clarification regarding how the rate change mechanism specified in the la= st para of 3.5.1 is expected to work without P/F. Or perhaps this para is = in error since it's inconsistent with the first para of 5.1 stating thing= s remain at a fixed rate. Cheers Rob Rennison -----Original Message----- From: Alexander Vainshtein Sent: Wednesday, March 02, 2011 8:37 AM To: Shahram Davari Cc: mpls@ietf.org; mpls-tp@ietf.org; Robert Rennison; David Allan I Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv= -rdi-03 Shahram and all, Please see some comments inline below. Regards, Sasha > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Tuesday, March 01, 2011 9:55 PM > To: Alexander Vainshtein; David Allan I > Cc: mpls@ietf.org; mpls-tp@ietf.org; Robert Rennison > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03 >=20 > Hi, >=20 > I would like to support the disabling of Poll/Final for MPLS-TP LSP=20 > BFDs. Transport networks don't need to change the rates and are mostly=20 > static. [[[Sasha]]] There are two different statements here IMO: 1. "Transport networks do not have to change the rates". Sounds very much like "transport networks are always single-vendor" to m= e. Because in a multi-vendor environment you have to deal with different ra= te ranges And have from time to time manipulate these rates... 2. "Transport networks are mostly static". I do not really understand how this is related to the subject. =20 Also Poll/Final will most likely require extra Software in > addition to HW, which can increase complexity and cost for MPLS-TP=20 > operation. [[[Sasha]]] Extra SW (as opposed to extra HW) usually doesn't cost to the o= perators. And the vendors who have implemented Poll/Final will have to go into new de= velopment and support two different BFD state machines... if this is not ex= pensive, what is? >=20 > Regards, > Shahram >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > Of Alexander Vainshtein > Sent: Thursday, February 10, 2011 6:38 AM > To: David Allan I > Cc: mpls@ietf.org; mpls-tp@ietf.org; Robert Rennison > Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03 >=20 > Dave, and all, > To avoid any misinterpretation, please consider the original email as=20 > my LC comment. >=20 > Regards, > Sasha >=20 >=20 > -----Original Message----- > From: Alexander Vainshtein > Sent: Thursday, February 10, 2011 1:36 PM > To: 'David Allan I' > Cc: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org;=20 > Robert Rennison > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03 >=20 > Dave and all, > I'd like to remind you that Rob and I have already questioned the=20 > decision to change the BFD state machine by disabling in some case the=20 > Poll/Final sequence. >=20 > The situation as presented in the draft seems to introduce even more=20 > problems. > E.g., RFC 5885 allows to run BFD in VCCV without UDP/IP encapsulation=20 > but follows the procedures specified in RFC 5880 and 5881 which, to=20 > the best of my understanding, include usage of Poll/Final sequence. >=20 > It is my understanding that BFD for an MPLS-TP LSP would look exactly=20 > as BFD in VCCV (including the same code point). > If this is correct, how should the implementation distinguish between > "PWE3 mode" (where poll/final are used) and "MPLS-TP mode where they=20 > seem to be prohibited? >=20 > Regards, > Sasha >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > Of David Allan I > Sent: Thursday, February 10, 2011 1:09 PM > To: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org;=20 > ahmpls-tp@lists.itu.int > Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03 >=20 >=20 >=20 > Hi Mach: >=20 > Thanks for the review >=20 > >I read the draft, here are some comments, please consider: >=20 > >1.Section 3.5, last sentence of first paragraph >=20 > >"Poll/final discipline can only used for VCCV and UDP/IP encapsulated > BFD." > >There is a "be" lost between "can" and "only". >=20 > Good catch, will fix. >=20 > >2.Section 3.5.2 > >"1. BFD control packets are received with an unexpected encapsulation > (mis-connectivity defect), these include: > > - a PW receiving a packet with a GAL", Since GAL can be=20 > >used for=20 > >PW(http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw- > 00), this should not be a defect. Suggest to remove it. >=20 > We'll review and edit accordingly. >=20 > >3 Section 3.5.2 > >" 4. Receipt of an expected session discriminator with an unexpected > label (mis-connectivity defect).", For a receiver, how does it know=20 > that the session >discriminator is valid but the label is invalid? > IMHO, this defect is just another description of defect 3 . Suggest to=20 > remove it. >=20 > If the session discriminator exists in the BFD database, it is=20 > superficially a valid descriminator but the label of arrival can be=20 > incorrect. This may indicate an implementation problem at the source=20 > MEP. What we were referring to in '3' was a session discriminator that=20 > did not exist in the local database, BFD had never handed it out hence=20 > it could not be found. >=20 > >4.Section 3.5.4.2 > >" Exit from a misconfiguration defect occurs when two consecutive CC > or > >CV frames have been received with the expected M bit setting." IMHO, > this sentence is little bit vague, and since this draft only defines=20 > for P2P LSP, why not just say "...with M bit clear." >=20 > OK >=20 > >5. Section 3.5.4.3 > >"Exit from a mis-connectivity defect state occurs when no CV messages=20 > >have been received with an incorrect source MEP-ID for a period of=20 > >3.5 > seconds.", since there are several defects listed in Section 3.5.2 and=20 > this is only one condition for exiting from a mis-connectivity defect=20 > state. How about "Exit >from a mis-connectivity defect state occurs=20 > when no CV messages with mis-connectivity defects have been received=20 > for a period of 3.5 seconds " >=20 > That seems to be more accurate, I'd replace "with...." with=20 > "indicating an on-going mis-connectivity defect has been....". Simply wor= dsmithing. >=20 > >6. Section 3.5.5 >=20 > >In Figure 5, seems that it is lack of "AIS-LDI, LKR" inputs for DOWN > state. >=20 > Good catch. Will fix >=20 > Cheers > Dave >=20 >=20 >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On=20 > > Behalf Of Loa Andersson > > Sent: Thursday, February 03, 2011 10:14 PM > > To: mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int > > Subject: [mpls-tp] mpls wg last call on > > draft-ietf-mpls-tp-cc-cv-rdi-03 > > > > Working Group, > > > > this is to start a four week working group last call on "Proactive=20 > > Connectivity Verification, Continuity Check and Remote Defect=20 > > indication for MPLS Transport Profile" > > (draft-ietf-mpls-tp-cc-cv-rdi-03.txt). > > > > Please send comments to the mpls-tp@ietf.org mailing list. > > > > This working group last call ends on February 28, 2011. > > > > > > Loa, George and Ross > > > > MPLS wg co-chairs > > -- > > > > > > Loa Andersson email: > > loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From Alexander.Vainshtein@ecitele.com Thu Mar 31 02:13:33 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFEE028C0DF for ; Thu, 31 Mar 2011 02:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] 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 d1F1y+-iGnEG for ; Thu, 31 Mar 2011 02:13:32 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id 755473A6B00 for ; Thu, 31 Mar 2011 02:13:31 -0700 (PDT) X-AuditID: 93eaf2e8-b7bb7ae000004cb7-7b-4d9445b7677b Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Brightmail Gateway) with SMTP id D2.90.19639.7B5449D4; Thu, 31 Mar 2011 11:13:27 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 31 Mar 2011 11:15:06 +0200 From: Alexander Vainshtein To: David Allan I , Robert Rennison Date: Thu, 31 Mar 2011 11:14:51 +0200 Thread-Topic: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03: Poll /Final Issues Thread-Index: AcvDrJpCvXJpavHRRhKBBXlDzw1/zAFFYIGQABGDQCAAAKcQEAACic4AAAbIaBADxnLswAAif0NABan8h6AAAbRRsAAAPEBg Message-ID: References: <4D4AB81D.3080907@pi.nu> <06c901cbc8d4$d682a820$8387f860$@com> <60C093A41B5E45409A19D42CF7786DFD51CDF3F790@EUSAACMS0703.eamcs.ericsson.se> <2C2F1EBA8050E74EA81502D5740B4BD6956BBA178B@SJEXCHCCR02.corp.ad.broadcom.com> <786AD2EC3D80A1428B921CDC9BE9EE5466F24A5B28@USPITMAIL01.ecitele.com> <60C093A41B5E45409A19D42CF7786DFD51D5311347@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD51D5311347@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03: Poll /Final Issues X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 09:13:34 -0000 Rob, Dave and all, The question raised by Rob remains unanswered IMHO: How does the side transiting from Init to Up know when to change its detect= ion interval=20 from 3.5 seconds to the interval that matches the configured tx rate of the= peer? If this is done too soon, false LOC will be detected, and it will result in= unnecessary protection switching etc... P/F is one way to resolve this issue. To the best of my understanding, no a= lternative has been proposed so far... Regards, Sasha > -----Original Message----- > From: David Allan I [mailto:david.i.allan@ericsson.com] > Sent: Thursday, March 31, 2011 11:10 AM > To: Robert Rennison; Alexander Vainshtein; Shahram Davari > Cc: mpls@ietf.org > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03: Poll /Final Issues >=20 > Hi Rob: >=20 > The first paragraph of 3.5.1 describes the initialization. The intent > is that an implementation that cannot support the requested periodicity > in the INIT request will not transition from DOWN to INIT and returns a > diagnostic code accordingly. The premise is that the periodicity is a > business requirement hence the negotiation is binary. >=20 > As for the contradictory statements, it is a fixed rate for the UP > state for the life of the session would be more precise wording.... >=20 > Hope this helps > Dave >=20 >=20 >=20 > -----Original Message----- > From: Robert Rennison [mailto:Robert.Rennison@ecitele.com] > Sent: Thursday, March 31, 2011 11:02 AM > To: Alexander Vainshtein; Shahram Davari > Cc: mpls@ietf.org; David Allan I > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03: Poll /Final Issues >=20 > Authors, >=20 > The Poll/Final issue is still open with this document and I'd like to > reiterate one point but also understand a technicality/feasibility >=20 > 1. An observation/ objection: It becomes yet another configuration > subtly / scope for error in needing to know" does the remote end of > this PW support P/F or not". Additionally we are now changing the BFD > state machine and complicating things to pander to the "perception" > that P/F is _unnecessarily_ complex. >=20 > Ok Off soapbox, now to my question. I'd like to understand how folks > who want to run without the P/F mechanism envisage things working. >=20 > If both ends can permanently "blast" at the preconfigured rate and set > the STA bits to say Init (what the Sta should be set to for this always > fixed rate should be made clear) then I can see how both ends will > transition to "Up" and this is what I figured was how things would > happen. However; in more careful reading of the draft I see the > following contradictory statements. >=20 > 3.5. BFD Profile for MPLS-TP >=20 > BFD MUST operate in asynchronous mode. In this mode, the BFD Control > packets are periodically sent at configurable time rate. This rate > is > typically a _fixed_ value for the lifetime of the session. In the > rare > circumstance where an operator has a reason to change session > parameters, the session MUST be moved to the ADMIN DOWN state. > Poll/final discipline can only used for VCCV and UDP/IP encapsulated > BFD. >=20 > Here we are saying things are sent at a fixed rate. >=20 > ------------ > 3.5.1. Session initiation > .... >=20 > Otherwise once a transition from DOWN to INIT has occurred, the > session progresses as per [4]. In both the DOWN and INIT states > messages are transmitted at a rate of one per second and the defect > detection interval is fixed at 3.5 seconds. On transition to the UP > state, message periodicity _changes to_ the negotiated and/or > configured rate and the detect interval switches to detect > multiplier > times the session peer's Tx Rate > ------------ >=20 > Here we are talking about the rate changing to the configured rate, and > there is no distinguishing between whterh P/F is used or not; it's > this change of rate that I cannot see easily working without the P/F >=20 > Paradoxically the so called "complex" poll/final is necessary not just > to change the rate due to some operational nicety but to allow us to > coordinate any rate changes, it's your friend once you understand it. > Given the above statement of starting at some slow rate there will > always need to be a rate change to get to any values other than a Tx > interval of 1 second. >=20 > Let's say I've made the transition from DOWN to INIT based on the > reception of a BFD control packet from the remote end. I now transition > to the UP state when receiving the next packet, I'm now expecting him > to start sending at the negotiated rate, however, in the absence of > the remote end setting the F bit to indicate he has programmed his HW > to start sending at the preconfigured rate, I may unfairly/ prematurely > declare the session down if he has not jumped into UP state himself. > Likewise the remote end may have this problem with my transition too. >=20 > In short, notwithstanding my objection to lack of P/F I'd like some > further clarification regarding how the rate change mechanism > specified in the last para of 3.5.1 is expected to work without P/F. > Or perhaps this para is in error since it's inconsistent with the > first para of 5.1 stating things remain at a fixed rate. >=20 > Cheers >=20 > Rob Rennison >=20 >=20 > -----Original Message----- > From: Alexander Vainshtein > Sent: Wednesday, March 02, 2011 8:37 AM > To: Shahram Davari > Cc: mpls@ietf.org; mpls-tp@ietf.org; Robert Rennison; David Allan I > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03 >=20 > Shahram and all, > Please see some comments inline below. >=20 > Regards, > Sasha >=20 > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Tuesday, March 01, 2011 9:55 PM > > To: Alexander Vainshtein; David Allan I > > Cc: mpls@ietf.org; mpls-tp@ietf.org; Robert Rennison > > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls- > tp- > > cc-cv-rdi-03 > > > > Hi, > > > > I would like to support the disabling of Poll/Final for MPLS-TP LSP > > BFDs. Transport networks don't need to change the rates and are > mostly > > static. > [[[Sasha]]] There are two different statements here IMO: >=20 > 1. "Transport networks do not have to change the rates". > Sounds very much like "transport networks are always single-vendor" > to me. > Because in a multi-vendor environment you have to deal with > different rate ranges > And have from time to time manipulate these rates... >=20 > 2. "Transport networks are mostly static". > I do not really understand how this is related to the subject. >=20 >=20 > Also Poll/Final will most likely require extra Software in > > addition to HW, which can increase complexity and cost for MPLS-TP > > operation. > [[[Sasha]]] Extra SW (as opposed to extra HW) usually doesn't cost to > the operators. > And the vendors who have implemented Poll/Final will have to go into > new development and support two different BFD state machines... if this > is not expensive, what is? > > > > Regards, > > Shahram > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of Alexander Vainshtein > > Sent: Thursday, February 10, 2011 6:38 AM > > To: David Allan I > > Cc: mpls@ietf.org; mpls-tp@ietf.org; Robert Rennison > > Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls- > tp- > > cc-cv-rdi-03 > > > > Dave, and all, > > To avoid any misinterpretation, please consider the original email as > > my LC comment. > > > > Regards, > > Sasha > > > > > > -----Original Message----- > > From: Alexander Vainshtein > > Sent: Thursday, February 10, 2011 1:36 PM > > To: 'David Allan I' > > Cc: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; > > Robert Rennison > > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls- > tp- > > cc-cv-rdi-03 > > > > Dave and all, > > I'd like to remind you that Rob and I have already questioned the > > decision to change the BFD state machine by disabling in some case > the > > Poll/Final sequence. > > > > The situation as presented in the draft seems to introduce even more > > problems. > > E.g., RFC 5885 allows to run BFD in VCCV without UDP/IP encapsulation > > but follows the procedures specified in RFC 5880 and 5881 which, to > > the best of my understanding, include usage of Poll/Final sequence. > > > > It is my understanding that BFD for an MPLS-TP LSP would look exactly > > as BFD in VCCV (including the same code point). > > If this is correct, how should the implementation distinguish between > > "PWE3 mode" (where poll/final are used) and "MPLS-TP mode where they > > seem to be prohibited? > > > > Regards, > > Sasha > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of David Allan I > > Sent: Thursday, February 10, 2011 1:09 PM > > To: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; > > ahmpls-tp@lists.itu.int > > Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls- > tp- > > cc-cv-rdi-03 > > > > > > > > Hi Mach: > > > > Thanks for the review > > > > >I read the draft, here are some comments, please consider: > > > > >1.Section 3.5, last sentence of first paragraph > > > > >"Poll/final discipline can only used for VCCV and UDP/IP > encapsulated > > BFD." > > >There is a "be" lost between "can" and "only". > > > > Good catch, will fix. > > > > >2.Section 3.5.2 > > >"1. BFD control packets are received with an unexpected > encapsulation > > (mis-connectivity defect), these include: > > > - a PW receiving a packet with a GAL", Since GAL can be > > >used for > > >PW(http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw- > > 00), this should not be a defect. Suggest to remove it. > > > > We'll review and edit accordingly. > > > > >3 Section 3.5.2 > > >" 4. Receipt of an expected session discriminator with an unexpected > > label (mis-connectivity defect).", For a receiver, how does it know > > that the session >discriminator is valid but the label is invalid? > > IMHO, this defect is just another description of defect 3 . Suggest > to > > remove it. > > > > If the session discriminator exists in the BFD database, it is > > superficially a valid descriminator but the label of arrival can be > > incorrect. This may indicate an implementation problem at the source > > MEP. What we were referring to in '3' was a session discriminator > that > > did not exist in the local database, BFD had never handed it out > hence > > it could not be found. > > > > >4.Section 3.5.4.2 > > >" Exit from a misconfiguration defect occurs when two consecutive CC > > or > > >CV frames have been received with the expected M bit setting." IMHO, > > this sentence is little bit vague, and since this draft only defines > > for P2P LSP, why not just say "...with M bit clear." > > > > OK > > > > >5. Section 3.5.4.3 > > >"Exit from a mis-connectivity defect state occurs when no CV > messages > > >have been received with an incorrect source MEP-ID for a period of > > >3.5 > > seconds.", since there are several defects listed in Section 3.5.2 > and > > this is only one condition for exiting from a mis-connectivity defect > > state. How about "Exit >from a mis-connectivity defect state occurs > > when no CV messages with mis-connectivity defects have been received > > for a period of 3.5 seconds " > > > > That seems to be more accurate, I'd replace "with...." with > > "indicating an on-going mis-connectivity defect has been....". Simply > wordsmithing. > > > > >6. Section 3.5.5 > > > > >In Figure 5, seems that it is lack of "AIS-LDI, LKR" inputs for DOWN > > state. > > > > Good catch. Will fix > > > > Cheers > > Dave > > > > > > > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On > > > Behalf Of Loa Andersson > > > Sent: Thursday, February 03, 2011 10:14 PM > > > To: mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int > > > Subject: [mpls-tp] mpls wg last call on > > > draft-ietf-mpls-tp-cc-cv-rdi-03 > > > > > > Working Group, > > > > > > this is to start a four week working group last call on "Proactive > > > Connectivity Verification, Continuity Check and Remote Defect > > > indication for MPLS Transport Profile" > > > (draft-ietf-mpls-tp-cc-cv-rdi-03.txt). > > > > > > Please send comments to the mpls-tp@ietf.org mailing list. > > > > > > This working group last call ends on February 28, 2011. > > > > > > > > > Loa, George and Ross > > > > > > MPLS wg co-chairs > > > -- > > > > > > > > > Loa Andersson email: > > > loa.andersson@ericsson.com > > > Sr Strategy and Standards Manager loa@pi.nu > > > Ericsson Inc phone: +46 10 717 52 13 > > > +46 767 72 92 13 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > From david.i.allan@ericsson.com Thu Mar 31 02:27:13 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB0B28C223 for ; Thu, 31 Mar 2011 02:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.466 X-Spam-Level: X-Spam-Status: No, score=-5.466 tagged_above=-999 required=5 tests=[AWL=1.133, 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 nCruI7rW-oIf for ; Thu, 31 Mar 2011 02:27:08 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 2856028C1A9 for ; Thu, 31 Mar 2011 02:23:50 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p2V9PDRs026905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Mar 2011 04:25:13 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.203]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 31 Mar 2011 05:25:12 -0400 From: David Allan I To: Alexander Vainshtein , Robert Rennison Date: Thu, 31 Mar 2011 05:25:10 -0400 Thread-Topic: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03: Poll /Final Issues Thread-Index: AcvDrJpCvXJpavHRRhKBBXlDzw1/zAFFYIGQABGDQCAAAKcQEAACic4AAAbIaBADxnLswAAif0NABan8h6AAAbRRsAAAPEBgAABsHVA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD51D531134E@EUSAACMS0703.eamcs.ericsson.se> References: <4D4AB81D.3080907@pi.nu> <06c901cbc8d4$d682a820$8387f860$@com> <60C093A41B5E45409A19D42CF7786DFD51CDF3F790@EUSAACMS0703.eamcs.ericsson.se> <2C2F1EBA8050E74EA81502D5740B4BD6956BBA178B@SJEXCHCCR02.corp.ad.broadcom.com> <786AD2EC3D80A1428B921CDC9BE9EE5466F24A5B28@USPITMAIL01.ecitele.com> <60C093A41B5E45409A19D42CF7786DFD51D5311347@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03: Poll /Final Issues X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 09:27:14 -0000 Hi: A further clarification would be that upon receipt of UP from the peer MEP = would be the time to change the detect mult to 3.5*rxinterval. That would b= e the point where the far end changed its periodicity from 1/sec to rxinter= val, and would avoid the potential race condition you describe.... I'll treat this discussion as LC comments requiring clarification for now..= . D -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Thursday, March 31, 2011 11:15 AM To: David Allan I; Robert Rennison Cc: mpls@ietf.org; Shahram Davari Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv= -rdi-03: Poll /Final Issues Rob, Dave and all, The question raised by Rob remains unanswered IMHO: How does the side transiting from Init to Up know when to change its detect= ion interval from 3.5 seconds to the interval that matches the configured t= x rate of the peer? If this is done too soon, false LOC will be detected, and it will result in= unnecessary protection switching etc... P/F is one way to resolve this issue. To the best of my understanding, no a= lternative has been proposed so far... Regards, Sasha > -----Original Message----- > From: David Allan I [mailto:david.i.allan@ericsson.com] > Sent: Thursday, March 31, 2011 11:10 AM > To: Robert Rennison; Alexander Vainshtein; Shahram Davari > Cc: mpls@ietf.org > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03: Poll /Final Issues > > Hi Rob: > > The first paragraph of 3.5.1 describes the initialization. The intent > is that an implementation that cannot support the requested > periodicity in the INIT request will not transition from DOWN to INIT > and returns a diagnostic code accordingly. The premise is that the > periodicity is a business requirement hence the negotiation is binary. > > As for the contradictory statements, it is a fixed rate for the UP > state for the life of the session would be more precise wording.... > > Hope this helps > Dave > > > > -----Original Message----- > From: Robert Rennison [mailto:Robert.Rennison@ecitele.com] > Sent: Thursday, March 31, 2011 11:02 AM > To: Alexander Vainshtein; Shahram Davari > Cc: mpls@ietf.org; David Allan I > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03: Poll /Final Issues > > Authors, > > The Poll/Final issue is still open with this document and I'd like to > reiterate one point but also understand a technicality/feasibility > > 1. An observation/ objection: It becomes yet another configuration > subtly / scope for error in needing to know" does the remote end of > this PW support P/F or not". Additionally we are now changing the > BFD state machine and complicating things to pander to the "perception" > that P/F is _unnecessarily_ complex. > > Ok Off soapbox, now to my question. I'd like to understand how folks > who want to run without the P/F mechanism envisage things working. > > If both ends can permanently "blast" at the preconfigured rate and set > the STA bits to say Init (what the Sta should be set to for this > always fixed rate should be made clear) then I can see how both ends > will transition to "Up" and this is what I figured was how things > would happen. However; in more careful reading of the draft I see the > following contradictory statements. > > 3.5. BFD Profile for MPLS-TP > > BFD MUST operate in asynchronous mode. In this mode, the BFD Control > packets are periodically sent at configurable time rate. This rate > is > typically a _fixed_ value for the lifetime of the session. In the > rare > circumstance where an operator has a reason to change session > parameters, the session MUST be moved to the ADMIN DOWN state. > Poll/final discipline can only used for VCCV and UDP/IP encapsulated > BFD. > > Here we are saying things are sent at a fixed rate. > > ------------ > 3.5.1. Session initiation > .... > > Otherwise once a transition from DOWN to INIT has occurred, the > session progresses as per [4]. In both the DOWN and INIT states > messages are transmitted at a rate of one per second and the defect > detection interval is fixed at 3.5 seconds. On transition to the UP > state, message periodicity _changes to_ the negotiated and/or > configured rate and the detect interval switches to detect > multiplier > times the session peer's Tx Rate > ------------ > > Here we are talking about the rate changing to the configured rate, > and there is no distinguishing between whterh P/F is used or not; > it's this change of rate that I cannot see easily working without the > P/F > > Paradoxically the so called "complex" poll/final is necessary not > just to change the rate due to some operational nicety but to allow > us to coordinate any rate changes, it's your friend once you understand i= t. > Given the above statement of starting at some slow rate there will > always need to be a rate change to get to any values other than a Tx > interval of 1 second. > > Let's say I've made the transition from DOWN to INIT based on the > reception of a BFD control packet from the remote end. I now > transition to the UP state when receiving the next packet, I'm now > expecting him to start sending at the negotiated rate, however, in the > absence of the remote end setting the F bit to indicate he has > programmed his HW to start sending at the preconfigured rate, I may > unfairly/ prematurely declare the session down if he has not jumped into = UP state himself. > Likewise the remote end may have this problem with my transition too. > > In short, notwithstanding my objection to lack of P/F I'd like some > further clarification regarding how the rate change mechanism > specified in the last para of 3.5.1 is expected to work without P/F. > Or perhaps this para is in error since it's inconsistent with the > first para of 5.1 stating things remain at a fixed rate. > > Cheers > > Rob Rennison > > > -----Original Message----- > From: Alexander Vainshtein > Sent: Wednesday, March 02, 2011 8:37 AM > To: Shahram Davari > Cc: mpls@ietf.org; mpls-tp@ietf.org; Robert Rennison; David Allan I > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp- > cc-cv-rdi-03 > > Shahram and all, > Please see some comments inline below. > > Regards, > Sasha > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Tuesday, March 01, 2011 9:55 PM > > To: Alexander Vainshtein; David Allan I > > Cc: mpls@ietf.org; mpls-tp@ietf.org; Robert Rennison > > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls- > tp- > > cc-cv-rdi-03 > > > > Hi, > > > > I would like to support the disabling of Poll/Final for MPLS-TP LSP > > BFDs. Transport networks don't need to change the rates and are > mostly > > static. > [[[Sasha]]] There are two different statements here IMO: > > 1. "Transport networks do not have to change the rates". > Sounds very much like "transport networks are always single-vendor" > to me. > Because in a multi-vendor environment you have to deal with > different rate ranges > And have from time to time manipulate these rates... > > 2. "Transport networks are mostly static". > I do not really understand how this is related to the subject. > > > Also Poll/Final will most likely require extra Software in > > addition to HW, which can increase complexity and cost for MPLS-TP > > operation. > [[[Sasha]]] Extra SW (as opposed to extra HW) usually doesn't cost to > the operators. > And the vendors who have implemented Poll/Final will have to go into > new development and support two different BFD state machines... if > this is not expensive, what is? > > > > Regards, > > Shahram > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of Alexander Vainshtein > > Sent: Thursday, February 10, 2011 6:38 AM > > To: David Allan I > > Cc: mpls@ietf.org; mpls-tp@ietf.org; Robert Rennison > > Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls- > tp- > > cc-cv-rdi-03 > > > > Dave, and all, > > To avoid any misinterpretation, please consider the original email > > as my LC comment. > > > > Regards, > > Sasha > > > > > > -----Original Message----- > > From: Alexander Vainshtein > > Sent: Thursday, February 10, 2011 1:36 PM > > To: 'David Allan I' > > Cc: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; > > Robert Rennison > > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls- > tp- > > cc-cv-rdi-03 > > > > Dave and all, > > I'd like to remind you that Rob and I have already questioned the > > decision to change the BFD state machine by disabling in some case > the > > Poll/Final sequence. > > > > The situation as presented in the draft seems to introduce even more > > problems. > > E.g., RFC 5885 allows to run BFD in VCCV without UDP/IP > > encapsulation but follows the procedures specified in RFC 5880 and > > 5881 which, to the best of my understanding, include usage of Poll/Fina= l sequence. > > > > It is my understanding that BFD for an MPLS-TP LSP would look > > exactly as BFD in VCCV (including the same code point). > > If this is correct, how should the implementation distinguish > > between > > "PWE3 mode" (where poll/final are used) and "MPLS-TP mode where they > > seem to be prohibited? > > > > Regards, > > Sasha > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of David Allan I > > Sent: Thursday, February 10, 2011 1:09 PM > > To: Mach Chen; 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; > > ahmpls-tp@lists.itu.int > > Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls- > tp- > > cc-cv-rdi-03 > > > > > > > > Hi Mach: > > > > Thanks for the review > > > > >I read the draft, here are some comments, please consider: > > > > >1.Section 3.5, last sentence of first paragraph > > > > >"Poll/final discipline can only used for VCCV and UDP/IP > encapsulated > > BFD." > > >There is a "be" lost between "can" and "only". > > > > Good catch, will fix. > > > > >2.Section 3.5.2 > > >"1. BFD control packets are received with an unexpected > encapsulation > > (mis-connectivity defect), these include: > > > - a PW receiving a packet with a GAL", Since GAL can be > > >used for > > >PW(http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw- > > 00), this should not be a defect. Suggest to remove it. > > > > We'll review and edit accordingly. > > > > >3 Section 3.5.2 > > >" 4. Receipt of an expected session discriminator with an > > >unexpected > > label (mis-connectivity defect).", For a receiver, how does it know > > that the session >discriminator is valid but the label is invalid? > > IMHO, this defect is just another description of defect 3 . Suggest > to > > remove it. > > > > If the session discriminator exists in the BFD database, it is > > superficially a valid descriminator but the label of arrival can be > > incorrect. This may indicate an implementation problem at the source > > MEP. What we were referring to in '3' was a session discriminator > that > > did not exist in the local database, BFD had never handed it out > hence > > it could not be found. > > > > >4.Section 3.5.4.2 > > >" Exit from a misconfiguration defect occurs when two consecutive > > >CC > > or > > >CV frames have been received with the expected M bit setting." > > >IMHO, > > this sentence is little bit vague, and since this draft only defines > > for P2P LSP, why not just say "...with M bit clear." > > > > OK > > > > >5. Section 3.5.4.3 > > >"Exit from a mis-connectivity defect state occurs when no CV > messages > > >have been received with an incorrect source MEP-ID for a period of > > >3.5 > > seconds.", since there are several defects listed in Section 3.5.2 > and > > this is only one condition for exiting from a mis-connectivity > > defect state. How about "Exit >from a mis-connectivity defect state > > occurs when no CV messages with mis-connectivity defects have been > > received for a period of 3.5 seconds " > > > > That seems to be more accurate, I'd replace "with...." with > > "indicating an on-going mis-connectivity defect has been....". > > Simply > wordsmithing. > > > > >6. Section 3.5.5 > > > > >In Figure 5, seems that it is lack of "AIS-LDI, LKR" inputs for > > >DOWN > > state. > > > > Good catch. Will fix > > > > Cheers > > Dave > > > > > > > > > -----Original Message----- > > > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] > > > On Behalf Of Loa Andersson > > > Sent: Thursday, February 03, 2011 10:14 PM > > > To: mpls-tp@ietf.org; mpls@ietf.org; ahmpls-tp@lists.itu.int > > > Subject: [mpls-tp] mpls wg last call on > > > draft-ietf-mpls-tp-cc-cv-rdi-03 > > > > > > Working Group, > > > > > > this is to start a four week working group last call on "Proactive > > > Connectivity Verification, Continuity Check and Remote Defect > > > indication for MPLS Transport Profile" > > > (draft-ietf-mpls-tp-cc-cv-rdi-03.txt). > > > > > > Please send comments to the mpls-tp@ietf.org mailing list. > > > > > > This working group last call ends on February 28, 2011. > > > > > > > > > Loa, George and Ross > > > > > > MPLS wg co-chairs > > > -- > > > > > > > > > Loa Andersson email: > > > loa.andersson@ericsson.com > > > Sr Strategy and Standards Manager loa@pi.nu > > > Ericsson Inc phone: +46 10 717 52 13 > > > +46 767 72 92 13 > > > _______________________________________________ > > > mpls-tp mailing list > > > mpls-tp@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > From Alexander.Vainshtein@ecitele.com Thu Mar 31 10:29:42 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BF9B3A6A1B for ; Thu, 31 Mar 2011 10:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 TfpyP4orplPq for ; Thu, 31 Mar 2011 10:29:36 -0700 (PDT) Received: from ilptbmg02.ecitele.com (ilptbmg02-out.ecitele.com [147.234.242.235]) by core3.amsl.com (Postfix) with ESMTP id 11AAE28B797 for ; Thu, 31 Mar 2011 10:29:35 -0700 (PDT) X-AuditID: 93eaf2e8-b7bb7ae000004cb7-a2-4d94b9fc02cb Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Brightmail Gateway) with SMTP id 8D.7A.19639.CF9B49D4; Thu, 31 Mar 2011 19:29:32 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 31 Mar 2011 19:31:14 +0200 From: Alexander Vainshtein To: Martini Date: Thu, 31 Mar 2011 19:30:51 +0200 Thread-Topic: Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free? Thread-Index: AcvvyWFcwqfBDpADRyOjnpzGuEFE1w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {B3057A61-E2DF-4904-BACB-6A2397F7B14B} x-cr-hashedpuzzle: Agbd BA4l CkNe Ehyr E2sE ILDg KQtQ LvAB N65g OIKf R+Rn SxQ4 TsZb Tw8e T1nR WWQI; 2; bABtAGEAcgB0AGkAbgBpAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBtAHAAbABzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {B3057A61-E2DF-4904-BACB-6A2397F7B14B}; YQBsAGUAeABhAG4AZABlAHIALgB2AGEAaQBuAHMAaAB0AGUAaQBuAEAAZQBjAGkAdABlAGwAZQAuAGMAbwBtAA==; Thu, 31 Mar 2011 17:30:51 GMT; RABvACAAdwBlACAAbgBlAGUAZAAgAHQAbwAgAHIAZQBpAG4AdgBlAG4AdAAgAFQAQwBQAC8ASQBQACwAIABvAHIAIAB3AGgAYQB0ACAAZABvAGUAcwAgAGkAdAAgAHIAZQBhAGwAbAB5ACAAbQBlAGEAbgAgAHQAaABhAHQAIABNAFAATABTAC0AVABQACAAaQBzACAASQBQAC0AZgByAGUAZQA/AA== acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76D722EB60F2ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" Subject: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 17:29:42 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D722EB60F2ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Luca and all, What I have been trying to say at the mike today can be essentially reduced= to a very simple statement: The "requirement" for IP-free MPLS-TP is very vague and requires clarificat= ion. MPLS-TP nodes presumably have to be managed (especially if they are suppose= d to operate independent of any control plane). And personally I do not bel= ieve they are going to be managed by connecting a local terminal via a seri= al cable to each of these nodes (of course you are free to disagree:)). This assumes a Management Communication Network (MCN), and , IMHO, this ass= umption is ensconced in RFC 5951 (which states that typically MPLS-TP nods = can be expected o have addresses on the MCN) while RFC 5718 provides the re= quired infrastructure for the MCN over G-ACH. Of course we can pretend that we do not know which network protocol will ru= n on top of the MCN (and some people have been arguing that we should selec= t the OSI stack for that purpose in the early days of the MPLS-TP work); bu= t I would expect that within the IETF refusal to use IP in this role should= not be taken too seriously:). The recent work on SNMP MIBs architecture f= or MPLS-TP looks to me as an additional confirmation. Hence it seems safe to assume that each MPLS-TP node will run at least a ho= st IP stack (not necessarily in the forwarding path). Once we agree on that, we could stop reinventing "TCP/IP for poor" with pr= oprietary solutions for reliability, fragmentation/reassembly, congestion a= voidance etc. My 2c, Sasha --_000_A3C5DF08D38B6049839A6F553B331C76D722EB60F2ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Luca and all,

What I have been trying to say at the mike= today can be essentially reduced to a very simple statement:

 

The “requirement” for IP-free MPLS-TP is very= vague and requires clarification.

=  

MPLS-TP nodes presumably have to be ma= naged (especially if they are supposed to operate independent of any contro= l plane). And personally I do not believe they are going to be managed by c= onnecting a local terminal via a serial cable to each of these nodes (of co= urse you are free to disagreeJ= ).  

 

This assumes a Management Communication Network (MCN), and , I= MHO, this assumption is ensconced in RFC 5951 (which states that typically = MPLS-TP nods can be expected o have addresses on the MCN) while RFC 5718 pr= ovides the required infrastructure for the MCN over G-ACH.

 

Of course we c= an pretend that we do not know which network protocol will run on top of th= e MCN (and some people have been arguing that we should select the OSI stac= k for that purpose in the early days of the MPLS-TP work); but I would expe= ct that within the IETF refusal to use IP in this role should not be taken = too seriouslyJ. The recent wor= k  on SNMP MIBs architecture for MPLS-TP looks to me as an additional = confirmation.

 

Hence it seems safe to assume that each MPLS-TP node will r= un at least a host IP stack (not necessarily in the forwarding path).<= /o:p>

 

Onc= e we agree on that, we could stop reinventing “TCP/IP for poor”=  with proprietary solutions for reliability, fragmentation/reassembly= , congestion avoidance etc.

 <= /o:p>

My 2c,

&nb= sp;    Sasha

 <= /o:p>

= --_000_A3C5DF08D38B6049839A6F553B331C76D722EB60F2ILPTMAIL02eci_-- From saalvare@cisco.com Thu Mar 31 12:57:51 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735C53A6B2C for ; Thu, 31 Mar 2011 12:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.986 X-Spam-Level: X-Spam-Status: No, score=-9.986 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 5Ab7TY1xaENp for ; Thu, 31 Mar 2011 12:57:46 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1DDD43A6AA4 for ; Thu, 31 Mar 2011 12:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=saalvare@cisco.com; l=8401; q=dns/txt; s=iport; t=1301601566; x=1302811166; h=mime-version:subject:date:message-id:from:to:cc; bh=Nkg25a1uwwkZgeYScEWREPnOK3cUl20MhyG6Vtvif/k=; b=apQy4MbF0W5YrDDXF/RsCA+w0kzV/bXN74Ws+yZm66h97JimhLTf7ciL Qj17cSFyaEKr4YGieaZuUy9zBLCg97SR/hmTLx5mXPlwqK8DwELU5xKcd zdBdeEgOR5fQSsQsTZjto7LSp6BxDBIb/FtyQ1HTIib1KAUCMb+aVfai3 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAMPclE2tJXG//2dsb2JhbACCXpU5jT93o2qcOoVrBIVBiys X-IronPort-AV: E=Sophos;i="4.63,277,1299456000"; d="scan'208,217";a="674008139" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-6.cisco.com with ESMTP; 31 Mar 2011 19:59:25 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2VJxOvX001560; Thu, 31 Mar 2011 19:59:25 GMT Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 12:59:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEFDE.220D5992" Date: Thu, 31 Mar 2011 12:59:23 -0700 Message-ID: <96327EF53EF71A48806DE2DFC034D57F0E3E9C14@xmb-sjc-22b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Do we need to reinvent TCP/IP, or what does it really meanthat MPLS-TP is IP-free? Thread-Index: AcvvyWFcwqfBDpADRyOjnpzGuEFE1wAE3psg From: "Santiago Alvarez (saalvare)" To: "Alexander Vainshtein" , "Luca Martini (lmartini)" X-OriginalArrivalTime: 31 Mar 2011 19:59:24.0669 (UTC) FILETIME=[22418AD0:01CBEFDE] Cc: mpls@ietf.org, "Santiago Alvarez \(saalvare\)" Subject: Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 19:57:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEFDE.220D5992 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MPLS-TP nodes would need an IP host stack to be able to source/sink IP traffic for management (e.g. SNMP). An LSR should not have an IP routing function with the exception of a LER where IP acts as a client. That IP routing/forwarding function should be defined in RFC 1812. Cheers. =20 SA -- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Thursday, March 31, 2011 10:31 AM To: Luca Martini (lmartini) Cc: mpls@ietf.org Subject: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free? =20 Luca and all, What I have been trying to say at the mike today can be essentially reduced to a very simple statement: =20 The "requirement" for IP-free MPLS-TP is very vague and requires clarification. =20 MPLS-TP nodes presumably have to be managed (especially if they are supposed to operate independent of any control plane). And personally I do not believe they are going to be managed by connecting a local terminal via a serial cable to each of these nodes (of course you are free to disagreeJ). =20 =20 This assumes a Management Communication Network (MCN), and , IMHO, this assumption is ensconced in RFC 5951 (which states that typically MPLS-TP nods can be expected o have addresses on the MCN) while RFC 5718 provides the required infrastructure for the MCN over G-ACH. =20 Of course we can pretend that we do not know which network protocol will run on top of the MCN (and some people have been arguing that we should select the OSI stack for that purpose in the early days of the MPLS-TP work); but I would expect that within the IETF refusal to use IP in this role should not be taken too seriouslyJ. The recent work on SNMP MIBs architecture for MPLS-TP looks to me as an additional confirmation. =20 Hence it seems safe to assume that each MPLS-TP node will run at least a host IP stack (not necessarily in the forwarding path). =20 Once we agree on that, we could stop reinventing "TCP/IP for poor" with proprietary solutions for reliability, fragmentation/reassembly, congestion avoidance etc. =20 My 2c, Sasha =20 ------_=_NextPart_001_01CBEFDE.220D5992 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MPLS-TP nodes would need an IP host stack to be = able to source/sink IP traffic for management (e.g. SNMP).  An LSR = should not have an IP routing function with the exception of a LER where = IP acts as a client. That IP routing/forwarding function should be = defined in RFC 1812.

Cheers.

 

SA

--

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Alexander Vainshtein
Sent: Thursday, March 31, 2011 10:31 = AM
To: Luca Martini (lmartini)
Cc: = mpls@ietf.org
Subject: [mpls] Do we need to reinvent TCP/IP, = or what does it really mean that MPLS-TP is = IP-free?

 

Luca and = all,

What I have been trying to say = at the mike today can be essentially reduced to a very simple = statement:

 

The = “requirement” for IP-free MPLS-TP is very vague and requires = clarification.

 

MPLS-TP = nodes presumably have to be managed (especially if they are supposed to = operate independent of any control plane). And personally I do not = believe they are going to be managed by connecting a local terminal via = a serial cable to each of these nodes (of course you are free to = disagreeJ). =  

 

This assumes a Management Communication Network (MCN), = and , IMHO, this assumption is ensconced in RFC 5951 (which states that = typically MPLS-TP nods can be expected o have addresses on the MCN) = while RFC 5718 provides the required infrastructure for the MCN over = G-ACH.

 

Of course we can pretend that we do not know which = network protocol will run on top of the MCN (and some people have been = arguing that we should select the OSI stack for that purpose in the = early days of the MPLS-TP work); but I would expect that within the IETF = refusal to use IP in this role should not be taken too seriouslyJ. The recent work  on SNMP = MIBs architecture for MPLS-TP looks to me as an additional = confirmation.

 

Hence it seems safe to assume that each MPLS-TP node = will run at least a host IP stack (not necessarily in the forwarding = path).

 

Once we agree on that, we could stop reinventing = “TCP/IP for poor”  with proprietary solutions for = reliability, fragmentation/reassembly, congestion avoidance = etc.

 

My 2c,

     Sasha

 

------_=_NextPart_001_01CBEFDE.220D5992-- From venkatflex@gmail.com Thu Mar 31 13:10:26 2011 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD01E3A69C4 for ; Thu, 31 Mar 2011 13:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 2S3QMAJt7G+8 for ; Thu, 31 Mar 2011 13:10:25 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 61A943A6AA4 for ; Thu, 31 Mar 2011 13:10:25 -0700 (PDT) Received: by vws12 with SMTP id 12so2555645vws.31 for ; Thu, 31 Mar 2011 13:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=f/TrEooFwUeaEBxyM1IHVmAyrXO8Zju2zIand63K+KI=; b=i2eCxudnuBrAfAqVKCU1FjOYxWWDFgl26M1ec+Biw38BmoHIVyRZaFX/SH2j40uJ6N d5BQoZL5ybCBLVAcQhZRka4MpX2ld8XkUTBNaYyka1HK1yS7ahwqLB7q+29sfqeu6cwS Av0+WYkAO8RWk8QFyA/zPzXOCQ1bNuaRtpWDI= 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 :content-type; b=fdq+BUYo+8WkeCV9xIhg7xyljd+OF2EsLlD06Ejxb0eHHWGAVe2JS9cQfsZbEGo8O9 2+PIewFApZqxuL9SVKM84I82awCTjUjsd1w8yBmxvfnbqvukfeFeZIlMV/LPaXjX2VsH weJn2IKkAgDMOXHEbigP6Cn2mObv3xWUje0yQ= MIME-Version: 1.0 Received: by 10.52.94.108 with SMTP id db12mr4118606vdb.293.1301602324741; Thu, 31 Mar 2011 13:12:04 -0700 (PDT) Received: by 10.52.164.230 with HTTP; Thu, 31 Mar 2011 13:12:04 -0700 (PDT) In-Reply-To: <96327EF53EF71A48806DE2DFC034D57F0E3E9C14@xmb-sjc-22b.amer.cisco.com> References: <96327EF53EF71A48806DE2DFC034D57F0E3E9C14@xmb-sjc-22b.amer.cisco.com> Date: Thu, 31 Mar 2011 16:12:04 -0400 Message-ID: From: venkatesan mahalingam To: "Santiago Alvarez (saalvare)" , mpls , Alexander Vainshtein Content-Type: multipart/alternative; boundary=20cf307abcf9347d3c049fcce842 Subject: Re: [mpls] Do we need to reinvent TCP/IP, or what does it really mean that MPLS-TP is IP-free? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 20:10:26 -0000 --20cf307abcf9347d3c049fcce842 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I think, we need at least an IP host stack on every node along the MPLS-TP path to support the IP based management operations (ex. SNMP). Thanks, Venkat. On Thu, Mar 31, 2011 at 3:59 PM, Santiago Alvarez (saalvare) < saalvare@cisco.com> wrote: > MPLS-TP nodes would need an IP host stack to be able to source/sink IP > traffic for management (e.g. SNMP). An LSR should not have an IP routing > function with the exception of a LER where IP acts as a client. That IP > routing/forwarding function should be defined in RFC 1812. > > Cheers. > > > > SA > > -- > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf O= f > *Alexander Vainshtein > *Sent:* Thursday, March 31, 2011 10:31 AM > *To:* Luca Martini (lmartini) > *Cc:* mpls@ietf.org > *Subject:* [mpls] Do we need to reinvent TCP/IP, or what does it really > mean that MPLS-TP is IP-free? > > > > Luca and all, > > What I have been trying to say at the mike today can be essentially reduc= ed > to a very simple statement: > > > > The =93requirement=94 for IP-free MPLS-TP is very vague and requires > clarification. > > > > MPLS-TP nodes presumably have to be managed (especially if they are > supposed to operate independent of any control plane). And personally I d= o > not believe they are going to be managed by connecting a local terminal v= ia > a serial cable to each of these nodes (of course you are free to disagree= J). > > > > > This assumes a Management Communication Network (MCN), and , IMHO, this > assumption is ensconced in RFC 5951 (which states that typically MPLS-TP > nods can be expected o have addresses on the MCN) while RFC 5718 provides > the required infrastructure for the MCN over G-ACH. > > > > Of course we can pretend that we do not know which network protocol will > run on top of the MCN (and some people have been arguing that we should > select the OSI stack for that purpose in the early days of the MPLS-TP > work); but I would expect that within the IETF refusal to use IP in this > role should not be taken too seriouslyJ. The recent work on SNMP MIBs > architecture for MPLS-TP looks to me as an additional confirmation. > > > > Hence it seems safe to assume that each MPLS-TP node will run at least a > host IP stack (not necessarily in the forwarding path). > > > > Once we agree on that, we could stop reinventing =93TCP/IP for poor=94 w= ith > proprietary solutions for reliability, fragmentation/reassembly, congesti= on > avoidance etc. > > > > My 2c, > > Sasha > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --20cf307abcf9347d3c049fcce842 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,

I think, we need at least an IP host stack on = every node along the MPLS-TP path to support the IP based management operat= ions (ex. SNMP).

Thanks,
Venkat.
On Thu, Mar 31, 2011 at 3:59 PM, Santiago Alvarez (saalvare) <saalvare@cisco.com> wrote:

MPLS-TP nodes would need an IP host stack= to be able to source/sink IP traffic for management (e.g. SNMP).=A0 An LSR= should not have an IP routing function with the exception of a LER where I= P acts as a client. That IP routing/forwarding function should be defined i= n RFC 1812.

Cheers.

=A0

SA

--

From: mpls-bounces= @ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Thursday, March 31, 2011 10:31 AM
To: Luca Martini (= lmartini)
Cc: = mpls@ietf.org
Subject: [mpls] Do we need to reinvent TCP/IP, = or what does it really mean that MPLS-TP is IP-free?

=A0

Luca and all,

What= I have been trying to say at the mike today can be essentially reduced to = a very simple statement:

=A0

The =93requirement=94 for IP-free MPLS-TP is very vague and requires c= larification.

=A0

MPLS-= TP nodes presumably have to be managed (especially if they are supposed to = operate independent of any control plane). And personally I do not believe = they are going to be managed by connecting a local terminal via a serial ca= ble to each of these nodes (of course you are free to disagreeJ). =A0

=A0

This assumes a Managem= ent Communication Network (MCN), and , IMHO, this assumption is ensconced i= n RFC 5951 (which states that typically MPLS-TP nods can be expected o have= addresses on the MCN) while RFC 5718 provides the required infrastructure = for the MCN over G-ACH.

=A0

Of course we can prete= nd that we do not know which network protocol will run on top of the MCN (a= nd some people have been arguing that we should select the OSI stack for th= at purpose in the early days of the MPLS-TP work); but I would expect that = within the IETF refusal to use IP in this role should not be taken too seri= ouslyJ. The recent work =A0on = SNMP MIBs architecture for MPLS-TP looks to me as an additional confirmatio= n.

=A0

Hence it seems safe to= assume that each MPLS-TP node will run at least a host IP stack (not neces= sarily in the forwarding path).

=A0

Once we agree on that, we could stop reinventing =93TCP/IP for poor=94 =A0w= ith proprietary solutions for reliability, fragmentation/reassembly, conges= tion avoidance etc.

=A0

My 2c,

=A0=A0=A0=A0 Sasha

=A0

=

_________________________________________= ______
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls


--20cf307abcf9347d3c049fcce842--